Contents
Although a well-implemented Veil2-based VPD
will give you a more secure system than one without
Veil2, there are some fundamental limits to how
secure your database can ever be.
There are many security threats that Veil2
can do nothing for. Veil2 can only limit
access to data for users that are, or appear to be legitimate.
Here are some things Veil2 can't protect
against:
- an attacker with credentials for the owner of the database objects;
- an attacker with credentials for the postgres account;
- an attacker with credentials for root;
- an attacker who can become root through a local privilege escalation attack;
- an attacker with access to the database filesystem;
- an attacker with access to database backups;
- an attacker with access to a replica/failover/reporting database.
Veil2 is designed primarily to protect
sensitive data from legitimate users. It is not intended to
keep attackers out of your systems. It cannot hope to keep your
data secure against attacks from state actors, or highly skilled
black-hat hackers.
It protects sensitive data from overly inquisitive users; against opportunist attacks from script kiddies; and can greatly limit the damage that can arise from a compromised application server.
Yep.
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.