AWS S3: cifrado del lado del cliente y del servidor

El cifrado del lado del cliente y del servidor de AWS S3 ofrece cinco maneras distintas de proteger los datos en Amazon Simple Storage Service, cada una con un equilibrio diferente entre la propiedad de las claves, la complejidad operativa, la profundidad de la auditoría y el coste. La opción adecuada depende de a quién necesite proteger: solo a atacantes externos o a AWS. Esta guía abarca todas las opciones de cifrado de S3, cuándo usar cada una, cómo aplicarlas con políticas de bucket, qué información aparece en CloudTrail y cómo decidir entre la administración nativa de claves, BYOK (Bring Your Own Key) y HYOK (Hyper Key Management).

Respuesta rápida: ¿Qué opción de cifrado de AWS S3 debería utilizar?

Para la mayoría de las cargas de trabajo: utilice SSE-KMS con una clave KMS administrada por el cliente. Obtendrá cifrado AES-256 en reposo, un registro de auditoría completo de CloudTrail de cada evento de cifrado y descifrado vinculado a una identidad IAM, capacidad de deshabilitación de clave independiente y rotación automática anual de claves. Para la máxima soberanía de clave (donde AWS nunca debe almacenar su clave): utilice cifrado del lado del cliente con su propia clave maestra. Para la configuración más simple sin sobrecarga de administración de claves y sin requisito de registro de auditoría: SSE-S3 (que ahora es el predeterminado de S3 desde enero de 2023). Para proporcionar su propia clave por solicitud sin usar KMS: SSE-C.

Puntos Clave

• S3 cifra los datos por defecto desde enero de 2023: Todos los objetos nuevos en cualquier bucket de S3 se cifran automáticamente con SSE-S3 (AES-256), incluso sin configuración explícita. Los objetos existentes no se cifran retroactivamente.
• Existen cinco opciones de cifrado, divididas en dos categorías: El cifrado del lado del servidor (SSE-S3, SSE-KMS, SSE-C) implica que S3 gestiona el cifrado tras recibir los datos. El cifrado del lado del cliente implica que se cifran los datos antes de subirlos, por lo que S3 nunca ve el texto sin cifrar.
• SSE-KMS es la opción predeterminada recomendada para cargas de trabajo reguladas: Proporciona un registro de auditoría por operación en CloudTrail, admite claves gestionadas por el cliente con BYOK y permite deshabilitar o eliminar una clave para impedir inmediatamente el descifrado sin eliminar objetos.
• BYOK y HYOK satisfacen diferentes necesidades de soberanía: BYOK (importar su propio material de clave a AWS KMS) mantiene la clave en AWS durante su uso, pero le brinda trazabilidad. HYOK (cifrado del lado del cliente con su propia clave maestra) significa que AWS nunca accede a la clave en ningún momento.
• El cifrado en tránsito requiere una política de depósito independiente: El cifrado predeterminado de S3 solo cubre los datos en reposo. Deniegue aws:SecureTransport=false en la política de su bucket para aplicar TLS a todas las solicitudes.

¿Qué es el cifrado de AWS S3 y por qué es importante?

Amazon S3 (Simple Storage Service) es el servicio de almacenamiento de objetos de AWS. Almacena datos como objetos dentro de contenedores llamados buckets. Cada objeto puede tener un tamaño de hasta 5 TB. S3 se utiliza ampliamente para copias de seguridad, lagos de datos, activos de aplicaciones, archivos de registros y conjuntos de datos regulados, incluidos los de los sectores sanitario (HIPAA), financiero (PCI DSS) y gubernamental (FedRAMP).

El cifrado en S3 aborda dos modelos de amenazas distintos. El cifrado en reposo protege los objetos almacenados en disco para que no se puedan leer si se accede al medio de almacenamiento subyacente sin autorización. El cifrado en tránsito protege los objetos mientras se transmiten entre los clientes y el servicio S3. Ambos son obligatorios para la mayoría de los marcos de cumplimiento normativo y requieren configuraciones independientes en S3.

S3 utiliza AES-256 con Modo de Contador de Galois (AES-256-GCM) para todas las operaciones de cifrado simétrico. GCM proporciona cifrado autenticado: añade una etiqueta de autenticación única a cada objeto cifrado, verificando que los datos no hayan sido manipulados y que se haya utilizado la clave correcta para el descifrado. Esto protege contra la interceptación pasiva y la modificación activa del texto cifrado almacenado.

Cifrado en tránsito: Implementación de TLS para todas las solicitudes de S3

S3 admite HTTPS (TLS) para todas las solicitudes de API. TLS cifra la conexión entre el cliente y el punto final de S3, protegiendo los datos de los objetos y los metadatos de la solicitud durante la transmisión. Sin embargo, S3 no impone HTTPS de forma predeterminada; un bucket de S3 sin una política definida aceptará tanto solicitudes HTTP como HTTPS.

Para aplicar TLS a todas las solicitudes a un bucket, aplique una política de bucket que deniegue cualquier solicitud donde aws:SecureTransport La condición clave es falsa. La política que se muestra a continuación deniega todas las solicitudes GetObject que no utilicen HTTPS:

{
  "Id": "EnforceSSLOnly",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonSSLRequests",
      "Action": "s3:*",
      "Effect": "Deny",
      "Resource": [
        "arn:aws:s3:::your-bucket-name",
        "arn:aws:s3:::your-bucket-name/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      },
      "Principal": "*"
    }
  ]
}

Aplique esta política a cada bucket de S3 que contenga datos confidenciales. Tenga en cuenta que la Resource El bloque debe cubrir tanto el ARN del bucket como el ARN del objeto (con /*) para denegar las llamadas a la API tanto a nivel de bucket como a nivel de objeto realizadas a través de HTTP.

Cifrado del lado del servidor (SSE): Tres opciones explicadas

El cifrado del lado del servidor implica que S3 recibe tus datos a través de HTTPS y los cifra antes de guardarlos en el disco. S3 almacena el texto cifrado. Cuando solicitas el objeto, S3 lo descifra (con la clave correspondiente) antes de enviártelo de vuelta a través de HTTPS. El cifrado y el descifrado se realizan dentro del entorno del servicio S3. Tu aplicación no necesita gestionar operaciones criptográficas.

SSE-S3: Claves gestionadas por S3 (opción predeterminada desde enero de 2023)

SSE-S3 (Cifrado del lado del servidor con claves administradas por Amazon S3) es el método de cifrado predeterminado para todos los objetos S3 nuevos desde enero de 2023. AWS genera una clave de cifrado de datos AES-256-GCM única para cada objeto. Esta clave se cifra con una clave maestra que AWS administra por completo y que se rota periódicamente. Usted no tiene visibilidad ni control sobre ninguna de las claves.

SSE-S3 es adecuado para cargas de trabajo que requieren cifrado en reposo, pero no se necesita un registro de auditoría del uso de claves ni un control independiente de las mismas. No añade sobrecarga operativa ni coste adicional al almacenamiento S3 estándar. La desventaja: no se puede deshabilitar, rotar ni auditar el acceso a la clave de cifrado. No existe un registro de CloudTrail sobre el descifrado de objetos individuales. No se puede revocar la capacidad de descifrar un objeto sin eliminarlo.

SSE-KMS: Claves gestionadas por KMS con registro de auditoría y control del cliente.

SSE-KMS utiliza AWS Key Management Service (KMS) para gestionar las claves de cifrado que protegen tus objetos de S3. Al cargar un objeto con SSE-KMS, S3 llama a KMS para generar una clave de cifrado de datos (DEK). KMS devuelve dos versiones: una DEK en texto plano (utilizada para cifrar el objeto) y una DEK cifrada (almacenada junto con el objeto cifrado en S3). S3 descarta la DEK en texto plano inmediatamente después de cifrar el objeto. Al descargar el objeto, S3 envía la DEK cifrada a KMS, que la descifra y devuelve la DEK en texto plano para que S3 pueda descifrar el objeto y devolvértelo.

Cada llamada a GenerateDataKey y Decrypt en KMS genera una entrada en el registro de CloudTrail que incluye el ARN de la clave KMS, la entidad principal de IAM solicitante, la clave del bucket y del objeto S3, y una marca de tiempo. Esto proporciona un registro de auditoría completo, vinculado a la identidad, de cada evento de cifrado y descifrado en cada objeto S3 protegido por SSE-KMS.

SSE-KMS admite dos tipos de claves, que tienen propiedades de seguridad y control significativamente diferentes:

Clave KMS administrada por AWS (aws/s3): AWS crea esta clave automáticamente la primera vez que habilita SSE-KMS en un bucket sin especificar una CMK. AWS administra la clave por completo, incluyendo la rotación (cada tres años para las claves aws/s3). Puede ver la clave en KMS, pero no puede cambiar su política, deshabilitarla ni eliminarla. Obtiene el registro de CloudTrail, pero no tiene control independiente sobre la clave.

Clave KMS gestionada por el cliente (CMK): Esta clave se crea en KMS antes de habilitar SSE-KMS. Se define la política de claves, se controla quién puede usarla para el cifrado y descifrado de S3, se habilita la rotación anual automática y se puede deshabilitar o eliminar la clave en cualquier momento. Deshabilitar la CMK impide inmediatamente que S3 descifre cualquier objeto cifrado con esa clave, sin eliminar dichos objetos. Esta es la opción recomendada para cargas de trabajo reguladas.

SSE-C: Claves de cifrado proporcionadas por el cliente

SSE-C (Cifrado del lado del servidor con claves proporcionadas por el cliente) requiere que incluyas una clave de cifrado AES de 256 bits en el encabezado de la solicitud HTTP para cada operación PutObject (carga) y GetObject (descarga). S3 utiliza la clave proporcionada para realizar la operación de cifrado o descifrado AES-256 y, a continuación, la elimina inmediatamente de la memoria. S3 almacena únicamente una huella digital HMAC (Código de autenticación de mensajes basado en hash) con un valor aleatorio para validar futuras solicitudes.

La consecuencia: si pierde la clave, perderá permanentemente el acceso a todos los objetos cifrados con ella. No existe ningún mecanismo de recuperación de clave. SSE-C debe usar HTTPS; S3 rechaza las solicitudes SSE-C realizadas a través de HTTP.

SSE-C es apropiado cuando necesita S3 para realizar operaciones de cifrado, pero no puede o no desea almacenar su clave en AWS KMS. Usted asume la responsabilidad total de la administración, rotación, almacenamiento y distribución de la clave a todos los sistemas que necesiten acceder a los objetos. SSE-C no genera eventos de CloudTrail de KMS porque no utiliza KMS.

Cifrado del lado del cliente: Cifrado antes de la carga

El cifrado del lado del cliente implica que su aplicación o cliente cifra los datos antes de que salgan de su entorno. Lo que S3 recibe y almacena ya está cifrado; S3 nunca tiene acceso al texto sin cifrar. Este es el único modelo de cifrado de S3 en el que AWS no puede acceder a sus datos bajo ninguna circunstancia operativa, ni siquiera en caso de requerimiento legal.

El SDK de AWS para Java (y otros lenguajes) proporciona un cliente de cifrado S3 que implementa el cifrado del lado del cliente. Hay dos opciones de administración de claves:

En el lado del cliente con AWS KMS CMK: Su aplicación llama a KMS para generar una clave de datos en texto plano y una clave de datos cifrada. Su aplicación cifra el objeto con la clave de datos en texto plano, descarta la clave en texto plano y carga el texto cifrado junto con la clave de datos cifrada como metadatos del objeto. Para descargar y descifrar, su aplicación recupera la clave de datos cifrada de los metadatos del objeto, llama a KMS para descifrarla, utiliza la clave de datos en texto plano devuelta para descifrar el objeto y descarta la clave en texto plano. AWS KMS interviene en el encapsulado de claves, por lo que existe un registro de CloudTrail de las operaciones con claves, pero AWS nunca tiene acceso a los datos del objeto en texto plano.

En el lado del cliente, con una clave maestra autogestionada: Su aplicación utiliza su propia clave maestra (almacenada en su HSM, sistema de gestión de claves o almacén de claves de la aplicación) para cifrar y descifrar la clave de cifrado de datos. AWS no interviene en ninguna operación de clave. Este es el modelo HYOK (Hold Your Own Key, es decir, "Mantén tu propia clave"): la clave de cifrado se encuentra completamente fuera de AWS. Incluso si AWS se viera obligado a proporcionar acceso a su bucket de S3, el texto cifrado almacenado sería inútil sin la clave maestra, que nunca entró en AWS.

Control de teclas nativo vs. BYOK vs. HYOK: ¿Qué modelo se ajusta mejor a sus necesidades?

La decisión más importante sobre el cifrado para cualquier carga de trabajo S3 no es qué modo AES usar, sino quién controla las claves. Los tres modelos de control de claves disponibles para S3 tienen propiedades de seguridad, requisitos operativos e implicaciones de cumplimiento muy diferentes.

Dimensión	Clave KMS nativa (SSE-S3 o gestionada por AWS)	BYOK (clave KMS gestionada por el cliente con material de clave importado)	HYOK (Cifrado del lado del cliente con clave maestra autogestionada)
¿Quién genera la clave de cifrado?	AWS	Cliente (importado a KMS)	Cliente (nunca ingresa a AWS)
Acceso de AWS a la clave en texto plano	Sí:	Sí, durante las operaciones activas de KMS.	No
Registro de auditoría de CloudTrail por objeto	SSE-S3: No. KMS administrado por AWS: Sí	Sí (GenerateDataKey + eventos Decrypt)	Variante KMS: Sí (encapsulado/desencapsulado de claves). Autogestionado: No
Desactivar/revocar clave independiente	SSE-S3: No. KMS administrado por AWS: No.	Sí (desactive o elimine CMK inmediatamente)	Sí (revocar en su sistema de gestión de claves)
Rotación automática de la llave	SSE-S3: Sí (gestionado por AWS). KMS gestionado por AWS: Cada 3 años	Sí (anual para CMK) o manual para material importado.	Gestión totalmente centrada en el cliente.
Complejidad operativa	Bajo	Media	Alto
Coste de la API de KMS por operación S3	SSE-S3: Ninguno. KMS administrado por AWS: $0.03/10 000 llamadas	Opciones de compra de $0.03/10k	Variante KMS: Opciones de compra de $0.03/10k. Autogestionado: Ninguno.
Ideal para	Cargas de trabajo generales; prioridad a la simplicidad	Sectores regulados: HIPAA, PCI DSS, FedRAMP	Almacenamiento de confianza cero; aislado físicamente; datos clasificados

Modelo IAM: Acceso con privilegios mínimos para el cifrado de S3

El cifrado por sí solo no impide el acceso no autorizado. Una configuración adecuada de IAM determina quién puede leer (y, por lo tanto, descifrar) los objetos de S3. Un modelo de IAM bien diseñado para cargas de trabajo SSE-KMS S3 separa la gestión de claves de cifrado del acceso a los datos mediante tres capas de control.

Política de bucket S3: Controla qué entidades principales de IAM pueden realizar llamadas a la API de S3 (GetObject, PutObject, ListBucket, DeleteObject) en el bucket y sus objetos. Para la aplicación de SSE-KMS, agregue una condición Denegar que requiera s3:x-amz-server-side-encryption encabezado a ser aws:kms En todas las solicitudes PutObject, se garantiza que no se puedan cargar objetos sin cifrar.

Política clave de KMS: Controla qué entidades principales de IAM pueden usar la CMK para kms:GenerateDataKey (necesario para cifrar objetos) y kms:Decrypt (necesario para descifrar objetos). El servicio S3 llama a KMS en nombre de la entidad principal de IAM solicitante; dicha entidad debe tener permisos tanto para S3 como para KMS para que la operación se realice correctamente. Separe el rol de administrador de claves (quien puede gestionar la política de claves, rotarlas y deshabilitarlas) del rol de usuario de claves (quien puede cifrar/descifrar a través de S3).

Política de identidad IAM: La política IAM del principal que realiza la llamada debe permitir tanto la acción S3 como la acción KMS. Para un rol de solo lectura que debería acceder a los objetos S3 pero nunca cargar nuevos, otorgue s3:GetObject y kms:Decrypt solamente. Para un rol de escritura, agregue s3:PutObject y kms:GenerateDataKeyNunca conceder kms:CreateKey, kms:DeleteKey, o kms:DisableKey a los roles de la aplicación.

Políticas de control de servicio (SCP): Si sus cuentas de AWS se encuentran 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 cualquier operación S3 PutObject que no incluya un encabezado de cifrado, lo que impide que cualquier entidad de la organización almacene accidentalmente objetos S3 sin cifrar, independientemente de las configuraciones de IAM de cada cuenta.

Rotación de claves para el cifrado S3

La rotación de claves para S3 SSE-KMS funciona mediante la rotación de claves de KMS, no mediante el recifrado de cada objeto de S3. Cuando se habilita la rotación anual automática en una clave maestra de cliente (CMK) gestionada por el cliente, KMS genera nuevo material criptográfico y lo marca como la versión activa. Todas las nuevas operaciones PutObject de S3 utilizan el nuevo material de clave. Los objetos existentes permanecen cifrados con la versión del material de clave que estaba activa cuando se cargaron; KMS conserva todas las versiones anteriores y utiliza la correcta al descifrar esos objetos antiguos.

Esto significa que nunca necesitará volver a cargar o volver a cifrar sus objetos S3 para implementar la rotación de claves. El ARN CMK y el ID de clave permanecen iguales; la rotación es transparente para S3 y para sus aplicaciones. El evento de rotación se registra en CloudTrail bajo el RotateKey tipo de evento.

Para las claves BYOK con material de clave importado, la rotación automática no está disponible a través de KMS. Debe generar nuevo material de clave externamente, importarlo al mismo CMK, establecerlo como material de clave principal y gestionar usted mismo el cronograma de transición. Para SSE-C, usted es totalmente responsable de la rotación: debe proporcionar nuevas claves en sus solicitudes y volver a cifrar los objetos existentes si desea cambiar la clave que los protege.

Registro de CloudTrail para eventos de cifrado de S3

El registro de CloudTrail es la base de auditoría para el cumplimiento del cifrado SSE-KMS. Cada llamada a la API de KMS realizada por S3 en nombre de una entidad solicitante genera un registro de CloudTrail que incluye el ARN de la clave KMS, la entidad IAM (usuario, rol o servicio), la dirección IP de origen, el nombre del bucket de S3 y la clave del objeto, y una marca de tiempo.

Los dos eventos a monitorear son: GenerateDataKey (generado cuando se carga un objeto con SSE-KMS) y Decrypt (generado cuando se descarga y descifra un objeto). Las alertas sobre estos eventos permiten varios casos de uso de seguridad: detectar entidades no autorizadas que descifran objetos confidenciales, identificar volúmenes de descifrado inusualmente altos que podrían indicar la filtración de datos, auditar el cumplimiento de las políticas de acceso a los datos y crear paquetes de evidencia para auditorías regulatorias.

Configure CloudTrail para que entregue eventos de datos de S3 además de los eventos de administración, ya que la actividad a nivel de objeto de S3 (GetObject, PutObject, DeleteObject) no se registra en los registros de eventos de administración de forma predeterminada. Dirija los registros de CloudTrail a un bucket de S3 independiente y protegido contra escritura en una cuenta de seguridad dedicada para evitar manipulaciones.

Consideraciones de costos para el cifrado S3

SSE-S3 no añade ningún coste al almacenamiento ni a las solicitudes de S3. SSE-KMS añade costes a las llamadas a la API de KMS: AWS KMS cobra 0.03 $ por cada 10 000 llamadas a la API (GenerateDataKey para cargas, Decrypt para descargas). Para una carga de trabajo que carga y descarga 1 millón de objetos al mes, el coste de la API de KMS es de aproximadamente 6 $ al mes por CMK y por región. Las claves KMS gestionadas por el cliente también cuestan 1 $ al mes por clave.

Con volúmenes de solicitudes elevados (decenas de millones de operaciones de S3 al mes), los costes de la API de KMS se vuelven significativos. S3 lo mitiga mediante una función de clave a nivel de bucket: al habilitar la opción Clave de bucket de S3 en un bucket de SSE-KMS, S3 genera una clave de datos de corta duración a nivel de bucket a partir de su CMK y la utiliza para generar DEK de objetos individuales localmente, lo que reduce las llamadas a la API de KMS hasta en un 99 %. El enfoque de Clave de bucket reduce drásticamente el coste para cargas de trabajo de S3 de alto rendimiento, manteniendo las mismas propiedades de cifrado.

SSE-C no tiene costo de AWS para la administración de claves, pero usted asume el costo operativo total de almacenar, distribuir, rotar y proteger la clave fuera de AWS. De manera similar, el cifrado del lado del cliente con una clave maestra autoadministrada no tiene costo de administración de claves de AWS, pero requiere su propia infraestructura para la administración del ciclo de vida de la clave.

Implementación del cifrado S3 con políticas de bucket

La configuración de cifrado en un bucket establece el comportamiento predeterminado para los objetos nuevos, pero no impide que un usuario cargue explícitamente un objeto sin cifrar a menos que se agregue una política de denegación. Para garantizar que todos los objetos estén cifrados y que solo se utilice el método seleccionado, combine dos declaraciones de denegación en la política del bucket.

Para aplicar SSE-KMS con una CMK específica:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonKMSEncryption",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    },
    {
      "Sid": "DenyWrongKMSKey",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption-aws-kms-key-id": "arn:aws:kms:us-east-1:123456789012:key/your-key-id"
        }
      }
    }
  ]
}

La primera instrucción prohíbe cualquier carga que no utilice SSE-KMS. La segunda instrucción restringe aún más las cargas para que solo utilicen su ARN CMK específico, evitando que alguien utilice accidentalmente la clave predeterminada de aws/s3 o una CMK diferente en su bucket de datos regulado.

Comparación completa de todas las opciones de cifrado S3

La siguiente tabla resume todas las opciones de cifrado de S3 en las dimensiones que importan para una decisión de seguridad y cumplimiento:

Opción	Cifrado en reposo	Cifrado en tránsito	Clave gestionada por	CloudTrail por objeto	Control de llaves independiente	AWS ve texto plano
SSE-S3	Sí (AES-256-GCM)	No (política aparte)	AWS	No	No	Sí:
SSE-KMS (clave gestionada por AWS)	Sí (AES-256-GCM)	No (política aparte)	AWS	Sí:	No	Sí:
SSE-KMS (CMK gestionado por el cliente)	Sí (AES-256-GCM)	No (política aparte)	Cliente (en KMS)	Sí:	Sí:	Sí:
SSE-C	Sí (AES-256-GCM)	No (política aparte)	Cliente (fuera de AWS)	No	Sí:	Sí (durante la operación)
CMK del lado del cliente + KMS	Sí (AES-256-GCM)	No (política aparte)	Cliente (clave en KMS)	Sí (solo envoltorio para llave)	Sí:	No
Clave del lado del cliente + autogestionada	Sí (AES-256-GCM)	No (política aparte)	Cliente (totalmente ajeno a AWS)	No	Sí:	No
Política de transporte seguro de AWS	No	Sí (TLS)	AWS (certificado TLS)	No	No	N/A

Arquitectura de cifrado híbrida y multi-nube para S3

Las organizaciones que utilizan S3 junto con Azure Blob Storage, Google Cloud Storage o almacenamiento de objetos local se enfrentan a un desafío clave en cuanto a la coherencia de la gestión: cada plataforma en la nube tiene su propio servicio nativo de gestión de claves, y gestionar inventarios de claves, políticas de rotación y registros de auditoría independientes entre proveedores multiplica la complejidad operativa y el esfuerzo de cumplimiento.

Existen tres patrones que abordan de forma consistente el cifrado S3 en múltiples nubes:

• Solución nativa en la nube por nube con CLM unificado: Utilice SSE-KMS para S3, claves administradas por Azure para Blob y Cloud KMS para GCS, pero implemente una plataforma de administración del ciclo de vida de certificados y claves que agregue el inventario de claves, supervise el cumplimiento de la rotación y proporcione un registro de auditoría unificado en todos los proveedores de la nube. Esto preserva el rendimiento nativo a la vez que proporciona visibilidad de la gobernanza.
• BYOK centralizado en cada nube: Genere todo el material clave desde un único sistema externo de gestión de claves. Importe las claves derivadas a AWS KMS (para SSE-KMS BYOK), Azure Key Vault (para Azure BYOK) y GCP Cloud KMS (para GCP BYOK). Todas las nubes utilizan claves que se remontan a la misma fuente autorizada. La rotación de claves y la política de ciclo de vida se gestionan de forma centralizada.
• Cifrado del lado del cliente con una clave maestra compartida: Cifra todos los datos del lado del cliente antes de subirlos, utilizando la misma clave maestra independientemente de la nube donde se almacenen. El proveedor de la nube queda totalmente excluido de la jerarquía de claves. Este es el modelo de soberanía multinube más robusto, pero requiere que tu aplicación gestione todas las operaciones criptográficas y que tu sistema externo de gestión de claves tenga alta disponibilidad para cada operación de lectura y escritura.

Para las organizaciones que gestionan claves de cifrado en S3 y otras fuentes en la nube y locales, CBOM Secure de Encryption Consulting ofrece detección e inventario automatizados de activos criptográficos, incluyendo claves KMS, configuraciones de cifrado de buckets de S3 e inventario de certificados en formato CycloneDX para la elaboración de informes de cumplimiento. Nuestros servicios de asesoramiento en protección de datos en la nube diseñan la arquitectura de control de claves adecuada para sus requisitos específicos de cumplimiento en entornos multinube.

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 cifrado S3 que cumplen con HIPAA, PCI DSS, FedRAMP, NIST 800-53 y otros marcos de cumplimiento normativo.

• Aviso sobre la protección de datos en la nube: Evaluamos su configuración actual de cifrado S3, identificamos deficiencias (cubos sin cifrar, políticas de cubo faltantes, SSE-S3 donde se requiere SSE-KMS, eventos de datos de CloudTrail faltantes) y diseñamos la arquitectura objetivo, incluyendo el modelo de control de claves, el modelo IAM, la aplicación de políticas de cubo y el cronograma de rotación. Consulte nuestra servicios de asesoramiento.
• HSM como servicio: Para escenarios BYOK y de cifrado del lado del cliente donde su material de clave debe generarse en un HSM validado por FIPS fuera de AWS, Encryption Consulting HSM como servicio Proporciona una infraestructura HSM dedicada con certificación FIPS 140-2 de nivel 3 para la generación de claves, con integración en los flujos de trabajo de importación de claves de AWS KMS.
• CBOM Seguro: Los entornos de AWS con muchos buckets de S3 a menudo tienen configuraciones de cifrado inconsistentes. Encryption Consulting's CBOM seguro Descubre e inventaría todas las configuraciones de cifrado de buckets de S3, las configuraciones de claves KMS y las políticas de acceso en todas sus cuentas de AWS, generando una lista de materiales criptográficos en formato CycloneDX que identifica deficiencias y admite paquetes de evidencia de auditoría.
• Infraestructura de clave pública como servicio: Para las organizaciones que necesitan certificados PKI privados para la autenticación de clientes S3 (TLS mutuo a puntos de acceso S3 o S3 a través de puntos finales VPC), Encryption Consulting ofrece PKI como servicio Proporciona una CA privada gestionada con administración automatizada del ciclo de vida de los certificados mediante ACME.
• 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. Si bien AES-256-GCM utilizado por S3 se considera resistente a la computación cuántica, la infraestructura de gestión de claves (encapsulación de claves KMS, conexiones TLS a los puntos finales de S3) deberá migrar a algoritmos post-cuánticos. Preparación para PQC El servicio compara su postura criptográfica completa de S3 con el cronograma de migración.

Para hablar sobre su arquitectura de cifrado S3, póngase en contacto con Encryption Consulting.

Conclusión

AWS S3 ahora cifra todos los objetos nuevos de forma predeterminada, lo que elimina el riesgo de almacenar accidentalmente datos sin cifrar. Sin embargo, el cifrado predeterminado con SSE-S3 no proporciona un registro de auditoría, ni control de claves independiente, ni la posibilidad de revocar el acceso a los datos sin eliminarlos. Para cualquier carga de trabajo regulada, SSE-KMS con una clave maestra de cliente (CMK) gestionada por el cliente es la configuración mínima adecuada: añade un registro de auditoría por objeto, permite deshabilitar la clave para revocar instantáneamente la capacidad de descifrado de S3 y admite BYOK si se necesita material de clave generado por el cliente.

El cifrado del lado del cliente es la opción correcta cuando el modelo de amenazas exige que AWS nunca tenga acceso al texto sin cifrar, incluso bajo coacción legal. Si bien aumenta la complejidad de la aplicación, proporciona la posición de soberanía de datos más sólida disponible en cualquier entorno de nube.

La decisión sobre el control de claves, el diseño de IAM, la aplicación de la política de buckets y la configuración de CloudTrail son tan importantes como el método de cifrado en sí. El cifrado sin los controles correspondientes es una mera formalidad: se puede afirmar que los datos están cifrados, pero no se puede precisar quién los descifró, cuándo ni si estaban autorizados para hacerlo.

Preguntas frecuentes

¿Cuál es la diferencia entre SSE-S3, SSE-KMS y SSE-C en Amazon S3?

SSE-S3 permite que AWS genere, administre y rote automáticamente todas las claves de cifrado sin visibilidad ni control por parte del cliente. SSE-KMS utiliza AWS KMS y proporciona un registro de auditoría de CloudTrail para cada operación de cifrado y descifrado, con la opción de elegir entre claves administradas por AWS o por el cliente. SSE-C requiere que se proporcione una clave AES de 256 bits en cada encabezado de solicitud; S3 la utiliza y la descarta inmediatamente, almacenando únicamente una huella digital HMAC. La diferencia clave radica en la profundidad y el control de la auditoría: SSE-S3 no ofrece ninguno de los dos; SSE-KMS ofrece ambos; SSE-C ofrece control sin un registro de auditoría de KMS.

¿Qué es el cifrado del lado del cliente en Amazon S3 y cuándo debo usarlo?

El cifrado del lado del cliente implica cifrar los datos antes de subirlos a S3, de modo que S3 solo almacena texto cifrado y AWS nunca gestiona el texto sin cifrar. Úselo cuando las normativas exijan el cifrado antes de que los datos salgan de su entorno, cuando su modelo de amenazas incluya a AWS como un posible punto de acceso (modelo HYOK) o cuando necesite almacenamiento de confianza cero donde ningún proveedor de la nube pueda acceder a sus datos. La contrapartida es la responsabilidad total de la aplicación en la gestión, rotación y distribución de claves a todos los sistemas que necesiten acceso a los objetos.

¿AWS S3 cifra los datos de forma predeterminada?

Sí. Desde enero de 2023, Amazon S3 aplica automáticamente SSE-S3 (AES-256-GCM) a todos los objetos nuevos en cualquier bucket de S3, incluso sin configuración explícita. Los objetos existentes que ya se encuentran en un bucket no se cifran retroactivamente. Puede cambiar la configuración predeterminada a SSE-KMS a nivel de bucket para habilitar un registro de auditoría de CloudTrail y el control de claves de cliente.

¿Qué es BYOK para Amazon S3 y cómo funciona?

BYOK (Bring Your Own Key) para S3 significa que usted genera el material de clave en su propio HSM o sistema de gestión de claves, lo importa a AWS KMS como una clave gestionada por el cliente con el material de clave importado y configura SSE-KMS en su bucket de S3 para usar esa CMK. AWS KMS usa el material importado para generar las claves de cifrado de datos que protegen sus objetos. Usted conserva el material de clave original y puede eliminarlo de KMS para evitar de inmediato cualquier descifrado posterior sin la intervención del soporte de AWS.

¿Cómo puedo aplicar el cifrado a todos los objetos de S3 mediante una política de bucket?

Agregue una instrucción Deny en la política de su bucket de S3 dirigida a las solicitudes s3:PutObject donde el encabezado s3:x-amz-server-side-encryption no esté configurado como aws:kms (para SSE-KMS) o AES256 (para SSE-S3). Agregue una segunda instrucción Deny con la condición aws:SecureTransport establecida en falso para bloquear cualquier solicitud HTTP (sin TLS). Estas dos condiciones, en conjunto, impiden tanto las cargas no cifradas como las conexiones no cifradas al bucket.

¿Cómo aparece el cifrado de AWS S3 en los registros de auditoría de CloudTrail?

SSE-KMS genera un evento GenerateDataKey de CloudTrail en cada PutObject y un evento Decrypt en cada GetObject. Cada evento incluye el ARN de la clave KMS, la entidad principal de IAM solicitante, el bucket de S3 y la clave del objeto, la IP de origen y una marca de tiempo. SSE-S3 y SSE-C no generan eventos KMS. Habilite los eventos de datos de S3 en CloudTrail por separado de los eventos de administración, ya que las llamadas a la API a nivel de objeto de S3 no se registran en los registros de eventos de administración de forma predeterminada.