1. Introducción a la Seguridad en Redes

La seguridad en redes constituye uno de los pilares fundamentales de la infraestructura tecnológica del Servicio Andaluz de Salud. En un entorno donde la disponibilidad, integridad y confidencialidad de la información sanitaria son críticas, la protección de las comunicaciones y sistemas de red no es opcional, es una obligación legal, ética y técnica que define la calidad del servicio que prestamos a los ciudadanos andaluces.

Cuando hablamos de seguridad en redes en el contexto del SAS, nos referimos a un ecosistema complejo que incluye la Red Corporativa del Sistema Sanitario Público de Andalucía, que interconecta más de 1.500 centros sanitarios, desde hospitales de tercer nivel hasta consultorios locales en poblaciones rurales. Esta red transporta diariamente millones de transacciones que van desde consultas a Diraya hasta prescripciones electrónicas, pasando por imágenes radiológicas de gran tamaño, videoconferencias de telemedicina y respaldos de sistemas críticos.

El concepto de seguridad en redes abarca tres dimensiones fundamentales que se alinean perfectamente con los principios del Esquema Nacional de Seguridad. La primera dimensión es la disponibilidad, que garantiza que los sistemas y la información estén accesibles cuando los profesionales sanitarios los necesiten. Un médico en urgencias no puede esperar a que se resuelva un problema de red para consultar el historial de alergias de un paciente. La segunda dimensión es la integridad, que asegura que la información no ha sido alterada de manera no autorizada durante su transmisión o almacenamiento. Una receta electrónica modificada podría tener consecuencias fatales. La tercera dimensión es la confidencialidad, que protege la información sensible de accesos no autorizados, cumpliendo así con el RGPD y la LOPDGDD.

La arquitectura de red del SAS presenta características únicas que la hacen especialmente vulnerable y, al mismo tiempo, especialmente crítica de proteger. Tenemos un entorno altamente distribuido con miles de puntos de acceso, desde puestos de enfermería hasta consultas de atención primaria. Manejamos grandes volúmenes de datos sensibles que son objetivo prioritario para ciberdelincuentes. Operamos servicios 24×7 donde cualquier interrupción puede afectar la atención sanitaria. Y debemos equilibrar la seguridad con la usabilidad, porque un sistema tan seguro que resulte inútil para los profesionales no cumple su función.

2. Amenazas y Ataques en Redes

Para defender eficazmente nuestras redes, primero debemos comprender las amenazas a las que nos enfrentamos. En el ámbito sanitario, los atacantes no son solo hackers aficionados buscando notoriedad, sino organizaciones criminales sofisticadas que ven en los sistemas de salud objetivos lucrativos, Estados que buscan obtener información estratégica, y grupos de hacktivismo que quieren causar impacto social. Cada tipo de atacante tiene motivaciones diferentes y utiliza técnicas distintas.

2.1. Clasificación de Ataques

Los ataques a redes pueden clasificarse según múltiples criterios que nos ayudan a entender su naturaleza y diseñar las defensas apropiadas. Desde el punto de vista de la técnica utilizada, podemos distinguir entre ataques pasivos y activos. Los ataques pasivos son aquellos donde el atacante únicamente observa y captura información sin modificar el tráfico de red. Un ejemplo típico es el sniffing, donde un atacante con acceso a un segmento de red captura paquetes para extraer información sensible como contraseñas o datos personales. Estos ataques son particularmente peligrosos porque pueden pasar desapercibidos durante largo tiempo.

Los ataques activos, por el contrario, implican que el atacante modifica, interrumpe o inyecta tráfico en la red. Estos ataques son más fáciles de detectar porque sus efectos suelen ser evidentes, pero también son más peligrosos porque comprometen directamente la disponibilidad o integridad de los sistemas. Un ataque de denegación de servicio distribuido contra los servidores de Diraya sería un ejemplo claro de ataque activo que podría paralizar el acceso a historias clínicas en toda Andalucía.

2.1.1. Ataques de Interceptación (Sniffing)

El sniffing es la técnica de captura y análisis del tráfico de red que circula por un medio compartido. En redes modernas con switches, el sniffing es más complejo que en las antiguas redes con hubs, pero sigue siendo posible mediante técnicas como ARP spoofing o mediante acceso físico a puertos de span en switches. En el contexto del SAS, un atacante que logre posicionarse en un segmento de red podría capturar comunicaciones entre un puesto de atención primaria y los servidores corporativos, obteniendo potencialmente credenciales de acceso o datos de pacientes si las comunicaciones no están adecuadamente cifradas.

Las herramientas de sniffing como Wireshark o tcpdump son legítimas cuando se utilizan para diagnóstico de red, pero en manos maliciosas se convierten en armas potentes. El protocolo de análisis de red debe distinguir entre el uso legítimo por parte del personal TIC autorizado para resolver problemas técnicos y el uso malicioso por parte de atacantes. Por eso las políticas de seguridad del SAS exigen que cualquier captura de tráfico de red se realice con autorización expresa, se registre adecuadamente y se elimine tras su análisis.

2.1.2. Ataques de Suplantación (Spoofing)

El spoofing engloba un conjunto de técnicas donde el atacante falsifica su identidad en la red haciéndose pasar por otra entidad legítima. Existen múltiples variantes según qué información se falsifique. En el IP spoofing, el atacante modifica la dirección IP origen de sus paquetes para hacerse pasar por un sistema confiable. En el ARP spoofing, manipula las tablas ARP de los dispositivos para redirigir el tráfico a través de su sistema. En el DNS spoofing, corrompe las respuestas DNS para redirigir a los usuarios a sitios maliciosos.

En el entorno sanitario del SAS, un ataque de ARP spoofing podría permitir a un atacante posicionarse como man-in-the-middle entre una estación de trabajo de consulta y el servidor de Diraya. Cada vez que el médico intente acceder a una historia clínica, el tráfico pasaría por el sistema del atacante, permitiéndole capturar credenciales, modificar datos o simplemente monitorizar qué pacientes están siendo atendidos. La detección de estos ataques requiere monitorización activa de anomalías en las tablas ARP y uso de soluciones como Dynamic ARP Inspection en switches gestionados.

2.1.3. Ataques de Denegación de Servicio (DoS y DDoS)

Los ataques de denegación de servicio buscan hacer que un recurso de red no esté disponible para sus usuarios legítimos, típicamente sobrecargando el sistema con tráfico ilegítimo o explotando vulnerabilidades que causan caídas del servicio. Cuando estos ataques se realizan desde múltiples fuentes coordinadas, hablamos de ataques distribuidos de denegación de servicio o DDoS, que son mucho más difíciles de mitigar porque el tráfico malicioso proviene de miles o millones de direcciones IP diferentes.

Para el SAS, un ataque DDoS contra la infraestructura de acceso web a Diraya o contra los servidores de receta electrónica podría tener consecuencias inmediatas en la atención sanitaria. Los médicos no podrían consultar historiales, prescribir medicación o registrar actos asistenciales. Los sistemas de cita previa dejarían de funcionar. La coordinación entre hospitales y atención primaria se vería comprometida. Por eso los sistemas críticos del SAS cuentan con protección DDoS en múltiples capas, desde servicios de mitigación en la nube hasta equipamiento especializado en los centros de proceso de datos.

2.1.4. Ataques de Inyección de Código Malicioso

Aunque técnicamente pertenecen más al ámbito de la seguridad de aplicaciones, los ataques de inyección tienen componentes de red significativos. El malware, una vez introduce en un sistema, suele intentar propagarse lateralmente por la red, comprometer otros equipos, establecer comunicaciones con servidores de comando y control externos, y exfiltrar información robada. El ransomware, que ha sido la amenaza más impactante para sistemas de salud en los últimos años, se propaga típicamente a través de redes internas tras la infección inicial de un puesto de trabajo.

El vector de infección puede ser un correo de phishing que un profesional sanitario abre inadvertidamente, una vulnerabilidad en software no actualizado, o una unidad USB infectada conectada a un puesto clínico. Una vez el malware tiene presencia en la red del SAS, la velocidad de propagación depende directamente de las medidas de segmentación de red, las políticas de acceso implementadas y la capacidad de detección de comportamientos anómalos. Un ransomware que cifre los respaldos de Diraya podría causar una pérdida catastrófica de información sanitaria.

2.1.5. Ingeniería Social y Vishing

No todos los ataques son técnicamente sofisticados. Muchos de los más exitosos explotan la dimensión humana de la seguridad. El vishing, contracción de voice phishing, consiste en ataques de ingeniería social realizados por teléfono donde el atacante se hace pasar por personal técnico, soporte de aplicaciones o incluso supervisores, solicitando credenciales o información sensible a profesionales sanitarios confiados.

Un escenario típico sería un atacante que llama a la centralita de un centro de salud haciéndose pasar por el servicio de ayuda de Diraya, indicando que hay un problema técnico que requiere verificar las credenciales del profesional. Un administrativo presionado y sin formación adecuada podría proporcionar sus credenciales, que el atacante utilizaría inmediatamente para acceder a historias clínicas o extraer información de pacientes.

2.2. Taxonomía Moderna de Amenazas

La evolución de las amenazas en ciberseguridad ha llevado a organizaciones como MITRE a desarrollar marcos de trabajo comprehensivos que categorizan las tácticas, técnicas y procedimientos utilizados por atacantes. El framework MITRE ATT&CK, ampliamente adoptado por equipos de seguridad corporativos y organismos gubernamentales como el CCN-CERT, proporciona una taxonomía estructurada de cómo los atacantes operan en redes empresariales.

Para el SAS, adoptar este framework implica entender que un ataque exitoso no es un evento puntual sino una cadena de acciones que el atacante debe completar. Primero necesita un acceso inicial, quizás mediante phishing o explotación de una vulnerabilidad expuesta en internet. Luego debe establecer persistencia para no perder el acceso si el sistema se reinicia. Posteriormente escalará privilegios para obtener mayores permisos. Realizará reconocimiento interno para mapear la red y localizar activos valiosos. Se moverá lateralmente comprometiendo otros sistemas. Y finalmente ejecutará sus objetivos, ya sea exfiltrar datos, cifrar sistemas o causar interrupción.

3. Herramientas de Prevención: Cortafuegos

El cortafuegos o firewall constituye la primera línea de defensa en cualquier arquitectura de seguridad de red. Su función principal es monitorizar, filtrar y controlar el tráfico de red entrante y saliente según políticas de seguridad definidas. En el contexto del SAS, donde la Red Corporativa interconecta miles de centros sanitarios y transporta información extremadamente sensible, los cortafuegos no son un elemento opcional sino un componente crítico obligatorio por normativa.

3.1. Fundamentos y Tipos de Cortafuegos

Históricamente, los primeros cortafuegos eran dispositivos relativamente simples que filtraban paquetes basándose únicamente en direcciones IP origen y destino, puertos y protocolo. Un firewall de filtrado de paquetes examina cada paquete de manera independiente sin mantener estado de las conexiones. Si un paquete TCP con destino al puerto 443 del servidor web corporativo cumple las reglas definidas, se permite su paso. Si no cumple las reglas, se descarta. Esta aproximación es rápida pero limitada porque no puede tomar decisiones basadas en el contexto de la comunicación.

La evolución natural llevó a los cortafuegos con estado o stateful firewalls, que mantienen tablas de las conexiones activas y pueden tomar decisiones más inteligentes. Cuando un servidor interno inicia una conexión saliente hacia un servidor de actualizaciones externo, el cortafuegos registra esa sesión y automáticamente permite el tráfico de respuesta asociado, sin necesidad de reglas específicas para cada dirección de tráfico. Esto mejora tanto la seguridad como la usabilidad, y es el tipo de firewall más común en entornos empresariales actuales.

3.1.1. Cortafuegos de Aplicación (Proxy Firewalls)

Los cortafuegos de aplicación o proxy firewalls operan en las capas superiores del modelo OSI, actuando como intermediarios que terminan las conexiones en ambos extremos. Cuando un cliente solicita acceso a un recurso externo, se conecta al proxy, que evalúa la solicitud, decide si cumple las políticas de seguridad, y si es así, establece una nueva conexión hacia el destino final. Este enfoque permite inspección profunda del tráfico y aplicación de políticas muy granulares, pero introduce latencia y puede convertirse en cuello de botella.

En el SAS, los proxy firewalls se utilizan típicamente para controlar el acceso a internet desde estaciones de trabajo administrativas. Un médico que intenta navegar a un sitio web de formación médica pasa por el proxy, que verifica que la categoría del sitio está permitida según las políticas, escanea el contenido descargado en busca de malware, y registra la actividad para auditoría. Si el sitio estuviera categorizado como entretenimiento o redes sociales, el proxy bloquearía el acceso según las políticas de uso aceptable.

3.1.2. Cortafuegos de Nueva Generación (NGFW)

Los Next Generation Firewalls o cortafuegos de nueva generación integran las capacidades tradicionales de filtrado con funcionalidades avanzadas de prevención de intrusiones, inspección SSL, control de aplicaciones y filtrado basado en identidad de usuario. Un NGFW puede identificar no solo que el tráfico va al puerto 443, sino que específicamente es tráfico de WhatsApp Web, y aplicar políticas diferenciadas según el usuario que lo genera y el contexto organizativo.

Para la infraestructura del SAS, donde coexisten múltiples perfiles de usuarios con necesidades muy diferentes, los NGFW proporcionan la flexibilidad necesaria. Un administrador de sistemas necesita acceso SSH a servidores de producción, pero un administrativo de atención primaria no. Un médico necesita acceder a bases de datos de medicamentos externas, pero debería bloquearse su acceso a redes sociales desde equipos corporativos durante horario laboral. Un aplicativo de facturación necesita comunicarse con la Tesorería de la Seguridad Social, pero no debería poder iniciar conexiones a direcciones IP arbitrarias en internet.

3.2. Diseño de Políticas de Cortafuegos

La efectividad de un cortafuegos no reside en sus capacidades técnicas sino en cómo se configuran sus políticas. Una política de firewall bien diseñada parte del principio de mínimo privilegio: todo está prohibido por defecto, y solo se permiten explícitamente las comunicaciones necesarias para el funcionamiento de los servicios. Este enfoque requiere un entendimiento profundo de los flujos de comunicación legítimos, documentación exhaustiva y procesos rigurosos de gestión de cambios.

Al diseñar políticas para el SAS, debemos considerar múltiples dimensiones. La dirección del tráfico: ¿es entrante desde internet, saliente hacia internet, o entre zonas internas? El origen y destino: ¿desde qué segmento de red o usuario, hacia qué servidor o servicio? El protocolo y puerto: ¿HTTPS en puerto 443, SSH en puerto 22, tráfico SQL hacia bases de datos? El contexto temporal: ¿esta comunicación debería ser posible 24×7 o solo durante horario laboral? La identidad: ¿qué usuarios o grupos están autorizados para este tipo de comunicación?

3.2.1. Reglas de Cortafuegos para Servicios Críticos

Los servicios críticos del SAS como Diraya requieren políticas de cortafuegos especialmente cuidadosas. El acceso a los servidores de aplicación de Diraya debe estar restringido exclusivamente desde las redes autorizadas: estaciones de trabajo clínicas identificadas, servidores de presentación web y sistemas de integración aprobados. Cualquier otro origen debe ser bloqueado. El tráfico debe ser exclusivamente HTTPS en puerto 443, nunca HTTP sin cifrar. Las conexiones deben originarse desde el cliente hacia el servidor, nunca en sentido inverso salvo para respuestas de sesiones establecidas.

Las bases de datos de Diraya requieren políticas aún más restrictivas. Solo los servidores de aplicación específicamente autorizados pueden comunicarse con los servidores de bases de datos, y únicamente en los puertos correspondientes al motor de base de datos utilizado. Ninguna estación de trabajo, ni siquiera de administradores, debe tener comunicación directa con las bases de datos de producción. Los respaldos se realizan a través de redes específicamente destinadas a ese propósito, aisladas del tráfico general.

3.2.2. Comprobar Reglas del Firewall: Caso Práctico

En los exámenes de oposición del SAS se han planteado casos prácticos donde, para que funcione correctamente un aula de formación, hay que realizar varias tareas en colaboración con el Área de Sistemas del Equipo Provincial TIC. Una de las opciones incorrectas planteadas era «Tirar el cable de red del armario de comunicaciones hasta el punto de red conexión del PC», porque el cableado estructurado ya debe estar previamente instalado y certificado según normativa. Sin embargo, una tarea fundamental y correcta es la «Comprobación de reglas del firewall definidas para el aula de formación».

Esta comprobación implica verificar que las políticas del cortafuegos permiten el tráfico necesario desde la VLAN del aula hacia los recursos formativos, que pueden incluir servidores de aplicaciones de prueba, máquinas virtuales de laboratorio, recursos en internet como plataformas de formación online, o servidores de ficheros con materiales didácticos. Al mismo tiempo, debe comprobarse que estas políticas no permiten accesos inapropiados, como conectividad directa desde el aula hacia sistemas de producción críticos.

3.3. Alta Disponibilidad en Cortafuegos

Dado que los cortafuegos son puntos únicos de paso obligatorio para el tráfico de red, su fallo puede paralizar completamente las comunicaciones. En un hospital del SAS, la caída del firewall perimetral implicaría pérdida de acceso a internet, imposibilidad de comunicación con otros centros sanitarios a través de la Red Corporativa, y potencialmente aislamiento de servicios críticos. Por eso los firewalls en entornos de producción se despliegan siempre en configuraciones de alta disponibilidad.

Es fundamental entender la diferencia entre alta disponibilidad y balanceo de carga, conceptos que frecuentemente se confunden. La alta disponibilidad busca garantizar continuidad del servicio ante fallos mediante redundancia. Tenemos dos firewalls configurados en modo activo-pasivo o activo-activo, sincronizando su estado continuamente. Si el firewall principal falla, el secundario asume automáticamente sus funciones con interrupción mínima del servicio. El objetivo es minimizar el downtime.

El balanceo de carga, por su parte, distribuye el trabajo entre múltiples dispositivos activos simultáneamente para mejorar el rendimiento y evitar saturación. Si a las 9 de la mañana del lunes 500 médicos en un hospital acceden simultáneamente a Diraya, el balanceador distribuye esas 500 sesiones entre los servidores disponibles. En la práctica, los firewalls críticos del SAS implementan ambas capacidades: varios equipos en modo activo-activo balancean el tráfico entre ellos mientras mantienen alta disponibilidad mediante sincronización de estado.

4. Control de Accesos e Intrusiones

Mientras los cortafuegos establecen un perímetro de seguridad y controlan qué tráfico puede pasar, los sistemas de detección y prevención de intrusiones analizan ese tráfico en busca de patrones maliciosos y comportamientos anómalos. Esta distinción es fundamental: el firewall dice «puedes pasar», pero el IDS/IPS dice «aunque puedas pasar, estamos vigilando qué haces, y si detectamos actividad sospechosa, te detendremos».

4.1. Sistemas de Detección de Intrusiones (IDS)

Un Sistema de Detección de Intrusiones o IDS es una herramienta que monitoriza el tráfico de red o la actividad del sistema en busca de señales de ataques o violaciones de políticas de seguridad. Cuando detecta algo sospechoso, genera una alerta que es revisada por los analistas de seguridad. Los IDS son pasivos en el sentido de que no bloquean activamente el tráfico, solo observan y alertan. Esta característica los hace muy seguros de desplegar porque no pueden causar falsos positivos que interrumpan servicios legítimos, pero también significa que no previenen directamente los ataques.

Existen dos aproximaciones fundamentales en los IDS. Los IDS basados en firmas comparan el tráfico observado contra una base de datos de patrones conocidos de ataques. Si detectan la secuencia de bytes característica de un exploit específico, generan una alerta. Esta aproximación es muy efectiva contra ataques conocidos y genera pocos falsos positivos, pero es ciega ante ataques nuevos para los que no existe firma. Los IDS basados en anomalías, por el contrario, aprenden qué es el comportamiento normal de la red y alertan cuando observan desviaciones significativas de ese patrón.

4.2. Sistemas de Prevención de Intrusiones (IPS)

Los Sistemas de Prevención de Intrusiones o IPS añaden capacidad de acción automática a la detección. Un IPS se sitúa inline en el flujo de tráfico, de modo que todos los paquetes deben atravesarlo. Cuando detecta actividad maliciosa, puede tomar acciones inmediatas como descartar los paquetes del ataque, terminar la sesión TCP, bloquear la dirección IP origen, o reconfigurar dinámicamente el firewall para crear nuevas reglas de bloqueo. Esta capacidad de respuesta automática es crucial en entornos donde los ataques se producen a velocidades que imposibilitan la intervención humana en tiempo real.

La principal ventaja del IPS sobre el IDS es que puede detener ataques antes de que alcancen sus objetivos. Si un exploit de ransomware intenta propagarse desde una estación de trabajo infectada hacia servidores de ficheros, el IPS puede bloquear esa comunicación instantáneamente, conteniendo la infección. El principal riesgo es que un falso positivo podría bloquear tráfico legítimo crítico. Un IPS que identifique erróneamente una actualización de Diraya como un ataque e interrumpa esa comunicación podría causar una interrupción del servicio no causada por un atacante real sino por la propia medida de seguridad.

4.3. Control de Acceso a la Red (NAC)

El Control de Acceso a la Red o Network Access Control es un enfoque de seguridad que verifica el estado de los dispositivos antes de permitir su conexión a la red. Cuando un ordenador portátil intenta conectarse a la red WiFi corporativa del SAS, el sistema NAC comprueba múltiples condiciones: ¿está actualizado el sistema operativo? ¿tiene antivirus activo y actualizado? ¿cumple con las políticas de configuración requeridas? ¿está el usuario autenticado correctamente? Solo si todas las verificaciones son satisfactorias, se concede acceso a la red, y aún así puede ser acceso limitado a una VLAN específica con políticas restrictivas.

El NAC es especialmente relevante en entornos sanitarios donde conviven múltiples tipos de dispositivos con diferentes niveles de control. Tenemos estaciones de trabajo corporativas administradas centralmente, equipos BYOD de profesionales que traen sus propios dispositivos, equipamiento médico con sistemas operativos embebidos que no pueden actualizarse fácilmente, y dispositivos IoT como sensores y bombas de infusión. Cada categoría requiere políticas NAC diferentes, balanceando seguridad con operatividad.

4.4. Equipos de Respuesta a Incidentes (CERT)

Un CERT, Computer Emergency Response Team, es un equipo de personas especializadas dedicado a prevenir, detectar y responder eficazmente a los incidentes de seguridad que puedan materializarse sobre los sistemas informáticos. El CERT no es un sistema automatizado ni un software, sino una estructura organizativa con procedimientos, herramientas y expertise específico. En España, el CCN-CERT coordina la respuesta a incidentes en las Administraciones Públicas, incluyendo el sector sanitario.

El SAS cuenta con capacidades de respuesta a incidentes integradas en su estructura de seguridad TIC. Cuando un hospital reporta un comportamiento anómalo en su red, cuando los sistemas IDS generan alertas de alta criticidad, o cuando un profesional reporta haber recibido un correo de phishing, el equipo de respuesta se activa siguiendo procedimientos predefinidos. La respuesta incluye contención del incidente para evitar su propagación, investigación para entender el alcance y vector de ataque, erradicación de la amenaza, recuperación de los sistemas afectados, y análisis post-incidente para mejorar defensas futuras.

5. Técnicas Criptográficas

La criptografía proporciona los fundamentos matemáticos para la protección de la confidencialidad, integridad y autenticidad de las comunicaciones. En el contexto de redes, las técnicas criptográficas se aplican en múltiples capas para asegurar que la información transmitida no pueda ser leída por terceros no autorizados, que no pueda ser modificada sin detección, y que podamos verificar la identidad de los comunicantes. Para el SAS, donde transmitimos datos de categoría especial según el RGPD, el cifrado no es opcional sino obligatorio.

5.1. Fundamentos de Criptografía

La criptografía moderna se basa en dos paradigmas principales: cifrado simétrico y cifrado asimétrico. El cifrado simétrico utiliza la misma clave para cifrar y descifrar información. Es extremadamente rápido y eficiente, lo que lo hace ideal para cifrar grandes volúmenes de datos. Algoritmos como AES-256 se utilizan para proteger datos en tránsito y en reposo. Sin embargo, el cifrado simétrico presenta el desafío de la distribución de claves: ¿cómo comparten dos partes la clave secreta de manera segura si el canal de comunicación no es seguro?

El cifrado asimétrico resuelve este problema utilizando pares de claves matemáticamente relacionadas: una clave pública que puede compartirse abiertamente, y una clave privada que debe mantenerse secreta. Lo cifrado con la clave pública solo puede descifrarse con la correspondiente clave privada, y viceversa. Algoritmos como RSA y curvas elípticas proporcionan esta capacidad. El cifrado asimétrico es computacionalmente más costoso que el simétrico, por lo que en la práctica se utiliza para establecer canales seguros e intercambiar claves simétricas, que luego se usan para el cifrado del volumen principal de datos.

5.2. Protocolos de Cifrado en Redes

5.2.1. SSL/TLS: La Base de las Comunicaciones Seguras

El protocolo TLS, Transport Layer Security, y su predecesor SSL, Secure Sockets Layer, son los fundamentos de las comunicaciones seguras en internet y redes corporativas. Cuando accedemos a una aplicación web mediante HTTPS, estamos utilizando HTTP sobre TLS. El protocolo TLS proporciona tres garantías fundamentales: cifrado del canal de comunicación, integridad de los datos transmitidos, y autenticación del servidor y opcionalmente del cliente.

El establecimiento de una conexión TLS, conocido como handshake, es un proceso fascinante. El cliente se conecta al servidor y propone una lista de algoritmos criptográficos que soporta. El servidor selecciona los algoritmos a utilizar y presenta su certificado digital, que contiene su clave pública firmada por una Autoridad de Certificación de confianza. El cliente verifica que el certificado es válido y pertenece efectivamente al servidor con el que quiere comunicarse. Mediante algoritmos de intercambio de claves como Diffie-Hellman, cliente y servidor establecen un secreto compartido sin haberlo transmitido directamente. Con ese secreto generan claves simétricas para cifrar la comunicación subsiguiente.

Para el SAS, TLS 1.3 en su última versión es el estándar mínimo aceptable para nuevas implementaciones. Versiones anteriores como TLS 1.0 y 1.1 están oficialmente obsoletas y presentan vulnerabilidades conocidas. Todo el tráfico entre estaciones de trabajo y servidores de aplicaciones críticas como Diraya debe ir cifrado con TLS. Los certificados digitales deben ser emitidos por la PKI corporativa del SAS o por Autoridades de Certificación públicas reconocidas, con renovación automática antes de su expiración para evitar interrupciones del servicio.

5.2.2. IPsec: Seguridad a Nivel de Red

IPsec, Internet Protocol Security, es un conjunto de protocolos que proporcionan seguridad a nivel de la capa de red del modelo OSI. A diferencia de TLS que opera en la capa de aplicación, IPsec es transparente para las aplicaciones porque cifra directamente los paquetes IP. Esto lo hace ideal para establecer túneles VPN entre sitios, por ejemplo conectando de manera segura todos los centros de salud de una provincia a su hospital de referencia a través de internet.

IPsec puede operar en dos modos: modo transporte y modo túnel. En modo transporte, solo se cifra el payload del paquete IP, manteniendo las cabeceras originales. Este modo es eficiente para comunicaciones entre dos hosts específicos. En modo túnel, el paquete IP completo se cifra y se encapsula en un nuevo paquete IP con nuevas cabeceras. Este modo se utiliza en VPNs sitio-a-sitio porque permite que las direcciones IP internas de la red corporativa viajen cifradas y sean inaccesibles para observadores en internet.

5.3. Funciones Hash y Firmas Digitales

Las funciones hash criptográficas son algoritmos que toman una entrada de tamaño arbitrario y producen una salida de tamaño fijo llamada digest o resumen. Funciones como SHA-256 tienen propiedades especiales: son deterministas, es decir, la misma entrada siempre produce la misma salida; son unidireccionales, es computacionalmente inviable obtener la entrada original a partir del hash; y tienen resistencia a colisiones, es extremadamente difícil encontrar dos entradas diferentes que produzcan el mismo hash.

Las firmas digitales combinan funciones hash con criptografía asimétrica para proporcionar autenticación e integridad. Cuando un servidor genera un informe de laboratorio digital para un paciente del SAS, puede firmarlo digitalmente. El proceso implica calcular el hash del documento y cifrarlo con la clave privada del servidor. Cualquier receptor puede verificar la firma descifrandola con la clave pública del servidor y comparando el resultado con el hash que él mismo calcula del documento. Si coinciden, tiene garantía de que el documento proviene del servidor legítimo y no ha sido modificado.

5.4. Infraestructura de Clave Pública (PKI)

Una Infraestructura de Clave Pública o PKI es un conjunto de políticas, procedimientos, hardware, software y personas necesarias para crear, gestionar, distribuir, usar, almacenar y revocar certificados digitales. El SAS opera su propia PKI corporativa que emite certificados digitales para servidores, aplicaciones y potencialmente usuarios. Esta PKI es jerárquica: en la raíz está la Autoridad de Certificación raíz del SAS, cuyo certificado está profundamente protegido y rara vez se utiliza. Por debajo están las Autoridades de Certificación subordinadas que emiten los certificados de uso diario.

Cuando un nuevo servidor de aplicaciones se despliega en el SAS, necesita un certificado digital para soportar conexiones HTTPS. El administrador del servidor genera un par de claves y una solicitud de firma de certificado o CSR. Esta solicitud se envía a la CA corporativa, que verifica la autenticidad de la solicitud y, si es válida, emite un certificado digital firmando la clave pública del servidor. Este certificado contiene información como el nombre DNS del servidor, su clave pública, el periodo de validez, y la firma de la CA. Los navegadores y aplicaciones que confían en la CA raíz del SAS automáticamente confiarán en este certificado.

6. Seguridad en Comunicaciones Móviles

La proliferación de dispositivos móviles en entornos sanitarios ha transformado radicalmente la manera en que los profesionales acceden a información clínica y se comunican. Médicos que consultan Diraya desde tablets durante el pase de planta, enfermeras que registran constantes vitales en smartphones, y gestores que acceden a cuadros de mando desde sus dispositivos personales presentan desafíos de seguridad específicos que requieren medidas adicionales más allá de las implementadas para dispositivos fijos en red cableada.

6.1. Amenazas Específicas en Entornos Móviles

Los dispositivos móviles son particularmente vulnerables porque combinan múltiples vectores de amenaza. Primero, su naturaleza portátil los hace susceptibles a pérdida o robo. Un smartphone con credenciales almacenadas de acceso a Diraya que se pierde en un taxi es una brecha de seguridad potencial. Segundo, los usuarios instalan aplicaciones de fuentes no verificadas, que pueden contener malware. Tercero, se conectan a redes WiFi públicas no seguras donde el tráfico puede ser interceptado. Cuarto, muchos dispositivos están desactualizados porque los usuarios posponen las actualizaciones del sistema operativo.

En Android, la fragmentación del ecosistema agrava el problema. Existen miles de modelos de dispositivos de decenas de fabricantes, cada uno con su propia capa de personalización sobre el sistema operativo base. Las actualizaciones de seguridad dependen de que el fabricante las desarrolle y el operador las distribuya, proceso que puede llevar meses o simplemente no ocurrir nunca para dispositivos antiguos. iOS presenta un panorama más controlado pero no está exento de vulnerabilidades, especialmente en dispositivos con jailbreak donde se han deshabilitado las protecciones del sistema.

6.2. Soluciones de Gestión de Dispositivos Móviles (MDM)

Las plataformas de Mobile Device Management o MDM permiten a las organizaciones gestionar centralmente la configuración y seguridad de dispositivos móviles. El SAS utiliza soluciones MDM para establecer políticas obligatorias en tablets corporativas utilizadas para acceso a Diraya móvil. Estas políticas pueden incluir cifrado obligatorio del almacenamiento, requisitos de contraseña o biometría, prohibición de jailbreak o root, instalación automática de actualizaciones de seguridad, y capacidad de borrado remoto si el dispositivo se pierde.

Un concepto más avanzado es la separación entre perfil personal y corporativo en el mismo dispositivo, conocido como contenedorización. En un modelo BYOD, Bring Your Own Device, donde el profesional usa su smartphone personal para acceder a recursos del SAS, el MDM puede crear un contenedor corporativo aislado. Las aplicaciones y datos corporativos existen en este contenedor cifrado, con políticas estrictas, mientras que el resto del dispositivo funciona normalmente para uso personal. Si el empleado deja la organización, se elimina el contenedor corporativo sin afectar sus datos personales.

6.3. Seguridad en Redes Móviles: 4G y 5G

Las redes móviles celulares han evolucionado significativamente en sus capacidades de seguridad. Las redes 4G LTE implementan cifrado extremo a extremo entre el dispositivo y la estación base, autenticación mutua entre el dispositivo y la red usando tarjetas SIM con capacidades criptográficas, e integridad de las comunicaciones de señalización. Sin embargo, permanecen vulnerabilidades relacionadas con la compatibilidad hacia atrás con tecnologías antiguas como 2G que tienen seguridad débil.

Las redes 5G introducen mejoras sustanciales de seguridad específicamente diseñadas para soportar casos de uso críticos como telemedicina y cirugía remota. La autenticación es más robusta, el cifrado se extiende más allá de la capa de radio hasta la infraestructura de red, y se implementan técnicas avanzadas de aislamiento entre servicios compartiendo la misma infraestructura física. Para el SAS, 5G permitirá aplicaciones antes impracticables, como transmisión en tiempo real de vídeo quirúrgico de alta definición para consultas remotas, o telemetría continua de pacientes ambulatorios.

6.4. Aplicaciones Móviles Seguras

Cuando el SAS desarrolla o adquiere aplicaciones móviles para acceso a sistemas corporativos, deben implementarse controles de seguridad específicos. La aplicación debe comunicarse exclusivamente mediante canales cifrados usando TLS 1.3, con certificate pinning para prevenir ataques man-in-the-middle usando certificados fraudulentos. Las credenciales nunca deben almacenarse en claro en el dispositivo, sino en el keychain del sistema operativo con protección hardware si está disponible. La aplicación debe implementar timeout de sesión automático tras periodo de inactividad, y debe poder ser borrada remotamente por MDM si el dispositivo se compromete.

El desarrollo de aplicaciones móviles para sanidad debe seguir guías específicas como las del OWASP Mobile Security Project. Las vulnerabilidades más comunes incluyen almacenamiento inseguro de datos locales, comunicaciones sin cifrado, autenticación débil, validación insuficiente de entrada que permite inyección de código, y exposición inadvertida de APIs internas. Cada release de una aplicación de producción debe pasar por pruebas de seguridad automatizadas y auditorías manuales por especialistas.

7. Arquitecturas de Seguridad Avanzadas

7.1. Modelo Zero Trust

El modelo tradicional de seguridad en redes asumía un perímetro confiable: dentro de la red corporativa todo era seguro, fuera todo era peligroso. Este modelo es obsoleto en entornos donde los profesionales trabajan remotamente, las aplicaciones migran a la nube, y los atacantes logran establecer presencia persistente dentro de las redes. El modelo Zero Trust parte del principio de «nunca confiar, siempre verificar»: cada solicitud de acceso debe ser autenticada, autorizada y cifrada, independientemente de su origen.

Implementar Zero Trust en el SAS implica varios componentes. Primero, identidad verificada de usuarios y dispositivos, usando autenticación multifactor y verificación continua del estado de seguridad de los dispositivos. Segundo, acceso con mínimo privilegio, donde cada usuario solo puede acceder a los recursos específicos que necesita para su función. Tercero, microsegmentación de la red, dividiendo los recursos en pequeños segmentos con controles de acceso granulares entre ellos. Cuarto, inspección y cifrado de todo el tráfico, sin excepciones para comunicaciones internas.

7.2. Segmentación de Red y VLANs

La segmentación de red mediante VLANs, Virtual Local Area Networks, es una técnica fundamental para aislar dominios de seguridad diferentes compartiendo la misma infraestructura física. En un hospital del SAS, típicamente encontramos múltiples VLANs: VLAN clínica para estaciones de trabajo con acceso a Diraya, VLAN administrativa para gestión y facturación, VLAN de infraestructura para servidores y sistemas de almacenamiento, VLAN de equipamiento médico para dispositivos IoT sanitarios, VLAN de invitados para profesionales visitantes, VLAN de pacientes para acceso WiFi de hospitalizados.

Cada VLAN constituye un dominio de broadcast aislado. El tráfico entre VLANs diferentes debe pasar por un router o switch de capa 3, donde pueden aplicarse políticas de seguridad mediante ACLs. Un equipo en la VLAN de pacientes nunca debe poder comunicarse directamente con servidores en la VLAN de infraestructura. Un dispositivo IoT médico en su VLAN específica solo debe poder comunicarse con los servidores de gestión del equipamiento, no con internet ni con estaciones de trabajo clínicas. Esta segmentación limita drásticamente la capacidad de movimiento lateral de un atacante que comprometa un dispositivo.

7.3. Defensa en Profundidad

El principio de defensa en profundidad postula que la seguridad no debe depender de una única medida sino de múltiples capas que se complementan. Si un atacante supera una defensa, debe enfrentarse a la siguiente. En la arquitectura de red del SAS, esto se traduce en firewall perimetral en el borde, IPS inline inspeccionando tráfico, segmentación de red con VLANs, NAC controlando dispositivos conectados, endpoint protection en estaciones de trabajo, cifrado de comunicaciones, monitorización y logging centralizado, y finalmente respuesta a incidentes. El fallo de cualquier capa individual no compromete completamente la seguridad.

8. Casos Prácticos y Aplicación en el SAS

8.1. Caso: Aseguramiento de una Nueva Sede de Atención Primaria

Cuando el SAS abre un nuevo centro de salud, la infraestructura de red debe diseñarse con seguridad integrada desde el principio. El cableado estructurado debe certificarse según estándares, con armarios de comunicaciones físicamente seguros. Los switches deben configurarse con VLANs separadas para clínica, administración e infraestructura. Debe implementarse NAC para que solo dispositivos autorizados y en buen estado de seguridad puedan conectarse. El centro se conecta a la Red Corporativa mediante enlaces cifrados VPN o circuitos dedicados protegidos con IPsec.

La red WiFi del centro requiere especial atención. Según la normativa de la Junta de Andalucía, es obligatorio prevenir el acceso físico a los puntos de acceso, que deben instalarse en ubicaciones de difícil manipulación, y restringir su alcance para que la señal no se propague innecesariamente fuera del edificio. El cifrado WPA2 o preferiblemente WPA3 es obligatorio, con contraseñas robustas almacenadas de manera segura. WPS debe estar desactivado por sus vulnerabilidades conocidas. El SSID puede ocultarse aunque, como se ha estudiado en el temario, esto no constituye una medida de seguridad robusta por sí sola porque un atacante puede descubrir el SSID oculto monitorizando el tráfico de clientes que se conectan.

8.2. Caso: Respuesta a un Incidente de Seguridad

Un lunes por la mañana, el SIEM del SAS genera alertas de comportamiento anómalo: varias estaciones de trabajo en un hospital están intentando conectarse a direcciones IP externas previamente identificadas como servidores de comando y control de malware. El equipo de respuesta a incidentes se activa siguiendo el procedimiento establecido. Primero, contención: las estaciones afectadas se aíslan de la red mediante configuración remota de los switches, impidiendo que el malware se propague pero permitiendo investigación forense. Segundo, identificación: se extraen muestras del malware para análisis y se determina el vector de entrada, descubriendo que fue un correo de phishing. Tercero, erradicación: se reimagentan las estaciones afectadas y se escanea toda la red en busca de indicadores de compromiso. Cuarto, recuperación: las estaciones se reintegran a la red con monitorización estrecha. Quinto, lecciones aprendidas: se refuerza la formación anti-phishing y se actualizan las firmas de los sistemas de protección.

8.3. Caso: Migración de Aplicación a Arquitectura Cifrada

Una aplicación legada de gestión de citas que originalmente se diseñó para uso interno en un hospital ahora necesita exponerse para acceso desde centros de salud dispersos geográficamente. La aplicación originalmente utilizaba HTTP sin cifrar porque operaba en una red supuestamente segura. La migración requiere múltiples modificaciones. Los servidores de aplicación deben configurarse para HTTPS exclusivamente, deshabilitando HTTP y redirigiendo cualquier intento de conexión insegura. Deben obtenerse certificados digitales válidos de la PKI corporativa del SAS. La aplicación debe modificarse para asegurar que todas las referencias a recursos utilizan URLs HTTPS. Los clientes deben configurarse para verificar los certificados del servidor y rechazar certificados inválidos o caducados. Los firewalls deben actualizarse para permitir HTTPS en puerto 443 pero bloquear HTTP en puerto 80. Y finalmente, debe realizarse testing exhaustivo para verificar que la aplicación funciona correctamente sobre el canal cifrado y que el rendimiento es aceptable.

                                    ╔════════════════════════════════════════╗
                                    ║      SEGURIDAD EN REDES (TEMA 32)     ║
                                    ║          Protección Integral          ║
                                    ╚════════════════════════════════════════╝
                                                    │
                    ┌───────────────────────────────┼───────────────────────────────┐
                    │                               │                               │
            ┌───────▼───────┐              ┌────────▼────────┐             ┌────────▼────────┐
            │   AMENAZAS Y  │              │   HERRAMIENTAS  │             │  CRIPTOGRAFÍA   │
            │    ATAQUES    │              │   DE DEFENSA    │             │  Y PROTOCOLOS   │
            └───────┬───────┘              └────────┬────────┘             └────────┬────────┘
                    │                               │                               │
        ┌───────────┼───────────┐      ┌───────────┼───────────┐      ┌────────────┼────────────┐
        │           │           │      │           │           │      │            │            │
    ┌───▼────┐ ┌───▼────┐ ┌───▼───┐ ┌▼──────┐ ┌──▼─────┐ ┌──▼───┐ ┌▼──────┐ ┌────▼────┐ ┌────▼────┐
    │Pasivos │ │Activos │ │Ingen. │ │Firewall│ │IDS/IPS │ │ NAC  │ │Simétrico│ │Asimétrico│ │SSL/TLS │
    │        │ │        │ │Social │ │        │ │        │ │      │ │AES-256 │ │RSA/ECC  │ │VPN/IPsec│
    └────────┘ └────────┘ └───────┘ └────────┘ └────────┘ └──────┘ └─────────┘ └─────────┘ └─────────┘
        │           │           │         │          │         │         │           │           │
        │           │           │         │          │         │         │           │           │
   ┌────▼────┐ ┌────▼────┐ ┌───▼────┐ ┌──▼──────┐ ┌▼───────┐ ┌▼──────┐ ┌▼────────┐ ┌▼────────┐ ┌▼────────┐
   │Sniffing │ │DoS/DDoS │ │Vishing │ │Stateful │ │Network │ │Control│ │Cifrado  │ │Firmas   │ │Túneles  │
   │Spoofing │ │Ransomw. │ │Phishing│ │Inspect. │ │Monitor │ │Acceso │ │Datos    │ │Digital. │ │Seguros  │
   └─────────┘ └─────────┘ └────────┘ └─────────┘ └────────┘ └───────┘ └─────────┘ └─────────┘ └─────────┘
        │                                                                      │
        │                                                                      │
        └──────────────────────────────┬───────────────────────────────────────┘
                                       │
                            ┌──────────▼──────────┐
                            │  ARQUITECTURAS DE   │
                            │  SEGURIDAD AVANZADAS│
                            └──────────┬──────────┘
                                       │
                    ┌──────────────────┼──────────────────┐
                    │                  │                  │
            ┌───────▼───────┐  ┌───────▼───────┐  ┌──────▼──────┐
            │  ZERO TRUST   │  │  SEGMENTACIÓN │  │  DEFENSA EN │
            │  (Nunca Confiar│  │    (VLANs)    │  │  PROFUNDIDAD│
            │Always Verify) │  │  Microsegment.│  │ (Múltiples   │
            └───────┬───────┘  └───────┬───────┘  │  Capas)     │
                    │                  │          └──────┬──────┘
                    │                  │                 │
                    └─────────┬────────┴─────────────────┘
                              │
                    ┌─────────▼─────────┐
                    │  APLICACIÓN SAS   │
                    │  ═══════════════  │
                    │ • Red Corporativa │
                    │ • Diraya/InterSAS │
                    │ • WiFi Sanitario  │
                    │ • VPN Profesional │
                    │ • ENS/RGPD        │
                    │ • CERT/USTIC      │
                    │ • Móvil/5G        │
                    └───────────────────┘

LEYENDA:
═══════════════════════════════════════════════════════════════════════════════
🔴 AMENAZAS: Pasivas (Sniffing), Activas (DDoS, Ransomware), Social (Vishing)
🛡️  DEFENSAS: Firewalls (Filtrado), IDS/IPS (Detección), NAC (Control Acceso)
🔒 CRIPTO: Simétrica (AES), Asimétrica (RSA), Protocolos (TLS, IPsec, VPN)
🏗️  ARQUITECTURA: Zero Trust, Segmentación VLANs, Defensa Profundidad
⚕️  SAS: USTIC, CERT, ENS-MEDIO/ALTO, RGPD categoría especial, WiFi normativa
═══════════════════════════════════════════════════════════════════════════════