“How can I protect the data stored in my database without having to disconnect it completely from the world?”
If this sounds familiar, then you probably own or are responsible for a piece of sensitive information. You cherish it and understand that it’s to your advantage to keep it safe. At the same time, you would like to share the information with people you trust –even from outside the organization– so that they may put it to good and profitable use.
That the information happens to be stored in a relational database is something you find very convenient: it is easy to connect to the database and query the information using SQL; anyone that has access can analyze it, write reports on it and even build applications with it.
But this is far from easy. Laws and regulations of various sorts put limits on how to share information. Business requirements change rapidly, so whoever was allowed to access the data yesterday may not be allowed to access it today. Concurrent regulations and/or business needs get combined into increasingly complex and dynamic policies. Also the granularity of access has changed, from the database to the table to the row and finally to the cell level. To complicate matters even further, there is on-going explosion of data volumes. Changing the way we develop applications from now on can help, but we still need to take care of legacy applications, where retrofitting access policies may turn out to be close to impossible.
The need to share information in such a generous but still restricted way was not present in the design board when most current relational database products first came to the market. So it is not particularly surprising that the methods developed by database vendors to support access control was added gradually, as an after-thought. It became possible to use SQL to grant permissions to users (since SQL-86), groups or roles (since SQL:1999) to perform operations on whole schemas, or just single tables. But the kind of access controls were too coarse, so some vendors extended permissions to operate on single columns. Others made it possible to attach labels to columns, row and even single cells in tables, and use those labels to control who may transform their contents and how. But who has the time and resources to label everything? Also, how can so many labels be quickly updated every time the law changes, or as soon as management dictates a new policy?
The Axiomatics Data Access Filter (ADAF) addresses the problems described above. It combines the use of attribute-based access control policies, written in XACML, with an enhanced data layer brokering the communication between applications and the database. The latter takes the form of a SQL proxy that intercepts SQL queries before they reach the database and rewrites them in accordance with the XACML policy.
ADAF uses XACML to enforce elaborate and detailed access control policies, that are external to both the applications and the database. As a consequence, policies can be easily changed, as requirements evolve, without affecting applications or the database. The changes take immediate effect, without interrupting the natural flow of business.
The key to the application of an ABAC language, like XACML, lies mostly in our ability to identify the resources in the model and, in particular, the attributes that describe those resources. For ADAF, resources are none other than isolated rows in database tables; their attributes represented by the contents of each cell in the row (and of other rows linked to it). When a SQL query is evaluated, the DBMS tries to access a large number of rows. For each accessed row, i.e. each resource, imagine it consulting the ABAC policy to determine if the row in question should or not should be returned to the requestor. Obviously such a row-by-row approach is unworkable. It is for this reason that ADAF applies the access control policy by transforming the original SQL query. As a result of this transformation, the SQL query that hits the database does not ask for rows that the user is not allowed to access.
If you managed to read this far, you are probably wondering why all this talk about table rows as resources: Does it mean we cannot control access to individual cells in a table? Actually we can. In the ABAC model, as embraced by XACML, there are not just subjects and resources. An ABAC policy may also depend on the action performed by the subject upon the resource, as well as the context in which the action takes place. In the case of a SQL query, it’s easy to imagine that a SELECT query represents a different kind of action than an INSERT statement. Furthermore, even queries of the SELECT type may represent different actions on a resource (a table row). For example, a SELECT statement may or may not examine a certain cell in a row. ADAF is able to determine, from the SQL query, which action is to be performed on each row cell and, thus, it becomes perfectly possible to write XACML policies that control whether the user can access a cell or not.
ADAF was first released in late 2013 with support for Oracle databases; the SQL query interception and rewriting capabilities relying heavily on Oracle’s Virtual Private Database. One year later we are launching ADAF MD, which no longer has a dependency on Oracle VPD, and instead uses a third-party SQL proxying technology, which gives us the ability to support multiple databases. Initially, along with the existing support for Oracle, we also support Microsoft SQL Server. We plan to add other databases in 2015.