Tema 83 – Identificación y Firma Electrónica – TFA-STI SAS

⚡ Tema 83: Identificación Electrónica y Firma Electrónica

🎯 Introducción: La Confianza Digital en el SSPA

Mira, vamos a ser sinceros desde el principio. Este tema es… digamos que crucial. Y no lo digo por decir. Cuando hablamos de identificación y firma electrónica en el ámbito sanitario, estamos tocando el corazón mismo de la transformación digital del Sistema Sanitario Público de Andalucía.

Piénsalo un momento: cada día, miles de profesionales sanitarios acceden a historias clínicas, prescriben recetas electrónicas, firman informes médicos. Pacientes que solicitan citas online, consultan sus resultados analíticos, tramitan sus bajas laborales desde casa. Todo esto… todo, necesita que sepamos con certeza quién está al otro lado. ¿Verdad?

Y aquí es donde entran en juego los mecanismos de identificación electrónica y firma digital. No son solo conceptos técnicos abstractos de esos que estudias y luego olvidas. Son las herramientas que garantizan que el sistema funcione con seguridad, que los datos de los pacientes estén protegidos, que cada acción quede registrada y no pueda ser repudiada.

🎓 Relevancia para el Técnico/a TFA-STI del SAS

Como futuro técnico del Servicio Andaluz de Salud, vas a trabajar con sistemas que manejan datos especialmente sensibles. Los datos de salud son categorías especiales según el RGPD… lo sabes, ¿no? Y por tanto, requieren un nivel de protección máximo.

Tu papel será fundamental en:

La gestión e integración de certificados digitales en aplicaciones corporativas (Diraya, BPS, ClicSalud+)
El soporte a profesionales en problemas de firma electrónica de documentos clínicos
La configuración de sistemas de autenticación federada (CLAVE, certificados corporativos)
La implementación de medidas de seguridad conformes con el ENS y eIDAS
El análisis de incidencias relacionadas con la identificación de usuarios

⚠️ Importante para el examen: Las preguntas sobre este tema suelen centrarse en la normativa eIDAS (especialmente tras su reforma con eIDAS2), los tipos de certificados y firmas, los niveles de seguridad, y la aplicación práctica en el contexto sanitario. No te extrañe ver casos prácticos sobre firma de recetas o autenticación de profesionales.

📋 Estructura del Tema

A lo largo de este tema vamos a recorrer:

Conceptos fundamentales de identificación y autenticación electrónica
Firma electrónica: tipos, características y validez jurídica
Certificados electrónicos y su infraestructura (PKI)
Marco normativo: Reglamento eIDAS y eIDAS2, legislación nacional
Proveedores de servicios de certificación (PSC/TSP)
Plataforma CLAVE: el sistema de identificación único
Tecnologías específicas para entornos sanitarios
La nueva Identidad Digital Europea (eID/EUID)
Aplicación práctica en el SAS y casos reales

1. Identificación y Autenticación Electrónica: Conceptos Fundamentales

1.1. Diferenciando Conceptos: Identificación vs Autenticación

Vamos a empezar aclarando algo que mucha gente confunde. Y es normal, porque en el día a día usamos estos términos casi como sinónimos… pero no lo son.

La identificación electrónica es el proceso mediante el cual una persona o entidad declara su identidad en un entorno digital. Es decir, «yo soy Juan Pérez, médico de familia del Centro de Salud El Greco».

La autenticación, por su parte, es el proceso que verifica que esa identidad declarada es real. Es la comprobación: «demuéstrame que realmente eres Juan Pérez».

📖 Definición legal (Reglamento eIDAS): «Medio de identificación electrónica: unidad material o inmaterial que contiene datos de identificación de una persona y que se utiliza para autenticarse en un servicio en línea» (Art. 3.2 del Reglamento UE 910/2014).

1.2. Factores de Autenticación

Cuando hablamos de autenticación, tradicionalmente distinguimos tres factores:

Factor	Descripción	Ejemplos en el SAS
Algo que sabes	Información que solo conoce el usuario	Contraseñas, PINs, preguntas de seguridad
Algo que tienes	Dispositivo físico o digital en posesión del usuario	Certificado digital, tarjeta criptográfica, token USB, móvil con app CLAVE
Algo que eres	Característica biométrica inherente a la persona	Huella dactilar, reconocimiento facial, iris (en desarrollo para acceso PACs)

La autenticación multifactor (MFA) combina dos o más de estos factores. Pues mira, esto es cada vez más importante. El ENS, en su nivel MEDIO y ALTO, ya exige autenticación de doble factor para ciertos accesos. Y en el SAS, sistemas críticos como Diraya o el acceso VPN corporativo implementan MFA.

1.3. Niveles de Seguridad en Identificación Electrónica

El Reglamento eIDAS establece tres niveles de garantía (LoA – Level of Assurance):

BAJO: Reduce el riesgo de uso indebido o alteración de la identidad. Autenticación simple con usuario/contraseña.
SUSTANCIAL: Reduce sustancialmente dicho riesgo. Requiere autenticación de doble factor o certificado digital.
ALTO: Reduce el riesgo de manera máxima. Exige certificados cualificados o dispositivos con características especiales de seguridad.

🔍 Detalle clave para el examen: En el ámbito sanitario del SAS, para acceder a historias clínicas (Diraya) desde ubicaciones externas al centro, se requiere como mínimo nivel SUSTANCIAL mediante certificado digital reconocido o CLAVE con segundo factor.

2. Firma Electrónica: Garantizando la Integridad y el No Repudio

2.1. ¿Qué es la Firma Electrónica?

Imagina que estás firmando un informe médico en papel. Tu firma manuscrita cumple varias funciones: identifica quién firma, vincula tu identidad al documento, y además… es difícil de falsificar (bueno, en teoría). La firma electrónica hace lo mismo, pero en el mundo digital.

Según eIDAS: «datos en formato electrónico anejos a otros datos electrónicos o asociados de manera lógica con ellos que utiliza el firmante para firmar».

2.2. Tipos de Firma Electrónica

El Reglamento eIDAS distingue tres tipos, con diferentes niveles de garantía jurídica:

2.2.1. Firma Electrónica Simple

Es la más básica. Puede ser tan simple como un escaneo de tu firma manuscrita, un checkbox de «acepto términos y condiciones», o un PIN en un cajero automático.

Validez jurídica: Admitida como prueba en juicio, pero con menor peso probatorio
Garantías: Mínimas; no garantiza necesariamente la identidad del firmante ni la integridad del documento
Uso en SAS: Aceptación de condiciones en aplicaciones internas sin criticidad

2.2.2. Firma Electrónica Avanzada

Aquí la cosa se pone seria. Una firma avanzada debe cumplir requisitos específicos del artículo 26 de eIDAS:

Estar vinculada al firmante de manera única
Permitir la identificación del firmante
Haber sido creada utilizando datos que el firmante puede utilizar bajo su exclusivo control
Estar vinculada con los datos firmados de tal modo que cualquier modificación posterior sea detectable

Ejemplo práctico: Firma digital con certificado no cualificado, firma biométrica avanzada, firma con DNI electrónico.

Validez jurídica: Equivalente a la firma manuscrita (Art. 25.2 eIDAS) salvo que una normativa específica exija nivel cualificado.

2.2.3. Firma Electrónica Cualificada

Es la reina de las firmas. Es una firma avanzada pero creada mediante un dispositivo cualificado de creación de firma y basada en un certificado cualificado.

Dispositivo cualificado (QSCD): Hardware o software certificado que cumple requisitos del Anexo II de eIDAS (ej: tarjeta DNIe, tarjeta de firma de la FNMT)
Certificado cualificado: Emitido por un Prestador de Servicios de Confianza Cualificado (QTSP)
Validez jurídica: Equivalencia plena con firma manuscrita en TODOS los Estados miembros de la UE

📖 Art. 32.2 Ley 39/2015: «En el caso de actuaciones automatizadas deberá emplearse firma electrónica cualificada de la Administración Pública, órgano o entidad actuante […] u otro sistema de firma electrónica que garantice la identidad, autenticidad e integridad.»

2.3. Sellos Electrónicos y Sellos de Tiempo

Aparte de las firmas de personas físicas, eIDAS regula dos servicios adicionales importantísimos:

Sello Electrónico

Es como la firma, pero para personas jurídicas. Lo usan las organizaciones (no las personas) para garantizar origen e integridad de documentos.

Uso en SAS: Los sistemas corporativos (ej: servidor de receta electrónica) utilizan sellos para firmar documentos generados automáticamente, respuestas de servicios web seguros, etc.

Sello de Tiempo Electrónico (Timestamp)

Vincula datos electrónicos a un instante concreto del tiempo, aportando prueba de que esos datos existían en ese momento.

Aplicación crítica: En la firma de documentos clínicos, el timestamp garantiza cuándo se firmó un informe o receta, algo fundamental ante posibles reclamaciones o auditorías.

3. Certificados Electrónicos: La Infraestructura de Clave Pública (PKI)

3.1. Fundamentos de la PKI

Vale, ahora vamos con lo técnico de verdad. Detrás de toda firma y certificado digital hay un sistema criptográfico: la Infraestructura de Clave Pública o PKI (Public Key Infrastructure).

Criptografía Asimétrica

Se basa en pares de claves matemáticamente relacionadas:

Clave privada: Secreta, custodiada por el titular, usada para firmar
Clave pública: Compartida públicamente, usada para verificar firmas y cifrar mensajes para el titular

El principio: lo que cifras con una clave, solo puede descifrarse con su pareja. Lo que firmas con tu clave privada, cualquiera puede verificarlo con tu clave pública.

3.2. Estructura de un Certificado Digital

Un certificado digital (formato estándar X.509) es un documento electrónico que vincula una clave pública con la identidad de su titular. Contiene:

Campo	Descripción
Versión	Versión del estándar X.509 (actualmente v3)
Número de serie	Identificador único del certificado
Algoritmo de firma	RSA, ECDSA, etc.
Emisor (CA)	Autoridad de Certificación que lo emitió
Período de validez	Fechas de inicio y expiración
Sujeto	Datos del titular (nombre, NIF, organización…)
Clave pública	La clave pública del titular
Extensiones	Uso de clave, políticas, CRL, OCSP, etc.
Firma digital de la CA	Garantiza autenticidad del certificado

3.2.1. Fundamentos de Criptografía Asimétrica: Más Allá de lo Básico

Vale, ahora vamos a profundizar de verdad en la criptografía que sostiene todo este sistema. Porque una cosa es saber que existe «criptografía de clave pública» y otra muy distinta es entender cómo funciona técnicamente y, sobre todo, qué implicaciones tiene para los sistemas del SAS que gestionas como técnico.

Algoritmos Criptográficos: RSA vs ECDSA

Los dos algoritmos principales que encontrarás en certificados digitales del ámbito sanitario son RSA (Rivest-Shamir-Adleman) y ECDSA (Elliptic Curve Digital Signature Algorithm). Y no, no es lo mismo. Cada uno tiene características que afectan directamente al rendimiento de los sistemas corporativos.

RSA es el veterano, el algoritmo que lleva décadas funcionando. Se basa en la dificultad matemática de factorizar números primos muy grandes. Cuando un médico firma una receta con un certificado RSA-2048, está usando claves de 2048 bits de longitud. El problema… o más bien, el reto, es que para mantener un nivel de seguridad adecuado ante el aumento de capacidad computacional, necesitamos claves cada vez más largas. Hoy se considera que RSA-2048 es el mínimo aceptable, y muchas organizaciones están migrando a RSA-4096.

ECDSA, por su parte, es más moderno y eficiente. Se basa en las propiedades matemáticas de las curvas elípticas. Lo fascinante aquí es que una clave ECDSA de solo 256 bits proporciona un nivel de seguridad equivalente a RSA-3072. ¿Te das cuenta de la diferencia? Claves mucho más cortas para la misma seguridad.

💡 Impacto en el SAS: ¿Por qué importa esto? Porque cuando Diraya procesa miles de firmas electrónicas al día (informes clínicos, recetas, partes de baja…), la diferencia de rendimiento entre RSA y ECDSA es significativa. Las operaciones ECDSA son más rápidas en verificación, consumen menos CPU y generan firmas más pequeñas. Por eso el SAS está migrando gradualmente de certificados RSA-2048 a ECDSA-256 en ciertos sistemas corporativos, especialmente en servicios de alta carga como la receta electrónica.

Característica	RSA-2048	RSA-4096	ECDSA-256	ECDSA-384
Nivel de seguridad equivalente	112 bits	140 bits	128 bits	192 bits
Tamaño de firma digital	256 bytes	512 bytes	64 bytes	96 bytes
Velocidad de verificación	Lenta	Muy lenta	Rápida	Rápida
Uso en SAS	Certificados legacy	Sistemas críticos específicos	Nueva generación de certificados	Documentos con requisitos de larga duración
Compatibilidad	Universal	Universal	Requiere software actualizado	Requiere software actualizado

Funciones Hash Criptográficas: La Huella Digital de los Documentos

Cuando un médico firma un informe clínico, no se firma directamente el documento completo. Sería ineficiente. En su lugar, se calcula primero un «resumen» matemático del documento mediante una función hash, y ese resumen es lo que se firma. Piensa en el hash como una huella digital única del documento.

Las funciones hash criptográficas tienen propiedades fascinantes que las hacen perfectas para esto. Cualquier cambio mínimo en el documento original, aunque sea una sola coma, produce un hash completamente diferente. Y lo más importante, es computacionalmente imposible encontrar dos documentos diferentes que produzcan el mismo hash, lo que llamamos «resistencia a colisiones».

SHA-256 y SHA-384 son las funciones hash que verás constantemente en el ámbito sanitario. SHA significa Secure Hash Algorithm, y el número indica los bits de salida. SHA-256 produce un hash de 256 bits, mientras SHA-384 produce uno de 384 bits.

📖 Directrices CCN-CERT: El Centro Criptológico Nacional, a través de su guía CCN-STIC 807 «Criptología de empleo en el ENS», establece que SHA-1 ya no es aceptable para nuevas implementaciones desde 2017. Todos los sistemas del SAS deben usar como mínimo SHA-256 para firmas con vigencia hasta 2030, y SHA-384 o superior para documentos que requieran validez a largo plazo, como historias clínicas que se conservan durante décadas.

Aquí viene algo que muchos opositores no saben y que puede caer en el examen. Cuando hablamos de firma electrónica, en realidad estamos hablando de un proceso en dos pasos. Primero se calcula el hash del documento con SHA-256 (o SHA-384), y luego ese hash se cifra con la clave privada del firmante usando RSA o ECDSA. El resultado de cifrar el hash es la firma digital propiamente dicha.

Curvas Elípticas: ¿Qué Son y Por Qué Importan?

Cuando mencionamos ECDSA, estamos hablando de algoritmos basados en curvas elípticas. Pero, ¿qué son exactamente? Sin meternos en matemáticas complejas, una curva elíptica es una ecuación matemática del tipo y² = x³ + ax + b que tiene propiedades especiales para operaciones criptográficas.

Lo importante para un técnico del SAS no es dominar las matemáticas subyacentes, sino entender qué curvas se utilizan y por qué. Las curvas elípticas más comunes en certificados digitales son:

P-256 (secp256r1 o prime256v1): La más utilizada actualmente, recomendada por NIST y NSA para información clasificada hasta nivel SECRET. Es la curva por defecto en certificados ECDSA-256 del SAS.
P-384 (secp384r1): Proporciona mayor seguridad, recomendada para TOP SECRET. Se usa en documentos sanitarios con requisitos de conservación a muy largo plazo.
Curve25519: Una curva alternativa diseñada por Daniel J. Bernstein, muy eficiente y considerada más segura contra ciertos ataques. Aunque aún no es estándar en certificados X.509 tradicionales, está ganando adopción en protocolos modernos.

💼 Caso Práctico: Migración de RSA a ECDSA en Receta Electrónica

Situación: El SAS está planificando migrar el sistema de Receta XXI de certificados RSA-2048 a ECDSA-256 para mejorar el rendimiento. Como técnico TFA-STI, te piden evaluar el impacto y los requisitos técnicos.

Análisis necesario:

1. Compatibilidad de software: Primero debes verificar que todas las farmacias con las que se intercambian datos tengan software actualizado que soporte ECDSA. Las versiones antiguas de Java (anteriores a Java 7) y de ciertos navegadores no soportan nativamente ECDSA. Necesitas hacer un inventario de versiones de software en las farmacias andaluzas integradas con el sistema.

2. Rendimiento esperado: Con RSA-2048, el servidor de receta electrónica procesa aproximadamente 500 verificaciones de firma por segundo por núcleo de CPU. Con ECDSA-256, ese número puede triplicarse o cuadruplicarse a 1500-2000 verificaciones por segundo. Esto es crucial en horas punta, cuando miles de ciudadanos recogen medicación simultáneamente.

3. Tamaño de firmas: Cada receta firmada con RSA-2048 genera una firma de 256 bytes. Con millones de recetas al año, cambiar a ECDSA-256 (64 bytes por firma) representa un ahorro significativo de almacenamiento en la BDU (Base de Datos de Usuarios) y en las transferencias de red.

4. Período de transición: No puedes migrar de golpe. Necesitas un período de coexistencia donde el sistema acepte tanto certificados RSA como ECDSA. Los médicos irán renovando sus certificados gradualmente, y durante 2-3 años convivirán ambos tipos.

5. Aspectos normativos: Debes verificar que los certificados ECDSA-256 de los prestadores cualificados (FNMT, Colegios Profesionales) cumplan con las políticas de certificados definidas en la Política de Firma Electrónica del SAS y sean compatibles con el validador @firma.

Recomendación técnica: Proponer una migración gradual en tres fases. Fase 1 (3 meses): Actualización de software en farmacias y pruebas en entorno de preproducción. Fase 2 (6 meses): Emisión de nuevos certificados ECDSA para médicos de centros piloto mientras se mantiene compatibilidad con RSA. Fase 3 (18 meses): Extensión a todos los centros sanitarios y eventual deprecación de RSA-2048 para nuevos certificados, manteniendo validación de certificados RSA existentes hasta su caducidad natural.

Modos de Cifrado y Padding en RSA

Aquí viene un detalle técnico que marca la diferencia entre un técnico que solo conoce la teoría y uno que realmente entiende cómo funcionan los sistemas. Cuando usamos RSA, no ciframos directamente los datos «en crudo». Necesitamos aplicar un esquema de padding (relleno) para evitar vulnerabilidades criptográficas.

Los dos esquemas principales que encontrarás en certificados sanitarios son:

PKCS#1 v1.5: El esquema clásico, ampliamente compatible pero con vulnerabilidades conocidas ante ataques de padding oracle. Aún lo verás en certificados legacy del SAS, pero ya no se recomienda para nuevas implementaciones.

PSS (Probabilistic Signature Scheme): El estándar moderno, mucho más seguro. Es el que se usa en certificados nuevos del SAS y es obligatorio según las directrices del CCN-CERT para sistemas ENS nivel ALTO. Cuando veas «RSA-PSS» en las propiedades de un certificado, significa que usa este esquema.

⚠️ Para el examen: Puede caer una pregunta sobre por qué el SAS está migrando de PKCS#1 v1.5 a PSS en sus sistemas críticos. La respuesta correcta debe mencionar que PSS proporciona seguridad demostrable y es resistente a ataques de padding oracle, además de ser el estándar recomendado por NIST SP 800-89 y requerido por ENS nivel ALTO para sistemas que manejan datos sensibles como historias clínicas.

Perfect Forward Secrecy (PFS) en Comunicaciones Sanitarias

Aunque no es estrictamente parte de la firma electrónica, es importante que entiendas un concepto relacionado con la criptografía asimétrica que afecta a las comunicaciones seguras del SAS: Perfect Forward Secrecy.

Imagina este escenario: un atacante graba todo el tráfico cifrado entre un médico accediendo remotamente a Diraya a través de VPN durante varios meses. En ese momento, no puede descifrarlo porque está protegido con TLS. Pero, ¿qué pasa si dos años después consigue robar la clave privada del servidor? Con sistemas tradicionales sin PFS, podría descifrar TODO ese tráfico histórico grabado.

Con PFS, aunque el atacante obtenga la clave privada del servidor, NO puede descifrar sesiones pasadas. Esto se logra mediante algoritmos de intercambio de claves como Diffie-Hellman Efímero (DHE) o ECDH Efímero (ECDHE), donde cada sesión TLS genera claves únicas que se destruyen al finalizar.

El SAS implementa PFS en todos sus servicios web críticos (AcceSAS, ClicSalud+, APIs de interoperabilidad) mediante la configuración de suites de cifrado que priorizan ECDHE. Esto es un requisito del ENS nivel MEDIO y ALTO para comunicaciones que transportan datos especialmente protegidos.

📖 Configuración ENS: La guía CCN-STIC 836 «Configuración de Protocolos Criptográficos TLS/SSL» establece las suites de cifrado permitidas según nivel ENS. Para nivel MEDIO del SAS, se requiere como mínimo TLS 1.2 con ECDHE y cifrado AES-128-GCM o superior. Nivel ALTO requiere TLS 1.3, que incluye PFS por diseño en todas sus suites de cifrado.

3.3. Tipos de Certificados según su Uso

Certificados de Persona Física

DNI electrónico: Emitido por la Dirección General de Policía, certificado cualificado de ciudadano
Certificado FNMT: De la Fábrica Nacional de Moneda y Timbre, descargable en software
Certificado de empleado público: Para funcionarios, emitido por administraciones (ej: certificado corporativo SAS)
Certificado de profesional sanitario: Emitido por Colegios Profesionales o Consejerías (ej: certificado OMC-FNMT)

Certificados de Persona Jurídica/Entidad

Certificado de entidad: Representa a una organización
Certificado de sede electrónica: Para sitios web oficiales de administraciones
Certificado de sello electrónico: Para sistemas automatizados

Certificados de Servidor (SSL/TLS)

Aunque no son certificados de firma, son fundamentales para garantizar la seguridad en las comunicaciones web (HTTPS). El SAS utiliza certificados SSL para sus portales: AcceSAS, ClicSalud+, etc.

3.4. Cadena de Confianza y Autoridades de Certificación

El sistema PKI se basa en una jerarquía de confianza:

CA Raíz (Root CA): Máxima autoridad, su certificado es auto-firmado y viene pre-instalado en navegadores y sistemas operativos
CA Intermedia: Certificadas por la raíz, emiten certificados de usuario final
Certificado de usuario final: Tu certificado personal

Para validar un certificado, el sistema verifica toda la cadena hasta llegar a una CA raíz confiable.

3.5. Revocación de Certificados

A veces hay que anular un certificado antes de su expiración natural (pérdida, robo, compromiso de la clave…). Existen dos mecanismos:

CRL (Certificate Revocation List)

Lista negra publicada periódicamente por la CA con certificados revocados. Problema: puede quedar desactualizada entre publicaciones.

OCSP (Online Certificate Status Protocol)

Consulta en tiempo real al servidor de la CA sobre el estado de un certificado. Es más moderno y eficiente.

⚠️ Para el examen: El ENS obliga a verificar el estado de revocación de certificados en comunicaciones de nivel MEDIO y ALTO. En el SAS, los sistemas críticos deben implementar validación OCSP.

4. Marco Normativo: Reglamento eIDAS y Legislación Nacional

4.1. Reglamento (UE) 910/2014 – eIDAS

El Reglamento eIDAS (electronic IDentification, Authentication and trust Services) es la piedra angular de la confianza digital en Europa desde julio de 2016.

Objetivos principales:

Crear un mercado único digital europeo
Establecer reconocimiento mutuo de medios de identificación electrónica entre Estados miembros
Armonizar servicios de confianza (firma, sello, timestamp, autenticación web…)
Garantizar validez jurídica transfronteriza de firmas y documentos electrónicos

Estructura del Reglamento:

Título I: Disposiciones generales y definiciones

Título II: Identificación electrónica (Arts. 6-12)

Reconocimiento mutuo obligatorio entre EEMM
Notificación de sistemas de identificación
Niveles de garantía (bajo, sustancial, alto)

Título III: Servicios de confianza (Arts. 13-45)

Firma electrónica (Arts. 25-34)
Sello electrónico (Arts. 35-40)
Sello de tiempo (Arts. 41-42)
Servicio de entrega electrónica certificada (Art. 43)
Autenticación de sitios web (Art. 45)

Título IV: Identificación electrónica y servicios de confianza para transacciones electrónicas con sector público (Arts. 46-49)

Título V: Prestadores cualificados de servicios de confianza y supervisión (Arts. 17-24)

📖 Art. 25.1 eIDAS: «No se denegará efectos jurídicos ni admisibilidad como prueba en procedimientos judiciales a una firma electrónica por el mero hecho de estar en formato electrónico o de no cumplir los requisitos de la firma electrónica cualificada.»

Art. 25.2: «A una firma electrónica cualificada se le reconocerán efectos jurídicos equivalentes a los de una firma manuscrita.»

4.2. Propuesta eIDAS 2.0 (Reglamento 2024/1183)

En junio de 2021, la Comisión Europea presentó la propuesta de reforma de eIDAS, conocida como eIDAS2. Fue aprobada definitivamente en 2024 y entrará en aplicación progresivamente.

Novedades principales:

1. Identidad Digital Europea (European Digital Identity – EUDI Wallet)

Todos los EEMM deberán ofrecer una cartera digital (wallet) a ciudadanos y empresas
Aplicación móvil que almacena identificación electrónica y documentos (DNI, carnet de conducir, títulos académicos, recetas médicas…)
Reconocimiento mutuo obligatorio en toda la UE
Nivel de garantía ALTO por defecto

2. Ampliación de servicios de confianza cualificados

Nuevos servicios: archivo electrónico, gestión de claves remotas, registros electrónicos
Atributos electrónicos cualificados (credenciales verificables para edad, titulaciones, permisos profesionales…)

3. Mayor regulación de la autenticación web

Requisitos más estrictos para certificados SSL/TLS
Control sobre dominios .eu

4. Refuerzo de la supervisión

Auditorías periódicas obligatorias a prestadores cualificados
Cooperación reforzada entre organismos de supervisión nacionales

🚀 Impacto en el SAS: La llegada de EUDI Wallet permitirá a los ciudadanos almacenar su tarjeta sanitaria, recetas, informes médicos e incluso autorizaciones de tratamiento en formato digital verificable. El SAS está trabajando en la integración con este estándar europeo.

4.3. Legislación Nacional Española

Ley 39/2015, de 1 de octubre, del Procedimiento Administrativo Común

Regula el uso de medios electrónicos en las relaciones entre administración y ciudadanos.

Artículos clave:

Art. 9-11: Identificación y firma en sede electrónica
Art. 10: Sistemas de identificación admitidos (certificados, CLAVE, claves concertadas)
Art. 32.2: Firma en actuaciones automatizadas

Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público

Arts. 155-158: Archivo electrónico de documentos

Real Decreto 4/2010 – ENI (Esquema Nacional de Interoperabilidad)

Normas técnicas de interoperabilidad (NTI) sobre digitalización, firma, expediente, documento electrónico…

Normativa Andaluza

Decreto 622/2019: Administración electrónica de la Junta de Andalucía
Decreto 534/2021: Administración electrónica del SAS
Política de Firma Electrónica del SAS: Documento interno que establece certificados admitidos y procedimientos

5. Prestadores de Servicios de Certificación (PSC/TSP)

5.1. Concepto y Clasificación

Un Prestador de Servicios de Confianza (Trust Service Provider – TSP, antes llamado PSC – Prestador de Servicios de Certificación) es una entidad que emite certificados digitales o presta otros servicios de confianza regulados por eIDAS.

Tipos de prestadores:

Prestadores de servicios de confianza (no cualificados):

No requieren autorización previa
Sujetos a normativa general de protección de datos y consumidores
Sus certificados/firmas tienen validez, pero no el nivel máximo de garantía jurídica

Prestadores Cualificados de Servicios de Confianza (QTSP):

Incluidos en la Lista de Confianza (Trusted List) nacional
Sometidos a auditorías cada 24 meses por organismos de supervisión
Cumplen requisitos técnicos y organizativos del Anexo I de eIDAS
Sus servicios tienen máximas garantías jurídicas

5.2. Principales QTSP en España

Prestador	Entidad	Servicios
FNMT-RCM	Fábrica Nacional de Moneda y Timbre – Real Casa de la Moneda	Certificados de ciudadanos, empresas, sello tiempo, @firma
ACCV	Agencia de Tecnología y Certificación Electrónica (Generalitat Valenciana)	Certificados para ciudadanos y empleados públicos valencianos
ANF-AC	Autoridad de Certificación Notarial	Certificados profesionales, persona jurídica, firma biométrica
CATCert	Agencia de Ciberseguridad de Cataluña	Certificados de ciudadanos, empresas y administración catalana
DGP	Dirección General de la Policía	Certificados del DNI electrónico
IZENPE	Entidad pública empresarial del País Vasco	Certificados de ciudadanos vascos y administración

5.3. Trusted List (Lista de Confianza)

Cada Estado miembro publica una lista oficial de sus QTSP en formato XML firmado. En España, la gestiona el Ministerio de Asuntos Económicos y Transformación Digital.

Consulta online: https://sede.mineco.gob.es/Prestadores

La Comisión Europea agrega todas las listas nacionales en la Lista de Confianza Europea (EU Trusted List), permitiendo verificar prestadores de cualquier país UE.

5.4. Prestadores en el Ámbito Sanitario

Para el sector sanitario existen prestadores específicos:

Colegios Profesionales: Emiten certificados para médicos, enfermeros, farmacéuticos (ej: certificado OMC-FNMT del Colegio de Médicos)
Consejerías de Salud autonómicas: Emiten certificados corporativos para profesionales del sistema público (ej: certificado SAS para empleados)
Operadores privados con perfil sanitario: Como Firmafy (firma biométrica para consentimientos informados)

💼 Caso Práctico 1: Gestión de Certificados en el SAS

Situación: Un médico de urgencias del Hospital Virgen del Rocío necesita firmar informes clínicos desde el sistema Diraya. Tiene DNIe, certificado FNMT personal y certificado corporativo SAS.

Pregunta: ¿Cuál debe usar y por qué?

Solución:

Debe usar el certificado corporativo SAS
Motivo: La Política de Firma del SAS establece que para documentos clínicos oficiales debe emplearse el certificado corporativo de empleado público, que vincula la firma a su condición de profesional del servicio
El DNIe o FNMT personal servirían para trámites como ciudadano, pero no en su rol profesional
Además, el certificado corporativo puede incluir atributos profesionales (especialidad, centro, colegiación) que son relevantes para el valor del documento

6. Plataforma CLAVE: Sistema de Identificación Común

6.1. ¿Qué es CLAVE?

CLAVE (Clave de Acceso Electrónica) es el sistema de identificación electrónica común para acceder a servicios públicos electrónicos desarrollado por la Secretaría General de Administración Digital del Ministerio.

Permite a ciudadanos y empresas identificarse ante cualquier administración española (estatal, autonómica, local) usando diferentes métodos, evitando tener que recordar múltiples usuarios y contraseñas.

6.2. Sistemas de Identificación Admitidos en CLAVE

Sistema	Nivel de Garantía	Descripción
Cl@ve Permanente	Bajo/Sustancial	Usuario y contraseña permanentes. Si se asocia móvil (segundo factor), pasa a nivel sustancial
Cl@ve PIN	Bajo	Contraseña de un solo uso enviada al móvil registrado
Certificado digital	Sustancial/Alto	DNIe, certificados FNMT, autonómicos…
Cl@ve Firma	Sustancial	App móvil con certificado en la nube, permite firmar documentos
Sistemas autonómicos	Variable	Integración con sistemas propios de CCAA (ej: eID Andalucía)

6.3. Arquitectura Técnica de CLAVE: Entendiendo la Federación de Identidades

Bien, ahora vamos a meternos de lleno en cómo funciona técnicamente CLAVE. Porque una cosa es saber que CLAVE existe y que permite autenticarse con diferentes métodos, y otra muy distinta es entender qué ocurre «por debajo del capó» cuando un ciudadano pulsa el botón de «Acceder con Cl@ve» en ClicSalud+. Y créeme, esto es exactamente el tipo de conocimiento que te separa de otros opositores y que te hace valioso como técnico del SAS.

El Modelo de Autenticación Federada

CLAVE no es un sistema de autenticación «tradicional». No es como cuando introduces tu usuario y contraseña directamente en una aplicación. CLAVE es lo que llamamos un sistema de autenticación federada, y eso cambia todo el paradigma.

Imagínate que CLAVE es como un «portero de discoteca» especializado que está en la puerta de múltiples servicios públicos. Cuando quieres entrar a ClicSalud+ (la discoteca en este ejemplo), el servicio no te pregunta directamente quién eres. Te redirige al portero CLAVE, que ya te conoce y en quien confía. El portero te reconoce, verifica tu identidad con los métodos que tú elijas, y luego le dice a ClicSalud+: «Este es Juan Pérez, yo certifico su identidad». ClicSalud+ confía en el portero y te deja entrar.

Este modelo tiene ventajas enormes. El usuario no necesita recordar múltiples contraseñas para cada servicio público. Los servicios no tienen que gestionar bases de datos de usuarios ni preocuparse por almacenar contraseñas de forma segura. Y el SAS no tiene que implementar desde cero su propio sistema de autenticación, puede delegar en CLAVE y centrarse en proporcionar servicios sanitarios de calidad.

Actores en la Arquitectura CLAVE

En la arquitectura técnica de CLAVE participan tres actores principales, y entender sus roles es fundamental para diagnosticar problemas cuando algo falla:

El Usuario (User Agent): El ciudadano con su navegador web o aplicación móvil. Es quien inicia el proceso queriendo acceder a un servicio.

El Service Provider (SP) o Proveedor de Servicios: Es el servicio al que el usuario quiere acceder. En nuestro caso, ClicSalud+, la sede electrónica del SAS, o cualquier otro servicio sanitario que requiera identificación. El SP confía en CLAVE para autenticar usuarios.

El Identity Provider (IdP) o Proveedor de Identidad: Es CLAVE propiamente dicho. Es quien realmente autentica al usuario y certifica su identidad ante el SP. CLAVE actúa como IdP centralizado para toda la administración española.

El Protocolo SAML 2.0: El Lenguaje de la Confianza

La comunicación entre estos actores se realiza mediante SAML 2.0 (Security Assertion Markup Language). SAML es un estándar basado en XML que define cómo intercambiar información de autenticación y autorización entre dominios de seguridad diferentes.

Piensa en SAML como el «idioma diplomático» que permite que ClicSalud+ del SAS y CLAVE del Ministerio se entiendan perfectamente sin importar que sean organizaciones diferentes con tecnologías internas distintas. SAML define tres tipos principales de mensajes que se intercambian:

Authentication Request (AuthnRequest): El SP le dice al IdP «necesito que autentiques a este usuario». Es como pedirle al portero que verifique la identidad de alguien.

Assertion: El IdP responde al SP con una aserción firmada digitalmente que contiene la identidad del usuario y atributos sobre él. Es como el portero dándole al servicio un documento certificado que dice «Este es Juan Pérez, DNI 12345678A, y yo garantizo su identidad».

Response: El contenedor que envuelve la Assertion y que viaja de vuelta al SP. Incluye información sobre el éxito o fracaso del proceso de autenticación.

Flujo de Autenticación SAML: Paso a Paso

Ahora vamos a recorrer exactamente qué ocurre cuando un paciente andaluz intenta acceder a ClicSalud+ con CLAVE. Voy a describirlo con el nivel de detalle que necesitas para entender cada punto donde puede surgir un problema.

🔄 Secuencia Completa de Autenticación con CLAVE en ClicSalud+

Paso 1: Inicio de Sesión

María, una paciente de Sevilla, abre su navegador y accede a https://clicsalud.sanidadandalucia.es. En la página de inicio, pulsa el botón «Acceder con Cl@ve».

¿Qué ocurre técnicamente? ClicSalud+ (actuando como SP) genera un mensaje SAML AuthnRequest. Este mensaje es un XML que contiene:

Un ID único para esta petición específica
La URL del IdP de CLAVE (donde redirigir al usuario)
La URL de retorno (AssertionConsumerServiceURL) donde CLAVE debe enviar la respuesta
El nivel de garantía (LoA) requerido: en este caso, «sustancial»
La firma digital del SP (ClicSalud+) autenticando la petición

Paso 2: Redirección al IdP

El navegador de María es redirigido automáticamente (HTTP 302 Redirect) a la URL de CLAVE, llevando consigo el AuthnRequest codificado en Base64 como parámetro de la URL. María ahora ve la página de CLAVE, no de ClicSalud+.

Aspecto crítico de seguridad: La redirección se hace mediante HTTP POST o HTTP Redirect Binding. El AuthnRequest va firmado digitalmente con el certificado del SP (ClicSalud+). CLAVE verifica esta firma antes de procesar la petición. Si la firma no es válida o el certificado de ClicSalud+ ha caducado, la autenticación falla aquí mismo. Este es un punto común de incidencias cuando se renuevan certificados corporativos del SAS.

Paso 3: Selección de Método de Autenticación

María ve en la pantalla de CLAVE varias opciones: Cl@ve Permanente, certificado digital, DNIe, Cl@ve PIN. Ella elige «Certificado digital» porque tiene instalado su certificado FNMT en el navegador.

¿Qué hace CLAVE? CLAVE tiene múltiples módulos internos de autenticación, uno por cada método. Cuando María selecciona «Certificado digital», CLAVE activa su módulo de autenticación PKI. Este módulo solicita al navegador que presente los certificados disponibles.

Paso 4: Autenticación con Certificado

El navegador de María muestra una ventana con los certificados instalados. Ella selecciona su certificado FNMT y el navegador realiza una autenticación TLS mutua (mutual TLS) con el servidor de CLAVE, donde el navegador presenta el certificado del usuario y CLAVE lo valida.

Validación del certificado por CLAVE: Aquí es donde ocurre la magia crítica. CLAVE debe verificar que el certificado es válido, y eso implica varios pasos técnicos:

Verificación de cadena de confianza: CLAVE comprueba que el certificado está firmado por una CA que está en su lista de CAs confiables (FNMT en este caso)
Verificación de vigencia: Comprueba que la fecha actual está dentro del período de validez del certificado (no ha caducado ni es prematuro)
Verificación de revocación: Consulta el estado del certificado mediante OCSP o CRL. Si el certificado está revocado, la autenticación falla
Verificación de uso: Comprueba que el certificado tiene el uso «digitalSignature» o «nonRepudiation» en sus extensiones KeyUsage
Extracción de atributos: CLAVE extrae del certificado los datos identificativos (nombre, apellidos, NIF) que luego incluirá en la assertion

Paso 5: Generación de la SAML Assertion

Una vez que CLAVE ha autenticado exitosamente a María, genera una SAML Assertion. Esta assertion es un documento XML firmado digitalmente que contiene:

<saml:Assertion ID="a3f1b2c4d5e6..." Version="2.0">
    <saml:Issuer>https://clave.gob.es</saml:Issuer>
    <saml:Subject>
        <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
            12345678A
        </saml:NameID>
    </saml:Subject>
    <saml:Conditions NotBefore="2025-11-03T10:00:00Z" NotOnOrAfter="2025-11-03T10:05:00Z">
        <saml:AudienceRestriction>
            <saml:Audience>https://clicsalud.sanidadandalucia.es</saml:Audience>
        </saml:AudienceRestriction>
    </saml:Conditions>
    <saml:AuthnStatement AuthnInstant="2025-11-03T10:00:00Z">
        <saml:AuthnContext>
            <saml:AuthnContextClassRef>
                http://eidas.europa.eu/LoA/substantial
            </saml:AuthnContextClassRef>
        </saml:AuthnContext>
    </saml:AuthnStatement>
    <saml:AttributeStatement>
        <saml:Attribute Name="givenName">
            <saml:AttributeValue>María</saml:AttributeValue>
        </saml:Attribute>
        <saml:Attribute Name="surname">
            <saml:AttributeValue>García López</saml:AttributeValue>
        </saml:Attribute>
        <saml:Attribute Name="eIDAS_LoA">
            <saml:AttributeValue>substantial</saml:AttributeValue>
        </saml:Attribute>
    </saml:AttributeStatement>
    <!-- Firma digital de CLAVE -->
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        ...
    </ds:Signature>
</saml:Assertion>

Elementos críticos de la Assertion:

ID único: Identifica esta assertion específica, usado para prevenir ataques de replay
Issuer: Identifica a CLAVE como emisor de la assertion
Subject/NameID: El identificador del usuario (su NIF en este caso)
Conditions: Ventana temporal de validez (típicamente 5 minutos). Fuera de esta ventana, la assertion no es válida
AudienceRestriction: Especifica que esta assertion SOLO es válida para ClicSalud+, no para otros servicios
AuthnContextClassRef: Indica el nivel de garantía alcanzado (sustancial, en este caso)
AttributeStatement: Atributos del usuario (nombre, apellidos, nivel LoA, etc.)
Signature: Firma digital XML de CLAVE que garantiza la autenticidad e integridad de toda la assertion

Paso 6: Envío de la Response a ClicSalud+

CLAVE genera una SAML Response que envuelve la Assertion y redirige el navegador de María de vuelta a ClicSalud+, concretamente a la URL AssertionConsumerService que ClicSalud+ indicó en el paso 1.

La Response se envía mediante HTTP POST. El navegador de María envía automáticamente un formulario POST invisible a ClicSalud+ conteniendo la Response codificada en Base64.

Paso 7: Validación de la Assertion por ClicSalud+

ClicSalud+ recibe la SAML Response y ahora debe validarla exhaustivamente antes de confiar en ella. Este es un momento crítico de seguridad. ClicSalud+ realiza las siguientes comprobaciones:

Decodificación y parsing XML: Decodifica el Base64 y parsea el XML
Validación de la firma digital: Verifica la firma XML de CLAVE usando el certificado público de CLAVE (que ClicSalud+ tiene preconfigurado en su metadata SAML)
Verificación temporal: Comprueba que la hora actual está dentro de la ventana NotBefore/NotOnOrAfter
Verificación de audiencia: Comprueba que el Audience coincide con la propia identidad de ClicSalud+
Verificación de InResponseTo: Comprueba que el ID de la Response corresponde al ID del AuthnRequest original que envió (protección contra ataques de replay)
Verificación del nivel LoA: Comprueba que el nivel de garantía alcanzado (sustancial) es suficiente para el servicio solicitado
Prevención de replay: Marca el ID de la Assertion como «ya usado» en una caché temporal. Si recibe otra petición con el mismo ID, la rechaza

Paso 8: Creación de Sesión Local

Solo si todas las validaciones del paso 7 son exitosas, ClicSalud+ confía en la identidad de María. Ahora ClicSalud+ crea una sesión local en su propio dominio, asocia la sesión con el NIF de María extraído de la Assertion, y establece una cookie de sesión en el navegador.

A partir de este momento, María puede navegar por ClicSalud+ sin necesidad de autenticarse de nuevo. La autenticación con CLAVE solo ocurre una vez al inicio. Durante su navegación, ClicSalud+ valida cada petición mediante la cookie de sesión local, no vuelve a consultar a CLAVE.

Paso 9: Acceso a Recursos

María ya puede consultar sus citas, ver informes médicos, solicitar recetas… ClicSalud+ consulta la Base de Datos Poblacional del SAS usando el NIF de María para recuperar su información sanitaria.

Metadatos SAML: El Contrato de Confianza

Para que todo este flujo funcione, ClicSalud+ y CLAVE necesitan conocerse mutuamente de antemano y confiar el uno en el otro. Esto se logra mediante metadatos SAML.

Los metadatos son documentos XML que cada parte publica y que contienen información técnica sobre cómo interactuar con ellos. Incluyen las URLs de los endpoints, los certificados públicos para validar firmas, los identificadores únicos (EntityID), los servicios soportados, etc.

Metadata de ClicSalud+ (Service Provider): Publicado por el SAS, contiene la URL donde CLAVE debe enviar las assertions, el certificado público con el que ClicSalud+ firma sus AuthnRequests, los atributos que ClicSalud+ requiere del usuario, etc.

Metadata de CLAVE (Identity Provider): Publicado por el Ministerio, contiene las URLs de autenticación de CLAVE, el certificado público con el que CLAVE firma sus assertions, los niveles de garantía que soporta, etc.

Cuando el SAS integra un nuevo servicio con CLAVE, el proceso técnico incluye un intercambio de metadatos. El SAS registra su nuevo servicio en el registro de Service Providers de CLAVE, proporcionando su metadata. Y el SAS importa el metadata de CLAVE en la configuración de su nuevo servicio. Este es el «contrato de confianza» que permite que la federación funcione.

🔧 Punto crítico de operación: Los certificados incluidos en los metadatos caducan. Cuando el certificado de firma de CLAVE se va a renovar, el Ministerio publica con antelación el nuevo metadata con el nuevo certificado. TODOS los Service Providers (incluido ClicSalud+ del SAS) deben actualizar su configuración antes de que el certificado antiguo expire. Si no lo hacen, las validaciones de firma fallarán y los usuarios no podrán autenticarse. Este tipo de incidencias ocurren periódicamente y como técnico del SAS necesitas conocer el procedimiento de actualización de metadatos SAML en tu infraestructura.

Gestión de Sesiones y Logout

Hay un aspecto que a menudo se pasa por alto pero que es importante: ¿qué ocurre cuando María termina de usar ClicSalud+ y cierra sesión?

SAML 2.0 soporta dos tipos de logout:

Local Logout: María cierra sesión solo en ClicSalud+. Su sesión local se destruye, pero si tuviera sesiones abiertas en otros servicios que también usan CLAVE (por ejemplo, la sede electrónica de la Junta), esas sesiones seguirían activas. Es como salir de una habitación pero quedarte en el edificio.

Single Logout (SLO): María cierra sesión en CLAVE, lo que desencadena un cierre automático de sesión en TODOS los servicios donde se autenticó con CLAVE durante esa sesión. Es como salir del edificio completo. Para implementar SLO, CLAVE envía peticiones de logout a todos los SPs donde el usuario tiene sesiones activas, y cada SP debe destruir la sesión correspondiente.

ClicSalud+ implementa Single Logout, lo que significa que cuando un paciente cierra sesión, se cierra su sesión tanto en ClicSalud+ como en CLAVE. Esto es importante para la seguridad, especialmente si el paciente accedió desde un ordenador compartido o público.

6.4. Integración de CLAVE en el SAS

El SAS ha integrado CLAVE en varios servicios ciudadanos:

ClicSalud+: Portal del paciente (citas, informes, recetas…)
Certificado digital COVID: Durante la pandemia
Servicios de salud responde: Consultas telemáticas
Tramitación de ayudas y prestaciones: Transporte sanitario, ortoprótesis…

⚙️ Detalle técnico: La integración se realiza mediante el componente CLAVE Service Provider (SP) que implementa el perfil de integración para administraciones. El SAS actúa como SP y delega la autenticación en el Identity Provider (IdP) de CLAVE.

6.5. eID Andalucía: La Identidad Digital Autonómica

La Junta de Andalucía desarrolló su propio sistema de identidad digital, eID Andalucía, que se integra con CLAVE pero también funciona de manera independiente.

Características:

App móvil eID Andalucía (Android/iOS)
Certificado en la nube alojado en infraestructura de la Junta
Permite firma de documentos desde móvil
Integrado con servicios de identificación autonómicos
Compatible con CLAVE y reconocimiento mutuo europeo

7. Tecnologías de Identificación en Entornos Sanitarios

7.1. Particularidades del Sector Sanitario

El ámbito sanitario tiene características específicas que condicionan las tecnologías de identificación:

Alta criticidad: Los errores de identificación pueden tener consecuencias graves (administración incorrecta de medicación, acceso a historia clínica equivocada…)
Urgencia: En situaciones de emergencia, el proceso debe ser rapidísimo
Movilidad: Profesionales que se mueven entre plantas, centros, domicilios
Protección de datos especiales: Datos de salud, categoría especial RGPD
Trazabilidad exhaustiva: Auditoría completa de quién accede a qué y cuándo

7.2. Tecnologías Específicas para Sanidad

7.2.1. Tarjeta Sanitaria Individual (TSI)

Aunque su función principal es identificar al paciente ante el sistema, las tarjetas modernas incorporan chip criptográfico que puede almacenar:

Datos básicos del titular
Código de identificación sanitaria (CIP en Andalucía)
Certificado digital del paciente (en desarrollo)
Datos de emergencia (alergias, patologías críticas)

7.2.2. Tarjetas de Profesional Sanitario

Muchas CCAA emiten tarjetas criptográficas para sus profesionales sanitarios que combinan:

Control de acceso físico (apertura de puertas mediante RFID)
Identificación lógica (login en estaciones de trabajo)
Certificado digital para firma de documentos clínicos
Almacenamiento de credenciales corporativas

En el SAS: La tarjeta de identificación profesional (TIP-SAS) permite acceso físico a instalaciones, pero la identificación en sistemas se realiza mediante certificado corporativo independiente o usuario/contraseña+2FA.

7.2.3. Biometría en Sanidad

La identificación biométrica ofrece ventajas únicas:

Huella dactilar: Común en control de presencia, acceso a zonas restringidas
Reconocimiento facial: En fase piloto para acceso rápido en urgencias
Iris: Muy preciso pero costoso, utilizado en algunos sistemas de alta seguridad (quirófanos, farmacias hospitalarias)
Voz: Emergente para identificación telefónica en call centers sanitarios
Palma de la mano: Tecnología muy precisa utilizada en algún hospital de referencia

⚖️ Consideración legal: Los datos biométricos son categoría especial según RGPD (Art. 9). Su uso requiere:

Evaluación de Impacto de Protección de Datos (EIPD)
Base legal adecuada (generalmente, misión de interés público + normativa específica)
Medidas de seguridad reforzadas
Información clara al interesado

7.2.4. SSO (Single Sign-On) y Federación de Identidades

Permite a profesionales autenticarse una vez y acceder a múltiples sistemas sin volver a introducir credenciales.

Tecnologías:

SAML 2.0: Estándar XML para intercambio de información de autenticación (usado por CLAVE)
OAuth 2.0 / OpenID Connect: Protocolos modernos basados en tokens JSON, más ligeros y flexibles
Kerberos: Protocolo clásico en entornos Microsoft Active Directory

Implementación en SAS: El SAS utiliza un sistema de SSO corporativo que integra:

Active Directory para gestión de usuarios Windows
Servidor LDAP para aplicaciones Java
Federación SAML para servicios web externos
Integración con CLAVE para servicios ciudadanos

7.2.5. Autenticación Basada en Contexto (Context-Aware Authentication)

Sistemas inteligentes que adaptan los requisitos de autenticación según el contexto:

Ubicación: Desde dentro del hospital (red corporativa) vs. desde casa
Dispositivo: Ordenador corporativo vs. dispositivo personal
Horario: Turno habitual vs. acceso nocturno inusual
Datos accedidos: Consulta general vs. acceso a historia de VIP
Patrón de comportamiento: Actividad sospechosa (accesos masivos, horarios anómalos)

Ejemplo: Un médico accediendo desde su consulta habitual solo necesita usuario/contraseña. El mismo médico accediendo desde un móvil personal fuera del horario laboral requiere 2FA y queda registrado para auditoría.

7.3. Firma de Documentos Clínicos

Marco Legal

La Ley 41/2002 de Autonomía del Paciente establece que toda la documentación clínica debe estar firmada. En formato electrónico, requiere firma electrónica avanzada o cualificada.

Tipos de Documentos y Requisitos

Documento	Tipo de Firma	Observaciones
Receta electrónica	Avanzada/Cualificada	Firmada por el médico prescriptor, incluye sello de tiempo
Informe clínico	Avanzada/Cualificada	Debe identificar inequívocamente al profesional firmante
Consentimiento informado	Cualificada (paciente)	Puede ser firma manuscrita digitalizada o biométrica avanzada
Parte de baja/alta	Cualificada	Tiene efectos ante INSS, requiere máximas garantías
Informe de alta	Avanzada	Documento resumen para continuidad asistencial

Formatos de Firma en Documentos Sanitarios

XAdES (XML Advanced Electronic Signatures): Para documentos XML como recetas o mensajes HL7
PAdES (PDF Advanced Electronic Signatures): Para informes en PDF, permite firma visible
CAdES (CMS Advanced Electronic Signatures): Para documentos binarios o cuando se firma el contenido separadamente del formato

Plataforma @firma en el SAS

El SAS utiliza componentes de la plataforma @firma del Gobierno para integrar firma electrónica en aplicaciones:

Cliente @firma: Applet Java (legacy) o aplicación nativa para firma desde navegador
@firma móvil: Componente para firma desde apps Android/iOS
Validador @firma: Servicio web para validar firmas según normativa
TS@ (Autoridad de Sellado de Tiempo): Para añadir timestamp cualificado

8. Reglamento eIDAS2 e Identidad Digital Europea

8.1. La Propuesta de Identidad Digital Europea

Como mencionamos, eIDAS2 introduce el concepto revolucionario de la Cartera Europea de Identidad Digital (European Digital Identity Wallet – EUDI Wallet).

Características Clave

Aplicación móvil (también extensión de navegador) emitida o reconocida por cada Estado miembro
Almacena identidad electrónica del ciudadano (equivalente a DNIe pero en formato digital nativo)
Credenciales verificables para múltiples propósitos (edad, cualificaciones, permisos…)
Reconocimiento mutuo obligatorio en toda la UE
Control del usuario sobre qué datos comparte y con quién
Interoperabilidad técnica mediante estándares comunes

8.2. Arquitectura Técnica del EUDI Wallet

El wallet se basa en el modelo de Identidad Auto-Soberana (Self-Sovereign Identity – SSI) utilizando:

Identificadores Descentralizados (DID): Identificadores únicos controlados por el usuario
Credenciales Verificables (VC): Atestaciones digitales firmadas por emisores de confianza
Blockchain/DLT (opcional): Para registro de DIDs y esquemas de credenciales
Zero-Knowledge Proofs: Permite probar atributos sin revelar datos subyacentes (ej: demostrar mayoría de edad sin mostrar fecha de nacimiento)

Casos de Uso

Identificación online: Acceder a servicios públicos o privados usando el wallet

Firma electrónica: El wallet incluye capacidad de firma cualificada

Presentación de credenciales: Demostrar titulaciones, permisos profesionales, edad…

Preservación de privacidad: Compartir solo la información estrictamente necesaria

8.3. EUDI Wallet en el Sector Sanitario: Casos de Uso

💼 Escenarios de Uso en Sanidad

1. Cartera Sanitaria Digital

Tarjeta sanitaria europea en formato digital
Historial de vacunación (como se demostró con el certificado COVID)
Alergias y datos de emergencia
Consentimientos para tratamientos

2. Receta Electrónica Transfronteriza

Ciudadano español de vacaciones en Italia presenta su wallet
Farmacia italiana valida su identidad y accede a recetas prescritas en España
Dispensación registrada en ambos sistemas automáticamente

3. Autenticación de Profesionales

Médico especialista con wallet que contiene credencial de colegiación
Accede a sistema hospitalario de otra CCAA usando su wallet
El sistema valida automáticamente su identidad y habilitación profesional

4. Gestión de Consentimientos

Paciente almacena en su wallet consentimientos firmados digitalmente
Puede revocarlos en cualquier momento
Trazabilidad completa y control del paciente sobre sus datos

8.4. Calendario de Implantación eIDAS2

Fecha	Hito
2024	Aprobación definitiva del Reglamento
2025	Publicación de especificaciones técnicas (ARF – Architecture Reference Framework)
2026	Proyectos piloto nacionales (Large Scale Pilots)
2027	EEMM deben ofrecer wallets a ciudadanos y empresas
2028	Adopción masiva, reconocimiento mutuo pleno

8.5. Arquitectura Técnica del EUDI Wallet: El Futuro de la Identidad Digital Sanitaria

Mira, aquí es donde la cosa se pone realmente interesante. Porque todo lo que hemos hablado hasta ahora sobre certificados digitales, CLAVE, autenticación federada… está bien, funciona, lleva años operativo. Pero el EUDI Wallet representa un cambio de paradigma completo en cómo entendemos la identidad digital. Y para el sector sanitario, las implicaciones son enormes.

Vamos a profundizar de verdad en cómo funciona técnicamente este sistema, porque no es simplemente «una app que guarda documentos digitales». Es mucho más sofisticado que eso. Es una arquitectura completa basada en principios de identidad auto-soberana, criptografía avanzada y protección de la privacidad desde el diseño.

8.5.1. Identidad Auto-Soberana: Un Cambio de Paradigma

Antes de meternos en los detalles técnicos, necesitas entender el cambio conceptual que representa el EUDI Wallet. Tradicionalmente, tu identidad digital estaba controlada por terceros. Cuando usas CLAVE, tu identidad está en los servidores del Ministerio. Cuando usas un certificado digital, la Autoridad de Certificación tiene control sobre su validez y puede revocarlo. Tú eres el sujeto de la identidad, pero no el controlador.

La identidad auto-soberana invierte esta lógica. Tú controlas tu identidad digital. Tú decides qué información compartes, con quién, y cuándo. Las credenciales que atestiguan tus atributos, aunque sean emitidas por autoridades confiables como el Ministerio del Interior o el Servicio Andaluz de Salud, están bajo tu control exclusivo en tu wallet. Nadie puede acceder a ellas sin tu consentimiento explícito.

Este modelo se basa en tres principios fundamentales que debes grabar a fuego. El primero es la minimización de datos. Solo compartes la información estrictamente necesaria para cada transacción. Si una farmacia necesita verificar que eres mayor de dieciocho años para venderte un medicamento, tu wallet puede demostrar ese hecho sin revelar tu fecha de nacimiento exacta, tu nombre completo o tu dirección. El segundo principio es el consentimiento informado. Cada vez que tu wallet comparte información, tú debes autorizar explícitamente esa acción, viendo exactamente qué datos se van a compartir. Y el tercer principio es la portabilidad. Tus credenciales digitales no están atadas a un proveedor específico. Puedes mover tus credenciales entre diferentes wallets compatibles con el estándar europeo.

8.5.2. Componentes Técnicos del Ecosistema EUDI Wallet

El ecosistema del EUDI Wallet se compone de varios actores técnicos que interactúan siguiendo protocolos estandarizados. Vamos a desglosarlos uno por uno porque entender estos componentes es crucial para comprender cómo funcionará el sistema en el SAS.

El Wallet (Cartera Digital del Usuario)

Es una aplicación móvil, aunque también puede ser una extensión de navegador o incluso un componente embebido en el sistema operativo del dispositivo. Para el caso español y andaluz, cada ciudadano tendrá acceso a un wallet emitido o reconocido oficialmente por el Estado. Este wallet debe cumplir requisitos técnicos muy estrictos definidos en el Architecture Reference Framework de la Comisión Europea.

El wallet tiene varias responsabilidades técnicas críticas. Genera y almacena de forma segura las claves criptográficas del usuario. Estas claves son la base de su identidad digital y deben protegerse con el máximo nivel de seguridad. En dispositivos móviles modernos, esto significa almacenamiento en el Secure Element del dispositivo o en el Trusted Execution Environment, zonas de hardware especialmente protegidas que ni siquiera el sistema operativo puede acceder directamente.

El wallet también recibe credenciales verificables de emisores confiables, las almacena de forma cifrada, y las presenta a verificadores cuando el usuario lo autoriza. Implementa protocolos de comunicación seguros para el intercambio de credenciales, gestiona la renovación de credenciales caducadas, y mantiene un registro local de todas las transacciones realizadas, aunque este registro nunca sale del dispositivo del usuario salvo que él decida compartirlo.

El Issuer (Emisor de Credenciales Verificables)

Los emisores son organizaciones de confianza que atestiguan atributos sobre los ciudadanos mediante credenciales verificables. En el contexto sanitario andaluz, el Servicio Andaluz de Salud actuaría como emisor de múltiples tipos de credenciales. Por ejemplo, podría emitir una credencial que atestigua que eres paciente del sistema sanitario público andaluz, otra que certifica tu estado de vacunación, otra con tu grupo sanguíneo, y otra que documenta que tienes prescrita medicación crónica.

Técnicamente, cuando el SAS actúa como emisor, debe implementar un servicio que genere credenciales verificables siguiendo el estándar W3C Verifiable Credentials. Este servicio consulta los sistemas corporativos del SAS para obtener la información veraz sobre el paciente. Por ejemplo, consultaría la Base de Datos Poblacional para verificar que efectivamente eres paciente del SAS, o consultaría el registro de vacunación para obtener las dosis que has recibido. Con esa información, genera una credencial verificable que es esencialmente un documento JSON firmado digitalmente con la clave privada del SAS.

Pero aquí viene algo fascinante. La credencial no solo contiene los datos en texto claro, sino que también incluye compromisos criptográficos que permiten demostraciones selectivas de información. Esto es lo que permite que más tarde puedas demostrar que tienes ciertas vacunas sin revelar todo tu historial de vacunación. El emisor debe también gestionar el ciclo de vida de las credenciales, incluyendo su eventual revocación si la información deja de ser válida.

El Verifier (Verificador de Credenciales)

Los verificadores son entidades que necesitan comprobar información sobre los ciudadanos. En el ámbito sanitario, una farmacia actuaría como verificador cuando necesita confirmar que tienes una receta válida. Un hospital de otra comunidad autónoma actuaría como verificador cuando necesita acceder a tu información sanitaria de emergencia. Una compañía de seguros actuaría como verificador cuando necesita confirmar tu estado de salud para procesar un siniestro.

Técnicamente, el verificador implementa un servicio que solicita credenciales específicas al wallet del usuario. Esta solicitud especifica exactamente qué atributos necesita conocer y para qué propósito, cumpliendo con el principio de minimización de datos del RGPD. El wallet del usuario presenta la solicitud al ciudadano de forma comprensible, mostrando algo como: «La Farmacia San José solicita verificar que tienes una receta válida para Ibuprofeno seiscientos miligramos. ¿Autorizas compartir esta información?». Si el usuario acepta, el wallet genera una presentación verificable que contiene solo la información solicitada, firmada criptográficamente para demostrar su autenticidad.

El verificador recibe esta presentación y debe validarla técnicamente. Esto implica varios pasos. Primero, verifica la firma criptográfica para asegurarse de que la credencial fue realmente emitida por quien dice ser el emisor, en este caso el SAS. Segundo, verifica que la credencial no ha sido revocada, consultando un registro de revocación que puede estar basado en blockchain o en listas públicas actualizadas. Tercero, verifica que la credencial sigue siendo válida temporalmente, que no ha caducado. Y cuarto, verifica que el usuario que presenta la credencial es realmente el titular legítimo, mediante pruebas de posesión de las claves asociadas a la identidad.

El Trust Registry (Registro de Confianza)

Para que todo este ecosistema funcione, necesitas un registro que establezca quién es de confianza para actuar como emisor o verificador. Este registro es el Trust Registry. En el contexto europeo, habrá un registro a nivel de la Unión Europea que lista todos los emisores oficiales autorizados. España tendrá su propio registro nacional, y Andalucía podría tener un registro regional para emisores autonómicos como el SAS.

Cuando tu wallet recibe una credencial de un supuesto emisor «Servicio Andaluz de Salud», antes de aceptarla y almacenarla, el wallet consulta el Trust Registry para verificar que efectivamente el SAS está autorizado como emisor de credenciales sanitarias, y que la clave pública con la que se firmó la credencial pertenece realmente al SAS. Esto previene ataques donde un emisor malicioso intente emitir credenciales falsas haciéndose pasar por una entidad legítima.

8.5.3. Tecnologías Subyacentes: DIDs y Verifiable Credentials

Ahora vamos a profundizar en las tecnologías específicas que hacen posible todo esto. Porque cuando dices «tengo una credencial verificable en mi wallet», hay una cantidad impresionante de tecnología trabajando por debajo para que eso funcione de forma segura y privada.

Decentralized Identifiers (DIDs)

Los DIDs son identificadores únicos que no requieren una autoridad central para su creación o gestión. Es como un DNI, pero que tú mismo generas sin necesidad de ir a la Policía, y que además es globalmente único y verificable. Un DID tiene este aspecto técnico: did:example:123456789abcdefghi. La primera parte, «did», indica que es un Decentralized Identifier. La segunda parte, «example», es el método DID, que especifica qué sistema subyacente se usa para registrar y resolver este DID. Y la tercera parte es el identificador único específico.

Existen diferentes métodos DID. Algunos usan blockchain como registro descentralizado. Por ejemplo, did:ethr utiliza la blockchain de Ethereum. Otros usan sistemas de clave pública tradicionales sin blockchain. Por ejemplo, did:key simplemente codifica una clave pública directamente en el identificador. Y otros usan registros centralizados pero con propiedades de descentralización en la gestión. Por ejemplo, did:web usa el sistema DNS tradicional pero permite que cada organización gestione sus propios DIDs.

Para el EUDI Wallet europeo, cada ciudadano tendrá un DID. Este DID se genera localmente en el wallet cuando lo activas por primera vez, y la clave privada asociada nunca sale de tu dispositivo. Cuando el SAS te emite una credencial verificable de vacunación, esa credencial está vinculada a tu DID. Cuando presentas esa credencial a una farmacia, la farmacia puede verificar criptográficamente que tú eres el legítimo titular de esa credencial porque puedes demostrar posesión de la clave privada asociada a ese DID, sin necesidad de revelar la clave privada en sí misma.

Verifiable Credentials (VCs)

Las credenciales verificables son documentos estructurados que atestiguan atributos sobre un sujeto. Están definidas por el estándar W3C Verifiable Credentials Data Model. Técnicamente, una credencial verificable es un objeto JSON que contiene varios componentes obligatorios. El contexto define el vocabulario y las reglas de interpretación de la credencial. El tipo especifica qué tipo de credencial es, por ejemplo «VaccinationCredential» o «PrescriptionCredential». El emisor identifica quién emitió la credencial mediante su DID. El sujeto identifica sobre quién es la credencial mediante el DID del titular. Las declaraciones de credenciales contienen los atributos específicos que se atestiguan. Y la prueba criptográfica es la firma digital del emisor que garantiza autenticidad e integridad.

Déjame mostrarte un ejemplo concreto de cómo sería una credencial verificable de vacunación COVID emitida por el SAS. Esto te ayudará a visualizar técnicamente cómo se estructura la información.

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/vaccination/v1"
  ],
  "id": "https://sas.junta-andalucia.es/credentials/vaccination/3732",
  "type": ["VerifiableCredential", "VaccinationCredential"],
  "issuer": {
    "id": "did:web:sas.junta-andalucia.es",
    "name": "Servicio Andaluz de Salud"
  },
  "issuanceDate": "2024-03-15T10:30:00Z",
  "expirationDate": "2029-03-15T23:59:59Z",
  "credentialSubject": {
    "id": "did:eudi:es:AND:12345678A",
    "type": "Person",
    "givenName": "María",
    "familyName": "García López",
    "birthDate": "1985-06-12",
    "vaccination": {
      "type": "Vaccination",
      "diseaseTarget": "COVID-19",
      "vaccine": {
        "medicineName": "Comirnaty",
        "manufacturer": "Pfizer-BioNTech",
        "atcCode": "J07BX03"
      },
      "doseNumber": 2,
      "doseSeries": 2,
      "dateOfVaccination": "2024-02-28",
      "administeredBy": {
        "name": "Centro de Salud Triana",
        "address": "Sevilla, Andalucía, España"
      },
      "batchNumber": "FG7823",
      "nextDoseDue": null
    }
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2024-03-15T10:30:00Z",
    "verificationMethod": "did:web:sas.junta-andalucia.es#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z3FXQjecWRbXb...S7sNLD8aq8yHKD6B"
  }
}

Fíjate en varios detalles técnicos importantes de esta estructura. El emisor se identifica mediante un DID del tipo web, lo que significa que su clave pública puede resolverse consultando el dominio sas.junta-andalucia.es en una ruta estandarizada. El sujeto de la credencial se identifica con un DID del tipo eudi, que será el estándar específico para los wallets europeos, incluyendo el código de país «es», la región «AND» para Andalucía, y un identificador vinculado al DNI del ciudadano.

La información de vacunación incluye todos los detalles necesarios: el nombre comercial de la vacuna, el fabricante, el número de dosis, la fecha, el centro donde se administró, y el número de lote. Esta riqueza de información es lo que hace que la credencial sea útil en múltiples contextos. Si viajas a otro país de la UE, su sistema sanitario puede verificar automáticamente tu estado de vacunación. Si tienes una reacción adversa, el número de lote permite rastrear si otros pacientes del mismo lote tuvieron problemas similares.

Y la prueba criptográfica usa el algoritmo Ed25519, que es una implementación eficiente de criptografía de curva elíptica. La proofValue es la firma digital propiamente dicha. Cualquier verificador puede tomar todo el contenido de la credencial, aplicar la clave pública del SAS que obtiene del DID did:web:sas.junta-andalucia.es, y verificar matemáticamente que la firma es válida, lo que garantiza que la credencial no ha sido alterada y que fue emitida realmente por el SAS.

8.5.4. Zero-Knowledge Proofs: Privacidad Matemática

Aquí es donde la tecnología se vuelve verdaderamente fascinante. Las Zero-Knowledge Proofs, o pruebas de conocimiento cero, son técnicas criptográficas que te permiten demostrar que cierto atributo es verdadero sin revelar el atributo en sí mismo. Suena como magia, pero es matemática pura.

Imagina este escenario real en el contexto sanitario. Una farmacia necesita verificar que tienes más de dieciocho años para venderte cierto medicamento sin receta que tiene restricción de edad. Con el sistema tradicional de certificados digitales o DNI, tendrías que mostrar tu DNI completo, revelando tu nombre, apellidos, fecha de nacimiento exacta, dirección, fotografía. La farmacia obtiene mucha más información de la que realmente necesita. Esto viola el principio de minimización de datos del RGPD.

Con una Zero-Knowledge Proof, tu wallet puede generar una prueba matemática que demuestra que tu fecha de nacimiento es anterior al tres de noviembre de dos mil siete, lo que implica que tienes más de dieciocho años, sin revelar cuál es tu fecha de nacimiento exacta. La farmacia recibe solo la información «Este usuario es mayor de dieciocho años: SÍ», junto con una prueba criptográfica que garantiza que esa afirmación es verdadera y está basada en una credencial válida emitida por una autoridad confiable, pero sin acceder nunca a tu fecha de nacimiento real.

¿Cómo funciona esto técnicamente? La implementación más común en el contexto de credenciales verificables usa esquemas como CL-Signatures de Camenisch-Lysyanskaya o BBS+ Signatures. Estos esquemas tienen una propiedad matemática especial: puedes tomar una credencial firmada que contiene múltiples atributos, y generar una prueba derivada que solo revela algunos de esos atributos, o que solo demuestra ciertas propiedades sobre esos atributos, sin que el verificador pueda obtener acceso a los atributos completos.

El proceso técnico funciona así. Cuando el SAS te emite una credencial de paciente que incluye tu nombre, fecha de nacimiento, número de tarjeta sanitaria y domicilio, esa credencial se firma usando un esquema de firma especial que permite pruebas selectivas. Tu wallet almacena esta credencial completa, pero cuando una farmacia solicita verificar solo tu edad, el wallet genera una presentación verificable que contiene únicamente la prueba de que edad mayor de dieciocho años es verdadera, derivada matemáticamente de la credencial original pero sin revelar la fecha de nacimiento.

La farmacia puede verificar esta prueba usando la clave pública del SAS, confirmando que la afirmación sobre tu edad está basada en una credencial válida emitida por el SAS, pero no obtiene acceso a tu fecha de nacimiento exacta ni a ningún otro atributo de la credencial original. La matemática garantiza que es imposible falsificar estas pruebas sin tener la credencial original válida, y al mismo tiempo garantiza que el verificador no puede extraer más información de la que intencionalmente se reveló.

⚡ Implicaciones para el RGPD: Esta capacidad de pruebas de conocimiento cero es revolucionaria desde el punto de vista de protección de datos. Permite cumplir perfectamente con el artículo cinco punto uno letra c del RGPD, que exige minimización de datos: «adecuados, pertinentes y limitados a lo necesario en relación con los fines para los que son tratados». Por primera vez, tenemos la tecnología para garantizar técnicamente que un verificador solo puede obtener exactamente la información que necesita, nada más. No depende de políticas organizativas o de buena fe, es una garantía matemática.

8.5.5. Flujos Técnicos Completos en el Contexto del SAS

Ahora vamos a recorrer varios flujos técnicos completos de cómo funcionaría el EUDI Wallet en escenarios reales del Servicio Andaluz de Salud. Estos ejemplos te darán una visión práctica de cómo todas las piezas que hemos visto encajan en la operativa diaria.

Escenario Uno: Emisión de Credencial de Paciente del SAS

📱 Flujo: Obtención de Credencial de Paciente SAS en el EUDI Wallet

Contexto: Laura, una ciudadana andaluza de treinta y dos años, acaba de instalar por primera vez la aplicación EUDI Wallet en su teléfono móvil. Quiere obtener su credencial digital de paciente del Servicio Andaluz de Salud que le permitirá identificarse en centros sanitarios, acceder a servicios digitales de salud, y compartir información sanitaria cuando sea necesario.

Paso Uno: Inicialización del Wallet

Laura abre la aplicación EUDI Wallet por primera vez. El wallet le pide que establezca un método de protección de acceso. Ella elige usar reconocimiento facial mediante Face ID de su iPhone, complementado con un PIN de seis dígitos como respaldo. El wallet explica que este método protegerá el acceso a todas sus credenciales y que nunca se compartirá con terceros.

En segundo plano, técnicamente el wallet está generando su DID. Específicamente, genera un par de claves criptográficas Ed25519. La clave privada se almacena en el Secure Enclave del iPhone, una zona de hardware especialmente protegida a la que ni siquiera el sistema operativo tiene acceso directo. La clave pública se usa para construir su DID, que tiene este formato: did:eudi:es:AND:28745632K. Este DID está vinculado a su DNI pero no es simplemente su DNI en formato digital. Es un identificador único derivado criptográficamente que permite verificación sin exponer directamente el DNI en cada transacción.

Paso Dos: Solicitud de Credencial al SAS

Laura navega en el wallet a la sección «Añadir credenciales» y ve una lista de emisores disponibles. Aparece el Servicio Andaluz de Salud entre las opciones. Selecciona «Credencial de Paciente SAS» y el wallet la redirige al servicio de emisión de credenciales del SAS.

Técnicamente, el wallet acaba de iniciar un protocolo OAuth 2.0 / OpenID Connect con el servicio emisor del SAS. Laura debe autenticarse ante el SAS para demostrar que efectivamente es paciente del sistema sanitario público andaluz. El SAS le ofrece varias opciones de autenticación: CLAVE, certificado digital, o DNI electrónico. Ella elige CLAVE con su certificado digital porque ya lo tiene instalado.

Una vez autenticada, el servicio emisor del SAS consulta la Base de Datos Poblacional para verificar que Laura está correctamente registrada como paciente. Obtiene su CIP, su fecha de nacimiento, su médico de familia asignado, su centro de salud de referencia, y otra información básica. Con estos datos, el servicio construye una credencial verificable.

Paso Tres: Emisión y Firma de la Credencial

El servicio emisor del SAS genera un objeto JSON de credencial verificable que contiene los atributos de Laura como paciente. Esta credencial incluye su nombre completo, su CIP, su fecha de nacimiento, su centro de salud asignado, su médico de familia, y la fecha de emisión de la credencial. También incluye el período de validez: la credencial será válida durante cinco años, alineado con la renovación de la tarjeta sanitaria física.

El servicio firma digitalmente esta credencial usando la clave privada corporativa del SAS. Esta clave está almacenada en un Hardware Security Module en el Centro de Proceso de Datos del SAS, garantizando el máximo nivel de seguridad. La firma usa el algoritmo Ed25519Signature2020, que es eficiente y compatible con el estándar W3C de credenciales verificables.

Adicionalmente, el servicio genera compromisos criptográficos para cada atributo usando BBS+ Signatures, lo que permitirá a Laura más adelante hacer revelaciones selectivas de información. Es decir, podrá demostrar solo algunos atributos de la credencial sin revelar todos los demás.

Paso Cuatro: Transferencia de la Credencial al Wallet

La credencial firmada se transmite de forma segura al wallet de Laura mediante una conexión HTTPS. El wallet recibe la credencial y antes de almacenarla, realiza varias verificaciones de seguridad. Primero, verifica que la firma criptográfica es válida usando la clave pública del SAS que obtiene del Trust Registry europeo. Segundo, verifica que el SAS está efectivamente autorizado como emisor de credenciales sanitarias según el registro de confianza. Tercero, verifica que la credencial está dirigida efectivamente a su DID.

Una vez verificada, el wallet almacena la credencial en su almacenamiento cifrado local. La credencial se cifra usando una clave derivada de la biometría de Laura, lo que significa que solo ella puede acceder a sus credenciales. El wallet muestra una notificación: «Has recibido correctamente tu Credencial de Paciente del Servicio Andaluz de Salud».

Laura puede ahora ver la credencial en su wallet. La interfaz le muestra de forma amigable la información: su foto, su nombre, su CIP, su centro de salud. También hay opciones avanzadas donde puede ver la credencial en formato JSON completo si tiene curiosidad técnica, verificar la firma criptográfica, o ver el historial de cuándo y con quién ha compartido esta credencial.

Escenario Dos: Presentación de Credencial en Farmacia

💊 Flujo: Dispensación de Medicamento con Verificación de Credencial

Contexto: Laura acude a una farmacia en Granada con una receta electrónica prescrita por su médico de familia en Sevilla. La farmacia necesita verificar su identidad como paciente del SAS y acceder a su receta electrónica.

Paso Uno: Solicitud de Verificación por la Farmacia

El farmacéutico introduce el CIP de Laura manualmente o escanea un código QR desde su wallet. El sistema de la farmacia detecta que Laura tiene capacidades de credencial verificable habilitadas, así que en lugar de usar el método tradicional de validación con tarjeta sanitaria física, genera una solicitud de presentación verificable.

Esta solicitud especifica exactamente qué información necesita la farmacia. En este caso, necesita verificar que Laura es paciente del SAS, conocer su CIP para acceder a su receta electrónica en el sistema, y opcionalmente verificar que no tiene alergias documentadas a componentes del medicamento que va a dispensar.

Técnicamente, el sistema de la farmacia genera un objeto de «Presentation Request» siguiendo el estándar W3C. Este objeto especifica los atributos requeridos, el propósito de la solicitud que es «dispensación de medicamento con receta electrónica», y un challenge criptográfico que Laura debe firmar para demostrar que es la poseedora legítima del wallet.

Paso Dos: Autorización por el Usuario

El sistema de la farmacia muestra un código QR en su pantalla. Laura escanea este código QR con su wallet. El wallet decodifica la solicitud de presentación y se la muestra a Laura en lenguaje claro y comprensible.

La pantalla de su wallet dice algo así: «Farmacia San Rafael solicita verificar la siguiente información: Tu identificación como paciente del SAS (nombre y CIP), y la existencia de alergias medicamentosas documentadas. Propósito: Dispensación de medicamento prescrito. ¿Autorizas compartir esta información?».

Laura revisa la solicitud. Puede ver exactamente qué atributos se van a compartir. Puede ver el nombre de la farmacia y un identificador verificado del establecimiento sanitario. Y puede decidir aceptar o rechazar la solicitud. Ella acepta tocando el botón «Autorizar» y autenticándose con Face ID para confirmar su consentimiento.

Paso Tres: Generación de Presentación Verificable

El wallet de Laura genera ahora una presentación verificable. Toma su credencial de paciente del SAS completa, pero no la envía entera a la farmacia. En su lugar, genera una prueba derivada que contiene solo los atributos solicitados. Extrae su nombre completo, su CIP, y la información sobre alergias si existe en su credencial. Los demás atributos como su fecha de nacimiento exacta, su dirección, su médico de familia asignado, no se incluyen en la presentación porque la farmacia no los solicitó.

La presentación incluye también una prueba criptográfica de que estos atributos provienen de una credencial válida emitida por el SAS. Esta prueba se genera usando las propiedades de BBS+ Signatures que permiten revelación selectiva. La prueba matemática garantiza que Laura no puede mentir sobre sus atributos, pero al mismo tiempo la farmacia no puede deducir información sobre atributos no revelados.

Adicionalmente, el wallet firma la presentación con la clave privada de Laura asociada a su DID. Esto crea una vinculación criptográfica entre la presentación y su identidad, demostrando que ella es la legítima poseedora de la credencial y no alguien que está presentando una credencial robada o copiada.

Paso Cuatro: Verificación y Uso de la Información

El wallet transmite la presentación verificable al sistema de la farmacia mediante comunicación NFC o escaneando otro código QR, según la infraestructura disponible. El sistema de la farmacia recibe la presentación y procede a verificarla técnicamente.

La verificación implica varios pasos criptográficos. Primero, verifica la firma de revelación selectiva usando la clave pública del SAS, confirmando que los atributos presentados provienen efectivamente de una credencial emitida por el SAS. Segundo, verifica la firma de Laura sobre la presentación usando su clave pública obtenida de su DID, confirmando que ella es la legítima poseedora. Tercero, verifica el challenge criptográfico para asegurarse de que la presentación fue generada específicamente para esta transacción y no puede ser reutilizada en otra farmacia, previniendo ataques de replay. Cuarto, consulta el registro de revocación para asegurarse de que la credencial de Laura no ha sido revocada por algún motivo.

Una vez verificada exitosamente la presentación, el sistema de la farmacia extrae el CIP de Laura y lo usa para consultar la receta electrónica en el sistema Receta XXI del SAS. La receta aparece, prescrita hace dos días por su médico de familia. El farmacéutico procede a dispensar el medicamento, registrando la dispensación en el sistema que automáticamente marca la receta como utilizada.

Todo este proceso, desde que Laura escanea el código QR hasta que se verifica su identidad, tarda menos de diez segundos. Es más rápido que buscar la tarjeta sanitaria física en el bolso, más seguro porque la verificación es criptográfica, y más privado porque la farmacia solo obtiene la información estrictamente necesaria.

9. Aplicación Práctica en el Servicio Andaluz de Salud

9.1. Política de Seguridad TI del SAS

La Política de Seguridad del SAS (basada en ENS nivel MEDIO/ALTO) establece requisitos específicos sobre identificación y firma:

Autenticación de doble factor para accesos remotos a sistemas críticos
Uso de certificado corporativo para firma de documentos clínicos oficiales
Registro exhaustivo de accesos (pista de auditoría de 6 años mínimo)
Revisión periódica de privilegios y cuentas de usuario
Bloqueo automático de cuentas tras intentos fallidos
Formación obligatoria en ciberseguridad para todos los empleados

9.2. Sistemas Corporativos y su Autenticación

Diraya – Historia de Salud Digital

Acceso interno: Usuario/contraseña corporativa + integración con Active Directory
Acceso remoto: VPN con certificado + 2FA (token SMS)
Firma de documentos: Certificado corporativo SAS o certificado colegial reconocido
Auditoría: Registro de cada acceso a historia clínica (quién, qué, cuándo)

BPS (Base Poblacional de Salud)

Almacén central de datos de salud de todos los ciudadanos andaluces
Acceso muy restringido: solo aplicaciones autorizadas mediante certificados de sello
Los profesionales no acceden directamente, sino a través de Diraya

ClicSalud+ (Portal del Paciente)

Identificación ciudadana: CLAVE (cualquier método), DNIe, certificado digital
Servicios: Citas, informes, recetas, vacunación, consentimientos
Nivel de garantía: Sustancial (para funciones de consulta), Alto (para firma de consentimientos)

Receta XXI – Sistema de Receta Electrónica

Prescripción: Médico firma con certificado digital (cualificado preferentemente)
Dispensación: Farmacéutico identifica paciente (TSI o DNI) y valida receta
Interoperabilidad: Integrado con sistema nacional de receta (SIFAR)
Custodia: Sellos de tiempo para garantizar validez temporal

9.3. Gestión de Incidencias Relacionadas con Identificación

Como técnico TFA-STI, te enfrentarás a incidencias típicas:

Problema: Certificado caducado o revocado

Síntoma: Profesional no puede firmar documentos

Diagnóstico: Verificar fecha de expiración, consultar estado en OCSP/CRL

Solución: Renovación del certificado, contacto con la CA emisora

Problema: Navegador no reconoce certificado

Síntoma: «Certificado no válido» o no aparece en lista de selección

Diagnóstico: Falta cadena de confianza (CA intermedia), certificado no importado correctamente

Solución: Instalar CAs intermedias, verificar almacén de certificados del navegador

Problema: Fallo en autenticación 2FA

Síntoma: No llega SMS o token rechazado

Diagnóstico: Problema con proveedor de SMS, desincronización de token TOTP, móvil no registrado

Solución: Re-registro de segundo factor, sincronización manual, métodos alternativos (códigos de backup)

Problema: Acceso bloqueado por intentos fallidos

Síntoma: Cuenta bloqueada tras X intentos

Diagnóstico: Política de seguridad (bloqueo tras 3-5 intentos)

Solución: Desbloqueo por parte de administrador previa verificación de identidad, revisión de logs por posible ataque

10. Casos Prácticos de Troubleshooting: Diagnóstico y Resolución de Incidencias

Muy bien, ahora viene la parte que separa la teoría de la práctica. Has estudiado toda la normativa, entiendes cómo funciona CLAVE técnicamente, conoces los tipos de certificados… pero cuando llegues al SAS y te enfrentes a tu primera incidencia real, ¿sabrás por dónde empezar?

Estos casos prácticos están basados en incidencias reales que ocurren en el día a día del Servicio Andaluz de Salud. No son inventados, son situaciones con las que te vas a encontrar. Y lo importante no es solo saber resolverlas, sino hacerlo siguiendo un método sistemático que puedas replicar una y otra vez.

📋 Metodología de Diagnóstico: Antes de lanzarte a resolver cualquier incidencia, respira hondo y sigue siempre esta secuencia:

ESCUCHA: Obtén todos los detalles del usuario afectado sin interrumpir
REPRODUCE: Intenta replicar el problema en un entorno controlado si es posible
AÍSLA: Determina si el problema es local del usuario, del sistema, o de infraestructura
DIAGNOSTICA: Usa herramientas técnicas para identificar la causa raíz
RESUELVE: Aplica la solución apropiada
DOCUMENTA: Registra la incidencia, diagnóstico y solución en el sistema de tickets
PREVIENE: Identifica si hay medidas preventivas para evitar recurrencias

10.1. Caso Práctico: Certificado Digital No Reconocido en Navegador

🎫 Incidencia #2025-03847 – Médico no puede firmar informes en Diraya

CONTEXTO: Martes, 9:15 AM. Recibes un ticket de la Dra. Carmen Ruiz, médico de familia del Centro de Salud Macarena (Sevilla). El ticket dice: «No puedo firmar los informes de alta desde esta mañana. Me dice que mi certificado no es válido. Ayer funcionaba perfectamente. Tengo 15 informes pendientes de firmar y los pacientes esperan. URGENTE.»

INFORMACIÓN INICIAL:

Usuario: Dra. Carmen Ruiz (DNI: 28.XXX.XXX-K)
Centro: CS Macarena
Sistema afectado: Diraya Historia de Salud Digital
Navegador: Chrome 120 en Windows 10
Última vez que funcionó: Ayer lunes por la tarde
Mensaje de error: «Certificado no válido o no reconocido»

PASO 1: PRIMERA INTERACCIÓN Y RECOPILACIÓN DE INFORMACIÓN

Llamas a la Dra. Ruiz y le pides que te lea exactamente el mensaje de error completo que aparece en pantalla. Te dice: «Error al cargar el certificado. No se encuentra un certificado válido en el sistema o el certificado ha caducado.»

Le preguntas: ¿Has instalado alguna actualización de Windows o del navegador recientemente? Respuesta: «Sí, ayer por la noche el ordenador se reinició solo y esta mañana Chrome me pidió actualizar.»

Bingo. Ya tienes una primera hipótesis. Las actualizaciones de Windows o del navegador pueden afectar al almacén de certificados o a la compatibilidad con ciertos componentes de firma.

PASO 2: VERIFICACIÓN REMOTA DEL CERTIFICADO

Le pides a la Dra. Ruiz que abra el Administrador de Certificados de Windows mientras tú le das instrucciones paso a paso por teléfono. Le dices que pulse Windows+R, escriba «certmgr.msc» y pulse Enter.

Ahora navegas con ella: Certificados – Usuario actual → Personal → Certificados. Le pides que busque su certificado corporativo del SAS. Lo encuentra. Bien, el certificado está instalado.

Le pides que haga doble clic en el certificado y vaya a la pestaña «General». Ahí debe aparecer una frase que diga «Tiene una clave privada que corresponde a este certificado». Ella te confirma que sí aparece. Perfecto, la clave privada está vinculada.

Ahora le pides que mire la pestaña «Detalles» y busque las fechas «Válido desde» y «Válido hasta». Te dice: «Válido desde 15/01/2023 hasta 15/01/2025». Hoy es 3 de noviembre de 2025.

Ahí está el problema. El certificado caducó hace casi 10 meses. Pero espera… ayer funcionaba. ¿Cómo es posible?

ANÁLISIS: Es posible que ayer aún funcionara porque el sistema tenía cacheada una validación exitosa del certificado o porque había algún problema con la sincronización horaria que hizo que el sistema no detectara la caducidad. Pero con la actualización de Windows y el reinicio, el caché se limpió y ahora el sistema correctamente detecta que el certificado está caducado.

PASO 3: VERIFICACIÓN DE CERTIFICADOS DISPONIBLES

Le preguntas: ¿Tienes otros certificados instalados? DNIe, certificado FNMT, certificado del Colegio de Médicos? Ella responde: «Sí, tengo mi DNIe en el lector.»

Le explicas que puede usar temporalmente su DNIe para firmar mientras tramitamos la renovación del certificado corporativo. Pero primero necesitas verificar que el DNIe esté operativo.

Le pides que abra Chrome, vaya a chrome://settings/security y busque la sección «Administrar certificados». En la pestaña «Personal» debe aparecer el certificado del DNIe si el lector está conectado y los drivers instalados. Ella confirma que aparece.

PASO 4: SOLUCIÓN TEMPORAL – USO DEL DNIe

Le indicas que acceda de nuevo a Diraya, intente firmar un informe, y cuando le pida seleccionar certificado, elija el que dice «DIRECCION GENERAL DE LA POLICIA» (el del DNIe) en lugar del certificado corporativo SAS caducado.

Prueba. Funciona. La firma se aplica correctamente. Le explicas que esta es una solución temporal válida porque el DNIe contiene un certificado cualificado de ciudadano que es perfectamente válido para firmar documentos administrativos, aunque no incluye sus datos corporativos de adscripción al SAS.

PASO 5: SOLUCIÓN DEFINITIVA – RENOVACIÓN DEL CERTIFICADO CORPORATIVO

Ahora le explicas que debe renovar su certificado corporativo del SAS. El procedimiento es el siguiente:

Solicitud de renovación: Debe acceder a la Intranet corporativa del SAS, sección «Certificados Digitales», y rellenar el formulario de renovación. Como su certificado anterior está caducado, necesita iniciar el trámite con su DNIe.
Validación de identidad: El sistema verificará automáticamente sus datos en el directorio corporativo del SAS (Active Directory) cruzándolos con su DNI.
Generación de par de claves: El sistema generará un nuevo par de claves RSA-2048 (o ECDSA-256 según la política actual) en su navegador. La clave privada quedará almacenada en el almacén de certificados de Windows.
Emisión del certificado: La Autoridad de Certificación corporativa del SAS (basada en Microsoft PKI) emitirá el nuevo certificado, válido por 2 años.
Instalación automática: El certificado se instalará automáticamente en su navegador.

Le dices que el proceso completo tarda unos 15 minutos. Mientras tanto, puede seguir trabajando con su DNIe para firmar documentos urgentes.

PASO 6: DOCUMENTACIÓN DE LA INCIDENCIA

Actualizas el ticket #2025-03847 con toda la información:

TICKET #2025-03847 - RESUELTO

USUARIO: Dra. Carmen Ruiz (DNI: 28.XXX.XXX-K)
FECHA: 03/11/2025 09:15
CENTRO: CS Macarena
SISTEMA: Diraya - Módulo de Firma Electrónica

SÍNTOMAS:
- Imposibilidad de firmar informes clínicos
- Mensaje de error: "Certificado no válido o no reconocido"
- Problema surgido tras actualización de Windows y Chrome

DIAGNÓSTICO:
- Certificado corporativo SAS caducado el 15/01/2025
- Certificado permaneció funcional por caché hasta reinicio del sistema
- DNIe del usuario operativo y disponible

SOLUCIÓN TEMPORAL (09:30):
- Configuración de firma con DNIe como método alternativo
- Usuario puede continuar firmando documentos urgentes

SOLUCIÓN DEFINITIVA (09:45):
- Inicio de proceso de renovación de certificado corporativo
- Certificado renovado y operativo
- Antiguo certificado caducado eliminado del almacén

CAUSA RAÍZ:
- Falta de notificación automática previa a caducidad del certificado
- Usuario no recibió avisos de renovación por filtro de spam en correo

ACCIONES PREVENTIVAS:
- Revisar sistema de notificaciones de caducidad de certificados
- Implementar recordatorio en pantalla de login de Diraya 30 días antes de caducidad
- Añadir a Dra. Ruiz a lista de seguimiento para futura renovación (2027)

TIEMPO TOTAL: 35 minutos
PRIORIDAD: ALTA (Afectación servicio asistencial)
TÉCNICO: [Tu nombre]

PASO 7: ANÁLISIS POST-INCIDENTE Y MEJORA CONTINUA

Después de resolver la incidencia, analizas si hay un problema sistémico. Consultas la base de datos de certificados corporativos y descubres que hay 43 certificados más que caducarán en los próximos 60 días. Generas un informe y lo envías al Coordinador de Sistemas con una propuesta: implementar un sistema automatizado de alertas que envíe notificaciones a los usuarios 90, 60 y 30 días antes de la caducidad.

También propones mejorar el sistema para que al hacer login en Diraya, si el certificado caduca en menos de 30 días, aparezca un aviso en pantalla con un enlace directo al proceso de renovación.

10.2. Caso Práctico: Fallo en Autenticación 2FA para Acceso VPN

🎫 Incidencia #2025-04112 – Enfermera no puede acceder a VPN corporativa

CONTEXTO: Viernes, 20:45 PM. Recibes una llamada en el móvil de guardia. Es Lucía Martínez, enfermera del Hospital Virgen del Rocío, que está de guardia localizable desde su domicilio. Necesita acceder urgentemente a Diraya para consultar la historia clínica de un paciente que acaba de ingresar en Urgencias con antecedentes complejos. No puede conectarse a la VPN corporativa.

INFORMACIÓN INICIAL:

Usuario: Lucía Martínez (usuario corporativo: lmartinez)
Ubicación: Domicilio particular (fuera de red corporativa)
Sistema: Cliente VPN Cisco AnyConnect
Dispositivo: Portátil corporativo Windows 10
Último acceso exitoso: Hace 3 días
Urgencia: CRÍTICA (afecta atención paciente urgente)

PASO 1: VERIFICACIÓN DE CREDENCIALES PRIMARIAS

Por teléfono, le preguntas qué mensaje de error aparece exactamente. Ella lee: «Autenticación fallida. Verifique sus credenciales y el código de segundo factor.»

Primera comprobación básica: ¿Está segura de que su usuario y contraseña son correctos? Ella confirma que sí, que es el mismo usuario de siempre. Le pides que pruebe a escribir la contraseña en el Bloc de Notas primero para asegurarse de que no hay un error tipográfico. Prueba. La contraseña está bien escrita.

PASO 2: VERIFICACIÓN DEL SEGUNDO FACTOR

El sistema VPN del SAS usa autenticación de doble factor: usuario/contraseña + código OTP (One-Time Password) enviado por SMS al móvil registrado.

Le preguntas: ¿Te está llegando el SMS con el código? Respuesta: «Sí, me llega. Introduzco el código de 6 dígitos que pone en el SMS, pero me dice que el código es incorrecto o ha caducado.»

Interesante. El SMS llega, lo que significa que el sistema de envío funciona y que el número de móvil está correctamente registrado. El problema está en la validación del código OTP.

PASO 3: DIAGNÓSTICO REMOTO DE SINCRONIZACIÓN TEMPORAL

Los códigos OTP funcionan mediante un algoritmo (TOTP – Time-based One-Time Password) que genera códigos que cambian cada 30 segundos basándose en la hora actual. Si el reloj del servidor y el reloj del sistema del usuario están desincronizados más de un cierto umbral (típicamente 2-3 minutos), los códigos no coincidirán.

Le pides a Lucía que verifique la hora de su portátil. Le dices que mire la esquina inferior derecha de la pantalla. Ella dice: «Pone las 20:48». Tú miras tu reloj de sistemas (sincronizado con el NTP corporativo): son las 20:51.

Ahí está el problema. Su reloj está atrasado 3 minutos, justo en el límite donde el sistema de OTP empieza a rechazar códigos.

ANÁLISIS DE CAUSA: ¿Por qué su reloj está desincronizado? Le preguntas si ha viajado recientemente o si ha cambiado alguna configuración. Ella recuerda que hace dos días tuvo que arrancar el portátil sin conexión a Internet (se había quedado sin wifi en un sitio rural durante una visita domiciliaria) y que la batería del CMOS del portátil está débil (el equipo tiene 4 años). Cuando el portátil arrancó sin sincronización NTP, mantuvo la hora incorrecta.

PASO 4: SOLUCIÓN INMEDIATA

Le indicas a Lucía que sincronice manualmente la hora de su portátil:

Hacer clic derecho en el reloj de la barra de tareas
Seleccionar «Ajustar fecha y hora»
Activar «Establecer hora automáticamente» si está desactivado
Hacer clic en «Sincronizar ahora» bajo «Sincronizar el reloj»

Lucía sigue las instrucciones. El reloj se sincroniza. Ahora marca 20:52, la hora correcta.

Le pides que pruebe de nuevo a conectarse a la VPN. Introduce su usuario y contraseña. Recibe un nuevo SMS con un código OTP. Lo introduce. ¡Conexión exitosa! VPN conectada.

Lucía ya puede acceder a Diraya y consultar la historia clínica que necesitaba. Crisis evitada. El paciente puede ser atendido adecuadamente con la información de sus antecedentes.

PASO 5: SOLUCIÓN PREVENTIVA A LARGO PLAZO

Le explicas a Lucía que debe mantener activada la sincronización automática de hora y que si el problema se repite, probablemente necesite cambiar la batería CMOS del portátil. Le dices que abra un ticket de hardware para que el equipo de mantenimiento le cambie la batería en los próximos días.

También te anotas mentalmente que deberías revisar la configuración del servidor VPN. Una desincronización de 3 minutos está en el límite. ¿Debería el sistema ser más tolerante? ¿O más estricto? Esto es un equilibrio entre seguridad y usabilidad. Decides consultarlo en la próxima reunión del equipo de seguridad.

PASO 6: DOCUMENTACIÓN Y REGISTRO

TICKET #2025-04112 - RESUELTO

USUARIO: Lucía Martínez (lmartinez)
FECHA: 03/11/2025 20:45
UBICACIÓN: Remoto (domicilio)
SISTEMA: VPN Cisco AnyConnect + 2FA

SÍNTOMAS:
- Imposibilidad de conectar a VPN corporativa
- Código OTP rechazado sistemáticamente
- SMS con códigos recibidos correctamente

DIAGNÓSTICO:
- Desincronización de reloj del sistema (3 minutos de atraso)
- Códigos TOTP generados fuera de ventana de validez
- Causa raíz: Batería CMOS débil + arranque sin conexión NTP

SOLUCIÓN INMEDIATA (20:53):
- Sincronización manual de reloj del sistema
- Reconexión exitosa a VPN
- Usuario con acceso restaurado en 8 minutos

SOLUCIÓN A LARGO PLAZO:
- Ticket de hardware abierto: #HW-2025-0847
- Programado cambio de batería CMOS
- Usuario notificado de mantener sincronización automática activada

IMPACTO:
- Alta criticidad por afectación a atención urgente de paciente
- Sin impacto en paciente (resolución antes de necesidad crítica)
- Tiempo sin servicio: 8 minutos

LECCIONES APRENDIDAS:
- Implementar monitorización de portátiles con desincronización >1 minuto
- Considerar programa de reemplazo de baterías CMOS en equipos >3 años
- Documentar este caso para base de conocimiento (problema recurrente)

TÉCNICO DE GUARDIA: [Tu nombre]

10.3. Caso Práctico: Fallo de Integración SAML con CLAVE en ClicSalud+

🎫 Incidencia #2025-04589 – Usuarios no pueden acceder a ClicSalud+

CONTEXTO: Lunes, 08:15 AM. Llegas al Centro de Proceso de Datos del SAS y el coordinador de turno te intercepta en la puerta: «Tenemos un problema gordo. Los ciudadanos no pueden acceder a ClicSalud+ desde las 7:30. El CAU ya tiene 150 llamadas en cola. Necesitamos esto funcionando YA.»

INFORMACIÓN INICIAL:

Sistema afectado: Portal ClicSalud+ (https://clicsalud.sanidadandalucia.es)
Alcance: Todos los usuarios que intentan acceder con CLAVE
Hora de inicio: Aproximadamente 07:30 AM
Síntoma: Error «No se ha podido validar su identidad. Por favor, inténtelo más tarde»
Usuarios afectados: Estimado 500+ intentos fallidos en 45 minutos
Métodos alternativos: Acceso con certificado digital funciona correctamente

PASO 1: EVALUACIÓN INICIAL Y ALCANCE

Lo primero es entender el alcance exacto del problema. Te conectas al servidor de monitorización y compruebas los dashboards de ClicSalud+. Ves un pico de errores HTTP 500 en el endpoint de SAML (AssertionConsumerService) desde las 07:32 AM.

Accedes al panel de administración de ClicSalud+ y verificas el estado de los componentes. Todo aparece «verde» excepto el módulo de integración SAML, que muestra estado «Warning» con el mensaje: «Error al validar firma de assertion SAML».

Ahí tienes tu primer indicio concreto. El problema está en la validación de las assertions SAML que llegan de CLAVE.

PASO 2: REVISIÓN DE LOGS DEL SERVIDOR

Accedes al servidor de aplicaciones de ClicSalud+ mediante SSH y revisas los logs del módulo SAML. Ejecutas:

tail -f /var/log/clicsalud/saml-auth.log

Ves múltiples entradas como esta:

[2025-11-03 08:16:23] ERROR [SAMLResponseValidator] 
Signature validation failed for assertion ID: _a8f2e9b4c3d1a5f7
SignatureException: Cannot find signing certificate in trusted metadata
Certificate subject: CN=CLAVE IdP New, O=Ministerio, C=ES
Certificate serial: 4F:2A:E8:D3:C1:B9:7A:5E
Certificate SHA256: a1b2c3d4e5f6...

El mensaje es claro: el certificado con el que CLAVE está firmando las assertions no se encuentra en la lista de certificados confiables de ClicSalud+. O dicho de otra manera, CLAVE ha cambiado su certificado de firma y ClicSalud+ todavía no tiene el nuevo certificado en su configuración.

PASO 3: VERIFICACIÓN DEL METADATA DE CLAVE

Accedes a la URL pública del metadata de CLAVE para verificar si efectivamente han actualizado su certificado. El metadata de CLAVE se publica en una URL estándar que conoces de memoria:

curl https://clave.gob.es/metadata/idp-metadata.xml > /tmp/clave-metadata-nuevo.xml

Abres el archivo XML y buscas la sección KeyDescriptor con uso «signing». Ves que efectivamente hay un nuevo certificado X.509 que no coincide con el que ClicSalud+ tiene configurado.

Verificas la fecha de validFrom del nuevo certificado: 01/11/2025. Hace dos días. ¿Por qué no recibiste notificación? Buscas en tu correo y encuentras un email del Ministerio enviado hace 15 días anunciando la renovación del certificado de CLAVE, con instrucciones para que todos los Service Providers actualizaran sus metadatos antes del 01/11/2025.

El email llegó, pero… está en la bandeja de «Notificaciones técnicas» que nadie revisa sistemáticamente porque recibe 50 correos diarios. Falló el proceso humano de seguimiento de notificaciones críticas.

PASO 4: SOLUCIÓN DE EMERGENCIA

Necesitas restaurar el servicio cuanto antes. Tienes dos opciones:

Opción A (rápida pero sucia): Añadir manualmente el nuevo certificado de CLAVE a la configuración de ClicSalud+ sin quitar el antiguo. Esto permitiría validar assertions firmadas tanto con el certificado nuevo como con el antiguo durante un período de transición.

Opción B (correcta pero más lenta): Actualizar completamente el metadata de CLAVE importando el nuevo archivo XML oficial. Esto actualiza el certificado y cualquier otro cambio que pudiera haber en el metadata (nuevas URLs, nuevos servicios, etc.).

Decides ir por la opción B porque es la forma correcta y no añade mucho tiempo extra (unos 10 minutos más). Accedes a la consola de administración de ClicSalud+ y navegas a la sección «Proveedores de Identidad Federada». Seleccionas «CLAVE» y pulsas «Actualizar Metadata».

El sistema te pide la URL del nuevo metadata. Introduces: https://clave.gob.es/metadata/idp-metadata.xml

El sistema descarga el metadata, lo parsea, valida la firma del metadata (el propio metadata está firmado por CLAVE), y te muestra un resumen de los cambios detectados:

Certificado de firma: CAMBIO DETECTADO (nuevo certificado)
Certificado de cifrado: SIN CAMBIOS
URLs de Single Sign-On: SIN CAMBIOS
URLs de Single Logout: SIN CAMBIOS

Confirmas la actualización. El sistema importa el nuevo metadata y recarga la configuración. No requiere reinicio del servicio (hot reload).

PASO 5: PRUEBA Y VERIFICACIÓN

Desde tu portátil, abres una ventana de incógnito en el navegador (para evitar cookies cacheadas) y accedes a ClicSalud+. Pulsas «Acceder con Cl@ve». Te redirige a CLAVE. Te autenticas con tu certificado FNMT personal. CLAVE te devuelve a ClicSalud+ con la assertion SAML firmada con el nuevo certificado.

Éxito. Accedes correctamente a ClicSalud+. La validación de la firma SAML funciona.

Verificas los logs en tiempo real. Ya no hay errores de validación de firma. Las assertions se están validando correctamente.

Miras el dashboard de monitorización. Los errores HTTP 500 han cesado. Las autenticaciones exitosas han vuelto a la normalidad.

Son las 08:42 AM. El servicio ha estado caído 1 hora y 12 minutos. Llamas al coordinador y le confirmas que el problema está resuelto. Le pides que notifique al CAU que los usuarios ya pueden volver a acceder con normalidad.

PASO 6: ANÁLISIS POST-MORTEM Y MEJORAS

A las 11:00 AM se celebra la reunión post-mortem con el equipo. Presentas un análisis completo:

ANÁLISIS POST-MORTEM - Incidencia #2025-04589

LÍNEA DE TIEMPO:
- 01/11/2025 00:00 - CLAVE activa nuevo certificado de firma
- 03/11/2025 07:32 - Primeras autenticaciones fallidas detectadas
- 03/11/2025 08:15 - Técnico notificado e inicia diagnóstico
- 03/11/2025 08:42 - Servicio restaurado
- Duración total del incidente: 1h 12min
- Usuarios afectados estimados: 850+

CAUSA RAÍZ:
El certificado de firma de CLAVE se renovó el 01/11/2025, pero el metadata 
de ClicSalud+ no se actualizó. Las assertions firmadas con el nuevo 
certificado no pudieron ser validadas por ClicSalud+.

POR QUÉ NO SE ACTUALIZÓ A TIEMPO:
- El Ministerio envió notificación por email hace 15 días (18/10/2025)
- El email llegó a bandeja compartida "Notificaciones técnicas" 
- Esta bandeja no tiene responsable asignado de revisión sistemática
- No hay procedimiento documentado para renovaciones de certificados federados
- No hay alertas automatizadas cuando metadata de IdPs va a expirar

IMPACTO:
- Servicio crítico ciudadano inaccesible durante 1h 12min en horario prime
- Aproximadamente 850 ciudadanos afectados
- Carga excesiva en CAU (150+ llamadas)
- Imagen del SAS afectada (tendencia negativa en Twitter #ClicSaludCaido)
- Sin impacto en datos (confidencialidad, integridad, disponibilidad de datos 
  históricos preservada)

ACCIONES INMEDIATAS:
1. Metadata de CLAVE actualizado correctamente
2. Verificación de otros proveedores federados (todos OK)
3. Documentación del incidente completa

ACCIONES CORRECTIVAS A MEDIO PLAZO:
1. Implementar sistema de monitorización de caducidad de certificados en metadatas
   - Alert 60 días antes de expiración
   - Alert 30 días antes de expiración
   - Alert 7 días antes de expiración
   - Responsable: Equipo de Monitorización
   - Fecha límite: 30/11/2025

2. Crear procedimiento documentado "PROC-SAS-2025-017" para gestión de 
   renovaciones de certificados de proveedores federados
   - Responsable: Equipo de Seguridad
   - Fecha límite: 20/11/2025

3. Asignar responsable de revisión diaria de bandeja "Notificaciones técnicas"
   - Turno rotativo entre técnicos senior
   - Responsable de implementación: Coordinación TI
   - Fecha límite: Inmediato (desde 04/11/2025)

4. Configurar renovación automática de metadata desde fuente oficial cada 7 días
   con validación y aplicación automática si no hay cambios estructurales
   - Responsable: Equipo de Desarrollo
   - Fecha límite: 15/12/2025

5. Crear runbook (guía de resolución rápida) para este tipo de incidencias
   - Responsable: Documentación técnica
   - Fecha límite: 10/11/2025

LECCIONES APRENDIDAS:
- La gestión manual de certificados federados es propensa a errores
- Los sistemas de notificación deben estar respaldados por monitorización proactiva
- La automatización es crítica para infraestructuras de autenticación federada
- Los procedimientos de emergencia deben estar documentados y accesibles

10.4. Caso Práctico: Investigación de Accesos No Autorizados a Historia Clínica

🔍 Incidencia #2025-05234 – Posible acceso indebido a historia clínica

CONTEXTO: Miércoles, 10:30 AM. Recibes una llamada del Responsable de Protección de Datos del SAS. Un paciente ha presentado una queja formal alegando que profesionales sanitarios han accedido a su historia clínica en Diraya sin justificación asistencial. El paciente sospecha que alguien está «cotilleando» su información médica. Esto es extremadamente grave. Estamos hablando de una posible vulneración del RGPD, que puede tener consecuencias legales y sanciones económicas importantes.

El tono de tu interlocutor es serio. Te dice: «Necesito un informe forense completo de todos los accesos a la historia clínica de este paciente en los últimos seis meses. Con nombre de cada profesional que accedió, fecha, hora exacta, desde qué terminal, qué secciones consultó, y si había relación asistencial que justificara el acceso. Y lo necesito para mañana porque Inspección Sanitaria ya está investigando.»

INFORMACIÓN INICIAL:

Paciente afectado: Juan Carlos Fernández Ruiz (CIP: AND-XXXXXXXX)
Período a investigar: Últimos 6 meses (mayo – octubre 2025)
Sistema: Diraya Historia de Salud Digital
Alcance: Todos los accesos por cualquier profesional sanitario
Urgencia: MÁXIMA (plazo 24 horas para informe)
Implicaciones legales: RGPD, posible sanción AEPD, inspección sanitaria

PASO 1: COMPRENSIÓN DEL MARCO LEGAL Y NORMATIVO

Antes de tocar ningún sistema, necesitas entender perfectamente el marco legal en el que te mueves. Esto no es una incidencia técnica ordinaria. Estás realizando una investigación que puede acabar en un procedimiento sancionador o incluso judicial. Cada paso que des debe ser meticuloso, documentado y conforme a la normativa.

Los datos de salud son categoría especial según el artículo nueve del RGPD. El acceso a historias clínicas está regulado por la Ley cuarenta y uno barra dos mil dos de Autonomía del Paciente, que establece que solo pueden acceder los profesionales directamente implicados en la asistencia. El acceso sin justificación asistencial es una infracción muy grave según la Ley Orgánica tres barra dos mil dieciocho.

Además, la Política de Seguridad del SAS obliga a mantener registros de auditoría de todos los accesos a historias clínicas durante un mínimo de seis años. Estos registros deben incluir identificación del usuario, fecha, hora, recurso accedido y acción realizada. Esto es exactamente lo que necesitas ahora.

PASO 2: EXTRACCIÓN DE LOGS DE AUDITORÍA

Diraya mantiene una tabla de auditoría específica para accesos a historias clínicas. Cada vez que un profesional abre una historia, la consulta queda registrada con un nivel de detalle exhaustivo. Accedes al servidor de base de datos de Diraya mediante una conexión segura y preparas tu consulta SQL.

Pero espera, antes de ejecutar ninguna consulta, debes documentar el procedimiento. Abres un documento que titulas «INFORME FORENSE – Auditoría de accesos HC – CIP AND-XXXXXXXX» y comienzas a registrar cada acción que realizas con timestamp preciso. Esto es fundamental porque tu informe debe tener valor probatorio.

-- Consulta SQL de auditoría de accesos a Historia Clínica
-- Ejecutada por: [Tu nombre] - [Tu usuario corporativo]
-- Fecha y hora: 2025-11-03 10:45:32
-- Sistema: Diraya - Base de Datos de Auditoría (servidor: diraya-audit-01.sas.junta-andalucia.es)
-- Objetivo: Investigación de posibles accesos no autorizados

SELECT 
    audit.timestamp_acceso,
    audit.usuario_corporativo,
    prof.nombre_completo,
    prof.categoria_profesional,
    prof.centro_trabajo,
    prof.servicio,
    audit.terminal_origen,
    audit.ip_origen,
    audit.seccion_consultada,
    audit.tiempo_permanencia_segundos,
    audit.acciones_realizadas,
    asist.existe_relacion_asistencial,
    asist.tipo_atencion,
    asist.justificacion
FROM 
    diraya_audit.accesos_historia_clinica audit
LEFT JOIN 
    diraya_rrhh.profesionales prof 
    ON audit.usuario_corporativo = prof.usuario_corporativo
LEFT JOIN 
    diraya_asistencial.relaciones_asistenciales asist 
    ON audit.usuario_corporativo = asist.profesional_usuario
    AND asist.paciente_cip = 'AND-XXXXXXXX'
    AND audit.timestamp_acceso BETWEEN asist.fecha_inicio AND asist.fecha_fin
WHERE 
    audit.paciente_cip = 'AND-XXXXXXXX'
    AND audit.timestamp_acceso >= '2025-05-01 00:00:00'
    AND audit.timestamp_acceso <= '2025-10-31 23:59:59'
ORDER BY 
    audit.timestamp_acceso DESC;

Esta consulta es poderosa porque no solo te dice quién accedió y cuándo, sino que cruza esa información con la tabla de relaciones asistenciales. Esta tabla registra automáticamente cuando un paciente es asignado a un profesional, por ejemplo cuando ingresa en una planta hospitalaria, cuando tiene una cita programada en consulta externa, o cuando acude a urgencias. Si alguien accedió a la historia clínica pero no aparece ninguna relación asistencial en las fechas próximas, eso es una bandera roja enorme.

PASO 3: ANÁLISIS DE LOS RESULTADOS

La consulta devuelve doscientos treinta y siete registros de acceso. Eso es bastante para un solo paciente en seis meses. Exportas los resultados a un archivo CSV y comienzas el análisis meticuloso.

Abres el archivo en una hoja de cálculo y empiezas a clasificar los accesos. Creas columnas adicionales para tu análisis: "Justificación aparente", "Nivel de sospecha", "Requiere investigación adicional", "Observaciones".

Identificas varios patrones que necesitas analizar con detalle. Primero, hay muchos accesos legítimos que están claramente justificados. Por ejemplo, ves que el paciente tuvo una cita en cardiología el quince de mayo, y hay registros de acceso del cardiólogo el mismo día a las nueve y cuarenta de la mañana, justo la hora de la cita. Eso está perfectamente justificado. Marcas esos accesos como "LEGÍTIMO - Relación asistencial documentada".

También ves múltiples accesos del médico de familia del paciente a lo largo de los seis meses. Verificas en la tabla de adscrición de pacientes y confirmas que efectivamente ese médico es el titular asignado al paciente en su centro de salud. Un médico de familia puede necesitar consultar la historia de su paciente para preparar citas, revisar resultados de analíticas que le han enviado desde el hospital, o actualizar tratamientos crónicos. Estos accesos también son justificables, aunque algunos no tienen una relación asistencial específica en ese momento exacto. Los marcas como "LEGÍTIMO - Médico de familia titular".

Pero entonces encuentras algo que te llama la atención. Hay diecisiete accesos de una enfermera del Hospital Virgen Macarena, María José Torres, entre junio y septiembre. Los accesos son a diferentes horas, algunos en su horario laboral, otros a las once de la noche, uno incluso un domingo. Y aquí viene lo interesante: verificas la tabla de relaciones asistenciales y este paciente nunca ha estado ingresado en el Virgen Macarena. De hecho, verificas su historial y nunca ha acudido a ese hospital para nada. Ni urgencias, ni consultas, nada.

Esto es altamente sospechoso. ¿Por qué una enfermera de un hospital al que el paciente nunca ha acudido está accediendo repetidamente a su historia clínica? Y además en horarios extraños, incluyendo fuera de su jornada laboral.

PASO 4: INVESTIGACIÓN AMPLIADA DE LOS ACCESOS SOSPECHOSOS

Decides profundizar en los accesos de María José Torres. Ejecutas una consulta más específica para ver exactamente qué secciones de la historia clínica consultó y cuánto tiempo pasó en cada una.

SELECT 
    timestamp_acceso,
    seccion_consultada,
    tiempo_permanencia_segundos,
    terminal_origen,
    ip_origen,
    tipo_dispositivo
FROM 
    diraya_audit.accesos_historia_clinica
WHERE 
    usuario_corporativo = 'mtorres_enf'
    AND paciente_cip = 'AND-XXXXXXXX'
ORDER BY 
    timestamp_acceso;

Los resultados son reveladores. La enfermera no estaba consultando secciones que una enfermera normalmente necesitaría para cuidados asistenciales, como constantes vitales, tratamientos actuales o plan de cuidados. No. Estaba consultando sistemáticamente las secciones de "Antecedentes familiares", "Enfermedades previas", "Informes de salud mental" y "Resultados de analíticas". Pasaba varios minutos en cada sección. Y lo que es más revelador, varios de estos accesos se realizaron desde un dispositivo móvil, según indica el campo tipo_dispositivo.

Verificas la IP de origen de estos accesos. Algunos son desde la red corporativa del Virgen Macarena, lo cual sería normal si ella estuviera trabajando. Pero otros son desde IPs externas, residenciales, claramente desde su domicilio particular o desde redes móviles. Esto confirma que estaba accediendo fuera de su horario laboral y desde ubicaciones no corporativas.

Ahora necesitas entender el motivo. Buscas información sobre la enfermera en el directorio de recursos humanos. Ves su nombre completo, su NIF, su dirección... Y entonces buscas si hay alguna relación entre ella y el paciente. Compruebas si comparten apellidos, si viven en la misma zona, si podría haber algún vínculo familiar. Y efectivamente, descubres que comparten el segundo apellido y viven en el mismo distrito postal de Sevilla. Es muy probable que sean familiares, quizás primos.

Esto encaja con un patrón que habéis visto antes en el SAS: accesos indebidos motivados por curiosidad o preocupación familiar. La enfermera probablemente quería saber el estado de salud de su familiar, y utilizó su acceso profesional a Diraya para satisfacer esa curiosidad personal. Esto, aunque humanamente comprensible, es una vulneración gravísima de la confidencialidad. El acceso a historias clínicas debe estar justificado exclusivamente por necesidad asistencial, nunca por vínculos personales o familiares.

PASO 5: VERIFICACIÓN DE OTROS ACCESOS POTENCIALMENTE PROBLEMÁTICOS

Continúas analizando el resto de accesos. Encuentras otros tres casos que requieren explicación adicional. Hay dos accesos de administrativos del servicio de facturación del Hospital Virgen del Rocío. Los administrativos normalmente no deberían acceder a historias clínicas completas, solo a datos administrativos específicos para facturación. Verificas qué secciones consultaron y efectivamente solo accedieron a datos administrativos y de facturación, no a información clínica. Esto parece legítimo, pero lo marcas para verificación porque uno de los accesos fue en horario nocturno, lo cual es inusual para personal administrativo.

También hay un acceso de un médico residente de traumatología que consultó la historia el veintitrés de agosto. Verificas y ese día el paciente acudió a urgencias con un esguince de tobillo, así que está perfectamente justificado.

Y hay un acceso del propio paciente a través del portal ClicSalud+ el tres de octubre. Los pacientes tienen derecho a acceder a su propia historia clínica. Esto no solo es legítimo, es un derecho fundamental reconocido en la legislación. Lo marcas como "LEGÍTIMO - Acceso del propio paciente".

PASO 6: ELABORACIÓN DEL INFORME FORENSE

Con todo el análisis completado, elaboras un informe forense detallado. Este documento debe ser claro, preciso y tener valor probatorio. Estructuras el informe en las siguientes secciones:

═══════════════════════════════════════════════════════════════════════
INFORME FORENSE DE AUDITORÍA DE ACCESOS A HISTORIA CLÍNICA
═══════════════════════════════════════════════════════════════════════

CLASIFICACIÓN: CONFIDENCIAL - PROTECCIÓN DE DATOS
FECHA DE ELABORACIÓN: 03/11/2025
ELABORADO POR: [Tu nombre y cargo]
SOLICITADO POR: Responsable de Protección de Datos del SAS
CASO: Incidencia #2025-05234

1. OBJETO DE LA INVESTIGACIÓN
─────────────────────────────────────────────────────────────────────
Análisis forense de todos los accesos realizados a la historia clínica
del paciente Juan Carlos Fernández Ruiz (CIP: AND-XXXXXXXX) en el
sistema Diraya durante el período comprendido entre el 1 de mayo de 2025
y el 31 de octubre de 2025, con el objetivo de identificar posibles
accesos no justificados por relación asistencial.

2. METODOLOGÍA EMPLEADA
─────────────────────────────────────────────────────────────────────
2.1. Extracción de registros de auditoría de la base de datos Diraya
2.2. Cruce de información con tabla de relaciones asistenciales
2.3. Verificación de datos de profesionales en directorio de RRHH
2.4. Análisis de patrones de acceso (horarios, secciones, permanencia)
2.5. Investigación ampliada de accesos considerados sospechosos
2.6. Validación con normativa aplicable (RGPD, LOPDGDD, Ley 41/2002)

Todas las consultas realizadas han sido documentadas con timestamp y
usuario ejecutor para garantizar la trazabilidad del proceso de auditoría.

3. RESUMEN EJECUTIVO
─────────────────────────────────────────────────────────────────────
TOTAL DE ACCESOS REGISTRADOS: 237
- Accesos legítimos con relación asistencial documentada: 213 (89.9%)
- Accesos justificables (médico de familia, coordinación): 7 (3.0%)
- Accesos del propio paciente (ClicSalud+): 1 (0.4%)
- Accesos sospechosos pendientes de aclaración: 3 (1.3%)
- ACCESOS NO JUSTIFICADOS IDENTIFICADOS: 17 (7.2%)

HALLAZGO CRÍTICO: Se han identificado 17 accesos realizados por una
profesional sanitaria (enfermera) sin relación asistencial justificada,
varios de ellos realizados fuera del horario laboral y desde dispositivos
y ubicaciones no corporativas.

4. DETALLE DE ACCESOS NO JUSTIFICADOS
─────────────────────────────────────────────────────────────────────
PROFESIONAL: María José Torres Fernández
NIF: 28.XXX.XXX-Y
CATEGORÍA: Enfermera
CENTRO: Hospital Universitario Virgen Macarena
SERVICIO: Medicina Interna - Planta 3ª

RELACIÓN CON EL PACIENTE:
Investigación adicional revela que la profesional y el paciente comparten
segundo apellido y residen en el mismo distrito postal, lo que sugiere
posible vínculo familiar (pendiente de confirmación por RRHH).

RELACIÓN ASISTENCIAL CON EL PACIENTE:
NINGUNA. El paciente nunca ha sido atendido en el Hospital Virgen Macarena
ni tiene citas programadas en dicho centro. No existe justificación
asistencial que ampare estos accesos.

DETALLE DE LOS 17 ACCESOS:

┌──────────────────┬─────────────────────────┬──────────────────┬───────────┐
│ Fecha y Hora │ Origen │ Secciones │ Tiempo │
├──────────────────┼─────────────────────────┼──────────────────┼───────────┤
│ 15/06/2025 23:18 │ IP doméstica / Móvil │ Antecedentes │ 4 min 32s │
│ 22/06/2025 15:43 │ Red corporativa │ Informes S.Mental│ 6 min 15s │
│ 29/06/2025 22:07 │ IP doméstica / Móvil │ Analíticas │ 3 min 48s │
│ 05/07/2025 14:22 │ Red corporativa │ Antecedentes Fam.│ 5 min 03s │
│ 12/07/2025 20:35 │ IP doméstica / PC │ Informes clínicos│ 7 min 22s │
│ ... │ ... │ ... │ ... │
└──────────────────┴─────────────────────────┴──────────────────┴───────────┘

[Tabla completa con los 17 accesos en el anexo A]

CARACTERÍSTICAS PREOCUPANTES:
✗ 9 de 17 accesos (53%) realizados fuera del horario laboral
✗ 6 accesos desde dispositivo móvil personal
✗ 4 accesos en fin de semana
✗ Patrón de consulta enfocado en información sensible (salud mental,
antecedentes familiares) sin justificación asistencial
✗ Tiempo de permanencia extenso (promedio 5 minutos), indicativo de
lectura detallada, no consulta puntual profesional

5. ACCESOS PENDIENTES DE ACLARACIÓN
─────────────────────────────────────────────────────────────────────
Se identifican 3 accesos adicionales que, aunque no son claramente
irregulares, requieren aclaración por parte de los profesionales:

5.1. Administrativo Servicio Facturación - Acceso nocturno (02:34 AM)
5.2. Administrativo Servicio Facturación - Acceso desde IP no corporativa
5.3. [Detalle en anexo B]

6. MARCO LEGAL Y NORMATIVO APLICABLE
─────────────────────────────────────────────────────────────────────
Los accesos identificados constituyen potenciales infracciones de:

- RGPD (Reglamento UE 2016/679), Art. 5 (Principios de tratamiento)
- RGPD, Art. 32 (Seguridad del tratamiento)
- Ley Orgánica 3/2018 (LOPDGDD), Art. 83 (Deber de confidencialidad)
- Ley 41/2002 de Autonomía del Paciente, Art. 16 (Usos de la HC)
- Código Penal, Art. 197.2 (Descubrimiento y revelación de secretos)

Clasificación de la infracción según LOPDGDD: INFRACCIÓN MUY GRAVE
Sanción potencial AEPD: Hasta 20.000.000€ o 4% facturación anual global

7. RECOMENDACIONES
─────────────────────────────────────────────────────────────────────
INMEDIATAS:
1. Suspensión cautelar del acceso de la profesional María José Torres
al sistema Diraya, efectiva de forma inmediata
2. Comunicación formal a la profesional de la apertura de expediente
disciplinario
3. Notificación a su superior jerárquico y Dirección de Enfermería
4. Preservación de todas las evidencias digitales
5. Comunicación al paciente afectado de los accesos identificados,
conforme Art. 34 RGPD (Comunicación de violación de seguridad)

A CORTO PLAZO:
6. Entrevista formal con la profesional para recabar su versión
7. Investigación de posibles accesos similares a otros pacientes
8. Valoración de comunicación a AEPD (posible brecha de seguridad)
9. Valoración de denuncia penal según gravedad y circunstancias

A MEDIO PLAZO:
10. Implementación de alertas automáticas ante patrones de acceso sospechosos
11. Formación reforzada en confidencialidad y protección de datos
12. Revisión de política de acceso para personal con vínculos familiares

8. CONCLUSIONES
─────────────────────────────────────────────────────────────────────
El análisis forense ha identificado accesos a la historia clínica del
paciente Juan Carlos Fernández Ruiz que NO están justificados por
relación asistencial. Los accesos fueron realizados por una profesional
sanitaria sin competencia asistencial sobre el paciente, en múltiples
ocasiones, fuera de horario laboral y desde ubicaciones no corporativas.

El patrón de acceso sugiere motivación de curiosidad personal,
probablemente relacionada con vínculo familiar entre profesional y paciente.

Estos accesos constituyen una vulneración grave del derecho a la
confidencialidad del paciente y de la normativa de protección de datos.

Se recomienda la adopción inmediata de las medidas correctivas indicadas
y la evaluación de responsabilidades disciplinarias y, en su caso, legales.

═══════════════════════════════════════════════════════════════════════

ANEXOS:
A. Tabla completa de 17 accesos no justificados con detalle técnico
B. Detalle de 3 accesos pendientes de aclaración
C. Logs completos de auditoría (237 registros)
D. Consultas SQL ejecutadas durante la investigación
E. Normativa aplicable (extractos relevantes)

FIRMA DIGITAL DEL INFORME:
[Hash SHA-256 del documento]
[Firma electrónica del técnico investigador]
[Timestamp cualificado]

PASO 7: COMUNICACIÓN DE RESULTADOS Y SEGUIMIENTO

Envías el informe al Responsable de Protección de Datos mediante correo certificado. A las dos horas recibes su respuesta. Te agradece la exhaustividad del trabajo y te informa de que han suspendido cautelarmente el acceso de la enfermera a Diraya y han abierto expediente disciplinario. También te informan de que van a comunicar la incidencia al paciente afectado, como exige el RGPD, y que están valorando si deben notificarlo a la Agencia Española de Protección de Datos.

Tres días después te llaman para una reunión. Quieren que implementes un sistema de alertas automáticas que detecte patrones sospechosos de acceso: accesos fuera de horario laboral, accesos desde IPs no corporativas, accesos reiterados sin relación asistencial, accesos a historias de pacientes con apellidos coincidentes con el profesional. Este sistema debería generar alertas en tiempo real para que Protección de Datos pueda investigar de forma proactiva, no solo reactiva cuando hay quejas.

También te piden que desarrolles un módulo de formación obligatoria sobre confidencialidad que todos los profesionales sanitarios del SAS deberán completar anualmente, con especial énfasis en que el acceso a historias clínicas de familiares, amigos o conocidos está absolutamente prohibido salvo que exista relación asistencial justificada.

10.5. Caso Práctico: Problemas de Firma en Receta Electrónica

💊 Incidencia #2025-05891 - Médicos no pueden prescribir recetas electrónicas

CONTEXTO: Jueves, 11:20 AM. El sistema de monitorización dispara una alerta crítica: el número de recetas electrónicas firmadas en los últimos treinta minutos ha caído a cero en toda Andalucía. Esto es imposible. En un día laborable normal, el sistema procesa entre ochocientas y mil doscientas recetas cada treinta minutos. Un descenso a cero significa que hay un problema sistémico gravísimo.

Simultáneamente, el teléfono del CAU echa humo. Médicos de familia de toda Andalucía están llamando reportando que no pueden firmar recetas. Los pacientes esperan en las consultas. Algunos necesitan medicación urgente. El sistema de salud está efectivamente paralizado en su capacidad de prescripción farmacéutica. La presión es máxima.

INFORMACIÓN INICIAL:

Sistema afectado: Receta XXI (Sistema de Receta Electrónica)
Alcance: Toda Andalucía, todos los médicos prescriptores
Hora inicio: Aproximadamente 10:50 AM
Síntoma: Imposibilidad de firmar recetas electrónicamente
Mensaje de error: "Error al aplicar firma electrónica. Contacte con soporte técnico"
Sistemas colaterales: Diraya funciona normalmente, solo afectado módulo de receta

PASO 1: ACTIVACIÓN DE PROTOCOLO DE CRISIS

Te reúnes urgentemente con el coordinador de sistemas y el responsable del servicio de receta electrónica. Activáis el protocolo de crisis que tenéis documentado para incidencias de nivel uno, aquellas que afectan servicios críticos asistenciales en toda la comunidad autónoma. Esto implica convocar al equipo completo, suspender cualquier otra tarea no crítica, establecer un puente de conferencia permanente entre todos los técnicos involucrados, y abrir un canal de comunicación directo con la Dirección del SAS para mantenerles informados cada quince minutos.

También activáis el plan de contingencia. Mientras investigáis y resolvéis el problema, los médicos deben poder seguir prescribiendo. Enviáis una comunicación masiva a todos los centros sanitarios indicando que temporalmente deben usar el procedimiento de prescripción manual excepcional, emitiendo recetas en papel con firma manuscrita y sello. No es lo ideal, pero permite que la asistencia continúe.

PASO 2: DIAGNÓSTICO INICIAL DEL SISTEMA

Empiezas por lo básico. Verificas el estado de los servidores de aplicación de Receta XXI. Todos operativos. CPU al treinta por ciento, memoria normal, disco con espacio suficiente. No hay problemas de hardware ni de capacidad.

Verificas la conectividad de red entre los componentes del sistema. Todo correcto. Los servidores de aplicación pueden comunicarse con los servidores de base de datos, con los sistemas de firma, con la plataforma @firma. No hay problemas de red ni de firewall.

Revisas los logs de aplicación del módulo de receta electrónica. Y aquí empiezas a ver algo. Múltiples errores del tipo "SignatureException: Certificate chain validation failed" desde las diez y cincuenta de la mañana. Todos los intentos de firma están fallando con el mismo error: fallo en la validación de la cadena de certificados.

PASO 3: INVESTIGACIÓN DE LA PLATAFORMA DE FIRMA

El sistema de Receta XXI utiliza la plataforma @firma del Gobierno para gestionar todo el proceso de firma electrónica. Los médicos firman con sus certificados digitales corporativos o colegiales, y @firma se encarga de validar el certificado, añadir el sello de tiempo, y generar la firma en formato XAdES.

Accedes al servidor donde está desplegado el componente @firma. Revisas sus logs y encuentras el mismo patrón de errores. Cada intento de validar un certificado falla con "Cannot build certification path". Esto significa que @firma no puede construir la cadena de confianza desde el certificado del médico hasta una CA raíz confiable.

Pero espera, esto funcionaba perfectamente ayer. ¿Qué ha cambiado en las últimas veinticuatro horas? Revisas el historial de cambios en el sistema. No ha habido ningún despliegue de código nuevo. No se han modificado configuraciones. No hay actualizaciones del sistema operativo pendientes de aplicar. Todo parece igual que ayer.

Entonces decides comprobar algo más específico. Verificas el almacén de certificados de confianza de @firma, donde se guardan los certificados de las CAs raíz e intermedias que se consideran confiables. Ejecutas un comando para listar los certificados y sus fechas de caducidad.

keytool -list -v -keystore /opt/afirma/truststore.jks -storepass changeit | grep -A 5 "Alias name"

Y ahí lo ves. Hay un certificado de CA intermedia de la FNMT que caducó... esta mañana a las nueve. El certificado estuvo válido hasta las ocho y cincuenta y nueve con cincuenta y nueve segundos del tres de noviembre de dos mil veinticinco. Hace hora y media exactamente.

Este certificado intermedio es parte de la cadena de confianza de los certificados corporativos del SAS y de muchos certificados de colegios profesionales. Cuando un médico intenta firmar una receta, @firma valida su certificado, sube por la cadena de confianza hasta llegar a la CA intermedia de la FNMT, y ahí se encuentra con que el certificado de la CA intermedia está caducado. Como no puede completar la cadena de confianza hasta una CA raíz válida, rechaza la firma.

PASO 4: OBTENCIÓN DEL CERTIFICADO ACTUALIZADO

Necesitas urgentemente el nuevo certificado de CA intermedia de la FNMT. Accedes a la web de la FNMT, sección de Descarga de Certificados Raíz e Intermedios. Navegas hasta encontrar el certificado actualizado de la CA intermedia que necesitas. Efectivamente, hay uno nuevo válido desde el primero de noviembre y con vigencia hasta dos mil veintiocho.

Descargas el certificado en formato PEM. Antes de instalarlo en el truststore de @firma, verificas su autenticidad. Calculas su huella SHA-256 y la comparas con la publicada oficialmente en la web de la FNMT. Coinciden. También verificas que el certificado está firmado por la CA raíz de la FNMT que ya tienes en tu truststore. Todo correcto.

PASO 5: INSTALACIÓN DEL CERTIFICADO Y PRUEBAS

Ahora necesitas instalar el nuevo certificado en el truststore de @firma. Pero tienes tres servidores de @firma funcionando en cluster para alta disponibilidad. Necesitas actualizar los tres, y hacerlo de forma que no generes más indisponibilidad de la que ya tienes.

Decides empezar por un solo servidor, el servidor @firma-tres, que es el que menos carga suele tener. Lo sacas temporalmente del balanceador de carga para que no reciba peticiones. Luego instalas el certificado en su truststore.

# Instalación del nuevo certificado de CA intermedia FNMT
keytool -import -trustcacerts \
        -alias fnmt_ca_intermedia_2025 \
        -file /tmp/fnmt_ca_intermedia_nov2025.pem \
        -keystore /opt/afirma/truststore.jks \
        -storepass changeit

El sistema te pregunta si confías en el certificado. Verificas de nuevo la huella digital que muestra y confirmas que sí. Certificado instalado.

Ahora necesitas que @firma recargue el truststore. Como @firma corre en un servidor de aplicaciones Tomcat, no necesitas reiniciar todo el servidor, puedes simplemente recargar la aplicación. Esto minimiza el impacto.

# Recarga de la aplicación @firma sin reiniciar Tomcat
/opt/tomcat/bin/catalina.sh restart-app afirma

La aplicación se recarga en unos segundos. Ahora necesitas probar si funciona. Desde un navegador, accedes a la interfaz de pruebas de @firma y subes un documento de prueba junto con un certificado corporativo del SAS. Le das a firmar. Y... ¡funciona! La firma se aplica correctamente. La validación de la cadena de certificados es exitosa.

Perfecto. Ahora que sabes que la solución funciona, necesitas aplicarla a los otros dos servidores. Los actualizas uno por uno, sacándolos temporalmente del balanceador, instalando el certificado, recargando la aplicación, probando, y volviéndolos a meter en el balanceador. En quince minutos tienes los tres servidores actualizados y operativos.

PASO 6: VERIFICACIÓN DE SERVICIO Y COMUNICACIÓN

Miras el dashboard de monitorización. Las recetas firmadas comienzan a subir. Cincuenta en el último minuto. Cien. Doscientas. Trescientas. En cinco minutos el sistema vuelve a los niveles normales de mil recetas cada treinta minutos. El servicio está restaurado.

Comunicas al coordinador que el problema está resuelto. Él envía una comunicación urgente a todos los centros sanitarios: "El problema técnico con Receta XXI ha sido resuelto. El sistema está operativo. Pueden volver a prescribir recetas electrónicas con normalidad. Disculpen las molestias."

El tiempo total de indisponibilidad ha sido de una hora y cincuenta minutos. Menos de dos horas. En una situación crítica que afectaba a toda Andalucía, habéis diagnosticado, solucionado y restaurado el servicio en menos de dos horas. Eso es un buen resultado en circunstancias difíciles.

PASO 7: ANÁLISIS POST-MORTEM Y PREVENCIÓN

Por la tarde se convoca la reunión de análisis post-mortem. Presentas tu diagnóstico completo de lo ocurrido. Un certificado de CA intermedia caducó sin que nadie lo detectara a tiempo. La FNMT había publicado el nuevo certificado con dos meses de antelación, pero nadie en el equipo lo instaló porque no había un proceso sistematizado de monitorización de caducidad de certificados de CAs en el truststore.

Propones tres medidas preventivas. Primera, implementar un script que se ejecute semanalmente y que verifique las fechas de caducidad de todos los certificados en el truststore de @firma, generando alertas cuando un certificado esté a menos de sesenta días de caducar. Segunda, documentar un procedimiento estándar para la actualización de certificados de CAs en el truststore, con checklist y responsables asignados. Y tercera, crear un entorno de preproducción donde probar actualizaciones de certificados antes de aplicarlas en producción, para asegurarse de que no hay efectos colaterales inesperados.

El equipo aprueba las tres propuestas. Te asignan la tarea de implementarlas en las próximas dos semanas. También decides documentar este caso como un runbook, una guía paso a paso que cualquier técnico pueda seguir si vuelve a ocurrir un problema similar. Lo titulas "RUNBOOK-007: Fallo de validación de certificados en @firma" y lo guardas en la wiki técnica del equipo.

11. Conclusiones y Aspectos Clave

Bueno, hemos hecho un viaje intenso por el mundo de la identificación y firma electrónica. Ahora... ¿qué te llevas de todo esto?

🎯 Ideas Fundamentales

1. La confianza digital es el pilar de la e-Salud

Sin mecanismos robustos de identificación y firma, no hay transformación digital sanitaria posible. Cada acceso a una historia clínica, cada receta prescrita, cada cita solicitada... todo depende de saber con certeza quién está al otro lado.

2. eIDAS marca el camino europeo

El Reglamento eIDAS (y su evolución eIDAS2) no es solo normativa... es el marco de confianza que permite que un documento firmado en España tenga validez en Francia, que un certificado alemán sea reconocido en Italia. Eso es el verdadero mercado único digital.

3. El sector sanitario tiene necesidades específicas

No es lo mismo identificarte para consultar tu cuenta bancaria que para acceder a datos de salud. Aquí hablamos de categorías especiales de datos, de situaciones de urgencia vital, de profesionales que necesitan movilidad... Las soluciones tecnológicas deben adaptarse a esta realidad.

4. CLAVE y la identidad digital europea son el futuro

El modelo de "un certificado por administración" está superado. La tendencia es la federación de identidades, el SSO, los wallets digitales. Y el EUDI Wallet va a cambiar la forma en que nos relacionamos con las administraciones y servicios.

5. Como técnico del SAS, eres pieza clave

Tu trabajo no es solo "instalar certificados" o "dar de alta usuarios". Eres custodio de la seguridad de datos sanitarios de millones de andaluces. Cada decisión técnica tiene implicaciones legales, éticas y prácticas.

📚 Consejos para el Estudio

✏️ Método de estudio recomendado:

Primera lectura: Comprensión global del tema, subraya conceptos clave
Mapa conceptual: Crea tu propio esquema (utiliza el que te proporciono como base)
Fichas de normativa: Artículos clave de eIDAS, Ley 39/2015, ENS... Anki funciona genial para esto
Casos prácticos: Resuelve situaciones reales, ponte en el papel del técnico del SAS
Preguntas tipo test: Practica con las 25+ que incluyo, busca exámenes anteriores
Conexiones: Relaciona este tema con seguridad (ENS), protección de datos (RGPD), interoperabilidad (HL7, FHIR)

🔗 Interrelación con Otros Temas

Este tema no va solo. Conecta estrechamente con:

ENS (Esquema Nacional de Seguridad): Medidas de control de acceso, autenticación
RGPD-LOPDGDD: Protección de datos personales, datos especiales de salud
Ley 39/2015 y 40/2015: Procedimiento administrativo electrónico
Interoperabilidad sanitaria: Intercambio seguro de información clínica
Gestión de incidencias: Procedimientos ante compromisos de credenciales
Auditoría de sistemas: Trazabilidad de accesos

11. Cuestionario de Autoevaluación

Y ahora... vamos a ver qué has aprendido. Aquí tienes 30 preguntas tipo test al estilo de la oposición. No hagas trampa, ¿eh? 😉

1. Según el Reglamento eIDAS, ¿cuál es el nivel de garantía mínimo para que un medio de identificación electrónica notificado por un Estado miembro sea reconocido obligatoriamente por los demás Estados miembros?

A) Bajo

B) Sustancial

C) Alto

D) No existe reconocimiento mutuo obligatorio

✓ Respuesta correcta: B) Sustancial

Explicación: El Art. 6 de eIDAS establece el reconocimiento mutuo obligatorio para niveles sustancial y alto. El nivel bajo es voluntario.

2. ¿Qué tipo de firma electrónica tiene equivalencia plena con la firma manuscrita en TODOS los Estados miembros de la UE sin necesidad de prueba adicional?

A) Firma electrónica simple

B) Firma electrónica avanzada

C) Firma electrónica cualificada

D) Firma biométrica

✓ Respuesta correcta: C) Firma electrónica cualificada

Explicación: Art. 25.2 eIDAS: "A una firma electrónica cualificada se le reconocerán efectos jurídicos equivalentes a los de una firma manuscrita."

3. En el contexto de PKI, ¿qué protocolo permite consultar en tiempo real el estado de revocación de un certificado digital?

A) CRL (Certificate Revocation List)

B) OCSP (Online Certificate Status Protocol)

C) LDAP (Lightweight Directory Access Protocol)

D) SCEP (Simple Certificate Enrollment Protocol)

✓ Respuesta correcta: B) OCSP

Explicación: OCSP es el protocolo estándar para verificación en tiempo real del estado de certificados. CRL es una lista publicada periódicamente (puede quedar obsoleta).

4. ¿Cuál de las siguientes afirmaciones sobre la plataforma CLAVE es CORRECTA?

A) Solo permite identificación mediante certificado digital cualificado

B) Funciona exclusivamente con el protocolo OpenID Connect

C) Permite autenticación con diferentes niveles de garantía según el método elegido

D) Es un sistema exclusivo de la Administración General del Estado, no utilizable por CCAA

✓ Respuesta correcta: C)

Explicación: CLAVE admite múltiples métodos (Cl@ve Permanente, PIN, certificados, Cl@ve Firma ) con diferentes niveles de garantía. Utiliza SAML 2.0 para federación y pueden integrarse tanto AGE como CCAA.

5. El certificado corporativo de empleado público del SAS permite:

A) Únicamente la identificación en sistemas internos

B) Identificación y firma electrónica avanzada de documentos en el ejercicio de funciones públicas

C) Acceso físico a instalaciones pero no firma digital

D) Solo puede usarse en navegadores Internet Explorer

✓ Respuesta correcta: B)

Explicación: El certificado corporativo SAS es un certificado de empleado público que permite tanto identificación como firma electrónica avanzada para documentos oficiales en el ejercicio de la función pública sanitaria.

6. ¿Cuál de los siguientes NO es un requisito para que una firma sea considerada "avanzada" según eIDAS?

A) Estar vinculada al firmante de manera única

B) Permitir la identificación del firmante

C) Ser creada mediante un dispositivo cualificado de creación de firma

D) Estar vinculada a los datos firmados de modo que cualquier modificación sea detectable

✓ Respuesta correcta: C)

Explicación: El dispositivo cualificado de creación de firma es requisito específico de la firma CUALIFICADA, no de la avanzada. Los requisitos A, B y D están en el Art. 26 de eIDAS para firma avanzada.

7. Los datos biométricos utilizados para identificación de profesionales sanitarios se consideran según el RGPD:

A) Datos personales ordinarios

B) Datos de categoría especial que requieren medidas adicionales

C) Datos anonimizados que no requieren protección

D) Datos de contacto sin especial protección

✓ Respuesta correcta: B)

Explicación: Art. 9 RGPD clasifica los datos biométricos dirigidos a identificar de manera unívoca a una persona como categoría especial. Requieren base legal específica, EIPD y medidas de seguridad reforzadas.

8. ¿Qué componente de eIDAS2 permitirá a los ciudadanos almacenar credenciales verificables en su dispositivo móvil?

A) CLAVE móvil

B) DNI electrónico

C) EUDI Wallet (Cartera de Identidad Digital Europea)

D) Certificado en la nube cualificado

✓ Respuesta correcta: C)

Explicación: El EUDI Wallet es la gran novedad de eIDAS2, una aplicación que funcionará como cartera digital para almacenar identidad y credenciales con reconocimiento en toda la UE.

9. En una PKI, la cadena de confianza comienza en:

A) El certificado del usuario final

B) La CA intermedia

C) La CA raíz (Root CA) cuyo certificado es auto-firmado

D) El servidor OCSP

✓ Respuesta correcta: C)

Explicación: La CA raíz es la máxima autoridad de confianza, con certificado auto-firmado e incluido en navegadores y sistemas operativos. Desde ella se establece la cadena de confianza hacia certificados intermedios y finales.

10. El sello de tiempo electrónico (timestamp) según eIDAS tiene como función principal:

A) Cifrar documentos para proteger su confidencialidad

B) Vincular datos electrónicos a un instante concreto del tiempo

C) Identificar al firmante de un documento

D) Sustituir a la firma electrónica en documentos oficiales

✓ Respuesta correcta: B)

Explicación: Art. 41 eIDAS define el sello de tiempo como datos que vinculan otros datos a un momento concreto, aportando prueba de que existían en ese instante. Crítico para firma de documentos con validez temporal.

11. ¿Cuál de las siguientes es una Autoridad de Certificación cualificada en España?

A) Google Certificate Authority

B) FNMT-RCM (Fábrica Nacional de Moneda y Timbre)

C) Microsoft CA

D) Let's Encrypt

✓ Respuesta correcta: B)

Explicación: FNMT-RCM es prestador cualificado español incluido en la Trusted List. Let's Encrypt emite certificados SSL pero no cualificados según eIDAS. Google y Microsoft no son PSC cualificados en España.

12. El sistema SSO (Single Sign-On) implementado en el SAS permite:

A) Eliminar completamente el uso de contraseñas

B) Autenticarse una vez y acceder a múltiples sistemas sin volver a introducir credenciales

C) Acceder sin identificación a sistemas públicos

D) Compartir credenciales entre diferentes usuarios

✓ Respuesta correcta: B)

Explicación: SSO permite autenticación única que da acceso a múltiples aplicaciones integradas, mejorando experiencia de usuario y seguridad al reducir puntos de entrada. El SAS lo implementa con AD, LDAP y SAML.

13. Según la Ley 39/2015, Art. 10, los sistemas de identificación electrónica admitidos para relacionarse con administraciones públicas NO incluyen:

A) Certificados electrónicos cualificados

B) Sistema CLAVE

C) Contraseña de redes sociales

D) Claves concertadas en sede electrónica

✓ Respuesta correcta: C)

Explicación: El Art. 10 establece sistemas válidos: certificados, CLAVE, DNIe y claves concertadas. Las contraseñas de redes sociales NO son medio admitido para relación con administraciones.

14. ¿Qué formato de firma electrónica se utiliza típicamente para documentos PDF en el ámbito sanitario?

A) XAdES

B) PAdES

C) CAdES

D) JAdES

✓ Respuesta correcta: B)

Explicación: PAdES (PDF Advanced Electronic Signatures) es el estándar para firma de documentos PDF, permite firma visible. XAdES es para XML, CAdES para binarios/detached, JAdES para JSON.

15. La autenticación de doble factor (2FA) combina:

A) Dos contraseñas diferentes

B) Dos factores distintos entre: algo que sabes, algo que tienes, algo que eres

C) Usuario y contraseña del mismo factor

D) Dos certificados digitales

✓ Respuesta correcta: B)

Explicación: La autenticación multifactor combina al menos dos categorías diferentes de factores de autenticación para mayor seguridad. Ejemplo: contraseña (sabes) + SMS (tienes).

16. El Esquema Nacional de Seguridad (ENS) en su nivel MEDIO obliga a:

A) Uso exclusivo de certificados cualificados para todo acceso

B) Verificación del estado de revocación de certificados y autenticación reforzada para accesos remotos

C) Autenticación biométrica en todos los casos

D) Cambio de contraseña cada 24 horas

✓ Respuesta correcta: B)

Explicación: ENS nivel MEDIO (RD 311/2022) requiere verificación de revocación de certificados (OCSP/CRL) y mecanismos de autenticación reforzada (típicamente 2FA) para accesos externos a sistemas críticos.

17. En el contexto del SAS, ¿qué sistema permite a los ciudadanos acceder a su historia clínica, citas y recetas electrónicas?

A) Diraya

B) ClicSalud+

C) BPS

D) PIDE

✓ Respuesta correcta: B)

Explicación: ClicSalud+ es el portal del paciente del SAS que permite acceso ciudadano mediante CLAVE o certificado digital. Diraya es el sistema profesional, BPS la base de datos poblacional.

18. Un sello electrónico cualificado se diferencia de una firma electrónica cualificada en que:

A) Tiene menor validez jurídica

B) Se utiliza por personas jurídicas/entidades, no por personas físicas

C) No requiere certificado cualificado

D) Solo puede usarse en comunicaciones internas

✓ Respuesta correcta: B)

Explicación: El sello electrónico (Arts. 35-40 eIDAS) es el equivalente a la firma pero para personas jurídicas y entidades. Garantiza origen e integridad de documentos corporativos y sistemas automatizados.

19. ¿Qué protocolo utiliza principalmente la plataforma CLAVE para la federación de identidades?

A) LDAP

B) SAML 2.0

C) SSH

D) FTP

✓ Respuesta correcta: B)

Explicación: CLAVE implementa federación mediante SAML 2.0 (Security Assertion Markup Language), estándar XML para intercambio de información de autenticación entre dominios de seguridad.

20. Según eIDAS, ¿cuándo debe un Estado miembro reconocer un medio de identificación electrónica de otro Estado miembro?

A) Solo si existe convenio bilateral previo

B) Nunca, cada Estado decide soberanamente

C) Cuando esté notificado y tenga nivel de garantía sustancial o alto

D) Únicamente para ciudadanos, no para empresas

✓ Respuesta correcta: C)

Explicación: Art. 6 eIDAS establece reconocimiento mutuo OBLIGATORIO para medios notificados con nivel sustancial o alto. El nivel bajo es reconocimiento voluntario.

21. La Trusted List (Lista de Confianza) española contiene:

A) Las contraseñas de todos los usuarios del sistema

B) La relación de Prestadores Cualificados de Servicios de Confianza autorizados

C) Los certificados revocados

D) Las direcciones IP permitidas

✓ Respuesta correcta: B)

Explicación: La Trusted List es el registro oficial de prestadores cualificados (QTSP) y sus servicios, publicado en formato XML firmado. Consultable en sede electrónica del Ministerio.

22. Para firmar una receta electrónica en el sistema Receta XXI del SAS, el médico debe utilizar:

A) Cualquier dirección de correo electrónico

B) Firma manuscrita escaneada

C) Certificado digital (avanzado o cualificado) que le identifique como profesional sanitario

D) No requiere firma, solo usuario y contraseña

✓ Respuesta correcta: C)

Explicación: La prescripción electrónica requiere firma electrónica avanzada o cualificada del médico prescriptor, garantizando autoría y no repudio. Se implementa mediante certificado corporativo o colegial.

23. ¿Qué es un DID (Decentralized Identifier) en el contexto de EUDI Wallet?

A) Un tipo de certificado digital tradicional

B) Un identificador único controlado por el usuario sin autoridad central

C) Una base de datos distribuida

D) Un dispositivo hardware de autenticación

✓ Respuesta correcta: B)

Explicación: Los DIDs son identificadores descentralizados bajo control del usuario, base de la identidad auto-soberana (SSI) que implementa el EUDI Wallet de eIDAS2.

24. La plataforma @firma del Gobierno de España proporciona:

A) Únicamente certificados digitales gratuitos

B) Componentes y servicios para integrar firma electrónica en aplicaciones

C) Navegadores web especializados

D) Antivirus para administraciones públicas

✓ Respuesta correcta: B)

Explicación: @firma es una suite de componentes (cliente firma, validador, TS@...) que facilita la integración de servicios de firma y validación conformes a normativa en aplicaciones corporativas.

25. En criptografía asimétrica, si un mensaje se cifra con la clave pública de un destinatario:

A) Solo puede descifrarse con la clave pública del emisor

B) Solo puede descifrarse con la clave privada del destinatario

C) Puede descifrarse con cualquier clave pública

D) Debe cifrarse dos veces para mayor seguridad

✓ Respuesta correcta: B)

Explicación: Principio fundamental de criptografía asimétrica: lo cifrado con clave pública solo puede descifrarse con la clave privada del par. Garantiza confidencialidad.

26. ¿Cuál es el período mínimo de conservación de pistas de auditoría de accesos a historias clínicas en el SAS?

A) 1 año

B) 3 años

C) 6 años

D) No es necesario conservarlas

✓ Respuesta correcta: C)

Explicación: La Política de Seguridad del SAS establece conservación mínima de 6 años para pistas de auditoría de accesos a datos de salud, coherente con normativa de conservación de documentación clínica.

27. El certificado del DNI electrónico español:

A) Es un certificado simple sin validez jurídica

B) Es un certificado cualificado emitido por la Dirección General de la Policía

C) Solo sirve para identificación, no para firma

D) Tiene validez únicamente en territorio español

✓ Respuesta correcta: B)

Explicación: El DNIe contiene dos certificados cualificados (autenticación y firma) emitidos por la DGP como prestador cualificado. Tiene reconocimiento en toda la UE por eIDAS.

28. Una "credencial verificable" en el contexto de eIDAS2 es:

A) Una contraseña muy segura

B) Un documento digital firmado que atestigua atributos de una persona y puede verificarse criptográficamente

C) Un tipo de certificado SSL

D) Una tarjeta de identificación física

✓ Respuesta correcta: B)

Explicación: Las Verifiable Credentials (VC) son atestaciones digitales firmadas por emisores de confianza (ej: título universitario, certificado de vacunación) almacenables en EUDI Wallet y verificables sin contactar al emisor.

29. ¿Qué requisito añade eIDAS2 para los certificados de autenticación de sitios web?

A) Elimina los certificados SSL/TLS

B) Establece requisitos más estrictos y mayor control sobre emisión

C) Prohíbe el uso de HTTPS

D) Solo permite certificados gratuitos

✓ Respuesta correcta: B)

Explicación: eIDAS2 refuerza regulación de certificados web (Art. 45), estableciendo requisitos más estrictos para emisores y mayor control sobre dominios .eu y servicios públicos europeos.

30. En el SAS, para acceder remotamente (desde fuera de la red corporativa) al sistema Diraya, el nivel de autenticación requerido es:

A) Usuario y contraseña simple

B) Certificado digital o doble factor de autenticación

C) Solo pregunta de seguridad

D) No está permitido el acceso remoto bajo ninguna circunstancia

✓ Respuesta correcta: B)

Explicación: Acceso remoto a sistemas críticos como Diraya requiere nivel sustancial/alto: VPN con certificado digital más segundo factor (token/SMS) según Política de Seguridad SAS y ENS nivel MEDIO.

12. Mapa Conceptual del Tema

🗺️ Estructura Visual del Tema 83

    
    IDENTIFICACIÓN Y FIRMA ELECTRÓNICA
    │
    ├── 🔐 IDENTIFICACIÓN ELECTRÓNICA
    │   ├── Conceptos: Identificación vs Autenticación
    │   ├── Factores de autenticación
    │   │   ├── Algo que sabes (contraseña)
    │   │   ├── Algo que tienes (certificado, token)
    │   │   └── Algo que eres (biometría)
    │   ├── Niveles de garantía (LoA)
    │   │   ├── Bajo
    │   │   ├── Sustancial
    │   │   └── Alto
    │   └── Tecnologías específicas
    │       ├── SSO (Single Sign-On)
    │       ├── MFA (Multi-Factor Authentication)
    │       └── Autenticación contextual
    │
    ├── ✍️ FIRMA ELECTRÓNICA
    │   ├── Tipos según eIDAS
    │   │   ├── Simple (validez limitada)
    │   │   ├── Avanzada (≈ manuscrita)
    │   │   └── Cualificada (≡ manuscrita en toda UE)
    │   ├── Servicios asociados
    │   │   ├── Sello electrónico (personas jurídicas)
    │   │   └── Sello de tiempo (timestamp)
    │   └── Formatos técnicos
    │       ├── XAdES (XML)
    │       ├── PAdES (PDF)
    │       ├── CAdES (binario)
    │       └── JAdES (JSON)
    │
    ├── 🔑 CERTIFICADOS DIGITALES (PKI)
    │   ├── Fundamentos criptográficos
    │   │   ├── Criptografía asimétrica
    │   │   ├── Par de claves (pública/privada)
    │   │   └── Algoritmos (RSA, ECDSA)
    │   ├── Estructura X.509
    │   │   ├── Datos del titular (Subject)
    │   │   ├── Clave pública
    │   │   ├── Emisor (CA)
    │   │   ├── Período validez
    │   │   └── Firma digital de la CA
    │   ├── Tipos de certificados
    │   │   ├── Persona física
    │   │   ├── Persona jurídica
    │   │   ├── Empleado público
    │   │   ├── Profesional sanitario
    │   │   └── Servidor (SSL/TLS)
    │   ├── Cadena de confianza
    │   │   ├── CA Raíz (Root)
    │   │   ├── CA Intermedia
    │   │   └── Certificado final
    │   └── Revocación
    │       ├── CRL (lista periódica)
    │       └── OCSP (consulta online)
    │
    ├── 📜 MARCO NORMATIVO
    │   ├── Europa
    │   │   ├── Reglamento eIDAS (910/2014)
    │   │   └── eIDAS2 (Propuesta 2024/1183)
    │   ├── España
    │   │   ├── Ley 39/2015 (Procedimiento)
    │   │   ├── Ley 40/2015 (Régimen Jurídico)
    │   │   └── RD 4/2010 (ENI)
    │   └── Andalucía
    │       ├── Decreto 622/2019
    │       ├── Decreto 534/2021 (SAS)
    │       └── Política de Firma SAS
    │
    ├── 🏢 PRESTADORES DE SERVICIOS (PSC/TSP)
    │   ├── Prestadores cualificados (QTSP)
    │   │   ├── FNMT-RCM
    │   │   ├── DGP (DNIe)
    │   │   ├── ACCV (Valencia)
    │   │   ├── CATCert (Cataluña)
    │   │   ├── IZENPE (País Vasco)
    │   │   └── ANF-AC (Notarial)
    │   ├── Supervisión y auditoría
    │   └── Trusted List (Lista de Confianza)
    │
    ├── 🔓 PLATAFORMA CLAVE
    │   ├── Sistemas admitidos
    │   │   ├── Cl@ve Permanente
    │   │   ├── Cl@ve PIN
    │   │   ├── Cl@ve Firma (app móvil)
    │   │   ├── Certificado digital
    │   │   └── Sistemas autonómicos
    │   ├── Arquitectura SAML 2.0
    │   └── Integración en SAS
    │       └── ClicSalud+, Servicios ciudadanos
    │
    ├── 🏥 TECNOLOGÍAS EN ENTORNOS SANITARIOS
    │   ├── Tarjeta Sanitaria Individual (TSI)
    │   ├── Tarjeta profesional (TIP-SAS)
    │   ├── Biometría
    │   │   ├── Huella dactilar
    │   │   ├── Reconocimiento facial
    │   │   ├── Iris
    │   │   └── Voz
    │   ├── SSO corporativo SAS
    │   │   ├── Active Directory
    │   │   ├── LDAP
    │   │   └── SAML
    │   └── Firma de documentos clínicos
    │       ├── Receta electrónica
    │       ├── Informes clínicos
    │       ├── Consentimientos
    │       └── Plataforma @firma
    │
    └── 🇪🇺 IDENTIDAD DIGITAL EUROPEA (eIDAS2)
        ├── EUDI Wallet (Cartera digital)
        ├── Credenciales verificables (VC)
        ├── Identificadores descentralizados (DID)
        ├── Casos de uso sanitarios
        │   ├── Cartera sanitaria digital
        │   ├── Receta transfronteriza
        │   ├── Certificado vacunación
        │   └── Consentimientos digitales
        └── Calendario 2024-2028

    🔒 SEGURIDAD Y CUMPLIMIENTO
    ├── ENS (Esquema Nacional de Seguridad)
    ├── RGPD-LOPDGDD (Protección de datos)
    ├── ISO 27001 / ISO 27799 (Seguridad información sanitaria)
    └── Auditoría y trazabilidad

13. Referencias Normativas y Bibliográficas

📖 Normativa Europea

Reglamento (UE) 910/2014 del Parlamento Europeo y del Consejo, de 23 de julio de 2014, relativo a la identificación electrónica y los servicios de confianza para las transacciones electrónicas en el mercado interior (eIDAS)
Reglamento (UE) 2024/1183 del Parlamento Europeo y del Consejo, por el que se modifica el Reglamento (UE) 910/2014 en lo que respecta al establecimiento de un marco europeo de identidad digital (eIDAS2) - En proceso de implementación
Decisión de Ejecución (UE) 2015/1506 de la Comisión, por la que se establecen las especificaciones relativas a los formatos de las firmas electrónicas avanzadas

📖 Normativa Estatal Española

Ley 39/2015, de 1 de octubre, del Procedimiento Administrativo Común de las Administraciones Públicas (Arts. 9-11, 32)
Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público (Arts. 155-158)
Real Decreto 4/2010, de 8 de enero, por el que se regula el Esquema Nacional de Interoperabilidad (ENI)
Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad (ENS)
Ley 41/2002, de 14 de noviembre, básica reguladora de la autonomía del paciente y de derechos y obligaciones en materia de información y documentación clínica
Reglamento (UE) 2016/679 (RGPD) y Ley Orgánica 3/2018 (LOPDGDD) - Protección de datos personales

📖 Normativa Autonómica Andaluza

Decreto 622/2019, de 27 de diciembre, de Administración Electrónica de la Junta de Andalucía
Decreto 534/2021, de 20 de julio, de Administración Electrónica del Servicio Andaluz de Salud
Política de Seguridad de la Información del SSPA - Consejería de Salud y Consumo
Política de Firma Electrónica del SAS - Documento interno corporativo

📖 Estándares Técnicos Internacionales

ISO/IEC 27001:2022 - Sistemas de gestión de seguridad de la información
ISO 27799:2016 - Gestión de la seguridad de la información en salud
RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and CRL Profile
RFC 6960 - Online Certificate Status Protocol (OCSP)
ETSI EN 319 401 - General Policy Requirements for Trust Service Providers
ETSI EN 319 411-1/2 - Policy and security requirements for Trust Service Providers issuing certificates
ETSI TS 119 612 - Trusted Lists

📖 Guías y Documentación Técnica

CCN-STIC 807 - Criptología de empleo en el ENS (Centro Criptológico Nacional)
CCN-STIC 140 - Política de firma electrónica y certificados
Guía de Comunicaciones en el ENS - CCN
Documentación plataforma @firma - Secretaría General de Administración Digital
Manual de usuario CLAVE - Ministerio de Asuntos Económicos y Transformación Digital
Architecture Reference Framework (ARF) EUDI Wallet - Comisión Europea (en desarrollo)

📚 Bibliografía Especializada

Sánchez Gómez, A. (2023). La identidad digital europea: análisis de la reforma eIDAS. Thomson Reuters Aranzadi.
Piñar Mañas, J.L. (2022). Reglamento General de Protección de Datos: hacia un nuevo modelo europeo de privacidad. Reus.
Gamero Casado, E. (2021). Tratado de Procedimiento Administrativo Común y Régimen Jurídico Básico del Sector Público. Tirant lo Blanch.
Recio Gayo, M. (2020). Sistemas de información en salud y protección de datos personales. Dykinson.
Ferguson, N., Schneier, B. (2019). Practical Cryptography. Wiley.

🌐 Recursos Online

Portal PAe - Punto de Acceso General electrónico: https://administracion.gob.es
Sede electrónica MINECO - Prestadores de servicios: https://sede.mineco.gob.es/Prestadores
EU Trusted Lists: https://eidas.ec.europa.eu/efda/tl-browser
CCN-CERT - Centro Criptológico Nacional: https://www.ccn-cert.cni.es
INCIBE - Instituto Nacional de Ciberseguridad: https://www.incibe.es
Portal ClicSalud+: https://www.juntadeandalucia.es/servicioandaluzdesalud/clicsalud

14. Palabras Clave (Keywords SEO)

🏷️ Etiquetas de Búsqueda

Identificación electrónica Firma electrónica eIDAS eIDAS2 Certificados digitales PKI CLAVE EUDI Wallet Identidad digital europea Autenticación sanitaria SAS Andalucía Diraya ClicSalud+ Firma documentos clínicos Receta electrónica TSP prestadores confianza FNMT certificados DNI electrónico Biometría sanitaria SSO Single Sign-On MFA autenticación doble factor ENS seguridad RGPD protección datos TFA-STI oposición Técnico administrativo SAS

15. Consejos Finales de Estudio

💡 Estrategia de Preparación

Semana 1-2: Asimilación de conceptos base

Lee el tema completo al menos dos veces
Subraya y anota en los márgenes
Crea tu propio mapa mental (puedes partir del proporcionado)
Consulta la normativa original (al menos los artículos citados)

Semana 3: Profundización técnica

Investiga casos reales del SAS (busca noticias, proyectos piloto)
Prueba CLAVE y ClicSalud+ con tu usuario
Descarga e instala un certificado digital (FNMT o autonómico)
Firma documentos de prueba con @firma

Semana 4: Consolidación y práctica

Resuelve las 30 preguntas del cuestionario SIN consultar
Analiza tus errores y repasa esos puntos
Busca exámenes anteriores de TFA-STI y resuelve preguntas relacionadas
Simula explicar el tema a otra persona (técnica Feynman)

Semana 5+: Mantenimiento y actualización

Repaso semanal del esquema principal
Sigue noticias sobre eIDAS2 y EUDI Wallet (está en plena implementación)
Relaciona con otros temas (ENS, RGPD, interoperabilidad)
Practica redacciones cortas sobre casos prácticos

⚠️ Errores Frecuentes a Evitar

Confundir firma avanzada y cualificada: La avanzada NO requiere dispositivo cualificado
Pensar que CLAVE es un certificado: CLAVE es una plataforma de federación que admite varios métodos
Olvidar que eIDAS2 aún está en implementación: No confundas estado actual con futuro (2027-2028)
Ignorar las particularidades sanitarias: Los datos de salud son categoría especial RGPD
No distinguir entre PSC y QTSP: Solo los cualificados (QTSP) están en Trusted List
Mezclar identificación y autenticación: Son conceptos relacionados pero distintos

🎓 Conclusión Final

Y así llegamos al final de este viaje por la identificación y firma electrónica. Si has llegado hasta aquí... enhorabuena. Has dado un paso importante en tu preparación.

Recuerda: este tema no es solo "para aprobar". Es la base de tu futuro trabajo en el SAS. Cada vez que un médico firme una receta, cada vez que un paciente acceda a ClicSalud+, cada vez que se produzca un incidente de seguridad relacionado con credenciales... tú estarás ahí. Con el conocimiento para entender qué pasa, por qué pasa, y cómo solucionarlo.

La transformación digital del sistema sanitario público depende de profesionales como tú, que entienden no solo la tecnología, sino también la normativa, la seguridad, y sobre todo... el impacto real en la vida de las personas.

Así que adelante. Estudia, practica, pregunta, investiga. Y cuando llegue el día del examen, respira hondo y confía en todo el trabajo que has hecho.

¡Mucho ánimo en tu preparación! 💪

🌟 Recuerda 🌟

"La mejor preparación para mañana es hacer hoy tu mejor esfuerzo"

Tema 83 - TFA-STI SAS - Preparado con dedicación para tu éxito

Documento generado para preparación de oposiciones TFA-STI del Servicio Andaluz de Salud
Actualizado a normativa vigente - Noviembre 2025
Para uso exclusivo de estudio y preparación