Sophos Firewall Administratoren und Profile sicher einrichten

Für die tägliche Administration sollte jede Person ein eigenes Konto erhalten. Dazu wird zuerst ein passendes Device-Access-Profil erstellt und danach unter Authentication > Users ein lokaler Benutzer mit User type: Administrator angelegt. Das Profil bestimmt, was der Administrator sehen oder ändern darf. MFA, Login-Quellen und Device Access schützen zusätzlich die Anmeldung und die Erreichbarkeit des WebAdmin.

Der Default-Administrator admin bleibt als getesteter Notfallzugang erhalten und wird nicht als gemeinsames Alltagskonto verwendet. So bleiben Änderungen einer Person zuordenbar und ein Fehler in einem eingeschränkten Profil sperrt nicht den letzten Recovery-Weg.

Lokalen Administrator in acht Schritten einrichten

1. Backup, Default-Administrator und Recovery-Zugang prüfen. Eine bestehende Admin-Sitzung bleibt bis zum erfolgreichen Test geöffnet.
2. Aufgabe und benötigte Rechte schriftlich festlegen, beispielsweise nur Diagnose oder zusätzlich Änderungen an Netzwerkobjekten.
3. Unter Profiles > Device access > Add ein eigenes Profil erstellen und nicht benötigte Bereiche auf None lassen.
4. Unter Authentication > Users > Add einen persönlichen Benutzernamen eintragen und User type auf Administrator setzen.
5. Das neue Profil, ein starkes eigenes Passwort und die geschäftliche E-Mail-Adresse zuweisen.
6. Unter Administrator advanced settings bei Bedarf Schedule for device access und Login restriction for device access begrenzen.
7. Prüfen, dass Local unter Authentication > Services > Administrator authentication methods weiterhin verfügbar ist. Danach MFA und den WebAdmin-Zugriff aus dem Managementnetz konfigurieren.
8. Das Konto in einem privaten Browserfenster positiv und negativ testen. Erst danach weitere Konten umstellen oder alte Zugänge deaktivieren.

⚠️ Ein neues Profil wird erst produktiv verwendet, wenn ein zweiter funktionierender Administrator und ein dokumentierter Recovery-Weg vorhanden sind. Das integrierte Profil Administrator gibt Vollzugriff und gehört nur zum kleinsten notwendigen Personenkreis.

Die fünf Schutzebenen auseinanderhalten

Bei Admin-Zugängen greifen mehrere Einstellungen zusammen. Sie lösen unterschiedliche Aufgaben und ersetzen einander nicht:

• Benutzerkonto: Identifiziert die Person. Persönliche Konten machen Änderungen nachvollziehbar; Teamkonten wie firewalladmin verwischen diese Zuordnung.
• Device-Access-Profil: Legt mit None, Read-only und Read-write fest, welche Menüs und Funktionen sichtbar oder änderbar sind. Die Rechte gelten auch für die API. None verhindert, dass der Administrator die betreffende Konfiguration im WebAdmin sieht oder über die API abruft. Read-only erlaubt dagegen das Lesen, aber keine Änderungen.
• Schedule und Login Restriction: Begrenzen, wann und von welchen IPv4-Adressen dieses konkrete Administratorkonto den WebAdmin verwenden darf.
• Device Access und Local Service ACL: Legen fest, aus welchen Zonen und Quellen der WebAdmin überhaupt erreichbar ist. Die Umsetzung beschreibt Device Access und Local Service ACL sicher konfigurieren.
• MFA und Audit Trail: MFA schützt das Konto zusätzlich zum Passwort. Der Audit Trail hilft, unterstützte Änderungen einer Identität, Quelle und Konsole zuzuordnen. Für Data Anonymization in Logs und Reports werden zusätzlich mindestens zwei persönliche Authorizer mit getrennten Konten vorbereitet.

Ein Read-only-Profil schützt beispielsweise nicht vor Passwortdiebstahl. MFA wiederum verhindert nicht, dass eine unnötig öffentlich erreichbare Loginseite angegriffen wird. Erst das Zusammenspiel reduziert sowohl Rechte als auch Angriffsfläche.

Ein Login-Disclaimer und angepasste Messages ergänzen diese Ebenen nur um sichtbare Hinweise. Die Zustimmung erweitert weder das Device-Access-Profil noch die Netzwerkfreigabe und ersetzt keine der fünf Kontrollen.

Default-Admin, lokale Konten und zentrale Identitäten

Der Default-Benutzer admin besitzt die Rechte des integrierten Profils Administrator. Er eignet sich als lokaler Notfallzugang, aber nicht als gemeinsam genutztes Tageskonto. Passwort, MFA, Konsolenzugang und Recovery-Ablauf müssen unabhängig von den persönlichen Konten dokumentiert und getestet sein.

Bei der ersten Konfiguration muss das werkseitige Passwort des Default-Super-Administrators geändert werden. Das neue Passwort darf weder ein häufig verwendetes Passwort noch ein Wörterbuchwort sein: Die Firewall vergleicht es mit einer entsprechenden Datenbank und fordert bei einem Treffer eine Änderung. Diese Prüfung gehört bereits zur Ersteinrichtung, nicht erst zum Anlegen persönlicher Konten.

Bei einem Upgrade von 18.0 MR3 oder früher oder 17.5 MR14 ist eine einmalige Passwortänderung des Default-Super-Administrators nötig, um den stärkeren Passwortschutz zu nutzen. Das ist kein allgemeiner Pflichtschritt bei jedem Firmware-Upgrade.

Das aktuelle Passwort wird in einem zugriffsgeschützten Passworttresor aufbewahrt. Wechselt man auf eine frühere Firmware-Version, die dieses Passwort verwendet, wird es dort für die Anmeldung benötigt. Vor einem Firmware-Rollback müssen deshalb das für die frühere Version benötigte Passwort und der unabhängige Recovery-Zugang verfügbar sein; man darf nicht voraussetzen, dass das zuletzt in der neueren Firmware gesetzte Passwort dort ebenfalls gilt.

Persönliche lokale Administratoren passen zu kleinen Teams, isolierten Firewalls und als bewusster Fallback. Grössere Teams können Admin-Rollen über Microsoft Entra ID SSO für WebAdmin, TACACS+ mit lokaler Profilzuweisung oder über Sophos Fusion Administrationsrollen verwalten. Ein unter Authentication > Users mit Managed by Central gekennzeichneter Benutzer wird in Sophos Fusion verwaltet und lässt sich nicht lokal bearbeiten.

Für SFOS 23 beschreibt Google Workspace OIDC mit Admin-Gruppenmapping einen weiteren zentralen Anmeldeweg mit separatem Servicekonto, lokalen Device-Access-Profilen sowie Planung und Prüfung des Rückwegs.

Automationen erhalten kein persönliches Tageskonto. Für die XML API wird ein separates Servicekonto mit eigenem Owner, begrenzten Rechten und fester Quellfreigabe verwendet. Den vollständigen Schutzpfad zeigt Sophos Firewall XML API Zugriff absichern.

Device-Access-Profil planen

Unter Profiles > Device access stellt Sophos einige nicht editierbare Standardprofile bereit:

• Administrator: Vollzugriff auf WebAdmin und API. Sophos beschreibt das Profil auch mit CLI-Vollzugriff; der direkte SSH-Login ist in SFOS trotzdem nur mit dem Default-Benutzernamen admin möglich.
• Audit admin: Lese- und Schreibzugriff auf Logs und Reports.
• Crypto admin: Lese- und Schreibzugriff für Sicherheitszertifikate.
• HAProfile: Read-only-Zugriff auf die Auxiliary Appliance eines HA-Clusters.
• Security admin: Schreibzugriff auf die Funktionen ausser Profilen, Logs und Reports.

Diese Profile sind praktische Ausgangspunkte, aber nicht automatisch die passende Rolle für den eigenen Betrieb. Ein eigenes Profil ist besser, wenn eine Person nur einen klar begrenzten Aufgabenbereich benötigt.

Rechte aus der Aufgabe ableiten

Die Profilbezeichnung allein hat keine technische Wirkung. Ein Profil namens ReadOnly kann weiterhin Schreibrechte enthalten. Entscheidend ist die vollständige Berechtigungsmatrix einschliesslich der aufgeklappten Untermenüs.

Für ein Helpdesk-Konto kann man beispielsweise so planen:

• Diagnose, Logs und die für den Support benötigten Konfigurationsbereiche auf Read-only setzen.
• Read-write nur vergeben, wenn das Team eine konkret benannte Änderung selbst durchführen muss.
• Administratorprofile, Zertifikate und alle nicht benötigten Produktbereiche auf None lassen.
• Für jede Schreibberechtigung ein Beispiel definieren, was erlaubt sein soll, und ein Beispiel, was ausdrücklich nicht erlaubt sein darf.

Ein Network-Operations-Profil darf breiter lesen und beispielsweise ausgewählte Netzwerkbereiche ändern. Es braucht deshalb trotzdem keinen Vollzugriff auf Administratoren, Zertifikate oder andere unabhängige Sicherheitsfunktionen. Least Privilege bedeutet nicht möglichst wenig sichtbare Menüs, sondern genau die Rechte, die für die verantwortete Aufgabe nötig sind.

Eigenes Profil erstellen

1. Profiles > Device access öffnen.
2. Add auswählen.
3. Einen eindeutigen Namen eintragen, beispielsweise SFOS-NOC-Limited.
4. Für jedes sichtbare Menü None, Read-only oder Read-write wählen.
5. Mit Expand die Untermenüs öffnen und abweichende Rechte enger festlegen.
6. Mit Save speichern.
7. Das Profil nochmals gegen die dokumentierten Aufgaben und Negativtests prüfen.

SFOS-NOC-Limited ist nur ein Beispielname. Er wird an Team und Aufgabe angepasst. Die tatsächlich vergebenen Rechte müssen zusätzlich dokumentiert werden, weil der Name die Berechtigungsmatrix nicht erklärt.

Bestehende Rechte ohne Aussperren ändern

Zum Prüfen eines bestehenden Profils öffnet man Profiles > Device access und wählt beim betreffenden Profil Edit. Mit Expand werden die Untermenüs aufgeklappt, damit die vollständige vorhandene Berechtigungsmatrix sichtbar ist; bei einer reinen Prüfung werden keine Rechte geändert oder gespeichert. Standardprofile bleiben nicht editierbar: Edit dient hier nur der Einsicht, Änderungen sind ausschliesslich bei Custom-Profilen möglich.

Eine Profiländerung wirkt auf alle Administratoren, denen dieses Profil zugewiesen ist. Vor einer Verschärfung werden deshalb der aktuelle Profilname, die vollständige aufgeklappte Rechtematrix und alle zugewiesenen Konten dokumentiert. Zum Prior State gehören ausserdem die Reihenfolge unter Authentication > Services > Administrator authentication methods, Schedule, Login Restriction, die WebAdmin-Freigaben unter Administration > Device access sowie die aktuellen Werte für Passwortkomplexität und Block login. Ein aktuelles Konfigurationsbackup, eine offene Sitzung eines zweiten Volladministrators und der getestete Konsolenzugang sind Voraussetzungen, nicht der Rollback selbst.

Statt ein gemeinsam verwendetes Profil direkt umzubauen, erstellt man das engere Profil neu und weist es zuerst genau einem Pilotkonto zu. Nach Positivtest, Negativtest und Audit-Kontrolle werden weitere Konten einzeln migriert. So betrifft ein Fehler nicht gleichzeitig alle Administratoren.

Der sichere Rückweg stellt aus der noch offenen Volladmin-Sitzung die exakt dokumentierten vorherigen Werte wieder her: dem Pilotkonto das frühere Profil zuweisen und geänderte Authentifizierungsmethoden, Reihenfolge, Schedule, Login Restriction, Device Access oder Lockout-Werte auf ihren jeweiligen Prior State zurücksetzen. Ist diese Sitzung nicht mehr nutzbar, verwendet man den vorab getesteten zweiten Administrator oder die lokale Konsole. Ein komplettes Backup wird nur in einem geplanten Recovery-Fenster wiederhergestellt, weil es auch unabhängige Änderungen zurücksetzen würde.

Persönlichen lokalen Administrator anlegen

Benutzer erfassen

1. Authentication > Users öffnen.
2. Add auswählen.
3. Unter Username einen dauerhaften persönlichen Namen eintragen, beispielsweise m.mueller. SFOS speichert den Namen in Kleinbuchstaben und wandelt Grossbuchstaben automatisch um; der Benutzername kann später nicht geändert werden.
4. Einen verständlichen Anzeigenamen und die geschäftliche E-Mail-Adresse erfassen.
5. User type auf Administrator setzen.
6. Unter Profile das zuvor geprüfte Profil SFOS-NOC-Limited auswählen.
7. Ein langes, eindeutiges und sicher übergebenes Passwort setzen. Wird ein häufig verwendetes Passwort oder Wörterbuchwort erkannt, verlangt die Firewall ein stärkeres Passwort.

m.mueller ist ein Muster und wird durch die eindeutige Identität der verantwortlichen Person ersetzt. Funktionsnamen wie noc-admin sollten nur verwendet werden, wenn dahinter wirklich eine einzelne technische Identität mit eigenem Owner steht. Mehrere Personen teilen kein Passwort.

Zeit und Login-Quelle begrenzen

Unter Administrator advanced settings stehen zwei zusätzliche Kontrollen zur Verfügung:

• Schedule for device access: Erlaubt WebAdmin-Anmeldungen nur während des gewählten Zeitplans. Das passt zu temporärem Support oder klaren Betriebszeiten. Für einen Bereitschaftsdienst darf der Zeitplan notwendige Notfalleinsätze nicht unbeabsichtigt blockieren.
• Login restriction for device access: Erlaubt die WebAdmin-Anmeldung nur von ausgewählten IPv4-Adressen oder einem IPv4-Bereich. Für einen Admin-Jump-Host kann beispielsweise 10.20.30.25 als Selected node verwendet werden.

Die Adresse 10.20.30.25 ist ein Beispiel aus einem privaten Netz. Sie wird durch die feste Adresse des eigenen Jump-Hosts oder Management-Arbeitsplatzes ersetzt. Bei wechselnden Clientadressen ist ein Admin-VPN oder ein dediziertes Managementnetz meist sauberer als eine grosse IP-Range.

Access time im normalen Benutzerbereich und Schedule for device access sind nicht dasselbe. Access Time für normale Benutzer und Gruppen steuert den Internetzugriff; für WebAdmin ist die Einstellung unter Administrator advanced settings relevant.

Lokale Authentifizierung erhalten

Unter Authentication > Services > Administrator authentication methods muss die lokale Datenbank für persönliche lokale Administratoren ausgewählt sein. Der Default-Super-Administrator admin ist von dieser Methodenliste ausgenommen, die neu angelegten lokalen Administratoren jedoch nicht.

Die lokale Methode wird nicht entfernt, bevor das neue Konto in einem separaten Browser erfolgreich getestet wurde. Bei externen Authentifizierungsservern bestimmt die Reihenfolge, wohin ein Loginversuch zuerst gesendet wird. Änderungen an dieser Reihenfolge gehören deshalb in denselben Abnahme- und Rollback-Plan wie das Konto selbst.

MFA und Erreichbarkeit absichern

Für interaktive Administratoren sollte MFA aktiviert werden. Persönliche Administratoren werden unter Authentication > Multi-factor authentication für Web admin console aufgenommen. Für den Default-Benutzer admin gilt ein eigener Schalter unter Administration > Device access > MFA for default admin. MFA für Sophos Firewall WebAdmin aktivieren erklärt Pilotgruppe, Token-Registrierung, Login Security und Recovery. MFA wird zuerst mit einem einzelnen neuen Administrator getestet, nicht gleichzeitig mit allen Konten.

Der WebAdmin bleibt zusätzlich auf Managementnetze, VPN oder eng definierte Quellen beschränkt. Eine aktive Login restriction for device access macht eine breite WAN-Freigabe nicht sicher. Umgekehrt ersetzt eine Local Service ACL nicht das persönliche Konto und dessen Rechteprofil.

Auch SSH wird nicht durch einen erfolgreichen WebAdmin-Test freigegeben. SFOS akzeptiert für den direkten SSH-Login nur den Benutzernamen admin; ein persönlicher lokaler WebAdmin wird deshalb nicht als SSH-Konto getestet. SSH braucht zusätzlich eine eigene Device-Access-Entscheidung. Die Public-Key-Verwaltung des Default-Admins und der sichere SSH-Zugang werden in Sophos Firewall per SSH verbinden getrennt behandelt.

Unter Administration > Admin and user settings gibt es zwei getrennte Bereiche: Administrator password complexity settings für Administratoren und User password complexity settings für Benutzer. In jedem Bereich wird Enable password complexity check separat aktiviert und die gewünschte Komplexität festgelegt. Der Administrator-Schalter ersetzt nicht den Benutzer-Schalter. Die Werte werden nach der eigenen Passwortpolicy gewählt; hier wird keine feste Mindestlänge oder Zeichenzahl als Produktvorgabe genannt. Vor einer Änderung werden beide Schalter und ihre bisherigen Werte dokumentiert. Nach dem Speichern öffnet man die Seite erneut und prüft beide Bereiche getrennt, während der getestete Recovery-Zugang verfügbar bleibt.

Unter Administration > Admin and user settings ergänzen Administrator password complexity, Session-Timeout und Block login die Kontoeinstellungen. Diese Werte gelten systemweit und werden deshalb nicht für ein einzelnes Konto aggressiv verschärft. Vor einer Änderung werden Checkbox-Status, Anzahl und Zeitfenster der Fehlversuche sowie Sperrdauer wörtlich notiert; zusätzlich bleiben eine zweite Managementquelle oder der Konsolenzugang erreichbar. Block login sperrt nach Erreichen des Grenzwerts die Quell-IP für alle Dienste, sodass WebAdmin, CLI, VPN Portal und User Portal von dieser Adresse nicht mehr öffnen. Ein einzelner Fehlversuch unterhalb des Grenzwerts prüft diese Sperrwirkung nicht; auch ein fehlgeschlagenes CAPTCHA zählt laut Sophos nicht als Login-Fehlversuch. Im Produktivbetrieb kontrolliert man deshalb zuerst nur, ob die Werte gespeichert sind und gültige Anmeldungen von beiden Managementquellen weiterhin funktionieren. Ist ein echter Lockout-Test erforderlich, wird er in einem Wartungsfenster von einer isolierten Testquelle bis zum Grenzwert durchgeführt. Danach prüft man die erwartete Sperre, wartet die dokumentierte Sperrdauer ab oder verwendet den unabhängigen Recovery-Weg und bestätigt anschliessend eine gültige Anmeldung. Bei unerwartetem Verhalten stellt die offene Recovery-Sitzung genau die notierten Vorwerte wieder her.

Die Option Log out admin session after beendet inaktive WebAdmin-Sitzungen standardmässig nach 10 Minuten. Wird die Option deaktiviert, bleibt die Sitzung nicht unbegrenzt offen: SFOS meldet sie nach 30 Minuten automatisch ab. Das Deaktivieren ist deshalb keine Methode für dauerhafte Admin-Sitzungen; der reale Ablauf wird mit einer Testsitzung geprüft.

Rechte und Login sicher testen

Vor dem Test bleiben das bisherige Admin-Fenster und ein unabhängiger Recovery-Weg verfügbar. Mehrere absichtliche Fehlanmeldungen sind ungeeignet, weil Block login die gemeinsame Quell-IP vorübergehend für weitere Anmeldedienste sperren kann.

1. Ein privates Browserfenster öffnen und den WebAdmin über den vorgesehenen FQDN aus dem erlaubten Managementnetz aufrufen.
2. Mit dem neuen Konto und MFA anmelden.
3. Prüfen, ob alle benötigten Menüs sichtbar sind und die vorgesehenen Informationen gelesen werden können.
4. Falls das Profil Schreibrechte enthält, eine ungefährliche, vorab genehmigte Teständerung mit direktem Rollback durchführen.
5. Einen Bereich öffnen, der auf None oder Read-only steht. Das Konto darf dort keine verbotene Änderung speichern können.
6. Einen kontrollierten Login von einer nicht erlaubten Quelle höchstens einmal prüfen. Bei unklarem Ergebnis zuerst Einstellungen und Logs auswerten, nicht weitere Fehlversuche erzeugen.
7. Die Teständerung und den verwendeten Administrator im Configuration Audit Trail prüfen. Nicht jedes Objekt erzeugt dort denselben Detailumfang; die technische Wirkung wird zusätzlich in der betroffenen Funktion kontrolliert.
8. Abmelden, erneut anmelden und erst danach das nächste Konto migrieren.

In einem HA-Cluster wird nach einem geplanten Failover zusätzlich eine frische Anmeldung am jetzt aktiven Node geprüft. Eine bestehende WebAdmin-Sitzung oder deren nahtlose Fortsetzung ist kein verlässliches Erfolgskriterium. Logs und Reports werden zwischen den HA-Geräten nicht synchronisiert; für die Fehleranalyse werden Log viewer > System und die relevanten Authentifizierungsereignisse deshalb auf beiden Geräten geprüft.

Für SFOS 22.0 gehört auch die Firmware-Abnahme dazu. Seit 22.0 MR1 wird bei Änderungen an einer einzelnen Firewall über Sophos Fusion (ehemals Sophos Central) die Sophos-Fusion-Benutzeridentität im Firewall Log Viewer sowie in Sophos Fusion protokolliert; ausserdem werden Conditional-Access-Richtlinien bei Entra-ID-SSO-Sitzungen erneut ausgewertet. Diese Zuordnung wird nach einem Update mit einer harmlosen Teständerung kontrolliert. Vor jedem Rollout werden Zielbuild, unterstützter Upgradepfad und versionsspezifische Blocker im SFOS 22 Upgrade-Check geprüft und im Change freigegeben; dessen Release- und Known-Issue-Prüfung ist für die Rollout-Entscheidung massgebend.

Ein sichtbares Menü beweist noch keine funktionierende Schreibberechtigung. Ein ausgeblendetes Menü beweist nicht, dass andere zugewiesene Funktionen korrekt sind. Positivtest, Negativtest und Audit-Zuordnung gehören deshalb zusammen.

Konten prüfen und sicher entfernen

Admin-Zugänge werden regelmässig gegen Owner, Aufgabe, Profil, MFA, Login-Quelle und letzte Nutzung geprüft. Temporäre Supportkonten erhalten zusätzlich ein dokumentiertes Enddatum. Für einen zeitlich begrenzten Avanet-Fall bleibt der eigene Ablauf Avanet Support-Zugang auf Sophos Firewall einrichten massgebend.

Davon zu unterscheiden ist der herstellereigene Zugang unter Diagnostics > Support access. Er erzeugt für die gewählte Dauer eine Access ID, mit der Sophos Support WebAdmin und Shell ohne Weitergabe der Admin-Zugangsdaten erreicht. Dafür baut die Firewall eine Verbindung über TCP 22 zu *.apu.sophos.com auf; vorgeschaltete Systeme müssen diesen Weg erlauben. Die Access ID wird nur im bestehenden Supportfall übergeben, der Status während der Arbeiten kontrolliert und Support access danach sofort deaktiviert – auch wenn die gewählte Laufzeit noch nicht abgelaufen ist.

Beim Offboarding ist ein kontrollierter Ablauf sicherer als sofortiges Löschen:

1. Prüfen, ob das Konto in API-Skripten, Passworttresoren, Dokumentationen oder Supportprozessen verwendet wird.
2. Unter Authentication > Users den Status auf inaktiv setzen.
3. In einem privaten Browser prüfen, dass keine neue Anmeldung mehr möglich ist.
4. Aktive WebAdmin-Sitzungen und aktuelle Änderungen separat prüfen. Das Deaktivieren darf nicht ungeprüft als Beweis gelten, dass jede bestehende Sitzung sofort beendet wurde.
5. MFA-Token, Secrets und externe Zuweisungen passend zum Konto entfernen oder rotieren.
6. Nach der vereinbarten Beobachtungszeit den Benutzer löschen, wenn keine Abhängigkeit mehr besteht.
7. Ein nicht mehr benötigtes Custom-Profil erst löschen, wenn es keinem Administrator mehr zugewiesen ist.

Der Default-Administrator bleibt ausserhalb dieses normalen Offboardings. Wird dessen Passwort oder MFA-Zugang verloren, hilft Sophos Firewall Admin-Passwort wiederherstellen bei der Vorbereitung des Recovery-Wegs.

Typische Probleme eingrenzen

Konto existiert, WebAdmin-Anmeldung schlägt aber fehl

Diese Punkte in Reihenfolge prüfen:

• User type ist wirklich Administrator.
• Benutzerstatus ist aktiv und das Passwort stimmt.
• Local ist unter Administrator authentication methods ausgewählt.
• Schedule for device access erlaubt den aktuellen Zeitpunkt.
• Login restriction for device access enthält die tatsächliche IPv4-Quelladresse.
• MFA-Token, Systemzeit und Registrierung sind korrekt.
• Block login hat die Quell-IP nach Fehlversuchen nicht gesperrt.
• Device Access oder eine Local Service ACL erlaubt HTTPS aus dieser Quelle.

Ist die Loginseite gar nicht erreichbar, beginnt die Analyse bei Device Access, Routing und Quelladresse. Ist sie erreichbar, lehnt aber nur dieses Konto ab, sind Benutzer, Profil, Authentifizierungsmethode, Schedule, Login Restriction und MFA die näheren Spuren.

Für die zeitliche Korrelation helfen der Authentication-Bereich im Log Viewer sowie access_server.log für Authentifizierung und Autorisierung. syslog.log ergänzt System- und admin-ausgelöste Ereignisse. Änderungen an unterstützten Objekten werden separat in configuration-audit.log geprüft.

Konto sieht zu viel oder zu wenig

Das zugewiesene Profil und dessen aufgeklappte Untermenüs prüfen. Read-only und Read-write können innerhalb eines Hauptmenüs unterschiedlich gesetzt sein. Danach mit einer neuen Anmeldung erneut testen und nicht nur auf den Profilnamen vertrauen.

Bei Managed by Central kommt die Rolle aus Sophos Fusion und wird nicht am lokalen Benutzer geändert. Bei Entra SSO entscheidet das Rollen- oder Gruppenmapping des Entra-Servers über das lokale Device-Access-Profil.

WebAdmin funktioniert, API oder SSH aber nicht

Das Device-Access-Profil gilt auch für API-Rechte, aber die API braucht zusätzlich aktivierten API-Zugriff und eine erlaubte Quelle. SSH ist ein eigener lokaler Dienst und kein geeigneter Erfolgstest für ein eingeschränktes WebAdmin-Profil. Ein Konto erhält nicht allein deshalb SSH-Zugriff, weil die WebAdmin-Anmeldung funktioniert.

NC-177609 ist ausdrücklich für SFOS 22.0 GA Respin Build 411 dokumentiert: Nach einem Upgrade können API-basierte Konfigurationsänderungen eines migrierten Benutzers abgelehnt werden, wenn MFA aktiv ist und der Request keinen One-Time Token enthält. Passt dieses Fehlerbild exakt, werden Build und Migrationsstatus des Kontos dokumentiert. Der dokumentierte Workaround verlangt für die Automation ein eigenes API-Konto nach dem Least-Privilege-Prinzip, bei dem MFA deaktiviert ist oder das ausdrücklich von MFA ausgenommen wurde; für interaktive Administratoren bleibt MFA aktiv. Der benannte API-Verantwortliche muss diese Ausnahme genehmigen und dokumentieren, einen Kontoverantwortlichen und Prüftermin festlegen, Quelle und API-Rechte beschränken, das Secret sicher verwahren und rotieren, die Nutzung überwachen und die Ausnahme entfernen, sobald sie nicht mehr erforderlich ist. Nach der Änderung wird zuerst mit einer ungefährlichen Leseabfrage und dann mit einer genehmigten kontrollierten Schreiboperation samt Rollback geprüft. Sophos Firewall XML API Zugriff absichern und der benannte API-Verantwortliche sind gemeinsam für diesen Ablauf zuständig; aus einem späteren Build darf kein Behebungsstatus abgeleitet werden.

Betriebscheckliste

• Default-Administrator und Recovery-Weg sind getestet und werden nicht geteilt.
• Jede Person verwendet ein eigenes Konto.
• Profile sind aus Aufgaben abgeleitet und Untermenüs wurden aufgeklappt geprüft.
• Vollzugriff ist auf den kleinsten notwendigen Personenkreis begrenzt.
• MFA, Schedule und Login-Quelle passen zum Einsatzzweck.
• WebAdmin ist nur aus vorgesehenen Managementquellen erreichbar.
• Positive und negative Rechteprüfungen wurden durchgeführt.
• Änderungen sind mit einem persönlichen Admin-Konto im Audit Trail, soweit unterstützt, nachvollziehbar.
• Prior State und kontoübergreifender Rollback für Profil-, Authentifizierungs- und Lockout-Änderungen sind dokumentiert.
• In HA wurden frischer Login und getrennte Logs auf beiden Geräten geprüft.
• API- und Supportkonten haben eigene Owner und Lebenszyklen.
• Offboarding umfasst Status, Sitzungen, MFA, Secrets und Abhängigkeiten.

FAQ