saltar al contenido
sec/atlas
volver al mapa
técnica
etapa: proteger
4 min de lectura

KMS & crypto - claves y envelopes

El cifrado en la nube empieza en el KMS: quien tiene acceso a la clave decide qué está 'cifrado'. Sin gobernar las claves, 'encrypted at rest' es solo un checkbox en la consola.

AWS KMSHashiCorp Vault TransitGoogle Cloud KMSAzure Key Vault

Qué es

KMS () es el componente que crea, almacena, usa y revoca claves criptográficas sin exponer el secreto a tu código. La aplicación le pide al KMS 'cifra esto' o 'descifra esto', y la clave nunca sale del servicio de claves. El resto del sistema usa el ciphertext.

Este detalle importa porque la mayor parte de las fallas de cifrado ocurre en el plano equivocado: claves en variables de entorno, claves commiteadas en Git, claves en archivos de config. Sacar la clave del camino de la aplicación es lo que hace el KMS.

Por qué 'encrypted at rest' es solo el comienzo

Los storage services ya vienen con cifrado en reposo habilitado por defecto (S3 SSE, EBS encryption, RDS storage encryption). Eso protege el disco contra la remoción física, pero no protege contra quien tiene acceso a la API: alguien con s3:GetObject lee el objeto cifrado y le pide al KMS que lo descifre.

Si la key policy permite un uso demasiado amplio, cualquier identidad que ya tenga permiso de lectura pasa a tener acceso efectivo al plaintext. La pregunta correcta no es '¿está cifrado?', sino '¿quién puede pedirle al KMS que descifre esto?'.

Envelope encryption: una clave protege a otra clave

Enviar un archivo grande completo al KMS en cada cifrado es caro y lento. La solución estándar es la : el KMS genera una data key simétrica, el payload se cifra localmente con AES, y la data key se cifra con la master key del KMS. El resultado viaja junto con el dato.

En el flujo de abajo, el cliente recibe el plaintext y el ciphertext de la data key, cifra el documento con la clave local, y descarta el plaintext. Solo el ciphertext de la data key queda persistido junto al archivo.

envelope.py - ejemplo conceptualpython
import boto3
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

kms = boto3.client("kms")
KEY_ID = "arn:aws:kms:us-east-1:111122223333:key/abcd1234-..."

def envelope_encrypt(plaintext: bytes, kms_key_id: str = KEY_ID):
    # 1. KMS devuelve una data key en plaintext + la misma clave cifrada
    resp = kms.generate_data_key(KeyId=kms_key_id, KeySpec="AES_256")
    plaintext_key = resp["Plaintext"]
    encrypted_key = resp["CiphertextBlob"]

    # 2. cifra el payload localmente, sin enviarlo nunca al KMS
    nonce = b"\x00" * 12
    ciphertext_body = AESGCM(plaintext_key).encrypt(nonce, plaintext, None)

    # 3. descarta el plaintext de la data key, solo el ciphertext sigue con el archivo
    del plaintext_key
    return {"encrypted_key": encrypted_key, "ciphertext_body": ciphertext_body, "nonce": nonce}

Key policy: quién usa la clave

La key policy es el documento que rige una clave KMS. Decide quién puede usar la clave, en qué operaciones y bajo qué condiciones. El default para claves generadas por AWS es liberal: la cuenta root puede todo, pero si nadie lo restringe, cualquier principal con kms:* en todo el entorno pasa.

Una buena key policy separa el uso administrativo (crear, rotar, eliminar) del uso criptográfico (cifrar, descifrar). El equipo de aplicación solo recibe el segundo mediante grants limitados a un patrón de ARN de bucket o tabla.

key-policy.json - separada por roljson
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AdminsManageKey",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/SecTeam" },
      "Action": [
        "kms:Create*", "kms:Describe*", "kms:Enable*", "kms:Disable*",
        "kms:ScheduleKeyDeletion", "kms:RotateKeyOnDemand"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AppEncryptsOnly",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/app-frontend" },
      "Action": [
        "kms:Encrypt", "kms:Decrypt", "kms:GenerateDataKey", "kms:DescribeKey"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:ViaService": "s3.us-east-1.amazonaws.com"
        }
      }
    }
  ]
}

Rotación y revocación

La rotación automática anual viene habilitada por defecto en las claves KMS y casi no cuesta usarla: la clave antigua sigue siendo válida para descifrar datos antiguos, y la nueva cifra los siguientes. Cuando lo necesitas, fuerzas una rotación manual tras sospecha de uso indebido.

La revocación es distinta: o deshabilitas la clave (bloquea el descifrado) o programas su eliminación. Bloquear la clave rompe aplicaciones legítimas que intentan leer datos antiguos. De ahí la regla práctica: monitorear el uso, separar claves por sensibilidad, y nunca mezclar una clave de producción con una de prueba en el mismo recurso.

Dónde aparece en el día a día

  • storage estándar: S3, EBS, RDS, DynamoDB y similares ya cifran con KMS, pero la key policy debe decir quién puede invocar el descifrado
  • envelope encryption: los payloads sensibles en una cola o blob pasan por el patrón de clave local + data key cifrada
  • BYOK/HYOK: las empresas reguladas importan su propia clave (Bring Your Own Key) o mantienen la clave en un HSM externo (Hold Your Own Key)
  • auditoría: cada llamada a GenerateDataKey, Encrypt o Decrypt se vuelve un evento en CloudTrail con ARN del principal y

Puntos fuertes

  • la clave nunca toca la aplicación: incluso un atacante con RCE en el servidor no puede extraer la clave del KMS
  • rotación centralizada: rotar en un lugar migra todo el árbol de data keys en uso
  • audit trail nativo: cada uso se firma y se registra con identidad, recurso y timestamp

Limitaciones

  • costo por llamada: KMS cobra por operación, y un envelope mal diseñado se vuelve una factura pesada por request
  • latencia por hop: cada Encrypt/Decrypt añade un viaje al KMS, y los caminos sensibles a la latencia necesitan una clave en caché local
  • BYOK/HYOK añade complejidad operativa: HSM en dos regiones, rotación manual, y procedimientos de disaster recovery separados
KMSkey management serviceServicio administrado que crea, almacena y controla el uso de claves criptográficas. La aplicación rara vez toca la clave maestra: le pide al KMS que cifre o descifre, y el proveedor registra cada uso en un log auditable. Sin KMS, la clave termina en disco y se vuelve un objetivo.ver en el glosario →Envelope encryptionPatrón de dos capas: una clave de datos (DEK) cifra el payload, y una clave del KMS (KEK) cifra la DEK. La aplicación guarda la DEK cifrada junto a los datos, y solo llama al KMS para desenvolver la DEK cuando necesita usarla. Reduce las llamadas al KMS y limita la exposición de la clave maestra.ver en el glosario →IAMidentity and access managementEl conjunto de políticas, roles y credenciales que dice quién es cada humano, servicio o workload, y qué puede hacer cada uno. En la nube, IAM se convirtió en el nuevo perímetro: el borde de red se volvió poroso, así que la identidad carga la autorización.ver en el glosario →Correlation idrequest idUn id único asociado a una solicitud y a cada línea de log que genera, que se muestra al usuario en los mensajes de error para que soporte encuentre los detalles sin filtrarlos.ver en el glosario →

conexiones en el mapa

actualizado el 14/10/2026 · fuentes para profundizar · reportar un error

en otros dominios

Estudia antes

Desbloquea

pon a prueba lo que entendiste

Cargando preguntas…