views:

86

answers:

4

Hello,
there's this interesting problem i can not solve myself. I will be very glad, if you help me.
Here's it:
there are many client applications that send data records to one MySQL server.
Few data records are not very important, but the whole database is. (You can imagine it is facebook DB :) )
Is there any way to ensure that

  • data from DB won't be used by anyone but true owner
  • DB will preserve essential features such as sorting etc.

assuming that attacker can mysteriously gain full access to server?
You can't simply encrypt data client-side and store it encrypted, since client application is wide-spread and attacker can get key from it.
Maybe adding some layers between application and DB, or combining encryption methods client- and server-side (using mysql built-in methods) will help?

A: 

I've no idea if such a thing exists in MySql, but row-level-versioning in Oracle enables you to define access rights on row-level IN the database: so that means, regardless of what tool is being used to access the data, the user only ever sees the same selection as determined by his/her credentials.

So if my username/role is only allowed to see data limited by some WHERE clause, that can appended to each and every SELECT that appears in the database, regardless of whether it comes from a web app, a SQL querying tool, or whatever.

davek
well, if attackers get full access on db (as sysdba / SA) it doesn't worth much....
Dani
A: 

I will use a 2nd layer and a firwall between them. so you have firewall ---- web server --- firewall -- 2nd layer server --- firewll --- db

it will be wise to use different platfroms between layers, it all depends how important is the data. anyway - the web server should have no access to DB.

about preserving sort - if you use a file encrypotion mechisim - it will only protect you from Hard drive theaft. if you encrypt the data it self, and if you do it smartly (storing the keys in a separate place) you will not loose sorting as you will look for the encryoted entry and not the real one- but now you have another thing to protect....

Dani
Sort and seek encrypted values: a good encryption scheme should change the key IV each time is used, which means you cannot sort nor seek encrypted values as the encrypted text changes every time, even for the same clear text. If the IV is not changed every time the key is used then you open yourself to a number of attacks, specially cribs attacks: http://en.wikipedia.org/wiki/Crib_%28cryptanalysis%29
Remus Rusanu
BTW, my comment is valid if you encrypt table entries one by one. For bulk encryption schemes (file encryption, volume encryption or transparent database encryption) all sort and seek characteristics are preserved after encryption, as the process is transparent for the DB. I think my misinterpreted your answer first time I commented.
Remus Rusanu
So this would be the primary reason for NONCE ( new IV on each transaction ) too many data centers have "hard shell and soft, chewy centre" but if each transaction has a header consisting of ( say for example ) [[email protected]] - then even with cbc or cfc that should lend a pattern in the transmission. ( No? ) Seems even with a broken root the only solution even remotely sane is KeyStore ( which I guess uses hashing + passphrase ) Even then, the Human Mind is probably the intrusion route of choice - db should use only feed-forward so there is no erasure avenue.
Nicholas Jordan
+3  A: 

As long as the database needs to start up and run unattended you can't hide the keys from a compromised root account (= 'mysterious full access'). Anywhere the database could possibly store the master key(s), the root will also have access. No amount of business layers or combination of client-server encryption will ever circumvent this simple fact. You can obfuscate it till the day after but if the prize is worth then root can get it.

One alternative is to require a manually assisted start up process, ie. a human enters the master key password during the server boot (or hardware module PIN), but this is extremely hard to maintain in real world, it requires a highly trusted employee to be on pager call to log in and start the database whenever there is downtime.

Solutions like TPM offer protection against physical loss of the server, but not against a compromised root.

Your root is as important as the database master key(s), so you must protect your root with the same care as the keys. This means setting up operating procedures, screening who has access to root, rotating the root password and so on and so forth. The moment someone gains 'mysteriously full access' the game is pretty much lost.

Remus Rusanu
Thanks, acknowledging these facts saddens me, but i guess that's how things really are. There's just no safe place in data transferring chain.
bizzz
Yes bizzz, Remus has got the mustard and potatoes on this. Just found this quote ( from Help Net Security ) quoting the Funky Business Inspector -> (intrusions on banking system on the rise due to ) "vulnerabilities presented by the lack of controls at the financial institution or third-party provider level." Encipherment, encryption, robust compartmentalization and everything else one can throw at the problem only work in a matrix including so do-gooders. Only solution is to limit risk to amounts that can be assignable to a risk-pool, a'la insurance industry known practice.
Nicholas Jordan
+2  A: 

I pretty much agree with Remus Rusanu's answer.

Maintaining good security is hard, but you can always pay attention to what you do. When ever you access sensitive information carefully verify your query and make sure it cannot be spoofed or exploited to gain access to information which shouldn't be accessible by given client.

If you can roll out physical access to the box by the attacker then there are several things you can do to harden your security. First of all I'd configure ssh access only to only allow connections from specific IP or IP range (and of course no root access). You can also do that that on your firewall. This would mean that the weakest link is your server (the application which receives data/requests from clients, could be web-server and whatever scripts you use). Now you "just" have to make sure that no one can exploit your server. There are a lot more things you could do to harden your system, but it think it would be more appropriate to ask on ServerFault.

If you're worried about physical access to the PC, there isn't really much you can do and most stuff has already been mentioned in Remus answer.

There's also another option. This is by far the most ineffective method from speed and ease to develop viewpoint, but it would partly protect you from any kind of an attack on your server (including physical). It's actually quite simple, but a bit hard to implement - only store the encrypted data in the database and handle all encryption/decryption client-side using javascript or flash. Only the client will have the key and data will always be transfered over the wire and stored in encrypted format. The biggest drawback is that once client forgets the key there's no way back, the data is inaccessible.

Of course it's all matter of time, money and effort - with enough of these anything can be broken.

Maiku Mori