Almacenamiento seguro de una clave de cifrado en AWS

Depende de lo que quiere decir con "almacenamiento", así como "servidor".

Voy a asumir, por el bien de la respuesta, que ahora hay dos "servidores" en uso, ambos en la nube de AWS:

servidor MySQL.

Servidor de aplicaciones (que actualmente tiene el código con su clave de criptografía).

El servidor MySQL no tiene ninguna razón para tener la clave, nunca.

El servidor de aplicaciones que asumo tiene que trabajar con los datos descifrados.

• Si el servidor de aplicaciones está haciendo el descifrado, TENDRÁ la clave en la memoria.
  • NO PUEDE saber si AWS guardó esa memoria en el disco, a menos que inspeccione el hardware.
• Si el servidor de aplicaciones no necesita realizar el descifrado en sí mismo, entonces es posible tener un servicio que tome los datos de MySQL y los descifre, enviándolos de vuelta al servidor de la aplicación mediante un cifrado de clave pública / privada. está satisfecho con.

Como siempre, si la clave está en AWS, cualquier empleado de AWS con suficiente acceso elige, así como cualquier otra persona con acceso suficiente (proveedores, Dell después de que el contenedor lleno de hardware se devuelva una vez que haya sufrido demasiadas fallas, etc. etc. etc.).

Un enfoque es almacenar tales claves confidenciales, contraseñas u otras credenciales en un grupo de S3 particular. Ese cubo no debe ser accesible / disponible públicamente. A continuación, creará un rol IAM que tiene acceso de solo lectura S3 a ese grupo. Por último, cuando inicie su instancia de EC2, asignará esa función de IAM a esa instancia.

Con este tipo de enfoque, su instancia de EC2 no necesita su clave de acceso / secreto de AWS para hablar con S3; Se permite automáticamente por el rol de IAM. Y luego los códigos / scripts en su instancia de EC2 pueden descargar la clave de cifrado (u otras credenciales) desde el depósito de S3, iniciar el proceso y luego eliminar esas credenciales del disco (asumiendo que las almacenó en el disco en su instancia); esto debería esperamos garantizar que esas credenciales ahora solo estén en la memoria en esa instancia de EC2.

Tenga en cuenta que si intenta este enfoque, es posible que deba configurar los permisos en el depósito S3 (y su archivo) para "permitir al usuario AWS autenticado", ya que su instancia de EC2 no tendrá su clave de acceso / secreto de AWS, y por lo tanto, no se identificará como su cuenta en S3.

Espero que esto ayude!

Depende de qué tan seguro necesita estar. Para PCI, por ejemplo, necesita tener dos claves.

La primera es la clave de cifrado de datos (DEK). El segundo es la clave de cifrado clave (KEK). Utiliza el DEK para cifrar los datos. Utiliza la tecla KEK para cifrar el DEK. No es obligatorio, pero se recomienda encarecidamente que almacene KEK en el almacén de claves proporcionado por su sistema operativo. Entonces solo el usuario registrado que lo creó puede acceder a él. Creamos un usuario oculto en el que la aplicación ha iniciado sesión para recuperar el KEK.

El punto es hacer que sea más difícil al necesitar tener éxito en varios vectores de ataque. Uno para acceder a las credenciales de inicio de sesión, otro para obtener acceso al almacén de claves, otro para acceder al DEK donde sea que esté almacenado y luego para acceder a los datos reales. Esto se opone a tener las claves en la base de datos. En ese caso, una vez que la base de datos está en peligro, todo está.

Puedes dividir tu KEK y tener la mitad del código para agregar otro nivel de dificultad. Personalmente, no me gusta tenerlo disponible en texto plano, así que ofusco esa mitad para que tengan que mirar el texto y el código, otro nivel de dificultad.

Probablemente para sus propósitos, puede salirse con solo una clave almacenada en el almacén de claves para el usuario con el que se ejecuta su aplicación.