Dónde se almacenan las claves de cifrado de KMS - Cómo funcionan el cifrado de sobre y los HSM
Se explican el mecanismo por el que las claves maestras de KMS se almacenan dentro de HSM con certificación FIPS 140-2, el diseño que protege doblemente las claves de datos con el cifrado de sobre y el funcionamiento interno de la rotación de claves.
Las claves KMS no se almacenan en texto plano
Las claves de cifrado (claves KMS, anteriormente llamadas CMK) creadas en AWS KMS (Key Management Service) nunca se almacenan en disco en texto plano. El material de clave (los datos reales de la clave de cifrado) de una clave KMS solo existe en texto plano dentro de HSM (Hardware Security Module) validados según el nivel de seguridad 3 de FIPS 140-3. Un HSM es un dispositivo de hardware dedicado al procesamiento criptográfico y cuenta con resistencia física a la manipulación (una función que detecta aperturas no autorizadas o manipulaciones y borra automáticamente las claves). Cuando una clave KMS se almacena fuera del HSM, se guarda en un estado cifrado (texto cifrado) con una clave de dominio interna del HSM. Cuando se necesita un procesamiento de cifrado / descifrado, el material de clave cifrado se carga en el HSM, se descifra dentro del HSM, se usa para el procesamiento criptográfico y, al terminar el procesamiento, se borra de la memoria del HSM. Es decir, lo que se almacena en los sistemas de almacenamiento de AWS es material de clave cifrado, y solo el HSM puede descifrarlo. Aunque un empleado de AWS acceda al almacenamiento, solo podrá ver material de clave cifrado.
Cifrado de sobre - Por qué se cifra una clave con otra clave
El núcleo del modelo de cifrado de KMS es el «cifrado de sobre» (Envelope Encryption). En lugar de cifrar los datos directamente con la clave KMS, primero se pide a KMS que genere una clave de datos (Data Key) y se cifran los datos con esa clave de datos. Después, la propia clave de datos se cifra con la clave KMS y se almacena. ¿Por qué es necesaria esta estructura doble? Hay dos razones. La primera es el rendimiento. La API de cifrado de KMS solo puede procesar hasta 4KB de datos por solicitud. Para cifrar un archivo de varios GB habría que enviar varios millones de solicitudes a KMS, lo cual no es realista. Si se usa la clave de datos de forma local, también se pueden cifrar datos grandes. La segunda es la latencia. Las llamadas a la API de KMS implican un viaje de ida y vuelta por la red. Si se almacena en caché la clave de datos en memoria, se reduce el número de llamadas a KMS. SSE-KMS (Server-Side Encryption with KMS) de S3 ejecuta este cifrado de sobre de forma automática internamente. Se genera una clave de datos única para cada objeto, los datos del objeto se cifran con la clave de datos y la clave de datos se cifra con la clave KMS y se guarda como metadatos del objeto.
Funcionamiento interno de la rotación de claves
Al activar la rotación automática de claves de KMS, se genera nuevo material de clave cada año (de 90 a 2560 días según la configuración). Lo importante aquí es que el material de clave antiguo no se elimina después de la rotación de claves. El ARN y el Key ID de la clave KMS no cambian, y los datos cifrados con el material de clave antiguo se descifran automáticamente con el material de clave antiguo. Para cifrar datos nuevos se usa el material de clave nuevo. La rotación de claves está diseñada para funcionar de forma transparente. No es necesario cambiar el código de la aplicación, y la rotación tampoco vuelve a cifrar los datos. Internamente, KMS incrusta en el texto cifrado la información de con qué versión del material de clave se cifró, y al descifrar selecciona automáticamente el material de clave adecuado. En el caso de la rotación manual de claves (el método de crear una nueva clave KMS y cambiar el alias), es necesario decidir por separado cómo tratar los datos cifrados con la clave KMS antigua. Si se elimina la clave KMS antigua después de una rotación manual sin entender la diferencia entre la rotación automática y la manual, ya no se podrán descifrar los datos antiguos.
Cuándo usar KMS y cuándo usar CloudHSM
KMS es un servicio administrado que funciona sobre HSM multi-tenant. Las claves KMS de varios clientes se procesan en el mismo clúster de HSM, pero cada clave está aislada criptográficamente y no es posible acceder a las claves de otros clientes. Por otro lado, CloudHSM es un servicio que proporciona HSM single-tenant. Se coloca un dispositivo HSM dedicado dentro de la VPC, y solo el cliente puede acceder a él. Los casos en que se necesita CloudHSM son limitados. En primer lugar, cuando los requisitos normativos exigen un «HSM dedicado». Algunas normativas de instituciones financieras y organismos gubernamentales exigen gestionar las claves de cifrado con hardware dedicado. En segundo lugar, cuando es necesario usar API criptográficas estándar como PKCS#11, JCE o CNG. KMS usa una API propia de AWS, mientras que CloudHSM admite API criptográficas estándar del sector. En tercer lugar, cuando se necesita un procesamiento criptográfico que supera el límite de tasa de solicitudes de KMS (de forma predeterminada, de 5.500 a 30.000 solicitudes por segundo, según la región). CloudHSM realiza el procesamiento con hardware dedicado. En muchos casos de uso, KMS es suficiente, y CloudHSM se considera cuando existen requisitos como los anteriores.
Eliminación de claves de cifrado - La operación más peligrosa, que no se puede deshacer
La eliminación de una clave KMS es una operación de gran impacto que no se puede deshacer una vez completada. Al eliminar una clave KMS, los datos cifrados con esa clave ya no se pueden descifrar. Los datos que dependen de esa clave, como objetos de S3, volúmenes de EBS o instantáneas de RDS, dejan de poder leerse. Para mitigar este riesgo, AWS establece un periodo de espera de 7 a 30 días para la eliminación de claves KMS. Al programar la eliminación, la clave pasa al estado «pendiente de eliminación» (Pending Deletion) y, durante el periodo de espera, no se puede usar para cifrar / descifrar. Si se cancela la eliminación durante el periodo de espera, la clave se recupera. Una vez transcurrido el periodo de espera, el material de clave se borra del HSM y no se puede restaurar. Si se usa una clave pendiente de eliminación (si se produce una solicitud de cifrado o descifrado), se registra un log en CloudTrail. Al supervisar este log, se puede comprobar si todavía existen recursos que dependen de esa clave. Para las claves KMS del entorno de producción, restringir la acción kms:ScheduleKeyDeletion con la política de claves facilita evitar las eliminaciones accidentales.
Referencias (recursos oficiales de AWS)
Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.
Si esta página y la documentación oficial difieren, prevalece la documentación oficial.