Database Security - Data Security

The problem is that most database vendors seem to just care about the security of the database, not about the security of the data, and leave data-security to the application, which is a good start for the database vendors, but not good enough for high-risk applications like CAcert.

State of the art

Needed security

Q: Are you thinking about per-row encryption? A: pre-row encryption is the beginner level for securing the data. There are more advanced techniques, but there you need really good database support, to be able to manage them, to be useful in practice.

I am currently thinking about writing a database proxy to implement those techniques into an existing database, or to otherwise implement it into a database-core.

There are 4 data-security base-techniques:


Encryption is usually reversable, where hashing and quantisation are irreversable (one-way). Now the problem is that in practice you have different applications all working on the same data. So when you one-way encrypt something, and you come up with another application demand later on, you can´t use the encrypted data anymore. So what is necessary there is that you use generate an offline public-keypair, and always encrypt an additional backup of each row that is inserted that public key, so that you can decrypt the data when needed for a new application.

The next thing that is necessary is that those techniques have to be transparently available as views for different users/roles. An administrator might have to be able to see more fine-granular data, than a normal user needs to see. For example the birthday, some roles might only need the year (>18 years old?), some roles might only to check for a certain day+month (birthday today?), so day+month could be hashed.

Different users need different quantisation levels of the same data. So the database should be able to have different views on the same table, with different quantisation levels on the individual columns, and be able to restrict users/roles to certain views. So that admins can see more fine-grained data than anonymous web-users ...

I think that those functions should be manageable in the databasesystem, not just done by the application, and ignored in the database.

Q: yes, the problem is that data has not to be used only by the user that owns it, but also from other privileged users, from the system, etc A: Yes, that´s why you need differently encrypted/hashed/quantisised views on the same data for different users

Rate limiting

Another important aspect is rate-limiting as an sql injection protection mechanism, and anti-spidering mechanism:





I was just told about which could be used to implement the necessary things. Can someone please investigate, and document which things can be solved with it?

Another proxy was just discovered: