✅ Respuesta Correcta: B

Argumentación: Los ISPs Tier 1 son las redes troncales de Internet (ejemplos: AT&T, Verizon, NTT, Lumen). Su característica definitoria es que tienen acceso a toda Internet sin pagar tránsito a nadie. Se interconectan entre sí mediante acuerdos de peering gratuito, formando el backbone global de Internet.

Justificación opciones incorrectas:

• A: Describe a los ISPs Tier 2 (regionales).
• C: Describe a los ISPs Tier 3 (locales).
• D: Describe a los IXP (Internet Exchange Points), que son infraestructura física, no ISPs.

✅ Respuesta Correcta: B

Argumentación: Una CDN (Content Delivery Network) es una red distribuida de servidores que almacenan copias (caches) de contenido estático (imágenes, vídeos, CSS, JavaScript) en ubicaciones geográficamente próximas a los usuarios. Esto reduce la latencia (tiempo de carga) y descarga tráfico del servidor origen, mejorando rendimiento y disponibilidad.

Justificación opciones incorrectas:

• A: Describe funcionalidad de un gestor de certificados.
• C: Describe sistemas de backup.
• D: Describe el sistema DNS.

✅ Respuesta Correcta: B

Argumentación: DNS utiliza mayormente UDP/53 por su rapidez en consultas estándar. Sin embargo, usa TCP/53 en dos casos principales:

1. Transferencias de zona (AXFR/IXFR): Replicación completa de la base de datos DNS entre servidor maestro y esclavos. Requiere fiabilidad (TCP).
2. Respuestas grandes (>512 bytes): Cuando la respuesta no cabe en un paquete UDP, se trunca y el cliente reintenta con TCP.

Justificación opciones incorrectas:

• A, C, D: No reflejan la realidad técnica del protocolo DNS.

✅ Respuesta Correcta: B

Argumentación: La mejora clave de HTTP/2 es la multiplexación binaria. Permite enviar y recibir múltiples «streams» (flujos de datos) en paralelo sobre una única conexión TCP, eliminando el problema de «head-of-line blocking» de HTTP/1.1 donde una petición bloqueada retrasa todas las demás. Esto mejora el rendimiento entre 30-50%.

Justificación opciones incorrectas:

• A: HTTP/2 recomienda TLS pero no es obligatorio (aunque en la práctica todos los navegadores lo requieren).
• C: HTTP/2 comprime cabeceras (HPACK), no las elimina.
• D: HTTP/2 sigue usando TCP. Es HTTP/3 el que usa QUIC sobre UDP.

✅ Respuesta Correcta: B

Argumentación: HTTP/3 es un cambio radical: abandona TCP y usa QUIC (Quick UDP Internet Connections) sobre UDP. Las ventajas principales son:

• ✅ Eliminación de HOL blocking a nivel TCP: Los streams son completamente independientes.
• ✅ Handshake 0-RTT: Reanudación de sesiones sin latencia (conexión instantánea).
• ✅ Migración de conexión: Cambio de red (WiFi ↔ 4G) sin perder la conexión.
• ✅ TLS 1.3 integrado: Cifrado nativo en QUIC.

Justificación opciones incorrectas:

• A, D: HTTP/3 NO usa TCP.
• C: SCTP no se usa en HTTP/3.

✅ Respuesta Correcta: C

Argumentación: En APIs REST, los métodos HTTP tienen semánticas específicas:

• POST: Crear nuevo recurso.
• PUT: Actualizar/reemplazar COMPLETO un recurso (idempotente).
• PATCH: Actualización PARCIAL de un recurso (solo los campos que se envían).
• DELETE: Eliminar recurso.

Ejemplo práctico: Para cambiar solo el teléfono de un paciente sin enviar todos sus datos, se usa PATCH /api/pacientes/12345 con {"telefono": "955123456"}.

Justificación opciones incorrectas:

• A: POST es para creación, no actualización.
• B: PUT reemplaza el recurso COMPLETO.
• D: UPDATE no es un método HTTP válido.

✅ Respuesta Correcta: A

Argumentación: La diferencia fundamental es:

• REST: Es un estilo arquitectónico (no un protocolo) que usa HTTP con métodos estándar (GET, POST, PUT, DELETE). Formato de datos flexible: JSON (mayormente), XML, HTML, texto. Ligero y simple.
• SOAP: Es un protocolo formal estandarizado por W3C. Solo usa XML (verboso). Independiente del transporte (HTTP, SMTP, JMS, TCP). Más complejo pero con características empresariales avanzadas (WS-Security, transacciones).

Justificación opciones incorrectas:

• B: REST funciona sobre HTTP/HTTPS (no otros protocolos). SOAP sí puede usar múltiples transportes.
• C: SOAP es más lento debido al overhead de XML.
• D: Al revés: SOAP requiere WSDL, REST no (usa OpenAPI opcionalmente).

✅ Respuesta Correcta: B

Argumentación: Estado actual (2025) de SSL/TLS:

Justificación opciones incorrectas:

• A: SSL 3.0 está prohibido (RFC 7568).
• C: Aunque se usan coloquialmente como sinónimos, técnicamente TLS es el sucesor de SSL.
• D: TLS 1.0 está deprecated, no es obligatorio ni recomendado.

✅ Respuesta Correcta: D

Argumentación: HTTPS = HTTP + TLS. Es simplemente el protocolo HTTP normal ejecutado sobre una capa de cifrado proporcionada por SSL/TLS. La «S» significa «Secure» (seguro). Esto garantiza:

• ✅ Confidencialidad: Nadie puede leer el contenido (cifrado).
• ✅ Integridad: Nadie puede modificar los datos sin detección.
• ✅ Autenticación: Verificas que estás conectado al servidor correcto (certificado digital).

HTTPS usa el puerto 443 (vs. HTTP puerto 80).

Justificación opciones incorrectas:

• A: VPN es una solución distinta (túnel a nivel de red).
• B: La compresión es independiente del cifrado (puede usarse GZIP sobre HTTP o HTTPS).
• C: HTTP/2 es una versión del protocolo, no relacionado con el cifrado HTTPS.

✅ Respuesta Correcta: D

Argumentación: Durante el handshake TLS se intercambian:

• ✅ Versiones TLS soportadas (A)
• ✅ Cipher suites (algoritmos de cifrado, hash, key exchange) (B)
• ✅ Certificado digital del servidor que incluye la clave PÚBLICA (C)
• ✅ Números aleatorios (client random, server random)
• ✅ Pre-master secret cifrado con la clave pública del servidor

La clave PRIVADA del servidor NUNCA se transmite ni sale del servidor. Es el secreto que solo el servidor conoce y usa para descifrar el pre-master secret que el cliente envió cifrado con la clave pública.

Justificación opciones incorrectas:

• A, B, C: Se intercambian durante el handshake.

✅ Respuesta Correcta: C

Argumentación: Los certificados EV (Extended Validation) requieren la validación más exhaustiva. La CA (Autoridad Certificadora) verifica:

• ✅ Existencia legal de la organización (registros mercantiles)
• ✅ Dirección física verificada
• ✅ Control del dominio
• ✅ Autorización del solicitante para representar a la organización
• ✅ Verificación telefónica directa

Los certificados EV se usan en banca online, e-commerce de alto valor y servicios críticos. Históricamente mostraban una «barra verde» en navegadores (ahora removida en Chrome/Firefox por usabilidad).

Comparativa:

• DV: Solo control del dominio (email/DNS) – Emisión automática en minutos.
• OV: Control dominio + verificación básica organización – 1-3 días.
• EV: Validación exhaustiva – 1-2 semanas.
• Wildcard: Es un tipo de alcance (*.dominio.com), no un nivel de validación (puede ser DV, OV o EV).

✅ Respuesta Correcta: C

Argumentación: Para mantener la persistencia de sesión (sticky sessions), se necesita que las peticiones del mismo usuario vayan siempre al mismo servidor backend. Esto se consigue con:

• IP Hash: Hash de la IP del cliente determina el servidor destino. Mismo cliente → misma IP → mismo servidor.
• Cookie-based persistence: El balanceador inserta una cookie que identifica el servidor asignado.

¿Por qué es necesario? Aplicaciones stateful que mantienen datos de sesión en memoria del servidor (carrito de compra, sesiones PHP sin sesiones compartidas, etc.) necesitan que el usuario vuelva al mismo servidor.

Justificación opciones incorrectas:

• A (Round Robin): Distribuye cíclicamente. El usuario puede ir a diferente servidor en cada petición → pierde sesión.
• B (Least Connections): Envía al servidor con menos carga. No garantiza persistencia.
• D (Random): Selección aleatoria. Sin persistencia.

Alternativa mejor: Usar sesiones compartidas (Redis, Memcached) o tokens JWT stateless → No necesitas sticky sessions.

✅ Respuesta Correcta: C

Argumentación: Diferencias clave entre tipos de proxy:

Un proxy inverso se sitúa en la DMZ, recibe peticiones de Internet y las redirige a servidores backend internos. Los clientes externos solo ven la IP del proxy, no de los servidores reales (protección + balanceo).

Justificación opciones incorrectas:

• A: Describe al revés. Forward proxy protege a los CLIENTES, no a los servidores.
• B: Describe forward proxy incorrectamente.
• D: Los proxies pueden manejar HTTPS mediante SSL/TLS termination o túnel SSL.

✅ Respuesta Correcta: B

Argumentación: IPsec utiliza el protocolo IKE (Internet Key Exchange) para negociar y establecer las claves de cifrado (Security Associations – SAs) antes de la transmisión de datos.

Puertos IPsec:

• UDP 500: IKE (IKEv1 o IKEv2) – Intercambio de claves y negociación de parámetros.
• UDP 4500: NAT-T (NAT Traversal) – IPsec encapsulado en UDP cuando hay NAT por el medio.
• Protocolo 50 (ESP): Encapsulating Security Payload – Datos cifrados (no es puerto, es protocolo IP).
• Protocolo 51 (AH): Authentication Header – Autenticación e integridad (poco usado).

Justificación opciones incorrectas:

• A (OpenVPN): Usa UDP/TCP 1194 por defecto (configurable).
• C (L2TP): Usa UDP 1701. Generalmente se combina con IPsec (L2TP/IPsec) para cifrado.
• D (WireGuard): Usa UDP 51820 por defecto.

✅ Respuesta Correcta: B

Argumentación: SFTP (SSH File Transfer Protocol) es la evolución segura de FTP. Sus ventajas principales son:

• ✅ Cifrado integral: TODO el tráfico (comandos, autenticación, datos) va cifrado mediante SSH.
• ✅ Un solo puerto: TCP 22 (vs. FTP que usa 21 + puertos dinámicos para datos → pesadilla de firewall).
• ✅ Autenticación robusta: Contraseña + claves públicas SSH.
• ✅ Integridad garantizada: Detección de manipulación de datos.

Comparativa:

Justificación opciones incorrectas:

• A: La velocidad es similar. La compresión SSH puede ayudar pero no es la ventaja principal.
• C: Los navegadores NO soportan SFTP nativamente (requieren cliente como FileZilla, WinSCP).
• D: Esas características dependen del cliente, no del protocolo en sí.

✅ Respuesta Correcta: B

Argumentación: HTTP es stateless (sin estado) significa que cada petición HTTP es completamente independiente. El servidor:

• ❌ NO recuerda quién eres
• ❌ NO recuerda qué hiciste antes
• ❌ NO mantiene contexto entre peticiones

Cada petición debe contener TODA la información necesaria para ser procesada (autenticación, parámetros, contexto).

¿Cómo mantenemos sesiones entonces?

• ✅ Cookies: El servidor envía un ID de sesión al cliente, que lo devuelve en cada petición.
• ✅ Tokens JWT: Token autónomo que contiene toda la información de sesión (firma criptográfica).
• ✅ Sesiones del lado del servidor: Cookie con ID → servidor busca datos en memoria/BD.

Ventajas de stateless:

• ✅ Escalabilidad: Cualquier servidor puede procesar cualquier petición (no hay «afinidad»).
• ✅ Simplicidad: No hay estado que sincronizar entre servidores.
• ✅ Fiabilidad: Si el servidor se reinicia, no se pierde estado (porque no lo había).

Justificación opciones incorrectas:

• A: HTTP/1.1 SÍ permite conexiones persistentes (Keep-Alive). Stateless se refiere a la APLICACIÓN, no a la conexión TCP.
• C: HTTP puede transmitir cualquier tipo de contenido (estático, dinámico, JSON, etc.).
• D: Absurdo. Los servidores web procesan millones de peticiones sin reiniciarse.

✅ Respuesta Correcta: B

Argumentación: Zero Trust es un cambio de paradigma en seguridad. El modelo tradicional («castillo y foso») asumía que todo dentro del perímetro era confiable. Ese modelo está roto (ataques internos, phishing, movilidad, cloud).

Principios fundamentales Zero Trust:

1. «Never trust, always verify»: Nunca confiar, siempre verificar. Cada acceso se autentica y autoriza explícitamente, sin importar el origen.
2. Least privilege access: Acceso mínimo necesario (JIT – Just In Time, JEA – Just Enough Access).
3. Assume breach: Asumir que hay un atacante dentro de la red. Microsegmentación y monitorización continua.

Implementación práctica:

• ✅ Identidad como perímetro: MFA obligatoria para todo (no solo VPN).
• ✅ Microsegmentación: Aislar cada aplicación/servicio (no confiar en VLAN).
• ✅ Acceso condicional: Evaluar contexto (ubicación, dispositivo, comportamiento) en cada acceso.
• ✅ Cifrado end-to-end: Incluso dentro de la red corporativa.
• ✅ Monitorización continua: Análisis de comportamiento (UEBA).

Justificación opciones incorrectas:

• A: Es lo OPUESTO a Zero Trust. Es el modelo tradicional (y vulnerable).
• C: VPN tradicional da acceso amplio una vez conectado. Zero Trust requiere autorización por recurso.
• D: El perímetro ha desaparecido (cloud, móvil, remoto). Zero Trust no depende del perímetro.

✅ Respuesta Correcta: B

Argumentación: Las PWA (Progressive Web Apps) son aplicaciones web que utilizan tecnologías modernas para comportarse como aplicaciones nativas.

Características clave de las PWA:

• ✅ Instalables: Se pueden «instalar» en el dispositivo (icono en escritorio/pantalla inicio).
• ✅ Funcionamiento offline: Mediante Service Workers que interceptan peticiones de red y sirven contenido cacheado.
• ✅ Notificaciones push: Alertas incluso con la app cerrada.
• ✅ Acceso a hardware: Cámara, GPS, sensores, bluetooth.
• ✅ Actualizaciones automáticas: Sin tiendas de aplicaciones.
• ✅ Responsive: Se adaptan a cualquier tamaño de pantalla.

Service Workers: Son scripts JavaScript que se ejecutan en segundo plano (separados de la página web) y permiten:

• Interceptar peticiones HTTP
• Cachear recursos (HTML, CSS, JS, imágenes, datos API)
• Servir contenido offline cuando no hay conexión
• Sincronización en background cuando se recupera conexión

Ejemplo SAS: ClicSalud+ como PWA permitiría a los pacientes consultar sus citas próximas, medicación actual y últimos informes incluso sin conexión (datos cacheados en última sincronización).

Justificación opciones incorrectas:

• A (WebSockets): Comunicación bidireccional en tiempo real (chat, notificaciones live). Requiere conexión activa.
• C (SPA): Aplicaciones de una sola página (React, Angular, Vue). No implica funcionamiento offline.
• D (SSE): Eventos del servidor al cliente (unidireccional). Requiere conexión.

✅ Respuesta Correcta: B

Argumentación: El RD 1112/2018, de 7 de septiembre, sobre accesibilidad de sitios web y aplicaciones para dispositivos móviles del sector público, establece como obligatorio el cumplimiento de las WCAG 2.1 nivel AA (Web Content Accessibility Guidelines).

WCAG 2.1 – Cuatro principios fundamentales (POUR):

1. Perceptible: La información debe ser presentada de forma que los usuarios puedan percibirla (alternativas textuales para imágenes, subtítulos para vídeos, contraste de color suficiente).
2. Operable: Los componentes de la interfaz deben ser operables (navegación por teclado, tiempo suficiente para leer, evitar contenido que provoque convulsiones).
3. Comprensible: La información y el manejo de la interfaz deben ser comprensibles (texto legible, comportamiento predecible, ayuda con errores).
4. Robusto: El contenido debe ser robusto para ser interpretado por diversos agentes de usuario, incluidas tecnologías de asistencia (marcado semántico HTML correcto).

Niveles de conformidad WCAG:

• Nivel A: Mínimo básico (esencial).
• Nivel AA: OBLIGATORIO para sector público (elimina barreras significativas).
• Nivel AAA: Máximo nivel (deseable pero no siempre alcanzable para todo el contenido).

Justificación opciones incorrectas:

• A: HTML5 incluye características de accesibilidad (elementos semánticos) pero no es un estándar de requisitos.
• C: WAI-ARIA es una especificación complementaria que añade semántica para aplicaciones dinámicas (roles, estados). Se usa JUNTO con WCAG, no en sustitución.
• D: Section 508 es la normativa de accesibilidad de EE.UU., no aplicable en España (aunque similar).

✅ Respuesta Correcta: B

Argumentación: La ventaja clave de GraphQL es que el cliente especifica exactamente qué datos necesita en su consulta (query), resolviendo dos problemas comunes de REST:

• ❌ Over-fetching: REST devuelve TODOS los campos del recurso aunque solo necesites unos pocos (desperdicio de ancho de banda).
• ❌ Under-fetching: REST requiere múltiples peticiones a diferentes endpoints para obtener datos relacionados (múltiples round-trips).

Ejemplo práctico:

REST (problema):

GET /api/pacientes/12345        # Devuelve TODO el paciente (50 campos)
GET /api/pacientes/12345/citas  # Segunda petición para citas
GET /api/medicos/789            # Tercera petición para médico de la cita

= 3 peticiones HTTP, mucho overhead

GraphQL (solución):

POST /graphql
{
  paciente(id: "12345") {
    nombre
    apellidos
    citas(limit: 5) {
      fecha
      medico {
        nombre
        especialidad
      }
    }
  }
}

= 1 petición HTTP, solo los campos necesarios

Otras ventajas GraphQL:

• ✅ Esquema fuertemente tipado (autodocumentación)
• ✅ Introspección (el cliente puede descubrir qué datos están disponibles)
• ✅ Evolución sin versiones (deprecar campos sin romper clientes)

Desventajas GraphQL:

• ❌ Mayor complejidad en el servidor (resolvers, N+1 problem)
• ❌ Dificulta caché HTTP estándar (todo va a un endpoint)
• ❌ Curva de aprendizaje más alta

Justificación opciones incorrectas:

• A: La seguridad es la misma (HTTPS). GraphQL no añade cifrado adicional.
• C: GraphQL usa JSON, no XML.
• D: GraphQL requiere una librería cliente (Apollo Client, Relay, URQL) o fetch manual con queries.

✅ Respuesta Correcta: A

Argumentación: La cabecera HSTS (HTTP Strict Transport Security) es una medida de seguridad que indica al navegador: «Durante X tiempo, conecta SIEMPRE a este dominio usando HTTPS, incluso si el usuario escribe http:// o hace clic en un enlace HTTP».

Sintaxis:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Donde:
- max-age=31536000: 1 año (en segundos) que el navegador debe recordar esta política
- includeSubDomains: Aplicar también a todos los subdominios
- preload: Solicitar inclusión en lista HSTS preload de navegadores

¿Por qué es importante?

Sin HSTS, un atacante podría hacer SSL stripping: interceptar la primera petición HTTP (antes de la redirección a HTTPS) y mantener la conexión en claro, robando credenciales.

Con HSTS:

1. Primera visita: Usuario accede a https://diraya.sas.junta-andalucia.es
2. Servidor responde con cabecera HSTS
3. Navegador guarda: «Durante 1 año, SOLO HTTPS para este dominio»
4. Visitas futuras: Incluso si usuario escribe http://diraya..., el navegador automáticamente lo cambia a https:// ANTES de hacer la petición (a nivel local, sin salir a la red)

HSTS Preload List: Google/Mozilla/Microsoft mantienen una lista de dominios con HSTS que viene integrada en los navegadores. Protección desde la primera visita.

Justificación opciones incorrectas:

• B: El timeout de sesión se gestiona del lado del servidor (cookies con expires/max-age, sesiones server-side).
• C: La compresión se gestiona con Content-Encoding: gzip.
• D: Los métodos permitidos se indican con Allow: o mediante configuración del servidor.

✅ Respuesta Correcta: B

Argumentación: OAuth 2.0 es un framework de autorización (no autenticación) que permite a una aplicación (cliente) acceder a recursos protegidos en nombre del usuario, sin que el usuario comparta sus credenciales con la aplicación.

Flujo típico (Authorization Code):

1. Usuario: «Aplicación X, quiero que accedas a mis datos en Servicio Y»
2. Aplicación X redirige al usuario a Servicio Y (servidor de autorización)
3. Usuario se autentica en Servicio Y y autoriza el acceso
4. Servicio Y devuelve un authorization code a Aplicación X
5. Aplicación X intercambia el code por un access token
6. Aplicación X usa el access token para acceder a la API de Servicio Y

Ventajas:

• ✅ La aplicación NUNCA ve la contraseña del usuario
• ✅ El usuario puede revocar el acceso en cualquier momento
• ✅ Los tokens tienen permisos limitados (scopes) y caducan
• ✅ Estándar ampliamente adoptado (Google, Facebook, Microsoft, GitHub…)

Tipos de tokens OAuth 2.0:

• Access Token: Token de corta duración para acceder a la API (ej. 1 hora).
• Refresh Token: Token de larga duración para obtener nuevos access tokens sin reautenticar (ej. 30 días).

Ejemplo uso SAS: Una aplicación móvil de terceros (autorizada por el SAS) que permite a los pacientes consultar sus citas. Usa OAuth 2.0 para acceder a la API de ClicSalud+ sin que el paciente comparta su contraseña con la app.

Justificación opciones incorrectas:

• A (SAML 2.0): Protocolo de autenticación (SSO) basado en XML. Para identidad federada, no delegación de acceso a APIs.
• C (Kerberos): Protocolo de autenticación de red (ticket-based). Usado en Active Directory, no para APIs web.
• D (LDAP): Protocolo de acceso a directorios (tipo agenda corporativa). No es de autorización.

✅ Respuesta Correcta: C

Argumentación: 5G NO incluye cifrado cuántico nativo. 5G usa cifrado convencional (AES-256, etc.), igual que 4G pero mejorado. El cifrado cuántico (QKD – Quantum Key Distribution) es una tecnología separada, aún en fase experimental y no parte del estándar 5G.

Ventajas reales de 5G en sanidad:

Casos de uso 5G en el SAS (futuro próximo):

• 📡 Ambulancias 5G: Transmisión ECG/constantes en tiempo real al hospital, diagnóstico previo a llegada
• 🏥 Quirófanos conectados: Cirugía asistida por IA con procesamiento en edge computing
• 🩺 Telemedicina avanzada: Consultas con calidad 4K, examen físico remoto con sensores
• 🔬 IoMT masivo: Miles de sensores/wearables en tiempo real sin saturar la red

Justificación opciones incorrectas:

• A, B, D: Son ventajas reales y documentadas de 5G.

✅ Respuesta Correcta: B

Argumentación: Edge Computing es un paradigma que acerca el procesamiento y almacenamiento de datos al «borde» de la red, lo más cerca posible del punto donde se generan los datos, en lugar de enviarlos a un datacenter centralizado o a la nube.

Arquitectura tradicional vs Edge:

TRADICIONAL (Cloud-Centric):
Dispositivo IoT → Internet → Nube (AWS/Azure) → Procesamiento → Respuesta
                    ↑
              Alta latencia (50-200ms)
              Todo por Internet (ancho de banda, privacidad)

EDGE COMPUTING:
Dispositivo IoT → Edge Server (local) → Procesamiento inmediato
                    ↓
              Baja latencia (1-10ms)
              Solo resultados a la nube (si es necesario)

Ventajas en entornos sanitarios:

• ✅ Latencia ultra-baja: Crítico para monitorización UCI en tiempo real, detección de arritmias, alertas inmediatas
• ✅ Privacidad mejorada: Datos sensibles (imágenes médicas, constantes) procesados localmente sin salir del hospital
• ✅ Reducción ancho de banda: Solo se envía información procesada/agregada a la nube, no datos brutos
• ✅ Funcionamiento offline: Servicios críticos siguen operativos sin conexión al CPD central
• ✅ Cumplimiento RGPD: Minimización de transferencias de datos personales de salud

Casos de uso SAS:

• 🏥 UCI inteligente: Edge servers procesan datos de 50 monitores simultáneos, IA detecta patrones anómalos en tiempo real (no hay latencia para enviar a nube y recibir respuesta)
• 🔬 Análisis de imagen local: IA pre-procesa radiografías en el propio hospital, detecta hallazgos urgentes, solo envía resultados + imagen a PACS central
• 🚑 Ambulancias: Edge computing en ambulancia procesa telemetría, ECG, envía solo diagnóstico pre-procesado (menos datos, mejor privacidad)

Justificación opciones incorrectas:

• A: Es lo opuesto. Cloud centralizado es el modelo tradicional que Edge busca complementar.
• C: No tiene nada que ver con cifrado.
• D: Describe geo-balancing, no Edge Computing.

✅ Respuesta Correcta: B

Argumentación: WebAssembly (abreviado WASM) es un formato de código binario portable que permite ejecutar en el navegador código compilado desde lenguajes de bajo nivel (C, C++, Rust, Go…) con rendimiento cercano al código nativo.

¿Cómo funciona?

1. Desarrollas en C/C++/Rust (ej. algoritmo intensivo de procesamiento)
2. Compilas a WASM usando herramientas como Emscripten, wasm-pack
3. Obtienes un archivo .wasm (binario optimizado)
4. Lo cargas en tu página web junto con JavaScript
5. JavaScript invoca funciones WASM cuando necesita alto rendimiento
6. WASM se ejecuta en una sandbox segura del navegador

Características clave:

• ✅ Rendimiento: 80-90% de velocidad de código nativo (vs. JavaScript interpretado)
• ✅ Portabilidad: Funciona en todos los navegadores modernos (Chrome, Firefox, Safari, Edge)
• ✅ Seguridad: Ejecuta en sandbox, sin acceso directo al sistema
• ✅ Complementario a JavaScript: No lo reemplaza, trabajan juntos
• ✅ Tamaño reducido: Binario compacto, descarga rápida

Casos de uso en sanidad (SAS):

• 🩻 Procesamiento de imágenes DICOM en navegador: Filtros, mejora de contraste, reconstrucciones 3D sin enviar datos al servidor (privacidad)
• 📊 Análisis de datos clínicos: Algoritmos estadísticos complejos ejecutados localmente
• 🧬 Visualización genómica: Renderizado de genomas completos en el navegador
• 🎮 Simulaciones médicas: Entrenamiento quirúrgico virtual (física realista en tiempo real)

Ejemplo código:

// C++ compilado a WASM
int procesar_imagen(uint8_t* imagen, int width, int height) {
    // Algoritmo intensivo de procesamiento
    for (int i = 0; i < width * height; i++) {
        imagen[i] = filtro_complejo(imagen[i]);
    }
    return 0;
}

// JavaScript carga y usa WASM
WebAssembly.instantiateStreaming(fetch('imagen.wasm'))
    .then(obj => {
        obj.instance.exports.procesar_imagen(imagenArray, 1920, 1080);
    });

Justificación opciones incorrectas:

• A: WASM no es un lenguaje de programación. Es un formato binario objetivo (target) de compilación.
• C: No es una librería de animación (eso sería GSAP, Anime.js, etc.).
• D: No tiene relación con Web Components.

✅ Respuesta Correcta: C

Argumentación: Los cipher suites (conjuntos de cifrado) son combinaciones de algoritmos criptográficos que TLS usa para el cifrado, autenticación y hash. Esta configuración es específica de TLS y no existe en HTTP sin cifrar.

Componentes de un cipher suite:

Ejemplo: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
         ↓     ↓    ↓         ↓       ↓     ↓
         TLS + Key  + Auth  + Cifrado + Hash
               Exchange

- ECDHE: Elliptic Curve Diffie-Hellman Ephemeral (intercambio de claves)
- RSA: Autenticación del servidor
- AES_256_GCM: Cifrado simétrico (AES 256 bits, modo GCM)
- SHA384: Función hash para integridad

Configuración segura TLS (ENS MEDIO/ALTO):

✅ Cipher suites recomendados (2025):

• TLS_AES_256_GCM_SHA384 (TLS 1.3)
• TLS_CHACHA20_POLY1305_SHA256 (TLS 1.3)
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (TLS 1.2)

❌ Cipher suites a DESHABILITAR:

• ❌ Cualquiera con RC4 (roto hace años)
• ❌ Cualquiera con 3DES (débil, 64 bits efectivos)
• ❌ Cualquiera con CBC en TLS 1.0/1.1 (vulnerable a BEAST, POODLE)
• ❌ Cualquiera sin ECDHE o DHE (no tiene Perfect Forward Secrecy)
• ❌ Cualquiera con MD5 o SHA1 (hash débil)

Perfect Forward Secrecy (PFS):

Los cipher suites con ECDHE o DHE proporcionan PFS: incluso si la clave privada del servidor se compromete en el futuro, las sesiones pasadas NO pueden ser descifradas (cada sesión usa claves únicas efímeras).

Justificación opciones incorrectas:

• A (Validación de entrada): Es una medida de seguridad de aplicación, aplicable a HTTP y HTTPS por igual.
• B (CORS): Mecanismo de seguridad del navegador, independiente de si usas HTTP o HTTPS.
• D (Sanitización XSS): Medida de aplicación, no específica de TLS.

✅ Respuesta Correcta: C

Argumentación: El campo SAN (Subject Alternative Name) en un certificado X.509 permite especificar dominios adicionales que están cubiertos por el mismo certificado.

Ejemplo práctico:

Certificado para:
CN (Common Name): diraya.sas.junta-andalucia.es

SAN (Subject Alternative Names):
- diraya.sas.junta-andalucia.es (repetición del CN)
- www.diraya.sas.junta-andalucia.es
- diraya-test.sas.junta-andalucia.es
- diraya-pre.sas.junta-andalucia.es

Con este certificado, puedes proteger los 4 dominios.

Evolución histórica:

• Antes: Solo el CN (Common Name) identificaba el dominio. Un certificado = un dominio.
• Ahora: Los navegadores modernos ignoran el CN y solo miran el SAN. Incluso para un solo dominio, DEBE estar en SAN.

Tipos de certificados según alcance:

Limitación Wildcard: *.sas.junta-andalucia.es cubre diraya.sas.junta-andalucia.es pero NO test.diraya.sas.junta-andalucia.es (2 niveles de subdominio). Para eso necesitas SAN específico o wildcard de 2º nivel.

Justificación opciones incorrectas:

• A (CN – Common Name): Era el campo principal para identificar el dominio, pero ahora está deprecated. Los navegadores solo miran SAN.
• B (Issuer): Identifica la CA (Autoridad Certificadora) que emitió el certificado, no los dominios cubiertos.
• D (Serial Number): Número único del certificado asignado por la CA, usado para identificación y revocación.

✅ Respuesta Correcta: B

Argumentación: ICANN (Internet Corporation for Assigned Names and Numbers) es la organización sin ánimo de lucro responsable de coordinar los identificadores únicos de Internet a nivel global.

Responsabilidades de ICANN:

• ✅ Gestión de TLDs: Aprueba y gestiona dominios de nivel superior genéricos (.com, .org, .net) y de países (.es, .fr, .uk)
• ✅ Coordinación de direcciones IP: Delega en RIRs (Regional Internet Registries) como RIPE NCC (Europa)
• ✅ Gestión de números de puerto y parámetros de protocolos: A través de IANA (Internet Assigned Numbers Authority), función que ICANN opera
• ✅ Coordinación del sistema DNS raíz: Gestiona los 13 servidores raíz de DNS

Estructura jerárquica:

ICANN (Coordinación global)
  ├── IANA (Asignación de números, puertos, TLDs)
  ├── RIRs (Registros Regionales de Internet)
  │    ├── RIPE NCC (Europa, Oriente Medio)
  │    ├── ARIN (América del Norte)
  │    ├── APNIC (Asia-Pacífico)
  │    ├── LACNIC (Latinoamérica, Caribe)
  │    └── AFRINIC (África)
  └── Registradores de dominios (GoDaddy, Namecheap, dondominio, etc.)

Justificación opciones incorrectas:

• A (W3C): Desarrolla estándares web (HTML, CSS, WCAG accesibilidad), NO gestiona direcciones IP ni dominios.
• C (IETF): Desarrolla estándares técnicos de Internet (RFC – Request for Comments), como TCP/IP, HTTP, TLS. Define CÓMO funcionan los protocolos, pero no asigna recursos.
• D (IEEE): Organización de ingeniería eléctrica que define estándares de redes físicas (Ethernet 802.3, WiFi 802.11), NO de Internet global.

Resumen rápido para el examen:

✅ Respuesta Correcta: B

Argumentación: El NIST (National Institute of Standards and Technology) de EE.UU. finalizó en 2024 la estandarización de los primeros algoritmos de criptografía post-cuántica, diseñados para resistir ataques de ordenadores cuánticos futuros.

¿Por qué es necesaria la criptografía post-cuántica?

Los ordenadores cuánticos suficientemente potentes podrán ejecutar el algoritmo de Shor, que rompe:

• ❌ RSA: Cifrado asimétrico usado en TLS, certificados, VPN
• ❌ ECC (Elliptic Curve Cryptography): Alternativa moderna a RSA, también vulnerable
• ❌ Diffie-Hellman: Intercambio de claves

⚠️ Aunque los ordenadores cuánticos útiles están a años de distancia, el peligro es AHORA:

«Harvest now, decrypt later»: Atacantes pueden capturar tráfico cifrado HOY y guardarlo para descifrarlo en el futuro cuando tengan ordenadores cuánticos. Datos

de salud cifrados hoy (comunicaciones médicas, historias clínicas) podrían ser desci frados en 10-15 años cuando existan ordenadores cuánticos potentes.

Algoritmos post-cuánticos estandarizados por NIST (2024):

• CRYSTALS-Kyber: Encapsulación de claves (KEM – Key Encapsulation Mechanism) para establecer claves simétricas de sesión de forma segura.
• CRYSTALS-Dilithium: Firma digital resistente a ataques cuánticos.
• SPHINCS+: Firma digital alternativa (basada en hash, más lenta pero muy conservadora).
• FALCON: Firma digital (alternativa más rápida pero mayor complejidad de implementación).

Estado actual (2025):

• ⏳ Ordenadores cuánticos útiles: Estimados para 2035-2040 (optimista).
• ✅ Algoritmos post-cuánticos: Ya estandarizados y disponibles para implementar.
• 📅 Migración recomendada: Comenzar pruebas piloto en 2025-2026, migración completa antes de 2030.

Relevancia para el SAS:

El SAS debe comenzar a planificar la migración a criptografía post-cuántica en sistemas críticos (cifrado de datos de salud en reposo, comunicaciones médicas críticas, firma electrónica de recetas). La información de salud tiene valor durante décadas, por lo que el riesgo «harvest now, decrypt later» es real y significativo.

Justificación opciones incorrectas:

• A: Los ordenadores cuánticos actuales (2025) son prototipos experimentales con ~100-1000 qubits ruidosos. No pueden romper RSA/ECC todavía. Se necesitan millones de qubits estables.
• C: TLS 1.3 usa criptografía convencional (RSA, ECC). NO incluye algoritmos post-cuánticos (aunque se están desarrollando extensiones experimentales).
• D: La criptografía post-cuántica afecta a TODOS los sectores que manejan datos sensibles de larga vida, especialmente sanidad (datos de salud protegidos durante décadas por RGPD).

✅ Respuesta Correcta: C

Argumentación: Para transferir datos sensibles de salud entre hospitales del SAS, la solución que cumple todos los requisitos es SFTP con autenticación por clave pública.

¿Por qué SFTP es la solución óptima?

Implementación práctica en el SAS:

# Hospital A genera par de claves SSH
ssh-keygen -t ed25519 -C "hospital-virgen-rocio-dicom"

# Clave pública se instala en Hospital B (servidor SFTP)
# Hospital A puede transferir sin contraseñas:
sftp -C usuario@sftp.hospital-b.sas.es
> put imagen-tc-123456.dcm
> bye

# Verificación automática de integridad:
sha256sum imagen-tc-123456.dcm > checksum.txt
sftp> put checksum.txt

# Hospital B verifica integridad al recibir:
sha256sum -c checksum.txt

Ventajas adicionales SFTP:

• ✅ Automatización: Scripts pueden transferir imágenes automáticamente (sin intervención humana).
• ✅ Reanudación: Transferencias interrumpidas pueden reanudarse (crítico con archivos de GB).
• ✅ Permisos Unix: Control granular de acceso a carpetas/archivos.
• ✅ Compatible: Todos los sistemas operativos (Windows, Linux, macOS) tienen clientes SFTP.

Justificación opciones incorrectas:

• A (FTP sin cifrado): ❌❌❌ COMPLETAMENTE INACEPTABLE. Viola ENS (datos en claro), RGPD (Art. 32 requiere cifrado), y expone datos de salud sensibles. Credenciales y archivos DICOM viajarían sin cifrar por Internet. Prohibido en cualquier entorno sanitario.
• B (Email con ZIP+contraseña): ❌ Múltiples problemas:
  • Límites de tamaño de adjuntos (imágenes DICOM pueden ser varios GB).
  • Contraseña del ZIP suele enviarse por canal inseguro (teléfono, otro email).
  • Sin integridad verificable.
  • Archivos quedan en servidores de email (multiplicación de copias → riesgo RGPD).
• D (Dropbox público con contraseña): ❌❌ Inaceptable por múltiples razones:
  • Datos de salud en cloud de terceros fuera de UE (Dropbox es estadounidense) → violación RGPD Art. 44-49.
  • Sin acuerdo de encargado de tratamiento adecuado para sanidad.
  • Enlace público es un riesgo (puede filtrarse, compartirse accidentalmente).
  • No cumple ENS (pérdida de control de los datos).

Referencia al caso práctico real del tema: Este es exactamente el caso práctico 7.4 del tema («Transferencia Segura de Imágenes DICOM Entre Hospitales»), donde se describe la solución implementada con SFTP en el SAS.