Encriptación de At Nat

Cifrado de At Nat

1) Por qué es necesario y qué es exactamente lo que protegemos

Definición. La encriptación de datos es la protección de los datos grabados en un medio (discos, snapshots, backups, objetos, registros, volcado de memoria) para que el acceso no autorizado a un medio físico o a un almacenamiento «crudo» no revele el contenido.

• Volúmenes de bloques/archivos, almacenes de objetos, bases de datos, colas/cabezales, vertederos de caché, registros/tracks, copias de seguridad, exportación/importación, instantáneas de VM/contenedores, volcado de núcleo/procesos, paginación/swap.
• Escenarios multiarrendamiento: aislamiento entre clientes/proyectos/entornos.

Lo que no cubrimos del todo: robo de sesiones en la memoria, ataques a procesos en vivo, vulnerabilidades de la aplicación, comprometer credenciales. Esto requiere cifrado «en vuelo», autenticación/autorización estricta, minimización de derechos y monitoreo (ver artículos relacionados: «Autenticación y autorización», «Firma y verificación de solicitudes»).

2) Modelo de amenazas y objetivos de control

• Pérdida/robo de medios (disco, cinta, USB, dispositivo del desarrollador).
• Acceso no autorizado a backups/snapshots/logs.
• Abuso de privilegios a nivel de plataforma/hipervisor/storage-nod.
• Intersección de inquilinos con errores de configuración.
• Archivos temporales «embotellados» y volcado que caen en artefactos e imágenes.

1. Confidencialidad de los datos en el medio.

2. Aislamiento criptográfico de inquilinos/alrededores.

3. Administración de claves (creación, almacenamiento, rotación, revocación).

4. Auditabilidad (quién y cuándo utilizó la clave).

5. Minimizar los riesgos operativos en caso de incidentes.

3) Principios básicos de la arquitectura

Ciframos todo por defecto. Opt-out está prohibido sin excepciones a nivel de riesgo.
Jerarquía de claves (envelope encryption). Root/KEK → DEK (data encryption keys) → objetos/archivos/páginas DB.
KMS/HSM como fuente de confianza. Generación y almacenamiento de KEK en KMS/HSM, las operaciones de envoltura/despliegue de claves se realizan en el mismo lugar.
Por-tenant/per-dataset claves. Granularidad bajo requisitos de aislamiento y rotación.
División de responsabilidades. Los equipos de la plataforma ≠ los propietarios de las llaves del inquilino; un mínimo de privilegios (PoLP).
Crypto-agility. Posibilidad de migrar algoritmos/longitudes de claves de forma segura.
La rotación como proceso, no como evento. Las claves y los datos deben ser compatibles con el reemplazo «deslizante».

4) Algoritmos y modos de cifrado

Para objetos/archivos/registros: AES-256-GCM o AES-256-SIV (AEAD con autenticación).
Para dispositivos de bloques/volúmenes: AES-XTS-256/512 (protección contra permutaciones de bloques; no AEAD - utilizar sobre formatos de archivos con MAC donde la integridad es importante).

• TDE (Transparent Data Encryption) движка: Oracle TDE, SQL Server TDE, MySQL/InnoDB TDE и пр.
• Criptografía de campo/línea (FPE/cifrado determinista): para capacidades de búsqueda/joynes en campos cifrados; aplicar con prudencia.
• Generación y almacenamiento de claves: KEK - en KMS/HSM; DEK - en la memoria de las aplicaciones de vida corta, en el almacenamiento - sólo en la vista envuelta.

5) Jerarquía de claves y KMS/HSM

1. Root key (estatutario, en HSM/KMS). No sale del perímetro HSM/KMS.

2. KEK (Key Encryption Key). Por proyecto/entorno/inquilino. Administra el ciclo de vida DEK.

3. DEK (Data Encryption Key). Por objeto/archivo/tabla/segmento. Breve vida, rotación sin parar.

• Todas las operaciones de envoltura/despliegue - a través de la API de KMS con auditoría.
• Políticas: quién puede «usar» la clave ≠ quién puede «administrar» la clave.
• Distribución geográfica de claves: pin-to-region + dual-control para la interregión.
• Es posible un modelo «doble» (dos operadores) para operaciones de alto riesgo.
• Para aislar un nivel fuerte - key-rings individuales por inquilino.

6) Rotación, revisión y cumplimiento

Rotación DEK: transparente y constante (rolling re-encryption a nivel de objetos/páginas).
Rotación KEK: periódica (por ejemplo, una vez cada 6-12 meses) + revocación inmediata cuando se sospecha un compromiso.
Revocación de acceso: a través de políticas KMS; bloquear las operaciones de unwrap = «encriptabilidad» instantánea de los datos.
Registros de auditoría: quién, cuándo, con qué derechos usaron las claves; almacenar por separado y cifrar también.
Regulaciones y estándares: nos centramos en los requisitos de la industria (por ejemplo, tolerancias GDPR/PCI/reguladores locales), utilizando criptomodules certificados (por ejemplo, cumplimiento de niveles de certificación).

7) Patrones por tipo de almacenamiento

7. 1 Volúmenes de bloques/archivos y VM/contenedores

Encriptación en disco completo (XTS) + administración de claves a través de KMS (inicialización del volumen al montar).
Proteger swap, dumps crash, directorios tmp, capas overlay contenedor, imágenes/AMI.
Instantáneas/snapshots: siempre en forma cifrada con DEK separados.

7. 2 Almacenamiento de objetos

Envelope encryption: DEK único por objeto; encabezados/metadatos - sin fugas PII.
Control de acceso a KMS clave por inquilinos y alrededores.
Cifrado del lado del servidor (SSE con su propio KMS) o el lado del cliente (CSE): seleccione según el modelo de confianza.

7. 3 Bases de datos

Habilitar TDE cuando esté disponible; llaves DB enlazar a KMS a través de plugin/extensión.
Para campos especialmente sensibles, el cifrado de aplicaciones (AEAD) antes de llegar a la DAB.
Registros redo/transaccionales, registros archivados, volcado - cifrado por separado, claves - separados.

7. 4 Registros/trayectos/métricas

Formato de registro: sin datos sensibles predeterminados (saneamiento).
Archivos de registro: claves individuales y TTL de almacenamiento corto.
Acceso a la lectura de registros - a través de un servicio proxy con A&A y auditoría.

7. 5 Copias de seguridad y medios fuera de línea

Encriptar siempre en el lado del cliente antes de grabar en cinta/nube.
Almacenar las claves por separado (out-of-band), escrow con control dividido.
Para casos de emergencia, separar el secreto (por ejemplo, m-of-n) para restaurar el acceso maestro.

8) Multi-arrendamiento (multi-tenant)

Clave del inquilino: KEK-per-tenant + DEK-per-dataset.
Aislamiento de políticas: espacios de nombres KMS, límites IAM, roles IDP individuales.
Eliminación a petición del cliente: «crypto-borrar» - revocar el KEK del inquilino y destruir DEK.
Informes para el cliente: artefactos de conformidad, registros de acceso a claves, confirmación de rotación.

9) Rendimiento y operación

Aceleraciones de hardware (AES-NI/x86, ARMv8 Crypto Extensions).
Perfilando vías calientes: ciframos en los límites de I/O, evitamos la doble encriptación sin necesidad.
Grupos de sesiones KMS, almacenamiento en caché de DEK envueltos en memoria (con TTL y protección contra volcado).
SLO/métricas: latencia unwrap, proporción de objetos «reencriptados», errores KMS, velocidad de cifrado de respaldo.

10) Proceso de implementación (reference runbook)

Paso 0 - Inventario de datos. Catalogar todos los almacenes y rutas de fuga (tmp, volcado, exportación, baquetas analíticas).
Paso 1 - Diseño de la jerarquía clave. Definimos los niveles KEK/DEK, granularidad, regiones, roles.
Paso 2: seleccione modos/bibliotecas. Algoritmos aprobados, criptotecas, políticas de versiones.
Paso 3 - Integración con KMS/HSM. Generación/envoltura/auditoría, políticas IAM, geo-pinning.
Paso 4 - Cifrado por escritura. Habilitar, de forma predeterminada, la migración de datos existentes a través de la reencriptación de antecedentes.
Paso 5 - Rotación y escenarios de emergencia. Regulaciones, pruebas de «compromiso clave», «KMS no está disponible».
Paso 6 - Supervisión y auditoría. Dashboards, alertas, informes regulares de cumplimiento.
Paso 7 - Aprendizaje y «código seguro». Guydas para ingenieros, prohibición de llevar secretos a los registros/volcado.

11) Pruebas y verificación

Pruebas de criptomonedas: corrección AEAD (verificación de etiquetas), validación de fallos cuando se cambia el byte.
Pruebas fallidas: desactivación de KMS, versiones de claves obsoletas, revocación forzada de KEK.
Pruebas Red/Blue: tratando de leer el disco «crudo »/snapshot/back.
Verificación de compatibilidad: migración de algoritmos/longitudes de claves (crypto-agility).
Certificación de biblioteca: utilice sólo cryptomodules validados; fijar versiones.

12) Errores frecuentes y cómo evitarlos

Doble encriptación sin sentido. Latencia y complejidad extra. Mantenga la capa que da la granularidad y el aislamiento deseados.
Almacenar claves junto a los datos. Claves - siempre por separado, bajo otro modelo de acceso.
Artefactos olvidados. Archivos temporales sin cifrar, exportación de CSV, volcado de soporte. Habilite el control en CI/CD y Data Loss Prevention.
No hay rotación. Haga que la rotación forme parte de pipelina/cron en lugar de un procedimiento manual.
Registros con datos sensibles. Introduzca un contrato para el formato de registro y los saneadores automáticos.

13) Mini recetas (pseudocódigo)

1) Request unwrap DEK from KMS by tenant KEK id dek = kms. unwrap(kek_id, wrapped_dek)

2) Generate fresh nonce/iv, encrypt payload (AEAD)
ciphertext, tag = aead_encrypt(dek, iv=random(), aad=metadata, plaintext=data)

3) Delete DEK from memory (zeroize), save {ciphertext, iv, tag, wrapped_dek}

For each object:
new_wrapped_dek = kms. rewrap(old_wrapped_dek, old_kek_id -> new_kek_id)
store(new_wrapped_dek)
We do not touch the data: we turn over only DEK

kms. disable_key (tenant_kek_id) # Deny unwrap kms. schedule_destroy (tenant_kek_id, hold_period_days=7) # Optional hold

14) Hojas de cheques

• El cifrado predeterminado está habilitado en todos los tipos de almacenamiento.
• La jerarquía de claves se describe e implementa; los roles y las políticas IAM están configuradas.
• KMS/HSM está integrado, la auditoría de operaciones clave está habilitada.
• La rotación DEK/KEK está automatizada; escenarios de compromiso trabajados.
• Los topes, los snapshots, los registros y los volcado están encriptados; las llaves se almacenan por separado.
• Alertas configuradas para errores de KMS, desviaciones de etiquetas AEAD, proporción de artefactos no cifrados.
• Se han superado las pruebas de no disponibilidad de KMS y la revisión de claves.

• Informe mensual sobre el uso de claves e intentos de acceso.
• Crypto-agility plan y ventana para la migración de algoritmos sin dolor.
• Equipo rojo periódico para extraer datos de medios «crudos».

15) Preguntas frecuentes (FAQ)

P: ¿Hay suficiente cifrado de disco completo?
R: Para los riesgos físicos - sí, pero para el aislamiento de los inquilinos y la rotación flexible es mejor envelope con DEK-por-objeto/conjunto.

P: ¿Qué hacer al comprometer KEK?
R: Retire KEK inmediatamente a KMS, vuelva a lanzar uno nuevo, realice un rewrap de todos los DEK, compruebe los registros y lleve a cabo el RCA.

P: ¿Cómo cifrar los campos que buscamos?
R: Utilizar esquemas deterministas o FPE sólo cuando se evalúan rigurosamente los riesgos (lecs de patrones). Es mejor diseñar las consultas para que los campos sensibles no requieran una vista abierta indexada.

P: ¿Necesita un comando separado para las claves?
R: Se recomienda «Operador Crypto/KMS» como un rol con derechos y procedimientos separados.

• «Administración de claves y rotación»
• «Autenticación S2S»
• «Firma y verificación de solicitudes»
• «OAuth2/OpenID Connect en el núcleo»
• "Garantías de entrega de webhooks'