Konfigurera administratörer och profiler säkert på Sophos Firewall

För den dagliga administrationen bör varje person få ett eget konto. Först skapas en lämplig Device Access-profil och därefter en lokal användare med User type: Administrator under Authentication > Users. Profilen avgör vad administratören får se eller ändra. MFA, inloggningskällor och Device Access skyddar dessutom inloggningen och åtkomsten till WebAdmin.

Standardadministratören admin behålls som testad nödåtkomst och används inte som ett delat konto i det dagliga arbetet. Då kan ändringar kopplas till en person och ett fel i en begränsad profil blockerar inte den sista återställningsvägen.

Konfigurera en lokal administratör i åtta steg

1. Kontrollera backup, standardadministratör och återställningsåtkomst. Låt en befintlig administratörssession vara öppen tills testet har lyckats.
2. Dokumentera uppgiften och de rättigheter som behövs, exempelvis endast diagnostik eller även ändringar av nätverksobjekt.
3. Skapa en egen profil under Profiles > Device access > Add och lämna områden som inte behövs som None.
4. Ange ett personligt användarnamn under Authentication > Users > Add och ställ in User type på Administrator.
5. Tilldela den nya profilen, ett starkt unikt lösenord och en e-postadress för arbetet.
6. Begränsa vid behov Schedule for device access och Login restriction for device access under Administrator advanced settings.
7. Kontrollera att Local fortfarande är tillgängligt under Authentication > Services > Administrator authentication methods. Konfigurera därefter MFA och WebAdmin-åtkomst från managementnätet.
8. Genomför ett positivt och ett negativt test av kontot i ett privat webbläsarfönster. Ändra först därefter andra konton eller inaktivera gamla åtkomster.

⚠️ Använd en ny profil i produktion först när det finns en andra fungerande administratör och en dokumenterad återställningsväg. Den inbyggda profilen Administrator ger fullständig åtkomst och ska bara tilldelas minsta nödvändiga personkrets.

Håll isär de fem skyddslagren

Flera inställningar samverkar vid administrativ åtkomst. De har olika uppgifter och ersätter inte varandra:

• Användarkonto: identifierar personen. Personliga konton gör ändringar spårbara, medan teamkonton som firewalladmin suddar ut kopplingen.
• Device Access-profil: anger med None, Read-only och Read-write vilka menyer och funktioner som är synliga eller kan ändras. Rättigheterna gäller även för API:n.
• Schedule och Login Restriction: begränsar när och från vilka IPv4-adresser det specifika administratörskontot får använda WebAdmin.
• Device Access och Local Service ACL: anger från vilka zoner och källor WebAdmin över huvud taget kan nås. Konfigurationen beskrivs i Konfigurera Device Access och Local Service ACL säkert.
• MFA och Audit Trail: MFA skyddar kontot utöver lösenordet. Audit Trail hjälper till att koppla ändringar som stöds till en identitet, källa och konsol. För Data Anonymization i loggar och rapporter förbereds dessutom minst två personliga authorizers med separata konton.

En Read-only-profil skyddar exempelvis inte mot lösenordsstöld. MFA förhindrar i sin tur inte angrepp mot en inloggningssida som är onödigt åtkomlig från internet. Det är först genom samspelet som både behörigheterna och angreppsytan minskar.

Ett inloggningsmeddelande och anpassade meddelandetexter kompletterar dessa lager enbart med synlig information. Godkännandet utökar varken Device Access-profilen eller nätverksåtkomsten och ersätter ingen av de fem kontrollerna.

Standardadministratör, lokala konton och centrala identiteter

Standardanvändaren admin har rättigheterna i den inbyggda profilen Administrator. Kontot passar som lokal nödåtkomst men inte som ett delat konto för den dagliga driften. Lösenord, MFA, konsolåtkomst och återställningsprocess måste vara dokumenterade och testade oberoende av de personliga kontona.

Personliga lokala administratörer passar för små team, isolerade brandväggar och som en medveten fallback. Större team kan hantera administratörsroller via Microsoft Entra ID SSO för WebAdmin, TACACS+ med lokal profiltilldelning eller administrationsroller i Sophos Central. En användare som är markerad med Managed by Central under Authentication > Users hanteras i Central och kan inte redigeras lokalt.

Automationer får inget personligt konto för den dagliga driften. För XML API används ett separat servicekonto med en egen ägare, begränsade rättigheter och en fast tillåten källa. Hela skyddskedjan beskrivs i Säkra åtkomsten till Sophos Firewall XML API.

Planera en Device Access-profil

Under Profiles > Device access tillhandahåller Sophos flera standardprofiler som inte kan redigeras:

• Administrator: fullständig åtkomst till WebAdmin och API. Sophos beskriver även profilen med fullständig CLI-åtkomst, men direkt SSH-inloggning i SFOS är ändå endast möjlig med standardanvändarnamnet admin.
• Audit admin: läs- och skrivåtkomst till loggar och rapporter.
• Crypto admin: läs- och skrivåtkomst till säkerhetscertifikat.
• HAProfile: Read-only-åtkomst till Auxiliary-enheten i ett HA-kluster.
• Security admin: skrivåtkomst till funktionerna utom profiler, loggar och rapporter.

Dessa profiler är praktiska utgångspunkter men är inte automatiskt rätt roll för den egna driften. En egen profil är bättre när en person bara behöver ett tydligt avgränsat ansvarsområde.

Härled rättigheterna från uppgiften

Profilnamnet har ingen teknisk effekt i sig. En profil med namnet ReadOnly kan fortfarande innehålla skrivrättigheter. Det är hela behörighetsmatrisen, inklusive de expanderade undermenyerna, som avgör.

För ett helpdesk-konto kan planeringen exempelvis se ut så här:

• Ställ in diagnostik, loggar och konfigurationsområden som behövs för support på Read-only.
• Ge endast Read-write om teamet själv måste utföra en konkret namngiven ändring.
• Lämna administratörsprofiler, certifikat och alla produktområden som inte behövs som None.
• Definiera för varje skrivrättighet ett exempel på vad som ska vara tillåtet och ett exempel på vad som uttryckligen inte får vara tillåtet.

En Network Operations-profil får läsa fler områden och exempelvis ändra utvalda nätverksdelar. Den behöver ändå inte fullständig åtkomst till administratörer, certifikat eller andra oberoende säkerhetsfunktioner. Least Privilege betyder inte så få synliga menyer som möjligt, utan exakt de rättigheter som krävs för den tilldelade uppgiften.

Skapa en egen profil

1. Öppna Profiles > Device access.
2. Välj Add.
3. Ange ett entydigt namn, exempelvis SFOS-NOC-Limited.
4. Välj None, Read-only eller Read-write för varje synlig meny.
5. Öppna undermenyerna med Expand och begränsa avvikande rättigheter mer exakt.
6. Spara med Save.
7. Kontrollera profilen igen mot de dokumenterade uppgifterna och de negativa testerna.

SFOS-NOC-Limited är bara ett exempelnamn. Anpassa det efter team och uppgift. De rättigheter som faktiskt har tilldelats måste dessutom dokumenteras eftersom namnet inte förklarar behörighetsmatrisen.

Skapa en personlig lokal administratör

Registrera användaren

1. Öppna Authentication > Users.
2. Välj Add.
3. Ange ett beständigt personligt namn under Username, exempelvis m.mueller. Användarnamnet kan inte ändras senare.
4. Ange ett begripligt visningsnamn och e-postadressen för arbetet.
5. Ställ in User type på Administrator.
6. Välj den tidigare kontrollerade profilen SFOS-NOC-Limited under Profile.
7. Ange ett långt, unikt och säkert överlämnat lösenord. Om brandväggen identifierar ett vanligt lösenord eller ett ord från en ordlista kräver den ett starkare lösenord.

m.mueller är ett exempel och ska ersättas med den ansvariga personens entydiga identitet. Funktionsnamn som noc-admin bör bara användas om de verkligen avser en enda teknisk identitet med en egen ägare. Flera personer delar inte ett lösenord.

Begränsa tid och inloggningskälla

Under Administrator advanced settings finns två ytterligare kontroller:

• Schedule for device access: tillåter WebAdmin-inloggningar endast under det valda schemat. Det passar för tillfällig support eller tydliga drifttider. För beredskapstjänst får schemat inte oavsiktligt blockera nödvändiga akuta insatser.
• Login restriction for device access: tillåter WebAdmin-inloggning endast från valda IPv4-adresser eller ett IPv4-intervall. För en administrativ jump host kan exempelvis 10.20.30.25 användas som Selected node.

Adressen 10.20.30.25 är ett exempel från ett privat nät. Ersätt den med den fasta adressen till den egna jump hosten eller managementarbetsstationen. Vid växlande klientadresser är en administrativ VPN eller ett dedikerat managementnät vanligtvis bättre än ett stort IP-intervall.

Access Time för vanliga användare och grupper styr internetåtkomst; för WebAdmin är Schedule for device access under Administrator advanced settings relevant. Det är inte samma inställning.

Behåll lokal autentisering

Under Authentication > Services > Administrator authentication methods måste den lokala databasen vara vald för personliga lokala administratörer. Standardsuperadministratören admin är undantagen från denna metodlista, men det är inte de nyskapade lokala administratörerna.

Ta inte bort den lokala metoden innan det nya kontot har testats framgångsrikt i en separat webbläsare. Med externa autentiseringsservrar avgör ordningen vart ett inloggningsförsök skickas först. Ändringar av ordningen hör därför till samma acceptans- och rollbackplan som själva kontot.

Säkra inloggningen med MFA och begränsa åtkomsten

MFA bör aktiveras för interaktiva administratörer. Personliga administratörer läggs till för Web admin console under Authentication > Multi-factor authentication. För standardanvändaren admin finns en separat inställning under Administration > Device access > MFA for default admin. Aktivera MFA för Sophos Firewall WebAdmin beskriver pilotgrupp, tokenregistrering, Login Security och återställning. Testa först MFA med en enda ny administratör, inte med alla konton samtidigt.

WebAdmin begränsas dessutom till managementnät, VPN eller snävt definierade källor. En aktiv Login restriction for device access gör inte en bred WAN-tillåtelse säker. Omvänt ersätter en Local Service ACL inte det personliga kontot och dess behörighetsprofil.

SSH tillåts inte heller genom ett lyckat WebAdmin-test. SFOS accepterar endast användarnamnet admin för direkt SSH-inloggning. En personlig lokal WebAdmin-administratör testas därför inte som ett SSH-konto. SSH kräver dessutom ett separat beslut för Device Access. Hantering av standardadministratörens public key och säker SSH-åtkomst behandlas separat i Ansluta till Sophos Firewall via SSH.

Under Administration > Admin and user settings kompletterar Administrator password complexity, Session Timeout och Block login kontoinställningarna. Dessa värden gäller för hela systemet och skärps därför inte aggressivt för ett enskilt konto. Särskilt Block login kan efter misslyckade försök blockera käll-IP-adressen för alla inloggningstjänster. Före testet behövs därför en andra managementkälla eller konsolåtkomst.

Testa rättigheter och inloggning säkert

Låt det befintliga administratörsfönstret och en oberoende återställningsväg vara tillgängliga före testet. Flera avsiktligt misslyckade inloggningar är olämpliga eftersom Block login tillfälligt kan blockera den gemensamma käll-IP-adressen för fler inloggningstjänster.

1. Öppna ett privat webbläsarfönster och anropa WebAdmin via avsedd FQDN från det tillåtna managementnätet.
2. Logga in med det nya kontot och MFA.
3. Kontrollera att alla nödvändiga menyer är synliga och att avsedd information kan läsas.
4. Om profilen har skrivrättigheter, genomför en ofarlig och i förväg godkänd teständring med omedelbar rollback.
5. Öppna ett område som är inställt på None eller Read-only. Kontot får inte kunna spara en otillåten ändring där.
6. Testa en kontrollerad inloggning från en otillåten källa högst en gång. Analysera först inställningar och loggar om resultatet är oklart och generera inte fler misslyckade försök.
7. Kontrollera teständringen och administratören som användes i Configuration Audit Trail. Alla objekt ger inte samma detaljnivå där. Kontrollera därför även den tekniska effekten i den berörda funktionen.
8. Logga ut, logga in igen och migrera först därefter nästa konto.

I ett HA-kluster kontrolleras dessutom en ny inloggning på den nu aktiva noden efter en planerad failover. En befintlig WebAdmin-session eller en sömlös fortsättning av den är inget tillförlitligt framgångskriterium.

En synlig meny bevisar ännu inte att skrivrättigheten fungerar. En dold meny bevisar inte att andra tilldelade funktioner är korrekta. Positivt test, negativt test och koppling i Audit Trail hör därför ihop.

Granska och ta bort konton säkert

Administrativa åtkomster granskas regelbundet med avseende på ägare, uppgift, profil, MFA, inloggningskälla och senaste användning. Tillfälliga supportkonton får dessutom ett dokumenterat slutdatum. För ett tidsbegränsat Avanet-ärende gäller fortfarande den separata processen Konfigurera Avanet-supportåtkomst på Sophos Firewall.

Vid offboarding är en kontrollerad process säkrare än att radera kontot direkt:

1. Kontrollera om kontot används i API-skript, lösenordsvalv, dokumentation eller supportprocesser.
2. Ställ in statusen som inaktiv under Authentication > Users.
3. Kontrollera i en privat webbläsare att en ny inloggning inte längre är möjlig.
4. Kontrollera aktiva WebAdmin-sessioner och aktuella ändringar separat. Inaktiveringen får inte utan kontroll betraktas som bevis för att alla befintliga sessioner avslutades omedelbart.
5. Ta bort eller rotera MFA-token, secrets och externa tilldelningar som hör till kontot.
6. Radera användaren efter överenskommen observationsperiod om inga beroenden finns kvar.
7. Radera en anpassad profil som inte längre behövs först när den inte är tilldelad till någon administratör.

Standardadministratören ingår inte i denna normala offboarding. Om lösenordet eller MFA-åtkomsten förloras hjälper Återställa administratörslösenordet för Sophos Firewall till att förbereda återställningsvägen.

Avgränsa typiska problem

Kontot finns men WebAdmin-inloggningen misslyckas

Kontrollera följande punkter i ordning:

• User type är verkligen inställt på Administrator.
• Användarstatusen är aktiv och lösenordet är korrekt.
• Local är valt under Administrator authentication methods.
• Schedule for device access tillåter den aktuella tiden.
• Login restriction for device access innehåller den faktiska IPv4-källadressen.
• MFA-token, systemtid och registrering är korrekta.
• Block login har inte blockerat käll-IP-adressen efter misslyckade försök.
• Device Access eller en Local Service ACL tillåter HTTPS från denna källa.

Om inloggningssidan inte kan nås alls börjar analysen med Device Access, routing och källadress. Om den kan nås men bara nekar detta konto är användaren, profilen, autentiseringsmetoden, Schedule, Login Restriction och MFA de närmaste spåren.

För tidsmässig korrelation hjälper området Authentication i Log Viewer samt access_server.log för autentisering och auktorisering. syslog.log kompletterar med systemhändelser och händelser som utlösts av en administratör. Ändringar av objekt som stöds kontrolleras separat i configuration-audit.log.

Kontot ser för mycket eller för lite

Kontrollera den tilldelade profilen och dess expanderade undermenyer. Read-only och Read-write kan vara olika inställda inom en huvudmeny. Testa därefter igen med en ny inloggning och lita inte bara på profilnamnet.

Med Managed by Central kommer rollen från Sophos Central och ändras inte på den lokala användaren. Med Entra SSO avgör roll- eller gruppmappningen på Entra-servern vilken lokal Device Access-profil som används.

WebAdmin fungerar men inte API eller SSH

Device Access-profilen gäller även för API-rättigheter, men API:n kräver dessutom att API-åtkomst är aktiverad och att källan är tillåten. SSH är en separat lokal tjänst och inget lämpligt framgångstest för en begränsad WebAdmin-profil. Ett konto får inte SSH-åtkomst bara för att WebAdmin-inloggningen fungerar.

Driftchecklista

• Standardadministratören och återställningsvägen är testade och delas inte.
• Varje person använder ett eget konto.
• Profilerna är härledda från uppgifterna och de expanderade undermenyerna har kontrollerats.
• Fullständig åtkomst är begränsad till minsta nödvändiga personkrets.
• MFA, Schedule och inloggningskälla passar användningsområdet.
• WebAdmin kan endast nås från avsedda managementkällor.
• Positiva och negativa behörighetstester har genomförts.
• Ändringar kan, i den mån det stöds, spåras till ett personligt adminkonto i Audit Trail.
• API- och supportkonton har egna ägare och livscykler.
• Offboarding omfattar status, sessioner, MFA, secrets och beroenden.

FAQ