Filtrado DNS para MSP y fincas multisitio

El filtrado DNS para MSP y redes multisede comprueba las solicitudes de dominio con 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 SSID, Captive Portals y analíticas, no requiere hardware in situ. Funcionando mediante integraciones como Cisco Meraki y HPE Aruba, Purple protege redes que abarcan más de 80.000 recintos activos sin necesidad de agentes.

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

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 denominado DNS de protección, comprueba ese nombre con una política antes de responder. Si el dominio es malicioso o no cumple con la política, el resolutor omite la dirección real. El dispositivo nunca abre una conexión, por lo que no se descarga nada y no se carga ninguna página.

Para un solo recinto, se trata de un control útil. Para un proveedor de servicios gestionados (MSP) o un equipo de TI multisede, la necesidad cambia de forma. Usted filtra docenas o cientos de redes, propiedad de diferentes clientes, con diferentes reglas y en diferente hardware. Esto conlleva tres requisitos que un filtro para un solo sitio rara vez cumple:

• Política por cliente. Un cliente o unidad de negocio cuenta con sus propias reglas. Un grupo hotelero familiar, una cadena de pubs y un centro de salud nunca deberían compartir la misma política.
• Gestión centralizada. Necesita ver y cambiar la política de cada cliente desde un único lugar, sin tener que iniciar sesión en cada sitio.
• Sin hardware por sede. Enviar, montar en rack y parchear un dispositivo en cada ubicación no es escalable en toda una flota.

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 SSID (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 un despliegue 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 establecen reglas para toda la 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 que está detrás de la recepción.

Los filtros DNS independientes suelen gestionar esto con una suborganización por cliente, configurada de forma independiente a la propia WiFi. Se acaba ejecutando dos entornos para cada cliente: uno para la red y el portal, y otro para el resolutor. Shield elimina el segundo entorno, ya que la política de filtrado sigue a las redes que ya ha definido en Purple.

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

Tres presiones sitúan al filtrado en la prioridad 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, los colegios e institutos siguen las normas de filtrado y supervisión del Ministerio de Educación, recogidas en Keeping children safe in education. En EE. UU., la Ley de Protección de la Infancia en Internet (CIPA) exige filtrar a las escuelas y bibliotecas que reciben fondos E-rate. Los hoteles, cafeterías y centros de ocio que acogen a familias se enfrentan a riesgos de reputación si un menor accede a contenido para adultos. El programa Friendly WiFi del Reino Unido existe exactamente por ese motivo.

Cuando gestiona el WiFi de 40 clientes, asume una parte de cada obligación. Un solo sitio no filtrado se traduce en una conversación con el cliente que no querrá tener.

Amenazas que alcanzan a los dispositivos no gestionados

No es posible instalar un agente en el teléfono de un visitante, ni tampoco parchearlo. Los enlaces de phishing, las descargas de malware y las llamadas de retorno a servidores de comando y control comienzan siempre con una consulta DNS. Eso convierte a la consulta en el único punto de control sobre cada dispositivo de la red.

Shield marca las amenazas en la fase de consulta DNS, deteniendo las peticiones maliciosas antes de que se completen las conexiones. En toda una flota de red, el bloqueo de una amenaza se aplica en las instalaciones de cada cliente al mismo tiempo. Para ver una perspectiva más amplia del mercado, consulte Phishing Protection Software: 10 Options for Shared WiFi.

Ancho de banda en ubicaciones con limitaciones

Muchas propiedades ejecutan el WiFi de invitados sobre conexiones modestas: 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 una ubicación saturada, 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 actúa en un punto diferente. Inspecciona las conexiones después de que el DNS ya ha respondido. Eso deja cuatro brechas en un entorno de invitados de múltiples ubicaciones:

1. El cifrado oculta el destino. TLS 1.3 (RFC 8446) cifra el certificado del servidor. Encrypted Client Hello (ECH), una extensión del 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 se puede instalar un certificado de descifrado en el dispositivo de un visitante.
2. Las direcciones IP compartidas difuminan las reglas. Las redes de distribución de contenidos albergan muchos dominios en las mismas direcciones. Si bloquea la IP, romperá sitios legítimos; si la permite, el dominio dañino conseguirá pasar.
3. Los conjuntos de reglas por ubicación se descompensan. Una flota construida a lo largo de los años combina diferentes proveedores de firewall y versiones de firmware. Mantener alineados 60 conjuntos de reglas es un trabajo a tiempo completo, y una sola ubicación olvidada se convierte en una brecha.
4. El bloqueo llega tarde. Para cuando el firewall actúa, el dispositivo ya ha resuelto el nombre y ha intentado la conexión. El filtrado DNS detiene la petición antes de que exista conexión alguna.

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

¿Cómo funciona el filtrado DNS en entornos multicliente?

Qué ocurre durante cada consulta

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, a partir de un enlace en un correo electrónico de phishing.
3. Shield comprueba el dominio con respecto a la directiva asignada a esa red.
4. Si el dominio está permitido, el dispositivo recibe la dirección y se conecta con normalidad.
5. Si está bloqueado, la consulta no devuelve la dirección real, por lo que no se abre ninguna conexión.

Cómo estructurar la directiva por cliente

El filtrado de contenidos por cliente funciona mejor como un pequeño conjunto de directivas estándar, no como un conjunto de reglas a medida por centro. Este patrón se mantiene en los sectores de hostelería, comercio minorista y sector público:

• Línea base de seguridad. El software malicioso, el phishing y otras categorías de amenazas se bloquean en todas las redes y para todos los clientes. Nadie queda excluido.
• Invitados familiares. La línea base más contenido para adultos e inadecuado para la edad. Adecuado para hoteles familiares, bibliotecas, centros de ocio, colegios y salas de espera de atención sanitaria.
• Invitados adultos. La línea base con reglas de contenido más ligeras. Adecuado para bares, locales nocturnos y hoteles de negocios.
• Personal. La línea base más las reglas que reflejan la política de uso aceptable de cada cliente.

Asigne una directiva por red y, a continuación, añada excepciones de clientes únicamente donde una empresa las necesite. El equipo de marketing de un hotel puede necesitar plataformas sociales que un colegio bloquearía. Cuatro directivas y una lista corta de excepciones son mucho más fáciles de auditar que 60 conjuntos de reglas creados manualmente.

Dado que Shield asocia la directiva a las redes que gestiona en Purple, los SSID de invitados y de personal de un centro pueden llevar diferentes directivas. Las redes de personal que utilizan IEEE 802.1X, el estándar para el control de acceso a redes basado en puertos, mantienen sus controles de identidad. Shield añade la capa DNS por encima.

Gestión de un parque de dispositivos desde un único panel de control

La gestión centralizada de la directiva DNS solo merece la pena si coincide con su forma de trabajar habitual. Shield se encuentra en la misma plataforma Purple que gestiona los SSID, los Captive Portal y las analíticas de cada cliente. No tiene que cambiar de consola para modificar un filtro ni mantiene un segundo inventario de centros.

Esto tiene consecuencias prácticas para un MSP:

• Incorporación. Un nuevo centro de cliente en Purple no necesita una cuenta de resolutor independiente.
• Control de cambios. Modifique una directiva una vez y se aplicará a cada red asignada a ella.
• Informes. La actividad de filtrado se sitúa junto a las analíticas de conexión que ya comparte, de modo que una sola revisión trimestral cubre el WiFi y la seguridad.

Por qué no hay nada que enviar físicamente

Shield filtra en la nube, por lo que no hay ningún equipo físico que comprar, configurar, enviar o sustituir en cada ubicación. Purple es independiente del hardware y funciona como una capa superpuesta en la nube sobre Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks y Fortinet. Un parque de clientes que combine varios fabricantes tras distintas adquisiciones seguirá ejecutando un único conjunto de directivas. La configuración varía según el fabricante, por lo que debe seguir la documentación de soporte de Purple correspondiente a su hardware.

Purple ya funciona en más de 80.000 centros activos y registró 440 millones de inicios de sesión en 2024 (datos de Purple).

¿Cómo se ve el filtrado DNS en un parque de centros real?

Los tres escenarios siguientes son composiciones creadas a partir de estructuras habituales de instalaciones. El número de ubicaciones 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 hostelero

Situación. Un MSP gestiona la red WiFi para invitados y personal para 14 clientes del sector hostelero en 60 ubicaciones. La combinación incluye hoteles independientes, un grupo de pubs con 20 locales y un parque de vacaciones. La red WiFi y los Captive Portals ya funcionan con Purple. El filtrado se ejecutaba en un servicio DNS independiente, con una cuenta y una lista de ubicaciones por cliente.

Qué se hizo. El MSP trasladó el filtrado a Shield y sustituyó 14 conjuntos de reglas personalizados por las cuatro directivas estándar. Los hoteles familiares y el parque de vacaciones adoptaron la directiva para invitados familiares; el grupo de pubs adoptó la de invitados adultos. Dos clientes mantuvieron listas reducidas de excepciones.

Resultado. Cero hardware enviado y cero visitas a las instalaciones en 60 ubicaciones. El MSP retiró 14 cuentas de filtrado independientes y ahora gestiona a cada cliente desde el panel de control de Purple que ya utilizaba. Modificar una regla supone editar una de las cuatro directivas, en lugar de hasta 60 entradas de ubicación.

Escenario 2: las bibliotecas y centros deportivos de un ayuntamiento

Situación. Un ayuntamiento ofrece WiFi pública en 22 bibliotecas y cinco centros deportivos. Los niños utilizan las redes de las bibliotecas después del colegio. Dos rondas de licitaciones dejaron HPE Aruba en las bibliotecas y Ubiquiti UniFi en los centros deportivos. El equipo de TI está formado por tres personas.

Qué se hizo. El ayuntamiento aplicó la directiva para invitados familiares a todos los SSID públicos y la directiva 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. Las 27 ubicaciones ejecutan una única directiva pública en dos proveedores de hardware diferentes, sin necesidad de appliances en ningún punto. Una sola edición llega a las 27 ubicaciones. El ayuntamiento muestra a los auditores una sola directiva y una sola fuente de registros, no 27 configuraciones locales.

Escenario 3: una cadena minorista de 120 tiendas con conexiones de red limitadas

Situación. Una empresa minorista ofrece WiFi para invitados a los compradores en 120 tiendas, un tercio de ellas con conexiones de respaldo 4G. La navegación de los clientes compite con los sistemas de la tienda por el ancho de banda. 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.

Qué se hizo. La empresa minorista activó la protección contra amenazas de Shield y el bloqueo de anuncios únicamente en el SSID para invitados. Comenzó con un piloto de 10 tiendas en sus ubicaciones 4G con mayor tráfico. Las redes del personal y de los sistemas de la tienda se mantuvieron en sus propios segmentos.

Resultado. El piloto midió el uso antes y después durante cuatro semanas, demostrando una reducción en el consumo general de datos en las conexiones limitadas. A continuación, la empresa minorista amplió la directiva a las 120 tiendas en un solo cambio, sin necesidad de visitar ninguna tienda.

¿Dónde se sitúa el filtrado DNS junto a lo que ya ejecuta?

El DNS de protección es solo una capa. Funciona mejor junto a los controles que probablemente ya posea.

• Segmentación. Las VLAN (LAN 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 las credenciales con un servidor central, decide quién se une a la red del personal. Lo mismo hace SecurePass con Microsoft Entra ID, Okta o Google Workspace. Shield decide adónde pueden acceder los dispositivos una vez conectados.
• Firewalls. Tu firewall sigue controlando los puertos, los protocolos y el tráfico entre segmentos. Shield bloquea los destinos maliciosos conocidos directamente en la consulta.
• Normativa de privacidad. Los registros DNS pueden contener direcciones IP e identificadores de dispositivos, que el GDPR considera datos personales. Purple cumple con el GDPR y cuenta con la certificación ISO 27001.

Comparativa de Shield con DNSFilter y Cisco Umbrella

DNSFilter y WebTitan están muy orientados a los MSP, y Cisco Umbrella es la opción predeterminada en muchas infraestructuras Cisco. Todos ellos filtran en la capa DNS dentro de la nube. Las diferencias radican en quién gestiona qué y dónde.

Criterio	Purple Shield	DNSFilter	Cisco Umbrella
Dónde se realiza 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 ubicación	Ninguno	Ninguno para el filtrado de red	Ninguno para la protección en la capa DNS
Gestión de inquilinos	Dentro del panel de Purple que gestiona la WiFi de los clientes	Consola MSP independiente con suborganizaciones	Consola multiorganización o MSP independiente
Vinculado a SSID, Captive Portals y analíticas WiFi	Sí, nativo de la plataforma WiFi	No, se configura como un entorno independiente	Se integra con Cisco Meraki y se gestiona en su propia consola
Dispositivos en itinerancia fuera de las instalaciones	Diseñado para dispositivos conectados a la WiFi que gestionas	Agente de cliente en itinerancia	Módulo de itinerancia de Cisco Secure Client
Cobertura de hardware	Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, Fortinet	Cualquier red capaz de reenviar peticiones DNS a sus resolutores	Cualquier red capaz de reenviar peticiones DNS a sus resolutores, con mayor integración en Cisco
Más idóneo para	MSP cuyos clientes gestionan su WiFi con Purple	MSP que protegen endpoints gestionados dentro y fuera de las instalaciones	Infraestructuras estandarizadas en la seguridad de Cisco

Las alternativas son sólidas en las áreas donde Shield no compite. Tanto DNSFilter como Cisco Umbrella ofrecen agentes de itinerancia para portátiles gestionados fuera de las instalaciones. Umbrella también se integra en el catálogo de seguridad más amplio de Cisco. WebTitan, de TitanHQ, ofrece asimismo un filtro en la nube multinquilino para MSP. Si tus contratos cubren endpoints corporativos en cualquier lugar al que se desplacen, cualquiera de estas opciones puede adaptarse a tus necesidades.

El caso de Purple Shield es más concreto y, para los MSP orientados a WiFi, más sólido. Si gestionas los SSID, Portales Cautivos y analíticas de cada cliente en Purple, mantener una pila de resolución independiente por cliente supone un coste adicional innecesario. Para más información, lee Shield vs DNSFilter: una comparación de DNS de protección para operadores de WiFi y Shield vs Cisco Umbrella: cómo elegir el DNS de protección para WiFi de invitados.

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

El filtrado DNS actúa en un punto concreto de la conexión, y eso determina sus límites.

• El DNS cifrado puede eludirlo. DNS sobre HTTPS (DoH, RFC 8484) y DNS sobre TLS (DoT, RFC 7858) permiten que un dispositivo elija su propio resolvedor. Los controles de red pueden mitigar esto en dispositivos no gestionados, pero no pueden eliminarlo del todo. Consulta Explicación de DNS sobre HTTPS: privacidad frente a filtrado en WiFi pública.
• Las VPN crean túneles que lo esquivan. Un invitado que utilice una VPN personal resuelve los nombres dentro del túnel. Puedes bloquear dominios de VPN conocidos, pero no absolutamente todos.
• Las conexiones por IP directa omiten el DNS. El malware que llama a una dirección IP prefijada en el código nunca realiza una búsqueda DNS. Tu cortafuegos se encarga de cubrir ese caso.
• Analiza dominios, no contenido. El filtrado DNS permite o bloquea un dominio completo, no páginas o archivos individuales.
• Las categorías requieren revisión. Cualquier lista de categorías puede, en ocasiones, bloquear de más o de menos. Asigna a cada cliente un contacto designado y un procedimiento para solicitar cambios.
• Los registros necesitan gobernanza. Acuerda la retención y el acceso por cliente antes del despliegue, y regístralo en tu contrato de tratamiento de datos.

¿Qué deberías hacer a continuación?

1. Mapea a tus clientes. Haz una lista de cada cliente, ubicación y red, indicando el sector vertical y los requisitos normativos aplicables, como escuelas, bibliotecas, centros sanitarios y locales autorizados.
2. Redacta directivas estándar. Empieza con las cuatro mencionadas anteriormente y mantén la base de seguridad como obligatoria.
3. Realiza pruebas piloto en ubicaciones representativas. Elige una ubicación por sector vertical, incluida una con conexiones de red limitadas, y mide el uso de datos antes y después.
4. Despliega por directiva, no por ubicación. Asigna directivas a las redes de cada cliente y, a continuación, revisa las excepciones tras 30 días.
5. Informa de los resultados. Añade la actividad de filtrado a las revisiones del servicio WiFi que ya entregas habitualmente.

Si el WiFi de tus clientes aún no funciona con Purple, empieza con Guest WiFi y, a continuación, añade Purple Shield. Para saber más sobre cómo proteger redes en múltiples instalaciones, consulta Todas las guías.

Preguntas frecuentes

¿Necesito instalar hardware en la ubicación de cada cliente para usar el filtrado DNS?

No. Purple Shield filtra en la capa DNS en la nube, por lo que no hay ningún dispositivo 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 fabricante, así que sigue la documentación de soporte de Purple para cada tipo de hardware de tu parque de dispositivos.

¿Puedo establecer diferentes directivas de filtrado para cada cliente y cada red?

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

¿Puedo gestionar el filtrado de contenidos para varios centros desde un solo panel de control?

Sí. Shield se gestiona en la misma plataforma Purple que ejecuta los SSID, Captive Portals y la analítica de tus clientes, por lo que puedes cambiar el filtrado sin cambiar de consola. Un cambio de política se aplica a cada red asignada a esa política, en todos los centros. La actividad de filtrado se muestra junto a tus informes de WiFi existentes, de modo que una sola revisión con el cliente cubre tanto la conectividad como la seguridad.

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

Shield se adapta a los MSP cuyos clientes ya ejecutan su WiFi en Purple, mientras que DNSFilter se adapta a los MSP que protegen portátiles gestionados dentro y fuera de las instalaciones. Ambos filtran en la capa DNS en la nube sin hardware por centro. DNSFilter se ejecuta como una consola multinquilino independiente con un agente itinerante. Shield se ejecuta dentro de la plataforma WiFi, vinculado a los mismos SSID, Captive Portals y analíticas que ya gestionas.

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

Sí, un invitado decidido puede hacerlo. DNS sobre HTTPS, DNS sobre TLS y las VPN personales envían las búsquedas fuera de tu resolutor. Los controles de red pueden reducir esto, por ejemplo, bloqueando endpoints públicos de DoH y VPN conocidos, 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.

¿Ayuda el filtrado DNS a que las escuelas y bibliotecas cumplan con los requisitos de filtrado?

Cubre el elemento de filtrado, pero el filtrado por sí solo no satisface la totalidad del requisito. En Inglaterra, los estándares de filtrado y supervisión del Departamento de Educación exigen tanto filtrado como supervisión, con responsabilidades nominativas y revisiones periódicas. En EE. UU., la 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 coherente en todos los centros con tus procesos de supervisión y salvaguarda.

¿Cómo se gestionan los registros de consultas DNS en virtud del GDPR?

Purple cumple con el GDPR y cuenta con la certificación ISO 27001. Los registros 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 del despliegue, y registra esos términos en tu acuerdo de procesamiento de datos. Como MSP, a menudo actuarás como encargado del tratamiento para tus clientes, así que documenta quién controla los registros de cada propiedad.

¿Cómo se calcula el precio de Shield para un entorno multicentro?

Shield es un complemento de seguridad para la plataforma Purple, junto con SecurePass y Verify, por lo que puedes añadirlo a los emplazamientos que ya funcionan con Purple. No requiere hardware por ubicación, por lo que no hay costes de dispositivos, envíos ni sustituciones que calcular. Solicita a Purple presupuesto en función del número de clientes y emplazamientos, e incluye cualquier ubicación que planees incorporar este año.