|
|
Me complace anunciar la disponibilidad de AWS Key Management Service (AWS KMS) Almacén de claves externo. Los clientes que tienen una necesidad reglamentaria de almacenar y utilizar sus claves de cifrado en las instalaciones o fuera de la nube de AWS ahora pueden hacerlo. Esta nueva capacidad le permite almacenar claves administradas por el cliente de AWS KMS en un módulo de seguridad de hardware (HSM) que opera en las instalaciones o en cualquier lugar de su elección.
En un nivel alto, AWS KMS reenvía llamadas a la API para comunicarse de forma segura con su HSM. Su material clave nunca sale de su HSM. Esta solución le permite cifrar datos con claves externas para la gran mayoría de los servicios de AWS que admiten claves administradas por el cliente de AWS KMS, como Amazon EBS, AWS Lambda, Amazon S3, Amazon DynamoDB y más de 100 servicios. No es necesario realizar ningún cambio en los parámetros o el código de configuración de los servicios de AWS existentes.
Esto lo ayuda a desbloquear casos de uso para una pequeña parte de las cargas de trabajo reguladas donde las claves de cifrado deben almacenarse y usarse fuera de un centro de datos de AWS. Pero este es un cambio importante en la forma en que opera la infraestructura basada en la nube y un cambio significativo en el modelo de responsabilidad compartida. Esperamos que solo un pequeño porcentaje de nuestros clientes habilite esta capacidad. La carga operativa adicional y los mayores riesgos para la disponibilidad, el rendimiento y las operaciones de baja latencia en los datos protegidos superarán, en la mayoría de los casos, los beneficios de seguridad percibidos de AWS KMS External Key Store.
Déjame sumergirme en los detalles.
Un breve resumen sobre la gestión y el cifrado de claves
Cuando un servicio de AWS está configurado para cifrar datos en reposo, el servicio solicita una clave de cifrado única de AWS KMS. A esto lo llamamos la clave de cifrado de datos. Para proteger las claves de cifrado de datos, el servicio también solicita que AWS KMS cifre esa clave con una clave específica administrada por el cliente de KMS, también conocida como clave raíz. Una vez cifradas, las claves de datos se pueden almacenar de forma segura junto con los datos que protegen. Este patrón se denomina cifrado de sobre. Imagine un sobre que contiene tanto los datos cifrados como la clave cifrada que se utilizó para cifrar estos datos.
Pero, ¿cómo protegemos la clave raíz? La protección de la clave raíz es esencial, ya que permite el descifrado de todas las claves de datos cifradas.
El material de la clave raíz se genera y almacena de forma segura en un módulo de seguridad de hardware, una pieza de hardware diseñada para almacenar secretos. Está resistente a la manipulación y diseñado para que el material clave nunca deje el hardware seguro en texto sin formato. AWS KMS utiliza HSM que están certificados bajo la Programa de certificación del módulo criptográfico NIST 140-2.
Puede optar por crear claves raíz vinculadas a la clasificación de datos, o crear claves raíz únicas para proteger diferentes servicios de AWS, o por etiqueta de proyecto, o asociadas a cada propietario de datos, y cada clave raíz es única para cada región de AWS.
AWS KMS llama a las claves raíz claves administradas por el cliente cuando crea y administra las claves usted mismo. Se denominan claves administradas por AWS cuando se crean en nombre de un servicio de AWS que cifra datos, como Amazon Elastic Block Store (Amazon EBS), Amazon Simple Storage Service (Amazon S3), Amazon Relational Database Service (RDS) o Amazon DynamoDB. Para simplificar, llamémoslas claves KMS. Estas son las claves raíz, las que nunca abandonan el entorno seguro de HSM. Todas las operaciones de cifrado y descifrado de KMS se realizan en el entorno seguro del HSM.
La solución de proxy XKS
Al configurar AWS KMS External Key Store (XKS), está reemplazando la jerarquía de claves de KMS con una nueva raíz de confianza externa. Todas las claves raíz ahora se generan y almacenan dentro de un HSM que usted proporciona y opera. Cuando AWS KMS necesita cifrar o descifrar una clave de datos, reenvía la solicitud al HSM específico de su proveedor.
Todas las interacciones de AWS KMS con el HSM externo están mediadas por un proxy de almacén de claves externo (proxy XKS), un proxy que usted proporciona y administra. El proxy traduce las solicitudes genéricas de AWS KMS a un formato que los HSM específicos del proveedor pueden entender.
Los HSM con los que XKS se comunica no están ubicados en los centros de datos de AWS.
Para proporcionar a los clientes una amplia gama de opciones de administración de claves externas, AWS KMS desarrolló la especificación XKS con los comentarios de varios proveedores de servicios de integración, administración de claves y HSM, incluidos Atos, Confiar, Fortanix, HashiCorp, Fuerza de ventas, Talesy Sistemas T. Para obtener información sobre disponibilidad, precios y cómo usar XKS con soluciones de estos proveedores, consulte directamente al proveedor.
Además, proporcionaremos una implementación de referencia de un proxy XKS que se puede usar con SoftHSM o cualquier HSM que admita un PKCS #11 interfaz. Este proxy XKS de implementación de referencia se puede ejecutar como un contenedor, está integrado en Rust y estará disponible a través de GitHub en las próximas semanas.
Una vez que haya completado la configuración de su proxy XKS y HSM, puede crear un recurso de almacén de claves externo correspondiente en KMS. Usted crea claves en su HSM y asigna estas claves al recurso de almacén de claves externo en KMS. Luego, puede usar estas claves con los servicios de AWS que admiten claves de clientes o sus propias aplicaciones para cifrar sus datos.
Cada solicitud de AWS KMS al proxy XKS incluye metadatos, como el principal de AWS que llamó a la API de KMS y el ARN de la clave de KMS. Esto le permite crear una capa adicional de controles de autorización en el nivel de proxy XKS, más allá de los que ya proporcionan las políticas de IAM en sus cuentas de AWS.
El proxy XKS es efectivamente un interruptor de apagado que usted controla. Cuando desactive el proxy XKS, todas las nuevas operaciones de cifrado y descifrado que utilicen claves XKS dejarán de funcionar. Los servicios de AWS que ya han aprovisionado una clave de datos en la memoria para uno de sus recursos seguirán funcionando hasta que desactive el recurso o caduque la memoria caché de la clave de servicio. Por ejemplo, Amazon S3 almacena en caché las claves de datos durante unos minutos cuando las claves del depósito están habilitadas.
El cambio en la responsabilidad compartida
Según los procedimientos operativos estándar de la nube, AWS es responsable de mantener la infraestructura de la nube en condiciones operativas. Esto incluye, pero no se limita a, parchear los sistemas, monitorear la red, diseñar sistemas para alta disponibilidad y más.
Cuando elige usar XKS, hay un cambio fundamental en el modelo de responsabilidad compartida. Según este modelo, usted es responsable de mantener el proxy XKS y su HSM en condiciones operativas. No solo tienen que estar protegidos y tener una alta disponibilidad, sino también tener el tamaño necesario para soportar la cantidad esperada de solicitudes de AWS KMS. Esto se aplica a todos los componentes involucrados: las instalaciones físicas, las fuentes de alimentación, el sistema de refrigeración, la red, el servidor, el sistema operativo y más.
Según su carga de trabajo, las operaciones de AWS KMS pueden ser críticas para operar servicios que requieren cifrado para sus datos en reposo en la nube. Los servicios típicos que dependen de AWS KMS para el funcionamiento normal incluyen Amazon Elastic Block Store (Amazon EBS), Lambda, Amazon S3, Amazon RDS, DynamoDB, y más. En otras palabras, significa que cuando la parte de la infraestructura bajo su responsabilidad no está disponible o tiene latencias altas (típicamente más de 250 ms), AWS KMS no podrá operar, en cascada la falla a las solicitudes que realiza a otros AWS. servicios. No podrá iniciar una instancia EC2, invocar una función Lambda, almacenar o recuperar objetos de S3, conectarse a sus bases de datos RDS o DynamoDB, ni a ningún otro servicio que dependa de las claves XKS de AWS KMS almacenadas en la infraestructura que administra.
Como me dijo uno de los gerentes de producto involucrados en XKS mientras preparaba esta publicación de blog, “usted está ejecutando su propio túnel hacia el oxígeno a través de un camino muy frágil”.
Recomendamos usar esta capacidad solo si tiene una necesidad reglamentaria o de cumplimiento que requiera que mantenga sus claves de cifrado fuera de un centro de datos de AWS. Solo habilite XKS para las claves raíz que admitan sus cargas de trabajo más críticas. No todas sus categorías de clasificación de datos requerirán almacenamiento externo de claves raíz. Mantenga el conjunto de datos protegido por XKS al mínimo para cumplir con sus requisitos reglamentarios y continúe usando las claves administradas por el cliente de AWS KMS, totalmente bajo su control, para el resto.
Algunos clientes para los que el almacenamiento de claves externo no es un requisito de cumplimiento también solicitaron esta función en el pasado, pero terminaron aceptando una de las opciones existentes de AWS KMS para el almacenamiento y uso de claves basadas en la nube una vez que se dieron cuenta de que la seguridad percibida Los beneficios de una solución similar a XKS no superaron el costo operativo.
¿Qué cambia y qué permanece igual?
Traté de resumir los cambios para usted.
| Que es idéntico a las claves estándar de AWS KMS |
Que es cambiando |
|
Las API de AWS KMS y los identificadores de clave (ARN) admitidos son idénticos. Los servicios de AWS que admiten claves administradas por el cliente funcionarán con XKS. La forma de proteger el acceso y monitorear el acceso desde el lado de AWS no ha cambiado. XKS utiliza las mismas políticas de IAM y las mismas políticas clave. Las llamadas a la API se registran en AWS CloudTrail y AWS CloudWatch tiene las métricas de uso. El precio es el mismo que el de otras operaciones de API y claves de AWS KMS. |
XKS no admite claves asimétricas o HMAC administradas en el HSM que proporcione. Ahora es dueño de las preocupaciones sobre la disponibilidad, la durabilidad, el rendimiento y los límites de latencia de sus operaciones de clave de cifrado. Puede implementar otra capa de autorización, auditoría y supervisión a nivel de proxy XKS. XKS reside en su red. Si bien el precio de KMS permanece igual, es probable que sus gastos aumenten sustancialmente para adquirir un HSM y mantener su parte de la infraestructura relacionada con XKS en condiciones operativas. |
Una especificación abierta
Para esas cargas de trabajo estrictamente reguladas, estamos desarrollando XKS como una especificación de interoperabilidad abierta. No solo hemos colaborado con los principales proveedores que ya mencioné, sino que también abrimos un repositorio de GitHub con los siguientes materiales:
- La especificación de la API del proxy XKS. Esto describe el formato de las solicitudes genéricas que KMS envía a un proxy XKS y las respuestas que espera. Cualquier proveedor de HSM puede usar la especificación para crear un proxy XKS para su HSM.
- Una implementación de referencia de un proxy XKS que implementa la especificación. Los proveedores de HSM pueden adaptar este código para crear un proxy para su HSM.
- Un cliente de prueba de proxy XKS que se puede usar para verificar si un proxy XKS cumple con los requisitos de la especificación API de proxy XKS.
Otros proveedores, como SalesForce, anunció su propia solución XKS permitiendo a sus clientes elegir su propia solución de gestión de claves y conectarla a la solución de su elección, incluido SalesForce.
Precios y disponibilidad
El almacén de claves externo se proporciona sin costo adicional además de AWS KMS. AWS KMS cobra $ 1 por clave raíz por mes, sin importar dónde se almacene el material clave, en KMS, en CloudHSM o en su propio HSM local.
Para obtener una lista completa de las regiones donde AWS KMS XKS está disponible actualmente, visite nuestra documentación técnica.
Si cree que XKS le ayudará a cumplir con los requisitos reglamentarios, consulte la documentación técnica y las preguntas frecuentes de XKS.
