KMS, ACM y patrones de cifrado

El cifrado es un control de seguridad fundamental que protege la confidencialidad de los datos incluso si el soporte de almacenamiento se ve comprometido o se obtiene acceso por otros medios. AWS proporciona cifrado para los datos en reposo (almacenados en bases de datos, S3 y EBS) y en tránsito (que se desplazan por las redes). Servicios clave: AWS Key Management Service (KMS) gestiona las claves de cifrado para el cifrado en reposo. AWS Certificate Manager (ACM) aprovisiona y gestiona certificados TLS para el cifrado en tránsito. Comprender cuándo y cómo aplicar cada uno es esencial para el dominio de arquitectura de seguridad del examen SAA-C03.

AWS KMS es un servicio totalmente administrado para crear y controlar claves de cifrado. KMS utiliza Hardware Security Modules (HSMs) para proteger las claves; el material de clave nunca sale del HSM sin cifrar. KMS se integra con la mayoría de los servicios de AWS para el cifrado del lado del servidor. Tipos de claves: AWS Managed Keys (gratuitas, rotación automática anual y sin control directo por su parte), Customer Managed Keys (CMK) (1 USD al mes cada una; usted controla la rotación, la política de claves y la eliminación). Custom Key Store utiliza su propio clúster de CloudHSM para requisitos de conformidad que exigen HSM dedicados.

Cada clave de KMS tiene una key policy, una política basada en recursos que controla quién puede utilizar y administrar la clave. A diferencia de las políticas de IAM, que se basan en identidades, las políticas de claves son obligatorias: la política de claves debe conceder explícitamente el acceso para que las políticas de IAM surtan efecto. Práctica recomendada: separe la administración de claves (quién puede administrar la clave) del uso de claves (qué servicios y roles pueden cifrar o descifrar). Utilice key grants para delegar acceso temporal; por ejemplo, conceda a un clúster de EMR acceso temporal a una clave de KMS para un trabajo sin modificar la política de claves.

KMS utiliza el cifrado de sobre para proteger grandes cantidades de datos de forma eficiente. No puede cifrar directamente más de 4 KB con una clave de KMS. En su lugar: KMS genera una Data Encryption Key (DEK), una clave aleatoria que se utiliza para cifrar localmente los datos reales. A continuación, la clave de KMS cifra la DEK (la Key Encryption Key). Debe almacenar la DEK cifrada junto con los datos cifrados. Para descifrar, primero debe llamar a KMS para descifrar la DEK y, después, utilizar localmente la DEK en texto plano para descifrar los datos. Así funcionan internamente el cifrado de S3, EBS y RDS.

La rotación de claves es una práctica recomendada de seguridad que sustituye periódicamente el material criptográfico de las claves, limitando el periodo de exposición si una clave se ve comprometida. Para las Customer Managed Keys, puede activar la rotación automática anual; KMS genera nuevo material de clave y lo utiliza para las nuevas operaciones de cifrado, conservando el material anterior para descifrar los datos existentes. Las AWS Managed Keys rotan automáticamente cada año. El material de clave importado NO admite la rotación automática (debe rotarlo manualmente). Tras la rotación, las nuevas operaciones de KMS utilizan automáticamente el nuevo material de clave sin cambios en la aplicación.

S3 admite tres opciones de cifrado del lado del servidor: SSE-S3: S3 gestiona las claves mediante AES-256; es gratuito y ofrece un control mínimo. SSE-KMS: utiliza una clave de KMS (administrada por AWS o una CMK), proporciona un registro de auditoría del uso de la clave en CloudTrail, admite políticas de claves y tiene un coste por llamada a la API de KMS. SSE-C: usted proporciona y gestiona el material de clave con cada solicitud; S3 nunca almacena la clave. Utilice SSE-KMS cuando necesite auditar quién utilizó la clave y cuándo. Utilice SSE-S3 para datos de baja sensibilidad cuando la simplicidad y el coste sean importantes. Imponga el cifrado mediante una política de bucket que deniegue PutObject sin cifrado.

AWS Certificate Manager (ACM) aprovisiona, gestiona y renueva automáticamente certificados SSL/TLS para los servicios de AWS sin coste. Los certificados de ACM se pueden utilizar con ALB, NLB, CloudFront, API Gateway y AppSync. ACM gestiona automáticamente el ciclo de vida de los certificados: los renueva 60 días antes de que caduquen y despliega la renovación de forma transparente. Puede solicitar certificados para dominios que sean de su propiedad (validados mediante DNS o correo electrónico) o importar certificados de terceros. Los certificados de ACM NO se pueden descargar, ya que están vinculados al servicio de AWS con el que se asocian.

ACM Private CA (Certificate Authority) le permite crear una jerarquía de CA privada totalmente administrada para emitir certificados para recursos internos, como instancias de EC2, contenedores, API internas y dispositivos IoT. A diferencia de los certificados públicos de ACM (que se usan con servicios accesibles desde Internet), los certificados de una CA privada pueden emitirse para cualquier nombre de host o dirección IP interna. Use Private CA para: TLS mutuo (mTLS) entre microservicios, autenticación basada en certificados para VPN y requisitos de cumplimiento de una PKI interna. Private CA cuesta 400 USD al mes por la CA, más 0,75 USD por cada certificado emitido.

Para el cifrado de volúmenes de EBS, actívelo al crear el volumen (o copie un volumen existente con el cifrado habilitado). Todos los datos del volumen, incluidas las instantáneas, se cifran mediante la clave de KMS que especifique. El cifrado de EBS es transparente para el sistema operativo: no se necesitan cambios en la aplicación. Para el cifrado de RDS, actívelo al crear la instancia de base de datos; no puede cifrar directamente una instancia de RDS existente que no esté cifrada. Como alternativa, cree una instantánea cifrada a partir de una instancia no cifrada y, después, restáurela en una instancia nueva cifrada. Las instantáneas cifradas de EBS y RDS permanecen cifradas al copiarlas.

Comprender la diferencia entre el cifrado del lado del servidor y del lado del cliente es importante para el examen SAA-C03. Cifrado del lado del servidor: AWS cifra los datos después de recibirlos y los descifra antes de entregarlos; los datos están en texto sin formato entre su aplicación y AWS. Cifrado del lado del cliente: usted cifra los datos antes de enviarlos a AWS; AWS solo almacena el texto cifrado y nunca ve el texto sin formato. Use el cifrado del lado del cliente para datos muy sensibles cuando no pueda confiar en que el proveedor de la nube gestione el texto sin formato, como historiales médicos o datos financieros sujetos a normativas estrictas.

Las claves de KMS se pueden compartir entre cuentas de AWS para escenarios de cifrado entre cuentas. Por ejemplo, si la aplicación de la Cuenta A escribe datos cifrados en un bucket de S3 propiedad de la Cuenta B, la clave de KMS de la Cuenta A debe permitir que la entidad principal de la Cuenta B la use. Configure la política de claves de KMS en la Cuenta A para conceder acceso entre cuentas y, después, cree una política de IAM en la Cuenta B para permitir que el rol use la clave de la Cuenta A. Este patrón es habitual en arquitecturas de intercambio de datos y con varias cuentas, en las que una cuenta central administra las claves de cifrado.

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección ha aprendido que: KMS administra claves de cifrado con protección mediante HSM y admite CMK para un control de acceso detallado y registros de auditoría; ACM aprovisiona y renueva automáticamente certificados TLS para los servicios de AWS sin coste; y el cifrado se puede aplicar del lado del servidor (KMS) o del lado del cliente, aunque el del lado del servidor es el patrón más habitual para las cargas de trabajo nativas de AWS. Imponga el cifrado mediante políticas de bucket que denieguen las operaciones sin cifrado. A continuación, exploraremos GuardDuty, Inspector y Macie.