2

I am looking forward to implement encryption at rest for two+ SQL database servers (Linux). My goal is (obviously) to avoid storing the clear encryption key on the server or store it in a well-known location where the server could grab it as needed. I therefore devised a solution where the encryption key is pushed to the server as needed.

I would like to identify the weaknesses of my design and understand how it can be make more robust and resilient.

Currently my plan is the following, for each server:

  • Add an encrypted volume to the server.
  • Arrange so that the server boots in a simple runlevel providing SSH access, where the encrypted volumes are not mounted.
  • Arrange so that a service monitors the database server and connects over SSH to mount the encrypted volume and cause the server to switch to another runlevel where the database service is active.

In a nutshell, I use the operating system runlevel as breakpoint in the boot procedure that gives the chance to an external service to automatically give its parameter and automatically resume the boot sequence.

Arthur le Perroquet
  • 21
  • 2
  • robust implies not losing access to your data through loss of your encryption key. it also means not publishing your encryption key by mistake. how are you managing the key. are these physical or vm hosts? what database are you using does it support transparent encryption? – simbo1905 Dec 02 '18 at 15:03
  • Could you reply to the comment? – 030 Dec 23 '19 at 10:12

0 Answers0