OP.EXP.11 Protección de las claves criptográficas

Documentos de referencia

Referencias normativas ENS

• Real Decreto 311/2022 - Anexo II, Medida OP.EXP.11
• CCN-STIC-807 - Criptología de empleo en el ENS
• CCN-STIC-804 - Guía de Implantación del ENS
• CCN-STIC-822 - Guía para la Configuración Segura de Sistemas

Documentación interna Legit Health

• T-024-018 - Procedimiento de gestión de claves criptográficas
• T-024-019 - Política de uso de criptografía
• T-024-020 - Inventario de claves y certificados
• R-110-003 - Inventario de claves criptográficas ENS
• GP-013 - Gestión de Ciberseguridad
• T-110-007 - Matriz RACI de seguridad ENS
• T-110-008 - Procedimiento de notificación CCN-CERT

Referencias internacionales

• ISO/IEC 27001:2022 - Control A.8.24 (Uso de criptografía)
• NIST SP 800-57 - Recomendaciones para gestión de claves
• FIPS 140-2 - Módulos criptográficos
• Common Criteria - Evaluación de seguridad

Referencias médicas

• IEC 62304:2015 - Procesos de ciclo de vida del software de dispositivos médicos
• ISO 14971:2019 - Gestión de riesgos para dispositivos médicos
• MDR 2017/745 - Reglamento de Dispositivos Médicos
• FDA Cybersecurity Guidance - Orientación de ciberseguridad para dispositivos médicos

Guía de implantación

Objetivo

Establecer un sistema integral de protección, gestión y control del ciclo de vida completo de todas las claves criptográficas utilizadas en los sistemas de Legit Health, garantizando la seguridad del dispositivo médico y el cumplimiento de los requisitos regulatorios.

Alcance

Este procedimiento aplica a:

• Claves de cifrado de datos (AES, ChaCha20)
• Claves de firma digital (RSA, ECDSA, EdDSA)
• Certificados digitales (SSL/TLS, firma de código)
• Claves de autenticación (API keys, tokens)
• Secretos de aplicación (passwords, connection strings)
• Claves de cifrado de base de datos
• Material criptográfico del dispositivo médico
• Claves de backup y recuperación

Arquitectura de gestión de claves

Componentes del sistema

Arquitectura de protección de claves criptográficas

Nivel	Componente	Descripción	Certificación/Proveedor
Nivel 1 - Raíz	Hardware Security Module (HSM)	Módulo de seguridad hardware que almacena las claves maestras con máxima protección física y lógica	FIPS 140-2 Level 3 Certified
Nivel 2 - Gestión	Key Management Service (KMS)	Servicio de gestión de claves que deriva claves del HSM y gestiona el ciclo de vida de claves de cifrado	AWS KMS / Azure Key Vault
Nivel 3a - Secretos	Secrets Vault	Almacenamiento seguro de secretos de aplicación (contraseñas, API keys, tokens) cifrados con claves del KMS	HashiCorp Vault
Nivel 3b - Certificados	Certificate Manager	Gestión de certificados digitales X.509 para TLS/SSL y autenticación, con claves protegidas por KMS	AWS Certificate Manager / Azure

Flujo de protección:

1. HSM (raíz de confianza):

   • Almacena la clave maestra raíz (Root Key)
   • Nunca exportable, solo operaciones criptográficas dentro del HSM
   • Protección física contra manipulación (tamper-resistant)

2. KMS deriva claves del HSM:

   • Solicita al HSM operaciones de derivación de claves
   • Genera y gestiona claves de cifrado de datos (DEKs)
   • Gestiona rotación automática de claves

3. Vault y Certificate Manager usan KMS:

   • Secrets Vault: Cifra secretos con claves gestionadas por KMS
   • Certificate Manager: Protege claves privadas de certificados con KMS
   • Ambos heredan el nivel de seguridad del HSM a través de KMS

Jerarquía de claves

La jerarquía de claves sigue una estructura de tres niveles:

Nivel 1 - Clave Maestra (HSM):

• Almacenada en Hardware Security Module certificado
• Protege todas las claves de nivel inferior

Nivel 2 - Claves de Cifrado de Claves (KEK):

• Claves de cifrado de datos (DEK)
• Claves de cifrado de base de datos
• Claves de cifrado de backup

Nivel 2 - Claves de Firma:

• Certificados de firma de código
• Claves de firma de documentos
• Claves de firma de peticiones API

Nivel 2 - Claves de Autenticación:

• Certificados TLS/SSL
• Claves SSH
• Claves de cuentas de servicio

Ciclo de vida de las claves

Generación de claves

Requisitos de generación

El equipo de seguridad debe generar claves criptográficas siguiendo este proceso:

1. Validar parámetros: Verificar que el tipo de clave y su propósito sean válidos según las políticas ENS
2. Seleccionar especificaciones según el tipo:
   • Claves simétricas: AES de 256 bits en modo GCM, generadas en HSM
   • Claves asimétricas: RSA de mínimo 4096 bits con padding OAEP y hash SHA-256
   • Claves de curva elíptica: ECDSA con curva P-384 (secp384r1) y hash SHA-384
3. Generar la clave: Utilizar el servicio KMS conectado al HSM, especificando la clave maestra y el contexto de cifrado apropiado
4. Registrar en inventario: Documentar los metadatos de la clave generada en el inventario R-110-003

Estándares mínimos

Tipo	Algoritmo	Tamaño mínimo	Uso
Simétrico	AES-GCM	256 bits	Cifrado de datos
Asimétrico	RSA	4096 bits	Firma, key exchange
Elíptica	ECDSA	P-384	Firma digital
Hash	SHA	SHA-384	Integridad
KDF	PBKDF2	100,000 iter	Derivación

Distribución segura

Mecanismos de distribución:

1. Distribución automatizada (preferida):
   • Método: API de Secrets Manager
   • Autenticación: Rol IAM + MFA obligatorio
   • Transporte: TLS 1.3
   • Auditoría: CloudTrail habilitado para todas las operaciones
   • Rotación: Activadores automáticos configurados
2. Distribución manual (excepcional):
   • Aprobación requerida: CISO + Custodio de Claves
   • Métodos permitidos: Courier seguro certificado o tarjeta HSM
   • Control dual: Requiere conocimiento dividido entre 2 personas
   • Verificación: Confirmación fuera de banda (out-of-band)
   • Documentación: Cadena de custodia completa

Protocolo de intercambio seguro:

Cuando sea necesario compartir claves entre sistemas de forma segura, el equipo técnico debe implementar el siguiente protocolo:

1. Generar clave efímera: Crear una clave temporal de un solo uso para este intercambio
2. Establecer secreto compartido: Utilizar ECDH (Elliptic Curve Diffie-Hellman) con la clave privada efímera y la clave pública del destinatario
3. Derivar clave de cifrado: Aplicar HKDF al secreto compartido con un salt aleatorio y parámetros específicos de intercambio de claves (longitud: 32 bytes)
4. Cifrar la clave: Usar AES-GCM con la clave derivada para cifrar la clave que se va a compartir
5. Firmar el paquete: Generar firma digital del conjunto (clave cifrada + clave pública efímera) para garantizar autenticidad
6. Transmitir: Enviar la clave cifrada, la clave pública efímera y la firma al destinatario

El destinatario debe verificar la firma y seguir el proceso inverso para recuperar la clave. La implementación técnica debe realizarse según CCN-STIC-807.

Almacenamiento seguro

Opciones de almacenamiento por tipo:

Tipo de Clave	Ubicación	Control de Acceso	Backup	Rotación/Renovación
Claves de Producción	HSM / AWS KMS	Basado en roles + MFA	Replicación en cluster HSM, auditado en cada acceso	Según calendario ENS
Claves de Desarrollo	HashiCorp Vault	Rol developer + aprobación	Cifrado en S3	Mensual
Certificados	AWS Certificate Manager	Solo cuentas de servicio	Respaldo automático	Automática (30 días antes de expiración), validación DNS/Email
Secretos/Contraseñas	AWS Secrets Manager	Roles de aplicación	Versionado (últimas 5 versiones)	Cada 90 días

Protección en memoria:

El equipo técnico debe implementar protecciones contra volcados de memoria (memory dumps) cuando las claves estén cargadas en RAM:

1. Bloqueo de memoria: Marcar las páginas de memoria que contienen claves como no-swappable para evitar que se escriban en disco
2. Protección de acceso: Configurar permisos de solo lectura cuando la clave no esté siendo utilizada activamente
3. Limpieza segura: Después de usar la clave, sobrescribir la memoria con ceros utilizando funciones que no puedan ser optimizadas por el compilador
4. Liberación: Desbloquear la memoria una vez completada la limpieza

Estas medidas previenen que las claves sean accesibles mediante dumps de memoria o swapping a disco. La implementación debe seguir las mejores prácticas de seguridad en memoria.

Uso de claves

Control de uso:

El sistema de gestión de claves debe implementar controles automáticos de uso que verifiquen:

1. Límites de operaciones por tipo de clave:

   • Claves de cifrado: máximo 1,000,000 operaciones
   • Claves de firma: máximo 100,000 operaciones
   • Límite temporal: 365 días desde creación

2. Proceso de autorización para cada uso:

   • Verificar permisos: Confirmar que el usuario actual tiene autorización para usar esta clave en esta operación
   • Verificar límites de uso: Comprobar que no se han superado los límites de operaciones; si se exceden, activar rotación automática
   • Verificar propósito: Asegurar que la operación solicitada coincide con el propósito declarado de la clave (ej: una clave de cifrado no puede usarse para firma)
   • Registrar el uso: Documentar en logs de auditoría cada uso de clave, incluyendo usuario, operación y timestamp

El sistema debe denegar el acceso y alertar al equipo de seguridad si cualquiera de estas verificaciones falla.

Separación de propósitos:

• Claves de cifrado NUNCA para firma
• Claves de producción NUNCA en desarrollo
• Claves de backup SOLO para recuperación
• Claves de usuario NUNCA para servicios

Rotación de claves

Calendario de rotación completo según ENS:

Tipo de clave	ENS Básico	ENS Medio	ENS Alto	Rotación forzada	Uso máximo
Master Keys (HSM)	2 años	1 año	6 meses	Compromiso sospechado	N/A
Key Encryption Keys (KEK)	1 año	6 meses	3 meses	Límite de uso alcanzado	100M operaciones
Data Encryption Keys (DEK)	6 meses	90 días	30 días	1M de operaciones	10M operaciones
TLS Certificates	1 año	90 días	90 días	Cambio de dominio	N/A
Code Signing Certificates	2 años	1 año	1 año	Compromiso de clave privada	N/A
API Keys (Aplicación)	6 meses	90 días	30 días	Empleado desvinculado	N/A
Service Account Keys	1 año	6 meses	90 días	Servicio descomisionado	N/A
Database Encryption Keys	6 meses	3 meses	1 mes	Brecha detectada	50M transacciones
SSH Keys (Admin)	1 año	6 meses	3 meses	Acceso anómalo	N/A
SSH Keys (Service)	2 años	1 año	6 meses	Cambio de infraestructura	N/A
Backup Encryption Keys	1 año	6 meses	3 meses	Backup comprometido	N/A

Rotación automatizada por tipo de clave:

El sistema automatizado de rotación de claves debe implementar la siguiente lógica:

Generación del calendario de rotación:

Para cada clave en el inventario, el sistema debe:

1. Determinar la frecuencia de rotación según el tipo de clave y nivel ENS aplicable
2. Calcular la fecha de próxima rotación basándose en la fecha de creación más la frecuencia
3. Aplicar un buffer de seguridad de 7 días (rotar antes de la fecha límite)
4. Clasificar la rotación en el cronograma apropiado según días restantes:
   • Diaria (≤1 día): prioridad urgente
   • Semanal (≤7 días): prioridad alta
   • Mensual (≤30 días): prioridad media
   • Trimestral (≤90 días): prioridad baja
   • Anual (>90 días): mantenimiento programado

Ejecución de rotaciones programadas:

El sistema debe ejecutar automáticamente las rotaciones siguiendo este proceso:

1. Obtener rotaciones del período: Identificar todas las claves que necesitan rotación en el período actual (diario/semanal/mensual)
2. Para cada rotación:
   • Validar prerrequisitos (backups actualizados, servicios disponibles)
   • Ejecutar el proceso de rotación
   • Validar que la nueva clave funciona correctamente
   • Registrar el resultado (éxito o fallo)
3. Gestión de fallos:
   • Si una rotación falla, registrar el error
   • Programar reintento automático en 4 horas
   • Alertar inmediatamente al equipo de seguridad
4. Generar informe: Documentar todas las rotaciones ejecutadas para auditoría

Los detalles técnicos de implementación deben mantenerse en la documentación técnica del sistema.

Matriz de rotación de claves médicas:

Tipo de Clave	Frecuencia	Validaciones Pre-Rotación	Validaciones Post-Rotación	Consideraciones Especiales
Claves de Datos de Pacientes	Mensual	• Backup de datos verificado • Coordinación con flujos clínicos • Programar fuera de horario	• Test de accesibilidad de datos • Test de integración con sistemas clínicos • Evaluación de impacto en rendimiento	Alta criticidad para operaciones clínicas
Claves de Firma de Modelos IA	Anual	• Notificar autoridades competentes 30 días antes • Validación clínica requerida • Actualizar control de versiones	• Verificación de firma del modelo • Validación de precisión clínica • Verificación de cumplimiento regulatorio	Requiere coordinación regulatoria
Claves de Comunicación del Dispositivo	Trimestral	• Estrategia de despliegue gradual • Capacidad de rollback preparada	• Monitoreo durante 48 horas post-rotación	Despliegue incremental para minimizar riesgo

Proceso de rotación automatizada:

El sistema debe ejecutar las rotaciones de claves siguiendo estos pasos:

1. Generar nueva clave: Crear una nueva clave con las mismas especificaciones que la clave a rotar
2. Fase de transición: Activar la nueva clave en modo transición, permitiendo que ambas claves (antigua y nueva) estén activas temporalmente
3. Re-cifrar datos gradualmente:
   • Programar un trabajo de re-cifrado en segundo plano
   • Procesar los datos en lotes de 1000 registros
   • Utilizar la nueva clave para re-cifrar los datos cifrados con la clave antigua
4. Monitorear progreso:
   • Verificar el estado del re-cifrado cada 5 minutos
   • Registrar el progreso en logs
   • Continuar hasta completar todo el re-cifrado
5. Desactivar clave antigua: Una vez completado el re-cifrado, desactivar la clave antigua
6. Archivar: Archivar la clave antigua con retención de 7 años para cumplimiento regulatorio
7. Notificar: Informar al equipo de seguridad que la rotación se ha completado exitosamente

Gestión de errores: Si ocurre cualquier error durante el proceso, realizar rollback automático de la rotación, alertar al equipo de seguridad y documentar el incidente.

Destrucción de claves

Procedimiento de destrucción segura:

La destrucción de claves criptográficas debe seguir un proceso riguroso y auditado:

1. Verificar dependencias: Confirmar que no existen datos activos que dependan de esta clave. Si existen, detener el proceso
2. Obtener aprobaciones: Requiere mínimo 2 aprobaciones de personas autorizadas (CISO + Custodio de Claves)
3. Backup de cumplimiento: Crear un archivo final de la clave para cumplimiento regulatorio (almacenado de forma segura con retención de 7 años)
4. Destrucción criptográfica:
   • Sobrescribir el material de la clave 7 veces según estándar DoD 5220.22-M
   • Utilizar patrones específicos en cada sobrescritura
5. Eliminar de todos los sistemas:
   • Eliminar del HSM
   • Eliminar del KMS
   • Eliminar del Vault
   • Eliminar de todos los backups
6. Verificar destrucción: Confirmar que la clave ya no existe en ningún sistema; si sigue existiendo, detener y alertar
7. Generar certificado: Crear un certificado de destrucción que documente:
   • ID de la clave
   • Timestamp de destrucción
   • Método utilizado (crypto shredding)
   • Aprobadores involucrados
   • Persona que verificó la destrucción
8. Registro permanente: Archivar el certificado de destrucción en logs de auditoría permanentes

Este proceso garantiza la destrucción completa y verificable de claves mientras se mantiene el cumplimiento regulatorio.

Controles de seguridad específicos

Segregación de funciones

Roles y responsabilidades:

Rol	Responsabilidades	Restricciones
Key Administrator	• Crear políticas de claves • Aprobar generación de master keys • Auditar uso de claves	NO puede usar claves directamente
Key Custodian	• Generar claves operacionales • Distribuir claves autorizadas • Rotar claves según calendario	NO puede modificar políticas
Key User	• Usar claves asignadas • Solicitar nuevas claves • Reportar incidentes	NO puede compartir o exportar claves
Key Auditor	• Revisar logs de uso • Verificar cumplimiento • Investigar anomalías	NO puede modificar claves o políticas

Directrices de Uso de HSM según CCN-STIC-807

Configuración HSM para cumplimiento ENS:

El HSM debe estar certificado como mínimo en FIPS 140-2 Level 3.

Algoritmos aprobados por nivel ENS:

Categoría	ENS Básico	ENS Medio	ENS Alto
Simétrico	• AES-256 (GCM, CBC) • ChaCha20-Poly1305	• AES-256-GCM (obligatorio)	• AES-256-GCM (obligatorio)
Asimétrico	• RSA-4096 (OAEP, PSS) • ECDSA P-256, P-384	• RSA-4096 (obligatorio) • ECDSA P-384 (recomendado)	• RSA-4096 con OAEP SHA-384 • ECDSA P-521
Hash	• SHA-256, SHA-384, SHA-512	• SHA-384 (mínimo)	• SHA-512 (obligatorio)

Procedimientos HSM específicos para dispositivos médicos:

La gestión de claves para dispositivos médicos requiere políticas especiales según IEC 62304 y MDR:

Políticas de claves por propósito médico:

Propósito	Algoritmo	Derivación	Rotación	Requisitos Especiales
Cifrado de Datos de Pacientes	AES-256-GCM	HKDF-SHA384	30 días	Redundancia geográfica, auditoría detallada, cumplimiento FDA
Firma de Algoritmos Diagnósticos	ECDSA-P384	SHA-384	365 días	Certificado de firma de código, aprobación regulatoria requerida antes de uso
Autenticación de Dispositivos	ECDSA-P256	—	730 días	TLS mutuo, vinculación a elemento seguro de hardware

Generación de claves para dispositivos médicos:

El equipo técnico debe seguir este proceso:

1. Validar propósito: Verificar que el propósito de la clave es reconocido (cifrado de pacientes, firma de IA, autenticación)
2. Validar clase del dispositivo:
   • Para dispositivos Clase IIa, IIb o III: Requiere aprobación regulatoria adicional
   • Verificar cumplimiento antes de proceder
3. Configurar especificaciones:
   • Algoritmo según política del propósito
   • Contexto regulatorio (MDR, FDA, seguridad del paciente)
   • Atributos especiales: no-repudio, escrow (solo Clase III), auditoría completa
4. Generar en HSM médico: Utilizar partición dedicada del HSM para dispositivos médicos
5. Registrar: Documentar en inventario de dispositivos médicos
6. Generar evidencias: Crear documentación de cumplimiento regulatorio

Rotación de claves médicas:

La rotación debe considerar el impacto clínico y regulatorio:

1. Obtener información de la clave y su propósito médico
2. Identificar dispositivos desplegados que utilizan esta clave
3. Si hay dispositivos desplegados (no emergencia):
   • Crear plan de rotación gradual
   • Notificar a autoridades regulatorias si requerido
   • Coordinar con equipos clínicos para minimizar disrupción
4. Ejecutar rotación según plan (emergencia o gradual)
5. Validar funcionalidad: Verificar que todos los dispositivos funcionan con la nueva clave
6. Documentar: Generar documentación completa para auditorías regulatorias

Los detalles de implementación técnica se mantienen en la documentación técnica del sistema.

Configuración de HSM por nivel de seguridad ENS:

Nivel ENS	Partición HSM	Autenticación	Backup de Claves	Auditoría	Respuesta a Manipulación	Seguridad Adicional
Básico	legit-health-basic	Password + smart card	Export cifrado	Mensual	—	—
Medio	legit-health-medium	Doble autenticación + biométrico	Replicación HSM + export cifrado	Semanal	Zeroización inmediata	—
Alto	legit-health-high	Triple autenticación + biométrico + PIN	Cluster HSM + redundancia geográfica	Diaria	Zeroización inmediata + alerta	Monitoreo 24x7 + custodia dual + VLAN dedicada + firewall

Control de acceso dual

Operaciones críticas con control dual:

• Generación de master keys
• Exportación de claves
• Destrucción de claves
• Cambio de políticas de seguridad
• Acceso a HSM físico

Proceso de control dual:

El sistema debe implementar el siguiente proceso para operaciones críticas:

1. Solicitar primera autorización: La persona que inicia la operación debe autenticarse y solicitar permiso
2. Solicitar segunda autorización: Una segunda persona diferente debe aprobar la operación; el sistema debe excluir automáticamente al iniciador de la lista de aprobadores
3. Verificar autorizaciones: Confirmar que ambas autorizaciones son válidas y provienen de personas autorizadas
4. Ejecutar con límite temporal:
   • La operación debe completarse dentro de una ventana de 30 minutos
   • Ejecutar la operación crítica
   • Registrar en auditoría los dos autorizadores, la operación y el resultado
5. Gestión de errores: Si la autorización dual falla, denegar la operación y alertar al equipo de seguridad

Escrow de claves

Procedimiento de escrow (solo claves críticas):

Claves elegibles para escrow:

• Master encryption keys
• Disaster recovery keys
• Legal hold keys

Método de escrow:

• División: Shamir's Secret Sharing (se requieren 3 de 5 fragmentos para recuperar)
• Almacenamiento de fragmentos:
  1. Fragmento 1: Caja de seguridad bancaria
  2. Fragmento 2: Despacho legal externo
  3. Fragmento 3: Caja fuerte ejecutiva
  4. Fragmento 4: Auditor externo
  5. Fragmento 5: Backup cloud (cifrado)

Proceso de recuperación:

• Aprobaciones requeridas: CEO + CFO + Legal
• Testigos: Auditor externo presente
• Documentación: Acta notarizada
• Verificación: Videollamada multi-parte para confirmar identidades

Protección física de material criptográfico

HSM físico

Medidas de seguridad física del HSM:

Aspecto	Requisito
Ubicación	Jaula segura dentro del datacenter
Control de Acceso	Biométrico + smartcard
Monitoreo	CCTV 24/7 con grabación
Temperatura	18-22°C controlada
Humedad	45-55% controlada
Supresión de Incendios	Sistema FM-200
Protección contra Manipulación	• Sensor de malla • Zeroización automática si se detecta manipulación • Logs de auditoría enviados a sistema remoto

Transporte de material criptográfico

Protocolo de transporte seguro:

1. Doble contenedor sellado
2. Courier bonificado con seguro
3. Tracking GPS en tiempo real
4. Verificación de integridad en destino
5. Destrucción de contenedores usados

Gestión de certificados digitales

Infraestructura PKI

Arquitectura de PKI

Componente	Características
CA Raíz	• HSM offline • Validez: 20 años • RSA 4096 / ECC P-521
CA Intermedia	• HSM online • Validez: 10 años • Emite certificados de entidad final

Tipos de certificados y validez

Tipo de Certificado	Período de Validez	Renovación
TLS/SSL	90 días	Automática
Firma de Código	1 año	Manual con aprobación
Email (S/MIME)	1 año	Automática con validación
Dispositivo	2 años	Manual coordinada
Autenticación de Usuario	1 año	Automática

Ciclo de vida de certificados

Monitoreo de certificados:

El sistema debe monitorear continuamente todos los certificados y tomar acciones según su estado de expiración:

Días hasta Expiración	Acción
Expirado (< 0 días)	• Alertar inmediatamente de certificado expirado • Deshabilitar el certificado • Escalar a equipo de seguridad
Renovación urgente (< 30 días)	• Si auto-renovable: ejecutar renovación automática • Si manual: notificar que se requiere renovación manual inmediata
Advertencia temprana (< 60 días)	• Enviar advertencia de próxima expiración • Notificar al responsable del certificado

Proceso de renovación automática:

1. Generar CSR: Crear una nueva solicitud de certificado (CSR) con el mismo sujeto y especificaciones de clave
2. Solicitar nuevo certificado: Enviar CSR a la CA para emisión del nuevo certificado
3. Instalar con período de overlap: Instalar el nuevo certificado permitiendo 7 días de coexistencia con el antiguo
4. Programar desactivación: Programar la desactivación del certificado antiguo después de 7 días

Este proceso garantiza renovación continua sin interrupción del servicio.

Auditoría y cumplimiento

Registros de auditoría

Eventos registrados según ENS:

Cada evento de gestión de claves debe registrarse con los siguientes metadatos:

Información básica del evento:

• Timestamp (ISO 8601)
• Tipo de evento (ej: KEY_GENERATION, KEY_ROTATION, KEY_DESTRUCTION)
• ID de la clave
• Clasificación ENS (BÁSICO/MEDIO/ALTO)
• Algoritmo utilizado
• Propósito de la clave

Contexto médico (si aplica):

• Clase del dispositivo médico
• Impacto en pacientes (directo/indirecto)
• Requisito regulatorio (ej: MDR Artículo 17)

Información de usuarios:

• Solicitante: ID de usuario, rol, nivel de autenticación (ej: MFA + biométrico)
• Aprobador: ID de usuario, rol, método de aprobación (ej: control dual)

Contexto de origen:

• Dirección IP
• Ubicación física del datacenter
• ID de sesión

Detalles del HSM:

• Número de serie del HSM
• Partición utilizada
• Versión de firmware
• Nivel FIPS

Resultado y cumplimiento:

• Resultado de la operación (SUCCESS/FAILURE)
• Cumplimiento con CCN-STIC-807
• Longitud de clave
• Fecha de expiración
• Calendario de rotación
• Backup creado (sí/no)
• Escrow requerido (sí/no)
• Retención de auditoría (7 años según ENS)

Referencias de integración:

• Análisis de riesgos (ej: R-TF-013-002)
• Modelo de amenazas (ej: T-024-006)
• Control ENS aplicable (ej: OP.EXP.11)

Eventos adicionales para dispositivos médicos:

Tipo de Evento	Descripción	Campos Obligatorios
CLINICAL_KEY_USAGE	Uso de claves en contexto clínico	• ID anonimizado de paciente • Procedimiento clínico • Proveedor de salud • Impacto en precisión diagnóstica
REGULATORY_NOTIFICATION	Notificación a autoridades regulatorias	• Autoridad competente • Tipo de notificación • Plazo regulatorio • Estado de cumplimiento
KEY_ESCROW_ACCESS	Acceso a claves en escrow	• Justificación legal • Referencia de orden judicial • Lista de testigos • Sujetos de datos afectados

Inventario Completo de Claves Criptográficas

Template de inventario según RD 311/2022:

El Administrador de Claves debe generar periódicamente un inventario completo que incluya:

Metadatos del inventario:

• Fecha de generación
• Nivel ENS de la organización
• Categoría del sistema (ej: Dispositivo Médico Clase IIa)
• Período de auditoría
• Marcos de cumplimiento aplicables (ENS, MDR, ISO 27001)

Resumen ejecutivo:

• Total de claves
• Claves activas
• Claves expiradas
• Claves pendientes de rotación
• Claves en HSM vs software
• Puntuación de cumplimiento

Categorías de claves a inventariar:

1. Master keys
2. Patient data keys
3. AI model keys
4. Communication keys
5. Backup keys
6. Administrative keys

Análisis por categoría:

Para cada categoría, documentar:

• Cantidad de claves
• Algoritmos utilizados y frecuencia de cada uno
• Fortaleza de claves (débil/adecuada/fuerte)
• Estado de rotación:
  • Al día
  • Próximas a rotar
  • Vencidas
• Ubicaciones de almacenamiento (HSM, KMS, Vault, etc.)
• Problemas de cumplimiento identificados

Evaluación de cumplimiento:

• Identificar brechas de cumplimiento
• Calcular puntuación general
• Generar recomendaciones de mejora

Este inventario debe actualizarse trimestralmente y estar disponible para auditorías ENS.

Registro R-110-003 - Inventario de Claves Criptográficas:

Ejemplo de contenido del inventario R-110-003

El inventario R-110-003 debe incluir las siguientes secciones:

Información General:

• Fecha de inventario
• Período de auditoría
• Responsable (Administrador de Claves ENS)
• Nivel de clasificación: CONFIDENCIAL

Resumen Ejecutivo:

Tabla con métricas clave:

• Total de claves activas
• Claves próximas a rotación (30 días)
• Claves vencidas
• Cumplimiento CCN-STIC-807 (%)
• Claves en HSM (número y porcentaje)
• Algoritmos no aprobados

Inventario por Categoría:

Para cada categoría (Claves Maestras, Claves de Datos de Pacientes, Claves de Modelos IA, etc.), incluir tabla con:

• ID de la clave
• Algoritmo
• Fecha de creación
• Próxima rotación
• Propósito/Uso
• Datos afectados (si aplica)
• Estado (Activa/Inactiva/Comprometida)

Este registro debe actualizarse trimestralmente y almacenarse de forma segura con acceso restringido.

Métricas de seguridad

Métrica	Objetivo	Actual	Estado
Claves rotadas a tiempo	100%	98%	⚠️
Certificados expirados	0	0	✅
Accesos no autorizados	0	0	✅
Tiempo generación claves	<5s	3.2s	✅
Disponibilidad HSM	99.99%	99.95%	✅
Claves sin uso >90 días	<5%	8%	⚠️

Respuesta a incidentes

Compromiso de claves

Procedimiento de respuesta inmediata:

El equipo de seguridad debe ejecutar los siguientes pasos inmediatamente al detectar un compromiso de claves:

1. Revocación inmediata: Revocar la clave comprometida en todos los sistemas
2. Notificación urgente: Alertar al equipo de seguridad indicando el tipo de incidente (KEY_COMPROMISE) y la clave afectada
3. Evaluación de impacto: Identificar todos los datos y sistemas que utilizan o han utilizado esta clave
4. Rotación de emergencia: Generar y activar una nueva clave de reemplazo inmediatamente
5. Re-cifrado de datos: Re-cifrar todos los datos afectados con la nueva clave
6. Investigación forense:
   • Analizar los últimos 7 días de actividad
   • Revisar: logs de acceso, tráfico de red, logs del sistema
   • Identificar cómo ocurrió el compromiso
7. Notificaciones regulatorias:
   • Si afecta datos personales: Notificar a la AEPD dentro de 72 horas
   • Si afecta dispositivo médico: Notificar a las autoridades competentes (AEMPS)
8. Documentación: Crear informe completo del incidente incluyendo:
   • ID de clave comprometida
   • Hora de detección
   • Impacto evaluado
   • Nueva clave de reemplazo
   • Resultados del análisis forense
   • Acciones correctivas implementadas

Todo el proceso debe documentarse según el procedimiento OP.EXP.7 de gestión de incidentes.

Procedimientos operativos

Backup de claves

Estrategia de backup:

Aspecto	Requisito
Frecuencia	• Incremental: Diario • Completo: Semanal
Métodos	• Primario: Replicación de cluster HSM • Secundario: Export cifrado a almacenamiento frío • Terciario: Backup en papel (códigos QR) en caja fuerte
Verificación	• Test de restauración: Mensual • Simulacro de recuperación completa: Trimestral • Auditoría externa: Anual
Ubicaciones de Almacenamiento	• Online: Cloud multi-región • Nearline: Bóveda del datacenter local • Offline: Caja de seguridad bancaria

Procedimientos de Recuperación de Claves

Procedimiento de escrow y recuperación según ENS:

Creación de escrow de claves:

El proceso de escrow debe aplicarse solo a claves críticas y esenciales:

1. Validar criticidad: Solo claves "críticas" o "esenciales" van a escrow (las "importantes" no)

2. Exportar clave del HSM temporalmente de forma segura

3. Configurar Shamir's Secret Sharing:

   • Críticas: 5 de 7 fragmentos necesarios
   • Esenciales: 3 de 5 fragmentos necesarios

4. Generar y distribuir fragmentos:

   • Dividir la clave en fragmentos
   • Para cada fragmento:
     • Seleccionar custodio apropiado
     • Cifrar con clave del custodio
     • Almacenar en ubicación segura
     • Documentar: número, custodio, ubicación, fecha, hash de verificación

5. Crear registro de escrow con:

   • IDs (clave original y escrow)
   • Criticidad y configuración Shamir
   • Lista de fragmentos y custodios
   • Autoridad legal supervisora
   • Retención: 7 años
   • Marcos: ENS, MDR

6. Generar certificado y registrar en inventario

Recuperación desde escrow:

1. Validar autorización: Verificar autorizaciones múltiples válidas
2. Obtener registro del escrow
3. Verificar custodios disponibles: Deben ser suficientes para el umbral
4. Solicitar fragmentos a custodios con autorización
5. Verificar integridad de cada fragmento (hash)
6. Reconstruir clave usando Shamir
7. Importar a HSM con nuevo ID
8. Documentar: IDs, timestamp, autorizadores, custodios, base legal

Este procedimiento garantiza que ninguna persona individual pueda recuperar claves críticas.

Recuperación de desastres

Plan de recuperación de claves:

1. Activar HSM de respaldo
2. Restaurar master keys desde quórum
3. Re-generar claves operacionales
4. Verificar integridad de datos
5. Restablecer servicios por prioridad
6. Auditoría post-recuperación

Formación y concienciación

Programa de formación:

• Básico (todos): Importancia de protección de claves
• Intermedio (IT): Uso seguro de claves y certificados
• Avanzado (Security): Gestión de HSM y PKI
• Especializado (Key Custodians): Procedimientos de escrow y recuperación

Integración con otros controles ENS

• MP.SW.2: Claves para firma de código
• MP.COM: Certificados TLS/SSL
• MP.SI.2: Cifrado de soportes
• OP.ACC.5: Claves de autenticación fuerte
• OP.EXP.10: Firma de logs de auditoría

Documentación y registros

• T-024-018: Procedimiento completo de gestión
• T-024-019: Política de uso aprobada
• T-024-020: Inventario actualizado de claves
• R-110-003: Inventario de claves criptográficas ENS
• Registros de auditoría: Todos los eventos de claves
• Certificados de destrucción: Archivo permanente
• Informes de rotación: Evidencia de cumplimiento
• Certificados de escrow: Documentación legal de custodia
• Registros de recuperación: Evidencia de accesos a escrow
• Informes de cumplimiento CCN-STIC-807: Evaluaciones periódicas

Referencias cruzadas ENS e integración

Integración con otros controles ENS

Control ENS	Relación	Descripción de integración
OP.EXP.7	Gestión de incidentes	Respuesta a compromiso de claves
OP.EXP.10	Registros de actividad	Firma criptográfica de logs
OP.ACC.5	Autenticación	Claves para MFA y certificados
MP.COM.2	Protección comunicaciones	Certificados TLS/SSL
MP.SW.2	Aceptación aplicaciones	Firma digital de código
MP.SI.2	Eliminación de soportes	Claves de cifrado de medios
OP.CONT.2	Plan de continuidad	Backup y recuperación de claves

Referencias a documentación ENS

• T-110-007: Matriz RACI - Roles en gestión de claves
• T-110-008: CCN-CERT - Notificación de incidentes criptográficos
• ORG.1: Política de seguridad - Marco para políticas de claves
• OP.PL.1: Análisis de riesgos - Riesgos criptográficos
• OP.PL.2: Arquitectura de seguridad - Integración de HSM

Cumplimiento regulatorio médico

Integración con regulación de dispositivos médicos:

Regulación	Artículo/Sección	Aplicación de Claves Criptográficas
MDR 2017/745	• Artículo 17 (Sistemas de gestión de calidad) • Anexo I 17.2 (Medidas de seguridad IT)	Claves para protección de datos clínicos
IEC 62304	• Sección 5.5 (Integración y testing) • Sección 7 (Procesos de gestión de riesgos del software)	Claves para firma de software médico
ISO 14971	• Cláusula 4.3 (Gestión de riesgos de dispositivos médicos) • Cláusula 7 (Evaluación y control de riesgos)	Integración de riesgos criptográficos en análisis general de riesgos
FDA Cybersecurity Guidance	• Premarket: Documentación de controles • Postmarket: Gestión de vulnerabilidades	Validación de implementación criptográfica

Métricas de efectividad ENS

KPIs específicos de cumplimiento ENS

Cálculo de puntuación de cumplimiento ENS:

El Administrador de Claves debe evaluar periódicamente el cumplimiento mediante las siguientes métricas:

Métricas individuales a evaluar:

• Cumplimiento de algoritmos: Verificar que todos los algoritmos utilizados están aprobados por CCN-STIC-807
• Cumplimiento de longitud de claves: Confirmar que todas las claves cumplen los tamaños mínimos según nivel ENS
• Cumplimiento de rotación: Verificar que las claves se rotan en los plazos establecidos
• Cumplimiento de uso de HSM: Confirmar que las claves críticas están en HSM certificado
• Cumplimiento de backup: Verificar que existen backups válidos y probados
• Cumplimiento de auditoría: Confirmar que todos los eventos se registran correctamente

Ponderación para puntuación global:

Métrica	Peso	Justificación
Cumplimiento de algoritmos	25%	Crítico para la seguridad fundamental
Cumplimiento de longitud de claves	20%	Esencial para resistencia criptográfica
Cumplimiento de rotación	20%	Esencial para limitar exposición temporal
Cumplimiento de uso de HSM	15%	Importante para protección física
Cumplimiento de backup	10%	Importante para continuidad
Cumplimiento de auditoría	10%	Importante para trazabilidad

Resultado del cálculo:

• Puntuación global (0-100%)
• Métricas individuales detalladas
• Nivel de cumplimiento determinado (Básico/Medio/Alto)
• Áreas identificadas para mejora

Métricas operacionales

Métrica ENS	Objetivo	Medición	Responsable
Cumplimiento CCN-STIC-807	100%	Mensual	Key Administrator
Rotación de claves en plazo	>98%	Automática	System
Disponibilidad HSM	>99.9%	Continua	Infrastructure Team
Tiempo de recuperación de escrow	<4 horas	Por evento	Security Team
Auditorías de claves completadas	100%	Trimestral	Compliance Team
Certificados próximos a vencer	0	Diaria	Certificate Manager
Incidentes criptográficos	0	Por evento	CISO

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

• Author: Team members involved
• Reviewer: JD-003, JD-004
• Approver: JD-001