I use Transparent Data Encryption (TDE) for postgresql. I want to store cipher key for my database in Vault. I have a program that execute automatically and get key from key storage when I carry out request to DB. This program print key in stdout and TDE module take it and get data from DB. If hacker get access to my postgresql server, he can run my program and get key. How can I do to Vault give key when it happen automatically and doesn’t give key when hacker run program?
You can’t.
If the postgresql server has a secret that allows it to authenticate to Vault, and the hacker has gained access to that secret, Vault has no way to tell the difference between postgresql and the hacker.
Thank you. Is there another way to store the secret so that a hacker doesn’t get access to the key?
Run the program from another server, so that a hacker who’s only been able to access the database server can’t read the data?
Anyway I or my program get cipher key into stdout. Hacker who’s only been able to access the database server can run this program and see key in console. Then he will download database and decrypt it. What should I do so that preserve my data?
Based what you have told us so far, the database software needs the key.
By definition, then, if the hacker has penetrated to the point they can successfully impersonate the database software, the hacker can also get the key.
There’s nothing you can do about that, it’s pure logic.
Is using Transparent Data Encryption insecure?
No, but no security system can protect against everything.
There is a big difference between protecting against someone stealing a hard drive and someone compromising a running system, for example.
The best anyone can do is mitigate the most likely & most disruptive/costly/legally problematic issue, and ensure there is sufficient monitoring & support to detect things that shouldn’t be happening.
Another way to put it, is this:
By choosing Transparent Data Encryption, you have chosen to give possession of the key to the database software… and any hackers who can successfully impersonate the database software or read where it temporarily stores the key.
That was the trade-off that was accepted to make the encryption transparent to the clients of the database.