If your database is being accessed from a web-based system it is in hostile territory. Typically, your web-facing application server will be running in a walled-off part of your network which is considered “untrusted”. This is often referred to as a DMZ.

This partitioning of your network is to keep servers that are publicly accessed from the internet, separate from any sensitive infrastructure. This is partly because of the poor history of web application security, and partly from a justifiable sense of caution.

Servers in the DMZ are often viewed as disposable, and easily rebuilt and replaced. The problem though, is that these servers must be given access, whether directly or indirectly, to your data and therefore to your databases. So, your databases have to accept queries from these “untrusted” servers.

When everything is secure and working as it should, your database will process many different queries on behalf of many different users having many different levels of access. It is likely that most of your database tables, and most of their contents need to be accessible to one legitimate user or another. Which means that the database server generally has to provide almost unlimited access to its data, to a server that by definition is not to be trusted.

Aside: many developers consider web-services to be a solution to this, but all they do is add an intermediate layer. Whether your web application provides access to different aspects of customer data indirectly via multiple web services, or directly via a link to the database, the result is the same: the web application server has access to all of your data. Although each web service can be given its own database account which can limit the data that it can see, the aggregation of all web services has to provide the same degree of data access that a more traditional application would have been granted directly in the absence of such web services.

What this means is that any breach of your web application server will result in an attacker having the same rights to your database that your application server has been given, and the chances are that your application server needs access to almost every relation in your database.

In summary: currently acceptable practice is to put web-application servers in a special untrusted segment of the network, because we don't trust them, and require that database servers treat all traffic from them as trusted. What could possibly go wrong?

Veil2 removes the need to trust your application server. As each user must individually authenticate to the database server itself, a compromised application server is less of a threat. It does not much matter if an attacker can send select * from customers to the database server if that database server is only going to let the attacker see the records for which they have appropriate credentials.

With Veil2 an attacker can only access the set of data for which they can steal credentials. If they can steal Bob's login credentials, then they can see all of the data that Bob can see. But no more than that. And they could probably steal Bob's credentials without going to the trouble of breaking in to the application server. Furthermore, if you implement the reporting of blocked accesses as suggested in the tips chapter, you will probably be alerted as soon as any intruder attempts to access the database.