Ir al contenido

¡Se acercan los certificados de 47 días! ¿Estás preparado?

Actúa ahora →

Análisis en profundidad del servicio de administración de claves de AWS

Administración de claves de AWS

AWS Key Management Service (AWS KMS) es la capa centralizada de administración de claves para la nube de AWS, que controla las claves de cifrado que protegen los datos en más de 100 servicios de AWS y aplicaciones de clientes. Esto es fundamental, ya que la seguridad de cada objeto S3 cifrado, volumen EBS, base de datos RDS y secreto Lambda depende de quién controla las claves KMS que los protegen y cómo se gestionan dichas claves. El punto de partida recomendado es crear claves KMS administradas por el cliente con una política de claves explícita, habilitar la rotación automática y configurar CloudTrail para registrar cada evento de cifrado y descifrado vinculado a una identidad autenticada.

Respuesta rápida: ¿Qué tipo de clave de AWS KMS debería usar?

Para cargas de trabajo reguladas: utilice siempre claves KMS gestionadas por el cliente. Son el único tipo que ofrece un registro de auditoría independiente por operación en CloudTrail, una política de claves que usted controla, la capacidad de deshabilitar o eliminar la clave de forma independiente y compatibilidad con BYOK (material de clave importado). Para cargas de trabajo generales donde el cumplimiento no requiere el control de claves por parte del cliente: las claves gestionadas por AWS son aceptables y no requieren ninguna sobrecarga operativa. Las claves propiedad de AWS no proporcionan registro de auditoría ni visibilidad para el cliente; evítelas para cualquier dato confidencial. Para el requisito de protección de claves más alto (FIPS 140-2 Nivel 3 con hardware dedicado): utilice un almacén de claves personalizado respaldado por AWS CloudHSM.

Puntos Clave

  • El material clave de KMS nunca sale del HSM en texto plano: Todas las claves KMS se generan y utilizan dentro de HSM validados según FIPS 140-2. El KMS estándar utiliza el Nivel 2; los almacenes de claves personalizados respaldados por CloudHSM utilizan el Nivel 3.
  • AWS KMS utiliza cifrado de sobre para la protección de todos los datos: KMS genera y protege claves de cifrado de datos (DEK). La clave KMS cifra la DEK; la DEK cifra los datos. La clave KMS nunca cifra los datos directamente.
  • Las claves gestionadas por el cliente son necesarias para los registros de auditoría de cumplimiento: Solo las claves gestionadas por el cliente generan eventos de CloudTrail por operación (GenerateDataKey, Decrypt) vinculados a identidades IAM específicas.
  • Tanto la política de claves como la política de IAM deben permitir una acción: El control de acceso de AWS KMS requiere tanto la política de recursos clave como la política de identidad IAM del principal que realiza la llamada para permitir la operación. Ninguna de las dos por sí sola es suficiente en la mayoría de las configuraciones.
  • La rotación automática no requiere volver a cifrar los datos existentes: Cuando una clave KMS rota, KMS conserva las versiones anteriores de la clave para descifrar los datos cifrados antes de la rotación. El ARN de la clave permanece igual; las aplicaciones no necesitan actualizarse.

¿Qué es el Servicio de administración de claves de AWS?

AWS Key Management Service (AWS KMS) es un servicio de administración de claves criptográficas que crea, almacena y controla el acceso a las claves de cifrado que protegen las cargas de trabajo de AWS. Al habilitar el cifrado en un bucket de S3, un volumen de EBS, una instancia de RDS o un secreto de Secrets Manager, AWS KMS genera y protege las claves que dan validez a dicho cifrado.

AWS KMS almacena todo el material de clave dentro de módulos de seguridad de hardware (HSM) validados según FIPS 140-2 Nivel 2 para claves KMS estándar. El material de clave generado en AWS KMS nunca sale del límite del HSM en texto plano. Cuando un servicio o aplicación de AWS necesita cifrar o descifrar datos, llama a la API de KMS, KMS realiza la operación de clave dentro del HSM y devuelve solo el resultado. AWS KMS se integra de forma nativa con más de 100 servicios de AWS, incluidos Amazon S3, Amazon EBS, Amazon RDS, Amazon DynamoDB, AWS Lambda, AWS Secrets Manager, Amazon Redshift, Amazon EFS y AWS Systems Manager Parameter Store.

Cómo AWS KMS utiliza el cifrado de sobre

AWS KMS no cifra los datos directamente. Utiliza cifrado de sobre: ​​una clave maestra (la clave KMS) protege una clave de cifrado de datos (DEK), y la DEK cifra los datos propiamente dichos. El cifrado de sobre mantiene el cifrado de datos local mientras protege la clave en el hardware, ya que las claves KMS nunca salen del HSM y no se pueden enviar grandes cantidades de datos a KMS para su cifrado directo.

Operación de escritura: la aplicación llama kms:GenerateDataKeyKMS genera una nueva clave de cifrado de datos (DEK) dentro del HSM y devuelve una DEK en texto plano y una DEK cifrada. La aplicación cifra los datos con la DEK en texto plano, la descarta inmediatamente y almacena la DEK cifrada junto con el texto cifrado. La DEK cifrada solo puede ser descifrada por KMS utilizando la clave KMS original.

Operación de lectura: la aplicación envía el DEK cifrado a KMS a través de kms:DecryptKMS lo descifra dentro del HSM y devuelve la clave DEK en texto plano. La aplicación descifra los datos y descarta inmediatamente la clave DEK en texto plano. La clave KMS nunca sale del HSM; solo la clave DEK se mueve entre KMS y la aplicación.

Tipos de claves de AWS KMS: Gestionado por AWS, Gestionado por el cliente y Propiedad de AWS

AWS KMS organiza las claves en tres tipos con propiedades de control, visibilidad y cumplimiento significativamente diferentes. La nomenclatura cambió en 2021 de CMK (Customer Master Key) a clave KMS, pero los tipos subyacentes siguen siendo los mismos.

Claves KMS gestionadas por el cliente

Las claves administradas por el cliente son creadas por usted en su cuenta de AWS. Usted define la política de clave, controla quién puede usar y administrar la clave, habilita o deshabilita la clave, programa la eliminación y configura la rotación automática. Cada GenerateDataKey y Decrypt La llamada genera un evento de CloudTrail con el ARN de la clave, la entidad principal de IAM solicitante, la IP de origen y una marca de tiempo. Este registro de auditoría por operación es la principal capacidad de cumplimiento que ofrecen las claves administradas por el cliente y que otros tipos de claves no proporcionan. Las claves administradas por el cliente cuestan 1 $ por clave al mes más 0.03 $ por cada 10 000 llamadas a la API. Admiten tres orígenes de material de clave: generado por AWS, BYOK (importado) y almacén de claves personalizado (con respaldo de CloudHSM).

Claves KMS administradas por AWS

Las claves administradas por AWS son creadas automáticamente por los servicios de AWS la primera vez que habilita el cifrado sin especificar una clave administrada por el cliente. El alias sigue el patrón aws/service-name (por ejemplo, aws/s3, aws/ebs, aws/rdsPuedes ver los metadatos de la clave, pero no puedes modificar la política de la clave, deshabilitarla, programar su eliminación ni controlar su rotación. AWS rota automáticamente las claves administradas por AWS cada tres años. No se aplican cargos adicionales más allá de las tarifas estándar de las llamadas a la API.

Claves KMS propiedad de AWS

Las claves propiedad de AWS son propiedad exclusiva de AWS y están gestionadas por esta empresa. Se comparten entre varias cuentas de clientes. No son visibles en la consola de KMS, usted no tiene control sobre ellas y no generan eventos de CloudTrail en su cuenta. Son adecuadas para datos no confidenciales donde la prioridad es minimizar la gestión, pero no son apropiadas para cargas de trabajo reguladas que requieran un registro de auditoría o el control de claves de cliente.

PropiedadClave gestionada por el clienteClave administrada por AWSClave propiedad de AWS
Creada porEl clienteServicio de AWSAWS
Visible en tu cuentaSí: Sí: No
Control de políticas claveControl total del clienteNingunaNinguna
Deshabilitar/eliminar capacidadSí: NoNo
Eventos de CloudTrail por operaciónSí (cada GenerateDataKey y Decrypt)LimitadaNo
Rotación automáticaOpcional (de 90 días a 7 años)Sí (cada 3 años)Varíable
Soporte BYOKSí: NoNo
Costo$1/clave/mes + $0.03/10 000 llamadas a la APISolo llamadas a la API por $0.03/10 000Sin cargo
Ideal paraCargas de trabajo reguladas, cumplimiento normativo, requisitos de auditoríaCargas de trabajo generales, bajos costos generalesEscenarios no sensibles y de gestión cero

Servicios de gestión de claves en la nube a medida

Obtenga servicios de consultoría flexibles y personalizables que se alineen con sus requisitos de nube.

Claves KMS simétricas, asimétricas y HMAC

Las claves KMS simétricas utilizan una única clave AES-GCM de 256 bits tanto para el cifrado como para el descifrado. El material de la clave nunca sale de AWS KMS en texto plano. Las claves simétricas son adecuadas para la mayoría de los casos de uso de protección de datos: cifrado de objetos S3, volúmenes EBS, bases de datos RDS y secretos de Secrets Manager. La mayoría de los servicios de AWS que se integran con KMS solo admiten claves simétricas.

Las claves asimétricas de KMS contienen un par de claves pública/privada. La clave privada nunca sale de KMS en texto plano. La clave pública se puede descargar y usar fuera de KMS. Las claves asimétricas de KMS admiten RSA (para cifrado/descifrado o firma/verificación) y ECDSA (solo para firma/verificación). Utilice claves asimétricas cuando necesite una clave pública para distribuir a terceros mientras la clave privada permanece protegida en KMS. Los servicios de AWS que cifran datos en reposo utilizan exclusivamente claves simétricas.

Las claves HMAC KMS generan y verifican códigos de autenticación de mensajes basados ​​en hash para la validación de tokens, la firma de solicitudes de API y la verificación de la integridad de los datos. Utilizan material de clave simétrica, pero su función es la autenticación, no el cifrado.

Modelo IAM: Cómo funciona el control de acceso en AWS KMS

El control de acceso a AWS KMS es el aspecto que con mayor frecuencia se configura incorrectamente en las implementaciones de KMS. El modelo de políticas de dos capas requiere que tanto la política de recursos clave como la política de identidad IAM del principal que realiza la llamada permitan una operación.

Política de claves (política basada en recursos): Cada clave KMS administrada por el cliente tiene una política de claves obligatoria que constituye el mecanismo principal de control de acceso. Si la política de claves no otorga explícitamente a una entidad de IAM permiso para usar la clave, dicha entidad no podrá usarla, independientemente de su política de identidad de IAM. Si la política de claves incluye la instrucción que otorga permisos de administración de claves a la cuenta raíz, las políticas de IAM de esa cuenta pueden otorgar permisos de administración de claves a las entidades de la cuenta. Esta es la política predeterminada creada por la consola KMS.

Política de identidad de IAM: Una política de identidad de IAM puede otorgar permisos de KMS, pero solo si la política de claves también lo permite para la entidad principal. Para las operaciones del plano de datos (cifrado, descifrado, generación de clave de datos, firma), aplique el principio de mínimo privilegio tanto en la política de claves como en la política de identidad de IAM.

Separación de la gestión de claves y su uso: Separe el rol de administrador de claves (quien puede gestionar las políticas, la rotación, la eliminación y la activación/desactivación de claves) del rol de usuario de claves (quien puede llamar a las funciones Cifrar, Descifrar y Generar clave de datos). Las cuentas de servicio de la aplicación solo deben tener los permisos específicos para operaciones criptográficas que necesitan sobre claves específicas, nunca permisos de gestión de claves.

Políticas de control de servicio (SCP): En una organización de AWS, las SCP proporcionan una capa de protección adicional a las políticas de IAM. Utilice una SCP para denegar la eliminación de claves KMS de producción, exigir el cifrado en servicios específicos o impedir la desactivación del registro de KMS a través de CloudTrail. Las SCP funcionan como un límite máximo de permisos; no pueden otorgar permisos, solo restringirlos.

BYOK en AWS KMS: Traiga su propio material de clave

BYOK (Bring Your Own Key) en AWS KMS significa importar material de clave generado fuera de AWS a una clave KMS. BYOK se utiliza cuando las regulaciones o las políticas internas exigen que el material de clave de cifrado se genere en una infraestructura controlada por el cliente y que este conserve el material de clave original independientemente de AWS.

El proceso de importación BYOK consiste en crear una clave KMS sin material de clave (Origen: EXTERNO); descargar la clave pública de envoltura y el token de importación desde KMS; generar material de clave AES de 256 bits en su propio HSM; cifrar su material de clave utilizando la clave pública de envoltura (RSA_OAEP_SHA_256); cargar el material de clave cifrado y el token de importación a KMS. KMS descifra el material de clave dentro del HSM y lo almacena como material de clave de la clave KMS.

Restricciones de BYOK: puede establecer una fecha de caducidad para el material de clave importado, tras lo cual KMS lo elimina automáticamente. Puede eliminar manualmente el material de clave importado sin eliminar la clave, lo que hace que todos los datos cifrados con ella sean inaccesibles hasta que se vuelvan a importar. La rotación automática no está disponible para las claves BYOK; debe generar material nuevo externamente y volver a importarlo.

HYOK: Mantén tu propia llave

HYOK (Hold Your Own Key) va más allá de BYOK: la clave de cifrado nunca ingresa a AWS KMS. Tu aplicación cifra los datos del lado del cliente antes de subirlos a cualquier servicio de AWS, utilizando una clave generada y almacenada en tu propia infraestructura. AWS solo almacena el texto cifrado y no puede descifrar tus datos bajo ninguna circunstancia, ni siquiera ante una demanda legal dirigida a AWS.

HYOK es apropiado para datos clasificados, requisitos de soberanía donde la infraestructura de AWS se encuentra fuera de su perímetro de confianza o cargas de trabajo donde su modelo de amenazas incluye a la propia AWS. Cada operación de lectura y escritura requiere una comunicación bidireccional con su sistema externo de gestión de claves, que debe tener alta disponibilidad. El HSM como servicio de Encryption Consulting proporciona la infraestructura externa de gestión de claves FIPS 140-2 Nivel 3 necesaria para implementar HYOK en cargas de trabajo de AWS.

DimensiónKMS nativo (clave generada por AWS)BYOK (Material clave importado)HYOK (Cliente, clave fuera de AWS)
Clave generada porAWS KMS HSMCliente (importado a KMS)Cliente (nunca ingresa a AWS)
Acceso de AWS a la clave durante su usoSí: Sí (operativo)No
Registro de auditoría de CloudTrailSí (por operación)Sí (por operación)No (solo registros KMS externos)
Revocación independienteDeshabilitar/eliminar la clave mediante APIEliminar material importado (inmediato)Revocar en KMS externo
Rotación automáticaSí (de 90 días a 7 años)No (se requiere reimportación manual)Gestión totalmente centrada en el cliente.
Complejidad operativaBajoMediaAlto
Ideal paraLa mayoría de las cargas de trabajo de AWSRegulado: se requiere la procedencia de la clave del cliente.Clasificado, confianza cero, mandato soberano

Almacén de claves personalizado KMS: FIPS 140-2 Nivel 3 con CloudHSM

Un almacén de claves personalizado de KMS asocia AWS KMS con un clúster de AWS CloudHSM de su propiedad y administración. El material de clave de KMS se genera y almacena en su clúster de CloudHSM con certificación FIPS 140-2 Nivel 3, en lugar de la infraestructura estándar de KMS Nivel 2. Las claves en un almacén de claves personalizado son AES-GCM de 256 bits, no exportables y nunca salen de los HSM de CloudHSM en texto plano. Todas las operaciones criptográficas se realizan dentro de su clúster de CloudHSM.

Los almacenes de claves personalizados requieren al menos dos HSM activos en diferentes zonas de disponibilidad. Si el clúster deja de estar disponible, KMS no puede realizar operaciones con esas claves, lo que significa que la disponibilidad de su aplicación depende de su clúster CloudHSM. Los almacenes de claves personalizados son adecuados para cargas de trabajo FedRAMP High que requieren FIPS 140-2 Nivel 3, operaciones de firma calificadas por eIDAS o para organizaciones con infraestructura CloudHSM existente que desean la validación de Nivel 3 dentro de la experiencia de la API de KMS.

Rotación de claves en AWS KMS

La rotación de claves de AWS KMS genera nuevo material criptográfico para una clave KMS y la marca como la versión activa para nuevas operaciones de cifrado, conservando todas las versiones anteriores para descifrar los datos cifrados antes de la rotación. El ARN de la clave, el ID de la clave y todos los alias permanecen sin cambios. Las aplicaciones siguen funcionando después de la rotación sin necesidad de modificar la configuración.

Para las claves gestionadas por el cliente con material generado por AWS, la rotación automática es configurable entre 90 días y 7 años. Cuando se produce la rotación, KMS genera nuevo material de clave dentro del HSM, lo marca como activo y registra un RotateKey Evento de CloudTrail. Las versiones anteriores del material se conservan indefinidamente.

Para las claves BYOK con material importado, la rotación automática no está disponible. Debe gestionar la rotación manualmente: genere un nuevo material de clave AES de 256 bits fuera de AWS, impórtelo como una nueva versión de clave y designelo como material principal. La rotación bajo demanda para claves gestionadas por el cliente con material generado por AWS está disponible en cualquier momento a través de RotateKeyOnDemand API, útil tras un posible incidente de exposición de claves.

Registro de CloudTrail para AWS KMS

Cada llamada a la API de AWS KMS genera un evento de administración de CloudTrail de forma predeterminada. Cada cifrado, descifrado, creación de clave, eliminación de clave y cambio de política se registra con la identidad solicitante, el ARN de la clave, la marca de tiempo y la IP de origen. Eventos clave para monitorear y recibir alertas:

  • Generar clave de datos: Se registra cuando un servicio o aplicación crea una nueva clave de cifrado de datos. Alerta sobre entidades no autorizadas que generan claves de datos.
  • Descifrar: Se registra cuando un servicio o aplicación descifra una clave de cifrado de datos. Se genera una alerta ante cualquier llamada de descifrado proveniente de una entidad que no se encuentre en la lista de roles aprobados. Un alto volumen de llamadas de descifrado puede indicar una filtración de datos.
  • Programar eliminación de clave: Reciba alertas inmediatas sobre cualquier clave de producción programada para su eliminación. KMS aplica un período de espera mínimo de 7 días.
  • Deshabilitar clave: Alerta inmediata. Una clave deshabilitada detiene todas las operaciones de cifrado y descifrado, lo que provoca interrupciones inmediatas del servicio.
  • PutKeyPolicy: Alerta ante cualquier cambio en la política de claves de producción. Los cambios en la política pueden ampliar o restringir el acceso a las claves.
  • RotateKey / RotateKeyOnDemand: Registro para evidencia de cumplimiento. Los eventos de rotación inesperados deben investigarse.

Dirija los registros de CloudTrail a un bucket de S3 independiente y protegido contra escritura en una cuenta de seguridad dedicada. Habilite la validación de integridad de los archivos de registro de CloudTrail. Habilite los eventos de datos de S3 por separado, ya que las operaciones a nivel de objeto no se capturan en los registros de eventos de administración de forma predeterminada.

Costo de AWS KMS: Precios y optimización

Las claves administradas por el cliente cuestan $1 por clave al mes. Las claves administradas por AWS y las claves propiedad de AWS no tienen cargo por almacenamiento de claves. Todas las llamadas a la API de KMS cuestan $0.03 por cada 10,000 solicitudes. Para cargas de trabajo S3 de alto volumen, los costos de la API de KMS se acumulan porque cada PutObject de S3 genera un GenerateDataKey llamada y cada GetObject genera un Decrypt Llamada. Una carga de trabajo S3 con 10 millones de operaciones PUT y GET al mes genera aproximadamente 60 dólares al mes en tarifas de la API de KMS.

La función S3 Bucket Key reduce este coste hasta en un 99 %. Cuando está habilitada, S3 genera una clave de datos temporal a nivel de bucket a partir de su clave KMS y la utiliza para generar DEK individuales para cada objeto localmente dentro de S3, en lugar de llamar a KMS para cada objeto. Las propiedades de seguridad no cambian; los objetos permanecen cifrados con AES-256-GCM bajo una jerarquía de claves que se remonta a su clave KMS. Para claves de almacén de claves personalizadas respaldadas por CloudHSM, el clúster cuesta aproximadamente 1.45 $ por hora por instancia de HSM, aproximadamente 2,100 $ al mes para un clúster HA de dos instancias, además de las tarifas estándar de KMS.

AWS KMS en arquitecturas multinube e híbridas

AWS KMS es nativo de AWS y no se extiende de forma nativa a Azure, GCP ni a sistemas locales. Tres patrones abordan AWS KMS en un contexto multinube:

  • Sistema de gestión de conocimiento (KMS) nativo por nube con gobernanza unificada: Utilice AWS KMS para AWS, Azure Key Vault para Azure y GCP Cloud KMS para GCP, pero implemente una plataforma centralizada de gestión del ciclo de vida de las claves que agregue el inventario de claves, el estado de rotación y los registros de auditoría de las tres. Esto preserva el rendimiento nativo de la nube a la vez que proporciona visibilidad del cumplimiento normativo entre nubes.
  • BYOK centralizado desde un HSM externo: Genere todo el material clave desde un único HSM externo. Importe las claves derivadas a AWS KMS como claves BYOK, a Azure Key Vault y a GCP Cloud KMS. Todo el cifrado se remonta a una única fuente de clave autorizada. HSM como servicio Proporciona la infraestructura HSM externa FIPS 140-2 de nivel 3 para este modelo.
  • Cifrado del lado del cliente con clave compartida (HYOK): Cifra todos los datos antes de que ingresen a cualquier proveedor de nube. AWS KMS no interviene; la nube solo almacena el texto cifrado. Es el modelo de soberanía multinube más robusto, pero requiere que las aplicaciones gestionen las operaciones criptográficas del lado del cliente y que tu KMS externo tenga alta disponibilidad.

Cómo puede ayudar la consultoría de cifrado

Encryption Consulting es una empresa de criptografía aplicada con certificaciones ISO/IEC 27001:2022 y SOC 2. Ayudamos a las organizaciones a diseñar, implementar y auditar configuraciones de AWS KMS, desde la arquitectura de claves inicial hasta la generación continua de evidencia de cumplimiento.

  • Aviso sobre la protección de datos en la nube: Evaluamos su configuración de AWS KMS, identificamos deficiencias (claves propiedad de AWS donde se requieren claves administradas por el cliente, políticas de clave faltantes, eventos de datos de CloudTrail ausentes, buckets de S3 sin optimización de Bucket Key, políticas de clave demasiado permisivas) y diseñamos la jerarquía de clave objetivo, el modelo IAM, el cronograma de rotación y la configuración de auditoría. Consulte nuestra servicios de consultoría en la nube.
  • HSM como servicio: Para arquitecturas BYOK y HYOK que requieren generación de claves FIPS 140-2 Nivel 3 fuera de AWS, Encryption Consulting HSM como servicio Proporciona una infraestructura HSM dedicada que se integra con los flujos de trabajo de importación de claves de AWS KMS, adecuada como fuente BYOK en AWS, Azure y GCP simultáneamente.
  • CBOM Seguro: Consultoría de cifrado CBOM seguro Descubre e inventaría todas las configuraciones de claves KMS, políticas de acceso y estados de rotación en todas las cuentas de AWS, generando una lista de materiales criptográficos en formato CycloneDX que cumple con la documentación del requisito 12.3.3 de PCI DSS v4.0.1.
  • Infraestructura de clave pública como servicio: Para cargas de trabajo de AWS que utilizan TLS mutuo entre servicios o implementan AWS Private CA para la emisión interna de certificados, Encryption Consulting PKI como servicio Proporciona una CA privada administrada con gestión automatizada del ciclo de vida de los certificados mediante ACME y almacenamiento de claves de CA respaldado por KMS. Consulte también nuestra guía sobre Cifrado del lado del cliente y del servidor de AWS S3.
  • Preparación para PQC: El NIST finalizó los estándares de criptografía post-cuántica FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA) en agosto de 2024. El NIST IR 8547 apunta a la desaprobación de RSA y ECC para nuevos usos alrededor de 2030. Las claves asimétricas RSA y ECC de AWS KMS necesitarán migración. Preparación para PQC El servicio compara su conjunto de claves de AWS KMS con el cronograma de migración posterior a la computación cuántica.
  • Aviso de cumplimiento: Mapeamos su configuración de AWS KMS a los requisitos de PCI DSS v4.0.1, FedRAMP, HIPAA, DORA, NIST CSF 2.0 y NIST SP 800-53 Rev. 5, identificamos brechas, creamos la hoja de ruta de remediación y generamos el paquete de evidencia de auditoría. Consulte nuestra Servicios de asesoramiento sobre cumplimiento.

Para hablar sobre la arquitectura de AWS KMS o los requisitos de cumplimiento, póngase en contacto con Encryption Consulting.

Conclusión

AWS KMS es la base de gestión de claves para la nube de AWS. La elección entre claves gestionadas por AWS, gestionadas por el cliente y claves BYOK (Bring Your Own Key) es una decisión de cumplimiento y soberanía que determina si su organización cuenta con un registro de auditoría independiente, capacidad de revocación independiente y procedencia de claves independiente.

Las configuraciones incorrectas más comunes de KMS incluyen el uso de claves administradas o propiedad de AWS cuando el cumplimiento normativo exige claves administradas por el cliente, políticas de claves demasiado permisivas que otorgan un amplio acceso a KMS a los roles de la aplicación, eventos de datos de CloudTrail ausentes o mal configurados que dejan lagunas en el registro de auditoría, y la falta de configuración de la clave del bucket de S3, lo que multiplica innecesariamente los costos de la API de KMS. Solucionar estos problemas desde el principio es mucho más sencillo que corregirlos en una gran infraestructura de AWS después de que una auditoría de cumplimiento los detecte.

Servicios de gestión de claves en la nube a medida

Obtenga servicios de consultoría flexibles y personalizables que se alineen con sus requisitos de nube.

Preguntas frecuentes

¿Qué es el Servicio de administración de claves de AWS (AWS KMS)?

AWS Key Management Service (AWS KMS) es un servicio administrado que crea y controla claves de cifrado utilizadas para proteger datos en los servicios y aplicaciones de AWS. AWS KMS almacena las claves en HSM validados según FIPS 140-2 (Nivel 2 para claves estándar, Nivel 3 para claves de almacén de claves personalizadas). Las claves nunca salen del HSM en texto plano. AWS KMS se integra de forma nativa con más de 100 servicios de AWS, incluidos S3, EBS, RDS, Lambda y Secrets Manager.

¿Cuál es la diferencia entre las claves administradas por AWS, las claves administradas por el cliente y las claves propiedad de AWS?

Las claves administradas por AWS se crean automáticamente mediante los servicios de AWS; puede verlas, pero no modificar su política, deshabilitarlas ni controlar su rotación. Las claves administradas por el cliente las crea usted mismo con control total sobre la política de claves, un registro de auditoría de CloudTrail por operación y la posibilidad de deshabilitarlas o eliminarlas; su costo es de $1 por clave al mes. Las claves propiedad de AWS son invisibles para usted, se comparten entre cuentas y no generan eventos de CloudTrail. Para cargas de trabajo reguladas, se requieren claves administradas por el cliente.

¿Cómo funciona el cifrado de sobres en AWS KMS?

AWS KMS genera una clave de cifrado de datos (DEK) cuando un servicio o aplicación la solicita, devolviendo una DEK en texto plano y una copia cifrada. La aplicación cifra los datos con la DEK en texto plano, la descarta y almacena únicamente la DEK cifrada junto con el texto cifrado. Para descifrar, la aplicación envía la DEK cifrada a KMS, que la descifra dentro del HSM y devuelve la DEK en texto plano. La clave de KMS nunca sale del HSM; solo la DEK se mueve entre KMS y la aplicación.

¿Qué es BYOK en AWS KMS y cómo funciona?

BYOK implica generar el material de clave en su propio HSM e importarlo a una clave de AWS KMS con el origen configurado como EXTERNO. Descargue una clave de envoltura de KMS, cifre su material de clave con ella y cargue el material cifrado. AWS KMS utiliza su material para operaciones criptográficas, pero usted conserva el original fuera de AWS. Puede eliminar el material importado de KMS para revocar inmediatamente su uso. La rotación automática no está disponible para las claves BYOK.

¿Cómo funciona la rotación de claves en AWS KMS?

La rotación automática genera nuevo material de clave dentro del HSM de KMS según un cronograma que usted configure (de 90 días a 7 años para claves administradas por el cliente). Las versiones anteriores del material se conservan para descifrar los datos cifrados antes de la rotación. El ARN y el ID de la clave permanecen sin cambios. Para las claves BYOK, la rotación automática no está disponible; usted genera nuevo material externamente y lo vuelve a importar manualmente. La rotación bajo demanda está disponible en cualquier momento a través de la API RotateKeyOnDemand.

¿Qué eventos de AWS KMS aparecen en CloudTrail y cómo se deben monitorizar?

Cada llamada a la API de KMS genera un evento de CloudTrail. Reciba alertas inmediatas sobre ScheduleKeyDeletion y DisableKey para cualquier clave de producción, sobre llamadas Decrypt de entidades principales que no estén en la lista de roles aprobados y sobre eventos Decrypt de alto volumen que sugieran una filtración de datos. Reciba alertas sobre cambios en PutKeyPolicy para claves de producción. Dirija los registros de CloudTrail a un bucket de S3 protegido contra escritura en una cuenta de seguridad dedicada. Habilite los eventos de datos de S3 por separado, ya que las operaciones a nivel de objeto no se capturan en los registros de eventos de administración de forma predeterminada.