1. Introducción

La seguridad de las tecnologías de la información en el ámbito sanitario representa uno de los pilares fundamentales sobre los que se sustenta la Transformación Digital del Sistema Sanitario Público de Andalucía (SSPA). No estamos hablando de teoría abstracta: cuando Diraya cae en el Hospital Virgen del Rocío, más de 50.000 profesionales sanitarios se quedan sin acceso a las historias clínicas de sus pacientes. Es literal: sin seguridad, no hay asistencia sanitaria moderna.

Este tema aborda los objetivos estratégicos de la seguridad (la famosa triada CIA: Confidencialidad, Integridad y Disponibilidad), las políticas y medidas que debemos implementar (físicas, técnicas, organizativas y legales), y los planes de contingencia que garantizan que, pase lo que pase, los servicios críticos sigan funcionando.

1.1. Relevancia en el contexto del SAS

El Servicio Andaluz de Salud gestiona algunos de los sistemas de información más críticos de la administración autonómica. Hablamos de:

• Diraya (Historia de Salud Digital): Sistema centralizado con datos clínicos de toda la población andaluza. Categoría ENS: ALTA en confidencialidad, integridad y disponibilidad.
• Receta XXI: Sistema de prescripción electrónica que permite dispensar medicación en cualquier farmacia de Andalucía. Su caída paraliza la dispensación farmacéutica.
• Nódulo (PACS): Almacenamiento y visualización de imágenes médicas. En urgencias, su disponibilidad es crítica para el diagnóstico.
• JARA: Gestión de citas. Millones de andaluces dependen de este sistema para acceder a la sanidad pública.

Estos sistemas no pueden fallar. Y cuando digo «no pueden», lo digo literalmente: un RTO (Recovery Time Objective) de Diraya en un hospital de referencia es de menos de 1 hora. Más allá de ese tiempo, la atención sanitaria se ve comprometida gravemente.

1.2. Marco normativo aplicable

La seguridad de la información en el SAS no es opcional. Viene impuesta por un marco normativo complejo pero bien definido:

1.3. Estructura del tema

A lo largo de este tema, vamos a ir construyendo tu conocimiento paso a paso, como si estuviéramos diseñando la estrategia de seguridad de un hospital desde cero:

1. Objetivos de seguridad: ¿Qué queremos proteger y por qué? (La triada CIA y más allá)
2. Estrategias y políticas: ¿Cómo organizamos la seguridad? (Del papel de la dirección al técnico de sistemas)
3. Medidas de seguridad: ¿Qué implementamos? (Físicas, técnicas, organizativas, legales)
4. Planes de contingencia: ¿Qué hacemos cuando todo falla? (BCP, DRP, backup)
5. Evaluación y certificación: ¿Cómo sabemos que estamos seguros? (Auditorías, ENS, ISO 27001)
6. Políticas específicas del SAS: ¿Cómo lo aplicamos en sanidad andaluza?
7. Estrategias de ciberseguridad: Desde Europa hasta Andalucía

2. Objetivos de la Seguridad de las Tecnologías de la Información

Vale, aquí viene lo primero que tienes que tatuarte en la cabeza: los objetivos de seguridad no son una lista arbitraria que alguien se inventó. Son las propiedades que DEBEN cumplir nuestros sistemas para que podamos confiar en ellos. Y cuando digo «confiar», hablo en serio: confiar para que un médico pueda diagnosticar, para que un paciente reciba el tratamiento correcto, para que no haya fugas de datos sensibles…

2.1. La Triada CIA: Los tres pilares fundamentales

2.1.1. Confidencialidad

La confidencialidad garantiza que la información solo sea accesible para personas autorizadas. Suena simple, ¿verdad? Pues es la madre de todos los problemas en sanidad.

Aplicación en el SAS:

• Control de acceso basado en roles (RBAC): En Diraya, un médico de digestivo NO puede ver las notas de psiquiatría a menos que esté justificado clínicamente.
• Auditoría de accesos: Cada vez que alguien abre una historia clínica, queda registrado: quién, cuándo, desde dónde. Esto es obligatorio por la Ley 41/2002.
• Cifrado de datos: Los datos en reposo en las bases de datos de Diraya están cifrados (TDE – Transparent Data Encryption). Las comunicaciones usan TLS 1.3.
• Segregación de redes: La red clínica está separada de la administrativa mediante VLANs y firewalls.

2.1.2. Integridad

La integridad asegura que la información no ha sido alterada de forma no autorizada. En sanidad, esto es CRÍTICO. Una prescripción médica modificada puede matar a un paciente.

Aplicación en el SAS:

• Firma electrónica: Las prescripciones en Receta XXI están firmadas digitalmente por el médico. No se pueden alterar sin invalidar la firma.
• Hashes criptográficos: Los documentos clínicos importantes (informes de alta, consentimientos informados) tienen hashes que permiten detectar modificaciones.
• Control de versiones: Diraya mantiene un histórico de modificaciones. Si cambias un dato, queda registrado qué era antes, qué es ahora, quién lo cambió y cuándo.
• Backups inmutables: Los backups de sistemas críticos se almacenan en modo WORM (Write Once, Read Many) para prevenir ransomware.

2.1.3. Disponibilidad

La disponibilidad garantiza que los sistemas estén operativos cuando se necesitan. En un hospital, esto no es negociable. Si Diraya cae en urgencias, las consecuencias pueden ser fatales.

En el SAS, hablamos de sistemas con disponibilidad 24/7/365. No hay «horario de oficina» en un hospital. Un infarto no espera a que se reinicie el servidor.

Aplicación en el SAS:

• Arquitectura redundante: Diraya funciona en clústeres activo-activo. Si un servidor cae, otro toma el relevo automáticamente.
• Hot Site: El SAS tiene un CPD principal en Sevilla y un Hot Site en Málaga. Replicación de datos continua (RPO = 15 minutos).
• Balanceo de carga: Múltiples servidores de aplicación distribuyen el trabajo para evitar saturación.
• SAI y generadores: En los CPDs hospitalarios hay sistemas de alimentación ininterrumpida (SAI) con autonomía de 15-30 minutos, y generadores diesel con autonomía de 72 horas.
• Monitorización 24/7: El SOC (Security Operations Center) del SAS vigila continuamente el estado de los sistemas críticos.

2.2. Objetivos adicionales: Más allá de la triada CIA

La triada CIA es fundamental, pero en el mundo real (y especialmente en sanidad) necesitamos más garantías:

2.2.1. Autenticidad

Verificar que quien dice ser el médico Juan Pérez es REALMENTE el médico Juan Pérez. No vale con un usuario y contraseña simple.

En el SAS:

• Certificados digitales: Los profesionales sanitarios del SAS tienen certificados digitales para firmar documentos clínicos.
• Autenticación multifactor (MFA): Para accesos remotos a Diraya desde fuera del hospital: certificado + usuario/contraseña + token SMS o app móvil.
• Tarjetas sanitarias con chip: Para identificación de profesionales en puestos clínicos.

2.2.2. Trazabilidad / No repudio

Poder demostrar quién hizo qué, cuándo y desde dónde. En términos legales, que nadie pueda negar haber realizado una acción.

En el SAS:

• Logs de auditoría: Obligatorios por la Ley 41/2002. Se conservan al menos 5 años.
• Firma electrónica: Garantiza el no repudio. Si firmas una prescripción, no puedes negar después que la hiciste tú.
• SIEM (Security Information and Event Management): Centraliza y correlaciona logs de todos los sistemas para detectar anomalías.

2.2.3. Privacidad

Protección de datos personales según el RGPD. Los datos de salud son categoría especial (artículo 9 RGPD), lo que implica medidas reforzadas.

En el SAS:

• Delegado de Protección de Datos (DPO): Obligatorio en el SAS. Supervisa el cumplimiento del RGPD.
• Evaluaciones de Impacto (EIPD): Obligatorias antes de implementar nuevos sistemas que traten datos de salud.
• Principio de minimización: Solo se recogen los datos estrictamente necesarios.
• Derechos ARCO: Los pacientes pueden ejercer sus derechos de Acceso, Rectificación, Cancelación y Oposición sobre sus datos.

2.3. Resumen: Objetivos de seguridad integrados

3. Estrategias, Políticas, Organización y Planificación

Muy bien, ya sabemos QUÉ queremos proteger (los objetivos de seguridad). Ahora toca la pregunta del millón: ¿CÓMO lo organizamos? Porque una cosa es saber que necesitas confidencialidad, integridad y disponibilidad… y otra muy distinta es conseguir que una organización de 100.000 empleados (como el SAS) trabaje de forma coordinada para lograrlo.

3.1. Estrategia de Seguridad

La estrategia de seguridad es la visión a largo plazo. Es el documento donde la dirección del SAS dice: «Estos son nuestros objetivos de seguridad para los próximos 3-5 años, y así es como vamos a conseguirlos».

En el SAS: La estrategia de seguridad está alineada con el Plan de Transformación Digital del SSPA 2022-2027 y la Estrategia de Ciberseguridad de Andalucía 2022-2025.

3.2. Política de Seguridad

La política de seguridad es el documento formal que establece las normas y directrices de seguridad que TODOS en la organización deben cumplir. Es como el «código penal» de la seguridad informática del SAS.

Características de una buena política de seguridad:

• Aprobada por la máxima dirección: En el SAS, por la Dirección General. Sin apoyo directivo, una política no sirve de nada.
• Obligatorio cumplimiento: No es opcional. El incumplimiento tiene consecuencias (desde amonestaciones hasta despido disciplinario).
• Revisada periódicamente: Al menos cada 2 años, o antes si hay cambios normativos importantes (como cuando entró en vigor el RGPD).
• Comunicada a TODOS: No vale tener una política guardada en un cajón. Debe estar publicada, accesible, y los empleados deben firmar que la conocen.

3.3. Normas y Procedimientos

Las políticas son declaraciones de intenciones. Los procedimientos son las instrucciones paso a paso de cómo hacer las cosas. Ejemplos:

• Procedimiento de Alta de Usuario: Cómo crear una cuenta en Diraya cuando entra un nuevo médico.
• Procedimiento de Baja de Usuario: Qué hacer cuando alguien deja el SAS (CRÍTICO: revocar accesos inmediatamente).
• Procedimiento de Gestión de Incidentes: Qué hacer cuando detectas un ransomware.
• Procedimiento de Backup: Qué sistemas, qué frecuencia, dónde se almacenan, cómo se prueban.

3.4. Organización de la Seguridad: Roles y Responsabilidades

La seguridad no es responsabilidad de una sola persona. Es un esfuerzo colectivo con roles bien definidos. El ENS (Esquema Nacional de Seguridad) establece cuatro roles clave:

3.4.1. Responsable de la Información

Determina qué hay que proteger y en qué medida. No es un técnico, es el «dueño» del sistema desde el punto de vista funcional.

En el SAS: El Director-Gerente de un hospital es el Responsable de la Información de Diraya en su centro. Él decide qué datos clínicos se recogen, quién debe tener acceso, etc.

3.4.2. Responsable del Servicio

Garantiza la prestación del servicio. Se asegura de que los sistemas estén disponibles y funcionando correctamente.

En el SAS: El Director de la Unidad de Sistemas de Información de un hospital es el Responsable del Servicio de los sistemas TI del centro.

3.4.3. Responsable de Seguridad

Diseña e implementa las medidas de seguridad. Es el técnico especialista en ciberseguridad.

En el SAS: Hay un Responsable de Seguridad a nivel corporativo (en la Dirección General de Tecnologías de la Información) y Responsables de Seguridad en cada gran hospital.

3.4.4. Responsable del Sistema

Gestiona técnicamente los sistemas TI. Administra servidores, bases de datos, redes…

En el SAS: Los Ingenieros Informáticos y Técnicos de Sistemas que trabajan en los CPDs hospitalarios son Responsables del Sistema.

3.5. Comité de Seguridad

El Comité de Seguridad es el órgano colegiado que supervisa y coordina la seguridad. Funciones:

• Aprobar políticas de seguridad
• Revisar incidentes graves y proponer mejoras
• Decidir inversiones en seguridad
• Coordinar la respuesta ante crisis (p.ej., un ciberataque masivo)

Composición típica en el SAS:

• Director General de Tecnologías de la Información (preside)
• Responsable de Seguridad corporativo
• Delegado de Protección de Datos (DPO)
• Representantes de áreas críticas (Diraya, Receta XXI, infraestructuras)
• Asesor jurídico

3.6. Planificación de la Seguridad: El Ciclo PDCA

La seguridad no es algo que haces una vez y te olvidas. Es un proceso continuo de mejora. Para eso usamos el ciclo PDCA (Plan-Do-Check-Act), también conocido como ciclo de Deming:

Este ciclo se repite continuamente. La seguridad nunca está «terminada».

4. Medidas de Seguridad

Ahora viene la chicha del tema, lo que de verdad vas a implementar en tu día a día como Ingeniero Informático del SAS. Las medidas de seguridad se clasifican en cuatro grandes bloques, y sí… las cuatro son igual de importantes. No vale con poner firewalls y olvidarte del resto.

4.1. Medidas de Seguridad Físicas

Las medidas físicas protegen los activos tangibles: servidores, redes, CPDs… Son las que a veces se infravaloran porque no parecen «informáticas», pero créeme: un intruso físico en tu CPD puede hacer más daño en 5 minutos que un hacker remoto en 5 meses.

4.1.1. Control de Acceso Físico

Objetivo: Que solo personal autorizado pueda acceder físicamente a infraestructuras críticas.

Medidas implementadas en CPDs del SAS:

• Zonas de seguridad diferenciadas:
  • Zona pública: Áreas de recepción (acceso libre)
  • Zona restringida: Oficinas técnicas (tarjeta de empleado)
  • Zona de alta seguridad: CPD (tarjeta + biometría + registro)
• Control biométrico: Huella dactilar o reconocimiento facial para acceder al CPD
• Registro de visitas: Todo acceso al CPD queda registrado (quién, cuándo, acompañante autorizado)
• Videovigilancia 24/7: Cámaras en todos los accesos y zonas críticas, con grabación de al menos 30 días
• Esclusas de seguridad: Sistema de dos puertas donde la segunda no se abre hasta que la primera está cerrada
• Alarmas de intrusión: Detectores de movimiento que se activan fuera del horario laboral

4.1.2. Protección de Instalaciones

Control ambiental:

• Temperatura: 20-22°C constante. Los servidores generan MUCHO calor. Sin refrigeración, se apagan automáticamente en minutos.
• Humedad: 45-55%. Demasiada humedad = condensación y cortocircuitos. Muy poca = electricidad estática que puede dañar componentes.
• Sistemas redundantes: Dos equipos de aire acondicionado. Si uno falla, el otro asume la carga.
• Monitorización continua: Sensores que alertan al SOC si la temperatura supera los 24°C.

Protección eléctrica:

• SAI (Sistema de Alimentación Ininterrumpida): Baterías que proporcionan energía durante 15-30 minutos en caso de corte eléctrico. Tiempo suficiente para que arranquen los generadores.
• Generadores diésel: Con autonomía de al menos 72 horas. Se prueban mensualmente.
• Doble acometida eléctrica: Dos líneas de suministro independientes desde diferentes subestaciones. Si una falla, la otra continúa.
• PDUs (Power Distribution Units): Distribución inteligente de energía a los racks. Monitorización del consumo.

Protección contra incendios:

• Detección temprana: Sensores de humo VESDA (Very Early Smoke Detection Apparatus) que detectan partículas mínimas antes de que haya fuego visible.
• Extinción por gas inerte: NO se usa agua (destruiría los servidores). Se usa gas inerte (FM-200, Novec 1230) que desplaza el oxígeno sin dañar equipos.
• Compartimentación: El CPD está dividido en secciones con puertas cortafuegos. Si hay incendio en una zona, no se propaga.
• Pulsadores de emergencia: EPO (Emergency Power Off) que cortan la electricidad del CPD en caso de emergencia grave.

4.1.3. Protección de Equipos

• Racks cerrados con llave: Los servidores están en armarios metálicos cerrados. No cualquiera puede tocarlos.
• Anclajes físicos: Los servidores críticos están anclados al suelo. No se pueden «llevar» fácilmente.
• Etiquetado y inventariado: Cada equipo tiene su número de serie y está en el inventario. Si desaparece, se detecta.
• Destrucción certificada de soportes: Los discos duros en desuso NO se tiran a la basura. Se destruyen con trituradora certificada (certificado de destrucción obligatorio por RGPD).
• Clear Desk Policy: En los puestos de trabajo, al finalizar la jornada: escritorio limpio, documentos guardados bajo llave, pantalla bloqueada.

4.2. Medidas de Seguridad Técnicas

Aquí es donde brillas como ingeniero informático. Las medidas técnicas son las que implementas mediante tecnología: software, hardware, configuraciones…

4.2.1. Control de Acceso Lógico

Gestión de identidades (IAM – Identity and Access Management):

• Directorio centralizado: En el SAS se usa Active Directory (AD) para gestionar las cuentas de usuario. Un único punto de administración.
• Control de acceso basado en roles (RBAC): Los permisos se asignan por roles, no individualmente.
  • Rol «Médico Urgencias» → Acceso completo a Diraya en urgencias
  • Rol «Administrativo Citas» → Solo acceso a JARA
  • Rol «Enfermería Planta» → Acceso a constantes vitales en Diraya, pero no a prescripciones
• Principio de mínimo privilegio: Cada usuario tiene SOLO los permisos que necesita para su trabajo. Ni más ni menos.
• Segregación de funciones: Nadie puede realizar todas las fases de un proceso crítico solo. Por ejemplo, quien aprueba una compra no puede ser el mismo que ejecuta el pago.

Autenticación multifactor (MFA):

MFA en el SAS:

• Acceso remoto a Diraya: VPN + certificado digital + usuario/contraseña + código SMS
• Acceso a servidores críticos: Certificado digital + contraseña + token RSA
• Administradores de sistemas: Tarjeta inteligente + PIN + huella dactilar para operaciones críticas

Políticas de contraseñas:

• Longitud mínima: 12 caracteres
• Complejidad: mayúsculas, minúsculas, números, símbolos
• Caducidad: 90 días (aunque hay debate sobre si esto sigue siendo una buena práctica)
• Historial: No se pueden reutilizar las últimas 12 contraseñas
• Bloqueo tras intentos fallidos: 5 intentos → cuenta bloqueada 30 minutos
• Prohibición de contraseñas comunes: Lista negra de contraseñas típicas (123456, password, SAS2024…)

4.2.2. Criptografía

La criptografía es tu mejor amiga para garantizar confidencialidad e integridad. Dos tipos principales:

Cifrado en reposo (Data at Rest):

• TDE (Transparent Data Encryption): Las bases de datos de Diraya están cifradas. Si alguien roba los discos duros, no puede leer los datos sin las claves.
• Cifrado de disco completo (FDE): Los portátiles de los profesionales del SAS tienen BitLocker activado. Si pierdes el portátil, los datos están protegidos.
• Cifrado de backups: Las copias de seguridad se cifran antes de enviarse al centro de respaldo. AES-256.

Cifrado en tránsito (Data in Transit):

• TLS 1.3: Todas las comunicaciones entre cliente y servidor usan TLS 1.3 (TLS 1.0 y 1.1 están prohibidos por vulnerabilidades conocidas).
• VPN IPsec: Las conexiones entre CPDs hospitalarios y el CPD central usan VPN con cifrado IPsec.
• HTTPS obligatorio: Todos los portales web del SAS usan HTTPS. HTTP está deshabilitado.

Firma electrónica:

• Recetas electrónicas: Firmadas digitalmente por el médico prescriptor. Garantiza autenticidad e integridad.
• Informes clínicos: Los informes de alta, consentimientos informados, etc. se firman digitalmente.
• Certificados cualificados: Los profesionales sanitarios del SAS tienen certificados digitales emitidos por una Autoridad de Certificación acreditada.

4.2.3. Seguridad de Red

Segmentación de red (VLANs):

Firewalls:

• Firewall perimetral: Protege la conexión del hospital a Internet. Inspección profunda de paquetes (DPI).
• Firewalls internos: Entre segmentos de red. Políticas de «default deny» (todo prohibido por defecto, se permiten solo conexiones autorizadas).
• Next-Generation Firewalls (NGFW): No solo filtran por IP/puerto, también inspeccionan el contenido de las aplicaciones (por ejemplo, bloquean Facebook pero permiten aplicaciones médicas específicas).

IDS/IPS (Sistemas de Detección/Prevención de Intrusiones):

• IDS (Intrusion Detection System): Detecta comportamientos sospechosos y alerta. Modo pasivo (observa pero no bloquea).
• IPS (Intrusion Prevention System): Detecta Y bloquea automáticamente. Modo activo.
• Ubicación: En el perímetro y en puntos críticos internos (antes de la red clínica, por ejemplo).

WAF (Web Application Firewall):

• Protege las aplicaciones web (ClicSalud+, portales de citas…) de ataques como:
  • SQL Injection
  • Cross-Site Scripting (XSS)
  • Cross-Site Request Forgery (CSRF)
  • DDoS (Distributed Denial of Service)

4.2.4. Seguridad en Sistemas

Hardening (endurecimiento) de servidores:

• Principio de superficie de ataque mínima: Desinstalar todo lo que no se use. Si el servidor es una base de datos, no necesita navegador web instalado.
• CIS Benchmarks: Guías de configuración segura publicadas por el Center for Internet Security. El SAS sigue estos estándares.
• Deshabilitar servicios innecesarios: Por ejemplo, en un servidor web no necesitas el servicio de impresión.
• Configuración de auditoría: Logs de eventos de seguridad activados y configurados para enviarse al SIEM.

Gestión de parches (Patch Management):

Proceso de patch management en el SAS:

1. Detección: Herramientas automáticas (WSUS para Windows, Satellite para Linux) detectan sistemas desactualizados.
2. Evaluación: ¿El parche es crítico? ¿Afecta a sistemas en producción?
3. Pruebas: Antes de aplicar en producción, se prueba en entorno de test.
4. Despliegue: Se aplica en producción en ventanas de mantenimiento programadas.
5. Verificación: Se comprueba que el parche se aplicó correctamente y no causó efectos secundarios.
6. Documentación: Registro de qué se parchó, cuándo y por quién.

Plazos de parcheo según criticidad (ENS):

• Crítico: 7 días naturales
• Alto: 30 días naturales
• Medio: 90 días naturales
• Bajo: En la siguiente ventana de mantenimiento programada

Antimalware:

• Endpoints: Todos los PCs, portátiles y servidores tienen antivirus empresarial (no el gratuito de casa). Actualización de firmas diaria.
• Servidores: Antivirus específicos para servidores (menor impacto en rendimiento).
• Correo electrónico: Gateway de correo con antispam y antimalware. Bloquea adjuntos peligrosos (.exe, .bat, .scr…).
• EDR (Endpoint Detection and Response): Sistemas avanzados que no solo detectan malware conocido (firmas), sino comportamientos sospechosos (análisis heurístico y machine learning).

4.2.5. Monitorización y Detección

SIEM (Security Information and Event Management):

El SIEM es el cerebro del SOC. Recopila logs de TODOS los sistemas y los correlaciona para detectar incidentes de seguridad.

Ejemplo de correlación en el SIEM del SAS:

1. 10:15h – Usuario «juan.perez» intenta acceder a Diraya desde Madrid (IP 80.58.x.x)
2. 10:16h – Mismo usuario intenta acceder desde Sevilla (IP interna hospital)
3. 10:17h – 15 intentos fallidos de contraseña desde Madrid
4. 🚨 ALERTA SIEM: «Posible compromiso de cuenta – acceso simultáneo desde ubicaciones incompatibles»
5. Respuesta automática: Bloquear cuenta, alertar al SOC, notificar al usuario

SOC (Security Operations Center) 24/7:

• Analistas de seguridad: Personas (sí, humanos) que revisan las alertas del SIEM y deciden qué es falso positivo y qué es incidente real.
• Turnos 24/7: Los ataques no tienen horario. El SOC tampoco.
• Playbooks de respuesta: Procedimientos predefinidos para cada tipo de incidente (malware detectado → aislar equipo, analizar, erradicar).
• Escalado: Si un incidente es grave, se escala a equipos especializados (CSIRT del SAS, CSIRT Andalucía, CCN-CERT…).

4.3. Medidas de Seguridad Organizativas

Las medidas organizativas son las que dependen de las personas y los procesos. Puedes tener la tecnología más puntera, pero si tus empleados usan «123456» como contraseña o pinchan en phishing… estás perdido.

4.3.1. Gestión de Personal

Formación y concienciación:

Temas de la formación:

• Reconocimiento de phishing y otros ataques de ingeniería social
• Uso seguro de contraseñas (gestores de contraseñas, no reutilizar…)
• Protección de datos personales (RGPD básico)
• Política de escritorio limpio
• Qué hacer si detectas un incidente de seguridad
• Uso seguro de dispositivos personales (BYOD)

Acuerdos de confidencialidad:

• Todo empleado del SAS firma un acuerdo de confidencialidad al incorporarse.
• Los empleados con acceso a datos especialmente sensibles (administradores de BBDD, personal de RRHH…) firman acuerdos reforzados.
• El incumplimiento puede llevar a despido disciplinario.

Proceso de alta/baja de empleados:

• Alta: Solicitud formal, aprobación del responsable, creación de cuenta con permisos mínimos necesarios, formación inicial.
• Baja: CRÍTICO – Revocación inmediata de accesos (mismo día de la baja). Recuperación de tarjetas, tokens, portátiles… Cambio de contraseñas de cuentas compartidas si las conocía.

4.3.2. Gestión de Terceros

El SAS no funciona solo. Tiene proveedores de TI, empresas de mantenimiento, consultoras… Todos ellos son riesgos potenciales.

• Cláusulas de seguridad en contratos: Obligaciones específicas de protección de datos, auditorías, notificación de incidentes…
• Acuerdos de encargado de tratamiento (RGPD art. 28): Si el proveedor va a tratar datos personales por cuenta del SAS, hay que firmar un contrato específico que cumpla el RGPD.
• Auditorías a proveedores: El SAS se reserva el derecho de auditar la seguridad de sus proveedores críticos.
• Acceso limitado: Los técnicos de mantenimiento solo acceden con supervisión. No se les dan cuentas de administrador permanentes.

4.3.3. Gestión de Incidentes

Un incidente de seguridad es cualquier evento que comprometa (o pueda comprometer) la confidencialidad, integridad o disponibilidad de la información.

Clasificación de incidentes:

Fases de gestión de incidentes:

1. Detección: SIEM, SOC, usuarios reportan…
2. Contención: Aislar el problema para que no se extienda (desconectar servidor de la red, bloquear IPs atacantes…)
3. Erradicación: Eliminar la causa raíz (eliminar malware, cerrar vulnerabilidad, revocar credenciales comprometidas…)
4. Recuperación: Volver a la normalidad (restaurar desde backup, reconectar sistemas…)
5. Lecciones aprendidas: Análisis post-mortem. ¿Cómo pasó? ¿Cómo lo prevenimos en el futuro?

4.3.4. Gestión de Cambios

Cambiar cosas en producción es peligroso. Un cambio mal hecho puede tumbar servicios críticos.

Proceso de control de cambios:

• Solicitud formal: Todo cambio debe estar documentado y justificado.
• Evaluación de riesgos: ¿Qué puede salir mal? ¿Qué sistemas afecta?
• Aprobación: Por el CAB (Change Advisory Board) – comité que revisa cambios importantes.
• Planificación: Fecha, hora (ventana de mantenimiento), procedimiento paso a paso, plan de rollback.
• Pruebas: En entorno de test antes de producción.
• Implementación: Siguiendo el procedimiento aprobado.
• Verificación: ¿Funcionó como se esperaba?
• Documentación: Actualizar documentación técnica.

4.4. Medidas de Seguridad Legales

Las medidas legales son las obligaciones que vienen impuestas por leyes y regulaciones. No son opcionales: son obligatorias.

4.4.1. Marco Normativo

4.4.2. Obligaciones del RGPD en el SAS

Principios del tratamiento de datos:

• Licitud, lealtad y transparencia: El paciente debe saber qué datos se recogen y para qué.
• Limitación de la finalidad: Solo usar los datos para el fin por el que se recogieron (asistencia sanitaria, gestión administrativa…).
• Minimización de datos: Solo recoger lo estrictamente necesario.
• Exactitud: Mantener los datos actualizados.
• Limitación del plazo de conservación: No guardar datos eternamente. Historia clínica: mínimo 5 años, pero máximos definidos.
• Integridad y confidencialidad: Medidas técnicas y organizativas apropiadas.

Base de legitimación para datos de salud (art. 9 RGPD):

Los datos de salud son categoría especial. Prohibición general de tratarlos… SALVO excepciones. La más relevante para el SAS:

• Artículo 9.2.h: «el tratamiento es necesario para fines de medicina preventiva o laboral, evaluación de la capacidad laboral del trabajador, diagnóstico médico, prestación de asistencia o tratamiento de tipo sanitario o social, o gestión de los sistemas y servicios de asistencia sanitaria»

Esto significa que cuando un médico del SAS accede a Diraya para atender a un paciente, NO necesita pedir consentimiento expreso. La base de legitimación es la prestación de asistencia sanitaria.

Pero ojo: Si el médico accede a la historia clínica de un paciente que NO está atendiendo (curiosidad, familiar…), ahí SÍ hay infracción grave del RGPD.

Delegado de Protección de Datos (DPO):

• Obligatorio en administraciones públicas (art. 37 RGPD)
• Funciones:
  • Informar y asesorar sobre obligaciones RGPD
  • Supervisar cumplimiento
  • Cooperar con la autoridad de control (AEPD)
  • Punto de contacto para los interesados
• Independencia: No recibe instrucciones sobre cómo hacer su trabajo. Reporta directamente a la máxima dirección.

Evaluación de Impacto (EIPD):

• Obligatoria cuando un tratamiento puede suponer un alto riesgo para derechos y libertades (art. 35 RGPD)
• Cuándo es obligatoria en el SAS:
  • Nuevo sistema que trate datos de salud a gran escala
  • Sistemas de videovigilancia extensiva
  • Tratamientos que impliquen decisiones automatizadas con efectos significativos
  • Tratamiento de datos genéticos o biométricos
• Contenido: Descripción del tratamiento, evaluación de necesidad y proporcionalidad, análisis de riesgos, medidas para mitigarlos.

Registro de Actividades de Tratamiento (RAT):

• Obligatorio para responsables y encargados del tratamiento (art. 30 RGPD)
• Contenido: Qué datos se tratan, con qué finalidad, quién tiene acceso, plazos de conservación, medidas de seguridad…
• En el SAS: Existe un RAT corporativo que documenta todos los tratamientos de datos personales (Diraya, RRHH, nóminas, formación…).

Notificación de brechas de seguridad:

4.4.3. Obligaciones del ENS

Categorización de sistemas:

Todo sistema de información de la administración pública debe estar categorizado según el ENS en función del impacto de un incidente en confidencialidad, integridad y disponibilidad:

Medidas de seguridad según categoría:

• BAJO: Medidas básicas (contraseñas robustas, antivirus, backup semanal…)
• MEDIO: Medidas básicas + medidas adicionales (MFA, SIEM, auditorías anuales…)
• ALTO: Medidas básicas + adicionales + medidas reforzadas (Hot Site, cifrado extremo-extremo, auditorías semestrales, pentesting anual…)

Auditorías ENS:

• Sistemas categoría ALTA: Auditoría cada 2 años (recomendado anual)
• Sistemas categoría MEDIA: Autoauditoría cada 2 años
• Sistemas categoría BAJA: Revisión interna periódica

Certificación ENS:

• Las auditorías pueden ser realizadas por el CCN-CERT o por auditores externos acreditados.
• Si se cumplen las medidas, se obtiene la Certificación ENS, que acredita públicamente el nivel de seguridad.
• La certificación se publica en el portal PAe (Administración Electrónica).

5. Evaluación y Certificación de la Seguridad

Vale, has implementado todas las medidas de seguridad. Genial. Pero… ¿cómo sabes que funcionan? ¿Cómo demuestras ante un auditor (o ante un juez, si las cosas se tuercen) que has hecho las cosas bien?

Respuesta: evaluando y certificando.

5.1. Auditorías de Seguridad

Una auditoría de seguridad es un examen sistemático de los sistemas, políticas y procedimientos para verificar que cumplen con los requisitos de seguridad.

5.1.1. Tipos de auditorías

Por alcance:

• Auditoría técnica: Análisis de configuraciones, vulnerabilidades, controles técnicos (firewalls, cifrado…).
• Auditoría organizativa: Revisión de políticas, procedimientos, formación, gestión de incidentes…
• Auditoría física: Inspección de CPDs, controles de acceso físico, protección ambiental…

Por enfoque:

• Auditoría de cumplimiento: ¿Cumplimos con ENS, RGPD, ISO 27001…?
• Test de penetración (pentesting): Simular un ataque real para identificar vulnerabilidades explotables.
• Análisis de vulnerabilidades: Escaneo automático de sistemas para detectar vulnerabilidades conocidas.
• Auditoría de código: Revisión del código fuente de aplicaciones para detectar fallos de seguridad (SQL injection, XSS…).

Por ejecutor:

• Auditoría interna: Realizada por el propio SAS (equipo de auditoría interna o CSIRT).
• Auditoría externa: Realizada por empresa especializada independiente. Mayor credibilidad.

5.1.2. Proceso de una auditoría de seguridad

1. Planificación: Definir alcance (qué sistemas se van a auditar), objetivos (cumplimiento ENS, detección de vulnerabilidades…), metodología.
2. Recopilación de información: Documentación (políticas, procedimientos, diagramas de red…), entrevistas con personal, acceso a sistemas para análisis técnico.
3. Análisis: Revisión de evidencias, tests técnicos, verificación de controles.
4. Identificación de hallazgos: Clasificación por gravedad (crítico, alto, medio, bajo).
5. Informe: Documento detallado con:
   • Resumen ejecutivo (para dirección)
   • Hallazgos detallados (para técnicos)
   • Recomendaciones de mejora
   • Plan de acción propuesto
6. Seguimiento: Verificar que se implementan las recomendaciones.

5.2. Metodologías de Análisis de Riesgos

El análisis de riesgos es el proceso de identificar amenazas, evaluar su probabilidad e impacto, y decidir qué controles implementar.

5.2.1. MAGERIT

MAGERIT (Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información) es la metodología OFICIAL para las administraciones públicas españolas. Desarrollada por el CCN (Centro Criptológico Nacional).

Componentes de MAGERIT:

• Activos: Qué tenemos (servidores, datos, aplicaciones, redes, personal…)
• Amenazas: Qué puede pasar (incendio, fallo hardware, ransomware, fuga de datos…)
• Vulnerabilidades: Debilidades que facilitan las amenazas (servidor sin parches, puerta CPD sin cerrar…)
• Salvaguardas: Controles que reducen el riesgo (firewall, backup, formación…)
• Impacto: Daño si se materializa la amenaza (económico, reputacional, legal…)
• Riesgo: Probabilidad × Impacto

Proceso MAGERIT:

1. Inventario de activos
2. Valoración de activos (qué valor tienen para la organización)
3. Identificación de amenazas
4. Evaluación de vulnerabilidades
5. Cálculo del riesgo intrínseco (sin controles)
6. Identificación de salvaguardas existentes
7. Cálculo del riesgo residual (con controles actuales)
8. Decisión: ¿El riesgo residual es aceptable? Si no → implementar más controles
9. Plan de tratamiento del riesgo

Herramientas MAGERIT:

• PILAR: Herramienta software gratuita del CCN para hacer análisis de riesgos con MAGERIT.
• Catálogos de elementos: Listados de activos, amenazas y salvaguardas típicos para facilitar el análisis.

5.2.2. ISO 27005

Estándar internacional de gestión de riesgos de seguridad de la información. Más genérico que MAGERIT (no específico de administraciones públicas).

Similar en concepto a MAGERIT, pero con enfoque internacional y mayor flexibilidad metodológica.

5.2.3. OCTAVE

OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) es una metodología desarrollada por el Carnegie Mellon University.

Enfoque más orientado a autoevaluación por parte de la propia organización (menos dependiente de consultores externos).

5.3. Certificaciones de Seguridad

Una certificación es un reconocimiento formal de que un sistema cumple con un estándar de seguridad.

5.3.1. Certificación ENS

Ya la hemos mencionado varias veces. Es la certificación OBLIGATORIA para administraciones públicas españolas.

Niveles de conformidad:

• ENS Básico: Sistemas categoría BAJA
• ENS Medio: Sistemas categoría MEDIA
• ENS Alto: Sistemas categoría ALTA (Diraya, Receta XXI…)

Proceso de certificación:

1. Autoevaluación inicial
2. Implementación de medidas
3. Auditoría por CCN-CERT o auditor acreditado
4. Corrección de no conformidades
5. Emisión del certificado (válido 2 años)
6. Renovación periódica

5.3.2. ISO 27001

ISO 27001 es el estándar internacional más reconocido de gestión de seguridad de la información.

Estructura:

• Cláusulas 4-10: Requisitos del Sistema de Gestión de Seguridad de la Información (SGSI)
• Anexo A: 114 controles de seguridad (organizativos, técnicos, físicos…)

Beneficios de certificarse en ISO 27001:

• Credibilidad internacional (ISO es reconocida mundialmente)
• Mejora continua (el estándar obliga a ciclos PDCA)
• Ventaja competitiva (en concursos públicos, tener ISO 27001 suma puntos)
• Reducción de riesgos (implementas controles probados internacionalmente)

Certificación: Por entidad certificadora acreditada (ENAC en España). Auditorías anuales de seguimiento + recertificación cada 3 años.

5.3.3. ISO 27017 e ISO 27018

ISO 27017: Guía de controles de seguridad para servicios cloud.

• Aplicable si el SAS contrata servicios cloud para alojar sistemas (cada vez más común)
• Controles específicos para cloud: gestión de máquinas virtuales, segregación entre clientes, trazabilidad de logs…

ISO 27018: Protección de datos personales en cloud.

• Complementa a ISO 27017 con enfoque RGPD
• Requisitos de transparencia, portabilidad de datos, notificación de accesos de autoridades…

5.3.4. ISO 27799

ISO 27799: Gestión de seguridad de información en salud.

Específica para el sector sanitario. Adapta ISO 27002 (código de buenas prácticas) al contexto de la salud.

Controles específicos sanitarios:

• Gestión de historias clínicas
• Protección de datos de salud
• Seguridad en dispositivos médicos conectados (IoMT)
• Intercambio seguro de información clínica

6. Planes de Contingencia y Recuperación ante Desastres

Vale, ahora viene la pregunta que nadie quiere hacerse pero que TODOS debemos responder: ¿Qué hacemos cuando todo se va a la mierda?

Y sí, he dicho «mierda» porque es exactamente lo que sientes cuando a las 3 de la madrugada te llaman para decirte que un ransomware ha cifrado los servidores de Diraya. O cuando un incendio destruye el CPD principal. O cuando una inundación… ya me entiendes.

6.1. Plan de Continuidad de Negocio (BCP)

El BCP es la estrategia global para garantizar que los servicios esenciales del SAS continúen funcionando ante cualquier tipo de disrupción.

6.1.1. Análisis de Impacto en el Negocio (BIA)

El BIA (Business Impact Analysis) es el primer paso. Consiste en responder estas preguntas:

• ¿Qué procesos son críticos? Urgencias, UCI, quirófanos, dispensación farmacéutica…
• ¿Cuánto tiempo podemos estar sin ellos? (MTD – Maximum Tolerable Downtime)
• ¿Cuánta pérdida de datos podemos aceptar? (RPO – Recovery Point Objective)
• ¿Qué sistemas TI los soportan? Diraya para urgencias, Nódulo para diagnóstico por imagen…
• ¿Qué recursos necesitamos? Personal, instalaciones, equipos, suministros…
• ¿Cuál es el impacto si fallan? Económico, reputacional, legal, vidas en riesgo…

6.1.2. Estrategias de Continuidad

Para el personal:

• Equipos de respaldo: Personal entrenado que puede asumir funciones críticas si el titular no está disponible
• Teletrabajo: Capacidad de trabajar remotamente si el edificio no es accesible
• Redistribución: Mover personal de áreas no críticas a áreas críticas temporalmente

Para las instalaciones:

• Sede alternativa: Ubicación alternativa donde operar si el edificio principal no está disponible
• Acuerdos de reciprocidad: Usar instalaciones de otro hospital temporalmente
• Instalaciones móviles: Unidades móviles de diagnóstico, quirófanos de campaña…

Para la tecnología:

• Hot Site: CPD alternativo operativo en todo momento (ahí entra el DRP)
• Cloud híbrido: Capacidad de migrar cargas de trabajo a cloud si el CPD on-premise falla
• Redundancia: Componentes duplicados (servidores, redes, almacenamiento…)

6.1.3. Equipo de Gestión de Crisis

Cuando hay una crisis, necesitas un equipo que tome decisiones rápidas y coordinadas.

Composición típica en el SAS:

• Director Gerente: Máxima autoridad, toma decisiones finales
• Director TI: Coordina la respuesta técnica
• Responsable de Seguridad: Evalúa el incidente, propone medidas
• Responsable de Comunicación: Gestiona comunicación interna y externa
• Asesor Jurídico: Implicaciones legales (notificaciones RGPD, denuncias…)
• Enlace con proveedores: Coordina con proveedores críticos (cloud, hardware, software…)

Sala de crisis:

• Ubicación física designada (y alternativa si la principal no está accesible)
• Comunicaciones redundantes (teléfono, videoconferencia, radio…)
• Acceso a documentación crítica (DRP, contactos, diagramas de red…)
• Pizarras, monitores para seguimiento de la situación en tiempo real

6.1.4. Comunicaciones en Crisis

Durante una crisis, la comunicación es CRÍTICA. El caos y los rumores pueden hacer tanto daño como el incidente en sí.

Plan de comunicación:

• Interna: ¿Cómo informamos al personal? Emails, intranet, SMS masivos, reuniones…
• Externa: ¿Cómo informamos a pacientes, prensa, autoridades?
• Portavoz único: Una sola persona autorizada para hablar públicamente (evita mensajes contradictorios)
• Mensajes preparados: Comunicados preescritos para diferentes escenarios (se personalizan según el caso concreto)

6.2. Plan de Recuperación ante Desastres (DRP)

Ahora sí, entramos en lo técnico puro y duro. El DRP se centra en recuperar los sistemas TI.

6.2.1. Conceptos clave: RPO y RTO

Estos dos acrónimos son FUNDAMENTALES. Te los preguntarán en el examen seguro.

RPO (Recovery Point Objective) – Objetivo de Punto de Recuperación:

• Definición: La máxima cantidad de datos que podemos permitirnos perder.
• Se mide en tiempo: «¿Hasta cuándo atrás podemos retroceder en el tiempo?»
• Ejemplo: RPO = 15 minutos → Podemos perder como máximo los últimos 15 minutos de datos.
• Determina: Frecuencia de backups y tipo de replicación.

RTO (Recovery Time Objective) – Objetivo de Tiempo de Recuperación:

• Definición: El tiempo máximo que podemos estar sin el sistema.
• Se mide en tiempo: «¿Cuánto tiempo tenemos para recuperar?»
• Ejemplo: RTO = 1 hora → El sistema debe estar operativo en menos de 1 hora.
• Determina: Tipo de arquitectura de recuperación (Hot Site, Warm Site, Cold Site).

6.2.2. Centros de Respaldo (DR Sites)

Cold Site (Sitio Frío):

• Qué es: Instalaciones con infraestructura básica (espacio, electricidad, conectividad), pero SIN equipos instalados.
• Tiempo de activación: Varios días (hay que llevar los equipos, instalarlos, configurarlos…)
• Coste: Bajo (solo pagas el alquiler del espacio)
• RPO/RTO: Alto (varios días)
• Uso en SAS: Sistemas no críticos

Warm Site (Sitio Templado):

• Qué es: Instalaciones con equipos ya instalados y configurados, pero con datos no actualizados al 100%.
• Tiempo de activación: Varias horas (hay que restaurar los últimos backups, sincronizar, validar…)
• Coste: Medio
• RPO/RTO: Medio (horas)
• Uso en SAS: Sistemas importantes pero no críticos (JARA, portales web…)

Hot Site (Sitio Caliente):

• Qué es: Réplica exacta del CPD principal, con datos replicados en tiempo real (o casi real), lista para asumir la carga inmediatamente.
• Tiempo de activación: Minutos (puede ser automático)
• Coste: Alto (es como tener dos CPDs completos)
• RPO/RTO: Muy bajo (minutos)
• Uso en SAS: Sistemas CRÍTICOS (Diraya, Receta XXI, Nódulo en urgencias)

6.2.3. Estrategias de Replicación

Replicación Síncrona:

• Cómo funciona: Cada escritura en el sistema principal se replica INMEDIATAMENTE en el secundario. La operación no se confirma hasta que ambos la tienen.
• RPO: Cero (o casi cero). No hay pérdida de datos.
• Limitación: Distancia. La latencia de red hace que sea inviable más allá de ~100 km.
• Coste: Alto rendimiento (las operaciones van más lentas porque esperan la confirmación del secundario)
• Uso en SAS: Replicación entre el CPD principal del hospital y el Hot Site local (mismo edificio o edificio cercano)

Replicación Asíncrona:

• Cómo funciona: Las escrituras en el principal se confirman inmediatamente. La replicación al secundario ocurre «cuando puede», con un pequeño retraso.
• RPO: Minutos. Puedes perder los últimos cambios no replicados.
• Limitación: Ninguna de distancia. Puede replicar a miles de km.
• Coste: Bajo impacto en rendimiento
• Uso en SAS: Replicación del Hot Site local a un DR Site remoto (Sevilla → Málaga, por ejemplo)

6.2.4. Fases del Plan de Recuperación

1. Activación:
   • Determinar si se debe activar el DRP (criterios claros en el documento)
   • Quién tiene autoridad para activarlo (Director TI, Responsable de Seguridad…)
   • Notificar al equipo de recuperación
   • Activar la sala de crisis
2. Respuesta inicial (primeras horas):
   • Evaluar el alcance del desastre
   • Proteger vidas (si hay riesgo físico)
   • Contener el incidente (si es un ciberataque, aislar sistemas comprometidos)
   • Evaluar la viabilidad de recuperación en el sitio principal vs activar DR Site
3. Recuperación (siguientes días):
   • Activar el DR Site si es necesario
   • Restaurar sistemas según orden de prioridad (Tier 1 → Tier 2 → Tier 3…)
   • Validar integridad de datos restaurados
   • Comunicar progreso a stakeholders
4. Vuelta a la normalidad:
   • Reparar/reconstruir el sitio principal
   • Sincronizar datos del DR Site al principal
   • Failback (volver a operar desde el sitio principal)
   • Restablecer la replicación normal
5. Revisión post-incidente:
   • Análisis post-mortem: ¿Qué pasó? ¿Por qué? ¿Cómo se detectó?
   • ¿El DRP funcionó como esperábamos? ¿Qué mejorar?
   • Actualizar el DRP con las lecciones aprendidas
   • Informe ejecutivo para la dirección

6.2.5. Pruebas del DRP

Un DRP que no se prueba es papel mojado. Cuando hay un desastre real NO es el momento de descubrir que el procedimiento no funciona.

Tipos de pruebas:

7. Respaldo y Continuidad

El backup es tu póliza de seguros. Nunca la necesitas… hasta que la necesitas DESESPERADAMENTE.

7.1. Políticas de Backup

7.1.1. La regla de oro: 3-2-1

Ejemplo aplicado al SAS:

• Copia 1: Datos en producción en el CPD principal (discos SAN)
• Copia 2: Backup en disco en el mismo CPD (NAS de backup, restauración rápida)
• Copia 3: Backup en cinta que se envía físicamente al DR Site remoto (Málaga)
• Bonus: Backup adicional en cloud (Azure Backup) para redundancia extra

7.1.2. Tipos de Backup

Backup Completo (Full):

• Qué copia: TODO
• Ventajas: Restauración rápida (solo necesitas el último full)
• Desventajas: Lento, consume mucho espacio, ventana de backup larga
• Uso típico: Semanal o mensual

Backup Incremental:

• Qué copia: Solo lo que cambió desde el ÚLTIMO backup (sea full o incremental)
• Ventajas: Rápido, consume poco espacio
• Desventajas: Restauración lenta (necesitas el full + TODOS los incrementales)
• Ejemplo:
  • Domingo: Full
  • Lunes: Incremental (cambios desde domingo)
  • Martes: Incremental (cambios desde lunes)
  • Miércoles: Incremental (cambios desde martes)
  Para restaurar el miércoles, necesitas: Full domingo + Incremental lunes + Incremental martes + Incremental miércoles

Backup Diferencial:

• Qué copia: Todo lo que cambió desde el ÚLTIMO FULL
• Ventajas: Compromiso entre full e incremental. Restauración más rápida que incremental.
• Desventajas: Cada día el diferencial es más grande (el viernes copia todo lo que cambió desde el domingo)
• Ejemplo:
  • Domingo: Full
  • Lunes: Diferencial (cambios desde domingo)
  • Martes: Diferencial (cambios desde domingo)
  • Miércoles: Diferencial (cambios desde domingo)
  Para restaurar el miércoles, necesitas: Full domingo + Diferencial miércoles

7.1.3. Estrategia típica en el SAS

Para Diraya (sistema crítico):

• Diario (L-V): Incremental a las 02:00h
• Semanal (Sábado): Diferencial a las 22:00h
• Mensual (Primer domingo): Completo a las 22:00h
• Replicación continua: Hot Site (RPO 15 min)
• Backup en cloud: Semanal (diferencial) a Azure

Para sistemas administrativos:

• Diario: Incremental
• Semanal: Completo

7.2. Sistemas de Almacenamiento para Backup

7.2.1. Soportes

Disco (Backup to Disk – B2D):

• Ventajas: Rápido para backup y restauración, acceso aleatorio
• Desventajas: Más caro por TB, menor durabilidad a largo plazo
• Uso: Backups recientes (últimos 30 días) para restauración rápida
• Tecnologías: NAS (Network Attached Storage), cabinas de discos dedicadas

Cinta (Tape):

• Ventajas: Muy barato por TB, larga durabilidad (30+ años si se almacena bien), portabilidad
• Desventajas: Lento, acceso secuencial (para leer el final de la cinta hay que rebobinar toda)
• Uso: Retención a largo plazo, backup offsite
• Tecnologías: LTO (Linear Tape-Open) – el estándar actual es LTO-9 (18TB sin comprimir, 45TB con comprimir)

Cloud:

• Ventajas: Offsite automático, escalable, sin gestión de hardware
• Desventajas: Coste recurrente, dependencia de conectividad, tiempos de restauración (bajar TBs por internet lleva tiempo)
• Uso: Backup secundario, DR as a Service
• Proveedores: Azure Backup, AWS S3 Glacier, Google Cloud Storage Nearline

7.2.2. Arquitecturas de almacenamiento

SAN (Storage Area Network):

• Red dedicada de almacenamiento, separada de la red de datos
• Protocolo Fibre Channel o iSCSI
• Rendimiento muy alto, latencia muy baja
• Uso: Almacenamiento de producción (bases de datos, máquinas virtuales…)

NAS (Network Attached Storage):

• Almacenamiento compartido en red de datos (Ethernet)
• Protocolo NFS (Linux) o SMB/CIFS (Windows)
• Más fácil de gestionar que SAN
• Uso: Compartir ficheros, backup to disk

Object Storage:

• Almacenamiento cloud, acceso por API HTTP/S
• Protocolo S3 (estándar de facto)
• Escalabilidad ilimitada (en teoría)
• Uso: Backup cloud, archivo de imágenes médicas (PACS)

7.3. Retención de Backups

No puedes guardar todos los backups para siempre. Hay que definir políticas de retención.

7.3.1. Normativa sanitaria

Ley 41/2002 – Historia clínica:

• Mínimo 5 años desde la fecha de alta de cada proceso asistencial
• Algunos documentos específicos: hasta 20 años (informes de quirófano, consentimientos informados de intervenciones graves…)
• En el caso de fallecimiento del paciente: desde la fecha de fallecimiento

Datos administrativos:

• Según normativa contable/administrativa
• Generalmente: 6 años (plazo de prescripción tributaria)

7.3.2. Política de retención típica en el SAS

7.4. Restauración y Pruebas de Backup

7.4.1. Tipos de restauración

Restauración de ficheros individuales:

• Usuario borró un documento por error
• Restauración selectiva de ficheros concretos
• Rápido (minutos)

Restauración de base de datos completa:

• Corrupción de BBDD
• Restaurar el último backup consistente
• Medio (horas, depende del tamaño)

Restauración de servidor completo (BMR – Bare Metal Recovery):

• Fallo hardware total del servidor
• Restaurar SO + aplicaciones + datos en un servidor nuevo (o máquina virtual)
• Lento (varias horas o días, depende del tamaño y complejidad)

7.4.2. Programa de pruebas de backup

Frecuencia recomendada:

• Sistemas críticos (Diraya): Prueba trimestral de restauración completa
• Sistemas importantes: Prueba semestral
• Sistemas normales: Prueba anual

Qué probar:

• Restauración completa en entorno de test
• Verificar integridad de datos
• Medir tiempos (para validar que cumples tus RTOs)
• Documentar problemas encontrados y corregirlos

Documentación:

• Acta de cada prueba con fecha, sistema probado, resultado, problemas, acciones correctivas
• Estas actas son evidencia para auditorías

7.5. Backups inmutables (protección anti-ransomware)

El ransomware moderno es sofisticado. No solo cifra los datos en producción… también BUSCA y DESTRUYE los backups.

Solución: Backups inmutables (WORM – Write Once, Read Many):

• Una vez escrito el backup, NO se puede modificar ni borrar durante el periodo de retención
• Ni siquiera el administrador puede borrarlo (previene tanto ransomware como borrado accidental/malicioso)
• Implementación:
  • Cintas físicas: Por naturaleza WORM (una vez grabado, no se puede sobreescribir sin borrar todo)
  • Object Storage con Object Lock: S3 Object Lock (AWS), Azure Immutable Blob Storage
  • Appliances de backup: Muchos tienen modo inmutable (Veeam, Commvault…)

8. Política de Seguridad de las TIC en la Junta de Andalucía y el SAS

Muy bien, hasta ahora hemos hablado de conceptos generales. Ahora toca aterrizarlos en TU contexto: Andalucía y el Servicio Andaluz de Salud.

8.1. Marco Normativo Andaluz

8.1.1. Decreto 311/2022 – ENS en Andalucía

El Real Decreto 311/2022 del Esquema Nacional de Seguridad es de ámbito estatal, pero Andalucía tiene su propia adaptación y desarrollo normativo.

• Aplicación obligatoria: Todas las consejerías, agencias y entes de la Junta de Andalucía (incluido el SAS) deben cumplir el ENS
• Categorización obligatoria: Todos los sistemas deben estar categorizados (BAJO, MEDIO, ALTO)
• Auditorías periódicas: Según categoría
• Certificación pública: Los sistemas categorizados ALTO deben publicar su conformidad ENS

8.1.2. Decreto 534/2021 – Administración Electrónica del SAS

Este decreto regula específicamente la administración electrónica en el ámbito del Servicio Andaluz de Salud.

Aspectos clave para seguridad:

• Firma electrónica obligatoria: Para profesionales sanitarios en actos que requieran garantía de autoría
• Notificaciones electrónicas: Seguras y con acuse de recibo
• Expediente electrónico: Garantías de integridad, autenticidad y conservación
• Interoperabilidad: Con otras administraciones (AGE, otras CCAA…)

8.2. Política de Seguridad Corporativa del SAS

El SAS tiene una política de seguridad propia, más específica que las normas generales de la Junta.

8.2.1. Política General de Seguridad de la Información del SSPA

Documento marco aprobado por la Dirección General del SAS que establece:

8.2.2. Normativas específicas del SAS

Normativa de Uso de Sistemas de Información:

• Prohibiciones:
  • Uso de dispositivos USB personales en equipos corporativos
  • Instalación de software no autorizado
  • Acceso a redes sociales desde equipos clínicos
  • Compartir credenciales de acceso (usuario/contraseña)
  • Dejar sesiones abiertas sin supervisión
• Obligaciones:
  • Bloqueo de pantalla al ausentarse (< 5 minutos)
  • Cambio de contraseña cada 90 días
  • Reporte inmediato de incidentes de seguridad
  • Participación en formación obligatoria anual

Política de Control de Acceso:

• Acceso por roles: Cada profesional tiene acceso según su perfil (médico, enfermería, administrativo…)
• Revisión periódica: Cada 6 meses se revisan los permisos de todos los usuarios
• Revocación inmediata: Al cambiar de puesto o cesar en el SAS, accesos revocados el mismo día
• Justificación de accesos excepcionales: Si un médico necesita acceso a un sistema fuera de su ámbito habitual, debe justificarlo por escrito

Política de Escritorio Limpio (Clear Desk):

• No dejar documentos con datos personales en mesas al final de la jornada
• Destrucción segura de documentos (trituradoras certificadas)
• Ordenadores portátiles guardados bajo llave
• Pantallas orientadas para que no sean visibles desde zonas públicas

8.2.3. Medidas específicas del SAS

8.3. Responsable de Seguridad en el SAS

Organización de la seguridad a nivel corporativo:

• Dirección General de Tecnologías de la Información: Máximo responsable TI del SAS
• Responsable Corporativo de Seguridad: Diseña y coordina la estrategia de seguridad del SAS
• Delegado de Protección de Datos (DPO): Obligatorio por RGPD. Independiente, supervisa cumplimiento de protección de datos
• CSIRT SAS: Equipo de respuesta a incidentes de seguridad
• Responsables de Seguridad de área: En cada provincia o gran hospital, coordinan la seguridad local

Funciones del Responsable de Seguridad:

1. Elaborar y mantener actualizada la política de seguridad
2. Supervisar el cumplimiento del ENS
3. Coordinar la respuesta ante incidentes de seguridad
4. Gestionar auditorías y certificaciones
5. Proponer inversiones en seguridad
6. Coordinar con CSIRT Andalucía y CCN-CERT
7. Elaborar informes de estado de seguridad para la dirección

9. Estrategias de Ciberseguridad (Europea, Nacional y Andaluza)

La ciberseguridad no es solo un tema técnico. Es un tema de seguridad nacional. Por eso existen estrategias coordinadas a nivel europeo, nacional y autonómico.

9.1. Estrategia Europea de Ciberseguridad

9.1.1. Directiva NIS2 (2022)

La Directiva NIS2 (Network and Information Security) actualiza la anterior Directiva NIS de 2016. Es el marco europeo de ciberseguridad.

Novedades principales:

• Ampliación de sectores: Incluye explícitamente la sanidad como sector esencial
• Más obligaciones: Medidas técnicas, organizativas y de gestión de riesgos más estrictas
• Notificación de incidentes: Obligatorio notificar incidentes significativos en 24 horas (alerta inicial), 72 horas (notificación completa)
• Sanciones: Multas de hasta 10 millones de euros o 2% de la facturación anual
• Gobernanza: Responsabilidad de la dirección (no se puede delegar)

Aplicación en el SAS:

• El SAS es un operador esencial según NIS2
• Debe implementar medidas de gestión de riesgos
• Obligación de notificar incidentes graves al CSIRT nacional (INCIBE/CCN-CERT)
• Auditorías de cumplimiento

9.1.2. ENISA – Agencia Europea de Ciberseguridad

ENISA (European Union Agency for Cybersecurity) coordina la ciberseguridad a nivel europeo.

Funciones:

• Emitir recomendaciones y buenas prácticas
• Coordinar respuesta a incidentes transfronterizos
• Certificación de productos de ciberseguridad
• Formación y concienciación
• Ejercicios de ciberdefensa a nivel europeo

9.1.3. Reglamento de Ciberresiliencia (Cyber Resilience Act)

En tramitación (2024-2025). Establecerá requisitos de seguridad obligatorios para productos con componentes digitales vendidos en la UE.

Impacto en sanidad:

• Dispositivos médicos conectados (IoMT) deberán cumplir requisitos de ciberseguridad
• Software sanitario con certificación de seguridad
• Actualizaciones de seguridad durante toda la vida útil del producto

9.2. Estrategia Nacional de Ciberseguridad

9.2.1. Estrategia Nacional 2019-2024 (prorrogada)

España tiene una estrategia nacional que se actualiza periódicamente. La actual (prorrogada hasta nueva publicación) tiene 5 ejes:

9.2.2. CCN-CERT

CCN-CERT (Centro Criptológico Nacional – Capacidad de Respuesta a Incidentes) es el CSIRT gubernamental de España.

Funciones:

• Respuesta a incidentes: En administraciones públicas y sectores estratégicos
• Alertas tempranas: Avisos de vulnerabilidades y amenazas
• Guías CCN-STIC: Documentación técnica de seguridad (más de 800 guías)
• Certificación ENS: Auditorías y certificación de cumplimiento ENS
• Formación: Cursos especializados para administraciones públicas

Relación con el SAS:

• El SAS debe notificar incidentes graves al CCN-CERT
• El CCN-CERT puede auditar sistemas del SAS para certificación ENS
• Recibe alertas y recomendaciones del CCN-CERT

9.2.3. INCIBE

INCIBE (Instituto Nacional de Ciberseguridad) es el CSIRT nacional para ciudadanos y sector privado.

Funciones:

• Respuesta a incidentes en empresas y ciudadanos
• Concienciación y formación
• Línea de ayuda en ciberseguridad
• Oficina de Coordinación de Ciberseguridad (OCC) – coordina respuesta a grandes incidentes

9.2.4. Ley 8/2011 – Protección de Infraestructuras Críticas

Esta ley identifica y protege las infraestructuras críticas de España. La sanidad es un sector estratégico.

El SAS es operador crítico:

• Obligación: Elaborar un Plan de Seguridad del Operador (PSO)
• Contenido del PSO:
  • Análisis de riesgos
  • Medidas de protección (físicas, técnicas, organizativas)
  • Planes de contingencia
  • Sistema de alertas
  • Protocolos de comunicación con autoridades
• Auditorías: El Ministerio del Interior puede inspeccionar el cumplimiento
• Centro Nacional de Protección de Infraestructuras Críticas (CNPIC): Coordina la protección

9.3. Estrategia Andaluza de Ciberseguridad

9.3.1. Estrategia de Ciberseguridad de Andalucía 2022-2025

Andalucía tiene su propia estrategia, alineada con la nacional y europea, pero adaptada a las peculiaridades autonómicas.

Objetivos estratégicos:

1. Proteger infraestructuras críticas andaluzas: Incluye explícitamente el SAS
2. Mejorar capacidades de detección y respuesta: CSIRT Andaluz operativo 24/7
3. Fomentar cultura de ciberseguridad: Formación en administraciones públicas andaluzas
4. Impulsar I+D en ciberseguridad: Colaboración con universidades andaluzas
5. Coordinación institucional: Entre consejerías, ayuntamientos, diputaciones…

9.3.2. CSIRT Andaluz

CSIRT Andaluz (Computer Security Incident Response Team de Andalucía) es el equipo autonómico de respuesta a incidentes.

Funciones:

• Coordinación: Respuesta a incidentes en administración autonómica (incluido SAS)
• Colaboración: Con CCN-CERT (escalado de incidentes graves)
• Alertas: Emisión de avisos de seguridad específicos para Andalucía
• Recomendaciones: Guías adaptadas al contexto andaluz
• Formación: Capacitación de equipos técnicos de consejerías

9.3.3. Protocolo de respuesta a incidentes en el SAS

Flujo de escalado:

9.3.4. Medidas específicas para sanidad

La Estrategia Andaluza reconoce la criticidad del sector sanitario y establece medidas específicas:

• Protección reforzada: Los sistemas sanitarios tienen prioridad en recursos de ciberseguridad
• Coordinación SAS-CSIRT Andaluz: Canal directo, respuesta prioritaria
• Ejercicios de ciberdefensa: Simulacros periódicos de ciberataques en hospitales
• Formación específica: Para personal TI sanitario (peculiaridades de la ciberseguridad en sanidad)
• Análisis de amenazas específicas: Threat intelligence enfocado en amenazas al sector salud (ransomware hospitalario, robo de historias clínicas…)

10. Mapa Conceptual del Tema

11. Preguntas de Autoevaluación

12. Referencias Bibliográficas y Normativas

12.1. Normativa Europea

• Reglamento (UE) 2016/679 (RGPD) – Reglamento General de Protección de Datos
• Directiva (UE) 2022/2555 (NIS2) – Directiva sobre medidas para un nivel común elevado de ciberseguridad en la Unión
• Reglamento eIDAS (UE) 910/2014 – Identificación electrónica y servicios de confianza

12.2. Normativa Nacional

• Real Decreto 311/2022 – Esquema Nacional de Seguridad (ENS)
• Ley Orgánica 3/2018 (LOPDGDD) – Protección de Datos Personales y garantía de los derechos digitales
• Ley 41/2002 – Autonomía del paciente y derechos y obligaciones en materia de información y documentación clínica
• Ley 8/2011 – Medidas de protección de infraestructuras críticas
• Real Decreto Legislativo 5/2015 – Estatuto Básico del Empleado Público

12.3. Normativa Autonómica (Andalucía)

• Decreto 534/2021 – Administración Electrónica del Servicio Andaluz de Salud
• Ley 2/1998 – Ley de Salud de Andalucía
• Estrategia de Ciberseguridad de Andalucía 2022-2025
• Plan de Transformación Digital del SSPA 2022-2027

12.4. Estándares Internacionales

• ISO/IEC 27001:2022 – Sistemas de Gestión de Seguridad de la Información
• ISO/IEC 27002:2022 – Código de buenas prácticas para controles de seguridad
• ISO/IEC 27005:2022 – Gestión de riesgos de seguridad de la información
• ISO/IEC 27017:2015 – Controles de seguridad para servicios cloud
• ISO/IEC 27018:2019 – Protección de datos personales en cloud
• ISO/IEC 27799:2016 – Gestión de seguridad de información en salud

12.5. Guías y Metodologías

• MAGERIT v3 – Metodología de Análisis y Gestión de Riesgos (CCN)
• Guías CCN-STIC – Serie de guías técnicas del Centro Criptológico Nacional
• NIST SP 800-53 – Security and Privacy Controls for Information Systems
• CIS Benchmarks – Center for Internet Security – Guías de configuración segura

12.6. Bibliografía Técnica Recomendada

• ITIL 4 Foundation – AXELOS. Gestión de Servicios TI
• COBIT 2019 – ISACA. Framework de gobierno y gestión de TI empresarial
• «Seguridad en Sistemas Informáticos» – Manuel José Fernández (McGraw-Hill)
• «Hacking Ético» – Carlos Tori (Ra-Ma)

12.7. Recursos Online

• CCN-CERT: https://www.ccn-cert.cni.es
• INCIBE: https://www.incibe.es
• ENISA: https://www.enisa.europa.eu
• AEPD: https://www.aepd.es
• Junta de Andalucía – CSIRT Andaluz: https://www.juntadeandalucia.es