ComparisonDNS filtering limits
Filtrado DNS frente a Secure Web Gateway: cuándo se necesita la herramienta más avanzada
Decida si sus redes necesitan filtrado DNS, una solución Secure Web Gateway o ambas, mediante ocho criterios que van desde la ubicación hasta la huella de privacidad. Podrá implementar DNS de protección en cada red, incluido el WiFi para invitados WiFi, y delimitar el alcance de una pasarela a los dispositivos...
Elija el filtrado DNS a nivel de resolución según la norma RFC 1035 para proteger dispositivos no administrados conectados a WiFi en más de 80,000 establecimientos en 90 países sin necesidad de instalar hardware. Elija una pasarela web segura cuando requiera inspeccionar URL completas, descargas o cargas en dispositivos administrados mediante plataformas como Microsoft Entra ID. El filtrado DNS detiene destinos maliciosos antes de que se establezca la conexión, mientras que las pasarelas actúan como proxy y descifran el tráfico.
Filtrado DNS frente a pasarela web segura: la respuesta breve
La respuesta depende de una sola pregunta: ¿necesita ver el interior de la conexión o únicamente hacia dónde se dirige?
El filtrado DNS toma decisiones a nivel del nombre de dominio. Se niega a resolver un destino malicioso o no deseado, de modo que el dispositivo nunca llega a conectarse. Una pasarela web segura (SWG) es un proxy que se ubica en la ruta del tráfico. Puede leer la URL completa, el archivo y la página, pero únicamente después de descifrar el tráfico TLS.
En la red WiFi para invitados, la cuestión se resuelve por sí sola. No es posible instalar un certificado raíz en el teléfono de un invitado. Sin ese certificado, una pasarela no puede descifrar el tráfico sin generar errores de certificado. El filtrado DNS protege cada dispositivo en la red sin necesidad de instalar nada. Por esta razón, es la opción predeterminada para el sector hospitalidad, comercio minorista, centros de transporte y eventos.
En las computadoras portátiles administradas del personal que manejan datos regulados, la pasarela justifica su costo. La necesita para inspeccionar archivos cargados, aplicar reglas en rutas de URL o implementar esquemas de prevención de pérdida de datos (DLP). La solución DLP evita que la información confidencial salga de su red.
La mayoría de los establecimientos necesitan DNS de protección en cada red y una pasarela en una minoría de dispositivos administrados, si es que la necesitan. Purple Shield ofrece la primera parte. Funciona de manera independiente en cualquier WiFi o junto con Purple Access, con una directiva por red y VLAN. Para conocer con mayor detalle los alcances de este enfoque, consulte nuestro resumen sobre los límites del filtrado DNS.
Qué comparamos y por qué estos criterios definen la elección
Evaluamos ambos enfoques con base en ocho criterios. Cada uno corresponde a una decisión que toma un gerente de seguridad de TI o un gerente de operaciones de establecimiento al definir el alcance del filtrado. Definimos las capacidades de cada opción a partir de su documentación pública y de la experiencia adquirida al implementar ambas.
La ubicación es el aspecto principal porque determina los otros siete criterios. El filtrado DNS actúa en la resolución de nombres, la búsqueda definida en la norma RFC 1035. Todos los dispositivos solicitan una dirección a un solucionador antes de conectarse. Un solucionador DNS de protección contrasta el dominio con la inteligencia de amenazas y las directivas por categoría, y posteriormente responde o rechaza la solicitud.
Debido a que dicha verificación se realiza antes de establecer cualquier conexión, detecta aquello que un firewall pasa por alto. Las reglas del firewall se basan en direcciones IP y puertos. Los dominios maliciosos se trasladan a través de direcciones de nube compartidas que un firewall no puede bloquear de manera segura. Un secure web gateway se ubica más adelante, dentro de la conexión. El tráfico llega a él a través de un agente de endpoint, un archivo de autoconfiguración de proxy (PAC) o un dispositivo en línea. Para leer HTTPS, el gateway termina TLS, inspecciona el contenido y lo vuelve a cifrar. Esa profundidad requiere un certificado raíz de confianza en cada dispositivo que inspecciona.
Los ocho criterios:
- Ubicación: en qué parte de la conexión el filtro toma su decisión.
- Visibilidad: lo que el filtro puede ver, desde el nombre del dominio hasta el contenido de la página.
- Dispositivos no gestionados: si se cubre el tráfico de invitados y BYOD (trae tu propio dispositivo).
- Huella de implementación: el hardware, los agentes y los certificados requeridos.
- Rendimiento: la latencia y el ancho de banda que añade el filtro.
- Comportamiento ante fallas: qué sucede cuando el servicio no está disponible.
- Resistencia a evasiones: con qué facilidad un dispositivo elude el filtro, por ejemplo a través de DNS sobre TLS (DoT) o DNS sobre HTTPS (DoH).
- Huella de privacidad: cuántos datos personales procesa el filtro.
En el mercado, la línea no siempre es clara. DNSFilter es un servicio de DNS de protección, la misma categoría que Shield. Cisco Umbrella vende seguridad a nivel de DNS y, en sus paquetes superiores, un secure web gateway completo, por lo que abarca ambos lados de esta comparación. Cuando evalúe a cualquier proveedor, verifique qué capa ofrece cada paquete en lugar de confiar solo en el nombre del producto.
Two lanes compare a DNS filtering path that blocks at the lookup with a gateway path that decrypts and inspects traffic.
Connections
- Device looks up a domain to Shield checks policy
- Shield checks policy to Blocked: no connection made (threat or blocked category)
- Shield checks policy to Allowed: device connects directly (allowed)
- Device sends traffic to proxy to Proxy decrypts TLS
- Proxy decrypts TLS to Inspects URL, files and content
- Inspects URL, files and content to Re-encrypts, forwards or blocks
¿Cómo se comparan el filtrado DNS y un secure web gateway?
| Criterion | Purple Shield (DNS filtering) | Secure web gateway |
|---|---|---|
| Placement | At DNS resolution, before any connection opens | In the traffic path, after the connection opens |
| Visibility | Domain names, checked against threat and category policy | Full URLs, files and page content once TLS is decrypted |
| Unmanaged and guest devices | Covered with nothing installed | No TLS inspection without a trusted certificate on the device |
| Deployment footprint | No new hardware: change the DNS server per network | Agent, PAC file or appliance, plus a root certificate per device |
| Performance | One lookup per new domain; ad blocking reduces overall bandwidth usage | Every web request passes through the proxy |
| Failure behaviour | Fails closed, so no network runs unfiltered | Fail open or fail closed, set and tested per deployment |
| Bypass resistance | Block DoT on port 853 and known DoH resolvers at the firewall | Block direct outbound web traffic that skips the proxy |
| Privacy footprint | Processes domain names, not content | Decrypts content, so staff inspection needs a GDPR DPIA |
Dos filas merecen una lectura más detallada. En visibilidad, el gateway gana por completo. Un filtro DNS ve example.com pero nunca la ruta a un archivo en ese sitio. Explicamos el motivo en por qué el filtrado DNS no puede ver URL completas. En dispositivos no administrados, el filtrado DNS gana por completo, porque la cobertura de invitados no requiere certificados ni agentes.
Las filas restantes son compensaciones que puede gestionar. Puede cerrar la evasión de DNS cifrado mediante reglas de firewall. La latencia del gateway es tolerable en un servicio cloud de tamaño adecuado. El comportamiento ante fallas depende del producto, razón por la cual declaramos claramente el de Shield: falla cerrado.
Dónde gana el filtrado DNS
WiFi de invitados y dispositivos no administrados
Cada dispositivo en una red WiFi utiliza el servidor DNS que le entrega DHCP. Apunte ese servidor a un resolvedor de protección y cada teléfono, laptop, consola de videojuegos y Smart TV quedará cubierto. Nadie instala nada. El Captive Portal, la página de inicio de sesión que se muestra antes del acceso a la red, se mantiene tal como está. A escala, esta es la única forma práctica de filtrar a invitados, residentes, pasajeros y fanáticos.
Múltiples sitios, sin hardware nuevo
Cambiar al filtrado DNS es un cambio de configuración, no un proyecto. Shield funciona en la red WiFi que ya opera, incluyendo Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet.
Se establece una política por red y por VLAN. Por lo tanto, una red para visitantes apta para todo público y una red para el personal en el mismo sitio pueden ejecutar reglas diferentes. Su red para el personal puede asignar VLANs por rol a través de IEEE 802.1X, el estándar de autenticación de red basado en puertos. De ser así, la política de DNS específica por rol se aplica sin necesidad de un proxy.
Bloqueo de amenazas más temprano
El DNS detecta la intención antes de que fluya cualquier tráfico. Un dispositivo víctima de phishing debe consultar un dominio antes de poder conectarse. Lo mismo ocurre con un dispositivo infectado que se comunica con un servidor de comando y control. Shield identifica las amenazas en las etapas iniciales de su ciclo de vida, antes de que se establezca una conexión web. Ese tiempo de ventaja puede determinar si un dominio de phishing se bloquea antes del primer clic o después de este.
Redes más ligeras
El bloqueo de anuncios ocurre en la misma capa. Al activarse, el bloqueo de anuncios reduce el uso del ancho de banda y disminuye el volumen de consultas DNS. En una red concurrida en una ubicación con enlace de red limitado, esa capacidad se recupera sin realizar nuevos gastos.
Fallas que mantienen la seguridad
Shield tiene un comportamiento de falla cerrado (fail closed), por lo que una interrupción nunca deja una red sin filtrar. Esto es fundamental en redes para visitantes, donde usted asume el riesgo reputacional de cualquier contenido que se cargue. Explicamos las ventajas y desventajas en DNS filtering fail open vs fail closed.
Menor impacto en la privacidad
Un filtro DNS procesa nombres de dominio, no el contenido de la página. Bajo el GDPR, esto representa un conjunto de datos personales más acotado que las sesiones de navegación descifradas. Como resultado, sus registros de procesamiento se mantienen más simples.
- 241,000amenazas bloqueadas a la semanaSt George's Healthcare NHS Trust
- 500Mde usuarios e inicios de sesión al añoDatos de Purple
- 99.999%de SLA de disponibilidad del servicioDatos de Purple
- 80,000+ubicaciones activas en 90 paísesDatos de Purple
Dónde destaca un secure web gateway
Sea preciso sobre las fortalezas del gateway. Si asume que el filtrado DNS las cubre por completo, su programa de seguridad tendrá brechas reales.
Control total de ruta y URL
Algunas políticas aplican por debajo del nivel de dominio. Es posible que desee permitir un servicio de almacenamiento en la nube pero bloquear una carpeta compartida específica. O permitir un sitio de noticias pero bloquear su sección de comentarios. Solo un proxy que visualice la URL completa puede aplicar este tipo de reglas. Las plataformas compartidas representan el caso más complejo, ya que un filtro DNS debe permitir o bloquear el dominio completo.
Inspección de archivos y contenido
Un gateway puede escanear descargas en busca de malware, bloquear tipos de archivos y ejecutar ejecutables desconocidos en un entorno sandbox. El filtrado DNS detiene las conexiones a dominios conocidos como maliciosos. Sin embargo, un archivo malicioso alojado en un dominio de confianza seguirá pasando la verificación.
Prevención de pérdida de datos (DLP)
Su personal puede manejar datos de tarjetas de pago dentro del alcance de PCI-DSS, o expedientes de pacientes. De ser así, es posible que deba inspeccionar las cargas en busca de contenido confidencial. Eso requiere tráfico descifrado y un gateway o una herramienta DLP dedicada.
Política por persona fuera de la red
Un agente de gateway aplica la política por identidad con nombre, sincronizada desde Microsoft Entra ID, Okta o Google Workspace. Esa política sigue a una laptop administrada a la banda ancha del hogar o al WiFi del hotel. La política de Shield se establece por red y VLAN, lo que se adapta a recintos y sitios fijos. Una fuerza laboral remota en dispositivos administrados puede necesitar la aplicación por persona dondequiera que la gente se conecte.
Controles de aplicaciones
Muchos gateways decodifican el tráfico para aplicaciones específicas. Por ejemplo, pueden permitir que el personal lea un servicio de archivos compartidos pero bloquear las cargas hacia él. El filtrado DNS puede permitir o bloquear los dominios de una aplicación, pero no acciones individuales dentro de ella.
Si está evaluando estas brechas frente a su registro de riesgos, lea ¿es suficiente el filtrado DNS? para conocer los controles que funcionan junto al DNS de protección.
¿Cuánto cuesta ejecutar cada uno?
Los dos enfoques tienen precios diferentes, por lo que debe comparar sus estructuras de costos en lugar de las cifras principales. No cotizamos precios de competidores. Confirme los términos actuales con cada proveedor.
| Elemento de costo | Purple Shield (filtrado DNS) | Secure web gateway |
|---|---|---|
| Base de licenciamiento | La categoría suele cotizarse por red, por sitio o por usuario | La categoría suele cotizarse por usuario, por dispositivo o por volumen de tráfico |
| Hardware | Ninguno: funciona en el WiFi que ya opera | Ninguno para servicios en la nube; appliances para proxies locales |
| Agentes de endpoint | Ninguno en la red | Requerido para dispositivos fuera de la red e inspección completa |
| Certificados | Ninguno | Certificado raíz implementado y renovado en cada dispositivo administrado |
| Mantenimiento de políticas | Listas de categorías, permitidos y bloqueados por red y VLAN | Reglas de URL, archivos, aplicaciones y excepciones |
| Ancho de banda | Menor uso de datos con el bloqueo de anuncios activado | Todo el tráfico inspeccionado se enruta a través del proxy |
| Carga de soporte | Solicitudes de acceso y revisiones de categorías | Errores de certificado, aplicaciones fijadas rotas y solicitudes de excepción |
| Trabajo de cumplimiento | Retención de registros de dominio bajo GDPR | DPIA y aviso al personal para contenido descifrado |
El costo oculto de un gateway es la gestión de certificados y excepciones. Las aplicaciones que fijan sus certificados (certificate pinning) fallan bajo la inspección TLS, por lo que cada una necesita una excepción. La mayoría de las implementaciones eximen los sitios bancarios y de salud por razones de privacidad. Cada exención se convierte en una regla que alguien debe mantener. Los agentes también necesitan actualizarse en toda la flotilla de dispositivos. Nada de esto es un defecto; es el precio de ver el tráfico interno.
El costo operativo del filtrado DNS reside en el mantenimiento de políticas y el control de evisiones. Usted revisa las decisiones de categorías y gestiona las solicitudes de acceso. También mantiene al día las reglas de firewall para DNS cifrado a medida que aparecen nuevos resolutores públicos.
¿Qué implica moverse entre el filtrado DNS y un gateway?
De un proxy al filtrado DNS en redes de invitados
Este es el cambio más común. Los equipos a menudo descubren que un proxy en la red WiFi de invitados filtra poco más que nombres de host, ya que no puede descifrar el tráfico de los invitados. Los pasos son:
- Exporte sus categorías de proxy actuales y sus listas de acceso y bloqueo.
- Mapeelas a categorías DNS. Las reglas de ruta URL no tienen equivalente en DNS, por lo que debe decidir por regla si permite o bloquea el dominio completo.
- Apunte el servidor DNS en el alcance DHCP de cada red al resolutor de protección.
- Bloquee el DNS saliente hacia otros resolutores, DoT en el puerto 853 y los puntos de enlace DoH conocidos.
- Realice pruebas desde un dispositivo de invitados real y luego retire el conjunto de reglas del proxy para esa red.
Los pasos de configuración de Purple Shield se cubren en cómo funciona Purple Shield. Los estándares de DNS cifrado son RFC 7858 para DoT y RFC 8484 para DoH.
Agregar un gateway para dispositivos administrados
Este cambio es más complejo y debe delimitarse a los dispositivos que realmente lo necesitan. Implemente el certificado raíz a través de su plataforma de gestión de dispositivos móviles (MDM). Despliegue el agente o archivo PAC y luego cree excepciones para las aplicaciones fijadas y las categorías sensibles a la privacidad. Complete una evaluación de impacto de protección de datos (DPIA) antes de iniciar la inspección. Mantenga Purple Shield funcionando por debajo, ya que sigue cubriendo cada dispositivo que el gateway no alcanza.
Ejecutar ambos
Combinar ambos métodos en capas es el diseño más sólido en instalaciones mixtas. Purple Shield bloquea los dominios maliciosos conocidos en el momento de la resolución, tanto en la red de invitados como en la del personal. Luego, el gateway inspecciona a fondo el tráfico administrado. Como el DNS elimina primero los destinos maliciosos, llega menos tráfico hostil al proxy. Alinee ambas políticas de categorías para que un dominio bloqueado en una capa no esté permitido en la otra.
Cómo decidir entre el filtrado DNS y un secure web gateway
Utilice esta regla de decisión. Si no es propietario de los dispositivos, utilice filtrado DNS. Si es propietario de los dispositivos y debe inspeccionar el tráfico por dentro, agregue un gateway solo en esos dispositivos. En cualquier otro lugar, el DNS protectivo es la herramienta con el tamaño adecuado.
¿Qué herramienta se adapta a su red?
Purple Shield (filtrado DNS)
Fits when
- Los invitados, residentes o pasajeros traen sus propios dispositivos
- Necesita protección en múltiples sitios sin nuevo hardware
- Desea una política por red y VLAN
- Una caída nunca debe dejar una red sin filtrar
Not when
- Debe aplicar reglas en rutas de URL o tipos de archivo
Secure web gateway
Fits when
- Gestiona los dispositivos y puede desplegar un certificado raíz
- Debe inspeccionar cargas para DLP o escanear descargas
- La política debe seguir al personal identificado en cualquier red
Not when
- La mayor parte del tráfico proviene de dispositivos de invitados no gestionados
Ambos, en capas
Fits when
- Un sitio atiende a invitados y maneja datos regulados en dispositivos gestionados del personal
- Desea que el DNS reduzca el volumen que inspecciona el gateway
Not when
- Ningún dispositivo gestionado requiere inspección de contenido
Our recommendation: Despliegue Shield primero en cada red, luego agregue un gateway solo en los dispositivos gestionados donde deba inspeccionar el tráfico por dentro.
Su siguiente paso es listar sus redes y VLAN, y marcar cuáles contienen dispositivos no gestionados. Esas redes reciben DNS protectivo de inmediato. Luego consulte cómo funciona Shield para su despliegue. Para controles más amplios sobre identidad, cifrado y segmentación, lea nuestra guía de seguridad para WiFi empresarial.
Preguntas frecuentes
¿Es el filtrado DNS más económico de operar que un secure web gateway?
Por lo general, sí, porque el filtrado DNS no requiere hardware, ni agentes en el endpoint, ni gestión de certificados. Un gateway añade licencias por usuario o dispositivo, mantenimiento de agentes, renovación de certificados raíz y reglas de excepción para aplicaciones que fallan bajo inspección. El costo operativo del filtrado DNS es el mantenimiento de políticas y las reglas de firewall para DNS cifrado. Compare el costo operativo total en lugar de solo los renglones de licencias y confirme los términos actuales con cada proveedor.
¿Funciona Purple Shield con el hardware WiFi que ya poseo?
Sí. Shield funciona en la capa DNS, por lo que opera en cualquier WiFi, incluyendo Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks y Fortinet. Solo debe apuntar el DNS de cada red a Shield y configurar una política por red y VLAN. Funciona de manera independiente o junto con Purple Access, sin hardware nuevo en el sitio.
¿Puede el filtrado DNS reemplazar a un secure web gateway?
Puede hacerlo en redes de invitados y recintos, pero no donde deba inspeccionar el tráfico por dentro. El filtrado DNS bloquea dominios maliciosos y no deseados antes de que se abra cualquier conexión, lo que cubre la mayoría de las necesidades de amenazas y contenido para visitantes. No puede aplicar reglas en rutas de URL, escanear archivos en dominios de confianza ni inspeccionar cargas para la prevención de pérdida de datos. Mantenga un gateway para los dispositivos gestionados que requieran esos controles.
¿Puedo ejecutar la filtración de DNS y un gateway web seguro al mismo tiempo?
Sí, y en sitios mixtos esa es la estructura más sólida. Shield filtra cada dispositivo en la resolución de DNS, incluidos los dispositivos de invitados que un gateway no puede inspeccionar. Luego, el gateway inspecciona a detalle los dispositivos gestionados del personal. Debido a que el DNS bloquea primero los dominios maliciosos conocidos, llega menos tráfico malicioso al proxy. Mantenga alineadas las políticas de ambas categorías para que un dominio bloqueado en una capa no se permita en la otra.
¿Un gateway web seguro funciona en el WiFi?
Solo parcialmente. Sin un certificado raíz de confianza en el dispositivo, un gateway no puede descifrar HTTPS sin causar errores de certificado. No puede instalar certificados en los teléfonos de los invitados. Aun así, un gateway puede filtrar el nombre de host enviado en la negociación TLS, lo cual es muy similar a lo que la filtración de DNS ya hace con menos infraestructura. Para el WiFi, el DNS de protección es la opción más práctica.
¿Qué sucede con la filtración si el servicio DNS se cae?
Con Shield, la filtración permanece activa. Shield cuenta con protección contra fallas (fail-closed), por lo que una interrupción nunca deja a la red sin filtrar. Los servicios con falla abierta (fail-open) dirigen los dispositivos a un resolutor sin filtrar para mantener el flujo de tráfico, lo que deja a la red expuesta durante el tiempo que dure la interrupción. Solicite a cada proveedor que declare por escrito su comportamiento ante fallas y pruébelo antes de la puesta en marcha.
¿La inspección TLS es compatible con la GDPR?
Puede serlo, pero requiere mayor gobernanza que la filtración de DNS. Descifrar el tráfico del personal implica procesar el contenido de sus comunicaciones. Por lo tanto, necesita una base legal, una evaluación de impacto de la protección de datos y una notificación clara al personal. La mayoría de las implementaciones también eximen a los sitios web bancarios y de salud. La filtración de DNS solo procesa nombres de dominio, una huella más reducida que es más sencilla de justificar y documentar.
¿Cuánto esfuerzo requiere migrar de un proxy a la filtración de DNS?
Menos de lo que la mayoría de los equipos espera, ya que la transición es un cambio de DNS por red. El trabajo se divide en tres partes. Debe mapear las categorías del proxy con las categorías de DNS, decidir qué hacer con las reglas de ruta de URL que no tienen un equivalente en DNS y bloquear el DNS cifrado en el firewall. Pruebe cada red desde un dispositivo real antes de retirar el conjunto de reglas anterior.
Key terms
- Filtrado DNS (DNS de protección)
- Un resolvedor que contrasta cada dominio consultado con la inteligencia de amenazas y la política de categorías antes de responder, utilizando la resolución de nombres definida en el RFC 1035. Se rechaza la resolución de los dominios bloqueados, por lo que no se abre ninguna conexión. Lo encontrará al cambiar el servidor DNS asignado por el DHCP en cada red. Cubre los dispositivos de invitados y BYOD sin instalar nada, lo que lo convierte en la opción predeterminada para el WiFi para invitados WiFi de un recinto.
- Pasarela web segura (SWG)
- Un proxy directo en la ruta del tráfico que finaliza sesiones TLS, inspecciona URL completas, archivos y contenido de páginas, y luego vuelve a cifrar o bloquea. El tráfico llega a él a través de un agente de punto de enlace, un archivo PAC o un dispositivo en línea. Lo encontrará al definir el alcance del filtrado para los dispositivos gestionados del personal. Su costo solo se justifica donde es obligatorio inspeccionar el tráfico interno, y requiere un certificado raíz en cada dispositivo inspeccionado.
- Inspección TLS
- Descifrado de sesiones HTTPS, especificado por el protocolo Transport Layer Security (RFC 8446 para TLS 1.3), mediante la presentación de un certificado proxy firmado por una raíz en la que confía el dispositivo, seguido del cifrado posterior a la inspección. Es el motivo por el cual una pasarela no puede inspeccionar los teléfonos de los invitados, y el origen de las fallas en aplicaciones fijadas, las reglas de excepción y la gobernanza del GDPR en los dispositivos del personal.
- DNS sobre TLS (DoT)
- RFC 7858, que transporta consultas DNS dentro de una sesión TLS en el puerto TCP 853, cifrando las búsquedas entre el dispositivo y el resolvedor. Un dispositivo que utiliza DoT hacia otro resolvedor omite su filtro DNS. Bloquee el puerto 853 en el firewall antes de retirar un proxy.
- DNS sobre HTTPS (DoH)
- RFC 8484, que envía consultas DNS como solicitudes HTTPS a un punto de enlace resolvedor, lo que dificulta su distinción del tráfico web ordinario. Los resolvedores DoH codificados directamente son una forma común de eludir el sistema. Mantenga actualizadas las reglas del firewall para los puntos de enlace DoH conocidos a medida que aparezcan nuevos resolvedores públicos.
- Archivo de autoconfiguración de proxy (PAC)
- Un archivo JavaScript que indica al navegador qué proxy utilizar para cada URL. Es una de las tres formas de dirigir el tráfico a una Secure Web Gateway, junto con los agentes y los dispositivos en línea. Se implementa al distribuir una pasarela en dispositivos gestionados. No tiene ningún efecto en los dispositivos de invitados que usted no controla.
- Prevención de pérdida de datos (DLP)
- Controles que inspeccionan el contenido saliente, como cargas de archivos, en busca de datos confidenciales como información de tarjetas de pago dentro del alcance de PCI DSS o expedientes de pacientes, y evitan que salgan de la red. DLP requiere tráfico descifrado, por lo que necesita una puerta de enlace o una herramienta dedicada de DLP. El filtrado DNS no puede proporcionarlo.
- Evaluación de impacto relativa a la protección de datos (DPIA)
- Una evaluación requerida en virtud del Artículo 35 del GDPR (Reglamento (UE) 2016/679) antes de realizar un procesamiento que pueda dar lugar a un alto riesgo para los derechos y libertades de las personas. El descifrado del tráfico del personal procesa el contenido de sus comunicaciones, por lo que debe completar una DPIA y notificar al personal antes de iniciar la inspección TLS.
- IEEE 802.1X
- El estándar IEEE de control de acceso a redes basado en puertos, que autentica un dispositivo a través de EAP frente a un servidor RADIUS (Remote Authentication Dial-In User Service) antes de conceder el acceso, y puede asignar una VLAN por usuario o función. Si la red de su personal asigna VLAN por función a través de 802.1X, una directiva de DNS por VLAN le ofrece un filtrado específico por función sin necesidad de un proxy.
- VLAN
- Una LAN virtual definida por IEEE 802.1Q, que etiqueta tramas Ethernet para segmentar una red física en redes lógicas aisladas. Shield establece la directiva por red y por VLAN, de modo que una red de WiFi para invitados apta para familias y una red de personal en el mismo sitio pueden ejecutar reglas diferentes.
- Fallo de bloqueo (fail closed)
- Un modo de fallo en el que un servicio de filtrado bloquea la resolución cuando no se puede localizar, en lugar de permitir el acceso sin filtrado a través de un resolutor abierto para mantener el flujo de tráfico. En las redes de WiFi para invitados, usted asume el riesgo reputacional de cualquier contenido que se cargue. Shield aplica fallo de bloqueo, por lo que ninguna red funciona sin filtrado durante una interrupción.
- Portal cautivo
- La página de inicio de sesión que se muestra a un dispositivo antes de concederle acceso a la red, utilizada normalmente en el WiFi para invitados para la aceptación de términos y la autenticación. Mover el filtrado de invitados a un DNS de protección mantiene su portal cautivo tal como está, de modo que la experiencia de inicio de sesión de los invitados no cambia.
Worked examples
Un recinto ejecuta un proxy en su WiFi para invitados WiFi, pero como no puede descifrar el tráfico de los invitados, casi no filtra nada más allá de los nombres de host. ¿Cómo se migra esa red al filtrado DNS?
Exporte las categorías del proxy y las listas de permisos y bloqueos; luego, vincúlelas a las categorías DNS. Las reglas de rutas de URL no tienen equivalente en DNS, así que decida por cada regla si permite o bloquea el dominio completo. Apunte el servidor DNS en el alcance DHCP de cada red al resolvedor de protección. Bloquee en el firewall el tráfico DNS saliente hacia otros resolvedores, el tráfico DNS over TLS en el puerto 853 y los puntos de enlace de DNS over HTTPS conocidos. Realice una prueba desde un dispositivo de invitado real y, a continuación, retire el conjunto de reglas del proxy para esa red. Esto funciona porque la transición es un cambio de DNS por red, y el DNS de protección cubre todos los dispositivos de invitados sin necesidad de instalar nada.
Un establecimiento atiende a invitados mediante WiFi y su personal gestiona datos regulados, como datos de tarjetas de pago dentro del alcance de PCI DSS, en laptops gestionadas. ¿Qué diseño se adapta mejor?
Combine ambos en capas. Implemente primero Shield en cada red, de modo que los dispositivos de invitados y del personal se filtren en la resolución DNS. Luego, añada una pasarela únicamente en las laptops gestionadas: implemente el certificado raíz mediante su plataforma MDM, distribuya el agente o el archivo PAC y cree excepciones para aplicaciones fijadas (pinned apps) y categorías sensibles a la privacidad. Complete una DPIA antes de iniciar la inspección. Shield elimina primero los dominios maliciosos conocidos, por lo que llega menos tráfico hostil al proxy. Alinee las políticas de categorías de ambos para que un dominio bloqueado en una capa no se permita en la otra.
Frequently asked questions
¿Es más económico operar el filtrado DNS que una puerta de enlace web segura?
Por lo general, sí, porque el filtrado DNS no requiere hardware, agentes de punto de finalización ni gestión de certificados. Una puerta de enlace añade licencias por usuario o dispositivo, mantenimiento de agentes, renovación de certificados raíz y reglas de excepción para las aplicaciones que fallan al inspeccionarse. El costo operativo del filtrado DNS es el mantenimiento de directivas y las reglas de firewall para DNS cifrado. Compare el costo operativo total en lugar de los conceptos de licencias y confirme los términos vigentes con cada proveedor.
¿Funciona Purple Shield con el hardware WiFi que ya poseo?
Sí. Shield funciona en la capa DNS, por lo que se ejecuta en cualquier WiFi, incluidos Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Usted solo debe apuntar el DNS de cada red a Shield y establecer una directiva por red y VLAN. Funciona de manera independiente o junto con Purple Access, sin necesidad de hardware nuevo en las instalaciones.
¿El filtrado DNS puede reemplazar a un gateway web seguro?
Puede hacerlo en redes de recintos y para invitados, pero no donde necesite ver el tráfico interno. El filtrado DNS bloquea dominios maliciosos y no deseados antes de que se abra cualquier conexión, lo que cubre la mayoría de las necesidades de contenido y amenazas para los visitantes. No puede aplicar reglas en rutas URL, examinar archivos en dominios de confianza ni inspeccionar cargas para la prevención de pérdida de datos. Mantenga un gateway para los dispositivos administrados que requieran dichos controles.
¿Puedo ejecutar el filtrado DNS y un gateway web seguro al mismo tiempo?
Sí, y en sitios mixtos ese es el diseño más sólido. Shield filtra cada dispositivo en la resolución DNS, incluidos los dispositivos de invitados que un gateway no puede inspeccionar. Luego, el gateway inspecciona en profundidad los dispositivos administrados del personal. Dado que el DNS bloquea primero los dominios que se sabe que son dañinos, llega menos tráfico malicioso al proxy. Mantenga alineadas las dos políticas de categoría para que un dominio bloqueado en una capa no se permita en la otra.
¿Un gateway web seguro funciona en el WiFi para invitadosWiFi?
Solo parcialmente. Sin un certificado raíz de confianza en el dispositivo, un gateway no puede descifrar HTTPS sin causar errores de certificado. No se pueden instalar certificados en los teléfonos de los invitados. Un gateway aún puede filtrar en el nombre de host enviado en el protocolo de enlace TLS, lo cual es similar a lo que el filtrado DNS ya hace con menos infraestructura. Para el WiFi, el DNS de protección es la opción práctica.
¿Qué sucede con el filtrado si el servicio DNS deja de funcionar?
Con Shield, el filtrado se mantiene activo. Shield utiliza un modo de falla de bloqueo (fail-closed), por lo que una interrupción nunca deja una red sin filtrar. Los servicios que utilizan un modo de falla de apertura (fail-open) envían los dispositivos a un solucionador sin filtrar para mantener el flujo del tráfico, lo que deja la red expuesta durante el tiempo que dure la interrupción. Solicite a cada proveedor que declare por escrito su comportamiento ante fallas y pruébelo antes de la puesta en marcha.
¿La inspección TLS es compatible con la GDPR?
Puede serlo, pero requiere más gobernanza que el filtrado DNS. El descifrado del tráfico del personal procesa el contenido de sus comunicaciones. Por lo tanto, usted necesita una base legal, una evaluación de impacto de la protección de datos y un aviso claro para el personal. La mayoría de las implementaciones también eximen a los sitios web bancarios y de salud. El filtrado DNS solo procesa nombres de dominio, una huella más reducida que es más simple de justificar y documentar.
¿Cuánto esfuerzo requiere migrar de un proxy al filtrado DNS?
Menos de lo que la mayoría de los equipos espera, porque la transición consiste en un cambio de DNS por red. El trabajo se divide en tres partes: asignar categorías de proxy a categorías de DNS, decidir qué hacer con las reglas de ruta URL que no tienen equivalente en DNS y bloquear el DNS cifrado en el firewall. Pruebe cada red desde un dispositivo real antes de retirar el antiguo conjunto de reglas.