Secure Web Gateway frente a protección DNS: cuál utilizar
Compare las pasarelas web seguras con las protecciones a nivel de DNS para WiFi de invitados y pública. Conozca las funcionalidades, el rendimiento y dónde encaja cada una en su infraestructura.
Published 19 de octubre de 2026
Si un invitado se conecta a su WiFi con un portátil comprometido, ¿qué detiene la llamada de retorno a su servidor de comando y qué puede probar después? Esa pregunta, y no una lista de verificación de funciones, debería determinar si necesita un secure web gateway, protección a nivel de DNS o ambos.
Tabla de contenidos
- Por qué es importante elegir la capa de protección web adecuada
- Lo que realmente hace una Secure Web Gateway
- Cómo funciona la protección a nivel de DNS
- Comparación de capacidades y rendimiento
- Dónde encaja cada enfoque en su infraestructura
- Cómo elegir el enfoque adecuado
- Prueba y verificación de su protección
Por qué es importante elegir la capa de protección web adecuada
Un invitado se registra en un hotel, abre un portátil y se conecta al SSID. El dispositivo parece normal. Se autentica, obtiene una dirección IP y empieza a resolver dominios, uno de los cuales pertenece a un servicio de comando y control al que el malware del equipo lleva días intentando acceder.
En ese momento, usted no controla el dispositivo final. No puede comprobar si su antivirus está actualizado, implementar un agente ni instalar un certificado para la inspección TLS. Debe operar a través de la ruta de red, y la capa en la que aplique la directiva determinará qué puede detener y de qué pruebas dispondrá más adelante.
La pregunta clave antes de la compra
Los operadores a menudo preguntan qué producto es mejor. Ese es un planteamiento incorrecto. Un secure web gateway y un servicio a nivel de DNS aplican el control en puntos diferentes, ven cosas distintas y fallan de formas diferentes, por lo que la pregunta útil es qué punto de aplicación se adapta mejor a su combinación de dispositivos, sus sedes y su deber de custodia.
Considere tres situaciones habituales en la misma propiedad. La tablet de un alumno necesita filtrado por categorías y Búsqueda Segura. El teléfono de un contratista necesita protección contra phishing sin que nadie toque el terminal. Un portátil gestionado del personal puede necesitar una inspección completa de las cargas en almacenamientos no autorizados. Una sola capa rara vez gestiona las tres cosas con la misma eficacia.
Regla práctica: Comience por la propiedad del dispositivo. Cuanto menos controle el dispositivo final, más temprana y nativa de la red debe ser su aplicación de políticas.
Equivocarse en esto tiene consecuencias visibles. Despliegue la inspección profunda donde no pueda gestionar certificados y romperá aplicaciones o esquivará el tráfico que pretendía inspeccionar. Confíe únicamente en las búsquedas donde necesite visibilidad de la carga útil y se perderá las amenazas transportadas dentro de sesiones autorizadas. Cualquiera de los dos errores deja una brecha que descubrirá durante un incidente, no durante el proceso de compra.
La experiencia del usuario importa en la misma medida. Los invitados juzgan su red en cuestión de segundos. Los controles que añaden un retraso perceptible, fuerzan alternativas en el Captive Portal o bloquean servicios legítimos sin una explicación clara generan llamadas al soporte técnico y presiones para debilitar la directiva. Los controles que operan durante el establecimiento de la conexión suelen resistir mejor el contacto con ubicaciones reales.
La elección tampoco es binaria. Muchas instalaciones necesitan una base amplia que cubra cada dispositivo, además de una inspección más profunda para la población más reducida de endpoints gestionados donde dicha inspección sea técnica y legalmente viable. La defensa en profundidad aquí no es un eslogan. Es admitir que cada capa demuestra algo diferente, y usted debe saber exactamente qué es ese algo antes de firmar.
Lo que realmente hace un Secure Web Gateway
Un secure web gateway se entiende mejor como un punto de inspección y aplicación de directivas para el tráfico web saliente, y no como una simple lista negra de mayor tamaño. El NIST describe esta función como la protección del tráfico saliente de los usuarios mediante la inspección HTTP y HTTPS, centralizando al mismo tiempo el control, la visibilidad y los informes en sedes centrales, sucursales, oficinas domésticas y ubicaciones remotas, lo cual puede consultar en la guía del NIST sobre funciones de secure web gateway.
En la práctica, el tráfico se redirige a la pasarela, ya sea de forma explícita mediante la configuración del proxy, a través de un túnel desde una sucursal o mediante un agente en un dispositivo gestionado. La pasarela evalúa la solicitud en función de la política, inspecciona el contenido devuelto y registra la decisión. Si este modelo de proxy no le resulta familiar, resulta útil comprender primero los conceptos de reenvío relacionados, incluyendo cómo funcionan los proxies inversos, antes de comparar las arquitecturas de diferentes proveedores.
Funciones principales que conviene evaluar
- Filtrado de URL y categorías: bloquea o permite destinos por reputación y tipo de contenido, en lugar de hacerlo únicamente por dominio.
- Detección de malware y phishing: analiza descargas y páginas, incluido el contenido dentro de sesiones permitidas en las que la inspección está habilitada.
- Controles de aplicaciones: distingue entre servicios autorizados y no autorizados que comparten la misma infraestructura subyacente.
- Inspección TLS: descifra y vuelve a cifrar el tráfico donde sea posible implementar confianza, algo sencillo en parques de dispositivos gestionados pero complejo en dispositivos de invitados.
- Registro de auditoría y alcance de directivas: registra quién o qué solicitó un recurso, qué regla se aplicó y qué acción se ejecutó a continuación.
Este último punto diferencia una pasarela de una lista de bloqueos. Está adquiriendo una política y evidencias coherentes, aplicadas de la misma manera en todas las ubicaciones, no solo una lista de dominios maliciosos.
Contexto de mercado y despliegue
Esta categoría es ahora un área de inversión clave en seguridad. El mercado de secure web gateway se estimó en 14 750 millones de USD en 2024, con previsiones de alcanzar los 75 540 millones de USD para 2033 con una TCAC del 20,6%, y Norteamérica concentró el 37,4% de los ingresos globales en 2024, según las estimaciones de mercado de Grand View Research para secure web gateways. Considere estos datos como estimaciones de analistas y no como totales auditados, ya que los proveedores e investigadores delimitan las categorías de productos de manera diferente.
La prestación del servicio se ha desplazado de forma decisiva hacia la nube. La implementación basada en la nube representó el 76,32 % de los ingresos de SWG en 2025, con una previsión de crecimiento de la implementación en la nube a una CAGR del 22,05 % hasta 2031, según el análisis de modelos de implementación de SWG de Mordor Intelligence. Esto resulta crucial a nivel operativo. Una pasarela en la nube puede aplicar directivas sin necesidad de un dispositivo físico en cada ubicación, lo que se adapta perfectamente a las instalaciones distribuidas, aunque introduce cierta dependencia respecto al enrutamiento y la proximidad a los puntos de inspección.
El compromiso es constante. Se gana en profundidad, visibilidad de la carga útil y control granular de las aplicaciones. Se paga en complejidad de despliegue, gestión de certificados y el trabajo continuo de reorientar el tráfico para que se realice la inspección.
Cómo funciona la protección a nivel de DNS
Cada conexión comienza con una consulta. Antes de que un navegador, una aplicación o un fragmento de software malicioso pueda acceder a un servicio, suele resolver un nombre, y el DNS protectivo responde a esa resolución según la política antes de que comience cualquier conexión.
Si el dominio es conocido por phishing, distribución de malware o comando y control, el resolutor rechaza o redirige la búsqueda. El dispositivo nunca obtiene un destino útil, por lo que la devolución de llamada falla en el punto más temprano posible. Se trata de una intervención más acotada que la inspección de la carga útil, pero funciona sin necesidad de tocar el endpoint.
Qué ocurre durante la resolución de DNS
La directiva de categorías funciona de la misma manera. Una solicitud de un dominio para adultos o de apuestas en un SSID familiar puede bloquearse, mientras que la misma búsqueda en una red de empleados sigue una regla diferente. La aplicación obligatoria de Safe Search en Google, Bing y YouTube se puede ejecutar mediante el comportamiento de resolución, y los dominios de anuncios y rastreadores se pueden omitir para que las páginas carguen menos peso de terceros.
La granularidad de la política es lo que resulta verdaderamente útil en todo un entorno. Puede variar las reglas según el SSID, la VLAN, el establecimiento y el horario, de modo que un colegio aplique un filtrado más estricto durante el horario lectivo, un hotel separe el tráfico de los huéspedes del tráfico interno y un grupo de pubs mantenga una base común permitiendo excepciones a nivel de local. El sistema de informes muestra qué dominio se ha solicitado, qué política ha coincidido y en qué segmento de la red se ha producido.
Un bloqueo de DNS demuestra que se detuvo una resolución bajo una política concreta en un momento determinado. No demuestra que se haya inspeccionado el contenido detrás de ese dominio, y los informes honestos no deberían pretender lo contrario.
Por qué se adapta a los dispositivos no gestionados
El despliegue es la ventaja decisiva. No requiere compra de hardware, cambios en el firewall ni instalación alguna en los dispositivos cliente, por lo que la cobertura se extiende a teléfonos, consolas de videojuegos, smart TV y el amplio abanico de dispositivos a los que los agentes nunca llegan. Un invitado que se conecta durante veinte minutos obtiene la misma protección base que un residente que se queda durante un trimestre.
Esa simplicidad tiene límites que conviene dejar claros. El DNS ve el nombre que se está resolviendo, no la ruta URL completa ni el contenido devuelto a través de una conexión permitida. Un archivo malicioso alojado en un servicio permitido y de buena reputación no se detectará únicamente mediante la consulta. Los clientes que omiten su servidor de resolución a través de DNS cifrado, resolución integrada en el código o una VPN también pueden reducir la visibilidad, a menos que la red gestione activamente esas rutas.
Por lo tanto, la protección a nivel de DNS ofrece un control amplio, temprano y respaldado por evidencias con un fricción mínima. No proporciona una inspección profunda. Saber cuál de las dos opciones necesita realmente es la clave de toda la decisión.
Comparación de capacidades y rendimiento
La forma más clara de comparar estas capas es por lo que cada una puede observar. Un gateway situado en la ruta del tráfico puede inspeccionar solicitudes y respuestas, incluidos los datos cargados completos de HTTPS cuando la inspección TLS se puede desplegar legítimamente. La protección DNS observa la búsqueda que precede a la conexión. Todo lo demás se deriva de esa diferencia.
Esto significa que las amenazas ocultas dentro de sesiones HTTPS permitidas, las cargas maliciosas y la pérdida de datos a través de servicios aparentemente autorizados requieren controles en la pasarela o en el endpoint. También implica que una pasarela que no se pueda colocar en la ruta del tráfico de un dispositivo de invitado no inspeccionará absolutamente nada, por muy potente que sea su motor. La cobertura que se puede aplicar supera a la capacidad que no se puede desplegar.
Comparativa rápida: SWG frente a protección a nivel de DNS
| Criterio | Secure Web Gateway | Protección a nivel de DNS |
|---|---|---|
| Profundidad de inspección | Solicitud y respuesta completas cuando está en la ruta | Búsqueda de dominio antes de la conexión |
| Cobertura de dispositivos | Mayor eficacia en dispositivos gestionados | Cualquier dispositivo que utilice el solucionador |
| Impacto en el rendimiento | Depende de la inspección y de la distancia al punto de presencia | Mínimo, limitado a la resolución |
| Complejidad de despliegue | Enrutamiento, túneles, agentes o certificados | Configuración del solucionador por red |
| Calidad de las evidencias | URL, usuario, acción y veredicto de contenido | Dominio, directiva, segmento, marca de tiempo, acción |
| Principal punto ciego | Tráfico que elude la ruta del proxy | Cargas útiles dentro de sesiones permitidas |
La calidad de los datos sustenta ambas filas de esa tabla. La precisión de las categorías, la actualización y la velocidad de recategorización determinan si cualquiera de los controles bloquea los elementos correctos, por lo que vale la pena entender cómo las fuentes de inteligencia sobre amenazas condicionan las decisiones de filtrado antes de comparar las afirmaciones de los proveedores.
Rendimiento que puede medir
No compare la cifra de rendimiento de una ficha técnica con la velocidad de carga de página de un invitado. Las guías independientes de SWG señalan aproximadamente de 40 a 80 ms de latencia adicional cuando los usuarios están cerca de un punto de presencia en la nube y aproximadamente de 150 a 400 ms cuando están lejos, mientras que la ficha técnica publicada de un equipo físico indica un rendimiento de cortafuegos de hasta 110 Gbps y más de 25 Gbps de rendimiento IPS en condiciones de laboratorio, datos detallados en la ficha técnica del dispositivo Check Point y guía de rendimiento de SWG. Esas cifras describen aspectos diferentes. El rendimiento en laboratorio ofrece muy poca información sobre el tiempo de negociación TLS en una ubicación rural congestionada durante las horas punta de entrada.
Mida en su lugar lo que perciben los invitados. Compare la seguridad habilitada frente a la omitida en sitios representativos, durante periodos de gran afluencia, y notifique la mediana junto con la latencia p95 y p99 para la resolución DNS, la configuración TLS y el tiempo hasta el contenido relevante. Los promedios ocultan las peores sedes, que es precisamente donde se originan las quejas.
La brecha de QUIC y el DNS cifrado
QUIC funciona sobre UDP, exige cifrado TLS 1.3 y admite la migración de conexiones entre redes WiFi y móviles, lo que crea una brecha de cumplimiento para las pasarelas convencionales, tal como se describe en la investigación sobre reenvío de tráfico y proxies compatibles con QUIC. Bloquear UDP en el puerto 443 puede forzar un retorno a TCP inspeccionable, pero puede degradar el rendimiento o interrumpir aplicaciones modernas. Permitir QUIC mantiene la experiencia de usuario pero reduce la visibilidad de una pasarela tradicional.
La política DNS se sigue aplicando en el momento de la resolución si el cliente utiliza su propio resolutor, razón por la cual los dos controles responden a preguntas diferentes. Pida a los proveedores que definan bloqueado con precisión. ¿Se detuvo una resolución, se impidió una conexión o se inspeccionó realmente el contenido? Son tres afirmaciones completamente distintas.
Dónde encaja cada enfoque en su arquitectura de red
El tipo de recinto predice la respuesta mejor que el tamaño de la organización. Un buen punto de partida es analizar la propiedad de los dispositivos en cada SSID y, a continuación, mapear las necesidades de inspección a esa realidad, un enfoque también reflejado en los consejos de seguridad de Nerds 2 You Edmonton para redes más pequeñas que valoran controles por capas.
El sector de la hostelería, los aeropuertos, las bibliotecas y las atracciones familiares operan redes donde casi todos los dispositivos son efímeros y no están gestionados. La protección a nivel de DNS se adapta perfectamente porque cubre a los invitados de inmediato, admite niveles gratuitos frente a niveles de pago mediante políticas por SSID y genera pruebas de filtrado sin inspeccionar el contenido personal. Una pasarela aporta muy poco en ese entorno si no se puede dirigir o descifrar el tráfico de los invitados de forma responsable.
Escuelas, campus y residencias de estudiantes se encuentran en un punto intermedio. Las obligaciones de protección requieren un filtrado de categorías constante y Safe Search en cada dispositivo, incluidos los teléfonos personales y las consolas. Sin embargo, los dispositivos de enseñanza gestionados pueden justificar la inspección en la pasarela para el control de aplicaciones y el escaneo de descargas, razón por la cual muchas instalaciones combinan ambos controles y los aplican a diferentes segmentos.
Vale la pena examinar en la práctica el patrón operativo que subyace a esa división.
Los hospitales y centros sanitarios se enfrentan a una división similar. El WiFi para pacientes y visitantes necesita un filtrado amplio y de baja fricción. Los sistemas clínicos y administrativos se ubican detrás de controles más estrictos y gestionados por separado, y mezclar a ambas poblaciones bajo un mismo modelo de inspección no suele funcionar bien para ninguna de las dos partes.
Dónde justifica su coste una pasarela
Las oficinas corporativas y las empresas con múltiples sedes y flotas gestionadas son el terreno principal de la pasarela. Puede desplegar agentes o túneles, gestionar certificados, vincular políticas a la identidad e inspeccionar subidas a servicios no autorizados. Los segmentos de dispositivos personales (BYOD) en esas mismas oficinas requieren una consideración independiente, ya que los dispositivos personales se resisten precisamente a los controles que hacen que una pasarela sea eficaz, una tensión que se analiza en la guía sobre seguridad BYOD para entornos con dispositivos mixtos.
- SSID para invitados y públicos: nivel básico en la capa DNS, páginas de bloqueo transparentes e informes por establecimiento.
- Redes de estudiantes y residentes: filtrado de DNS en todas partes y controles de pasarela en dispositivos gestionados.
- Segmentos de personal y corporativos: inspección de pasarela vinculada a la identidad, con DNS como bloqueo previo.
- Tecnología operativa y pantallas: política de DNS para dispositivos que no pueden ejecutar agentes y listas de permitidos con un alcance estrictamente definido.
El modelo híbrido no es falta de decisión. Se trata de asignar cada capa al grupo de usuarios donde su aplicación es efectiva.
Cómo elegir el enfoque adecuado
Tres preguntas resuelven la mayoría de las evaluaciones. ¿Quién es el propietario de los dispositivos, qué nivel de inspección requiere su postura de riesgo o cumplimiento, y qué capacidad operativa tiene para ejecutar el control correctamente? Respóndalas por segmento de red, no para la organización en su conjunto.
Si predominan los dispositivos no gestionados, comience con la protección a nivel de DNS como opción predeterminada. Cubre cada intento de conexión que utilice su DNS resolver, se despliega sin trabajo en el endpoint y le proporciona pruebas auditables de qué se bloqueó, dónde y cuándo. Para hoteles, pubs, aeropuertos y WiFi pública, este es el control que seguirá funcionando un sábado de gran afluencia cuando no haya nadie disponible para solucionar una excepción de proxy.
Si predominan los dispositivos gestionados y necesita inspección de carga útil, control de aplicaciones o prevención de pérdida de datos, elija una pasarela web segura y financie el trabajo operativo que requiere. Eso incluye la dirección del tráfico, el ciclo de vida de los certificados, la gestión de excepciones para aplicaciones fijadas y la planificación de capacidad para los puntos de inspección. Comprar la licencia sin ese trabajo implica comprar una cobertura parcial.
Fiabilidad por encima de las listas de funcionalidades
Sea escéptico ante las afirmaciones de detección que no pueda verificar. Investigaciones independientes que evalúan herramientas de control parental hallaron una protección desigual entre proveedores, sin que ninguna herramienta ofreciera una cobertura completa, mientras que el filtrado de resolvedores DNS funcionó de forma más consistente que varias alternativas, y Cloudflare informó que los enlaces engañosos representaron el 52% de los correos electrónicos maliciosos analizados en 2025, frente al 43% en 2024, según investigaciones independientes sobre cobertura de herramientas de filtrado y tendencias de enlaces engañosos.
Prueba de selección: Pregunte a cada proveedor con qué rapidez se clasifica un dominio recién registrado, cómo funcionan las apelaciones de recategorización y qué evidencia genera un solo bloqueo. Las respuestas difusas anticipan problemas operativos.
Para la mayoría de las instalaciones mixtas, la recomendación honesta es utilizar ambas, secuenciadas de forma sensata. Despliegue primero la base de DNS porque es rápida, cubre los dispositivos que nada más toca y genera inmediatamente pruebas en toda la instalación. Añada la inspección de pasarela donde la propiedad del dispositivo y el riesgo lo justifiquen. Ese orden cierra primero la brecha más amplia en lugar de perfeccionar la protección para los dispositivos más fáciles.
Prueba y verificación de su protección
No acepte una captura de pantalla del panel como prueba. Realice una prueba de aceptación en sus propios SSIDs, con su propia combinación de dispositivos, antes de comprometerse, y estructúrela en función de cómo se comporta el tráfico en lugar de cómo dice el diagrama de ventas que debería comportarse. Para un diseño de pruebas más amplio, consulte las recomendaciones de ThreatExploit AI sobre cómo crear rutinas de pruebas de seguridad repetibles.
Una prueba de aceptación con significado real
Mida la aplicación del control de forma independiente para DNS, HTTP, HTTPS, QUIC, DNS cifrado e IPv6, y luego verifique que los resultados se mantengan constantes en todos los SSIDs, VLANs, ubicaciones y horarios. Un bloqueo que funciona en la red del personal pero no en la VLAN de invitados, o durante el día pero no bajo una directiva nocturna, es un hallazgo, no una simple nota al pie.
- Búsquedas maliciosas conocidas: confirme que los dominios de prueba de phishing, malware y comando y control estén bloqueados y registrados con su correspondiente directiva y segmento.
- Comprobaciones por categoría: verifique las categorías de contenido para adultos, juegos de azar y otras restringidas en cada SSID, además del comportamiento de Búsqueda Segura en los principales servicios de vídeo y motores de búsqueda.
- Intentos de elusión: pruebe con DNS cifrado, una VPN de consumo, acceso directo por IP y navegadores compatibles con QUIC; a continuación, registre qué sigue detectando cada control.
- Dominios recientes: pruebe dominios sin categorizar y registrados recientemente, y observe si la directiva por defecto permite, bloquea o advierte.
- Servicios legítimos: confirme que las aplicaciones de pago, videoconferencia y aquellas críticas para el establecimiento sigan funcionando sin que se acumulen excepciones manuales.
Comportamiento ante fallos y rendimiento
Pruebe deliberadamente la respuesta fail-open frente a fail-closed interrumpiendo el servicio o el túnel. Debe saber si una caída provoca una navegación bloqueada o una red sin filtrar, y cuál de estas situaciones puede tolerar su deber de diligencia. Documente este comportamiento en su registro de riesgos, ya que los auditores se lo pedirán. Esta misma disciplina en las evidencias respalda un trabajo de garantía más amplio, incluidos los controles descritos en la guía sobre requisitos de certificación Cyber Essentials.
Realice pruebas de rendimiento en sitios representativos durante los periodos de mayor actividad. Registre la carga de la página hasta el contenido relevante, el tiempo de resolución DNS, el tiempo de negociación TLS y el rendimiento con usuarios concurrentes, comparando la seguridad habilitada frente a la omitida y notificando la mediana junto con p95 y p99. Incluya la pérdida de túnel o punto de presencia para observar el comportamiento de reconexión antes de que lo hagan los invitados.
Por último, inspeccione las propias evidencias. Cada bloqueo debe conservar la marca de tiempo, la directiva, el segmento de red, el dominio solicitado, la acción y el motivo. Un contador global no satisfará a un responsable de protección, a una aseguradora ni a su propia revisión de incidentes. Si los informes no pueden reconstruir una sola decisión, el control no está completo, independientemente de lo que haya bloqueado.
Purple Shield ofrece protección DNS y filtrado de contenidos diseñados para WiFi de invitados, establecimientos y espacios públicos, comprobando cada búsqueda antes de que se inicie la conexión y aplicando políticas por SSID, VLAN, establecimiento y horario sin necesidad de agentes en los dispositivos de los usuarios. Si desea disponer de esa evidencia básica en todo su entorno mientras decide dónde debe aplicarse una inspección de pasarela más profunda, visite Purple Shield para ver cómo se despliega en su red actual.