Filtrado DNS para MSPs y propiedades multisitio

El filtrado DNS para MSP y redes multisitio verifica las solicitudes de dominio con respecto a las políticas de seguridad en la nube antes de que los dispositivos se conecten. Gestionado de forma centralizada a través de Purple junto con SSIDs, Captive Portals y analíticas, no requiere hardware en el sitio. Al operar en integraciones como Cisco Meraki y HPE Aruba, Purple protege redes que abarcan más de 80,000 ubicaciones activas sin necesidad de agentes.

¿Qué es el filtrado DNS para MSP y redes multisitio?

Cada conexión que realiza un dispositivo comienza con una búsqueda DNS (Domain Name System). El dispositivo solicita a un resolutor que transforme un nombre como ejemplo.com en una dirección IP. El filtrado DNS, también llamado DNS de protección, verifica ese nombre con respecto a una política antes de responder. Si el dominio es malicioso o incumple la política, el resolutor omite la dirección real. El dispositivo nunca abre una conexión, por lo que no se descarga nada ni se carga ninguna página.

Para una sola ubicación, este es un control útil. Para un proveedor de servicios gestionados (MSP) o un equipo de TI multisitio, el requisito cambia de forma. Usted filtra docenas o cientos de redes, propiedad de diferentes clientes, con diferentes reglas y en diferente hardware. Esto genera tres requisitos que un filtro de un solo sitio rara vez cumple:

• Política por cliente. Un cliente es una empresa o unidad de negocio con sus propias reglas. Un grupo hotelero familiar, una cadena de restaurantes y un consultorio médico nunca deberían compartir la misma política.
• Gestión centralizada. Necesita ver y cambiar la política de cada cliente desde un solo lugar, sin iniciar sesión en cada sitio.
• Sin hardware por sitio. Enviar, montar en rack y parchear un equipo físico en cada ubicación no es escalable a través de una flota de red.

Purple Shield es el complemento de DNS de protección de Purple, junto con SecurePass y Verify. El filtrado se ejecuta en la nube y se vincula a los SSIDs (nombres de red), Captive Portals y analíticas que ya gestiona para cada cliente. Un Captive Portal es la página de inicio de sesión que ve un visitante antes de conectarse a internet.

En qué se diferencia el filtrado para MSP de una implementación en un solo sitio

Un filtro para un solo sitio tiene una política, un administrador y una red. La red de un MSP tiene una jerarquía. Se definen reglas para la flota de red, se anulan por cliente y luego se varían por red dentro de un sitio. La red de invitados de un hotel necesita reglas diferentes a las de la red del personal ubicada detrás de la recepción.

Los filtros DNS independientes suelen gestionar esto con una suborganización por cliente, configurada de forma independiente del WiFi. Se termina ejecutando dos plataformas para cada cliente: una para la red y el portal, y otra para el resolutor. Purple Shield elimina la segunda plataforma, ya que la política de filtrado sigue a las redes que ya definió en Purple.

¿Por qué es importante el filtrado DNS en una flota de sitios de clientes?

Tres factores impulsan el filtrado en la agenda de un MSP: el deber de protección, la exposición a amenazas y el ancho de banda limitado.

Deber de protección en redes compartidas

El WiFi público y para invitados conlleva obligaciones reales. En Inglaterra, las escuelas y colegios siguen los estándares de filtrado y monitoreo del Departamento de Educación, contemplados en Keeping children safe in education. En EE. UU., la Ley de Protección de los Niños en Internet (CIPA) exige filtrar a las escuelas y bibliotecas que reciben fondos de E-rate. Los hoteles, cafeterías y centros de recreación que reciben familias se enfrentan a riesgos reputacionales si un menor accede a contenido para adultos. El esquema Friendly WiFi del Reino Unido existe exactamente por esa razón.

Cuando gestionas el WiFi de 40 clientes, asumes una parte de cada obligación. Un solo sitio no filtrado se convierte en una conversación con un cliente que preferirías evitar.

Amenazas que alcanzan a los dispositivos no gestionados

No puedes instalar un agente en el teléfono de un visitante ni puedes parchearlo. Los enlaces de phishing, las descargas de malware y las llamadas de retorno de comando y control comienzan con una búsqueda DNS. Esto convierte a la búsqueda en el único punto que puedes controlar para cada dispositivo en la red.

Shield marca las amenazas en la etapa de búsqueda DNS, deteniendo las peticiones maliciosas antes de que se completen las conexiones. En toda una flotilla de redes, el bloqueo de una amenaza se aplica en cada sitio de cliente al mismo tiempo. Para ver un panorama más amplio del mercado, consulta Phishing Protection Software: 10 Options for Shared WiFi.

Ancho de banda en sitios con limitaciones

Muchas instalaciones ejecutan WiFi para invitados con una red de transporte modesta: un router 4G en una estación de servicio, una línea compartida en un pub o un circuito saturado en una estación. El tráfico de anuncios y el contenido web no deseado compiten con todo lo demás. Filtrar anuncios y dominios maliciosos en la capa DNS reduce el consumo de datos de la red y mejora las velocidades de carga. En un sitio congestionado, ese margen recuperado vuelve al tráfico que los invitados realmente buscan.

Lo que se le escapa a un firewall

Un firewall sigue siendo importante, pero funciona en un punto diferente. Inspecciona las conexiones después de que el DNS ya ha respondido. Eso deja cuatro brechas en una red de invitados multisitio:

1. El cifrado oculta el destino. TLS 1.3 (RFC 8446) cifra el certificado del servidor. Encrypted Client Hello (ECH), una extensión IETF para TLS, también puede ocultar el nombre del servidor. Sin descifrado, un firewall solo ve una dirección IP y poco más, y no es posible instalar un certificado de descifrado en el dispositivo de un visitante.
2. Las direcciones IP compartidas confunden las reglas. Las redes de distribución de contenido alojan muchos dominios en las mismas direcciones. Si bloqueas la IP, rompes sitios legítimos; si la permites, el dominio dañino logra pasar.
3. Las reglas por sitio se desalinean. Una infraestructura creada a lo largo de los años combina diferentes proveedores de firewall y versiones de firmware. Mantener alineadas 60 reglas es un trabajo de tiempo completo, y un solo sitio olvidado representa una vulnerabilidad.
4. El bloqueo llega demasiado tarde. Para cuando el firewall actúa, el dispositivo ya ha resuelto el nombre e intentado una conexión. El filtrado DNS detiene la petición antes de que exista conexión alguna.

El filtrado DNS cierra estas brechas sin descifrado, agentes ni reglas por sitio. No reemplaza la función del firewall de segmentar redes y controlar puertos.

¿Cómo funciona el filtrado DNS en entornos multitenant?### Qué ocurre durante cada búsqueda

1. Un invitado se conecta al WiFi del cliente, a menudo a través de un Captive Portal.
2. El dispositivo solicita un dominio, por ejemplo, desde un enlace en un correo electrónico de phishing.
3. Purple Shield verifica el dominio con la política asignada a esa red.
4. Si el dominio está permitido, el dispositivo recibe la dirección y se conecta de forma normal.
5. Si está bloqueado, la búsqueda no devuelve la dirección real, por lo que no se abre ninguna conexión.

Cómo estructurar la política por arrendatario

El filtrado de contenido por arrendatario funciona mejor como un conjunto pequeño de políticas estándar, en lugar de un conjunto de reglas a la medida por sitio. Este patrón se mantiene en los sectores de hospitalidad, retail y el sector público:

• Línea base de seguridad. Malware, phishing y otras categorías de amenazas se bloquean en cada red, para cada arrendatario. Nadie queda fuera.
• Invitado familiar. La línea base más contenido para adultos y no apto para ciertas edades. Ideal para hoteles familiares, bibliotecas, centros de entretenimiento, escuelas y salas de espera de atención médica.
• Invitado adulto. La línea base con reglas de contenido más flexibles. Ideal para bares, recintos nocturnos y hoteles de negocios.
• Personal. La línea base más reglas que reflejan la política de uso aceptable de cada cliente.

Asigne una política por red y, luego, agregue excepciones de clientes solo donde la empresa las necesite. El equipo de marketing de un hotel puede necesitar plataformas sociales que una escuela bloquearía. Cuatro políticas y una lista corta de excepciones son mucho más fáciles de auditar que 60 conjuntos de reglas creados manualmente.

Debido a que Purple Shield vincula la política a las redes que ejecuta en Purple, los SSID de invitados y personal de un sitio pueden llevar diferentes políticas. Las redes del personal que usan 802.1X, el estándar para el control de acceso a redes basado en puertos, conservan sus controles de identidad. Purple Shield agrega la capa de DNS encima.

Gestión de una flota desde un solo panel de control

La gestión centralizada de políticas DNS solo rinde frutos si se adapta a su forma de trabajar actual. Purple Shield se encuentra en la misma plataforma Purple que ejecuta los SSID, Captive Portals y analíticas de cada cliente. No tiene que cambiar de consola para cambiar un filtro y no mantiene un segundo inventario de sitios.

Esto tiene consecuencias prácticas para un MSP:

• Integración. Un nuevo sitio de cliente en Purple no necesita una cuenta de resolución independiente.
• Control de cambios. Cambie una política una vez y se aplicará a cada red asignada a ella.
• Reportes. La actividad de filtrado se ubica junto a las analíticas de conexión que ya comparte, de modo que una revisión trimestral cubre WiFi y seguridad.

Por qué no hay nada que enviar

Purple Shield filtra en la nube, por lo que no hay ningún equipo físico que comprar, configurar, enviar o reemplazar en cada ubicación. Purple es independiente del hardware y se ejecuta como una superposición en la nube en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti, UniFi, Cambium, Extreme Networks y Fortinet. La propiedad de un cliente que combina proveedores después de adquisiciones sigue ejecutando un solo conjunto de políticas. La configuración varía según el proveedor, así que consulte la documentación de soporte de Purple para su hardware.

Purple ya opera en más de 80,000 ubicaciones activas y registró 440 millones de inicios de sesión en 2024 (datos de Purple).

¿Cómo se ve el filtrado DNS en una propiedad real?

Los tres escenarios a continuación son modelos integrados basados en configuraciones comunes de instalaciones. El número de sitios y el hardware son los típicos; los resultados son la aritmética operativa de cada cambio.

Escenario 1: un MSP con 14 clientes del sector hospitalidad

Situación. Un MSP administra WiFi para invitados y personal para 14 clientes de la industria de la hospitalidad en 60 sitios. La combinación incluye hoteles independientes, un grupo de 20 pubs y un parque vacacional. El WiFi y los Captive Portals ya funcionan con Purple. El filtrado se ejecutaba en un servicio DNS independiente, con una cuenta y lista de sitios por cliente.

Lo que se hizo. El MSP movió el filtrado a Shield y reemplazó 14 conjuntos de reglas personalizados con las cuatro políticas estándar. Los hoteles familiares y el parque vacacional adoptaron la política para invitados familiares; el grupo de pubs adoptó la de invitados adultos. Dos clientes conservaron listas cortas de excepciones.

Resultado. Cero envíos de hardware y cero visitas a los sitios en las 60 ubicaciones. El MSP retiró 14 cuentas de filtrado independientes y ahora gestiona a todos los clientes desde el panel de Purple que ya utilizaba. Un cambio de regla implica editar una de las cuatro políticas, no hasta 60 entradas de sitios.

Escenario 2: bibliotecas y centros recreativos de un ayuntamiento

Situación. Un ayuntamiento ofrece WiFi público en 22 bibliotecas y cinco centros recreativos. Los niños usan las redes de la biblioteca después de la escuela. Dos rondas de licitaciones dejaron HPE Aruba en las bibliotecas y Ubiquiti UniFi en los centros recreativos. El equipo de TI consta de tres personas.

Lo que se hizo. El ayuntamiento aplicó la política para invitados familiares a cada SSID público y la política de personal a las redes de los empleados. La autenticación del personal se mantiene en 802.1X con WPA3-Enterprise, el estándar actual de cifrado para WiFi empresarial. Los visitantes siguen conectándose a través del Captive Portal del ayuntamiento.

Resultado. Los 27 sitios ejecutan una misma política pública en dos proveedores de hardware distintos, sin necesidad de ningún dispositivo físico adicional en ningún lugar. Una sola edición llega a los 27 sitios. El ayuntamiento muestra a los auditores una sola política y una sola fuente de registros, en lugar de 27 configuraciones locales.

Escenario 3: una tienda minorista de 120 sucursales con red de transporte limitada

Situación. Una empresa minorista ofrece WiFi para invitados a los compradores en 120 tiendas, un tercio de ellas con red de transporte 4G. La navegación de los compradores compite por el ancho de banda con los sistemas de la tienda. El entorno de datos de los titulares de tarjetas ya está segmentado del tráfico de invitados para mantenerlo fuera del alcance de PCI DSS.

Lo que se hizo. La empresa minorista habilitó la protección contra amenazas y el bloqueo de anuncios de Shield únicamente en el SSID de invitados. Comenzó con una prueba piloto de 10 tiendas en sus sitios 4G con mayor tráfico. Las redes del personal y de los sistemas de la tienda se mantuvieron en sus propios segmentos.

Resultado. La prueba piloto midió su propio uso antes y después durante cuatro semanas, demostrando un menor consumo total de datos en conexiones limitadas. Posteriormente, la empresa minorista extendió la política a las 120 tiendas en un solo cambio, sin realizar ninguna visita a las sucursales.

¿Dónde se ubica el filtrado DNS en relación con lo que ya opera?

El DNS de protección es una capa más. Funciona mejor junto con los controles que probablemente ya posee.

• Segmentación. Las VLANs (LANs virtuales que dividen una red física en redes lógicas aisladas) mantienen el tráfico de invitados separado del personal y de los sistemas de pago. Consulta Cómo configurar la segmentación de red para invitados y personal.
• Autenticación. 802.1X con RADIUS, el protocolo que verifica credenciales contra un servidor central, decide quién se une a la red del personal. De la misma manera lo hace SecurePass con Microsoft Entra ID, Okta o Google Workspace. Shield decide a dónde pueden ir los dispositivos una vez conectados.
• Firewalls. Tu firewall sigue controlando puertos, protocolos y tráfico entre segmentos. Shield bloquea destinos maliciosos conocidos desde la consulta.
• Ley de privacidad. Los registros de DNS pueden contener direcciones IP e identificadores de dispositivos, los cuales el GDPR considera datos personales. Purple cumple con el GDPR y cuenta con la certificación ISO 27001.

Cómo se compara Shield con DNSFilter y Cisco Umbrella

DNSFilter y WebTitan se enfocan fuertemente en los MSPs, y Cisco Umbrella es la opción predeterminada en muchas infraestructuras de Cisco. Todos filtran en la capa de DNS en la nube. Las diferencias radican en quién gestiona qué y dónde.

Criterio	Purple Shield	DNSFilter	Cisco Umbrella
Dónde ocurre el filtrado	Consulta DNS, en la nube de Purple	Consulta DNS, en la nube de DNSFilter	Consulta DNS, en la nube de Cisco
Hardware por sitio	Ninguno	Ninguno para filtrado de red	Ninguno para protección a nivel de DNS
Gestión de inquilinos	Dentro del panel de Purple que opera el WiFi de los clientes	Consola de MSP independiente con suborganizaciones	Consola independiente multiorganización o de MSP
Vinculado a SSIDs, portales cautivos y analíticas de WiFi	Sí, nativo de la plataforma de WiFi	No, se configura como un stack independiente	Se integra con Cisco Meraki y se gestiona en su propia consola
Dispositivos en itinerancia fuera de las instalaciones	Diseñado para dispositivos en el WiFi que administras	Agente de cliente itinerante	Módulo itinerante de Cisco Secure Client
Cobertura de hardware	Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, Fortinet	Cualquier red que pueda reenviar DNS a sus resolutores	Cualquier red que pueda reenviar DNS a sus resolutores, con mayor integración en Cisco
Más adecuado para	MSPs cuyo WiFi de clientes se ejecuta en Purple	MSPs que protegen endpoints gestionados dentro y fuera de las instalaciones	Infraestructuras estandarizadas en la seguridad de Cisco

Las alternativas son sólidas en áreas donde Shield no compite. Tanto DNSFilter como Cisco Umbrella ofrecen agentes itinerantes para laptops gestionadas fuera del sitio. Umbrella también se integra dentro del portafolio de seguridad más amplio de Cisco. WebTitan, de TitanHQ, también ofrece un filtro en la nube multi-tenant para MSPs. Si tus contratos cubren endpoints corporativos a donde sea que viajen, una de esas opciones puede ser adecuada.

El caso de Shield es más concreto y, para los MSP orientados a WiFi, más sólido. Si gestionas los SSID, Captive Portals y analíticas de cada cliente en Purple, mantener una pila de resolución independiente por cliente genera costos operativos innecesarios. Para más detalles, lee Shield vs DNSFilter: a protective DNS comparison for WiFi operators y Shield vs Cisco Umbrella: choosing protective DNS for guest WiFi.

¿Cuáles son los límites del filtrado DNS que debes conocer?

El filtrado DNS actúa en un punto específico de la conexión, lo que define sus límites.

• El DNS cifrado puede evadirlo. DNS over HTTPS (DoH, RFC 8484) y DNS over TLS (DoT, RFC 7858) permiten que un dispositivo elija su propio resolvedor. Los controles de red pueden reducir esto en dispositivos no administrados, pero no eliminarlo por completo. Consulta DNS over HTTPS explained: privacy vs public WiFi filtering.
• Las VPN crean túneles que lo esquivan. Un usuario en una VPN personal resuelve nombres dentro del túnel. Puedes bloquear dominios de VPN conocidos, pero no absolutamente todos.
• Las conexiones IP directas omiten el DNS. El malware que llama a una dirección IP fija nunca realiza una búsqueda DNS. Tu firewall se encarga de ese caso.
• Ve dominios, no contenido. El filtrado DNS permite o bloquea un dominio entero, no páginas o archivos individuales.
• Las categorías requieren revisión. Cualquier lista de categorías a veces bloqueará de más o de menos. Asigna a cada cliente un contacto nombrado y un canal para solicitar cambios.
• Los registros necesitan gobernanza. Acuerda la retención y el acceso por cliente antes de la implementación, y regístralo en tu acuerdo de procesamiento de datos.

¿Qué debes hacer a continuación?

1. Mapea a tus clientes. Enumera cada cliente, sitio y red, incluyendo su sector e imponderables normativos como escuelas, bibliotecas, sector salud y establecimientos con licencia.
2. Redacta políticas estándar. Comienza con las cuatro anteriores y mantén la base de seguridad como obligatoria.
3. Realiza una prueba piloto en sitios representativos. Elige un sitio por sector, incluyendo uno con enlace de respaldo restringido, y mide el uso de datos antes y después.
4. Implementa por política, no por sitio. Asigna políticas a las redes de cada cliente y luego revisa las excepciones después de 30 días.
5. Informa los resultados. Agrega la actividad de filtrado a las revisiones de WiFi que ya entregas.

Si el WiFi de tus clientes aún no funciona con Purple, comienza con Guest WiFi y luego agrega Shield. Para obtener más información sobre cómo proteger las redes en todas tus instalaciones, explora All guides.

Preguntas frecuentes

¿Necesito instalar hardware en cada sitio de cliente para usar el filtrado DNS?

No. Shield filtra en la capa DNS en la nube, por lo que no hay ningún equipo físico que comprar, configurar o enviar a ninguna ubicación. Purple se ejecuta como una superposición en la nube en los puntos de acceso que tus clientes ya poseen, incluidos Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks y Fortinet. La configuración varía según el proveedor, así que sigue la documentación de soporte de Purple para cada tipo de hardware en tus instalaciones.

¿Puedo establecer diferentes políticas de filtrado para cada cliente y cada red?

Sí. Shield vincula la política de filtrado a las redes que ya ejecutas en Purple, por lo que cada cliente, y cada SSID dentro de un sitio, puede llevar su propia política. La red de invitados de un hotel puede bloquear contenido para adultos mientras que su red de personal aplica las reglas de uso aceptable del cliente. Un conjunto pequeño de políticas estándar, más listas cortas de excepciones, es más fácil de auditar que reglas personalizadas por sitio.

¿Puedo gestionar el filtrado de contenido para muchos sitios desde un solo panel de control?

Sí. Shield se gestiona en la misma plataforma de Purple que ejecuta los SSID, los portales cautivos y la analítica de tus clientes, por lo que cambias el filtrado sin cambiar de consola. Un cambio de política se aplica a cada red asignada a esa política, en cada sitio. La actividad de filtrado se ubica junto a tus informes de WiFi existentes, por lo que una sola revisión de cliente cubre la conectividad y la seguridad al mismo tiempo.

¿Cómo se compara Shield con DNSFilter para un MSP?

Shield se adapta a los MSP cuyos WiFi de clientes ya se ejecutan en Purple, mientras que DNSFilter se adapta a los MSP que protegen laptops gestionadas dentro y fuera del sitio. Ambos filtran en la capa DNS en la nube sin hardware por sitio. DNSFilter se ejecuta como una consola multinquilino independiente con un agente itinerante. Shield se ejecuta dentro de la plataforma de WiFi, vinculado a los mismos SSID, portales cautivos y analítica que ya gestionas.

¿Pueden los invitados eludir el filtrado DNS con DNS over HTTPS o una VPN?

Sí, un invitado determinado puede hacerlo. DNS over HTTPS, DNS over TLS y las VPN personales envían búsquedas fuera de tu resolutor. Los controles de red pueden reducir esto, por ejemplo, bloqueando puntos de enlace conocidos de VPN y DoH públicos, pero ningún filtro DNS controla por completo un dispositivo no gestionado. Trata el filtrado DNS como la protección predeterminada para cada dispositivo que utilice el DNS de la red, junto con la segmentación y tu firewall.

¿El filtrado DNS ayuda a las escuelas y bibliotecas a cumplir con los requisitos de filtrado?

Cubre el elemento de filtrado, pero el filtrado por sí solo no cumple con el requisito completo. En Inglaterra, los estándares de filtrado y monitoreo del Departamento de Educación esperan tanto filtrado como monitoreo, con responsabilidades designadas y revisión regular. En los EE. UU., CIPA exige que las escuelas y bibliotecas financiadas por E-rate utilicen medidas de protección tecnológica dentro de una política de seguridad en internet. Combina un filtrado constante en todos los sitios con tus procesos de monitoreo y salvaguarda.

¿Cómo se manejan los registros de consultas DNS según el GDPR?

Purple cumple con el GDPR y cuenta con la certificación ISO 27001. Los registros de DNS pueden incluir direcciones IP e identificadores de dispositivos, que el GDPR trata como datos personales. Acuerda la retención, el acceso y la finalidad con cada cliente antes de la implementación, y registra esos términos en tu acuerdo de procesamiento de datos. Como MSP, a menudo actuarás como procesador para tus clientes, así que documenta quién controla los registros de cada propiedad.

¿Cómo se establecen los precios de Shield para una propiedad de múltiples sitios?

Shield es un complemento de seguridad para la plataforma Purple, junto con SecurePass y Verify, por lo que puedes agregarlo a los sitios que ya operan con Purple. No requiere hardware por sitio, por lo que no hay costos de equipos, envío o reemplazo que contemplar. Solicita a Purple una cotización basada en tu número de clientes y sitios, e incluye cualquier sitio que planees incorporar este año.