Benutzerbasierte Firewall-Regeln: AD- und Entra-Gruppen statt IP-Gefummel

Sophos-Firewall-Regeln auf AD-Gruppen stützen statt auf IP-Listen — die Idee ist so alt wie verlockend, und die Kurzantwort vorab: Ja, die XGS kann Regeln an Benutzer und Gruppen knüpfen; die Identität kommt wahlweise vom STAS-Agenten auf dem Domänencontroller, per Security Heartbeat vom Sophos-Endpoint (dann auch mit reinen Entra-ID-Geräten), übers Captive Portal oder aus RADIUS-Accounting. Der Gewinn ist erheblich: IP-basierte Regeln lügen, sobald DHCP die Adressen würfelt oder das Homeoffice die Netzgrenzen verwischt — benutzerbasierte Regeln bleiben wahr, und das Regelwerk wird nebenbei lesbar wie ein Organigramm. Der ehrliche Nachsatz gehört dazu: Das Modell steht und fällt mit der Zuverlässigkeit der Benutzerzuordnung, und die hat ihre Tücken — von der Abmelde-Erkennung über die Eine-Gruppe-Logik der XGS bis zum Terminalserver, der das ganze Konzept sprengt. Dieser Artikel liefert beides: den Aufbau — und die Stabilisierung.

Die Grenzen IP-basierter Regeln

Warum überhaupt umbauen? Weil die IP-Adresse als Stellvertreter für einen Menschen eine Annahme aus den Neunzigern ist, die der heutige Alltag im Wochentakt widerlegt. Erstens DHCP: Die Regel »10.1.20.0/26 darf auf die Bankportale« meint die Buchhaltung — bis der Adresspool rotiert, ein Notebook umzieht oder die Netzsegmentierung neu geschnitten wird; ab dann meint die Regel niemanden Bestimmtes mehr, und keiner merkt es. Zweitens die Mobilität: Dieselbe Kollegin arbeitet heute am Platz, morgen im Besprechungsraum-WLAN, übermorgen per VPN aus dem Homeoffice — drei Adressen, ein Mensch, und die IP-Regel kennt nur eine davon. Drittens die Pflege-Realität: IP-Listen wachsen, veralten und sammeln Sonderfälle (»die .57 ist der Praktikanten-PC, der brauchte das mal«), bis das Regelwerk aussieht wie ein Adressbuch nach drei Umzügen — technisch gültig, inhaltlich Archäologie.

Und viertens die Nachvollziehbarkeit, die den Bogen zur Prüfungswelt schlägt: Ein Log-Eintrag »10.1.20.57 → Zugriff erlaubt« beantwortet die Frage, wer da zugegriffen hat, exakt nicht — die Zuordnung Adresse-zu-Mensch ist eine Rechercheaufgabe mit DHCP-Lease-Archiv. Benutzerbasierte Regeln drehen das Bild komplett: Die Regel selbst dokumentiert die Absicht, das Log nennt den Namen, und die Rezertifizierung von Berechtigungen wird zur simplen Gruppenpflege. Der Faktenkasten fasst diesen Audit-Gewinn zusammen — er ist in der Praxis oft das schlagkräftigere Argument als die Technik. Eine wichtige Randnotiz gleich hier: Benutzerbezogene Firewall-Protokolle sind auswertbare Leistungsdaten im Sinne der Mitbestimmung; bevor das neue Regelwerk live geht, gehört der Rahmen dafür geklärt — die saubere Konstruktion mit Betriebsrat und Datenschutz behandelt [LINK: C3].

Identitätsquellen der XGS: AD, Entra, STAS und Clients

Damit eine Regel auf Benutzer reagieren kann, muss die XGS zwei Dinge wissen: Wer sitzt gerade hinter welcher IP (die Live-Zuordnung) — und in welcher Gruppe ist dieser Benutzer (die Verzeichnisanbindung, klassisch AD per LDAPS, ergänzt um die Entra-Anbindung aus dem SSO-Kapitel des Clusters). Für die Live-Zuordnung stehen vier Quellen bereit, die die Landkarten-Skizze samt Bewertung zeigt. Quelle eins und in modernen Sophos-Häusern die erste Wahl: die Synchronized User ID über den Security Heartbeat — der Intercept-X-Endpoint meldet den angemeldeten Benutzer selbst und ereignisgesteuert an die Firewall; das funktioniert ohne Domänencontroller-Abhängigkeit und ausdrücklich auch mit reinen Entra-ID-Geräten. Quelle zwei ist der Klassiker STAS: Ein Agent auf dem Domänencontroller wertet die Anmeldeereignisse aus und meldet Benutzer-IP-Paare — clientlos und mit jedem Domänengerät, aber mit den bekannten Schwächen bei Abmelde-Erkennung und Terminalservern.

Quelle drei ist das Captive Portal: Unbekannter Verkehr landet auf einer Anmeldeseite (seit SFOS v20 auf Wunsch mit Entra-SSO) — als Auffangnetz für Gäste, BYOD und Sonderfälle unverzichtbar, als Fundament ungeeignet, weil interaktiv und sitzungsgebunden. Und Quelle vier ist RADIUS-SSO: WLAN-Controller mit 802.1X-Anmeldung liefern ihre Accounting-Daten an die XGS, die daraus Benutzer und IP liest — elegant für Funk-Landschaften. Die Quellen kombinieren sich: Der robuste Alltag ist Heartbeat oder STAS als Fundament plus Captive Portal als Netz darunter. Die Vergleichstabelle liefert die Entscheidungsgrundlage — und ein Detail verdient Fettdruck fürs nächste Kapitel: Egal woher die Identität kommt, die XGS führt je Benutzer genau eine Gruppe.

Skizze 1: Vier Wege zur Benutzer-IP-Zuordnung — Heartbeat als moderne erste Wahl, STAS als AD-Klassiker, Portal und RADIUS als Ergänzung.

Gruppenbasierte Regeln aufbauen

Der Bau selbst ist erfreulich geradlinig: Firewall-Regeln bekommen die Bedingung »nur für bekannte Benutzer« plus die gewünschten Gruppen; Web- und App-Steuerungs-Richtlinien lassen sich ebenso je Gruppe differenzieren. Die Vorarbeit entscheidet über die Wartbarkeit: dedizierte, sprechende Gruppen im Verzeichnis (SG-FW-Buchhaltung, SG-FW-IT-Admins) statt der Wiederverwendung von Abteilungsverteilern, die noch drei andere Jobs haben — dieselbe Disziplin wie beim Rollen-Mapping der Firewall-Verwaltung, nur eben für den Datenverkehr. Dann der Import der Gruppen auf die XGS über die Verzeichnisanbindung, und ab hier gilt das Detail, das in keinem Schnellstart steht und trotzdem die Hälfte aller »Regel greift nicht«-Tickets erklärt: Die XGS ordnet jedem Benutzer genau eine Gruppe zu — die erste passende in ihrer Gruppenliste. Ein Benutzer, der im Verzeichnis in fünf Gruppen steckt, ist für die Firewall Mitglied von exakt einer, und welche das ist, bestimmt die Reihenfolge auf der XGS.

Daraus folgt die Baumeister-Regel: Die Gruppenliste der XGS wird von speziell nach allgemein sortiert — die kleinen, mächtigen Rollen (IT-Admins) vor den Fachrollen (Buchhaltung) vor den Sammelgruppen (Alle-Mitarbeiter), denn wer in mehreren steckt, soll in der spezifischsten landen. Und im Regelwerk selbst gilt dieselbe Logik von oben nach unten, wie die Regelwerk-Skizze im Rollenkapitel zeigt. Der Warn-Kasten widmet sich dem Klassiker, der aus dieser Mechanik folgt — er ist der mit Abstand häufigste Grund, warum benutzerbasierte Regeln »manchmal« nicht greifen, und »manchmal« ist bei Fehlersuchen bekanntlich das teuerste Wort.

Zuverlässigkeit der Benutzerzuordnung sichern

Ein benutzerbasiertes Regelwerk ist nur so gut wie seine Zuordnungstabelle, deshalb gehört die Stabilisierung zum Bau dazu. Baustein eins ist die Grundsatzentscheidung, was ohne Identität passiert: Benutzerregeln greifen schlicht nicht, wenn die IP unbekannt ist — der Verkehr fällt auf die nächste Regel durch. Dieses Durchfallen gehört bewusst gestaltet (Umleitung aufs Portal oder definierter Minimalzugang), niemals dem Zufall überlassen. Baustein zwei ist die eiserne Ausnahme: Server und Dienste kennen keine Anmeldung — Server-Verkehr, Backup, Monitoring laufen grundsätzlich über klassische IP-Regeln, die im Regelwerk vor den Benutzerregeln stehen; wer Serverzugriffe an Benutzeridentitäten hängt, baut sich Ausfälle ins System, sobald die Zuordnung hustet. Baustein drei ist die Quellen-Hygiene: bei STAS die Abfrage-Intervalle und die Abmelde-Erkennung sauber konfigurieren und die DC-Agenten überwachen; beim Heartbeat die Endpoint-Abdeckung im Blick behalten — jedes Gerät ohne Agent ist ein Identitäts-Blindfleck.

Baustein vier ist das Messen: Die Live-Benutzer-Ansicht der XGS ist die Wahrheit über die Zuordnung — sie gehört in jede Fehlersuche als erster Blick (steht dort der richtige Name mit der richtigen Gruppe?), und der Anteil unbekannter Benutzer im Verkehr ist die Betriebskennzahl des Modells: Steigt er, ist eine Quelle krank, lange bevor Tickets kommen. Der Identitätsfluss in der Skizze zeigt die komplette Kette samt ihrer zwei Bruchstellen — fehlende Meldung und veralteter oder falscher Eintrag. Und dann ist da noch der Sonderfall, der eine eigene Antwort braucht, weil er das Grundprinzip Adresse-gleich-Person prinzipbedingt sprengt: der Terminalserver. Der Faktenkasten liefert Problem und Lösung.

Skizze 2: Die Kette von der Anmeldung bis zur Regelentscheidung — und ihre zwei Bruchstellen. Diagnose-Startpunkt ist immer die Live-Benutzer-Tabelle.

Muster für typische Rollenmodelle

Zum Abschluss die Schablone, die sich über Dutzende Mittelstandsumgebungen bewährt hat — sechs Regelblöcke, deren Reihenfolge die Logik ist, wie die Skizze zeigt. Block eins: Server- und Systemverkehr, IP-basiert, vor allem anderen — die Ausnahme aus dem Zuverlässigkeitskapitel. Block zwei: die mächtigste Rolle zuerst, typischerweise die IT-Administratoren mit Verwaltungszugriffen in die Server-Zonen und erweiterter Web-Richtlinie — sie stehen oben, weil Admins fast immer auch Mitglied der Standardgruppen sind. Block drei: die Fachrollen mit Sonderzielen — Buchhaltung mit Bankportalen, Personal mit Bewerberportalen, Marketing mit freigeschalteten Social-Media-Kategorien; je Rolle eine Regel, die Absicht im Namen. Block vier ist das Fundament: alle bekannten Benutzer mit Basis-Internet und Standard-Web-Richtlinie. Block fünf regelt das Durchfallen: Unbekannte landen auf dem Captive Portal oder im definierten Gastprofil. Und Block sechs ist das Sicherheitsnetz: alles Übrige verwerfen, mit Logging. Für die Web-Richtlinien je Rolle gilt übrigens: Wie die Authentifizierung im Web-Proxy technisch ineinandergreift, hängt am gewählten Proxy-Modus — die Grundlagen dazu stehen in [LINK: A6].

Skizze 3: Sechs Blöcke von speziell nach allgemein — ein Regelwerk, das ein Prüfer ohne Netzwerkdiplom lesen kann.

FAQ — häufige Fragen zu benutzerbasierten Regeln auf der Sophos XGS

Kann die XGS Firewall-Regeln auf AD-Gruppen stützen?

Ja, durchgängig: Firewall-Regeln lassen sich auf bekannte Benutzer und ausgewählte Gruppen einschränken, und auch Web-Filter- und App-Steuerungs-Richtlinien differenzieren je Gruppe. Der Unterbau besteht aus zwei Teilen: der Verzeichnisanbindung (klassisch AD über LDAPS), aus der die XGS Gruppen importiert, und einer Live-Quelle für die Benutzer-IP-Zuordnung — STAS auf den Domänencontrollern, die Synchronized User ID über den Heartbeat des Sophos-Endpoints, das Captive Portal oder RADIUS-Accounting. Zwei Dinge gehören von Anfang an mitgedacht: Erstens die Eine-Gruppe-Logik — die XGS ordnet jedem Benutzer genau eine Gruppe zu (die erste passende ihrer Liste), weshalb dedizierte, exklusiv geschnittene Firewall-Gruppen und eine von speziell nach allgemein sortierte Liste Pflicht sind. Zweitens die Ausnahme: Server- und Dienstverkehr bleibt IP-basiert, denn Dienste melden sich nirgends an. Mit diesen beiden Leitplanken ist das Modell stabil und im Alltag deutlich wartbarer als jede IP-Liste.

Funktioniert das auch mit reinen Entra-ID-Geräten?

Ja — mit dem richtigen Werkzeug, und das heißt hier Synchronized User ID: Der Sophos-Endpoint meldet den angemeldeten Benutzer über den Security Heartbeat direkt an die XGS, völlig unabhängig davon, ob das Gerät in einer klassischen Domäne oder rein in Entra ID beheimatet ist. STAS scheidet in diesem Szenario naturgemäß aus — es lauscht auf die Anmeldeereignisse eines On-Prem-Domänencontrollers, den es bei Cloud-only-Geräten schlicht nicht gibt. Als Ergänzung oder Alternative dient das Captive Portal, das sich seit SFOS v20 mit Entra-SSO betreiben lässt — die Anmeldung läuft dann über das vertraute Microsoft-Fenster samt MFA. Für die Gruppenseite gilt: Die Rollen können aus Entra-Sicherheitsgruppen kommen; die Anbindung des Verzeichnisses folgt demselben Muster wie beim Verwaltungs-SSO. Die Praxis-Empfehlung für gemischte und Cloud-first-Umgebungen ist eindeutig: Wer Intercept X ohnehin einsetzt, fährt mit dem Heartbeat als Fundament am robustesten — er ist die einzige Quelle, die On-Prem-, Hybrid- und Entra-only-Geräte identisch behandelt.

Warum greift eine Benutzerregel manchmal nicht?

»Manchmal« hat drei Verdächtige, und die Reihenfolge der Prüfung spart Stunden. Verdächtiger eins, der häufigste: die Eine-Gruppe-Falle — der Benutzer ist im Verzeichnis in mehreren Gruppen, die XGS gibt ihm aber genau eine (die erste ihrer Liste), und wenn das die Sammelgruppe ist, sieht ihn die spezifische Regel nie; der Blick in die Live-Benutzer-Ansicht klärt das in dreißig Sekunden. Verdächtiger zwei: die Zuordnung fehlt oder ist veraltet — die Quelle hat die Anmeldung nicht gemeldet (STAS-Agent gestört, Gerät ohne Endpoint, Terminalserver ohne SATC) oder ein alter Eintrag klebt an der IP, etwa nach einem DHCP-Wechsel; auch das zeigt dieselbe Ansicht. Verdächtiger drei: die Regelreihenfolge — eine breitere Regel weiter oben fängt den Verkehr ab, bevor die Benutzerregel drankommt. Die Diagnose-Routine daraus: erst Live-Ansicht (richtiger Name? richtige Gruppe?), dann Regelwerk von oben lesen, erst danach an den Quellen schrauben. Wer umgekehrt vorgeht, tauscht gern stundenlang STAS-Einstellungen, während die Antwort die ganze Zeit in einer Tabellenzeile stand.

Wie handhabe ich Terminalserver?

Mit SATC — der Sophos Authentication for Thin Clients aus dem STAS-Paket, denn ohne sie ist der Terminalserver der Systembruch des ganzen Modells: Zwanzig gleichzeitige Benutzer teilen sich eine Quell-IP, und die Gleichung »Adresse gleich Person« ist damit prinzipbedingt unlösbar. Der SATC-Agent auf dem Terminalserver löst das elegant über die Transportebene: Er weist jeder Benutzersitzung einen eigenen Quellport-Bereich zu und meldet die Zuordnung an die XGS — die kann den Verkehr dann trotz geteilter Adresse personengenau den Gruppen und Regeln zuführen, inklusive differenzierter Web-Richtlinien je Sitzung. Drei Betriebsregeln dazu: SATC gehört auf jeden Terminalserver der Umgebung (ein vergessener Host bedeutet, dass dessen komplette Benutzerschaft in der Unbekannt-Behandlung landet), er gehört in die Update- und Abnahme-Routine der Serverpflege — nach großen Windows-Updates ist der Funktionstest Pflicht —, und die Überwachung ist simpel: Rutschen plötzlich alle Terminalserver-Benutzer ins Unbekannt-Profil, ist der Agent der erste Verdächtige. Für Azure Virtual Desktop und größere RDS-Farmen gelten dieselben Prinzipien in größerem Maßstab.

Wie viele Gruppen verkraftet das Regelwerk?

Technisch mehr, als organisatorisch gesund ist — die relevante Grenze ist nicht die Firewall, sondern die Lesbarkeit. Die Erfahrungsformel: Für den typischen Mittelständler tragen fünf bis zehn Rollen-Gruppen das komplette Modell — eine Handvoll Fachrollen mit Sonderzielen, die IT-Administration, eventuell Azubis oder Externe mit restriktiverem Profil, dazu das Fundament für alle Bekannten. Wer je Abteilung, Teilteam und Sonderwunsch eine eigene Gruppe samt Regel anlegt, baut das IP-Adressbuch von früher einfach in Grün nach: Das Regelwerk wird wieder unlesbar, die Gruppenreihenfolge (Eine-Gruppe-Logik!) wird zum Minenfeld, und die Rezertifizierung zur Fleißarbeit. Die Disziplin-Fragen vor jeder neuen Gruppe: Braucht diese Rolle wirklich andere Firewall-Ziele als das Fundament — oder nur eine andere Web-Kategorie, die sich in der bestehenden Richtlinie abbilden lässt? Und lässt sich der Sonderfall als Mitgliedschaft in einer vorhandenen Rolle lösen? Als Faustregel: Wenn die Regelwerk-Skizze nicht mehr auf eine Seite passt, ist nicht die Seite zu klein.

Was passiert bei ausgefallener AD-Verbindung?

Zwei Ebenen, zwei Antworten. Ebene eins, die Live-Zuordnung: Bestehende Benutzer-IP-Einträge auf der XGS bleiben zunächst erhalten — wer angemeldet ist und arbeitet, arbeitet weiter; es sind die neuen Anmeldungen, die je nach Quelle nicht mehr gemeldet werden (STAS ohne erreichbaren DC schweigt, der Heartbeat ist hier robuster, weil er vom Endpoint kommt). Die Folge ist ein schleichendes Anwachsen der Unbekannten, die dann in der bewusst gestalteten Durchfall-Behandlung landen — Captive Portal oder Minimalprofil, weshalb genau diese Behandlung nie ein Zufallsprodukt sein darf. Ebene zwei, die Gruppeninformation: Die importierten Gruppenzuordnungen sind auf der XGS vorhanden und verschwinden nicht schlagartig mit dem Verzeichnis. Die Betriebskonsequenzen: Erstens laufen kritische Infrastruktur-Freigaben grundsätzlich IP-basiert (die Server-Ausnahme), damit ein Verzeichnisproblem nie Backup oder Monitoring reißt. Zweitens ist der Anteil unbekannter Benutzer die Frühwarn-Kennzahl — steigt er ungewöhnlich, ist eine Quelle oder das Verzeichnis krank. Und drittens gehört der DC-Ausfall einmal getestet: bewusst trennen, zusehen, was das Regelwerk daraus macht — vor dem Ernstfall, nicht in ihm.

Fazit: Identität schlägt Adresse — mit Netz, doppeltem Boden und einer sortierten Liste

Benutzerbasierte Regeln lösen ein echtes Problem: IP-Listen veralten still, benutzerbasierte Regeln bleiben wahr — und das Regelwerk wird nebenbei zum lesbaren Berechtigungskonzept, das Prüfer versteht und der Ein-/Austritts-Prozess automatisch pflegt. Der Preis ist Sorgfalt an vier Stellen: eine tragfähige Identitätsquelle (Heartbeat als moderne erste Wahl, STAS als Klassiker, Portal als Netz), die Eine-Gruppe-Logik mit exklusiven Gruppen und sortierter Liste, die eiserne Server-Ausnahme — und SATC auf jedem Terminalserver. Dazu die Betriebskennzahl »Anteil Unbekannter« im Blick und die Live-Benutzer-Ansicht als ersten Diagnose-Griff. Wer so baut, bekommt sechs Regelblöcke statt sechzig IP-Zeilen — und beantwortet die Frage »wer darf hier eigentlich was?« künftig mit dem Regelwerk selbst statt mit Ausgrabungen.

Von hier aus weiter im Cluster: Das Gesamtbild der XGS in Microsoft-Umgebungen zeichnet der Pillar-Artikel [LINK: Pillar]. Wie die Verwaltungsseite der Firewall an Entra ID kommt — App-Registrierung, Rollen-Mapping, Break-Glass —, steht im SSO-Artikel [LINK: B1]. Die Mitbestimmungs- und Datenschutzseite benutzerbezogener Protokolle — bevor das Regelwerk live geht — behandelt [LINK: C3]. Und wie die Benutzer-Authentifizierung mit den Web-Proxy-Modi zusammenspielt, klärt [LINK: A6].