El Cifrado Documental en Perú: Protección Real o Falsa Tranquilidad
En octubre de 2024, la brecha en Interbank expuso una verdad que muchos equipos de seguridad ya sospechaban pero preferían no articular: el perímetro de protección de una organización ya no termina en sus propios servidores. El atacante no forzó ninguna puerta principal. Comprometió las credenciales de un proveedor externo de monitoreo, extrajo volúmenes de documentación que el banco consideraba protegidos y dejó expuestos más de tres millones de clientes. Si esos archivos hubieran estado cifrados con claves bajo control exclusivo del banco, los terabytes exfiltrados habrían sido criptográficamente inutilizables. No lo estaban.
Esta distinción —entre datos cifrados con claves propias y datos cifrados con claves del proveedor— define si una organización puede defenderse regulatoriamente ante la SBS o la ANPD después de una brecha. Y es, con demasiada frecuencia, una distinción que los equipos de TI dan por resuelta cuando ven el candado en el navegador o leen “AES-256” en el contrato con su proveedor cloud. Ninguna de esas dos señales es suficiente.
Este artículo desglosa los tres estados del cifrado, las obligaciones concretas de la SBS 504-2021 y el DS 016-2024-JUS, los modelos reales de gestión de claves y el protocolo que convierte una brecha en un expediente regulatorio defendible. El objetivo no es la criptografía por sí misma: es la capacidad de demostrar inaccesibilidad ante reguladores cuando el incidente ya ocurrió.
Los Tres Estados del Cifrado: Una Distinción Que Puede Salvar una Auditoría
La confusión más frecuente en repositorios documentales corporativos surge de tratar el cifrado como un control binario: o está o no está. En la práctica, existen tres estados con protecciones radicalmente diferentes.
Cifrado en tránsito: el sobre sellado
TLS 1.2 y 1.3, SFTP, APIs REST con HTTPS protegen los datos mientras viajan por la red. Es el equivalente a un sobre sellado: nadie puede leerlo en tránsito. El problema es que en cuanto el archivo llega al servidor de destino, el sobre se abre. El servidor receptor descifra el contenido automáticamente.
Lo que protege: ataques de intercepción en la red (man-in-the-middle), sniffing de paquetes.
Lo que no protege: cualquier dato que ya reside en el servidor. Un proveedor comprometido puede acceder a esos archivos con la misma facilidad que sus propios administradores.
Una vulnerabilidad adicional que suele ignorarse: configuraciones TLS con versiones 1.0 y 1.1 aún activas, suites de cifrado obsoletas o certificados expirados invalidan incluso esta capa básica.
Cifrado en reposo: la caja fuerte del proveedor
AES-256, TDE (Transparent Data Encryption), BitLocker, LUKS protegen archivos almacenados en disco, bases de datos y copias de respaldo. Es la capa que la mayoría de los contratos con proveedores cloud mencionan como estándar.
El problema de fondo: si el proveedor gestiona las claves, él tiene la combinación de esa caja fuerte. Esto tiene dos implicaciones concretas:
- Un atacante que compromete al proveedor a nivel de sistema puede descifrar los datos, exactamente como ocurrió en el caso Interbank.
- Una orden judicial extranjera bajo la Ley CLOUD de Estados Unidos puede obligar a un proveedor con presencia en ese país a descifrar archivos de clientes peruanos sin notificarlos.
El cifrado en reposo con claves del proveedor protege contra el robo físico de hardware. No protege contra un atacante sofisticado que llega a nivel de infraestructura.
Cifrado de extremo a extremo (E2EE): la caja fuerte con llave del propietario
En este modelo, el documento se cifra antes de salir del entorno del cliente y solo se descifra en el entorno del destinatario autorizado. El proveedor del repositorio nunca posee la clave.
Arquitectura zero-knowledge: el proveedor no tiene capacidad técnica de acceder al contenido aunque lo quisiera o aunque se lo ordenaran judicialmente desde otra jurisdicción.
La ventaja ante una brecha es concreta: si el atacante extrae volúmenes cifrados y las claves nunca salieron del HSM del cliente, los documentos son criptográficamente inutilizables. Ese argumento —demostrable con logs de auditoría— es exactamente lo que la SBS y la ANPD requieren después de un incidente.
Tabla comparativa: qué protege cada capa ante diferentes escenarios de brecha
| Escenario de ataque | Cifrado en tránsito | Cifrado en reposo (claves proveedor) | E2EE / HYOK (claves cliente) |
|---|---|---|---|
| Robo físico de hardware del servidor | No aplica | Protege | Protege |
| Atacante compromete credenciales de admin del proveedor | No protege | No protege | Protege |
| Atacante compromete infraestructura del proveedor cloud | No protege | No protege | Protege |
| Orden judicial extranjera sobre el proveedor | No protege | No protege | Protege |
| Intercepción en red | Protege | No aplica | Protege |
Lo Que Exige la SBS 504-2021: Obligaciones Concretas para CISOs Financieros
La Resolución SBS 504-2021 no es una lista de recomendaciones. Es un reglamento con revisión periódica y exigencia de evidencia documentada. Para entidades financieras supervisadas —bancos, financieras, cajas municipales, AFP, empresas de seguros— el incumplimiento tiene consecuencias regulatorias directas.
El marco SGSI-C y la criptografía como obligación explícita
La norma establece cinco capacidades alineadas con el NIST Cybersecurity Framework: Identificación, Protección, Detección, Respuesta y Recuperación. Dentro de la capacidad de Protección, la norma exige “utilizar criptografía para asegurar la confidencialidad, autenticidad e integridad de la información” y “estándares criptográficos vigentes, basados en software o en hardware.”
La SBS no prescribe AES-256 por nombre, pero en una auditoría, el uso de algoritmos obsoletos —MD5, SHA-1, DES, RC4, 3DES— equivale a incumplimiento. El criterio es el estado del arte al momento de la revisión.
Gestión del ciclo de vida de claves: no es opcional
La norma exige procedimientos documentados de activación, suspensión, reemplazo, renovación y revocación de claves criptográficas. Una auditoría SBS puede solicitar:
- La política escrita de gestión de claves.
- El historial de rotaciones con fechas y responsables.
- Evidencia de separación de roles: quien genera claves no es quien las usa ni quien audita.
- Registros de acceso al KMS en modo inalterable.
Una clave que nunca se ha rotado es tanto un riesgo técnico como una señal de incumplimiento normativo.
Proveedores cloud: las tres certificaciones no negociables
Para operaciones significativas en la nube, la SBS 504-2021 exige que los contratos con proveedores cloud incluyan certificaciones auditadas de forma independiente: ISO/IEC 27001 (gestión de seguridad de la información), ISO/IEC 27017 (controles específicos para servicios en la nube) e ISO/IEC 27018 (protección de datos personales en entornos cloud).
No basta con que el proveedor declare que “cumple con estándares internacionales.” Las certificaciones deben ser auditadas por organismos independientes y estar vigentes al momento de la auditoría SBS.
Lo Que Exige el DS 016-2024-JUS: El Nuevo Reglamento de Protección de Datos
Vigente desde marzo de 2025, el Decreto Supremo 016-2024-JUS introduce el elemento temporal que muchas organizaciones subestiman.
48 horas: el reloj que no para
La notificación a la ANPD es obligatoria dentro de las 48 horas de detectado el incidente. El reloj corre desde la detección, no desde la contención. Una organización que detecta una brecha el lunes debe notificar a la ANPD antes del miércoles, independientemente de si el análisis forense está completo.
La notificación inicial se presenta con la información disponible al momento; las actualizaciones siguen después. El plazo de 48 horas no admite excepciones por “todavía estamos investigando.”
Medidas técnicas documentadas: el cifrado no alcanza por sí solo
El reglamento exige medidas técnicas, organizativas y legales como conjunto integrado. La pérdida de un dispositivo sin cifrado —un laptop, un disco externo, una USB— puede constituir un incidente reportable por sí sola, sin que haya habido ataque externo.
El principio de minimización también aplica: el cifrado no justifica retener datos innecesarios. La protección técnica debe ir acompañada de políticas de retención definidas y documentadas.
Responsabilidad en cadena: proveedores bajo la lupa
En incidentes de alto impacto, la ANPD revisa no solo al responsable del tratamiento sino a encargados y subcontratistas. La lección del caso Interbank aplica directamente: la responsabilidad por un incidente originado en un proveedor externo recae también sobre quien contrató a ese proveedor sin los controles adecuados.
Gestión de Claves Criptográficas: El Componente Que Decide Todo
Los tres modelos y sus límites reales
Provider-Managed Keys: el proveedor genera, almacena y opera las claves. El cliente no controla el ciclo de vida. Adecuado únicamente para datos de baja sensibilidad regulatoria. No debería aplicarse a documentación sujeta a supervisión SBS ni a datos personales bajo Ley 29733.
BYOK — Bring Your Own Key: el cliente genera las claves y las importa al KMS del proveedor. El límite crítico: las operaciones de cifrado y descifrado ocurren en la infraestructura del proveedor. Las claves “propias” residen en el entorno ajeno durante las operaciones. Es mejor que provider-managed, pero no habilita el argumento de inaccesibilidad ante una brecha del proveedor. Las entidades que argumentan “control de claves” con BYOK estándar ante una auditoría SBS están en terreno frágil.
HYOK — Hold Your Own Key: las claves nunca salen del entorno del cliente. Las operaciones criptográficas ocurren en el HSM del cliente o en un enclave seguro bajo su control exclusivo. El proveedor cloud opera únicamente con datos ya cifrados y no tiene capacidad técnica de descifrarlos. Este es el único modelo que habilita el argumento de inaccesibilidad ante la SBS y la ANPD después de una brecha. La contrapartida es real: mayor carga operativa y necesidad de alta disponibilidad del HSM.
HSM: el cofre inviolable para las claves maestras
Un Hardware Security Module es un dispositivo físico especializado para operaciones criptográficas. La certificación de referencia es FIPS 140-2 Nivel 3 (el Nivel 4 es el más alto; el 3 es el estándar de facto en banca y salud regulada).
Opciones disponibles en la práctica:
- HSM on-premise: Thales Luna, Utimaco CryptoServer, nShield de Entrust.
- Cloud HSM dedicado: AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM.
La SBS 504-2021 acepta estándares “basados en software o en hardware”; un HSM certificado FIPS 140-2 Nivel 3+ es la opción de mayor solidez probatoria ante auditoría porque la certificación es independiente y verificable.
Jerarquía de claves KEK/DEK: por qué importa la arquitectura
- DEK (Data Encryption Key): cifra el contenido de cada documento.
- KEK (Key Encrypting Key): cifra las DEKs; reside en el HSM y nunca lo abandona.
Si un atacante obtiene una DEK individual, compromete un documento o un conjunto acotado, no el repositorio completo. Las DEKs cifradas pueden almacenarse junto a los documentos sin riesgo: son inutilizables sin la KEK, que permanece en el HSM.
Mejores prácticas de ciclo de vida de claves
- Rotación periódica: claves de datos críticos cada 90 días; claves de menor criticidad anualmente como mínimo.
- Separación de roles: quien genera claves, quien las usa y quien audita son funciones separadas con accesos distintos.
- Respaldo seguro en ubicaciones físicamente separadas, nunca en el mismo volumen que los datos cifrados.
- Autenticación multifactor para acceder al KMS.
- Registro de auditoría inmutable de todas las operaciones: uso, rotación, revocación.
Ante una Brecha: Del Incidente al Expediente Regulatorio en Cuatro Fases
Fase 1 — Contener (primeras horas)
Aislar sistemas afectados sin destruir evidencia. Revocar credenciales comprometidas —no solo las del usuario atacado, sino todos los accesos con privilegios equivalentes. Preservar logs en estado inmutable: sin sobreescritura, sin depuración, sin rotación automática mientras el incidente está activo.
El plan de respuesta a incidentes debe ser activable en horas, no en días. Un incidente no es el momento de leer el plan por primera vez.
Fase 2 — Evaluar (primeras 24 horas)
Determinar el perímetro exacto: qué datos fueron accedidos o exfiltrados, desde qué repositorios, durante qué ventana temporal. La pregunta más crítica en esta fase es: ¿el estado del KMS está intacto?
Si las claves fueron comprometidas, el cifrado no protege. Si están intactas:
- Documentar el estado criptográfico de cada repositorio afectado: algoritmo, longitud de clave, estado en KMS al momento del incidente.
- Obtener logs del KMS con operaciones de descifrado durante el período.
- Preservar logs del repositorio con intentos de acceso.
- Calcular hashes SHA-256 de los archivos para verificar integridad.
Fase 3 — Notificar (dentro de las 48 horas: ANPD, SBS, CNSD según corresponda)
- ANPD: notificación inicial dentro de las 48 horas con la información disponible. No esperar el análisis completo.
- SBS: cuando el incidente cause impacto material adverso significativo, con resumen ejecutivo y análisis forense técnico.
- CNSD: si el incidente afecta infraestructura crítica bajo DS 126-2025-PCM (sector financiero, salud).
El argumento regulatorio debe estar documentado y listo para presentar: “Los documentos estaban cifrados con AES-256 bajo modelo HYOK; los logs del KMS no muestran operaciones de descifrado no autorizadas durante el período del incidente; la información permaneció semánticamente inaccesible al atacante.”
Fase 4 — Demostrar (auditoría post-incidente)
El expediente regulatorio debe incluir: política de cifrado vigente al momento del incidente, certificados del HSM (FIPS 140-2), logs de auditoría criptográfica exportados en modo inalterable, y resultado del análisis forense con firma de un perito independiente.
Un perito forense digital independiente que valide la conclusión de inaccesibilidad refuerza materialmente el argumento ante reguladores. La SBS y la ANPD valoran tanto la capacidad de respuesta como la evidencia de mejora continua.
Los Diez Errores Que Invalidan el Argumento de Cifrado ante Reguladores
- Las claves estaban en el mismo servidor comprometido. Si el atacante accedió al servidor, accedió también a las claves.
- Modelo BYOK con el proveedor comprometido. Las operaciones criptográficas ocurrían en la infraestructura atacada.
- Sin logs de auditoría del KMS. Sin registros inmutables, es imposible probar que las claves no fueron usadas durante la brecha.
- Las claves almacenadas junto a los datos cifrados en el mismo volumen o base de datos.
- Ninguna clave fue rotada jamás. Una clave comprometida en el pasado da acceso permanente hacia atrás.
- Algoritmos obsoletos: MD5, SHA-1, DES, RC4, 3DES. Su uso invalida el argumento de inaccesibilidad ante cualquier regulador técnicamente informado.
- Sin separación de funciones: el atacante que accedió a los datos también podía acceder a las claves.
- Terceros y proveedores ignorados. La cadena de custodia de claves debe incluir a cada subcontratista con acceso al repositorio.
- Cifrado sin controles de acceso. El cifrado protege datos robados, no datos consultados por usuarios con acceso legítimo pero sin autorización real.
- Ausencia de pruebas de penetración periódicas sobre el repositorio y el KMS.
Recomendaciones por Sector Regulado
Sector financiero (bancos, financieras, cajas, AFP)
- Expedientes de crédito y KYC: clasificación de alta sensibilidad; E2EE con HYOK recomendado.
- Contratos de préstamo e hipotecas: requieren firma digital certificada e integridad SHA-256 verificable.
- Documentación de auditoría interna y reportes SBS: acceso restringido con logs WORM (Write Once Read Many).
- Microformas digitales bajo D.L. 681: la certificación ante SGS Perú incorpora integridad hash y firma digital como parte del proceso; el cifrado del repositorio de destino es la extensión natural de esa cadena de custodia.
Sector asegurador
- Siniestros y peritajes médicos: doble regulación (SBS + Ley 29733 por datos de salud del asegurado); HYOK recomendado.
- Documentación de reaseguro: datos compartidos con terceros internacionales; TLS 1.3 más cláusulas contractuales de cifrado obligatorio en los acuerdos con reaseguradoras.
- Reportes actuariales: alta confidencialidad competitiva; claves bajo control exclusivo del cliente.
Sector salud (MINSA, EsSalud, EPS, clínicas privadas)
- Historia clínica electrónica (HCE) en RENHICE/SIHCE: los datos de salud son categóricamente sensibles bajo Ley 29733; cifrado obligatorio con claves bajo control del establecimiento, no del proveedor de digitalización.
- Resultados de laboratorio e imágenes DICOM: AES-256 en reposo con control de acceso basado en roles (RBAC).
- Digitalización de historias clínicas físicas: el escaneo y el OCR deben ocurrir en canales cifrados; el repositorio final debe aplicar cifrado con claves bajo control del hospital.
La Cadena de Custodia Criptográfica en Microformas
La NTP 392.030-2:2015 y el D.L. 681 establecen que las microformas digitales tienen valor probatorio equivalente al documento original. Esa equivalencia legal descansa en la verificabilidad de la integridad: un hash SHA-256 vinculado a cada microforma en el momento de la certificación actúa como huella digital inalterable.
Si el hash del archivo almacenado coincide con el registrado en el momento de la certificación SGS Perú, se demuestra que el documento no fue alterado en ningún punto de la cadena. La firma digital del operador certificado —bajo DS 052-2008-PCM y sus modificatorias— vincula el documento a una identidad verificada con sello de tiempo, verificable independientemente del software del proveedor.
El repositorio de destino es el último eslabón de esa cadena. Un repositorio que recibe microformas certificadas y las almacena sin cifrado adecuado —o con claves del proveedor de almacenamiento en lugar del cliente— rompe la cadena de seguridad en el punto más cercano al uso. La recomendación es directa: cifrado con claves bajo control del cliente, sin modificación del hash original certificado, con logs de acceso inmutables.
Horizonte: Criptografía Post-Cuántica
Las computadoras cuánticas suficientemente potentes podrían comprometer RSA y ECC clásicos. El horizonte exacto es incierto, pero el NIST finalizó en 2024 los primeros estándares post-cuánticos: CRYSTALS-Kyber (ML-KEM) para intercambio de claves y CRYSTALS-Dilithium (ML-DSA) para firmas digitales.
La acción inmediata no es reemplazar infraestructura hoy. Es mapear las dependencias criptográficas actuales —qué algoritmos se usan, dónde, con qué ciclo de vida— para planificar la migración antes de que la amenaza sea operativa.
El riesgo específico para repositorios documentales es el ataque “harvest now, decrypt later”: un adversario que hoy extrae volúmenes cifrados con RSA-2048 y los almacena para descifrarlos cuando la computación cuántica lo permita. Los documentos con valor legal a largo plazo —escrituras, contratos hipotecarios, expedientes judiciales, historias clínicas— son los más expuestos a este riesgo temporal. La planificación debe comenzar por esos repositorios.
Conclusiones Clave
El cifrado en tránsito y en reposo con claves del proveedor no protege ante una brecha sofisticada. Si el proveedor gestiona las claves —incluso en modelo BYOK—, un atacante que compromete al proveedor puede descifrar los volúmenes. Solo el modelo HYOK con claves bajo control exclusivo del cliente genera el argumento legal de inaccesibilidad ante la SBS y la ANPD.
Los logs del KMS son tan importantes como el cifrado en sí. Después de una brecha, los reguladores no aceptan declaraciones sobre el estado del cifrado: requieren evidencia forense. Sin registros de auditoría inmutables que muestren la ausencia de operaciones de descifrado no autorizadas durante el incidente, el argumento de inaccesibilidad no se sostiene.
La SBS 504-2021 convierte la gestión del ciclo de vida de claves en obligación normativa. Activación, rotación, suspensión y revocación son requisitos explícitos del reglamento, no buenas prácticas opcionales.
El reloj de 48 horas de la ANPD corre desde la detección, no desde la contención. Las organizaciones que no tienen un plan de respuesta activable en horas —con el expediente de cifrado listo para presentar— llegarán tarde al plazo regulatorio.
