OP.AAC.5 Mecanismo de autenticación

Objetivo

Establecer los mecanismos de autenticación robustos y multinivel para el sistema Legit Health Plus, garantizando la verificación fidedigna de la identidad de usuarios y sistemas mediante métodos apropiados al nivel de riesgo, cumpliendo con ENS, MDR y estándares de ciberseguridad para dispositivos médicos.

Alcance

Este procedimiento aplica a:

• Autenticación de profesionales sanitarios y personal administrativo
• Autenticación de sistemas y servicios automatizados
• Autenticación para integraciones API y servicios externos
• Mecanismos de autenticación multifactor (MFA)
• Gestión de credenciales y secretos
• Autenticación federada y Single Sign-On (SSO)

Implementación en Legit Health Plus

Arquitectura de Autenticación

Niveles de Autenticación según Criticidad

Nivel	Contexto de Uso	Métodos Requeridos	Factores	Ejemplo
Nivel 1 - Básico	Acceso a información pública	Password robusto	1 factor	Documentación, estadísticas
Nivel 2 - Medio	Acceso a datos no críticos	Password + MFA	2 factores	Informes agregados
Nivel 3 - Alto	Acceso a datos de pacientes	Password + MFA + Contexto	2+ factores	Historiales clínicos
Nivel 4 - Crítico	Modificación de algoritmos IA	Certificado + MFA + Biometría	3 factores	Cambios en modelos diagnósticos
Nivel 5 - Máximo	Acceso administrativo total	Hardware token + Biometría + PIN	3+ factores	Root access, PKI management

Implementación de Autenticación Multifactor (MFA)

Configuración MFA por Rol

Requisitos de Autenticación Multifactor por Tipo de Usuario

Rol	Métodos Permitidos	MFA Obligatorio	Período Gracia	Recordar Dispositivo	Evaluación Basada en Riesgo	Configuración Adicional
Profesionales Sanitarios (HCP)	TOTP, SMS, Push	Sí	0 días	7 días	Sí	-
Profesionales IT (ITP)	Token Hardware, TOTP	Sí	0 días	No	No	-
Administradores (ADMIN)	Token Hardware, Biométrico	Sí	0 días	No	No	Timeout sesión: 15 minutos
Clientes API (API)	Certificado Cliente	Sí	N/A	N/A	No	Mutual TLS requerido

Leyenda de métodos MFA:

• TOTP: Time-based One-Time Password (aplicaciones como Google Authenticator, Authy)
• SMS: Código de verificación enviado por mensaje de texto
• Push: Notificación push a aplicación móvil autenticada
• Token Hardware: Dispositivo físico generador de tokens (ej: YubiKey)
• Biométrico: Huella digital, reconocimiento facial
• Certificado Cliente: Certificado digital X.509 para autenticación mTLS

---

PRO-AUTH-001: Aplicación de MFA Basada en Rol y Contexto

Objetivo: Determinar si se debe requerir autenticación multifactor para un intento de inicio de sesión específico, considerando el rol del usuario y el contexto de la autenticación.

Pasos:

1. Obtener configuración MFA del rol:

   • Identificar el rol del usuario (HCP, ITP, ADMIN, API)
   • Consultar requisitos MFA para ese rol en tabla de configuración

2. Verificar si MFA es obligatorio para el rol:

   • Si MFA NO es obligatorio para el rol: PERMITIR acceso sin MFA
   • Si MFA ES obligatorio: Continuar evaluación

3. Evaluar contexto basado en riesgo (si aplica al rol):

   • Solo para roles con evaluación basada en riesgo activada (HCP)
   • Calcular puntuación de riesgo del contexto (ver PRO-AUTH-002)
   • Si puntuación de riesgo > 0.7 (70%): REQUERIR MFA obligatoriamente
   • Si puntuación ≤ 0.7: Continuar evaluación

4. Verificar dispositivo recordado (si aplica):

   • Solo si el rol permite recordar dispositivos (HCP: 7 días)
   • Consultar si el dispositivo está en la lista de dispositivos recordados
   • Verificar que no haya expirado el período de confianza
   • Si dispositivo es recordado y válido: PERMITIR sin MFA
   • Si no: REQUERIR MFA

5. Decisión final:

   • Si llegamos aquí: REQUERIR MFA

Resultado: Decisión de si requerir o no MFA para el intento de autenticación

---

PRO-AUTH-002: Cálculo de Puntuación de Riesgo de Autenticación

Objetivo: Calcular una puntuación de riesgo (0.0 a 1.0) basada en el contexto del intento de autenticación.

Factores de riesgo evaluados:

1. Nueva ubicación geográfica (+0.3 puntos):

   • El usuario intenta acceder desde un país o región no utilizado anteriormente
   • Se compara con historial de ubicaciones del usuario

2. Dispositivo desconocido (+0.2 puntos):

   • El dispositivo (identificado por fingerprint) no ha sido usado previamente por este usuario
   • No está registrado en la lista de dispositivos conocidos

3. Hora inusual (+0.2 puntos):

   • El intento de acceso ocurre fuera del horario habitual del usuario
   • Se compara con patrón histórico de horas de acceso (ej: acceso a las 3 AM cuando normalmente accede de 8 AM a 6 PM)

4. Patrón de acceso anómalo (+0.3 puntos):

   • El sistema de detección de anomalías ha identificado comportamiento sospechoso
   • Ejemplos: múltiples intentos fallidos previos, velocidad de viaje imposible, cambio brusco de patrones

Cálculo:

1. Inicializar puntuación = 0.0
2. Evaluar cada factor:
   • Si el factor está presente: Sumar el valor de riesgo correspondiente
   • Si no está presente: No sumar nada
3. Limitar puntuación máxima a 1.0 (100%)

Interpretación de puntuaciones:

• 0.0 - 0.3: Riesgo bajo - Contexto normal
• 0.4 - 0.6: Riesgo medio - Requiere atención
• 0.7 - 1.0: Riesgo alto - Requiere MFA obligatoriamente

Resultado: Puntuación de riesgo entre 0.0 y 1.0

Políticas de Contraseñas

Requisitos de Complejidad

Parámetro	Usuario Estándar	Usuario Privilegiado	Administrador
Longitud mínima	12 caracteres	15 caracteres	20 caracteres
Mayúsculas	Mínimo 1	Mínimo 2	Mínimo 3
Minúsculas	Mínimo 1	Mínimo 2	Mínimo 3
Números	Mínimo 1	Mínimo 2	Mínimo 3
Caracteres especiales	Mínimo 1	Mínimo 2	Mínimo 3
Historial	Últimas 12	Últimas 24	Últimas 36
Expiración	90 días	60 días	30 días
Intentos fallidos	5	3	3
Bloqueo	30 minutos	60 minutos	Manual

Implementación de Políticas

PRO-AUTH-003: Validación de Contraseñas

Objetivo: Verificar que una contraseña propuesta cumple con los requisitos de complejidad según el tipo de usuario.

Pasos de validación:

1. Identificar política aplicable:

   • Determinar tipo de usuario (estándar, privilegiado, administrador)
   • Consultar requisitos en tabla de complejidad

2. Validar longitud mínima:

   • Contar caracteres totales de la contraseña
   • Comparar con longitud mínima requerida
   • Si es menor: Agregar error "Mínimo X caracteres"

3. Validar mayúsculas:

   • Contar letras mayúsculas (A-Z)
   • Comparar con cantidad mínima requerida
   • Si es insuficiente: Agregar error "Mínimo X mayúsculas"

4. Validar minúsculas:

   • Contar letras minúsculas (a-z)
   • Comparar con cantidad mínima requerida
   • Si es insuficiente: Agregar error "Mínimo X minúsculas"

5. Validar números:

   • Contar dígitos (0-9)
   • Comparar con cantidad mínima requerida
   • Si es insuficiente: Agregar error "Mínimo X números"

6. Validar caracteres especiales:

   • Contar caracteres especiales (!@#$%^&*(),.?":|<>)
   • Comparar con cantidad mínima requerida
   • Si es insuficiente: Agregar error "Mínimo X caracteres especiales"

7. Verificar contra diccionario de contraseñas comunes:

   • Consultar lista de contraseñas frecuentemente comprometidas
   • Ejemplos: "Password123!", "Qwerty123!", "Admin2024!"
   • Si coincide: Agregar error "Contraseña demasiado común"

8. Detectar patrones predecibles:

   • Buscar secuencias consecutivas (123456, abcdef)
   • Buscar patrones de teclado (qwerty, asdfgh)
   • Buscar repeticiones excesivas (aaaaaa, 111111)
   • Buscar información personal obvia (nombre+año)
   • Si se detecta patrón: Agregar error "Contraseña contiene patrones predecibles"

9. Generar resultado:

   • Si no hay errores: ACEPTAR contraseña
   • Si hay errores: RECHAZAR y devolver lista de errores para corrección

Resultado: Contraseña aceptada o rechazada con lista de errores

---

PRO-AUTH-004: Generación de Contraseñas Seguras

Objetivo: Generar una contraseña aleatoria que cumpla automáticamente con todos los requisitos de seguridad.

Método de generación:

1. Obtener requisitos del tipo de usuario:

   • Consultar política correspondiente (estándar/privilegiado/administrador)
   • Extraer requisitos mínimos de cada tipo de carácter

2. Definir conjuntos de caracteres:

   • Mayúsculas: A-Z (26 caracteres)
   • Minúsculas: a-z (26 caracteres)
   • Números: 0-9 (10 caracteres)
   • Especiales: !@#$%^&*(),.?":|<> (20 caracteres)

3. Garantizar requisitos mínimos:

   • Seleccionar aleatoriamente X mayúsculas (según requisito)
   • Seleccionar aleatoriamente X minúsculas (según requisito)
   • Seleccionar aleatoriamente X números (según requisito)
   • Seleccionar aleatoriamente X caracteres especiales (según requisito)
   • Usar generador criptográficamente seguro para selección

4. Completar longitud requerida:

   • Calcular caracteres restantes = Longitud mínima - Caracteres ya seleccionados
   • Seleccionar aleatoriamente de todos los conjuntos para completar
   • Mantener aleatoriedad criptográficamente segura

5. Aleatorizar orden:

   • Mezclar todos los caracteres usando algoritmo de shuffling criptográfico
   • Evitar que los caracteres requeridos aparezcan siempre al inicio
   • Garantizar distribución uniforme

6. Formar contraseña final:

   • Unir todos los caracteres en orden aleatorizado
   • Verificar que cumple todos los requisitos (paso de validación)
   • Si no cumple (caso extremadamente raro): Regenerar

Resultado: Contraseña segura generada automáticamente

Ejemplo de contraseña generada para administrador (20 caracteres):

• Cumple: 3 mayúsculas, 3 minúsculas, 3 números, 3 especiales + 8 caracteres adicionales aleatorios
• Orden completamente aleatorio
• No contiene patrones predecibles

Autenticación Federada y SSO

Proveedores de Identidad Soportados

Proveedor	Protocolo	Uso Principal	Configuración
Azure AD	SAML 2.0 / OIDC	Hospitales con Microsoft	Federación completa
Google Workspace	OAuth 2.0 / OIDC	Clínicas pequeñas	SSO simplificado
Okta	SAML 2.0 / OIDC	Empresas sanitarias	Integración avanzada
Custom LDAP	LDAP/LDAPS	Sistemas legacy	Bridge authentication
DNIe / Certificados	X.509	Administración pública	PKI nacional

Gestión de Sesiones

Parámetros de Sesión

Configuración de Sesiones por Tipo de Usuario

Tipo de Usuario	Timeout Inactividad	Timeout Absoluto	Sesiones Concurrentes	Aviso de Inactividad	Configuración Adicional
Usuario Estándar	30 minutos	8 horas	3 sesiones	5 minutos antes	-
Usuario Privilegiado	15 minutos	4 horas	1 sesión	2 minutos antes	-
Cliente API	Token: 60 minutos	Refresh: 7 días	N/A	N/A	Rate limit: 100 req/min

Definiciones:

• Timeout Inactividad: Tiempo máximo sin actividad antes de cerrar sesión automáticamente
• Timeout Absoluto: Tiempo máximo total de sesión, independientemente de la actividad (requiere re-autenticación)
• Sesiones Concurrentes: Número máximo de sesiones simultáneas permitidas para el mismo usuario
• Aviso de Inactividad: Notificación previa al cierre por timeout, permite al usuario extender la sesión
• Token Expiry: Duración de validez del token de acceso para APIs
• Refresh Token: Duración del token de renovación antes de requerir re-autenticación completa
• Rate Limit: Número máximo de peticiones API permitidas por minuto

Procedimientos

PRO-AAC-013: Configuración Inicial de Autenticación

1. Provisión de Credenciales

   • Generación de credenciales temporales
   • Envío por canal seguro
   • Activación con cambio obligatorio
   • Configuración de MFA

2. Verificación de Identidad

   • Validación documental
   • Confirmación telefónica
   • Activación presencial si crítico

3. Registro de Factores

   • Configuración de TOTP
   • Registro biométrico si aplica
   • Backup codes generation

PRO-AAC-015: Gestión de Privilegios de Administración

1. Clasificación de Accesos Privilegiados

Nivel de Privilegio	Descripción	Autenticación Requerida	Revisión
Super Admin	Acceso root completo a infraestructura	Hardware Token + Biometría + PIN	Semanal
System Admin	Administración de sistemas operativos	Hardware Token + MFA	Quincenal
DB Admin	Gestión de bases de datos clínicas	Certificado + MFA	Quincenal
Security Admin	Configuración de seguridad	Hardware Token + MFA	Semanal
Application Admin	Configuración de aplicaciones	MFA + Aprobación	Mensual

2. Procedimiento de Elevación de Privilegios

PRO-AUTH-005: Solicitud de Elevación Temporal de Privilegios

Objetivo: Gestionar la solicitud de elevación temporal de privilegios para realizar tareas administrativas específicas.

Duración por defecto: 4 horas (configurable según necesidad justificada)

Pasos:

1. Validar elegibilidad del usuario:

   • Verificar que el usuario tiene autorización base para solicitar el nivel de privilegio
   • Consultar lista de usuarios autorizados para cada nivel
   • Si NO es elegible: RECHAZAR con mensaje "Usuario no elegible para este nivel"

2. Verificar MFA adicional para privilegios críticos:

   • Solo para niveles críticos: Super Admin, Security Admin
   • Solicitar factor de autenticación adicional (token hardware, biométrico)
   • Verificar respuesta MFA adicional
   • Si falla MFA adicional: RECHAZAR con mensaje "MFA adicional requerida"

3. Crear solicitud de elevación:

   • Generar ID único de solicitud (formato: REQ-ELEV-YYYY-NNNN)
   • Registrar ID del usuario solicitante
   • Registrar nivel de privilegio solicitado
   • Registrar justificación del negocio (obligatoria)
   • Registrar duración solicitada (en horas)
   • Anotar timestamp de la solicitud
   • Establecer estado inicial: "PENDIENTE DE APROBACIÓN"

4. Determinar si requiere aprobación:

   • Consultar matriz de aprobaciones según nivel de privilegio
   • Niveles que requieren aprobación: Super Admin, Security Admin, System Admin
   • Niveles sin aprobación: Application Admin (si duración ≤ 4 horas)

5. Procesar según requisito de aprobación:

   • Si requiere aprobación:
     • Enviar solicitud a aprobadores designados (ver tabla de tipos de cuentas)
     • Notificar al solicitante: "Solicitud enviada para aprobación"
     • Retornar ID de solicitud para seguimiento
   • Si NO requiere aprobación:
     • Proceder directamente a concesión (PRO-AUTH-006)
     • Retornar token de sesión privilegiada

Resultado: Solicitud creada y procesada según requisitos de aprobación

---

PRO-AUTH-006: Concesión de Elevación de Privilegios

Objetivo: Conceder la elevación de privilegios una vez aprobada la solicitud (o si no requiere aprobación).

Prerequisito: La solicitud debe estar aprobada por los responsables requeridos (si aplica).

Pasos:

1. Crear token de sesión privilegiada:

   • Generar token único criptográficamente seguro
   • Asociar token al ID del usuario
   • Asignar nivel de privilegio concedido
   • Establecer duración de validez (según solicitud)
   • Incluir timestamp de creación
   • Marcar como sesión privilegiada (para auditoría diferenciada)

2. Registrar actividad de elevación:

   • Guardar registro completo en log de auditoría:
     • ID de solicitud
     • Usuario beneficiario
     • Nivel de privilegio concedido
     • Duración concedida
     • Aprobadores (si aplica)
     • Justificación
     • Timestamp de concesión
     • Estado: "CONCEDIDO"
   • Generar alerta para equipo de seguridad
   • Notificar al usuario: "Privilegios elevados activados"

3. Programar revocación automática:

   • Calcular timestamp de expiración = Ahora + Duración solicitada
   • Crear tarea programada de revocación
   • Configurar alertas previas:
     • 30 minutos antes: Aviso al usuario
     • 5 minutos antes: Aviso final al usuario
   • Al expirar: Revocar token automáticamente (PRO-ACC-005)

4. Entregar token al usuario:

   • Proporcionar token de sesión privilegiada al usuario
   • Incluir instrucciones de uso
   • Recordar duración limitada
   • Indicar responsabilidades adicionales

Resultado: Privilegios elevados concedidos temporalmente con revocación automática programada

Seguimiento post-elevación:

• Monitoreo continuo de actividad privilegiada
• Revisión obligatoria de logs tras expiración
• Documentación de acciones realizadas (responsabilidad del usuario)

3. Just-In-Time (JIT) Access Management

Configuración JIT por Sistema:

Sistema	Duración Máxima	Aprobación Requerida	Aprobadores	MFA Adicional	Controles Especiales
Base de Datos Producción	2 horas	Sí	DB Lead + Security Lead	Sí	Grabación de sesión completa
Kubernetes Cluster	4 horas	Sí	DevOps Lead	Sí	Comandos permitidos: kubectl get, kubectl describe únicamente
AWS Producción	1 hora	Sí	Cloud Architect + Security Lead	Sí	Role assumption: arn:aws:iam::account:role/emergency-access

Principios del Acceso Just-In-Time:

• Duración limitada: Los accesos son temporales y se revocan automáticamente al expirar
• Aprobación obligatoria: Todos los sistemas críticos requieren aprobación previa
• MFA adicional: Se requiere factor adicional de autenticación más allá del login normal
• Grabación de sesión: Las sesiones privilegiadas se graban para auditoría
• Whitelist de comandos: Algunos sistemas limitan los comandos permitidos para minimizar riesgo
• Least privilege: Se concede solo el nivel mínimo necesario para la tarea específica

PRO-AAC-016: Revisiones Obligatorias de Acceso

1. Calendario de Revisiones

Tipo de Acceso	Frecuencia	Responsable	Herramienta
Accesos Privilegiados	Semanal	Security Admin	PAM Dashboard
Accesos Clínicos	Mensual	Clinical Lead	Access Review Portal
Accesos API	Quincenal	API Manager	API Gateway Console
Accesos Externos	Mensual	Partnership Manager	Identity Provider
Cuentas de Servicio	Trimestral	DevOps Lead	Service Account Audit

2. Proceso de Revisión Automatizada

PRO-AUTH-007: Generación de Informe de Revisión de Accesos

Objetivo: Generar un informe completo de revisión de accesos para un período específico.

Período por defecto: 30 días

Pasos:

1. Definir alcance de la revisión:

   • Establecer tipo de revisión (cuentas privilegiadas, usuarios estándar, cuentas de servicio, etc.)
   • Definir fecha de inicio del período (fecha actual - X días)
   • Definir fecha de fin del período (fecha actual)
   • Documentar alcance en el informe

2. Inicializar estructura del informe:

   • Tipo de revisión realizada
   • Período analizado (fechas inicio y fin)
   • Contadores inicializados a cero:
     • Total de cuentas analizadas
     • Cuentas activas
     • Cuentas inactivas
     • Cuentas privilegiadas
   • Lista de anomalías detectadas (inicialmente vacía)
   • Lista de recomendaciones (inicialmente vacía)

3. Obtener datos de acceso del período:

   • Extraer registros de autenticación y actividad
   • Filtrar por tipo de revisión especificado
   • Filtrar por rango de fechas del período
   • Consolidar datos de múltiples fuentes si necesario

4. Analizar cada cuenta individualmente:

   Para cada cuenta en los datos:

   a. Incrementar contador total de cuentas analizadas

   b. Evaluar actividad:

   • Verificar si hubo inicio de sesión en el período
   • Si hay actividad: Incrementar contador de cuentas activas
   • Si NO hay actividad: Incrementar contador de cuentas inactivas

   c. Clasificar nivel de privilegio:

   • Determinar si la cuenta tiene privilegios elevados
   • Si es privilegiada: Incrementar contador de cuentas privilegiadas

   d. Detectar anomalías (ver PRO-AUTH-008)

   • Ejecutar detección de anomalías para la cuenta
   • Agregar anomalías encontradas a la lista del informe

5. Generar recomendaciones:

   • Analizar patrones agregados del informe
   • Identificar cuentas inactivas candidatas a desactivación
   • Identificar privilegios excesivos o innecesarios
   • Identificar anomalías de seguridad que requieren acción
   • Proponer acciones correctivas específicas
   • Priorizar recomendaciones por riesgo

6. Completar y entregar informe:

   • Calcular porcentajes y estadísticas agregadas
   • Generar resumen ejecutivo
   • Incluir gráficos de tendencias (si aplica)
   • Entregar informe al responsable designado

Resultado: Informe completo de revisión de accesos con estadísticas, anomalías y recomendaciones

---

PRO-AUTH-008: Detección de Anomalías en Patrones de Acceso

Objetivo: Identificar patrones de acceso anómalos o sospechosos en una cuenta de usuario.

Tipos de anomalías detectadas:

1. Ubicaciones Inusuales:

   • Criterio: Acceso desde país o región no utilizado anteriormente por el usuario
   • Detección: Comparar ubicación de acceso con historial geográfico del usuario
   • Ejemplo de anomalía: Usuario siempre accede desde España, detectado acceso desde China
   • Registro: Tipo: "unusual_location", Cuenta: [ID], Detalles: "Acceso desde: China, Rusia"

2. Horarios Inusuales:

   • Criterio: Acceso fuera del horario laboral habitual del usuario
   • Detección: Comparar hora de acceso con patrón histórico de horarios
   • Ejemplo de anomalía: Usuario normalmente accede 9:00-18:00, detectado acceso a las 03:00
   • Registro: Tipo: "unusual_hours", Cuenta: [ID], Detalles: "Acceso fuera de horario: 03:00, 04:30"

3. Privilegios No Utilizados:

   • Criterio: Usuario tiene permisos asignados que nunca utiliza
   • Detección: Analizar uso de cada privilegio en el período
   • Ejemplo de anomalía: Usuario tiene permiso de admin pero solo realiza operaciones de lectura
   • Registro: Tipo: "unused_privileges", Cuenta: [ID], Detalles: "Privilegios sin usar: admin_write, delete_users"

4. Otros indicadores de anomalía:

   • Múltiples intentos de acceso fallidos seguidos de éxito
   • Velocidad de viaje imposible (acceso desde dos ubicaciones distantes en corto tiempo)
   • Acceso simultáneo desde múltiples ubicaciones
   • Patrón de acceso que difiere significativamente del comportamiento normal
   • Cambios súbitos en el volumen de actividad

Proceso de detección:

1. Para cada cuenta analizada, ejecutar las verificaciones de anomalías
2. Registrar cada anomalía encontrada con:
   • Tipo de anomalía
   • ID de cuenta afectada
   • Detalles específicos de la anomalía
   • Nivel de severidad (bajo/medio/alto)
3. Agregar todas las anomalías a la lista del informe
4. Generar alertas para anomalías de severidad alta

Resultado: Lista de anomalías detectadas para la cuenta

3. Matriz de Certificación de Accesos

Template de Certificación Mensual:

CERTIFICACIÓN DE ACCESOS - MES/AÑO

Resumen Ejecutivo

• Total de cuentas revisadas: TOTAL
• Cuentas activas certificadas: ACTIVAS
• Cuentas desactivadas: DESACTIVADAS
• Anomalías detectadas: ANOMALÍAS
• Acciones correctivas: ACCIONES

Revisión por Tipo de Acceso

Accesos Privilegiados

Usuario	Rol	Último Acceso	Justificación	Acción
user001	DB Admin	2025-08-28	Mantenimiento programado	Mantener
user002	Sys Admin	2025-07-15	Sin actividad reciente	Revocar

Accesos Clínicos

Usuario	Especialidad	Pacientes Accedidos	Justificación	Acción
dr001	Dermatología	45	Actividad normal	Mantener
dr002	Medicina General	2	Baja actividad	Revisar

Certificación de Responsables

• Responsable Seguridad: [Nombre] - [Firma] - [Fecha]
• Responsable Clínico: [Nombre] - [Firma] - [Fecha]
• Responsable IT: [Nombre] - [Firma] - [Fecha]

PRO-AAC-017: Gestión de Cuentas de Servicio

1. Registro de Cuentas de Servicio

Información Requerida para cada Cuenta de Servicio

Cada cuenta de servicio debe estar documentada en el registro con la siguiente información completa:

Información Básica:

• ID de la cuenta: Identificador único de la cuenta de servicio
• Propósito: Descripción clara del uso y función de la cuenta
• Propietario: Equipo o persona responsable de la cuenta
• Fecha de creación: Cuándo se creó la cuenta

Gestión de Credenciales:

• Última rotación: Fecha de la última rotación de credenciales
• Calendario de rotación: Frecuencia establecida (mensual, trimestral, semestral)
• Próxima rotación: Fecha programada para la siguiente rotación

Privilegios y Permisos:

• Lista de privilegios: Permisos específicos asignados a la cuenta
• Justificación: Por qué necesita cada privilegio (principio de mínimo privilegio)
• Nivel de criticidad: Clasificación del impacto si la cuenta se ve comprometida

Restricciones de Red:

• Redes permitidas: Rangos IP desde donde puede autenticarse la cuenta (whitelist)
• Restricciones geográficas: Países o regiones permitidos (si aplica)

Monitoreo y Alertas:

• Alertas de actividad inusual: Si está activado
• Límites de tasa: Máximo de peticiones por minuto/hora
• Umbrales de alerta: Condiciones que generan alertas

Configuración Operativa (si aplica):

• Horario de operación: Cuándo se espera que la cuenta esté activa
• Programación de tareas: Tareas automatizadas que ejecuta

Ejemplos de Registros de Cuentas de Servicio:

Cuenta de Servicio	Propósito	Propietario	Última Rotación	Rotación	Privilegios	Redes Permitidas	Monitoreo
api-gateway-prod	Autenticación API Gateway producción	DevOps Team	01/08/2025	Trimestral	api-gateway-read, cognito-validate	10.0.1.0/24	Alerta actividad inusual, Max: 1000 req/min
backup-service	Servicio automático de backups	Infrastructure Team	15/08/2025	Mensual	s3-backup-write, rds-snapshot	10.0.2.0/24	Ejecución diaria 02:00 UTC

Revisión del Registro:

• Frecuencia: Trimestral
• Responsable: Security Team + Propietarios de cuentas
• Acciones: Verificar vigencia de propósito, validar privilegios necesarios, confirmar rotación de credenciales

2. Rotación Automática de Credenciales

PRO-AUTH-009: Rotación de Credenciales de Cuenta de Servicio

Objetivo: Rotar las credenciales de una cuenta de servicio de forma controlada minimizando el impacto en los servicios dependientes.

Frecuencia: Según calendario establecido (mensual, trimestral, semestral)

Pasos:

1. Generar nuevas credenciales:

   • Crear credenciales nuevas criptográficamente seguras
   • Aplicar los mismos requisitos de complejidad que las contraseñas de usuario
   • Generar par de claves (pública/privada) si se usa autenticación basada en certificados
   • Verificar que las credenciales cumplan las políticas de seguridad

2. Actualizar gestor de secretos:

   • Almacenar las nuevas credenciales en el sistema de gestión de secretos (ej: AWS Secrets Manager, HashiCorp Vault)
   • Marcar la versión de las credenciales
   • Mantener credenciales anteriores temporalmente (no eliminar aún)
   • Verificar que la actualización fue exitosa

3. Actualizar servicios dependientes:

   • Identificar todos los servicios y aplicaciones que usan esta cuenta
   • Notificar a los servicios sobre las nuevas credenciales
   • Actualizar configuración en cada servicio dependiente
   • Verificar que cada servicio puede autenticarse con las nuevas credenciales

4. Período de gracia para actualización:

   • Esperar 5 minutos para permitir que todos los servicios se actualicen
   • Durante este período, ambas credenciales (antigua y nueva) son válidas
   • Monitorear que no haya errores de autenticación
   • Permitir tiempo para que cachés se actualicen

5. Revocar credenciales anteriores:

   • Invalidar las credenciales antiguas
   • Eliminar del gestor de secretos (mantener en histórico de auditoría)
   • Verificar que ningún servicio sigue usando credenciales antiguas
   • Confirmar que no hay errores de autenticación

6. Registrar operación:

   • Documentar rotación exitosa en registro de auditoría
   • Incluir: ID de cuenta, fecha/hora, versión de credenciales, servicios actualizados
   • Actualizar fecha de última rotación en el registro de cuentas de servicio
   • Programar próxima rotación

Manejo de errores:

Si la rotación falla en cualquier paso:

• Registrar el fallo con detalles del error
• Ejecutar procedimiento de rollback:
  • Revertir a credenciales anteriores
  • Notificar a servicios dependientes
  • Mantener credenciales anteriores activas
• Generar alerta para equipo de seguridad
• Investigar causa del fallo antes de reintentar

Resultado: Credenciales rotadas exitosamente o rollback completado si hay error

---

PRO-AUTH-010: Monitoreo de Uso de Cuentas de Servicio

Objetivo: Monitorear continuamente el uso de cuentas de servicio para detectar anomalías y verificar cumplimiento.

Frecuencia: Continua (análisis diario de últimas 24 horas)

Métricas recopiladas:

1. Volumen de peticiones:

   • Total de peticiones en las últimas 24 horas
   • Comparar con patrón histórico normal
   • Identificar picos anormales de actividad

2. Fuentes de acceso:

   • Contar direcciones IP únicas que usan la cuenta
   • Verificar que todas las IPs están en la whitelist
   • Detectar accesos desde IPs no autorizadas

3. Tasa de error:

   • Contar peticiones con código de error (≥400)
   • Calcular: (Peticiones con error / Total peticiones) × 100
   • Registrar tipo de errores más frecuentes

4. Patrones inusuales detectados:

   • Acceso desde ubicaciones no autorizadas
   • Uso fuera del horario esperado
   • Volumen de peticiones muy superior al normal
   • Tipos de operaciones no habituales
   • Múltiples fallos de autenticación

Evaluación de cumplimiento:

Determinar estado de cumplimiento según las métricas:

• CUMPLIMIENTO (compliant):

  • Tasa de error ≤10%
  • Sin patrones inusuales detectados
  • Uso dentro de límites establecidos

• REQUIERE ATENCIÓN (attention_required):

  • Tasa de error >10%
  • Volumen inusualmente alto
  • Acción: Notificar al propietario de la cuenta

• REQUIERE INVESTIGACIÓN (investigation_needed):

  • Patrones inusuales detectados
  • Posible uso no autorizado
  • Acción: Alerta al equipo de seguridad, iniciar investigación

Acciones según estado:

• Cumplimiento: Registrar métricas normales
• Requiere Atención: Enviar notificación al propietario, solicitar revisión
• Requiere Investigación: Alerta de seguridad, suspender cuenta temporalmente si hay indicios de compromiso, iniciar procedimiento de incidentes

Resultado: Informe diario de uso con estado de cumplimiento y acciones requeridas

PRO-AAC-014: Gestión de Incidentes de Autenticación

1. Bloqueo por Intentos Fallidos

   • Notificación automática al usuario
   • Alerta al SOC
   • Proceso de desbloqueo verificado

2. Compromiso de Credenciales

   • Bloqueo inmediato
   • Reset forzado de contraseña
   • Auditoría de accesos recientes
   • Notificación a afectados

3. Pérdida de Factor MFA

   • Verificación de identidad alternativa
   • Uso de backup codes
   • Re-registro de factor

4. Respuesta a Anomalías de Acceso Privilegiado

   PRO-AAC-014-A: Respuesta a Anomalías en Accesos Privilegiados

   Objetivo: Responder de forma automatizada y proporcional a anomalías detectadas en accesos privilegiados, aplicando medidas de contención según la severidad del incidente.

   Pasos:

   1. Crear registro de incidente:

      • Generar ID único de incidente (formato: INC-PRIV-YYYY-NNNN)
      • Registrar timestamp de detección
      • Capturar información de la anomalía detectada
      • Asociar con ID de usuario afectado
      • Establecer estado inicial: "DETECTADO"

   2. Evaluar severidad de la anomalía:

      • Calcular nivel de severidad según factores de riesgo
      • Niveles de severidad: CRITICAL, HIGH, MEDIUM, LOW
      • Criterios de clasificación:
        • CRITICAL: Acceso desde ubicación geográfica no autorizada + horario inusual + privilegios máximos
        • HIGH: Múltiples factores de riesgo combinados + privilegios elevados
        • MEDIUM: Un factor de riesgo con privilegios estándar

   3. Aplicar respuesta según severidad:

      Si severidad = CRITICAL:

      • a. Suspender acceso inmediatamente:
        • Revocar todas las sesiones activas del usuario
        • Deshabilitar cuenta temporalmente
        • Bloquear acceso a sistemas críticos
        • Tiempo de acción: < 1 minuto
      • b. Notificar a CISO y Security Team:
        • Alerta de prioridad CRÍTICA
        • Enviar detalles completos del incidente
        • Activar protocolo de respuesta de emergencia
        • Canal: Email + SMS + llamada telefónica
      • c. Iniciar investigación forense:
        • Preservar logs y evidencias
        • Capturar estado de sesiones activas
        • Documentar timeline de eventos
        • Asignar investigador forense

      Si severidad = HIGH:

      • a. Requerir re-autenticación:
        • Invalidar sesión actual
        • Solicitar autenticación completa con MFA adicional
        • No permitir acceso hasta completar re-autenticación
      • b. Notificar al Security Team:
        • Alerta de prioridad ALTA
        • Proporcionar contexto del incidente
        • Solicitar revisión en siguiente turno
      • c. Aumentar nivel de monitorización:
        • Activar monitorización intensiva por 24 horas
        • Registrar todas las acciones del usuario
        • Aplicar análisis de comportamiento en tiempo real
        • Generar alertas adicionales ante nuevas anomalías

      Si severidad = MEDIUM:

      • a. Marcar para revisión:
        • Añadir usuario a lista de revisión prioritaria
        • Programar revisión en próximas 24-48 horas
        • Mantener acceso activo pero monitorizando
      • b. Notificar al gestor del usuario:
        • Enviar notificación informativa al manager directo
        • Incluir ID del incidente
        • Solicitar confirmación de actividad legítima
        • Plazo de respuesta: 24 horas

   4. Documentar respuesta ejecutada:

      • Registrar todas las acciones tomadas
      • Incluir timestamps de cada acción
      • Actualizar estado del incidente
      • Generar registro de auditoría completo

   5. Retornar ID de incidente:

      • Proporcionar ID único para seguimiento
      • Permitir correlación con otros eventos
      • Facilitar auditoría posterior

   Resultado: Incidente gestionado con medidas de contención aplicadas según severidad, con ID de incidente para seguimiento

   Tiempos de Respuesta Objetivo:

   • CRITICAL: Acción inmediata (< 1 minuto)
   • HIGH: Dentro de 5 minutos
   • MEDIUM: Dentro de 1 hora

5. Procedimiento de Investigación de Accesos Anómalos

   Fase 1: Detección Automática (0-5 minutos)

   • SIEM detecta patrón anómalo
   • Sistema clasifica automáticamente el riesgo
   • Se activan contramedidas automáticas según severidad

   Fase 2: Análisis Inicial (5-30 minutos)

   • Analista de seguridad revisa alertas
   • Correlación con otros eventos de seguridad
   • Validación de falsos positivos

   Fase 3: Investigación Detallada (30 minutos - 4 horas)

   • Análisis forense de logs de autenticación
   • Revisión de actividades del usuario
   • Contacto con el usuario para validación

   Fase 4: Resolución y Documentación (4-24 horas)

   • Implementación de medidas correctivas
   • Documentación de lecciones aprendidas
   • Actualización de reglas de detección

Responsabilidades

Chief Information Security Officer (CISO)

• Definir políticas de autenticación
• Aprobar métodos y tecnologías
• Supervisar cumplimiento

Identity and Access Management (IAM) Team

• Implementar sistemas de autenticación
• Gestionar ciclo de vida de credenciales
• Mantener integraciones federadas

Security Operations Center (SOC)

• Monitorizar intentos de autenticación
• Detectar y responder a anomalías
• Gestionar incidentes de seguridad

Usuarios

• Proteger sus credenciales
• Reportar incidentes inmediatamente
• Cumplir políticas establecidas

Registros y Evidencias

Logs de Autenticación

Contenido Requerido en Registros de Auditoría de Autenticación

Cada evento de autenticación debe registrar la siguiente información completa para cumplir con los requisitos de auditoría de ENS:

Información Temporal:

• Timestamp (fecha y hora): Momento exacto del evento en formato ISO 8601 (ej: 2024-01-20T10:30:45Z)

Información del Evento:

• Tipo de evento: LOGIN_SUCCESS, LOGIN_FAILURE, LOGOUT, MFA_SUCCESS, MFA_FAILURE, SESSION_TIMEOUT, PASSWORD_RESET, etc.

Información del Usuario:

• ID del usuario: Identificador único del usuario (ej: LH-HCP-12345)
• Tipo de identidad: HCP, ITP, ADMIN, API, SVC, PAT

Información de Autenticación:

• Método de autenticación: PASSWORD, PASSWORD_MFA, CERTIFICATE, BIOMETRIC, SAML, OAUTH
• Tipo de MFA (si aplica): TOTP, SMS, PUSH, HARDWARE_TOKEN, BIOMETRIC
• Factores de autenticación utilizados: Número y tipos de factores aplicados

Información de Contexto:

• Dirección IP: Dirección IP de origen (ej: 192.168.1.100)
• User Agent: Navegador o cliente utilizado (ej: Mozilla/5.0...)
• Ubicación geográfica: Ciudad y país (ej: Madrid, ES)
• Dispositivo: Fingerprint o identificador del dispositivo

Evaluación de Riesgo:

• Puntuación de riesgo: Valor calculado entre 0.0 y 1.0 (ej: 0.2)
• Factores de riesgo detectados: Nueva ubicación, dispositivo desconocido, horario inusual, etc.

Información de Sesión:

• ID de sesión: Identificador único de la sesión creada (ej: sess_abc123)
• Duración máxima de sesión: Timeout configurado

Ejemplos de Eventos:

• Login exitoso: timestamp: 2024-01-20T10:30:45Z, tipo: LOGIN_SUCCESS, usuario: LH-HCP-12345, método: PASSWORD_MFA, MFA: TOTP, IP: 192.168.1.100, ubicación: Madrid, ES, risk_score: 0.2, sesión: sess_abc123

• Login fallido por MFA: timestamp: 2024-01-20T14:22:15Z, tipo: LOGIN_FAILURE, usuario: LH-ITP-67890, método: PASSWORD_MFA, MFA: TOTP, motivo: MFA_VERIFICATION_FAILED, IP: 10.0.5.23, ubicación: Barcelona, ES, intentos_fallidos: 2

• Logout automático por timeout: timestamp: 2024-01-20T18:45:30Z, tipo: SESSION_TIMEOUT, usuario: LH-HCP-12345, sesión: sess_abc123, duración_sesión: 480min, última_actividad: 2024-01-20T18:15:30Z

Período de Retención:

• Logs de autenticación: 2 años mínimo (requisito ENS para CATEGORIA MEDIA)
• Logs de accesos privilegiados: 5 años
• Logs de incidentes de seguridad: 7 años

Métricas y KPIs

KPIs Básicos de Autenticación

Métrica	Objetivo	Frecuencia	Responsable
Tasa de adopción MFA	100%	Semanal	IAM Team
Intentos de autenticación fallidos	<5%	Diario	SOC
Tiempo medio de autenticación	<3 segundos	Continuo	DevOps
Incidentes de compromiso	0	Mensual	CISO
Contraseñas expiradas activas	0%	Diario	IAM Team
Sesiones concurrentes anómalas	<1%	Continuo	SOC

KPIs de Gestión de Privilegios (ENS)

Métrica ENS	Objetivo	Medición	Responsable
Revisiones de acceso completadas	100% en plazo	Mensual	Access Manager
Accesos privilegiados sin usar	<5%	Semanal	Security Admin
Tiempo de revocación de acceso	<4 horas	Por solicitud	IAM Team
Cumplimiento rotación credenciales	100%	Automático	System
Certificación de accesos médicos	100% mensual	Mensual	Clinical Lead
Anomalías de acceso detectadas	100% investigadas	Continuo	SOC
JIT access requests processed	<2 horas	Por solicitud	Security Team

Métricas de Cumplimiento ENS

PRO-AAC-018: Generación de Informe Mensual de Cumplimiento ENS

Objetivo: Generar un informe mensual de cumplimiento de las medidas de autenticación establecidas en OP.ACC.5 del ENS.

Frecuencia: Mensual

Componentes del Informe:

El informe mensual debe incluir las siguientes 5 áreas de cumplimiento:

1. Cumplimiento de MFA (mfa_compliance)
2. Cumplimiento de Políticas de Contraseñas (password_policy_compliance)
3. Cumplimiento de Revisiones de Privilegios (privilege_review_compliance)
4. Cumplimiento de Cuentas de Servicio (service_account_compliance)
5. Cumplimiento de Respuesta a Anomalías (anomaly_response_compliance)

Pasos:

1. Establecer período del informe:

   • Definir mes y año a analizar (formato: YYYY-MM)
   • Ejemplo: "2025-01" para enero de 2025

2. Calcular métricas de cada área de cumplimiento:

   • Ejecutar cálculo para MFA (ver PRO-AAC-018-A)
   • Ejecutar cálculo para políticas de contraseñas
   • Ejecutar cálculo para revisiones de privilegios
   • Ejecutar cálculo para cuentas de servicio
   • Ejecutar cálculo para respuesta a anomalías
   • Cada cálculo debe generar: total, conforme, tasa de cumplimiento, puntuación

3. Calcular puntuación general de cumplimiento:

   • Extraer puntuaciones (score) de las 5 áreas
   • Calcular promedio: (score1 + score2 + score3 + score4 + score5) / 5
   • Resultado: Puntuación general entre 0 y 100

4. Determinar nivel de cumplimiento:

   • Cumplimiento Completo: Puntuación ≥ 95
   • Cumplimiento Alto: Puntuación 85-94
   • Cumplimiento Medio: Puntuación 70-84
   • Cumplimiento Bajo: Puntuación 50-69
   • No Cumplimiento: Puntuación < 50

5. Generar informe completo:

   • Período analizado
   • Métricas detalladas de cada área
   • Puntuación general de cumplimiento
   • Nivel de cumplimiento alcanzado
   • Recomendaciones de mejora

Resultado: Informe mensual de cumplimiento ENS con puntuación general y nivel alcanzado

---

PRO-AAC-018-A: Cálculo de Cumplimiento de MFA

Objetivo: Calcular el porcentaje de usuarios con MFA activado para evaluar cumplimiento.

Pasos:

1. Obtener total de usuarios activos:

   • Consultar sistema de gestión de identidades
   • Contar usuarios con estado: ACTIVO
   • Excluir cuentas desactivadas o suspendidas

2. Obtener usuarios con MFA activado:

   • Consultar configuración MFA de cada usuario
   • Contar usuarios con al menos un método MFA configurado y activo
   • Métodos válidos: TOTP, SMS, PUSH, HARDWARE_TOKEN, BIOMETRIC

3. Calcular tasa de cumplimiento:

   • Fórmula: (Usuarios con MFA / Total usuarios) × 100
   • Manejo de división por cero: Si total_users = 0, entonces tasa = 0%
   • Ejemplo: (95 usuarios con MFA / 100 usuarios totales) × 100 = 95%

4. Determinar puntuación:

   • Puntuación = Tasa de cumplimiento (máximo 100)
   • Si tasa = 95%, puntuación = 95

5. Evaluar estado de cumplimiento:

   • COMPLIANT (Conforme): Tasa = 100%
   • NON_COMPLIANT (No conforme): Tasa < 100%

6. Calcular brecha de cumplimiento:

   • Brecha (gap): Total usuarios - Usuarios con MFA
   • Ejemplo: 100 - 95 = 5 usuarios sin MFA
   • Si brecha es negativa (imposible): Reportar 0

Resultado del Cálculo:

El resultado debe incluir:

• total_users: Número total de usuarios activos
• mfa_enabled: Número de usuarios con MFA activado
• compliance_rate: Porcentaje de cumplimiento (0-100)
• score: Puntuación de cumplimiento (0-100)
• status: Estado (compliant / non_compliant)
• gap: Usuarios faltantes para alcanzar 100% de cumplimiento

Ejemplo de resultado:

• Total de usuarios: 100
• Usuarios con MFA: 95
• Tasa de cumplimiento: 95%
• Puntuación: 95
• Estado: non_compliant
• Brecha: 5 usuarios

Acción requerida si non_compliant:

• Identificar usuarios sin MFA
• Enviar notificación de activación obligatoria
• Establecer plazo de activación (7 días)
• Deshabilitar acceso si no se activa en plazo

Referencias Cruzadas

Documentos Internos

• OP.AAC.1: Identificación - Base para autenticación
• OP.AAC.4: Gestión de derechos - Post-autenticación
• T-024-009: Security Architecture - Detalles técnicos
• GP-013: Ciberseguridad - Marco general
• T-110-007: Matriz RACI - Roles y responsabilidades ENS
• T-110-008: CCN-CERT - Procedimientos de notificación

Cumplimiento Normativo

• ENS: [op.acc.5] Mecanismo de autenticación
• ISO 27001: A.9.4.2 - Procedimientos seguros de inicio de sesión
• MDR: Requisito 17.2 - Medidas de seguridad IT
• FDA Cybersecurity: Autenticación robusta
• NIST 800-63B: Digital Identity Guidelines

Documentos de referencia

• Guías CCN-STIC:
  • Guía CCN-STIC-436 - Herramientas de Análisis de Contraseñas
  • Guía CCN-STIC-490 Dispositivos biométricos de huella dactilar
  • Guía CCN-STIC-807 - Criptología de Empleo en el ENS
  • Guía CCN-STIC-827 - Gestión y uso de dispositivos móviles
• ISO/IEC 27000
  • 27002:2013:
    • 9.2.4 - Gestión de la información secreta de autenticación de usuarios
    • 9.3.1 - Uso de la información secreta de autenticación
    • 9.4.3 - Sistema de gestión de contraseñas
• NIST SP 800-53 rev4:
  • [IA-2] Identification and Authentication (Organizational Users)
  • [IA-3] Device Identification and Authentication
  • [IA-5] Authenticator Management
  • [IA-7] Cryptographic Module Authentication
  • [IA-8] Identification and Authentication (Non-Organizational Users)
• Otras referencias:
  • SANS - CIS Critical Security Controls - Version 6.1
    • CSC.5 - Controlled Use of Administrative Privileges
    • CSC.14 - Controlled Access Based on the Need to Know
  • Password Policy, SANS Institute http://www.sans.org/resources/policies/Password_Policy.pdf

Definiciones

• Hash o funciones resumen: La función de hashing criptográfico es una función (matemática) en la cual un algoritmo conocido toma un mensaje de longitud arbitraria como entrada y produce un resultado de longitud fija (generalmente denominado “código hash” o “resumen de mensaje”).
• Personal Identification Number es un número de identificación personal utilizado en ciertos sistemas, como el teléfono móvil o el cajero automático, para identificarse y obtener acceso al sistema. Es un tipo de contraseña.
• Tokens: Tarjeta o dispositivo electrónico que utiliza un usuario autorizado para acceder a un sistema informático.

Guía de implantación

128. Es el mecanismo que permite validar la identidad de un usuario. Es crítico por cuanto la identificación del usuario es, en general, fácilmente accesible.

129. Típicamente los mecanismos de autenticación recurren:

• a algo que se conoce (un secreto, por ejemplo, una contraseña)
• a algo que se tiene (un objeto, por ejemplo, una tarjeta o una llave)
• a algo que es propio del usuario (características biométricas)

130. A veces estos mecanismos se emplean por pares para dificultar la falsificación y ganar tiempo frente a la pérdida de alguno de los mecanismos. Como, por ejemplo:

• una tarjeta + un PIN
• una tarjeta + una característica biométrica
• una característica biométrica + una contraseña

131. Cada mecanismo tiene sus puntos débiles que deben atajarse por medio de normativa y procedimientos que regulen su uso, periodo de validez y gestión de incidencias tales como la pérdida por parte del usuario legítimo.

Factor de autenticación	Ejemplos	Bajo	Medio	Alto
Algo que se sabe	Contraseñas, claves concertadas, PIN	ok	con cautela	con cautela
Algo que se tiene	Tokens, tarjetas	ok	ok	criptográficos
Algo que se es	Biometría	ok	ok	ok

Mecanismos de autenticación según nivel de dimensiones de seguridad

132. Las credenciales deberán activarse una vez estén bajo control efectivo del usuario (por ejemplo, contraseña temporal de un solo uso) y serán única y exclusivamente para dicho usuario, prohibiéndose su divulgación o uso compartido. Es decir, el usuario deberá reconocer que ha recibido las credenciales y que conoce y acepta las obligaciones que implica su tenencia, en particular, el deber de custodia diligente, protección de su confidencialidad e información inmediata en caso de pérdida.

133. Las credenciales caducarán con una periodicidad marcada por la política de la organización, aunque la entidad (persona, equipo o proceso) haga uso habitual de ellas.

134. Las credenciales se retirarán y serán inhabilitadas cuando la entidad (persona, equipo o proceso) que autentican:

• Termina su relación con el sistema
• Tras un periodo definido de no utilización

135. Además, debe contemplarse la posibilidad de que las aplicaciones y otros elementos tecnológicos de seguridad de los que se haga uso, sobre todo si se usan productos comerciales, no tengan la capacidad para permitir una adecuada configuración de los mecanismos de autenticación atendiendo al Esquema Nacional de Seguridad y a la categoría del sistema. Por ello deberán tenerse en cuenta las siguientes opciones:

• Adquirir productos con la capacidad de cumplir los requisitos exigidos.
• Disponer de otros elementos o medidas previas que suplan las carencias de los productos comerciales (por ejemplo, autenticación contra LDAP o Directorio Activo, máquinas de salto para autenticar en elementos de seguridad con configuración limitada, etc.).
• Reemplazar las medidas de seguridad por otras compensatorias siempre y cuando se justifique documentalmente que protegen igual o mejor el riesgo sobre los activos y sea aprobado formalmente por el Responsable de la Seguridad, tal como se indica en el Artículo 27 del Real Decreto 3/2010, de 8 de Enero.

Contraseñas (secretos compartidos en general)

136. Características:

• se pueden olvidar
• a veces los usuarios las escriben abriendo una oportunidad al conocimiento por robo
• si el número de posibilidades es reducido y el mecanismo de validación permite probar rápidamente, un atacante puede descubrir el secreto a base de pruebas
• nótese que la revelación de un secreto puede producirse sin el conocimiento de la parte afectada por lo que el ladrón dispone de una amplia ventana de tiempo para actuar maximizando sus oportunidades
• la principal ventaja es que son baratas de implantar y fáciles de reemplazar en caso de pérdida

137. Se debe concienciar a los usuarios de los riesgos del uso de contraseñas e instruirles en cómo generarlas y custodiarlas.

138. La expresión “con cautela” empleada más arriba indica que debemos establecer una política rigurosa de empleo de contraseñas como mecanismo de autenticación. Una política incluye los siguientes elementos:

• La Política de contraseñas debe formalizarse en normativa [org.2] y procedimientos operativos de seguridad [org.3].
• Debe diferenciar entre contraseñas de usuario y contraseñas con privilegios de administrador.
• Debe tener en cuenta si se emplea aisladamente o en combinación con otro factor de autenticación.
• Debe fijar los procesos de creación, distribución, custodia y terminación.
• Debe establecer las características (patrones) de las contraseñas para considerarse válidas. Por ejemplo, número de caracteres y conjunto admitido y requerido de caracteres.
• Debe establecer un periodo máximo de validez y un tiempo mínimo de no repetición (por ejemplo, hay que renovarla al menos cada 6 meses y no se puede establecer una contraseña ya utilizada en los últimos 3 años).
• Deben detectarse los intentos repetidos de utilización y tratarlos como posibles ataques de descubrimiento por el método de prueba-error. Y debe establecerse un procedimiento de actuación que puede ir desde la introducción de un retardo creciente en el mecanismo de validación, hasta la suspensión cautelar de la cuenta.
• Debe ejecutarse regularmente una aplicación de descubrimiento de contraseñas por fuerza bruta (password cracker), suspendiéndose de oficio todas las contraseñas rotas.
• Deben suspenderse las contraseñas que hayan sido utilizadas con éxito en un proceso de autenticación de doble factor, incluso si el segundo factor ha bloqueado el acceso.
• Deben establecerse planes de concienciación y formación de los usuarios y administradores que emplean contraseñas.

139. Se debe implementar un procedimiento de resolución de incidencias relacionadas con incidentes relacionados con contraseñas; en particular debe haber un procedimiento urgente de suspensión de cuenta tras un robo.

Claves concertadas

140. Las claves concertadas son una variante de las contraseñas, que se suponen más cómodas de establecer para el ciudadano usuario.

141. Se entienden por claves concertadas códigos generados previa identificación y autenticación del ciudadano por otros medios. Jurídicamente, el ciudadano expresa su voluntad de utilizar este mecanismo en el proceso de solicitud. Las claves concertadas deberán garantizar que el usuario no puede ser suplantado, ni por otro usuario, ni por la propia Administración. Para ello deberán:

• ser razonablemente robustas frente a ataques de adivinación, tanto por estar asociadas a datos ampliamente conocidos del ciudadano, como por falta de aleatoriedad suficiente en la generación
• ser razonablemente robustas frente a ataques de diccionario
• ser razonablemente robustas frente a ataques de fuerza bruta; es decir, deben disponer de suficiente entropía
• impedir que el ciudadano pueda ser suplantado por su contraparte en la Administración
• seguir un procedimiento de generación que garantice la autenticidad del ciudadano
• seguir un procedimiento de comunicación al interesado que garantice que llega a la persona correcta
• disponer de un procedimiento de comunicación de pérdida o robo que suspenda inmediatamente la operatividad de la clave
• disponer de procedimientos de custodia de los datos de firma y verificación de la firma durante el período de validez de la información firmada, incluyendo los instantes de tiempo en que se genera, se suspende y se extingue la validez de la clave concertada

142. A fin de garantizar la robustez, la Administración deberá recurrir a generadores aleatorios que proporcionen suficiente entropía (que hayan tantas claves posibles que sea imposible probarlas todas una por una).

143. Es responsabilidad del usuario custodiar dichas claves de forma segura.

144. El proceso de generación debe garantizar la identidad del sujeto y dejar evidencia documental de las pruebas de identidad empleadas.

145. El procedimiento de distribución debe garantizar que sólo se le facilita al titular legítimo. Por ejemplo:

• usando una red privada virtual cifrada y autenticada (mp.com.2 y mp.com.3)
• por doble canal; ej. Internet + teléfono móvil
• por escrito en sobre cerrado

146. Deben generarse de forma aleatoria para:

• resistir ataques de adivinación
• resistir ataques de diccionario

Llaves o tarjetas

147. Características:

• se pueden perder, accidental o deliberadamente
• se pueden robar
• se pueden hacer copias
• en general, son caras y difíciles de reemplazar en caso de pérdida o deterioro

148. Uso habitual:

• autenticación frente a terminales (logon)
• acceso remoto y establecimiento de canales seguros
• activación de dispositivos criptográficos
• uso de dos o más tarjetas de activación
• acceso a instalaciones

149. Parece natural que se potencie el uso del DNI electrónico como mecanismo de autenticación de la persona. Este dispositivo proporciona medios de autenticación criptográficos acreditados. Frente a su uso no autorizado se protege con un PIN de activación. Nótese que el DNI electrónico sólo está capacitado por política para identificar a la persona; el resto del sistema de control y registro de acceso debe implementarse aparte.

150. Otras tarjetas de la administración pueden proporcionar funciones de autenticación del usuario asociadas a las funciones propias de su cargo en el organismo.

151. En sistemas de nivel Alto, se deben utilizar elementos criptográficos hardware que utilicen algoritmos y parámetros acreditados por el Centro Criptológico Nacional. La Guía CCN-STIC-807 Criptografía (claves de autenticación y certificados electrónicos) indica los tipos de clave pública y funciones hash que se pueden utilizar para los diferentes niveles (bajo, medio y alto).

Biometría

152. Características:

• normalmente no son secretas, y su robustez depende de que no se pueda suplantar al usuario; esto depende mucho del mecanismo concreto, pero algunos permiten técnicas de reproducción un tanto avanzadas.
• en general los dispositivos son costosos
• es difícil de reemplazar en caso de pérdida del control por parte del usuario legítimo

153. Uso habitual:

• En la autenticación frente a terminales:

  • reconocimiento de huella dactilar
  • reconocimiento facial
  • como doble factor se puede usar una contraseña o un PIN

• En el acceso a locales o áreas:

  • reconocimiento de la mano
  • reconocimiento del iris o del fondo del ojo
  • como doble factor se puede utilizar una tarjeta o un PIN

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