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. Spara därefter användaren med Save, bekräfta posten i användarlistan och öppna den igen: User type: Administrator, Profile, Schedule for device access och Login restriction for device access måste motsvara de avsedda värdena innan Users lämnas.
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. None hindrar administratören från att se den berörda konfigurationen i WebAdmin eller hämta den via API:n. Read-only tillåter däremot läsning, men inte ändringar.
• 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.

Vid den första konfigurationen måste fabrikslösenordet för standardsuperadministratören ändras. Det nya lösenordet får inte vara ett vanligt lösenord eller ett ord från en ordlista: brandväggen jämför det med en motsvarande databas och begär en ändring om det finns en träff. Denna kontroll ingår redan i den första konfigurationen, inte bara när personliga konton skapas.

Vid uppgradering från 18.0 MR3 eller tidigare eller 17.5 MR14 krävs en engångsändring av lösenordet för standardsuperadministratören för att dra nytta av starkare lösenordsskydd. Det är inget generellt krav vid varje firmwareuppgradering.

Förvara det aktuella lösenordet i ett lösenordsvalv med åtkomstkontroll. Om man återgår till en tidigare firmwareversion som använder detta lösenord behövs det för att logga in där. Före en firmwareåtergång måste därför lösenordet som den tidigare versionen behöver och en oberoende återställningsväg finnas tillgängliga; förutsätt inte att lösenordet som senast ställdes in i den nyare firmwaren också gäller där.

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 Fusion. En användare som är markerad med Managed by Central under Authentication > Users hanteras i Sophos Fusion och kan inte redigeras lokalt.

För SFOS 23 beskriver Google Workspace OIDC med mappning av administratörsgrupper ytterligare ett centralt inloggningssätt med ett separat tjänstekonto, lokala Device Access-profiler samt planering och verifiering av återgången.

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.

Ändra befintliga rättigheter utan att låsa ute dig

För att granska en befintlig profil, öppna Profiles > Device access och välj Edit för den aktuella profilen. Öppna undermenyerna med Expand för att se hela den befintliga behörighetsmatrisen; ändra eller spara inga rättigheter vid en ren granskning. Standardprofiler kan fortfarande inte redigeras: Edit ger endast möjlighet att granska dem, och rättigheter kan bara ändras i anpassade profiler.

En profiländring påverkar alla administratörer som har profilen. Dokumentera före en skärpning det aktuella profilnamnet, hela den expanderade rättighetsmatrisen och alla tilldelade konton. Föregående tillstånd omfattar även ordningen under Authentication > Services > Administrator authentication methods, schema, inloggningsbegränsning, WebAdmin-behörigheter under Administration > Device access samt aktuella värden för lösenordskomplexitet och Block login. En aktuell säkerhetskopia, en öppen session för en andra fullständig administratör och testad konsolåtkomst är förutsättningar, men inte själva återställningen.

Redigera inte en delad profil direkt. Skapa den mer begränsade profilen separat och tilldela den först till exakt ett pilotkonto. Migrera övriga konton ett i taget först efter positivt test, negativt test och auditkontroll.

En säker återgång återställer via den fortfarande öppna fullständiga sessionen de exakt dokumenterade tidigare värdena: tilldela pilotkontot dess tidigare profil och återställ ändrade autentiseringsmetoder och ordning, schema, inloggningsbegränsning, Device Access och blockeringsvärden. Använd den förtestade andra administratören eller den lokala konsolen om sessionen inte fungerar. Återställ en fullständig backup endast i ett planerat återställningsfönster, eftersom även orelaterade ändringar rullas tillbaka.

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. SFOS lagrar det med små bokstäver och omvandlar automatiskt stora bokstäver; 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.
8. Konfigurera de Administrator advanced settings som beskrivs nedan innan användaren sparas. Spara och kontrollera sedan användaren enligt beskrivningen nedan innan du går vidare till Services eller MFA.

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. Välj Selected nodes för en administrativ jump host, ange exempeladressen 10.20.30.25 efter att den har ersatts för den egna miljön och klicka på plusknappen (+) för varje IPv4-adress. Kontrollera att listan som skapas motsvarar de avsedda källorna. Om Node range väljs i stället, ange start- och slutadressen för det avsedda IPv4-intervallet. Spara därefter användaren enligt beskrivningen nedan; att bara skriva adressen lägger inte till en post i listan.

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.

När användarfälten och Administrator advanced settings har fyllts i, klicka på Save innan Authentication > Users lämnas. Bekräfta att användaren visas i listan och öppna posten igen. User type måste vara Administrator; Profile, Schedule for device access och Login restriction for device access, inklusive de tillagda IPv4-adresserna, måste motsvara de avsedda värdena. Gå först därefter vidare till Services eller MFA. Håll den befintliga administratörssessionen och den oberoende återställningsvägen tillgängliga för följande tester.

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.

XML API: använd inte motstridiga lägesvärden

För automatisering anger Sophos XML API-dokumentation för SFOS 22 och 23 sökvägarna AdminAuthentication/AuthenticationMethods och AdminAuthentication/AuthenticationServerList/AuthenticationServer. Exemplet visar SameAsFirewall/Custom för den första sökvägen och ServerName för servern; detta är inget verifierat, körbart val av läge.

Parametertabellen motsäger exemplet: för AuthenticationMethods tillåter den endast det token som bokstavligen skrivs som ''on''. Beskrivningarna verkar också vara omkastade: AuthenticationServer beskriver att brandväggens autentiseringsmetod används, medan AuthenticationMethods beskriver servern som används vid inloggning. Varken en bekräftad väljare eller en koppling från on till Custom kan härledas ur detta.

Tills Sophos officiellt har klargjort värdena för den specifika målbuilden ges därför inget körbart recept för lägesval. Behåll den lokala återställningsmetoden och den dokumenterade serverordningen; en senare godkänd ändring hör till den befintliga acceptans- och rollbackplanen.

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 finns två separata avsnitt: Administrator password complexity settings för administratörer och User password complexity settings för användare. Aktivera Enable password complexity check separat i varje avsnitt och ange önskad komplexitet. Administratörsinställningen ersätter inte användarinställningen. Välj värden enligt den egna lösenordspolicyn; här anges ingen fast minimilängd eller något fast antal tecken som produktkrav. Dokumentera före en ändring båda inställningarna och deras tidigare värden. Öppna sidan igen efter att ha sparat och kontrollera båda avsnitten separat, samtidigt som den testade återställningsåtkomsten hålls tillgänglig.

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.

Notera före en ändring av Block login exakt kryssrutans status, antalet och tidsfönstret för misslyckade försök samt blockeringstiden. När gränsen nås blockeras käll-IP-adressen för WebAdmin, CLI, VPN Portal och User Portal. Ett enda misslyckat försök under gränsen testar inte denna blockering; Sophos anger också att en misslyckad CAPTCHA inte räknas som ett misslyckat inloggningsförsök. Kontrollera därför först i produktion endast att värdena har sparats och att giltiga inloggningar fortfarande fungerar från båda managementkällorna. Om ett verkligt lockouttest krävs ska det utföras i ett underhållsfönster från en isolerad testkälla tills gränsen nås. Kontrollera sedan den förväntade blockeringen, vänta den dokumenterade blockeringstiden eller använd den oberoende återställningsvägen och bekräfta därefter en giltig inloggning. Vid oväntat beteende återställer den öppna recovery-sessionen exakt de tidigare värdena.

Alternativet Log out admin session after avslutar som standard inaktiva WebAdmin-sessioner efter 10 minuter. Om alternativet stängs av förblir sessionen inte öppen utan tidsgräns: SFOS loggar ändå ut den automatiskt efter 30 minuter. Att stänga av alternativet är därför ingen metod för permanenta administratörssessioner; kontrollera det faktiska beteendet med en testsession.

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. Testa de två begränsningarna separat:
   • Vid None får den berörda konfigurationen varken vara synlig eller läsbar. En nekad ändring är inte tillräckligt bevis i sig.
   • Vid Read-only måste den avsedda konfigurationen förbli läsbar, men en otillåten ändring får inte sparas. Använd endast en ofarlig, i förväg godkänd teståtgärd med förberedd rollback.
   • Om kontot redan används för API-åtkomst, kontrollera avsedd API-läsåtkomst och nekad åtkomst separat med befintliga skyddsåtgärder för källor, rättigheter och hemligheter. Aktivera inte API-åtkomst enbart för att testa ett interaktivt WebAdmin-konto.
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.

Loggar och rapporter synkroniseras inte mellan HA-enheterna: kontrollera vid felsökning Log viewer > System och relevanta autentiseringshändelser på båda. Sedan SFOS 22.0 MR1 loggas Sophos Fusion-användarens identitet vid ändringar av en enskild brandvägg via Sophos Fusion (tidigare Sophos Central), och Entra ID SSO-sessioner utvärderar Conditional Access-principer på nytt. Verifiera kopplingen efter en uppdatering med en ofarlig teständring. Kontrollera före varje utrullning målbuild, uppgraderingsväg som stöds och versionsspecifika blockerare i uppgraderingskontrollen för SFOS 22 och godkänn dem i ändringen; dess kontroll av versioner och kända problem styr utrullningsbeslutet.

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.

Skilj detta konto från tillverkaråtkomsten under Diagnostics > Support access. Den skapar ett Access ID för vald tid, så att Sophos Support når WebAdmin och shell utan att få administratörsuppgifter. Brandväggen ansluter via TCP 22 till *.apu.sophos.com; uppströms system måste tillåta detta. Dela Access ID endast i det aktiva supportärendet, övervaka status under arbetet och stäng av Support access direkt efteråt, även om tiden inte har löpt ut.

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 Fusion 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.

NC-177609 är dokumenterat specifikt för SFOS 22.0 GA Respin Build 411: efter en uppgradering kan API-baserade konfigurationsändringar från en migrerad användare nekas när MFA är aktivt och begäran saknar en one-time token. Om symptomet stämmer exakt ska build och kontots migreringsstatus dokumenteras. Den dokumenterade lösningen kräver att automatiseringen använder ett särskilt API-konto med minsta möjliga behörighet, där MFA är inaktiverat eller kontot uttryckligen har undantagits från MFA; MFA förblir aktivt för interaktiva administratörer. Den utsedda API-ägaren måste godkänna och dokumentera undantaget, ange kontoägare och granskningsdatum, begränsa källa och API-rättigheter, lagra hemligheten i ett valv och rotera den, övervaka användningen och ta bort undantaget när det inte längre behövs. Efter ändringen verifieras först en ofarlig läsbegäran och sedan en godkänd, kontrollerad skrivoperation med rollback. Säkra åtkomsten till Sophos Firewall XML API och den utsedda API-ägaren ansvarar gemensamt för detta arbetsflöde; dra inga slutsatser om korrigeringsstatus från en senare build.

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.
• Föregående tillstånd och återställning mellan konton för profil-, autentiserings- och blockeringsändringar är dokumenterade.
• I HA har en ny inloggning och separata loggar på båda enheterna kontrollerats.
• API- och supportkonton har egna ägare och livscykler.
• Offboarding omfattar status, sessioner, MFA, secrets och beroenden.

FAQ