Encryption, Key Management and Data Protection

Resumen

El cifrado convierte un dato en algo inútil para quien lo intercepta o lo sustrae sin autorización. En Google Cloud es una protección por defecto: el contenido almacenado se cifra en reposo y las comunicaciones se cifran en tránsito sin que el cliente tenga que activar nada. La decisión que realmente importa no es cifrar o no cifrar, sino quién controla las claves, dónde viven, quién puede usarlas y qué evidencia queda de cada uso. Esa decisión separa el cifrado gestionado por Google del cifrado con claves gestionadas por el cliente (CMEK), del cifrado con claves aportadas por el cliente (CSEK) y del cifrado con claves externas (Cloud EKM).

Este tema explica los tres estados del dato —en reposo, en tránsito y en uso—, la jerarquía de claves y el cifrado de sobre (envelope encryption), los servicios que materializan el control —Cloud KMS, Cloud HSM, Cloud EKM y Secret Manager— y las consecuencias de negocio de cada elección: separación de funciones, capacidad de revocar acceso criptográficamente, requisitos regulatorios, continuidad operativa y coste. También distingue el cifrado de datos del almacenamiento de secretos: una clave criptográfica y una contraseña de aplicación son activos distintos y se gobiernan con herramientas distintas.

Para un Digital Leader, el cifrado no es un detalle de implementación. Es la respuesta a preguntas que aparecen en una due diligence, en un contrato con un cliente regulado o en una auditoría: ¿dónde están las claves?, ¿quién puede usarlas?, ¿qué pasa si se revoca el acceso?, ¿cómo se demuestra que el dato estuvo protegido? La respuesta correcta no siempre es usar CMEK; la respuesta correcta es elegir el nivel de control que el riesgo y la regulación exigen, y poder operarlo sin romper el servicio.

Objetivos de Aprendizaje

Al terminar este contenido, serás capaz de:

Diferenciar el cifrado en reposo, en tránsito y en uso, y asociar cada estado con los controles y servicios que lo protegen.
Explicar el cifrado por defecto de Google Cloud y qué significa que el cliente no tenga que gestionar claves para obtenerlo.
Describir el cifrado de sobre (envelope encryption) y la relación entre data encryption keys (DEK) y key encryption keys (KEK).
Comparar claves gestionadas por Google, CMEK, CSEK y claves externas (Cloud EKM) según control, esfuerzo operativo y caso de uso.
Explicar qué aporta Cloud KMS: key rings, keys, versiones, rotación, ubicaciones, IAM y auditoría.
Distinguir claves software de claves respaldadas por hardware en Cloud HSM y explicar el valor de cumplimiento de un HSM.
Justificar el uso de Secret Manager para secretos de aplicación y diferenciarlo de Cloud KMS.
Explicar cómo Confidential Computing protege los datos en uso y qué límites tiene esa protección.
Diseñar controles de separación de funciones y mínimo privilegio sobre claves, incluida la destrucción criptográfica (crypto-shredding).
Evaluar, ante un requisito regulatorio o contractual, qué nivel de control de claves es proporcionado y cuál sería excesivo.

Contenido Principal

Subtema 1: Los tres estados del dato y la protección por defecto

Un dato puede encontrarse en tres estados, y cada uno tiene una superficie de exposición distinta. En reposo (at rest) está almacenado en un disco, un bucket, una base de datos o una cinta de backup. En tránsito (in transit) se mueve entre un cliente y un servicio, entre dos servicios o entre regiones. En uso (in use) está en memoria o en la CPU mientras una aplicación lo procesa. La confidencialidad depende de que los tres estados estén cubiertos; cifrar solo el disco y dejar la base de datos accesible por una credencial robada, o cifrar la red y dejar los datos en claro en memoria, deja huecos que un atacante puede explotar.

Google Cloud aplica cifrado en reposo de forma predeterminada a todo el contenido del cliente, utilizando AES-256 en la capa de almacenamiento, sin configuración ni coste adicional. También cifra el tráfico entre sus instalaciones y ofrece TLS en los endpoints públicos. Esa protección por defecto cubre el requisito básico y libera al cliente de construir su propio esquema criptográfico, pero no le da control sobre las claves. Para muchos casos de uso es suficiente; para otros, la regulación o el contrato exigen que el cliente sea quien controle la clave, pueda revocarla o pueda demostrar que Google no la usa sin justificación.

Estado del dato	Dónde vive	Control principal de Google Cloud	Pregunta de negocio
En reposo	Discos, buckets, bases de datos, backups	Cifrado por defecto AES-256, CMEK, CSEK, Cloud EKM	¿Quién puede descifrar si pierdo el control de la cuenta?
En tránsito	Red pública, red de Google, entre servicios	TLS, cifrado de la red troncal, mTLS en mallas	¿El dato viaja protegido de extremo a extremo?
En uso	Memoria y CPU del servidor	Confidential Computing (Confidential VMs, Confidential GKE Nodes)	¿El proveedor o un operador privilegiado puede ver el dato mientras se procesa?

La elección del control debe seguir al riesgo, no al revés. Un sitio web de marketing con datos públicos no necesita CMEK; un expediente clínico, un historial de transacciones financieras o un dataset de recursos humanos sí pueden necesitar claves controladas por el cliente, separación de funciones y evidencia de uso. El error de gobierno es aplicar el control más costoso a todo o, en el extremo opuesto, asumir que el cifrado por defecto resuelve un requisito regulatorio que exige control de claves.

Subtema 2: Cifrado de sobre y jerarquía de claves

Google Cloud no cifra cada objeto directamente con una única clave maestra. Utiliza envelope encryption: una data encryption key (DEK) cifra el dato, y una key encryption key (KEK) cifra la DEK. La DEK cifrada se almacena junto al dato; para leerlo, el servicio pide a Cloud KMS que descifre la DEK con la KEK, y solo entonces descifra el contenido. Esta separación permite rotar la KEK sin volver a cifrar todos los datos, delegar el uso de la clave a un servicio y auditar cada operación criptográfica en un punto central.

La jerarquía tiene implicaciones de negocio claras. Si el cliente controla la KEK en Cloud KMS, puede revocar el acceso del servicio a esa clave y, con ello, dejar los datos cifrados e inutilizables aunque el almacenamiento siga existiendo. Esa es la base del crypto-shredding: destruir la clave para volver inaccesible el dato sin recorrer y borrar cada objeto. También es la base de la separación de funciones: el equipo que administra el bucket no tiene por qué ser el que administra la clave, y el equipo que usa la clave no tiene por qué poder exportarla.

Nivel de control	Quién crea y custodia la clave	Quién puede revocar el acceso	Esfuerzo operativo	Caso típico
Cifrado por defecto	Google	Google, dentro del servicio	Ninguno	Datos sin requisito específico de control de claves
CMEK	Cliente, en Cloud KMS	Cliente, deshabilitando o destruyendo la clave	Medio: IAM, rotación, ubicación, monitorización	Regulación o contrato que exige control de claves
CSEK	Cliente, fuera de Google	Cliente, dejando de aportar la clave	Alto: el cliente custodia y aporta el material	Casos heredados o requisitos muy específicos
Cloud EKM	Cliente, en un key manager externo	Cliente, en su key manager	Alto: integración, latencia y disponibilidad externas	Soberanía o política que exige claves fuera de Google

CMEK no significa que el cliente vea ni exporte la clave. Significa que la clave vive en un proyecto de Cloud KMS que el cliente controla, que las operaciones quedan registradas y que el cliente decide la ubicación, la rotación y el ciclo de vida. Es el nivel que suele responder a la pregunta de auditoría ¿quién controla la clave? sin obligar a construir un sistema criptográfico propio. CSEK va un paso más allá: el cliente aporta el material de la clave en cada operación y Google no lo almacena; su coste operativo y su riesgo de pérdida son mayores. Cloud EKM mantiene la clave fuera de Google Cloud y la usa a través de un proveedor externo compatible, lo que puede satisfacer requisitos de soberanía pero añade dependencia de disponibilidad y latencia del key manager externo.

Subtema 3: Cloud KMS, versiones y rotación

Cloud KMS es el servicio gestionado para crear, usar, rotar y destruir claves criptográficas. Su unidad de organización es el key ring, un contenedor lógico de claves con una ubicación; dentro se crean keys, y cada key tiene versiones con un propósito (por ejemplo, ENCRYPT_DECRYPT o ASYMMETRIC_SIGN). Las versiones permiten rotar el material sin cambiar el identificador lógico de la clave; los datos antiguos siguen descifrándose con la versión que se usó para cifrarlos, y los nuevos usos emplean la versión primaria. La rotación automática es una política de la clave, no una operación que el cliente deba ejecutar a mano.

La ubicación importa. Un key ring se crea en una región o multirregión concreta, y las claves no se replican automáticamente entre ubicaciones. Elegir la ubicación de la clave es una decisión de residencia y de latencia: debe alinearse con la ubicación de los datos que protege y con los requisitos regulatorios de la organización. Una clave en una región distinta de los datos puede funcionar, pero complica la historia de residencia que se presenta a un auditor.

IAM sobre Cloud KMS debe diseñarse con mínimo privilegio y separación de funciones. Los roles separan a quien administra el key ring, a quien usa la clave para cifrar o descifrar y a quien audita. El rol roles/cloudkms.cryptoKeyEncrypterDecrypter permite usar la clave sin administrarla; el rol de administrador permite crear y configurar claves. Dar ambos al mismo equipo elimina la separación de funciones que justifica CMEK. Cloud Audit Logs registra las operaciones administrativas y, cuando se configura, los accesos a datos; esa evidencia es lo que permite demostrar quién usó la clave y cuándo.

La rotación no es una cura universal. Rotar reduce el volumen de datos protegidos por una versión comprometida y cumple políticas, pero no invalida automáticamente el acceso a datos antiguos ni elimina una clave filtrada. Si una clave se compromete, la respuesta incluye revocar permisos, rotar, investigar el uso y, si corresponde, destruir la versión o la clave. La rotación debe probarse: una política que rota claves sin que las aplicaciones sepan usar la versión nueva es una interrupción programada.

Subtema 4: Cloud HSM, Cloud EKM y claves externas

Cloud KMS ofrece claves software y claves respaldadas por hardware. Las claves software son adecuadas para la mayoría de los casos y usan módulos criptográficos validados. Cuando una regulación exige que el material de la clave nunca salga de un módulo de hardware, se usa Cloud HSM, que aloja claves en un clúster de HSMs certificados FIPS 140-2 Level 3 y mantiene la interfaz de Cloud KMS. El cliente conserva el control de la política de la clave, pero Google gestiona el clúster, el escalado y el parcheo. Para requisitos de aislamiento criptográfico más estrictos existen instancias de HSM de un solo inquilino, con administración por quórum y claves de seguridad fuera de Google Cloud.

Cloud EKM permite usar claves que residen en un key manager externo compatible. Google Cloud envía la operación criptográfica al sistema externo y no almacena el material de la clave. Es la opción cuando la política exige que la clave permanezca bajo el control físico o legal de un tercero o del propio cliente, pero introduce una dependencia crítica: si el key manager externo no está disponible, las operaciones que dependen de esa clave fallan. La decisión no es solo de seguridad; es de continuidad de negocio y de arquitectura de proveedores.

Servicio	Dónde está el material	Certificación o control	Cuándo elegirlo	Riesgo principal
Cloud KMS software	En Google Cloud, gestionado por el servicio	Módulos validados, control lógico	Mayoría de casos con CMEK	Configuración de IAM demasiado amplia
Cloud HSM	En HSMs de Google Cloud	FIPS 140-2 Level 3	Regulación que exige hardware dedicado	Coste y complejidad de planificación
Cloud HSM de un solo inquilino	En particiones dedicadas	Aislamiento y administración por quórum	Requisitos de aislamiento criptográfico	Operación más compleja
Cloud EKM	En un key manager externo	Depende del proveedor externo	Soberanía o claves fuera de Google	Disponibilidad del proveedor externo

Subtema 5: Secret Manager y la diferencia entre clave y secreto

Una clave criptográfica no es lo mismo que un secreto de aplicación. Una clave en Cloud KMS se usa para cifrar, descifrar o firmar; el cliente no necesita conocer su material y, de hecho, no puede exportarlo en la mayoría de las configuraciones. Un secreto —una contraseña de base de datos, un token de API, una clave privada de un proveedor externo— es un valor que la aplicación necesita leer para autenticarse. Mezclar ambos conceptos lleva a dos errores opuestos: guardar secretos en variables de entorno o en el código, o intentar usar Cloud KMS como almacén de contraseñas.

Secret Manager almacena secretos versionados, aplica IAM por secreto, registra accesos en Cloud Audit Logs y permite rotar versiones sin redeploy. La aplicación con el rol adecuado accede a la versión habilitada; los usuarios no ven el valor en la consola si no tienen permiso. El patrón recomendado es que la aplicación obtenga el secreto en tiempo de ejecución, no que lo incruste en la imagen del contenedor. Para secretos que protegen datos en reposo dentro de una aplicación, la combinación correcta es Secret Manager para la credencial y Cloud KMS para la clave que cifra el dato; cada uno cumple una función distinta.

Necesidad	Servicio adecuado	Por qué
Cifrar un bucket o una base de datos con una clave propia	Cloud KMS con CMEK	Control del ciclo de vida y auditoría de uso de la clave
Custodiar una contraseña o un token que la aplicación debe leer	Secret Manager	Versionado, IAM granular y auditoría de acceso al valor
Cumplir un requisito de clave en hardware	Cloud HSM	Material protegido en HSM certificados
Mantener la clave fuera de Google Cloud	Cloud EKM	El material reside en un key manager externo
Proteger datos mientras se procesan	Confidential Computing	Aislamiento de la memoria en uso

Subtema 6: Datos en uso y Confidential Computing

El cifrado en reposo y en tránsito no protege el dato cuando la aplicación lo descifra para procesarlo: en ese momento el dato está en memoria y, en un entorno virtualizado tradicional, el hipervisor o un operador con privilegios podría inspeccionarlo. Confidential Computing reduce esa superficie con Confidential VMs y Confidential GKE Nodes, que usan hardware de cifrado de memoria para aislar el dato en uso incluso del proveedor de la infraestructura. La promesa de negocio es concreta: permite procesar datos sensibles en una nube pública con una garantía adicional de que el operador no puede leerlos en memoria.

La protección tiene límites que conviene declarar. No sustituye IAM, no corrige una aplicación que escribe el dato en un log, no impide que el cliente con acceso legítimo lo vea y no cubre todos los servicios ni todos los modelos de máquina. Es una capa más de defensa en profundidad, no una autorización para relajar el resto de controles. Para un examen, la asociación correcta es confidentiality of data in use, y la diferencia frente a CMEK es que esta última protege el dato en reposo, no en memoria.

Subtema 7: Gobierno, evidencia y errores de diseño

Un programa de cifrado se gobierna con tres decisiones: qué datos se protegen, con qué nivel de control y quién puede operar las claves. La clasificación del dato define el nivel; la regulación y el contrato definen el mínimo; el riesgo de negocio define el resto. A partir de ahí se aplican controles organizativos: separación entre el equipo que administra datos y el que administra claves, revisión periódica de permisos, rotación probada, monitorización de fallos de descifrado y planes de continuidad para la indisponibilidad de una clave o de un key manager externo.

La evidencia es tan importante como el control. Cloud Audit Logs, los registros de acceso a Secret Manager y los informes de cumplimiento permiten responder a un auditor con hechos. Una organización que dice usar CMEK pero no puede demostrar qué claves protegen qué datos, quién tiene el rol de uso y cuándo se rotaron, tiene una historia incompleta. El cifrado no es un checkbox: es una cadena de custodia de la clave que debe poder recorrerse de extremo a extremo.

Ejemplo Práctico

El siguiente recorrido muestra el ciclo mínimo de una clave CMEK y de un secreto de aplicación. Los nombres son ilustrativos y deben sustituirse por los del proyecto.

# Crear un key ring regional y una clave simétrica con rotación automática
gcloud kms keyrings create cdl-keyring --location=europe-west1
gcloud kms keys create cdl-data-key \
  --location=europe-west1 \
  --keyring=cdl-keyring \
  --purpose=encryption \
  --rotation-period=90d \
  --next-rotation-time=2027-01-19T00:00:00Z

# Conceder solo el uso criptográfico a la cuenta de servicio de la aplicación
gcloud kms keys add-iam-policy-binding cdl-data-key \
  --location=europe-west1 \
  --keyring=cdl-keyring \
  --member=serviceAccount:app-data@mi-proyecto.iam.gserviceaccount.com \
  --role=roles/cloudkms.cryptoKeyEncrypterDecrypter

# Guardar y leer un secreto versionado
printf 'contra-ejemplo' | gcloud secrets create db-password --data-file=-
gcloud secrets versions access latest --secret=db-password

# Auditar el uso administrativo de claves
gcloud logging read 'resource.type=cloudkms_cryptokey' --limit=20

La lectura de negocio es que la clave y el secreto quedan separados, el permiso de uso no concede administración y cada acceso deja un rastro. Si la aplicación se despliega en otro proyecto, se le concede el rol sobre la clave, no la posesión del key ring; si se revoca el acceso, el dato sigue cifrado y deja de ser descifrable por esa identidad.

Temas relacionados: Security and Trust Principles in Google Cloud, Identity, Access Management and Compliance, Network Security, VPC and Perimeter Defense, Compliance, Data Sovereignty and Data Residency.

Errores Comunes

Error: Asumir que el cifrado por defecto de Google Cloud no existe o que hay que activarlo manualmente. → Solución: Partir de que todo el contenido en reposo se cifra por defecto con AES-256; la decisión adicional es si se necesita control de claves (CMEK), claves en hardware (Cloud HSM) o claves externas (Cloud EKM).
Error: Creer que CMEK permite al cliente ver o exportar la clave. → Solución: CMEK da control sobre el ciclo de vida y el uso, no acceso al material. Si se necesita que el material resida fuera de Google Cloud, la opción es Cloud EKM, con sus dependencias operativas.
Error: Usar Cloud KMS para guardar contraseñas y tokens de aplicación. → Solución: Usar Secret Manager para secretos que la aplicación debe leer, y Cloud KMS para claves que cifran datos. Son activos distintos con ciclos de vida y controles de acceso distintos.
Error: Dar el rol de administrador de claves al mismo equipo que las usa en producción. → Solución: Separar la administración del key ring del uso criptográfico; el equipo de aplicación recibe solo el rol de cifrado y descifrado, y la administración queda en un equipo de seguridad o plataforma.
Error: Rotar claves sin probar el flujo de descifrado ni la disponibilidad del key manager externo. → Solución: Probar la rotación en un entorno representativo, verificar que las versiones antiguas siguen disponibles para el descifrado y documentar el plan de continuidad si Cloud EKM o el HSM no responden.

Puntos para el Examen

🎯 Punto clave 1: Google Cloud cifra por defecto los datos en reposo y en tránsito. La pregunta del examen no suele ser si hay cifrado, sino qué nivel de control de claves corresponde a un escenario.

🎯 Punto clave 2: CMEK vive en Cloud KMS y lo controla el cliente; CSEK lo aporta el cliente y Google no lo almacena; Cloud EKM mantiene la clave en un key manager externo. Esa es la progresión de control y de dependencia operativa.

🎯 Punto clave 3: Cloud HSM aporta claves en hardware con certificación FIPS 140-2 Level 3; Cloud KMS software es suficiente para la mayoría de los casos. El HSM se elige por requisito regulatorio o de aislamiento, no por moda.

🎯 Punto clave 4: Secret Manager no es un KMS. Gestiona secretos versionados que la aplicación debe leer; Cloud KMS gestiona claves criptográficas que no se exportan.

🎯 Punto clave 5: Confidential VMs y Confidential GKE Nodes protegen datos en uso. No reemplazan IAM, cifrado en reposo ni una aplicación bien diseñada; añaden una capa para el estado en memoria.

Recursos Externos

Data encryption — Visión general del cifrado en reposo, en tránsito y en uso en Google Cloud.
Cloud Key Management Service overview — Key rings, claves, versiones, CMEK, Cloud HSM y Cloud EKM.
Customer-managed encryption keys (CMEK) — Qué controla y qué no controla el cliente con CMEK.
Envelope encryption — Relación entre DEK y KEK y funcionamiento del cifrado de sobre.
Secret Manager documentation — Gestión de secretos, versiones, IAM y auditoría.
Confidential Computing — Protección de datos en uso con Confidential VMs y Confidential GKE Nodes.

Autoevaluación Rápida

Pregunta: Una auditoría exige que la organización controle las claves que protegen sus datos en BigQuery, pero no exige que el material salga de Google Cloud. ¿Qué opción es proporcionada? Respuesta: CMEK con Cloud KMS. El cliente crea y controla la clave en su proyecto, decide ubicación y rotación, y puede revocar el acceso; el material sigue custodiado por el servicio, que es suficiente si el requisito es control y evidencia, no residencia externa del material.
Pregunta: ¿Cuál es la diferencia entre CMEK y CSEK? Respuesta: Con CMEK la clave se almacena y usa en Cloud KMS, bajo control del cliente. Con CSEK el cliente aporta el material de la clave en cada operación y Google no lo almacena, lo que aumenta el control pero también el esfuerzo y el riesgo de pérdida. CSEK se asocia a servicios concretos como Cloud Storage y Compute Engine.
Pregunta: ¿Por qué Cloud HSM no es la respuesta por defecto para todos los clientes? Respuesta: Porque la mayoría de los requisitos se satisfacen con claves software de Cloud KMS, que son más simples y económicas. Cloud HSM se justifica cuando la regulación exige que el material permanezca en hardware certificado o cuando se necesita un nivel de aislamiento que las claves software no ofrecen.
Pregunta: Una aplicación necesita una contraseña de base de datos y una clave para cifrar expedientes. ¿Cómo se separan? Respuesta: La contraseña se guarda en Secret Manager y la aplicación la lee con una identidad autorizada; la clave de cifrado de los expedientes se gestiona en Cloud KMS como CMEK. La aplicación nunca incrusta la contraseña en la imagen ni recibe permiso para administrar la clave.
Pregunta: ¿Qué protege Confidential Computing y qué no protege? Respuesta: Protege los datos en uso en memoria frente al operador de la infraestructura mediante aislamiento por hardware. No protege datos en reposo, no sustituye IAM, no evita que una aplicación escriba datos en un log y no cubre todo el entorno si no se diseña la carga de trabajo con ese fin.