Preguntas frecuentes de AWS Key Management Service

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-3 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 NIST de conformidad con la norma FIPS 140-3.

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-3 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 cumplen los requisitos de seguridad de la norma FIPS 140-3. 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-3.

Los HSM validados con el nivel de seguridad 3 según la norma FIPS 140-3 se despliegan 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 enlace 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.

CloudHSM le proporciona un clúster de HSM de inquilino único validado en su nube privada virtual (VPC) de Amazon para almacenar y utilizar sus claves. Tiene el control exclusivo de la manera en la que se utilizan las claves mediante un mecanismo de autenticación independiente de AWS. La interacción con las claves del clúster de CloudHSM es similar a la interacción con las aplicaciones que se ejecutan en Amazon EC2. Puede usar CloudHSM para admitir distintos casos de uso, como la administración de derechos digitales (DRM), la infraestructura de clave pública (PKI), la firma de documentos y las funciones criptográficas mediante el uso de PKCS#11, Java JCE o las interfaces de Microsoft CNG.
 

Con AWS KMS puede crear y controlar las claves de cifrado que usan las aplicaciones y los servicios de AWS admitidos en varias regiones del mundo desde una única consola. El servicio utiliza un HSM de la norma FIPS que ha sido validado según la norma FIPS 140-3 o está en proceso de validación para proteger la seguridad de sus claves. Con la administración centralizada de todas las claves en AWS KMS puede controlar quién puede usar las claves, bajo qué condiciones, cuándo se rotan y quién puede administrarlas. La integración de AWS KMS con CloudTrail ofrece la posibilidad de auditar el uso de las claves para respaldar las actividades normativas y de conformidad. Puede interactuar con AWS KMS desde las aplicaciones mediante el SDK de AWS si desea llamar a las API del servicio directamente, a través de otros servicios de AWS que están integrados con AWS KMS o mediante el SDK de cifrado de AWS, si desea realizar el cifrado en el cliente.

Con AWS KMS solo paga por lo que usa y no hay ninguna cuota mínima. No se requieren cuotas de configuración ni compromisos para comenzar a utilizar el servicio. A final de mes, se le cobrará automáticamente en su tarjeta de crédito el uso de ese mes.

Se cobrará por todas las claves de KMS que cree, así como por las solicitudes a la API realizadas al servicio cada mes que superen el nivel gratuito.
 

Para obtener más información sobre los precios, visite la página de precios de AWS KMS.

Sí. Con el nivel gratuito de AWS puede comenzar a utilizar AWS KMS de forma gratuita* en todas las regiones. Las claves de AWS KMS administradas por AWS que los servicios de AWS crean por usted se almacenan sin costos en la cuenta. También existe un nivel gratuito de uso que ofrece un número gratuito de solicitudes al servicio por mes. Para obtener más información actualizada sobre los precios, incluido el nivel gratuito, visite la página de precios de AWS KMS.

* Las solicitudes de API que involucren claves de KMS asimétricas y las solicitudes de API a las API GenerateDataKeyPair y GenerateDataKeyPairWithoutPlaintext no están incluidas en el nivel gratuito.

Si no se especifica lo contrario, nuestros precios no incluyen los impuestos ni gravámenes correspondientes, como el IVA y cualquier otro impuesto sobre las ventas.  En el caso de los clientes con una dirección de facturación de Japón, el uso de los servicios de AWS está sujeto al impuesto de consumo nipón. Puede obtener más información aquí.

Sí. Puede importar una copia de la clave de su propia infraestructura de administración de claves de AWS KMS y usarla con cualquier servicio de AWS integrado o desde sus 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.

Hay dos diferencias principales:
 

1. Debe conservar una copia de las claves que importe en su infraestructura de administración de claves, a fin de poder volver a importarlas en cualquier momento. AWS, sin embargo, verifica la disponibilidad, seguridad y durabilidad de las claves que genera AWS KMS para usted hasta que programe la eliminación de las claves.
2. Puede establecer un periodo de vencimiento de la clave importada. AWS KMS eliminará de forma automática el material de claves después del periodo de vencimiento. También puede eliminar el material de claves importado bajo demanda. En ambos casos, el material de claves en sí se elimina, pero la referencia de la clave de KMS en AWS KMS y los metadatos asociados se retienen para que el material de claves se pueda volver a importar en el futuro. Las claves generadas por AWS KMS no tienen una fecha de vencimiento y no pueden ser eliminadas inmediatamente; existe un periodo de espera obligatorio de 7 a 30 días. Todas las claves de KMS administradas por el cliente, independientemente de si se importó el material de claves, se pueden deshabilitar manualmente o se puede programar su eliminación. En este caso, se elimina la clave de KMS, no solo el material de clave subyacente.

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 lógica que actúe conforme a 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 tipos de claves de curva elíptica, AWS KMS admite los algoritmos de acuerdo de claves del protocolo ECDH.

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.

Sí. Los límites de frecuencia de solicitudes por segundo son diferentes para diferentes tipos de claves y algoritmos. Para obtener más información, consulte nuestra página Límites de AWS KMS.

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.

La utilización de un almacén de claves personalizado no afecta los precios de AWS KMS. No obstante, cada almacén de claves personalizadas exige que su clúster de AWS CloudHSM contenga al menos dos HSM. Estos HSM se cobran en función de los precios estándar de AWS CloudHSM. El uso de un almacén de claves personalizado no tiene costos adicionales.

Los usuarios de AWS KMS que quieran utilizar un almacén de claves personalizado deberán configurar un clúster de AWS CloudHSM, agregar HSM, administrar usuarios de HSM y, posiblemente, restaurar los HSM a partir de copias de seguridad. Estas tareas afectan la seguridad y puede verificar que dispone de los recursos y los controles de organización adecuados en su lugar.

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.

Visite el sitio web de AWS CloudHSM para obtener más información general sobre el servicio. Para obtener más información sobre su configuración y utilización, lea la Guía del usuario de AWS CloudHSM.

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.

Riesgo de responsabilidad: es responsable de la disponibilidad del proxy del XKS y del material de claves externo. Este sistema debe ofrecer una alta disponibilidad para verificar que, siempre que necesite una clave del XKS para descifrar un recurso cifrado o cifrar datos nuevos, AWS KMS puede conectarse correctamente al proxy del XKS, el cual puede conectarse al administrador de claves externo para completar la operación criptográfica necesaria mediante el uso de la clave. Por ejemplo, imagínese que ha cifrado un volumen de EBS con una clave del XKS y ahora quiere iniciar una instancia de EC2 y adjuntar ese volumen cifrado. El servicio de EC2 pasará la clave de datos cifrados única de ese volumen a AWS KMS con el objetivo de descifrarla para que pueda aprovisionarse en la memoria volátil de la tarjeta Nitro a fin de descifrar y cifrar operaciones de escritura o lectura en el volumen. Si el proxy del XKS o el administrador de claves externo no está disponible para descifrar la clave del volumen, la instancia de EC2 no se iniciará. En estos tipos de errores, AWS KMS devuelve una KMSInvalidStateException en la que se indica que el proxy del XKS no está disponible. Ahora le toca a usted determinar por qué el proxy del XKS y el administrador de claves no están disponibles en función de los mensajes de error que le proporciona KMS.

Riesgo de durabilidad: como usted controla las claves en sistemas fuera de AWS, es el único responsable de la durabilidad de todas las claves externas que cree. Si la clave externa de una clave del XKS se pierde o elimina de forma permanente, los textos cifrados con esa clave del XKS no se podrán recuperar.

Riesgo de rendimiento: es el responsable de comprobar si el proxy del XKS y la infraestructura del almacén de claves externo están diseñados con las características de rendimiento suficientes para satisfacer sus necesidades. Como las solicitudes que usan claves del XKS necesitan conectarse al almacén de claves externo, el proxy del XKS puede convertirse en un cuello de botella si la tasa de solicitudes de AWS KMS supera la tasa de solicitudes que pueden asumir el proxy del XKS o el administrador de claves externo. Además. si el tiempo transcurrido de una única solicitud (incluido un nuevo intento) de AWS KMS al proxy del XKS es superior a 500 ms, AWS KMS devolverá un error 400 al cliente que llama y comunicará eficazmente que la clave del XKS no está disponible y que el cliente que llama no debería volver a intentarlo. Este comportamiento se ha diseñado para minimizar el riesgo de que los servicios de AWS ascendentes o sus propias aplicaciones tengan que reaccionar ante una latencia excesiva esporádica provocada por problemas de conectividad a la infraestructura.

*AWS KMS volverá a intentarlo una única vez para cualquier solicitud que dure 250 ms. Si la nueva solicitud también dura más de 250 ms, se devolverá un error 400 al cliente que llama.

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.