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
- Encryption of the database storage on the harddisk/filesystem. (To prevent outside access that would circumvent the database engine and it´s security concept)
- SSL connnections between application and database.
- Username/Password authentication of the application/users to the database.
- Role concepts behind the username/password to map permissions
- Some API enhancements beyond simple SQL secure against SQL injections
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:
- private key encryption
- public key encryption
- hashing
- quantisation
One-way
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:
- Anonymous users should only be able to spider the whole database 10 rows per second, any further queries shall be delayed by the database.
- Queries that would result in more than 100 rows should generate an alert
- This can be done using different users to connect to the database
- The user database should allow only 5 rows per second, the location database can allow 100 rows per second.
- Rate-limiting per user and Rate-limiting per Role (All anonymous users together, all Admins together)
- Updates (including deletes) should be limited to one row per operation.
Alerting
- Any user requesting a result of more than 100 rows should get his connection killed and an alert sent to the admins. (All legitimate queries have a LIMIT 100 in it, so any unlimited query is an issue)
Auditing
- Statistics about the query and update rates should be available to help specifying proper restrictions, and to identify problems.
References
http://www.amazon.com/Database-Hackers-Handbook-Defending-Servers/dp/0764578014 Database-Hackers-Handbook (Database Security)
http://www.petefinnigan.com/orasec.htm (Database Security)
http://www.wayner.org/books/td/ Translucent-Databases (Data Security)
http://code.google.com/p/sepgsql/ (Security-Labels for Postgres)
http://www.oracle.com/database/advanced-security.html (Mostly Database Security)
http://www.intersystems.com/cache/ (good Database Security)
NEWS
I was just told about http://forge.mysql.com/wiki/MySQL_Proxy 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: http://www.greensql.net/