DNS-Filterung für MSPs und Umgebungen mit mehreren Standorten

DNS filtering für MSPs und Multi-Site-Umgebungen prüft Domain-Anfragen in der Cloud anhand von Sicherheitsrichtlinien, bevor Geräte eine Verbindung herstellen. Über Purple zentral zusammen mit SSIDs, Captive Portals und Analysen verwaltet, erfordert es keine Hardware vor Ort. Durch die Integration mit Systemen wie Cisco Meraki und HPE Aruba schützt Purple Netzwerkumgebungen an über 80.000 Live-Standorten agentenlos.

Was ist DNS filtering für MSPs und Multi-Site-Umgebungen?

Jede Verbindung, die ein Gerät herstellt, beginnt mit einer DNS-Abfrage (Domain Name System). Das Gerät fordert einen Resolver auf, einen Namen wie example.com in eine IP-Adresse umzuwandeln. DNS filtering, auch als Protective DNS bezeichnet, gleicht diesen Namen vor der Antwort mit einer Richtlinie ab. Ist die Domain bösartig oder verstößt sie gegen die Richtlinien, hält der Resolver die echte Adresse zurück. Das Gerät baut keine Verbindung auf, sodass weder Downloads noch Seitenaufrufe stattfinden.

Für einen einzelnen Standort ist dies eine nützliche Steuerung. Für einen Managed Service Provider (MSP) oder ein Multi-Site-IT-Team ändern sich die Anforderungen grundlegend. Sie filtern Dutzende oder Hunderte von Netzwerken unterschiedlicher Kunden, mit verschiedenen Regeln und auf unterschiedlicher Hardware. Das bringt drei Anforderungen mit sich, die ein Filter für Einzelstandorte selten erfüllt:

• Mandantenspezifische Richtlinie. Ein Mandant ist ein Kunde oder eine Geschäftseinheit mit eigenen Regeln. Eine Familienhotelgruppe, eine Pub-Kette und eine Arztpraxis sollten sich niemals dieselbe Richtlinie teilen.
• Zentrale Verwaltung. Sie müssen die Richtlinien aller Mandanten von einem zentralen Ort aus einsehen und ändern können, ohne sich an jedem einzelnen Standort anzumelden.
• Keine Hardware pro Standort. Das Versenden, Einbauen und Ppatchen eines Geräts an jedem Standort ist über eine gesamte Flotte hinweg nicht skalierbar.

Shield ist das Protective-DNS-Add-on von Purple, neben SecurePass und Verify. Das Filtering läuft in der Cloud und ist an die SSIDs (Netzwerknamen), Captive Portals und Analysen gebunden, die Sie bereits für jeden Kunden verwalten. Ein Captive Portal ist die Anmeldeseite, die ein Besucher sieht, bevor er online geht.

Wie sich MSP-Filtering von einer Einzelstandort-Bereitstellung unterscheidet

Ein Filter für einen Einzelstandort hat eine Richtlinie, einen Administrator und ein Netzwerk. Eine MSP-Umgebung besitzt eine Hierarchie. Sie legen Regeln für die gesamte Umgebung fest, überschreiben diese pro Kunde und variieren sie anschließend pro Netzwerk innerhalb eines Standorts. Das Gäste-WiFi eines Hotels benötigt andere Regeln als das Personalnetzwerk hinter der Rezeption.

Eigenständige DNS-Filter lösen dies typischerweise über eine Unterorganisation pro Mandant, die getrennt vom eigentlichen WiFi konfiguriert wird. Am Ende betreiben Sie zwei Stacks für jeden Kunden: einen für das Netzwerk und das Portal, einen für den Resolver. Shield eliminiert den zweiten Stack, da die Filtering-Richtlinie direkt den Netzwerken folgt, die Sie bereits in Purple definiert haben.

Warum ist DNS filtering über eine Flotte von Kundenstandorten hinweg wichtig?

Drei Faktoren rücken Filtering ganz oben auf die Agenda eines MSPs: Sorgfaltspflicht, Bedrohungslage und begrenzte Bandbreite.

Sorgfaltspflicht in geteilten Netzwerken

Öffentliches WiFi und Gast-WiFi bringen reale Verpflichtungen mit sich. In England befolgen Schulen und Hochschulen die Filtering- und Monitoring-Standards des Department for Education, auf die in "Keeping children safe in education" verwiesen wird. In den USA verpflichtet der Children's Internet Protection Act (CIPA) Schulen und Bibliotheken, die E-rate-Förderung erhalten, zum Filtern. Hotels, Cafés und Freizeitzentren, die Familien willkommen heißen, stehen vor einem Reputationsrisiko, wenn ein Kind Erwachseneninhalte erreicht. Das britische Friendly WiFi-Programm existiert genau aus diesem Grund.

Wenn Sie WiFi für 40 Kunden betreiben, tragen Sie einen Teil jeder Verpflichtung. Eine ungefilterte Website ist ein Kundengespräch, das Sie nicht führen möchten.

Bedrohungen, die verwaltete Geräte nicht erreichen

Sie können keinen Agenten auf dem Smartphone eines Besuchers installieren und Sie können es nicht patchen. Phishing-Links, Malware-Downloads und Command-and-Control-Callbacks beginnen alle mit einer DNS-Abfrage. Das macht die Abfrage zum einzigen Punkt, den Sie für jedes Gerät im Netzwerk kontrollieren.

Shield markiert Bedrohungen bereits in der Phase der DNS-Abfrage und stoppt schädliche Anfragen, bevor Verbindungen hergestellt werden. Über einen gesamten Bestand hinweg greift eine Bedrohungsblockade an allen Kundenstandorten zum selben Zeitpunkt. Für einen breiteren Überblick über den Markt siehe Phishing-Schutz-Software: 10 Optionen für gemeinsam genutztes WiFi.

Bandbreite an kapazitätsbeschränkten Standorten

Viele Objekte betreiben Gast-WiFi über bescheidene Anbindungen: einen 4G-Router an einer Tankstelle, eine gemeinsam genutzte Leitung in einem Pub, einen ausgelasteten Anschluss an einem Bahnhof. Werbe-Traffic und unerwünschte Webinhalte konkurrieren mit allen anderen Daten. Das Filtern von Werbung und schädlichen Domains auf der DNS-Ebene reduziert den Netzwerkdatenverbrauch und verbessert die Ladezeiten. An einem überlasteten Standort kommt dieser Freiraum direkt dem Datenverkehr zugute, für den die Gäste gekommen sind.

Was eine Firewall übersieht

Eine Firewall ist weiterhin wichtig, arbeitet aber an einem anderen Punkt. Sie prüft Verbindungen erst, nachdem die DNS-Abfrage bereits beantwortet wurde. Das hinterlässt vier Lücken in einem standortübergreifenden Gäste-Netzwerk:

1. Verschlüsselung verbirgt das Ziel. TLS 1.3 (RFC 8446) verschlüsselt das Serverzertifikat. Encrypted Client Hello (ECH), eine IETF-Erweiterung für TLS, kann auch den Servernamen verbergen. Ohne Entschlüsselung sieht eine Firewall eine IP-Adresse und sonst wenig, und Sie können kein Entschlüsselungszertifikat auf dem Gerät eines Besuchers installieren.
2. Gemeinsam genutzte IP-Adressen verwischen Regeln. Content Delivery Networks hosten viele Domains auf denselben Adressen. Blockieren Sie die IP, sperren Sie legitime Websites; erlauben Sie sie, gelangt die schädliche Domain durch.
3. Regelsätze pro Standort weichen voneinander ab. Ein über Jahre aufgebauter Bestand kombiniert verschiedene Firewall-Anbieter und Firmware-Versionen. 60 Regelsätze synchron zu halten ist eine Vollzeitaufgabe, und ein vergessener Standort ist die Lücke.
4. Die Blockierung erfolgt zu spät. Bis eine Firewall eingreift, hat das Gerät den Namen bereits aufgelöst und eine Verbindung versucht. DNS-Filtering stoppt die Anfrage, bevor überhaupt eine Verbindung besteht.

DNS-Filtering schließt diese Lücken ohne Entschlüsselung, Agenten oder Regeln pro Standort. Es ersetzt nicht die Aufgabe der Firewall, Netzwerke zu segmentieren und Ports zu steuern.

Wie funktioniert DNS-Filtering über mehrere Mandanten hinweg?

Was bei jeder Abfrage passiert

1. Ein Gast verbindet sich mit dem WiFi des Kunden, häufig über ein Captive Portal.
2. Das Gerät fordert eine Domain an, beispielsweise über einen Link in einer Phishing E-Mail.
3. Shield prüft die Domain anhand der Richtlinie, die diesem Netzwerk zugewiesen ist.
4. Ist die Domain erlaubt, erhält das Gerät die Adresse und stellt die Verbindung wie gewohnt her.
5. Wird sie blockiert, gibt die Abfrage nicht die echte Adresse zurück, sodass keine Verbindung aufgebaut wird.

So strukturieren Sie Richtlinien pro Mandant

Inhaltsfilterung pro Mandant funktioniert am besten als kleiner Satz von Standardrichtlinien, nicht als maßgeschneidertes Regelwerk pro Standort. Dieses Muster bewährt sich im Gastgewerbe, im Einzelhandel und im öffentlichen Sektor:

• Sicherheits-Baseline. Malware, Phishing und andere Bedrohungskategorien werden in jedem Netzwerk für jeden Mandanten blockiert. Davon gibt es keine Ausnahme.
• Gäste mit Familie. Die Baseline zuzüglich Inhalten für Erwachsene und nicht altersgerechten Inhalten. Eignet sich für Familienhotels, Bibliotheken, Freizeitzentren, Schulen und Wartebereiche im Gesundheitswesen.
• Erwachsene Gäste. Die Baseline mit gelockerten Inhaltsregeln. Eignet sich für Bars, Nachtbetriebe und Business-Hotels.
• Personal. Die Baseline plus Regeln, die die Richtlinien zur angemessenen Nutzung des jeweiligen Kunden widerspiegeln.

Weisen Sie pro Netzwerk eine Richtlinie zu und fügen Sie Kundenausnahmen nur dort hinzu, wo ein Unternehmen sie benötigt. Das Marketingteam eines Hotels benötigt möglicherweise soziale Plattformen, die eine Schule blockieren würde. Vier Richtlinien und eine kurze Ausnahmeliste lassen sich weitaus einfacher auditieren als 60 manuell erstellte Regelwerke.

Da Shield die Richtlinie an die Netzwerke bindet, die Sie in Purple betreiben, können die SSIDs für Gäste und Personal eines Standorts unterschiedliche Richtlinien tragen. Personalnetzwerke, die IEEE 802.1X nutzen - den Standard für portbasierte Netzwerkzugriffskontrolle - behalten ihre Identitätskontrollen. Shield fügt die DNS-Schicht darüber ein.

Verwaltung einer Flotte über ein einziges Dashboard

Zentrales DNS-Richtlinienmanagement zahlt sich nur aus, wenn es zu Ihrer bestehenden Arbeitsweise passt. Shield ist in dieselbe Purple Plattform integriert, die die SSIDs, Captive Portals und Analysen jedes Kunden betreibt. Sie müssen nicht die Konsole wechseln, um einen Filter zu ändern, und Sie müssen kein zweites Standortinventar pflegen.

Das hat praktische Konsequenzen für einen MSP:

• Onboarding. Ein neuer Kundenstandort in Purple benötigt kein separates Resolver-Konto.
• Änderungssteuerung. Ändern Sie eine Richtlinie einmal und sie gilt für jedes Netzwerk, das ihr zugewiesen ist.
• Berichterstattung. Filteraktivitäten stehen direkt neben den Verbindungsanalysen, die Sie bereits teilen, sodass eine einzige quartalsweise Überprüfung WiFi und Sicherheit abdeckt.

Warum keine Hardware geliefert werden muss

Shield filtert in der Cloud, sodass an keinem Standort ein Gerät gekauft, konfiguriert, versendet oder ausgetauscht werden muss. Purple ist hardwareunabhängig und läuft als Cloud-Overlay auf Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks und Fortinet. Eine Kundenumgebung, die nach Übernahmen verschiedene Anbieter kombiniert, nutzt weiterhin ein einziges Set von Richtlinien. Die Einrichtung variiert je nach Anbieter. Befolgen Sie daher die Support-Dokumentation von Purple für Ihre Hardware.

Purple läuft bereits an über 80.000 aktiven Standorten und verzeichnete 440 Millionen Anmeldungen im Jahr 2024 (Purple Daten).

Wie sieht DNS-Filterung auf einem echten Standortbestand aus?

Die drei folgenden Szenarien sind zusammengesetzte Beispiele aus typischen Netzwerkstrukturen. Standortzahlen und Hardware sind repräsentativ; die Ergebnisse zeigen die betriebliche Logik jeder Änderung.

Szenario 1: Ein MSP mit 14 Gastronomie- und Hotelleriekunden

Ausgangslage. Ein MSP betreibt Gäste- und Mitarbeiter-WiFi für 14 Kunden aus Gastronomie und Hotellerie an 60 Standorten. Der Mix umfasst unabhängige Hotels, eine Pub-Gruppe mit 20 Standorten und einen Ferienpark. WiFi und Captive Portals laufen bereits über Purple. Die Filterung erfolgte über einen separaten DNS-Dienst mit jeweils eigenem Konto und eigener Standortliste pro Kunde.

Umsetzung. Der MSP verlegte die Filterung zu Shield und ersetzte 14 individuelle Regelwerke durch die vier Standardrichtlinien. Familienhotels und der Ferienpark wählten das Protokoll für Familiengäste; die Pub-Gruppe entschied sich für das Protokoll für erwachsene Gäste. Zwei Kunden behielten kurze Ausnahmelisten bei.

Ergebnis. Kein Hardware-Versand und keine Techniker-Einsätze vor Ort an allen 60 Standorten. Der MSP löschte 14 separate Filter-Accounts und verwaltet nun jeden Kunden über das bereits genutzte Purple Dashboard. Eine Regeländerung bedeutet jetzt das Bearbeiten einer von vier Richtlinien - statt bis zu 60 Standorteinträgen.

Szenario 2: Bibliotheken und Sportzentren einer Kommunalverwaltung

Ausgangslage. Eine Kreisverwaltung bietet öffentliches WiFi in 22 Bibliotheken und fünf Sportzentren an. Kinder nutzen die Bibliotheksnetzwerke nach der Schule. Durch zwei frühere Beschaffungsrunden wird in den Bibliotheken HPE Aruba und in den Sportzentren Ubiquiti UniFi eingesetzt. Das IT-Team besteht aus drei Personen.

Umsetzung. Die Verwaltung wendete die Richtlinie für Familiengäste auf jede öffentliche SSID und die Mitarbeiter-Richtlinie auf die internen Netzwerke an. Die Mitarbeiter-Authentifizierung verbleibt auf 802.1X mit WPA3-Enterprise, dem aktuellen Enterprise-WiFi-Verschlüsselungsstandard. Besucher verbinden sich weiterhin über das Captive Portal der Verwaltung.

Ergebnis. Alle 27 Standorte nutzen eine einheitliche öffentliche Richtlinie über zwei Hardware-Anbieter hinweg - völlig ohne lokale Zusatzgeräte. Eine Änderung erreicht alle 27 Standorte. Die Verwaltung weist gegenüber Prüfern eine einzige Richtlinie und eine zentrale Protokollquelle nach, statt 27 lokaler Konfigurationen.

Szenario 3: Ein Einzelhändler mit 120 Filialen und begrenzter Bandbreite

Situation. Ein Einzelhändler bietet Kunden-WiFi in 120 Filialen an, von denen ein Drittel über eine 4G-Anbindung verfügt. Das Surfverhalten der Kunden konkurriert mit den Filialsystemen um Bandbreite. Die Karteninhaber-Datenumgebung ist bereits vom Gästeverkehr isoliert, um nicht in den PCI-DSS-Geltungsbereich zu fallen.

Umsetzung. Der Einzelhändler aktivierte den Bedrohungsschutz und das Ad-Blocking von Shield ausschließlich auf der Gäste-SSID. Die Einführung begann mit einem Pilotprojekt in 10 Filialen an den am stärksten ausgelasteten 4G-Standorten. Netzwerke für Mitarbeiter und Filialsysteme verblieben auf ihren eigenen Segmenten.

Ergebnis. Im Rahmen des Pilotprojekts wurde die Nutzung über vier Wochen hinweg im Vorher-Nachher-Vergleich gemessen. Dies belegte einen reduzierten Gesamtdatenverbrauch über die bandbreitenbeschränkten Verbindungen. Der Einzelhändler weitete die Richtlinie daraufhin in einem einzigen Schritt auf alle 120 Filialen aus - ganz ohne Technikertermin vor Ort.

Wie fügt sich DNS-Filterung in Ihre bestehende Infrastruktur ein?

Protektives DNS ist eine Sicherheitsebene. Es funktioniert am besten in Kombination mit den Schutzmaßnahmen, die Sie wahrscheinlich bereits einsetzen.

• Segmentierung. VLANs (virtuelle LANs, die ein physisches Netzwerk in isolierte logische Netzwerke unterteilen) halten Gast-Traffic von Mitarbeitenden und Zahlungssystemen fern. Siehe Einrichten der Netzwerksegmentierung für Gäste und Mitarbeiter.
• Authentifizierung. 802.1X mit RADIUS, das Protokoll, das Anmeldeinformationen mit einem zentralen Server abgleicht, entscheidet, wer dem Mitarbeiter-Netzwerk beitritt. Ebenso SecurePass mit Microsoft Entra ID, Okta oder Google Workspace. Shield entscheidet, wohin Geräte nach der Verbindung navigieren können.
• Firewalls. Ihre Firewall steuert weiterhin Ports, Protokolle und Traffic zwischen den Segmenten. Shield stoppt bekannte schädliche Ziele direkt beim Aufruf.
• Datenschutzrecht. DNS-Logs können IP-Adressen und Gerätekennungen enthalten, die nach GDPR als personenbezogene Daten gelten. Purple ist GDPR-konform und nach ISO 27001 zertifiziert.

Wie Shield im Vergleich zu DNSFilter und Cisco Umbrella abschneidet

DNSFilter und WebTitan richten sich stark an MSPs, und Cisco Umbrella ist in vielen Cisco-Umgebungen der Standard. Alle filtern auf DNS-Ebene in der Cloud. Die Unterschiede liegen darin, wer was und wo verwaltet.

Kriterium	Purple Shield	DNSFilter	Cisco Umbrella
Wo die Filterung stattfindet	DNS-Aufruf, in der Cloud von Purple	DNS-Aufruf, in der Cloud von DNSFilter	DNS-Aufruf, in der Cloud von Cisco
Hardware pro Standort	Keine	Keine für Netzwerkfilterung	Keine für Schutz auf DNS-Ebene
Mandantenverwaltung	Im Purple Dashboard, das das Kunden-WiFi betreibt	Separate MSP-Konsole mit Unterorganisationen	Separate Multi-Org- oder MSP-Konsole
An SSIDs, Captive Portale und WiFi-Analysen gebunden	Ja, nativ in der WiFi-Plattform enthalten	Nein, als separater Stack konfiguriert	Integriert mit Cisco Meraki, verwaltet in einer eigenen Konsole
Externe Roaming-Geräte	Entwickelt für Geräte im von Ihnen betriebenen WiFi	Roaming-Client-Agent	Cisco Secure Client Roaming-Modul
Hardware-Abdeckung	Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, Fortinet	Jedes Netzwerk, das DNS an seine Resolver weiterleiten kann	Jedes Netzwerk, das DNS an seine Resolver weiterleiten kann, am tiefsten mit Cisco
Am besten geeignet für	MSPs, deren Kunden-WiFi auf Purple läuft	MSPs, die verwaltete Endpunkte vor Ort und unterwegs schützen	Umgebungen, die auf Cisco-Sicherheit standardisiert sind

Die Alternativen sind dort stark, wo Shield nicht konkurriert. DNSFilter und Cisco Umbrella bieten beide Roaming-Agenten für verwaltete Laptops außerhalb des Unternehmens. Umbrella ist zudem Teil des breiteren Sicherheitsportfolios von Cisco. WebTitan von TitanHQ bietet ebenfalls einen mandantenfähigen Cloud-Filter für MSPs. Wenn Ihre Verträge Unternehmens-Endpunkte unabhängig von deren Standort abdecken, könnte eine dieser Optionen passen.

Die Argumentation für Shield ist passgenauer und – für WiFi-fokussierte MSPs – überzeugender. Wenn Sie die SSIDs, Captive Portals und Analysen jedes Kunden in Purple verwalten, bedeutet ein separater Resolver-Stack pro Mandant unnötigen Mehraufwand. Für Details lesen Sie Shield vs DNSFilter: ein schützender DNS-Vergleich für WiFi-Betreiber und Shield vs Cisco Umbrella: Auswahl von schützendem DNS für Gäste-WiFi.

Welche Grenzen der DNS-Filterung sollten Sie kennen?

DNS-Filterung greift an einem bestimmten Punkt einer Verbindung, was ihre Grenzen definiert.

• Verschlüsseltes DNS kann sie umgehen. DNS over HTTPS (DoH, RFC 8484) und DNS over TLS (DoT, RFC 7858) erlauben es einem Gerät, seinen eigenen Resolver zu wählen. Netzwerksteuerungen können dies auf nicht verwalteten Geräten reduzieren, aber nicht vollständig verhindern. Siehe DNS over HTTPS erklärt: Datenschutz vs. öffentliches WiFi-Filtering.
• VPNs leiten den Datenverkehr am Filter vorbei. Ein Gast mit einem privaten VPN löst Namen innerhalb des Tunnels auf. Sie können bekannte VPN-Domains blockieren, aber nicht jede einzelne.
• Direkte IP-Verbindungen überspringen DNS. Schadsoftware, die eine fest codierte IP-Adresse aufruft, führt keine DNS-Abfrage durch. Ihre Firewall deckt diesen Fall ab.
• Es erkennt Domains, keine Inhalte. DNS-Filterung erlaubt oder blockiert eine gesamte Domain, keine einzelnen Seiten oder Dateien.
• Kategorien erfordern Überprüfung. Jede Kategorienliste wird manchmal zu viel oder zu wenig blockieren. Richten Sie für jeden Kunden einen benannten Ansprechpartner und einen Weg ein, um Änderungen anzufordern.
• Protokolle erfordern Governance. Vereinbaren Sie Speicherdauer und Zugriff pro Kunde vor der Einführung und halten Sie dies in Ihrer Vereinbarung zur Auftragsverarbeitung fest.

Was sollten Sie als Nächstes tun?

1. Erfassen Sie Ihre Mandanten. Listen Sie jeden Kunden, Standort und jedes Netzwerk auf, inklusive Branchen- und Regulierungsanforderungen wie für Schulen, Bibliotheken, das Gesundheitswesen oder lizenzierte Veranstaltungsorte.
2. Entwerfen Sie Standard-Richtlinien. Beginnen Sie mit den vier oben genannten und behalten Sie die Sicherheits-Baseline als verpflichtend bei.
3. Führen Sie Pilotsysteme auf repräsentativen Standorten aus. Wählen Sie einen Standort pro Branche, einschließlich eines Standorts mit eingeschränkter Anbindung, und messen Sie die Datennutzung vor und nach der Umsetzung.
4. Rollen Sie nach Richtlinie aus, nicht nach Standort. Weisen Sie Netzwerken für jeden Kunden Richtlinien zu und überprüfen Sie Ausnahmen nach 30 Tagen.
5. Berichten Sie Ergebnisse. Ergänzen Sie Ihre bestehenden WiFi-Berichte um Aktivitäten zur DNS-Filterung.

Wenn das WiFi Ihrer Kunden noch nicht auf Purple läuft, beginnen Sie mit Guest WiFi und fügen Sie dann Shield hinzu. Für weitere Informationen zur Sicherung von Netzwerken über mehrere Standorte hinweg durchsuchen Sie Alle Leitfäden.

Häufig gestellte Fragen

Muss ich an jedem Kundenstandort Hardware installieren, um DNS-Filterung zu nutzen?

Nein. Shield filtert auf der DNS-Ebene in der Cloud, sodass keine Appliance gekauft, konfiguriert oder an einen Standort geliefert werden muss. Purple läuft als Cloud-Overlay auf Access Points, die Ihre Kunden bereits besitzen, darunter Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet. Die Einrichtung variiert je nach Anbieter, befolgen Sie daher die Support-Dokumentation von Purple für jeden Hardware-Typ in Ihrem Bestand.

Kann ich für jeden Kunden und jedes Netzwerk unterschiedliche Filterrichtlinien festlegen?

Ja. Shield verknüpft Filterrichtlinien mit den Netzwerken, die Sie bereits in Purple betreiben, sodass jeder Kunde und jede SSID innerhalb eines Standorts eine eigene Richtlinie erhalten kann. Das Gäste-WiFi eines Hotels kann Anstößiges für Erwachsene blockieren, während das Mitarbeiter-Netzwerk die Regeln für eine akzeptable Nutzung des Kunden anwendet. Eine kleine Gruppe von Standardrichtlinien plus kurze Ausnahmelisten lässt sich einfacher überprüfen als maßgeschneiderte Regeln pro Standort.

Kann ich die Inhaltsfilterung für mehrere Standorte über ein einziges Dashboard verwalten?

Ja. Shield wird auf derselben Purple Plattform verwaltet, die auch die SSIDs, Captive Portals und Analysen Ihrer Kunden betreibt. Sie können Filter also anpassen, ohne die Konsole zu wechseln. Eine Richtlinienänderung gilt für jedes Netzwerk, das dieser Richtlinie zugewiesen ist - über alle Standorte hinweg. Die Filteraktivitäten werden zusammen mit Ihren bestehenden WiFi Berichten angezeigt, sodass eine einzige Kundenüberprüfung sowohl die Konnektivität als auch die Sicherheit abdeckt.

Wie schneidet Shield im Vergleich zu DNSFilter für einen MSP ab?

Shield eignet sich für MSPs, deren Kunden-WiFi bereits auf Purple läuft, während sich DNSFilter für MSPs eignet, die verwaltete Laptops vor Ort und außerhalb schützen. Beide filtern auf der DNS-Ebene in der Cloud ohne Hardware pro Standort. DNSFilter läuft als separate mandantenfähige Konsole mit einem Roaming Agent. Shield läuft innerhalb der WiFi Plattform, verknüpft mit denselben SSIDs, Captive Portals und Analysen, die Sie bereits verwalten.

Können Gäste die DNS-Filterung mit DNS over HTTPS oder einem VPN umgehen?

Ja, ein entschlossener Gast kann das. DNS over HTTPS, DNS over TLS und persönliche VPNs senden Abfragen außerhalb Ihres Resolvers. Netzwerksteuerungen können dies reduzieren, beispielsweise durch das Blockieren bekannter VPN- und öffentlicher DoH-Endpunkte, aber kein DNS-Filter kann ein nicht verwaltetes Gerät vollständig kontrollieren. Betrachten Sie die DNS-Filterung als Standard-Schutz für jedes Gerät, das das DNS des Netzwerks nutzt, zusammen mit Segmentierung und Ihrer Firewall.

Hilft die DNS-Filterung Schulen und Bibliotheken, die Filteranforderungen zu erfüllen?

Sie deckt das Filterelement ab, aber eine Filterung alleine erfüllt nicht die gesamten Anforderungen. In England verlangen die Filter- und Überwachungsstandards des Bildungsministeriums sowohl Filterung als auch Überwachung mit benannten Verantwortlichkeiten und regelmäßiger Überprüfung. In den USA verlangt CIPA von durch E-Rate finanzierten Schulen und Bibliotheken den Einsatz technischer Schutzmaßnahmen im Rahmen einer Internetsicherheitsrichtlinie. Kombinieren Sie eine konsistente Filterung über Standorte hinweg mit Ihren Überwachungs- und Schutzprozessen.

Wie werden DNS-Abfrageprotokolle unter der GDPR gehandhabt?

Purple ist GDPR-konform und besitzt eine ISO 27001-Zertifizierung. DNS-Protokolle können IP-Adressen und Gerätekennungen enthalten, die von der GDPR als personenbezogene Daten behandelt werden. Vereinbaren Sie Speicherung, Zugriff und Zweck vor der Einführung mit jedem Kunden und halten Sie diese Bedingungen in Ihrer Vereinbarung zur Auftragsverarbeitung fest. Als MSP agieren Sie häufig als Auftragsverarbeiter für Ihre Kunden. Dokumentieren Sie daher, wer die Protokolle der jeweiligen Umgebung steuert.

Wie wird Shield für ein Objekt mit mehreren Standorten preislich gestaltet?

Shield ist ein Sicherheits-Add-on für die Purple-Plattform, neben SecurePass und Verify. Sie fügen es einfach zu Standorten hinzu, die bereits auf Purple laufen. Es gibt keine Hardware pro Standort, sodass keine Kosten für Geräte, Versand oder Austausch einkalkuliert werden müssen. Fragen Sie Purple nach den Preisen basierend auf Ihrer Anzahl an Kunden und Standorten und schließen Sie alle Standorte ein, die Sie in diesem Jahr einrichten möchten.