1. INTRODUCCIÓN

Los servicios de acceso a la información basados en Internet constituyen la capa visible de una cadena técnica mucho más amplia. Cuando una persona consulta un portal, una aplicación móvil recupera una cita, un profesional accede a una aplicación corporativa o dos sistemas intercambian información, intervienen mecanismos de identificación del recurso, resolución de nombres, encaminamiento, transporte, seguridad criptográfica, control de acceso, publicación de contenidos y operación continua. El objetivo del tema no es memorizar una colección de siglas, sino comprender cómo se encadenan y qué responsabilidad asume cada agente.

Internet es una interconexión de redes autónomas que cooperan mediante protocolos abiertos. La Web es uno de sus servicios y utiliza las semánticas de HTTP para solicitar representaciones de recursos identificados mediante URI. Alrededor de ese núcleo aparecen DNS, sistemas de búsqueda, API, servicios web, redes de distribución de contenidos, proxies, balanceadores, autoridades de certificación, proveedores de identidad y operadores de telecomunicaciones. La calidad del acceso depende tanto de la conectividad como de la capacidad de localizar el recurso correcto, autenticar a las partes, autorizar la operación y mantener el servicio disponible.

En una organización sanitaria, el acceso a la información debe conjugar objetivos que a veces entran en tensión. La asistencia exige disponibilidad y tiempos de respuesta previsibles; la protección de datos exige confidencialidad, integridad, trazabilidad y minimización; la interoperabilidad exige estándares y contratos estables; y la seguridad operacional exige segmentación, autenticación robusta, actualización y monitorización. La solución correcta rara vez consiste en un único producto. Es una arquitectura por capas, gobernada mediante políticas y controles verificables.

Este tema se relaciona directamente con la arquitectura TCP/IP, la seguridad en redes, el Esquema Nacional de Seguridad, la identificación electrónica, la interoperabilidad, el desarrollo web y los portales corporativos. En el examen suelen aparecer distinciones muy concretas: TCP frente a UDP, HTTP frente a HTTPS, cifrado simétrico frente a asimétrico, autenticación frente a autorización, proxy directo frente a proxy inverso, FTP frente a FTPS y SFTP, o HTTP/2 frente a HTTP/3. Dominar esas fronteras conceptuales permite resolver preguntas aunque cambie el escenario.

2. AGENTES QUE INTERVIENEN EN EL ACCESO A LA INFORMACIÓN

2.1. Cliente, usuario y aplicación

El primer agente es quien necesita la información: una persona que utiliza un navegador, una aplicación móvil, un sistema corporativo, un dispositivo médico o un proceso automatizado. El cliente construye la solicitud, selecciona el protocolo, verifica la identidad del servicio y presenta la respuesta. En un navegador, además, se aplican el modelo de mismo origen, CORS, políticas de contenido, cookies y aislamiento. En un cliente servidor-a-servidor, esas protecciones del navegador no existen y deben sustituirse por validación explícita, autenticación de carga de trabajo, límites y controles de salida.

El usuario no debe confundirse con el cliente. Una aplicación puede actuar por cuenta de una persona, con identidad propia o combinando ambas. Esta distinción aparece en OAuth 2.0: el cliente solicita autorización para acceder a un recurso, pero no es necesariamente el propietario de los datos. En servicios corporativos resulta esencial registrar quién inició la acción, qué aplicación la ejecutó y con qué alcance.

2.2. Proveedores de acceso y operadores

Los proveedores de acceso conectan hogares, dispositivos y sedes mediante fibra, cable, radio, redes móviles, enlaces dedicados o satélite. Operan redes con sus propios prefijos y políticas, mantienen puntos de presencia, agregan tráfico y contratan o intercambian conectividad con otras redes. La calidad percibida depende de la última milla, la congestión, el encaminamiento, la resolución DNS y la proximidad del contenido, no solo de la velocidad nominal contratada.

La clasificación Tier se utiliza como simplificación comercial para describir relaciones de tránsito y peering. Una red denominada Tier 1 alcanza el conjunto de Internet sin comprar tránsito, mediante peering con otras redes equivalentes. Una red Tier 2 combina tránsito comprado y peering, y una Tier 3 se orienta principalmente al acceso final. No es una certificación oficial ni una medida directa de seguridad, disponibilidad o rendimiento. Para un examen importa el criterio económico y de interconexión, no memorizar una lista de empresas que puede cambiar.

2.3. Sistemas autónomos e IXP

Un sistema autónomo agrupa redes IP bajo una política de encaminamiento común y se identifica mediante un ASN. Los registros regionales de Internet asignan recursos numéricos en sus regiones conforme a políticas comunitarias. En Europa, Oriente Medio y parte de Asia Central, esa función corresponde a RIPE NCC. Los sistemas autónomos anuncian prefijos y rutas mediante BGP, aplicando relaciones de cliente, proveedor y peering.

Un IXP proporciona infraestructura para que múltiples redes intercambien tráfico de forma directa. Normalmente ofrece una plataforma de conmutación y servicios auxiliares, pero cada participante conserva su política BGP. El IXP no es un ISP, no asigna por sí mismo todos los recursos de Internet y no garantiza que cualquier participante intercambie tráfico con todos los demás. Los acuerdos de peering siguen siendo decisiones de las redes.

2.4. Proveedores de contenido, alojamiento y nube

El proveedor de contenido define los recursos y su política de publicación. Puede operar infraestructura propia, contratar alojamiento, utilizar nube pública o combinar entornos. El proveedor de nube aporta capacidad de cómputo, red, almacenamiento y servicios gestionados, pero la responsabilidad se reparte: el proveedor asegura la infraestructura según el servicio contratado y el cliente configura identidades, datos, aplicaciones y redes dentro de su ámbito.

Las CDN acercan contenido o ejecución a puntos de presencia distribuidos. El servidor de origen conserva la versión autoritativa, mientras los nodos de borde atienden solicitudes según reglas de caché y enrutamiento. Una CDN puede aportar protección DDoS, terminación TLS y optimización, pero no debe considerarse automáticamente autorizada para almacenar cualquier dato. La clasificación de la información, el contrato y la configuración determinan qué respuestas pueden salir del origen.

2.5. DNS, registradores y gobernanza de nombres

El titular de un dominio lo contrata a través de un registrador acreditado. El registro mantiene la base correspondiente al dominio de nivel superior y la zona delega servidores autoritativos. Los resolutores recursivos consultan la jerarquía en nombre de los clientes y conservan respuestas en caché. Es importante distinguir titular, registrador, registro, servidor autoritativo y resolutor: todos intervienen en DNS, pero cumplen funciones diferentes.

2.6. Autoridades de certificación y confianza

Las autoridades de certificación emiten certificados tras validar control del dominio y, según el tipo, datos organizativos. Los sistemas operativos, navegadores y aplicaciones mantienen almacenes de confianza. El servidor presenta su certificado y las intermedias; el cliente verifica cadena, nombre, vigencia, algoritmos y restricciones. La confianza no depende de que el certificado “parezca oficial”, sino de una cadena válida hasta una raíz aceptada por la política del cliente.

2.7. Proveedores de identidad y autorización

Un proveedor de identidad autentica usuarios o cargas de trabajo y emite aserciones o tokens. Los servicios consumen esa evidencia y aplican sus propias reglas de autorización. En una federación, el proveedor de servicio delega parte del proceso de identidad, pero conserva responsabilidad sobre los permisos que concede. La centralización facilita MFA, baja y auditoría, aunque convierte al proveedor de identidad en una dependencia crítica.

2.8. Organismos de normalización y coordinación

3. CARACTERÍSTICAS Y ESTRUCTURA DE LAS REDES SOPORTE

3.1. Infraestructura física y lógica

La red soporte incluye medios físicos, equipos, enlaces, protocolos y políticas. La fibra ofrece gran capacidad y baja atenuación; los enlaces radio aportan movilidad; el satélite cubre zonas remotas con latencia condicionada por la órbita. Sobre esos medios se construyen Ethernet, redes móviles, MPLS, IP y túneles. El usuario observa una única conexión, pero el tráfico atraviesa múltiples dominios con tecnologías y responsabilidades diferentes.

La topología física indica cómo están conectados los equipos; la lógica describe cómo circula el tráfico y se segmentan los dominios. Internet no es una malla completa. Combina redes jerárquicas, mallas parciales, enlaces privados, puntos de intercambio y rutas alternativas. En una organización, el diseño suele separar acceso, distribución o agregación y núcleo, aunque arquitecturas de centro de datos modernas pueden utilizar diseños leaf-spine.

3.2. Red de acceso y última milla

La última milla conecta al usuario o sede con el operador. Puede ser FTTH, Ethernet metropolitana, radioenlace, 4G/5G, Wi-Fi o acceso satelital. Su capacidad, cobertura y compartición influyen en la experiencia. Una sede crítica puede contratar enlaces de operadores distintos y rutas físicas diversificadas; contratar dos circuitos que comparten canalización o central no elimina el punto único de fallo.

La red local añade conmutación, VLAN, control de acceso, direccionamiento y salida. La conectividad Wi-Fi requiere autenticación, cifrado, planificación radio y separación de redes. Los dispositivos de invitados o personales no deben compartir implícitamente el mismo dominio de confianza que puestos corporativos o equipos asistenciales.

3.3. Agregación, núcleo y tránsito entre redes

La agregación concentra accesos y aplica políticas. El núcleo transporta grandes volúmenes con alta disponibilidad y convergencia rápida. Entre redes autónomas, BGP intercambia prefijos y atributos. Dentro de una red, protocolos como OSPF o IS-IS calculan rutas según la topología interna. La frontera entre IGP y BGP es una distinción clásica: uno distribuye rutas dentro del dominio; el otro intercambia alcanzabilidad y política entre dominios.

BGP es un protocolo de vector de camino. La selección considera preferencia local, longitud de AS-PATH, origen, MED y reglas del operador. No debe describirse como un algoritmo que siempre elige la menor latencia. La política comercial puede preferir una ruta más larga. La seguridad del encaminamiento exige filtros, límites de prefijos, validación de origen mediante RPKI y coordinación operativa.

3.4. Direccionamiento, NAT e IPv6

IPv4 utiliza direcciones de 32 bits y su escasez impulsó el uso de NAT. NAT traduce direcciones y, en su variante con puertos, permite compartir una dirección pública. No constituye por sí mismo un cortafuegos ni aporta autenticación. IPv6 utiliza 128 bits, facilita direccionamiento extremo a extremo y elimina la necesidad estructural de NAT por escasez, pero requiere las mismas políticas de filtrado, segmentación y monitorización.

La coexistencia dual-stack obliga a proteger ambos protocolos. Un servicio correctamente filtrado en IPv4 puede quedar expuesto por IPv6 si las reglas no son equivalentes. Los túneles automáticos y mecanismos de transición deben inventariarse porque introducen caminos que pueden escapar a la inspección prevista.

4. LOCALIZACIÓN Y DESCUBRIMIENTO DE RECURSOS

4.1. URI, URL y nombres de dominio

El acceso comienza identificando el recurso. Una URI es un identificador uniforme; una URL es una URI que, además de identificar, expresa un mecanismo de localización. En una URL como https://portal.ejemplo.es:443/ruta?x=1#apartado, el esquema es https, la autoridad contiene el nombre del host y, opcionalmente, el puerto, la ruta selecciona el recurso, la consulta aporta parámetros y el fragmento identifica una parte de la representación en el cliente. El nombre de dominio no es la dirección IP: es una referencia estable que DNS traduce a información útil para alcanzar el servicio.

La separación entre nombre y dirección permite cambiar servidores, distribuir tráfico o utilizar varias direcciones sin modificar los enlaces publicados. También permite delegar zonas DNS y administrar nombres de forma jerárquica. La zona raíz delega dominios de nivel superior; estos delegan dominios inferiores; y cada zona publica registros de recurso. La resolución puede ser recursiva, cuando un resolutor obtiene la respuesta completa para el cliente, o iterativa, cuando recibe referencias sucesivas.

4.2. Registros DNS esenciales

4.3. Transporte de DNS, caché y seguridad

DNS utiliza el puerto 53 tanto sobre UDP como sobre TCP. UDP es habitual para consultas y respuestas ordinarias. TCP se emplea en transferencias de zona y debe estar disponible como mecanismo de recuperación cuando una respuesta no puede transportarse adecuadamente por UDP. El límite histórico de 512 octetos se amplió con EDNS(0), por lo que no debe memorizarse la regla simplista de que toda respuesta superior a 512 octetos usa necesariamente TCP. La fragmentación, los cortafuegos y la política del resolutor también influyen.

La caché reduce latencia y carga. Cada registro tiene un TTL que indica cuánto tiempo puede conservarse. Un TTL bajo facilita cambios rápidos, pero aumenta consultas; uno alto mejora eficiencia, pero prolonga datos obsoletos. La caché negativa conserva temporalmente la inexistencia de un nombre. En operación, los cambios deben planificarse reduciendo el TTL con antelación y verificando la delegación, la firma DNSSEC y la propagación.

DNSSEC aporta autenticidad e integridad a los datos DNS mediante una cadena de confianza, pero no cifra las consultas. La privacidad del transporte puede mejorarse con DNS sobre TLS, DNS sobre HTTPS o DNS sobre QUIC. Estas técnicas no eliminan la necesidad de confiar en el resolutor y pueden interferir con políticas corporativas si cada aplicación selecciona resolutores externos al margen de la organización.

4.4. Buscadores, directorios y metadatos

No todo acceso se inicia conociendo una URL. Los buscadores rastrean recursos, extraen contenido, construyen índices y ordenan resultados. En intranets y portales corporativos, la localización depende además de metadatos, taxonomías, permisos y calidad editorial. El buscador debe respetar el control de acceso: indexar un documento no debe convertirlo en visible para quien no está autorizado. En información sanitaria y administrativa, la minimización y la prevención de fugas en fragmentos de resultados son requisitos de diseño.

5. MODELO DE ACCESO WEB Y SEMÁNTICA HTTP

5.1. Modelo petición-respuesta

HTTP es un protocolo de aplicación sin estado para sistemas distribuidos. Un cliente envía una solicitud formada por método, objetivo, versión o contexto de protocolo, cabeceras y, opcionalmente, cuerpo. El servidor responde con un código de estado, cabeceras y una representación. La semántica común está definida independientemente de la versión de transporte, por lo que GET, códigos y cabeceras conservan su significado en HTTP/1.1, HTTP/2 y HTTP/3.

HTTP no cifra por sí mismo. El esquema http suele utilizar el puerto 80 y el esquema https el 443, aunque una URI puede indicar otro puerto. HTTPS añade TLS y autentica normalmente al servidor. La elección del puerto es una convención y un punto de escucha; no convierte por sí sola una conexión en segura. Un servidor que escuche en 443 sin TLS no ofrece HTTPS.

GET /api/citas?fecha=2026-08-04 HTTP/1.1
Host: portal.ejemplo.es
Accept: application/json
Authorization: Bearer <token>

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

El ejemplo muestra la estructura, no recomienda colocar datos sensibles en la consulta. Los parámetros de URL pueden aparecer en historiales, proxies y registros. Cuando una operación maneja identificadores o filtros sensibles, el diseño debe minimizar exposición, proteger registros y valorar cuerpos o identificadores opacos según la semántica.

5.2. Semántica de métodos

HTTP separa la semántica de la representación. GET recupera una representación y se considera seguro e idempotente; HEAD obtiene las mismas cabeceras sin cuerpo; POST solicita que el servidor procese la representación enviada; PUT crea o reemplaza el estado del recurso identificado y es idempotente; PATCH aplica una modificación parcial conforme al formato de parche; DELETE solicita eliminar la asociación actual. Seguridad e idempotencia son propiedades semánticas, no garantías de que una implementación defectuosa carezca de efectos secundarios.

5.3. Códigos de estado y cabeceras

Los códigos se agrupan por clases: 1xx informativos, 2xx éxito, 3xx redirección, 4xx error atribuible a la solicitud y 5xx fallo del servidor o de un intermediario. Conviene distinguir 200 OK, 201 Created, 204 No Content, 301 Moved Permanently, 302 Found, 304 Not Modified, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 429 Too Many Requests, 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable y 504 Gateway Timeout. El nombre histórico 401 puede inducir a error: normalmente indica ausencia o invalidez de autenticación, mientras que 403 implica que el servidor comprende la identidad o solicitud pero rechaza el acceso.

Las cabeceras expresan negociación de contenido, caché, autenticación, cookies, compresión, origen y seguridad. Content-Type describe el formato del cuerpo; Accept expresa formatos aceptables; Authorization porta credenciales o tokens; Cache-Control gobierna almacenamiento; ETag identifica una versión; If-None-Match permite revalidar; Location señala un recurso creado o una redirección. El diseño correcto evita colocar secretos en la URL, porque rutas y consultas aparecen con frecuencia en historiales, registros y sistemas intermedios.

5.4. Estado, cookies y caché

HTTP es un protocolo sin estado en el sentido de que cada solicitud contiene la información necesaria para interpretarla. Las aplicaciones pueden mantener estado mediante cookies, tokens, almacenamiento del cliente o sesiones en el servidor. Una cookie de sesión no contradice la naturaleza de HTTP: es un mecanismo añadido por la aplicación. Las cookies sensibles deben usar Secure, HttpOnly y una política SameSite adecuada. Los identificadores de sesión deben ser impredecibles, rotarse tras autenticar y revocarse al cerrar sesión o detectar riesgo.

6. EVOLUCIÓN DE HTTP Y RENDIMIENTO

6.1. HTTP/1.1: persistencia y limitaciones

HTTP/1.1 introdujo conexiones persistentes por defecto, de modo que varias solicitudes pueden reutilizar una conexión TCP. La idea de una conexión por objeto corresponde más a patrones antiguos y no debe usarse como definición. El protocolo permite pipelining, pero su implantación fue limitada porque las respuestas deben mantenerse en orden y una respuesta lenta puede retrasar las siguientes. Los navegadores compensaron abriendo varias conexiones por origen, con coste de handshakes, congestión y recursos.

6.2. HTTP/2: tramas, flujos y HPACK

HTTP/2 conserva la semántica de HTTP y cambia la forma de transportar mensajes. Utiliza una capa binaria de tramas, identifica flujos independientes, multiplexa solicitudes y respuestas en una conexión y comprime cabeceras con HPACK. También incorpora control de flujo y prioridades, aunque la evolución posterior ha refinado los mecanismos de priorización. La multiplexación evita que una respuesta de aplicación tenga que completarse antes de comenzar otra, pero todos los flujos comparten TCP: si se pierde un segmento, TCP debe reconstruir el orden antes de entregar datos posteriores, produciendo bloqueo a nivel de transporte.

6.3. HTTP/3 y QUIC

HTTP/3 mapea la semántica HTTP sobre QUIC. QUIC es un protocolo de transporte seguro que se implementa sobre UDP para facilitar su despliegue en sistemas existentes, integra TLS 1.3 y proporciona múltiples flujos con recuperación independiente. La pérdida que afecta a un flujo no obliga a detener la entrega de datos válidos de otros flujos. QUIC identifica la conexión mediante identificadores que permiten mantenerla cuando cambia la dirección IP o el puerto, lo que resulta útil en movilidad, aunque la migración está sujeta a validaciones de ruta y política.

HTTP/3 no significa que UDP se vuelva fiable por sí mismo. QUIC implementa fiabilidad, control de congestión, cifrado, confirmación y recuperación de pérdidas en espacio de usuario. Tampoco garantiza que siempre sea más rápido: el beneficio depende de latencia, pérdidas, soporte de red, caché y reutilización. Algunas redes bloquean o degradan UDP, por lo que los clientes deben poder volver a HTTP/2 o HTTP/1.1.

HTTP/1.1  → HTTP sobre TCP; mensajes textuales; persistencia
HTTP/2    → HTTP binario y multiplexado sobre una conexión TCP
HTTP/3    → HTTP sobre QUIC; QUIC integra TLS 1.3 y usa UDP como sustrato

6.4. Rendimiento extremo a extremo

El tiempo percibido incluye resolución DNS, establecimiento del transporte, negociación TLS, espera del servidor, transferencia y procesamiento en el cliente. Las mejoras deben basarse en medición: caché, compresión de contenido, reducción de objetos, reutilización de conexión, proximidad geográfica, optimización de base de datos y límites de concurrencia. Una CDN no corrige una aplicación lenta en el origen; HTTP/3 no corrige consultas ineficientes; y ampliar ancho de banda no elimina la latencia de propagación.

7. API, SERVICIOS WEB Y FORMATOS DE INTERCAMBIO

7.1. REST como estilo arquitectónico

REST describe restricciones: separación cliente-servidor, comunicación sin estado, respuestas cacheables cuando proceda, interfaz uniforme, sistema por capas y código bajo demanda opcional. Una API que usa JSON y rutas HTTP no es automáticamente RESTful. Debe modelar recursos, utilizar la semántica de métodos y códigos, ofrecer identificadores estables y evitar acciones arbitrarias escondidas tras un único POST. REST no exige HTTPS como restricción académica; sin embargo, una API con datos personales, credenciales o funciones administrativas debe protegerse con TLS por requisitos de seguridad.

7.2. SOAP, WSDL y seguridad de mensaje

SOAP define un sobre XML para intercambiar mensajes y puede operar sobre distintos transportes. WSDL describe operaciones, mensajes, tipos y puntos de acceso; XSD define estructuras XML. La familia WS-* añade capacidades como seguridad de mensaje, direccionamiento y políticas. TLS protege el canal entre dos extremos; una firma XML puede preservar integridad y autenticidad de partes del mensaje incluso si atraviesa intermediarios autorizados. La complejidad de canonicalización, firmas envolventes y validación exige bibliotecas maduras y perfiles interoperables.

7.3. OpenAPI, versionado y contratos

OpenAPI permite describir endpoints, parámetros, esquemas, respuestas y mecanismos de seguridad de una API HTTP. Facilita documentación, generación de clientes, pruebas y gobierno, pero no reemplaza el diseño. El contrato debe definir errores, paginación, filtrado, límites, idempotencia y compatibilidad. El versionado puede expresarse en la ruta, cabecera o negociación; lo esencial es gestionar cambios incompatibles, deprecar con plazo y observar qué consumidores siguen usando versiones antiguas.

7.4. GraphQL, eventos y acceso asincrónico

GraphQL permite al cliente seleccionar campos y recorrer un esquema tipado, reduciendo algunas situaciones de sobreobtención o múltiples llamadas, pero introduce riesgos de consultas costosas, autorización por campo y caché más compleja. La mensajería y los eventos son adecuados cuando el emisor no debe esperar una respuesta inmediata o cuando varios consumidores reaccionan al cambio. No sustituyen a HTTP: suelen coexistir con API síncronas, colas, webhooks y flujos de eventos.

WebSocket proporciona un canal bidireccional persistente tras una negociación inicial HTTP. Server-Sent Events permite eventos del servidor al navegador sobre HTTP. La elección depende de dirección, frecuencia, tolerancia a desconexiones, escalabilidad y necesidad de reanudación. En entornos sanitarios, cualquier canal en tiempo real debe aplicar autenticación continua, caducidad de tokens, límites de mensajes y trazabilidad.

8. INFRAESTRUCTURA DE PUBLICACIÓN Y ENTREGA

8.1. Servidor de origen y servidor de aplicaciones

El servidor web termina conexiones, procesa HTTP, sirve contenido estático y puede actuar como puerta de entrada a la lógica de aplicación. El servidor de aplicaciones ejecuta componentes de negocio, gestiona transacciones, conexiones a datos y servicios internos. En despliegues modernos esas funciones pueden repartirse entre un proxy de entrada, contenedores y servicios especializados. La frontera no depende de una marca concreta, sino de responsabilidades: terminación de TLS, enrutamiento, ejecución, persistencia y observabilidad.

8.2. Proxy directo y proxy inverso

Un proxy directo representa al cliente frente a Internet y permite control de salida, autenticación, filtrado, registro y caché. Un proxy inverso representa a los servidores frente al cliente y permite publicar varios servicios bajo una entrada, terminar TLS, aplicar políticas, comprimir, cachear y distribuir tráfico. Ambos son intermediarios HTTP, pero se sitúan en lados distintos de la relación y protegen activos diferentes.

8.3. Balanceo y estado

Los algoritmos incluyen round robin, ponderación, menor número de conexiones, hash y decisiones basadas en latencia o salud. Un balanceador debe retirar instancias no saludables mediante comprobaciones que representen la capacidad real de atender solicitudes. La afinidad de sesión puede ser necesaria en aplicaciones heredadas, pero dificulta redistribución y recuperación. Cuando es posible, conviene externalizar el estado de sesión o utilizar tokens y almacenes compartidos para permitir escalado horizontal.

8.4. CDN y cachés intermedias

Una CDN replica o almacena contenido en puntos próximos a los usuarios y puede aportar terminación TLS, protección DDoS, optimización y enrutamiento. No se limita a contenido estático, aunque la caché de objetos inmutables es su caso más eficiente. La política debe evitar cachear respuestas personalizadas o datos sensibles de manera compartida. Cabeceras como Cache-Control: private, no-store, Vary y validadores condicionan el comportamiento.

8.5. Navegador y modelo de seguridad

El navegador resuelve nombres, valida certificados, negocia protocolos, aplica la política del mismo origen, ejecuta HTML, CSS, JavaScript y WebAssembly, administra cookies y almacenamiento, y muestra indicadores de seguridad. La política del mismo origen separa recursos por esquema, host y puerto. CORS permite al servidor autorizar determinados accesos entre orígenes; no es un mecanismo de autenticación ni protege una API frente a clientes no navegador.

9. TLS Y HTTPS

9.1. Qué protege TLS

TLS proporciona confidencialidad, integridad y autenticación del extremo mediante un protocolo de establecimiento y un protocolo de registros protegidos. HTTPS es la utilización de las semánticas HTTP sobre una conexión protegida por TLS. TLS no determina qué usuario puede leer una historia clínica ni valida la lógica de negocio: protege el canal y la identidad criptográfica del servicio, mientras la aplicación aplica autorización y auditoría.

9.2. SSL, TLS 1.2 y TLS 1.3

SSL es el antecedente histórico y sus versiones están obsoletas. TLS 1.0 y TLS 1.1 fueron formalmente desaprobados por la IETF. TLS 1.2 continúa desplegado si se configura con algoritmos y extensiones adecuados; TLS 1.3 simplifica la negociación, elimina algoritmos heredados y reduce viajes de ida y vuelta. La política concreta de una administración debe seguir el ENS y las guías criptográficas y de configuración aplicables, sin atribuir al texto general del ENS una lista cerrada de versiones que pertenece a guías y perfiles técnicos.

9.3. Handshake de TLS 1.3

El cliente envía ClientHello con versiones, algoritmos, extensiones y material para intercambio de claves. El servidor responde con ServerHello, selecciona parámetros y ambos derivan secretos de tráfico. Los mensajes posteriores, incluido el certificado y la prueba de posesión de la clave privada, se protegen con claves de handshake. El cliente valida la cadena, el nombre del servicio, la vigencia y las restricciones. Los mensajes Finished confirman que ambas partes poseen los secretos y que la negociación no fue alterada.

La clave privada del servidor nunca se transmite. En TLS 1.3 tampoco debe describirse el proceso general como envío de un secreto premaestro cifrado con RSA, porque ese modelo corresponde a suites antiguas de TLS. El intercambio efímero basado en Diffie-Hellman proporciona secreto hacia delante: comprometer posteriormente la clave de firma no revela por sí solo sesiones pasadas capturadas.

9.4. 0-RTT y riesgos de repetición

TLS 1.3 y QUIC pueden permitir datos tempranos 0-RTT al reanudar una relación previa. Esos datos reducen latencia, pero no tienen las mismas garantías frente a repetición. Solo deben usarse para operaciones repetibles y sin efectos irreversibles, o deben incluir defensas específicas. Una compra, una prescripción o una modificación clínica no debe ejecutarse ciegamente como dato temprano repetible.

9.5. Terminación, extremo a extremo e inspección

La terminación TLS puede ocurrir en un balanceador o proxy. A partir de ahí, el tráfico puede volver a cifrarse hacia el backend, preferiblemente con autenticación y segmentación. Hablar de HTTPS externo no garantiza cifrado extremo a extremo hasta la aplicación. La arquitectura debe documentar cada tramo, el propietario de las claves, los registros generados y la protección de datos en memoria.

La inspección TLS corporativa crea dos conexiones y presenta al cliente un certificado emitido por una autoridad interna. Puede detectar amenazas, pero rompe el canal original y requiere distribución segura de la CA, exclusiones para aplicaciones con certificate pinning, protección de claves, minimización y evaluación jurídica. Si se configura mal produce errores de confianza o debilita protocolos.

10. CERTIFICADOS DIGITALES Y PKI

10.1. Certificados X.509 y cadena de confianza

Un certificado vincula una clave pública con una identidad y está firmado por una autoridad de certificación. El cliente construye una cadena desde el certificado del servicio, pasando por autoridades intermedias, hasta una raíz de confianza instalada en su almacén. La firma de la CA permite comprobar que el certificado no fue modificado y fue emitido bajo una política, pero el cliente debe además validar fechas, uso de clave, restricciones, nombre y estado de revocación cuando proceda.

El servidor debe presentar el certificado final y las intermedias necesarias; normalmente no envía la raíz. Una cadena incompleta puede funcionar en un equipo que conservó la intermedia y fallar en otro. Por ello las pruebas deben realizarse con clientes limpios y revisar SNI, cadena, algoritmos, nombres y protocolo. En arquitecturas con múltiples dominios, SNI permite que el cliente indique el nombre solicitado durante la negociación para seleccionar el certificado adecuado.

10.2. Identidad del servicio y SAN

La identidad DNS se expresa en la extensión subjectAltName. El cliente compara el nombre solicitado con los nombres autorizados. Un comodín como *.ejemplo.es cubre un nivel de subdominio según las reglas de coincidencia, no nombres arbitrariamente profundos ni el dominio base por sí solo. Los certificados multidominio incluyen varios SAN. La validación DV, OV o EV describe procedimientos de emisión y atributos organizativos, no una diferencia en la fortaleza criptográfica de la sesión.

10.3. Renovación, revocación y automatización

Los certificados caducan y deben renovarse antes del vencimiento. La automatización reduce errores, pero requiere inventario, propietarios, pruebas y alertas. La revocación puede consultarse mediante CRL u OCSP; OCSP stapling permite que el servidor adjunte una respuesta firmada y evita que el cliente consulte directamente a la CA en cada conexión. En la práctica, la respuesta de los clientes ante fallos de revocación varía, por lo que la protección no puede depender exclusivamente de este mecanismo.

La protección de claves privadas es crítica. Deben generarse y almacenarse con controles de acceso, registro, copia o redundancia conforme al servicio y, cuando el riesgo lo requiera, módulos criptográficos o gestores de secretos. Compartir una misma clave entre demasiados sistemas aumenta el impacto de compromiso. La renovación no debe consistir en copiar manualmente archivos por canales no controlados.

10.4. CAA, Certificate Transparency y pinning

CAA permite al titular del dominio indicar qué CA puede emitir certificados. Certificate Transparency registra certificados públicos en bitácoras verificables y ayuda a detectar emisiones indebidas. El pinning de clave o certificado dentro de aplicaciones reduce ciertas amenazas, pero complica rotación y recuperación; debe diseñarse con claves de respaldo y no confundirse con la antigua cabecera HPKP, retirada de navegadores.

11. IDENTIDAD, AUTENTICACIÓN Y AUTORIZACIÓN

11.1. Identificación, autenticación y autorización

Identificar es declarar quién se es; autenticar es aportar evidencia; autorizar es decidir qué acción se permite; contabilizar o auditar es registrar lo ocurrido. Una contraseña autentica, un rol autoriza y un registro de acceso aporta trazabilidad. Mezclar conceptos conduce a diseños inseguros: que un usuario esté autenticado no significa que pueda consultar cualquier dato, y que una red sea interna no prueba la identidad del dispositivo ni la necesidad asistencial.

11.2. Factores y autenticación multifactor

Los factores se agrupan en conocimiento, posesión e inherencia. MFA combina factores independientes; dos contraseñas siguen siendo un solo tipo. Los códigos de un solo uso mejoran frente a contraseña aislada, pero pueden ser objeto de phishing en tiempo real. Los autenticadores criptográficos resistentes al phishing, como credenciales basadas en clave pública y WebAuthn, vinculan la respuesta al origen y evitan entregar un secreto reutilizable al servidor.

La autenticación debe considerar ciclo de vida: alta, prueba de identidad, entrega del autenticador, recuperación, revocación y baja. La recuperación suele ser el punto más débil. En puestos compartidos o asistencia urgente deben existir procedimientos que mantengan trazabilidad sin fomentar el uso compartido de cuentas.

11.3. OAuth 2.0 y OpenID Connect

OAuth 2.0 es un marco de autorización delegada. Un cliente obtiene un token con alcances limitados para acceder a un recurso sin recibir la contraseña del usuario. OpenID Connect añade una capa de identidad sobre OAuth 2.0 e introduce el ID Token y endpoints de descubrimiento. Por tanto, decir que OAuth es un protocolo de autenticación es impreciso; la autenticación del usuario dentro del flujo no convierte al token de acceso en prueba de identidad para cualquier uso.

Para aplicaciones interactivas se prefiere el flujo Authorization Code con PKCE. El flujo de credenciales del cliente se reserva para comunicación entre servicios sin usuario. Los tokens deben tener audiencia, emisor, caducidad y alcance verificables. JWT es un formato de token firmado o cifrado, no un protocolo de autorización y no obliga a que el token sea autocontenido.

11.4. SAML, federación y SSO

SAML intercambia aserciones XML entre proveedor de identidad y proveedor de servicio y se utiliza ampliamente en federación empresarial. El inicio de sesión único mejora experiencia y centraliza políticas, pero concentra riesgo: la indisponibilidad o compromiso del proveedor de identidad afecta a múltiples servicios. Debe combinarse con MFA, sesiones limitadas, revocación, monitorización y segmentación de privilegios.

11.5. mTLS y autenticación de servicios

En TLS habitual, el cliente autentica al servidor. En mTLS, el servidor solicita además un certificado del cliente. Es útil para autenticación fuerte entre servicios, dispositivos gestionados o integraciones B2B. No reemplaza la autorización: el certificado identifica una entidad, mientras las políticas deciden qué operaciones, datos y entornos puede utilizar.

12. SEGURIDAD DE APLICACIONES Y SERVICIOS DE ACCESO

12.1. Modelo de amenazas

La seguridad comienza identificando activos, actores, superficies y consecuencias. Un servicio público puede sufrir interceptación, suplantación, manipulación, abuso de credenciales, inyección, control de acceso roto, fuga por registros, denegación de servicio y compromiso de dependencias. TLS reduce interceptación y manipulación en tránsito, pero no evita que un usuario autorizado abuse de permisos, que el servidor sea vulnerable o que el endpoint esté comprometido.

12.2. Seguridad de transporte y cabeceras

HSTS indica al navegador que use HTTPS durante un periodo. Solo debe enviarse por HTTPS. La primera visita sigue expuesta a degradación si el usuario entra por HTTP y el dominio no está precargado; la lista de precarga reduce ese riesgo, pero exige que todos los subdominios afectados soporten HTTPS de forma permanente. Content-Security-Policy restringe orígenes de scripts, estilos y otros recursos; X-Content-Type-Options: nosniff evita ciertas interpretaciones; Referrer-Policy limita información de referencia; y las políticas de aislamiento pueden reducir interacción entre contextos.

CSP es defensa en profundidad, no reparación de una inyección. Debe evitar listas permisivas y, cuando proceda, usar nonces o hashes. Las cookies de sesión deben llevar Secure y HttpOnly; SameSite ayuda frente a CSRF, pero la aplicación puede necesitar tokens antifalsificación y validación de origen.

12.3. Riesgos de aplicación

El control de acceso roto permite actuar sobre recursos ajenos mediante cambios de identificador o funciones no protegidas. La inyección aparece cuando datos no confiables alteran una consulta o comando; se previene con parametrización, validación, APIs seguras y mínimos privilegios. XSS ejecuta código en el contexto del origen y se reduce mediante codificación de salida contextual, plantillas seguras y CSP. SSRF induce al servidor a realizar solicitudes hacia destinos no previstos, pudiendo alcanzar metadatos cloud o redes internas.

La edición 2025 del OWASP Top 10 mantiene el control de acceso roto como riesgo principal y actualiza el panorama de concienciación. El documento sirve para priorizar formación, pero no sustituye un modelo de amenazas, pruebas de seguridad, revisión de arquitectura y gestión de vulnerabilidades adaptados al servicio.

12.4. WAF, API gateway y limitación

Un WAF inspecciona tráfico HTTP y aplica reglas frente a patrones de ataque. Un API gateway añade autenticación, autorización, cuotas, transformación, descubrimiento y observabilidad. Ninguno corrige una autorización ausente en el backend. Las reglas genéricas pueden producir falsos positivos; deben probarse, mantenerse y complementarse con validación en la aplicación.

Las cuotas y el rate limiting protegen recursos y equidad. Deben considerar usuario, cliente, IP, operación y coste, no solo número bruto de solicitudes. Una consulta pesada puede consumir más que cientos de operaciones simples. Las respuestas 429 pueden incluir información para reintento, y los clientes deben aplicar retroceso exponencial con aleatoriedad.

12.5. Gestión de secretos, registro y privacidad

Claves, contraseñas y tokens no deben almacenarse en código, repositorios ni imágenes. Los gestores de secretos permiten control, rotación y auditoría. Los registros deben ser suficientes para investigar, pero no contener contraseñas, tokens completos, datos clínicos innecesarios ni cuerpos sensibles. La correlación mediante identificadores técnicos y seudonimización reduce exposición.

12.6. Denegación de servicio y resiliencia

Los ataques volumétricos saturan enlaces; los de protocolo agotan estados; los de aplicación consumen recursos mediante operaciones legítimas costosas. La defensa combina capacidad, filtrado ascendente, CDN o protección DDoS, límites, caché, colas, circuit breakers y degradación controlada. La disponibilidad no se alcanza solo bloqueando tráfico: requiere arquitectura que mantenga funciones prioritarias durante picos y fallos parciales.

13. ACCESO REMOTO, VPN Y TRANSFERENCIA SEGURA

13.1. VPN de red, VPN de acceso y túneles

IPsec protege tráfico en la capa de red y puede funcionar en modo transporte o túnel. En acceso remoto, una VPN asigna conectividad lógica hacia redes internas y suele entregar rutas, DNS y políticas. Una VPN basada en TLS puede publicar acceso de red o aplicaciones concretas. El término SSL-VPN se mantiene por tradición, aunque los productos modernos utilizan TLS.

El acceso debe aplicar autenticación multifactor, evaluación del dispositivo, mínimos privilegios y segmentación. Enviar todo el tráfico por el túnel facilita inspección y política uniforme, pero aumenta carga y latencia. El split tunneling reduce esos costes, pero crea rutas simultáneas que deben evaluarse. La decisión depende de riesgo, capacidad y tipo de equipo.

13.2. ZTNA y acceso por aplicación

El acceso Zero Trust Network Access evita conceder por defecto visibilidad amplia de red. Un intermediario verifica identidad, dispositivo, contexto y política antes de conectar al usuario con una aplicación concreta. ZTNA no es sinónimo de Zero Trust completo: es un patrón de acceso que debe integrarse con identidad, inventario, telemetría, segmentación y respuesta.

13.3. Transferencia de ficheros

FTP separa canal de control y datos y no cifra de forma nativa. FTPS añade TLS al protocolo FTP, conservando su modelo de canales. SFTP es un protocolo distinto ejecutado sobre SSH y utiliza normalmente una única conexión. SCP copia archivos sobre SSH, pero ofrece menos operaciones de gestión que SFTP. Para automatización se prefieren claves protegidas, cuentas de servicio limitadas, restricciones de ruta, registro e integridad.

13.4. Acceso sanitario e intercambio de imágenes

El intercambio clínico no debe reducirse a copiar archivos genéricos. DICOM define servicios y objetos para imagen médica; DICOMweb utiliza HTTP para operaciones como búsqueda, recuperación y almacenamiento. La protección puede apoyarse en TLS, redes privadas, autenticación, autorización y auditoría. SFTP puede ser válido para lotes controlados de ficheros cuando el flujo se diseña así, pero no sustituye las capacidades semánticas, de consulta y ciclo de vida de PACS, VNA o DICOMweb.

13.5. Acceso remoto administrativo

SSH proporciona terminal, túneles y transferencia segura. RDP y escritorios virtuales permiten interactuar con un entorno remoto. La exposición directa de estos servicios a Internet eleva el riesgo; deben situarse tras pasarelas, MFA, listas de acceso, bastiones y monitorización. Las sesiones privilegiadas pueden grabarse y las cuentas deben ser nominativas, temporales y separadas de las de uso cotidiano.

14. DISPONIBILIDAD, OBSERVABILIDAD Y CONTINUIDAD

14.1. Disponibilidad, capacidad y latencia

La disponibilidad es la probabilidad de que el servicio esté operativo cuando se necesita. Depende de infraestructura, software, dependencias, operación y recuperación. La capacidad determina cuánta carga puede atenderse dentro de objetivos. La latencia mide tiempo; el ancho de banda mide capacidad de transferencia; no existe una relación causal simple. Un enlace satelital puede tener gran capacidad y latencia alta, mientras un enlace directo puede tener poca capacidad y latencia baja.

Los objetivos deben expresarse mediante SLI y SLO: porcentaje de solicitudes correctas, percentiles de latencia, frescura de datos o éxito de autenticación. El promedio oculta colas largas; percentiles como p95 o p99 describen la experiencia de la mayoría y los casos lentos. Los acuerdos de nivel de servicio añaden consecuencias y responsabilidades contractuales.

14.2. Redundancia y eliminación de puntos únicos

La redundancia puede aplicarse a enlaces, resolutores, balanceadores, instancias, zonas y centros. No basta duplicar componentes si comparten alimentación, configuración, credenciales o dependencia. La conmutación debe probarse. Activo-activo distribuye carga pero exige consistencia y resolución de conflictos; activo-pasivo simplifica algunos estados, pero el secundario puede degradarse sin uso real.

14.3. Observabilidad

Los registros describen eventos; las métricas cuantifican comportamiento; las trazas siguen una solicitud entre componentes. La correlación requiere identificadores que no revelen datos sensibles. La observabilidad debe cubrir DNS, handshake, códigos HTTP, saturación, colas, errores de dependencia y experiencia del usuario. Un 200 puede ocultar una respuesta funcionalmente errónea; las comprobaciones sintéticas deben validar operaciones representativas.

Cliente → DNS → CDN/WAF → balanceador → aplicación → servicio interno → base de datos
           │       │           │            │              │               │
        latencia  caché      salud/TLS    trazas        dependencia      espera/errores

14.4. Copias, continuidad y recuperación

La alta disponibilidad reduce interrupciones, pero no sustituye copias ni recuperación. Un error lógico puede replicarse a todos los nodos. El RTO expresa cuánto tiempo puede tardar la recuperación; el RPO, cuánta pérdida de datos temporal es tolerable. Los procedimientos deben contemplar certificados, DNS, secretos, infraestructura como código y dependencias externas, no solo bases de datos.

14.5. Gestión de cambios

Los despliegues progresivos, blue-green, canary y banderas de funcionalidad reducen impacto, siempre que existan métricas, reversión y compatibilidad de datos. La caché y DNS hacen que un cambio no sea instantáneo. La renovación de certificados, retirada de TLS antiguo o migración de API debe probarse con inventario de clientes y ventanas controladas.

15. TENDENCIAS

15.1. DNS cifrado y descubrimiento moderno

DoT, DoH y DoQ protegen el transporte de consultas DNS frente a observación y manipulación en la red local. La tendencia no elimina la gobernanza: una organización debe decidir resolutores autorizados, registro proporcional, filtrado y tratamiento de equipos gestionados. Los registros HTTPS y SVCB permiten publicar parámetros de conexión y alternativas de servicio, facilitando descubrimiento de HTTP/3 y otros datos de enlace.

15.2. Zero Trust y políticas dinámicas

Zero Trust desplaza la decisión desde la ubicación de red hacia identidad, recurso, dispositivo y contexto. NIST SP 800-207 insiste en eliminar la confianza implícita y evaluar cada acceso. La tendencia práctica es integrar proveedor de identidad, gestión de dispositivos, microsegmentación, telemetría y motores de política. No implica autenticar manualmente cada paquete, sino mantener decisiones continuas y revocables.

15.3. Criptografía post-cuántica

NIST publicó en 2024 FIPS 203 para ML-KEM, FIPS 204 para ML-DSA y FIPS 205 para SLH-DSA. La migración requiere inventario criptográfico, agilidad para sustituir algoritmos y pruebas de impacto en tamaño, latencia y compatibilidad. La transición inicial tiende a mecanismos híbridos que combinan algoritmos clásicos y post-cuánticos. No existe un TLS 1.3 mágicamente cuántico: los grupos y firmas deben evolucionar mediante extensiones y despliegues interoperables.

15.4. Edge, PWA y WebAssembly

El edge acerca ejecución, caché o análisis al lugar donde se generan o consumen datos, reduciendo latencia y tráfico, pero distribuye la superficie de gestión. Las PWA combinan manifiesto, service worker y capacidades web para instalación y trabajo limitado sin conexión. WebAssembly aporta un formato binario portable y aislado útil para procesamiento intensivo. En salud, el uso sin conexión obliga a gestionar cifrado local, caducidad, sincronización y conflicto.

15.5. IA en la capa de acceso

Los asistentes conversacionales y buscadores semánticos pueden facilitar acceso, pero deben limitar fuentes, registrar evidencia, proteger datos y evitar que la respuesta generada sustituya el sistema de registro. La IA añade amenazas de inyección de instrucciones, fuga de contexto, contenido incorrecto y dependencia de proveedores. El patrón seguro separa recuperación autorizada, generación, validación y ejecución de acciones.

15.6. IPv6, movilidad y redes 5G

IPv6 amplía direccionamiento y simplifica determinados aspectos de autoconfiguración, pero no elimina cortafuegos ni políticas. La coexistencia dual-stack aumenta superficie y obliga a monitorizar ambos protocolos. 5G aporta perfiles de servicio, mayor densidad y potencial de baja latencia, condicionados por despliegue real y arquitectura. En casos clínicos críticos debe distinguirse capacidad teórica de garantía contractual y cobertura efectiva.

16. APLICACIÓN AL SSPA Y AL SERVICIO ANDALUZ DE SALUD

16.1. Principios de aplicación en el SSPA

En el Servicio Andaluz de Salud conviven portales ciudadanos, aplicaciones profesionales, servicios de integración, acceso remoto y comunicaciones entre centros. El temario debe aterrizar los conceptos sin inventar productos, marcas, direcciones o topologías internas. Puede afirmarse que sistemas como ClicSalud+ y los servicios asociados a Diraya requieren publicación segura, identidad, autorización, interoperabilidad, alta disponibilidad y protección de datos; la configuración concreta debe tomarse de documentación corporativa vigente.

El diseño debe clasificar información y servicios conforme al ENS, aplicar protección de datos desde el diseño, limitar acceso por necesidad, mantener trazabilidad y asegurar continuidad. Los datos de salud son categorías especiales bajo el RGPD. El cifrado en tránsito es un control importante, pero se complementa con minimización, segregación, gestión de identidades, registro, copias y respuesta a incidentes.

16.2. Portal ciudadano

Un portal ciudadano debe validar identidad, proteger sesión, ofrecer información accesible y evitar exponer datos en URL, cachés compartidas o analítica. Las acciones sensibles pueden requerir autenticación reforzada. La arquitectura típica incluye DNS, protección perimetral, terminación TLS, balanceo, aplicación, servicios internos y repositorios. Esa descripción es una arquitectura de referencia, no una afirmación sobre marcas o número de nodos del SAS.

16.3. Aplicación profesional

El acceso profesional puede apoyarse en identidad corporativa y contexto del puesto. La autorización debe incorporar rol, centro, relación asistencial, función y situación de emergencia. Las sesiones deben bloquearse en puestos desatendidos y los accesos a información clínica quedar auditados. El hecho de estar dentro de la red corporativa no basta para confiar implícitamente en toda solicitud.

16.4. Integración entre sistemas

Las integraciones pueden utilizar API REST, SOAP, mensajería, HL7, FHIR o DICOM según semántica y ecosistema. La seguridad requiere autenticación de servicios, autorización por operación, protección de canal, límites y versionado. Los certificados de cliente o identidades de carga de trabajo evitan compartir cuentas genéricas. Las colas permiten absorber indisponibilidad temporal, pero exigen idempotencia y tratamiento de duplicados.

16.5. Acceso remoto y soporte

El acceso remoto debe diferenciar usuario final, soporte técnico, proveedor y administración privilegiada. MFA, dispositivos gestionados, bastiones, sesiones limitadas y registro reducen riesgo. Los proveedores externos no deben recibir conectividad amplia permanente; el acceso debe habilitarse por necesidad, alcance y tiempo, con supervisión y revocación.

16.6. Criterios de decisión

17. MAPA CONCEPTUAL Y CONCLUSIONES

17.1. Mapa conceptual

17.2. Distinciones que debes dominar

• Internet / Web: infraestructura global frente a servicio de hipertexto y API sobre HTTP.
• HTTP / HTTPS: semántica de aplicación frente a HTTP protegido con TLS.
• TLS asimétrico / simétrico: autenticación y establecimiento frente a cifrado eficiente de datos.
• Autenticación / autorización: demostrar identidad frente a decidir permisos.
• OAuth / OpenID Connect: autorización delegada frente a identidad sobre OAuth.
• Proxy / proxy inverso: representa al cliente frente a representar al servidor.
• HTTP/2 / HTTP/3: multiplexación sobre TCP frente a HTTP sobre QUIC.
• FTP / FTPS / SFTP: FTP sin protección nativa, FTP con TLS y protocolo de ficheros sobre SSH.
• DNSSEC / DoH-DoT-DoQ: autenticidad de datos frente a privacidad del transporte.

17.3. Estrategia de estudio

Estudia el recorrido de una solicitud completa. Primero se identifica una URL; DNS resuelve el nombre; IP y el encaminamiento llevan los paquetes; TCP o QUIC establecen transporte; TLS autentica y protege; HTTP expresa la operación; el proxy y el balanceador seleccionan destino; la aplicación autentica y autoriza; y la respuesta puede almacenarse en caché. Después incorpora fallos: DNS incorrecto, certificado no confiable, token caducado, backend saturado, caché mal configurada o ruta VPN incompleta.

Memoriza las perlas oficiales verificadas, pero acompáñalas del criterio. El puerto 53 se entiende por DNS; el registro A por IPv4; GET por consulta; multiplexación por HTTP/2; QUIC por HTTP/3; cifrado simétrico tras el handshake por eficiencia; SFTP por SSH y conexión única; y un error de certificado por cadena o nombre. Así podrás resolver variantes y no depender de una frase literal.