Applications are a different story

Managing change is hard enough, making it a succes is even harder. As GDPR is law as of May 2018, success is mandatory.

Although there is an incentive to centralise data (although less than necessary), there is no way to identify all applications which use your data.

Of course, there is the web-app for editing and browsing your data, including riskful data. But there are reports too. There are e-mails which are interpreted by scripts, there are e-mails with attachments which are copied into spreadsheet-documents. There is a completely independent web-application developed by IT for speeding up asset-entry. And of course, there is more, a lot more.

Quite a lot with regards to GDPR can be covered with database policies and people being risk-aware. The hard part is to do this without interrupting functionality of all other applications, especially the ones you don't know about.

Most of the solutions on this site can do without big application changes.

That is, if the application pushes identities right through to the end. This is a ISO 27001 requirement, so most applications do this already. Eh, well, they don't. Some applications do authentication themselves (please don't, it is too hard a job to do right), they also do authorisation themselves (argh, a GUI to do user-administration, don't, don't). These applications have some kind of application super-user to connect to the database server. All control then fails as no disaster in the database can be lead back to a particular end-user. No access control, no authorisation is possible, no differentiation too.

If your applications needs a database user/password combination in order to connect to the RDBMS for all transactions, the application is not fit for ISO27001 and not for GDPR.

The right question to ask now is: are RDBMS' capable of doing this? And I must say: no, they cannot. The most heard of argument against per-user database accounts is that it introduces one database connection per user. Connections are known to be wasting resources. Most large scale applications use connection pooling to avoid this. But the argument doesn't hold. Connection pooling can still be used as connections can be shared among users, as long as a set role command is part of every single transaction. So, please make an application-user account match 1-on-1 with the RDBMS-account.

I've seen terrible stuff, where an application would filter out rows which are not accessible by the user by JavaScript on the front-end. I've seen PHP-code for doing just that on the server-side, files which were writeble by world! All can be covered with Row-Level Security (RLS) where conditions must be met for being able to retrieve rows. RLS is capable of implementing full ABAC; terribly new for some, but available for some time now: you better start using it.

Even multi-tenant solutions should be done with RLS; put a tenant-id in the rows necessary and have RLS deal with returning just the rows for this particular user's tenancy. This will even support users with two or more tenancies!

The first four or five titles were written in some kind of rage after visiting the Big Data Expo, Utrecht 2017. I then knew about GDPR and had implemented various mechanisms to avoid running risks. The commercial heavy lifting on that expo was terrible. People should be informed about GDPR without FUD.