Body: <p>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.</p>
  
  <p>I would like to identify the weaknesses of my design and understand how it can be make more robust and resilient.  </p>
  
  <p>Currently my plan is the following, for each server:</p>
  
  <ul>
  <li>Add an encrypted volume to the server.</li>
  <li>Arrange so that the server boots in a simple runlevel providing SSH access, where the encrypted volumes are not mounted.</li>
  <li>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.</li>
  </ul>
  
  <p>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.</p>
  
Comments: CC BY-SA 4.0
Comments: 2018-12-02T15:03:38.133Z
Comments: 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?
Comments: simbo1905
Comments: CC BY-SA 4.0
Comments: 2019-12-23T10:12:20.997Z
Comments: Could you reply to the comment?
Comments: 030
Tags: <databases><encryption><architecture>
Title: Is this a robust implementation of database encryption at rest?
UserDisplayName: Arthur le Perroquet
ThreadText: # Is this a robust implementation of database encryption at rest?
  
  (Asked by: username_0 on 2018-04-19)
  
  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.
  
  **Tags:** databases, encryption, architecture
  
  > **Comments:**
  > **username_1**: 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?  
  > **username_2**: Could you reply to the comment?  
  
  ---
  
  ## 0 answers
  
  