Preguntas frecuentes de AWS Key Management Service

La disponibilidad se indica en la página global de Productos y servicios por región.

Puede ejecutar las siguientes funciones de administración de claves:

• Crear claves simétricas, asimétricas y HMAC en las que el material de claves solo se utiliza dentro del servicio
• Crear claves simétricas en las que el material de claves se genera y se usa en un almacén de claves personalizado controlado por usted y respaldado por AWS CloudHSM o su propio administrador de claves externo fuera de AWS.
• Importar su propio material clave simétrico, asimétrico y HMAC para usarlo en los servicios de AWS compatibles y en su propia aplicación
• Definir qué usuarios y roles de AWS Identity and Access Management (IAM) pueden administrar claves
• Definir qué usuarios y roles de IAM pueden usar claves para cifrar y descifrar datos
• Elegir que las claves generadas por el servicio se roten automáticamente cada año
• Deshabilitar temporalmente las claves para que nadie pueda utilizarlas
• Rehabilitar las claves deshabilitadas
• Programar la eliminación de claves que ya no están en uso
• Auditar el uso de las claves mediante el análisis de los registros en AWS CloudTrail

Para poder comenzar a utilizar el servicio, debe solicitar la creación de una clave de AWS KMS. El usuario controla el ciclo de vida de las claves de KMS administradas por el cliente y quién puede utilizarlas o administrarlas. Una vez que haya creado una clave de KMS, puede enviar datos directamente al servicio AWS KMS para que se cifren, descifren, firmen o verifiquen, o para generar o verificar un HMAC mediante esta clave KMS. El usuario establece políticas de utilización en estas claves que determinan qué acciones puede realizar cada usuario y en qué condiciones.

AWS KMS se integra con servicios de AWS y conjuntos de herramientas del lado del cliente que utilizan un método conocido como cifrado de sobre para proteger sus datos. Con este método, AWS KMS genera claves de datos que se utilizan para cifrar datos localmente en el servicio de AWS o en la aplicación. Las claves de datos están cifradas en una clave de AWS KMS que define el usuario. AWS KMS no retiene ni administra claves de datos. Los servicios de AWS cifran los datos y los almacenan en una copia cifrada de la clave principal junto con los datos cifrados. Cuando un servicio necesita descifrar los datos, solicita a AWS KMS que descifre la clave de datos mediante la clave de KMS. Si el usuario que solicita datos al servicio de AWS está autorizado para descifrarlos con la clave de KMS, el servicio de AWS recibirá la clave de datos descifrados de AWS KMS. A continuación, el servicio de AWS descifra los datos y los devuelve como texto no cifrado. Todas las solicitudes para utilizar las claves de KMS se registran en CloudTrail, para que pueda saber quién utilizó una clave determinada, en qué contexto y cuándo.

Normalmente existen tres situaciones de cifrado de los datos con AWS KMS. En primer lugar, puede utilizar las API de AWS KMS directamente para cifrar y descifrar datos mediante las claves de KMS almacenadas en el servicio. En segundo lugar, puede elegir que los servicios de AWS cifren los datos con las claves de KMS almacenadas en el servicio. En este caso, los datos se cifran con claves de datos que están protegidas por las claves de KMS. En tercer lugar, puede utilizar el SDK de cifrado de AWS que está integrado con AWS KMS para realizar el cifrado dentro de las propias aplicaciones, independientemente de si funcionan en AWS o no.

AWS KMS se integra perfectamente con la mayoría de los otros servicios de AWS para que producir datos cifrados en aquellos servicios sea más sencillo. En algunos casos, los datos se cifran de forma predeterminada mediante las claves almacenadas en AWS KMS, pero que pertenecen al servicio de AWS en cuestión y están administradas por él. En muchos casos es el usuario quien posee y administra las claves de AWS KMS dentro de su cuenta. Algunos servicios brindan la opción de que uno mismo administre las claves o que el servicio lo haga en su nombre. Consulte la lista de servicios de AWS que actualmente están integrados con AWS KMS. Consulte la guía para desarrolladores de AWS KMS para obtener más información sobre cómo los servicios integrados utilizan AWS KMS.

Si bien AWS KMS admite el envío de datos con un volumen inferior a 4 KB para cifrarlos directamente, el cifrado de sobre puede ofrecer beneficios de rendimiento importantes. Si los datos se cifran directamente con AWS KMS, estos deben transferirse a través de la red. El cifrado de sobre reduce la carga de la red, ya que solo la solicitud y entrega de la clave de datos mucho menor se transfiere a través de la red. La clave de datos se utiliza localmente en la aplicación o servicio de cifrado de AWS, lo cual evita la necesidad de enviar todo el bloque de datos a AWS KMS y tener latencia de red.

Tiene la opción de seleccionar una clave de KMS específica para utilizarla cuando desee que un servicio de AWS cifre los datos por usted. Estas claves se conocen como claves de KMS administradas por el cliente y el usuario tiene completo control sobre ellas. Puede definir el control de acceso y la política de utilización para cada clave y otorgar permisos a otras cuentas y servicios para utilizarlas. Además de las claves administradas por el cliente, AWS KMS también proporciona dos tipos de claves administradas por AWS: (1) las claves de KMS administradas por AWS son claves creadas en su cuenta pero administradas por AWS, y (2) las claves que pertenecen a AWS son claves de propiedad exclusiva que se administran desde cuentas de AWS. Puede realizar un seguimiento de las claves administradas de AWS en la cuenta y la totalidad de la utilización se registra en CloudTrail. Sin embargo, usted no tiene control directo sobre las claves. Las claves que pertenecen a AWS son las más automatizadas y proporcionan el cifrado de los datos en AWS. Sin embargo, no proporcionan controles de política o registros de CloudTrail sobre la actividad de las claves.

La creación de la propia clave de KMS permite ejercer un mayor control que con las claves de KMS administradas por AWS. Cuando crea una clave de KMS simétrica administrada por el cliente, puede utilizar el material de claves generado por AWS KMS, generado dentro de un clúster de AWS CloudHSM o un administrador de claves externo (a través del almacén de claves personalizado), o importar su propio material de claves. Puede definir un alias y una descripción para la clave y elegir la opción para que la clave rote automáticamente una vez al año, si esta se generó mediante AWS KMS. También puede definir permisos sobre la clave para controlar quién puede utilizarla o administrarla. En el caso de las claves de KMS asimétricas administradas por el cliente, existen un par de advertencias para la administración: el material de claves solo se puede generar en el HSM de AWS KMS y no existe una opción para la rotación automática de claves.

Sí. Puede elegir que AWS KMS rote automáticamente las claves de KMS cada año, siempre que dichas claves se hayan generado en los HSM de AWS KMS. La rotación automática de claves no es compatible con claves importadas o claves asimétricas generadas en un clúster de CloudHSM a través de la característica de almacenamiento de claves personalizado de AWS KMS. Si decide importar claves a AWS KMS o claves asimétricas o utilizar un almacén de claves personalizado, puede rotarlas manualmente mediante la creación de una nueva clave de KMS y la asignación de un alias de clave existente de la antigua clave de KMS a la nueva clave de KMS.

Si elige que AWS KMS rote automáticamente las claves, no tendrá que volver a cifrar sus datos. AWS KMS conserva las versiones anteriores de las claves a fin de utilizarlas para descifrar los datos cifrados con una versión anterior de una clave. Todas las solicitudes de cifrado nuevas relacionadas con una clave en AWS KMS se cifran con la versión más reciente de la clave. Si rota manualmente las claves del almacén de claves importadas o personalizadas, es posible que tenga que volver a cifrar los datos, dependiendo de si usted decide mantener versiones antiguas de claves disponibles.

Si rota manualmente las claves del almacén de claves importadas o personalizadas, puede que tenga que volver a cifrar sus datos, dependiendo de si usted decide mantener versiones antiguas de claves disponibles.

Sí. Puede programar la eliminación de una clave de AWS KMS y de los metadatos asociados que creó en AWS KMS, con un periodo de espera configurable de 7 a 30 días. Este periodo de espera ayuda a verificar el impacto que tendría eliminar una clave en las aplicaciones y los usuarios que la utilizan. El periodo de espera predeterminado es de 30 días. Durante el periodo de espera puede cancelar la eliminación. Cuando se programa la eliminación de una clave, esta no se puede utilizar hasta que no se cancele la eliminación durante el periodo de espera. Si no cancela la eliminación, la clave se elimina al final del periodo de espera configurable. Cuando una clave se elimina, ya no es posible utilizarla. No se puede obtener acceso a los datos protegidos con una clave maestra eliminada.

En el caso de las claves de AWS KMS con material de claves importado, puede eliminar de dos maneras el material de claves sin eliminar el ID de clave de AWS KMS ni los metadatos. En primer lugar, puede eliminar el material de claves importado bajo demanda sin periodo de espera. En segundo lugar, cuando importe el material de claves a la clave de AWS KMS, puede definir una fecha de vencimiento que fije cuánto tiempo AWS puede utilizar el material de claves importado antes de que se elimine. Si necesita utilizarlo de nuevo, puede volver a importar el material de claves a la clave de AWS KMS.

Sí. AWS KMS es compatible con los SDK de AWS, el SDK de cifrado de AWS, el cifrado del cliente de Amazon DynamoDB y con el cliente de cifrado de Amazon Simple Storage Service (S3) para facilitar el cifrado de los datos dentro de sus propias aplicaciones dondequiera que se ejecuten. Visite los sitios web AWS Crypto Tools y Desarrollo en AWS para obtener más información.

Puede crear hasta 100 000 claves de KMS por cuenta y región. Como las claves de KMS habilitadas y deshabilitadas cuentan para el límite, recomendamos eliminar las claves deshabilitadas que ya no utiliza. Las claves de KMS administradas por AWS creadas para que pueda utilizarlas en los servicios de AWS compatibles no se tienen en cuenta para este límite. No existe ningún límite en cuanto al número de claves de datos que se pueden derivar mediante el uso de una clave de KMS y que se pueden utilizar en la aplicación o que pueden utilizar los servicios de AWS para cifrar los datos por usted. Puede solicitar que se incremente el límite de claves de KMS en el AWS Support Center.

No. Las claves de KMS o la parte privada de una clave de KMS asimétrica no se pueden exportar en texto no cifrado desde los HSM. Solo la parte pública de una clave de KMS asimétrica se puede exportar desde la consola o mediante una llamada a la API GetPublicKey.

Sí. Las claves de datos simétricas se pueden exportar utilizando la API GenerateDataKey o la API GenerateDataKeyWithoutPlaintext. Además, la parte privada y pública de los pares de claves de datos asimétricos se pueden exportar desde AWS KMS utilizando la API GenerateDataKeyPair o la API GenerateDataKeypairWithoutPlaintext.

La clave de datos simétrica o la parte privada de la clave de datos asimétrica se cifran bajo la clave de KMS simétrica que usted define cuando solicita que AWS KMS genere la clave de datos.

El motivo principal para usar el servicio AWS Private CA es ofrecer una infraestructura de clave pública (PKI, por sus siglas en inglés) que tenga como objetivo identificar entidades y proteger conexiones de red. Dicha infraestructura ofrece procesos y mecanismos, principalmente a través de certificados X.509, para disponer de una estructura en torno a operaciones criptográficas de claves públicas. Los certificados ofrecen una asociación entre una identidad y una clave pública. El proceso de certificación mediante el cual una entidad de certificación emite un certificado, permite a la entidad que emite el certificado de confianza aseverar la identidad de otra entidad a través de la firma de un certificado. PKI proporciona identidad, fiabilidad distribuida, gestión del ciclo de vida de la clave y estado del certificado creado a través de la revocación. Estas funciones agregan un importante proceso e infraestructura a las claves criptográficas asimétricas subyacentes y a los algoritmos proporcionados por AWS KMS.

Con AWS Private CA puede emitir certificados para identificar servidores web y de aplicaciones, mallas de servicios, usuarios de VPN, puntos de conexión de API internos y dispositivos de AWS IoT Core. Con los certificados puede establecer la identidad de estos recursos y crear canales de comunicación TLS o SSL. Si se está planteando usar claves asimétricas para la terminación TLS en servidores web y de aplicaciones, equilibradores de carga elásticos, puntos de conexión de API Gateway, instancias de Amazon Elastic Compute Cloud (EC2) o contenedores, deberá plantearse el uso de AWS Private CA para emitir certificados y proporcionar una infraestructura de clave pública.

En cambio, con AWS KMS puede generar, administrar y usar claves asimétricas para firmas digitales u operaciones de cifrado que no requieren certificados. Si bien los certificados pueden permitir la verificación de la identidad del expedidor y el receptor entre partes no fiables, el tipo de operaciones asimétricas sin procesar que ofrece AWS KMS generalmente es útil cuando usted cuenta con otros mecanismos para comprobar la identidad o no necesita comprobarla para obtener el beneficio de seguridad que desea.

No hay una integración nativa ofrecida por AWS KMS para cualquier otro proveedor API criptográfico. Usted debe usar los API de AWS KMS directamente o a través de AWS SDK para integrar las capacidades de firmado y cifrado en sus aplicaciones.

AWS KMS implanta las políticas de uso y administración definidas por el usuario. Tiene la opción de permitir que los usuarios y las funciones de IAM de la cuenta o de otras cuentas utilicen y administren las claves.

AWS KMS está diseñado para que nadie, ni siquiera los empleados de AWS, pueda recuperar claves de KMS de texto no cifrado del servicio. AWS KMS usa módulos de seguridad de hardware (HSM) que sirven para proteger la confidencialidad e integridad de las claves y que se validaron según las normas FIPS 140-2 o están en proceso de validación. Las claves de KMS de texto no cifrado jamás abandonan los HSM, jamás se graban en el disco y solo se usan en una memoria volátil de los HSM durante el tiempo necesario para realizar la operación criptográfica que solicitó. Las actualizaciones de software en los hosts del servicio y en el firmware del HSM de AWS KMS se verifican con un control de acceso de varios participantes que audita y revisa un grupo independiente de Amazon, así como un laboratorio certificado por el Instituto Nacional de Estándares y Tecnología (NIST) de conformidad con la norma FIPS 140-2.

Puede encontrar información adicional sobre estos controles de seguridad en el documento técnico sobre los detalles criptográficos de AWS KMS. También puede consultar el certificado FIPS 140-2 de los HSM de AWS KMS y la política de seguridad asociada para obtener más detalles sobre cómo los HSM de AWS KMS cumple los requisitos de seguridad de la norma FIPS 140-2. Además, puede descargar una copia del informe de los Controles de sistemas y organización (SOC) disponible en AWS Artifact para obtener más información sobre los controles de seguridad que utiliza el servicio para proteger las claves de KMS.

No necesita hacer nada. Todas las claves de AWS KMS, independientemente de la fecha de creación u origen, están protegidas automáticamente mediante la utilización de HSM validados con el nivel de seguridad 3 según la norma FIPS 140-2.

Los HSM validados con el nivel de seguridad 3 según la norma FIPS 140-2 se implementan en todas las regiones de AWS en las que se ofrece AWS KMS.
NOTA: Por ley, AWS KMS en las regiones de China no puede utilizar los HSM conformes a FIPS y NIST, en cambio, utiliza HSM certificados por la Oficina de la Administración Criptográfica Comercial Estatal (OSCCA) de China.

AWS KMS es un servicio con dos capas. Los puntos de conexión de las API reciben solicitudes de los clientes a través de una conexión HTTPS únicamente mediante el uso de conjuntos de cifrado TLS que admiten la confidencialidad directa total. Estos puntos de conexión de las API autentican y autorizan la solicitud antes de pasar la solicitud por una operación criptográfica a los HSM de AWS KMS o su clúster de AWS CloudHSM, si utiliza el almacén de claves personalizadas de KMS.

Puede configurar las aplicaciones para que se conecten a los puntos de conexión HTTPS validados según la norma FIPS 140-2 únicos y regionales. Los puntos de conexión HTTPS validados según la norma FIPS 140-2 de AWS KMS cuentan con la tecnología del módulo de objeto OpenSSL FIPS. Puede revisar la política de seguridad del módulo OpenSSL aquí. Los puntos de conexión de la API validados según la norma FIPS 140-2 se encuentran disponibles en todas las regiones comerciales en las que se ofrece AWS KMS.

Sí. AWS KMS cuenta con validación por tener los controles de funcionalidad y de seguridad necesarios para cumplir con los requisitos de cifrado y administración de claves (a los que se hace referencia, principalmente, en las secciones 3.5 y 3.6) de la norma PCI DSS 3.2.1.

Para obtener más detalles sobre los servicios de AWS que cumplen con la norma PCI DSS, lea las preguntas frecuentes sobre la norma PCI DSS.

Puede solicitar que AWS KMS genere claves de datos que puedan devolverse para utilizarse en la propia aplicación. Las claves de datos se cifran con una clave maestra definida por usted en AWS KMS, para que pueda almacenar la clave de datos cifrada junto con los datos cifrados. Solo pueden descifrar la clave de datos cifrados (y los datos de origen) los usuarios con permisos para utilizar la clave maestra original empleada para descifrar la clave de datos cifrados.

No. Las claves de AWS KMS se crean y utilizan solo en el servicio para ayudar a verificar la seguridad, implementar las políticas para que se apliquen con uniformidad y ofrecer un registro centralizado de la utilización.

Una clave de KMS de región única generada por AWS KMS se almacena y usa solo en la región en la que se creó. Las claves de varias regiones de AWS KMS le permiten replicar una clave principal de varias regiones en varias regiones dentro de la misma partición de AWS.

Los registros de AWS CloudTrail mostrarán todas las solicitudes de la API de AWS KMS, incluidas las solicitudes de administración (como la creación, la rotación, la desactivación o la edición de políticas) y las solicitudes criptográficas (como el cifrado y el descifrado). Active CloudTrail en la cuenta para ver estos registros.

Sí. Puede importar una copia de la clave de su propia infraestructura de administración de claves a AWS KMS y utilizarla con cualquier servicio de AWS integrado o desde las propias aplicaciones.

Puede utilizar una clave importada para disponer de mayor control en la creación, administración del ciclo de vida y durabilidad de su clave en AWS KMS. Las claves importadas están diseñadas para ayudarle a cumplir los requisitos de conformidad, que podrían incluir la capacidad de generar o mantener una copia segura de la clave en la infraestructura, así como la capacidad de eliminar inmediatamente la copia importada de la clave desde la infraestructura de AWS.

Puede importar claves simétricas, asimétricas (RSA y curva elíptica) y claves de HMAC.

Durante el proceso de importación, la clave estará encapsulada en una clave pública proporcionada por AWS KMS mediante el uso del algoritmo de empaquetado compatible. De este modo, se comprueba que solo AWS KMS puede descifrar la clave cifrada.

Puede volver a importar una copia del material de claves con una fecha de vencimiento válida a AWS KMS bajo la clave de AWS KMS original para poder utilizarla.

Sí. Cuando importe la clave a una clave de AWS KMS, recibirá una métrica de CloudWatch cada varios minutos que cuenta el tiempo que falta para el vencimiento de la clave importada. También recibirá un evento de CloudWatch una vez que venza la clave importada en la clave de AWS KMS. Puede crear una lógica que utilice estas métricas o eventos y vuelva a importar la clave de forma automática con una nueva fecha de vencimiento para evitar un riesgo de disponibilidad.

AWS KMS admite claves de 256 bits al crear una clave de KMS para el cifrado y el descifrado. Las claves de datos generados devueltas al intermediario pueden ser de 256 bits, 128 bits o un valor arbitrario de hasta 1024 bytes. Cuando AWS KMS utiliza una clave de KMS de 256 bits por usted para cifrar o descifrar, se utiliza el algoritmo AES en el modo de contador de Galois (AES-GCM).

AWS KMS admite los siguientes tipos de clave asimétrica: RSA 2048, RSA 3072, RSA 4096, ECC NIST P-256, ECC NIST P-384, ECC NIST-521 y ECC SECG P-256k1. AWS KMS admite los algoritmos de cifrado RSAES_OAEP_SHA_1 y RSAES_OAEP_SHA_256 con los tipos de clave RSA 2048, RSA 3072 y RSA 4096. Los algoritmos de cifrado no se pueden usar con los tipos de clave de curva elíptica (ECC NIST P-256, ECC NIST P-384, ECC NIST-521 y ECC SECG P-256k1).

Cuando se utilizan los tipos de claves RSA, AWS KMS apoya la RSASSA_PSS_SHA_256, RSASSA_PSS_SHA_384, RSASSA_PSS_SHA_512, RSASSA_PKCS1_V1_5_SHA_256, RSASSA_PKCS1_V1_5_SHA_384, y algoritmos de firma RSASSA_PKCS1_V1_5_SHA_512. Cuando se utilizan tipos de clave de curva elíptica, AWS KMS es compatible con los algoritmos de firma ECDSA_SHA_256, ECDSA_SHA_384 y ECDSA_SHA_512.

La parte pública del material de claves asimétrico se genera en AWS KMS y se puede utilizar para la verificación de firma digital mediante una llamada a la API “Verify” o para el cifrado de clave pública mediante una llamada a la API “Encrypt”. La clave pública también se puede utilizar fuera de AWS KMS para verificación o cifrado. Puede llamar a la API GetPublicKey para recuperar la parte pública de la clave de KMS asimétrica.

El límite de tamaño es de 4 KB. Si desea firmar digitalmente datos de más de 4 KB, tiene la opción de crear un resumen del mensaje de los datos y enviarlo a AWS KMS. La firma digital se crea sobre el resumen de los datos y se devuelve. El usuario especifica si va a enviar el mensaje completo o un resumen del mensaje como parámetro en la solicitud de API Sign. Cualquier dato enviado a las API Encrypt, Decrypt o Recrypt que requiera la utilización de operaciones asimétricas también debe ser inferior a 4 KB.

En la consola, cada clave tendrá un nuevo campo llamado Key Type (Tipo de clave). Tendrá el valor Asymmetric Key (Clave asimétrica) o Symmetric Key (Clave simétrica) para indicar el tipo de clave. La API DescribeKey devolverá un campo KeyUsage que especificará si la clave se puede utilizar para firmar, generar HMAC o cifrar.

No, la rotación automática de claves no es compatible con las claves de KMS asimétricas o de HMAC. En general, la rotación de claves asimétricas o de HMAC puede afectar en gran medida la carga de trabajo actual, ya que es necesario retirar y reemplazar todas las instancias de claves que haya compartido con otras partes en el pasado. En caso de que sea necesario, puede rotarlas manualmente mediante la creación de una nueva clave de KMS y la asignación de un alias de clave existente de la clave de KMS antigua a la nueva.

No. Al crear una clave de KMS, debe especificar si la clave se puede utilizar para descifrar o firmar operaciones. Se puede utilizar un tipo de clave RSA para operaciones de firma o cifrado, pero no ambas. Los tipos de clave de curva elíptica solo se pueden usar para operaciones de firma.

No, no puede utilizar la funcionalidad de almacenamiento de claves personalizadas con claves asimétricas.

No directamente. AWS KMS no almacena ni asocia certificados digitales a las claves de KMS asimétricas que crea. Puede optar por hacer que una entidad de certificación como ACM PCA emita un certificado para la parte pública de la clave de KMS asimétrica. Esto permitirá que las entidades que utilizan la clave pública verifiquen que dicha clave púbica es en realidad de su propiedad.

La característica de almacenamiento de claves personalizado de AWS KMS combina los controles proporcionados por CloudHSM con la integración y facilidad de utilización de AWS KMS. Puede configurar su propio clúster de CloudHSM y autorizar a AWS KMS para usarlo como un almacén de claves dedicado para sus claves en lugar del almacén de claves de AWS KMS predeterminado. Al crear claves en AWS KMS puede decidir generar el material de claves en el clúster de CloudHSM. Las claves de KMS que se generan en el almacén de claves personalizado nunca dejan los HSM en el clúster de CloudHSM en texto no cifrado y todas las operaciones de AWS KMS que utilizan estas claves solo se llevan a cabo en el HSM. En todos los demás aspectos, las claves de KMS almacenadas en el almacén de claves personalizado son coherentes con otras claves de AWS KMS.

Puede encontrar orientación adicional para decidir si utilizar un almacén de claves personalizado es adecuado para usted en este blog.

Dado que usted controla el clúster de CloudHSM, tiene la opción de administrar el ciclo de vida de las claves de KMS, independientemente de AWS KMS. Existen tres razones por las cuales podría serle útil un almacén de claves personalizado. En primer lugar, podría tener claves que deben explícitamente estar protegidas en un HSM de inquilino único o en un HSM sobre el que tiene control directo. En segundo lugar, podría necesitar tener la capacidad de eliminar inmediatamente el material de claves de AWS KMS y demostrar que lo ha hecho por sus propios medios. En tercer lugar, puede tener un requisito para poder auditar todo uso de sus claves que realice independientemente de AWS KMS o CloudTrail.

Hay dos diferencias a la hora de administrar claves en un almacén de claves personalizado respaldado por CloudHSM en comparación con el almacén de claves de AWS KMS predeterminado. No se puede importar el material de claves al almacén de claves personalizado y no puede tener claves de rotación automática de AWS KMS. En todos los demás aspectos, incluido el tipo de claves que pueden generarse, la forma en que las claves utilizan alias y cómo se definen las políticas, las claves que se almacenan en un almacén de claves personalizado se administran de la misma manera que cualquier otra clave de KMS administrada por el cliente de AWS KMS.

No, solo las claves de KMS administradas por el cliente se pueden almacenar y administrar en un almacén de claves personalizado de AWS KMS respaldado por CloudHSM. Las claves de KMS administradas por AWS que otros servicios de AWS crean por usted para cifrar datos siempre se generan y almacenan en el almacén de claves predeterminadas de AWS KMS.

No, las solicitudes de API a AWS KMS para utilizar una clave de KMS para cifrar y descifrar datos se manejan de la misma manera. Los procesos de autenticación y autorización funcionan independientemente del lugar donde esté almacenada la clave. Toda actividad en la que se utiliza una clave en un almacén de claves personalizado respaldado por CloudHSM también se registra en CloudTrail de la misma forma. Sin embargo, las operaciones criptográficas reales ocurren exclusivamente tanto en el almacén de claves personalizado como en el almacén de claves de AWS KMS predeterminado.

Además de la actividad que AWS KMS registra en CloudTrail, la utilización de un almacén de claves personalizado ofrece tres mecanismos adicionales de auditoría. En primer lugar, CloudHSM también registra toda la actividad de la API en CloudTrail, como la creación de clústeres o la adición o eliminación de los HSM. En segundo lugar, cada uno de los clústeres también captura sus propios registros locales para registrar la actividad de administración de usuarios y claves. En tercer lugar, cada instancia de CloudHSM copia los registros de la actividad de administración de claves y usuarios locales en AWS CloudWatch.

El uso de un almacén de claves personalizado de AWS KMS lo ayuda a responsabilizarse de verificar que sus claves están disponibles para que AWS KMS las utilice. Los errores en la configuración de CloudHSM y la eliminación accidental de material de claves dentro de un clúster de CloudHSM podrían afectar la disponibilidad. La cantidad de HSM que utiliza y su elección de zonas de disponibilidad (AZ) también pueden afectar la capacidad de recuperación del clúster. Como en cualquier sistema de administración de claves, es importante comprender cómo la disponibilidad de claves puede influir en el proceso de recuperación de datos cifrados.

La velocidad a la cual se pueden utilizar las claves almacenadas en un almacén de claves personalizado de AWS KMS respaldado por CloudHSM mediante llamadas a la API de AWS KMS es inferior a la que utilizan las claves almacenadas en el almacén predeterminado de clave de AWS KMS. Consulte la guía del desarrollador de AWS KMS para conocer los límites de rendimiento actuales.

No, la capacidad de importar su propio material de claves a un almacén de claves personalizado de AWS KMS no se admite. Las claves que se almacenan en un almacén de claves personalizado solo se pueden generar en los HSM que forman su clúster de CloudHSM.

No, la capacidad de migrar claves entre los diferentes tipos de almacén de claves de AWS KMS no es compatible actualmente. Todas las claves se deben crear en el almacén de claves en el que se van a utilizar, excepto en situaciones donde importa su propio material de claves en el almacén predeterminado de clave de AWS KMS.

La capacidad de rotar automáticamente material de claves en un almacén de claves personalizadas de AWS KMS no es compatible. La rotación de claves se debe realizar manualmente mediante la creación de nuevas claves y la reasignación de alias de las claves de AWS KMS utilizados por el código de la aplicación para usar las nuevas claves para las futuras operaciones de cifrado.

Sí, AWS KMS no exige el acceso exclusivo a su clúster de CloudHSM. Si ya dispone de un clúster, puede utilizarlo como un almacén de claves personalizado y seguir utilizándolo para otras aplicaciones. Sin embargo, si el clúster admite altas cargas de trabajo ajenas a AWS KMS, usted puede experimentar una reducción en el rendimiento de las operaciones al utilizar las claves de KMS del almacén de claves personalizadas. Asimismo, una alta tasa de solicitud de AWS KMS al almacén de claves personalizadas podría afectar a otras aplicaciones.

Un almacén de claves externo es un almacén de claves personalizado respaldado por una infraestructura de administración de claves externa que le pertenece y administra fuera de AWS. Todas las operaciones de cifrado y descifrado que utilizan una clave de KMS en un almacén de claves externo se llevan a cabo en su administrador de claves con operaciones y claves criptográficas que usted controla y que son físicamente inaccesibles para AWS.

El XKS puede ayudarlo a cumplir las normas y regulaciones según las cuales las claves de cifrado deben almacenarse y usarse fuera de AWS, y estar controladas por usted.

Las solicitudes a AWS KMS desde servicios de AWS integrados en su nombre o desde sus propias aplicaciones se reenvían a un componente de su red llamado proxy del XKS. El proxy del XKS es una especificación de API de código abierto que lo ayuda a usted y a su proveedor de administración de claves a crear un servicio que acepte estas solicitudes y las reenvíe a su infraestructura de administración de claves para usar sus claves para el cifrado y el descifrado.

Thales, Entrust, Atos, Fortanix, DuoKey, Securonix, Utimaco, Salesforce, T-Systems y HashiCorp cuentan con soluciones que se integran con la especificación del proxy XKS. Para obtener información sobre disponibilidad, precios y cómo usar soluciones de estos proveedores, consulte la documentación correspondiente. Le animamos a usted y a su socio de infraestructura de administración de claves a aprovechar la especificación del proxy del XKS de código abierto para crear una solución que se adecue a sus necesidades. La especificación de API para el proxy del XKS está publicada aquí.

Las claves externas son compatibles con las siguientes operaciones de cifrado simétrico: Encrypt, ReEncrypt, Decrypt y GenerateDataKey.

Puede usar las claves del XKS para cifrar datos en cualquier servicio de AWS que se integre con AWS KMS mediante el uso de claves administradas por el cliente. Consulte la lista de servicios compatibles aquí. Los servicios de AWS llaman a la API GenerateDataKey de AWS KMS para solicitar una clave de datos de texto no cifrado única para cifrar sus datos. La clave de datos de texto no cifrado se devuelve al servicio junto con una copia cifrada de la clave de datos para almacenarse junto a sus datos cifrados. Para producir una copia cifrada de la clave de datos, una clave almacenada en AWS KMS exclusiva de su cuenta de AWS cifra primero la clave de datos de texto no cifrado. A continuación, esta clave de datos cifrada se reenvía a la implementación del proxy del XKS conectada al administrador de claves externo para que se cifre por segunda vez en la clave que defina en el administrador de claves externo. La clave de datos con doble cifrado resultante se devuelve como respuesta a la solicitud de API GenerateDataKey.

La conexión de red entre AWS KMS, la implementación del proxy del XKS y el administrador de claves externo debería protegerse con un protocolo de cifrado punto a punto como TLS. Sin embargo, para proteger los datos que abandonan AWS KMS hasta que lleguen al administrador de claves externo, AWS KMS primero los cifra con una clave de KMS administrada internamente en su cuenta, específica para cada clave de KMS definida en el almacén de claves externo. El texto cifrado resultante se reenvía al administrador de claves externo, que lo cifra mediante el uso de la clave del administrador de claves externo. El cifrado doble proporciona un control de seguridad según el cual los textos cifrados no pueden descifrarse nunca sin usar el material de claves del administrador de claves externo. También proporciona un control de seguridad según el cual el texto cifrado que abandona la red de AWS se ha cifrado con los HSM de AWS KMS con certificación FIPS 140. El administrador de claves externo debe usarse para descifrar los datos. Por lo tanto, si anula el acceso a AWS KMS, no se podrá acceder a los datos cifrados subyacentes.

Sí. Las claves del XKS también pueden utilizarse desde sus propias aplicaciones cuando emplee una solución de cifrado simétrico del cliente que use AWS KMS como su proveedor de claves. Las soluciones de cifrado del cliente de código abierto de AWS, como el SDK de cifrado de AWS, el cliente de cifrado de S3 y el cliente de cifrado de DynamoDB, son compatibles con las claves del XKS.

Todas las claves del XKS deben crearse como claves nuevas en KMS. No puede migrar las claves de KMS existentes a las claves del XKS alojadas en el administrador de claves externo.

Si el servicio de AWS o su propia aplicación son compatibles con la acción, puede volver a cifrar los datos existentes en claves del XKS recién generadas. Muchos servicios de AWS lo ayudarán a copiar un recurso cifrado y designar una nueva clave de KMS para cifrar la copia. Puede configurar la clave del XKS en el comando COPY que le proporciona el servicio de AWS. Llame a la API ReEncrypt de KMS y configure la clave del XKS para volver a cifrar los datos cifrados del cliente en sus propias aplicaciones.

Igual que sucede con todas las claves administradas de clientes, el precio de las claves del XKS es de 1 USD al mes por clave hasta que se eliminen. Las solicitudes en las claves del XKS se cobran al mismo precio que cualquier otra clave simétrica de AWS KMS. Obtenga más información sobre los precios en la página de precios de AWS KMS.

Sí. La rotación automática de claves es compatible con la especificación XKS y es una capacidad que ofrecen la mayoría de los proveedores que admiten XKS. La rotación automática de las claves XKS se produce íntegramente en el administrador de claves externo y funciona de forma similar a la rotación automática de las claves de AWS KMS creadas y administradas dentro de KMS. Cuando se utiliza una clave KMS XKS rotada para cifrar datos, el administrador de claves externo utiliza el material de clave actual. Cuando se utiliza la clave XKS rotada para descifrar el texto cifrado, el administrador de claves externo utiliza la versión del material de claves que se utilizó para cifrarlo. Siempre que las claves XKS anteriores utilizadas para crear los textos cifrados anteriores sigan activadas en el administrador de claves externo, podrá realizar correctamente la solicitud de Decrypt API con esas versiones de sus claves XKS.

En los servicios que no almacenan claves en caché, se producirá un error al usar esta clave de KMS del XKS en la próxima llamada de API. Algunos servicios implementan el almacenamiento de claves de datos en caché u otros mecanismos de derivación para el rendimiento, la latencia o la administración de costos de KMS. El almacenamiento de estas claves en caché puede durar entre 5 minutos y 24 horas. Los recursos protegidos que se estén usando actualmente (como la base de datos de RDS o la instancia de EC2) responderán de manera diferente tras la denegación de acceso a la clave. Consulte la documentación del servicio de AWS correspondiente para obtener más información.

Para autenticarse en el proxy del almacén de claves externo, AWS KMS firma todas las solicitudes realizadas al proxy con las credenciales de AWS SigV4 que ha configurado en el proxy y ha proporcionado a KMS. AWS KMS autentica el proxy del almacén de claves externo con certificados TLS del servidor. De forma opcional, el proxy puede activar la TLS mutua para ofrecer una garantía adicional de que solo acepta solicitudes de AWS KMS.

Todos los mecanismos de autorización de AWS KMS habituales, como las políticas de IAM, las políticas de claves de AWS KMS o las concesiones, que usa con otras claves de KMS funcionan de la misma manera para las claves de KMS de los almacenes de claves externos.

Además, usted o sus socios del administrador de claves externo pueden implementar una capa secundaria de controles de autorización en función de los metadatos de la solicitud incluidos en cada solicitud que se envía desde AWS KMS al proxy del XKS. El rol o usuario de AWS que realiza la llamada, el ARN de la clave de KMS y la API de KMS específica que se ha solicitado forman parte de estos metadatos. De este modo, puede aplicar una política de autorización detallada sobre el uso de una clave en el administrador de claves externo que vaya más allá de confiar simplemente en cualquier solicitud de AWS KMS. La elección de la aplicación de la política mediante estos atributos de solicitud se deja para las implementaciones individuales del proxy del XKS.

El ID único generado para cada solicitud que llega a AWS KMS y que involucra claves del XKS también se reenvía al proxy del XKS. Puede usar los datos de registro (si están disponibles) del proxy del XKS o del administrador de claves externo para conciliar las solicitudes realizadas a AWS KMS y las realizadas al administrador de claves externo. Esta característica permite verificar si todas las solicitudes para usar claves en el administrador de claves externo proceden de una llamada que inició a AWS KMS directamente o a través de un servicio de AWS integrado.

Como AWS no puede controlar la disponibilidad de un extremo a otro de la conexión entre AWS KMS y la infraestructura del almacén de claves externo, excluimos específicamente el uso del XKS en nuestra SLA de disponibilidad de KMS pública. Además, las claves del XKS se excluyen de la SLA de disponibilidad de cualquier servicio de AWS en el cual se configure una clave del XKS para cifrar datos en el servicio.