Sophos Firewall-beheerders en profielen veilig instellen

Voor het dagelijkse beheer hoort iedere persoon een eigen account te krijgen. Daarvoor wordt eerst een passend Device Access-profiel gemaakt en vervolgens onder Authentication > Users een lokale gebruiker met User type: Administrator aangemaakt. Het profiel bepaalt wat de beheerder kan zien of wijzigen. MFA, loginbronnen en Device Access beveiligen daarnaast de aanmelding en de bereikbaarheid van WebAdmin.

De standaardbeheerder admin blijft beschikbaar als geteste noodtoegang en wordt niet als gedeeld dagelijks account gebruikt. Zo blijven wijzigingen aan één persoon toe te wijzen en blokkeert een fout in een beperkt profiel niet de laatste herstelmogelijkheid.

Een lokale beheerder in acht stappen instellen

1. Controleer de backup, de standaardbeheerder en de hersteltoegang. Laat een bestaande beheersessie open tot de test is geslaagd.
2. Leg de taak en de benodigde rechten schriftelijk vast, bijvoorbeeld alleen diagnose of daarnaast wijzigingen aan netwerkobjecten.
3. Maak onder Profiles > Device access > Add een eigen profiel en laat niet benodigde onderdelen op None staan.
4. Voer onder Authentication > Users > Add een persoonlijke gebruikersnaam in en stel User type in op Administrator.
5. Wijs het nieuwe profiel, een sterk uniek wachtwoord en het zakelijke e-mailadres toe.
6. Beperk onder Administrator advanced settings zo nodig Schedule for device access en Login restriction for device access. Sla de gebruiker daarna op met Save, bevestig de vermelding in de gebruikerslijst en open deze opnieuw: User type: Administrator, Profile, Schedule for device access en Login restriction for device access moeten overeenkomen met de bedoelde waarden voordat Users wordt verlaten.
7. Controleer of Local onder Authentication > Services > Administrator authentication methods beschikbaar blijft. Configureer daarna MFA en WebAdmin-toegang vanuit het beheernetwerk.
8. Test het account positief en negatief in een privébrowservenster. Pas daarna andere accounts aan of schakel oude toegangen uit.

⚠️ Gebruik een nieuw profiel pas in productie wanneer een tweede werkende beheerder en een gedocumenteerde herstelprocedure beschikbaar zijn. Het ingebouwde profiel Administrator geeft volledige toegang en hoort alleen bij de kleinst mogelijke groep personen.

De vijf beveiligingslagen uit elkaar houden

Bij beheerstoegang werken meerdere instellingen samen. Ze hebben verschillende taken en vervangen elkaar niet:

• Gebruikersaccount: identificeert de persoon. Persoonlijke accounts maken wijzigingen traceerbaar; teamaccounts zoals firewalladmin vertroebelen die koppeling.
• Device Access-profiel: bepaalt met None, Read-only en Read-write welke menu’s en functies zichtbaar of wijzigbaar zijn. De rechten gelden ook voor de API. None voorkomt dat de beheerder de betreffende configuratie in WebAdmin kan bekijken of via de API kan ophalen. Read-only staat daarentegen wel lezen toe, maar geen wijzigingen.
• Schedule en Login Restriction: beperken wanneer en vanaf welke IPv4-adressen dit specifieke beheerdersaccount WebAdmin mag gebruiken.
• Device Access en Local Service ACL: bepalen vanuit welke zones en bronnen WebAdmin überhaupt bereikbaar is. De uitvoering staat in Device Access en Local Service ACL veilig configureren.
• MFA en Audit Trail: MFA beveiligt het account naast het wachtwoord. De Audit Trail helpt ondersteunde wijzigingen aan een identiteit, bron en console toe te wijzen. Voor Data Anonymization in logs en rapporten worden bovendien minimaal twee persoonlijke authorizers met afzonderlijke accounts voorbereid.

Een Read-only-profiel beschermt bijvoorbeeld niet tegen wachtwoorddiefstal. MFA voorkomt op zijn beurt niet dat een onnodig publiek bereikbare loginpagina wordt aangevallen. Alleen de combinatie beperkt zowel rechten als aanvalsvlak.

Login-disclaimers en aangepaste berichten voegen aan deze lagen alleen zichtbare meldingen toe. Acceptatie breidt noch het Device Access-profiel noch de netwerktoestemming uit en vervangt geen van de vijf controles.

Standaardbeheerder, lokale accounts en centrale identiteiten

De standaardgebruiker admin heeft de rechten van het ingebouwde profiel Administrator. Dit account is geschikt als lokale noodtoegang, maar niet als gedeeld dagelijks account. Wachtwoord, MFA, consoletoegang en herstelprocedure moeten onafhankelijk van de persoonlijke accounts zijn gedocumenteerd en getest.

Bij de eerste configuratie moet het fabriekswachtwoord van de standaard-superbeheerder worden gewijzigd. Het nieuwe wachtwoord mag geen veelgebruikt wachtwoord of woordenboekwoord zijn: de firewall vergelijkt het met een daarvoor bestemde database en vraagt bij een overeenkomst om een wijziging. Deze controle hoort al bij de eerste configuratie, niet pas bij het aanmaken van persoonlijke accounts.

Bij een upgrade vanaf 18.0 MR3 of eerder of 17.5 MR14 is een eenmalige wachtwoordwijziging voor de standaard-superbeheerder nodig om van sterkere wachtwoordbescherming te profiteren. Dit is geen algemene verplichting bij elke firmware-upgrade.

Bewaar het huidige wachtwoord in een wachtwoordkluis met toegangsbeperking. Bij een terugkeer naar een eerdere firmwareversie die dit wachtwoord gebruikt, is het nodig om daar aan te melden. Zorg daarom vóór een firmware-rollback dat het wachtwoord dat de eerdere versie nodig heeft en onafhankelijke hersteltoegang beschikbaar zijn; neem niet aan dat het laatst in de nieuwere firmware ingestelde wachtwoord daar ook geldt.

Persoonlijke lokale beheerders passen bij kleine teams, geïsoleerde firewalls en een bewuste fallback. Grotere teams kunnen beheerdersrollen beheren via Microsoft Entra ID SSO voor WebAdmin, TACACS+ met lokale profieltoewijzing of via Sophos Fusion-beheerdersrollen. Een gebruiker die onder Authentication > Users als Managed by Central is gemarkeerd, wordt in Sophos Fusion beheerd en kan niet lokaal worden bewerkt.

Voor SFOS 23 beschrijft Google Workspace OIDC met beheerdersgroepmapping een aanvullende centrale aanmeldmethode met een apart serviceaccount, lokale Device Access-profielen en het plannen en verifiëren van de terugvalroute.

Automatiseringen krijgen geen persoonlijk dagelijks account. Voor de XML API wordt een apart serviceaccount gebruikt met een eigen eigenaar, beperkte rechten en een vaste bronvrijgave. Het volledige beveiligingspad staat in Sophos Firewall XML API-toegang beveiligen.

Een Device Access-profiel plannen

Onder Profiles > Device access biedt Sophos enkele niet-bewerkbare standaardprofielen:

• Administrator: volledige toegang tot WebAdmin en API. Sophos beschrijft het profiel ook met volledige CLI-toegang; een directe SSH-login is in SFOS toch alleen mogelijk met de standaardgebruikersnaam admin.
• Audit admin: lees- en schrijftoegang tot logs en rapporten.
• Crypto admin: lees- en schrijftoegang tot beveiligingscertificaten.
• HAProfile: Read-only-toegang tot de Auxiliary appliance van een HA-cluster.
• Security admin: schrijftoegang tot de functies behalve profielen, logs en rapporten.

Deze profielen zijn handige uitgangspunten, maar niet automatisch de juiste rol voor de eigen organisatie. Een eigen profiel is beter wanneer iemand slechts een duidelijk afgebakend takenpakket nodig heeft.

Rechten afleiden uit de taak

De profielnaam heeft op zichzelf geen technische werking. Een profiel met de naam ReadOnly kan nog steeds schrijfrechten bevatten. Doorslaggevend is de volledige rechtenmatrix, inclusief de uitgeklapte submenu’s.

Voor een helpdeskaccount kan men bijvoorbeeld als volgt plannen:

• Zet diagnose, logs en de voor support benodigde configuratieonderdelen op Read-only.
• Geef Read-write alleen wanneer het team een concreet benoemde wijziging zelf moet uitvoeren.
• Laat beheerdersprofielen, certificaten en alle niet benodigde productonderdelen op None staan.
• Definieer voor elk schrijfrecht één voorbeeld van wat toegestaan moet zijn en één voorbeeld van wat uitdrukkelijk niet toegestaan mag zijn.

Een Network Operations-profiel mag breder lezen en bijvoorbeeld geselecteerde netwerkonderdelen wijzigen. Het heeft daarom nog steeds geen volledige toegang tot beheerders, certificaten of andere onafhankelijke beveiligingsfuncties nodig. Least Privilege betekent niet zo weinig mogelijk zichtbare menu’s, maar precies de rechten die voor de toegewezen taak nodig zijn.

Een eigen profiel maken

1. Open Profiles > Device access.
2. Kies Add.
3. Voer een eenduidige naam in, bijvoorbeeld SFOS-NOC-Limited.
4. Kies voor elk zichtbaar menu None, Read-only of Read-write.
5. Open met Expand de submenu’s en beperk afwijkende rechten verder.
6. Sla op met Save.
7. Controleer het profiel opnieuw aan de hand van de gedocumenteerde taken en negatieve tests.

SFOS-NOC-Limited is slechts een voorbeeldnaam. Pas hem aan team en taak aan. De daadwerkelijk verleende rechten moeten daarnaast worden gedocumenteerd, omdat de naam de rechtenmatrix niet verklaart.

Bestaande rechten wijzigen zonder uzelf buiten te sluiten

Open Profiles > Device access en kies Edit bij het betreffende profiel om een bestaand profiel te controleren. Open met Expand de submenu’s om de volledige bestaande rechtenmatrix te bekijken; wijzig of sla geen rechten op als het alleen om controle gaat. Standaardprofielen blijven niet-bewerkbaar: Edit maakt alleen inzage mogelijk en rechten kunnen uitsluitend in aangepaste profielen worden gewijzigd.

Een profielwijziging raakt alle beheerders aan wie dat profiel is toegewezen. Documenteer vóór aanscherping de huidige profielnaam, de volledig uitgeklapte rechtenmatrix en alle toegewezen accounts. De eerdere toestand omvat ook de volgorde onder Authentication > Services > Administrator authentication methods, planning, loginbeperking, WebAdmin-toegang onder Administration > Device access en de huidige waarden voor wachtwoordcomplexiteit en Block login. Een actuele back-up, een open sessie van een tweede volledige beheerder en geteste consoletoegang zijn voorwaarden, maar vormen niet zelf de rollback.

Wijzig een gedeeld profiel niet direct, maar maak het beperktere profiel afzonderlijk en wijs het eerst aan precies één pilotaccount toe. Migreer andere accounts pas één voor één na de positieve en negatieve test en de auditcontrole.

De veilige rollback herstelt vanuit de nog open volledige beheersessie de exact gedocumenteerde vorige waarden: wijs het pilotaccount zijn oude profiel toe en zet gewijzigde authenticatiemethoden en volgorde, planning, loginbeperking, Device Access en blokkeerwaarden terug naar hun eerdere toestand. Gebruik de vooraf geteste tweede beheerder of lokale console als die sessie niet meer werkt. Herstel een volledige back-up alleen in een gepland herstelvenster, omdat daarmee ook niet-gerelateerde wijzigingen worden teruggedraaid.

Een persoonlijke lokale beheerder aanmaken

Gebruiker vastleggen

1. Open Authentication > Users.
2. Kies Add.
3. Voer onder Username een blijvende persoonlijke naam in, bijvoorbeeld m.mueller. SFOS slaat deze in kleine letters op en zet hoofdletters automatisch om; de gebruikersnaam kan later niet worden gewijzigd.
4. Leg een begrijpelijke weergavenaam en het zakelijke e-mailadres vast.
5. Stel User type in op Administrator.
6. Selecteer onder Profile het eerder gecontroleerde profiel SFOS-NOC-Limited.
7. Stel een lang, uniek en veilig overgedragen wachtwoord in. Wanneer de firewall een veelgebruikt wachtwoord of woordenboekwoord herkent, vraagt hij om een sterker wachtwoord.
8. Configureer vóór het opslaan de hieronder beschreven Administrator advanced settings. Sla de gebruiker vervolgens op en controleer deze zoals hieronder beschreven voordat naar Services of MFA wordt gegaan.

m.mueller is een voorbeeld en wordt vervangen door de unieke identiteit van de verantwoordelijke persoon. Functienamen zoals noc-admin horen alleen te worden gebruikt wanneer daar werkelijk één technische identiteit met een eigen eigenaar achter zit. Meerdere personen delen geen wachtwoord.

Tijd en loginbron beperken

Onder Administrator advanced settings zijn twee aanvullende controles beschikbaar:

• Schedule for device access: staat WebAdmin-aanmeldingen alleen binnen het gekozen tijdschema toe. Dat past bij tijdelijke support of duidelijke bedrijfstijden. Voor een wachtdienst mag het tijdschema noodzakelijke noodinterventies niet onbedoeld blokkeren.
• Login restriction for device access: staat de WebAdmin-aanmelding alleen toe vanaf geselecteerde IPv4-adressen of een IPv4-bereik. Kies voor een beheer-jumphost Selected nodes, voer het voorbeeldadres 10.20.30.25 in nadat het voor de eigen omgeving is vervangen en klik voor elk IPv4-adres op de plusknop (+). Controleer of de resulterende lijst overeenkomt met de bedoelde bronnen. Voer bij Node range in plaats daarvan het begin- en eindadres van het bedoelde IPv4-bereik in. Sla de gebruiker daarna op zoals hieronder beschreven; alleen typen voegt nog geen vermelding aan de lijst toe.

Het adres 10.20.30.25 is een voorbeeld uit een privénetwerk. Vervang het door het vaste adres van de eigen jumphost of beheerwerkplek. Bij wisselende clientadressen is een beheer-VPN of een afzonderlijk beheernetwerk meestal netter dan een groot IP-bereik.

Access Time voor normale gebruikers en groepen regelt de internettoegang; voor WebAdmin is Schedule for device access onder Administrator advanced settings van belang. Dit zijn niet dezelfde instellingen.

Klik na het invullen van de gebruikersvelden en Administrator advanced settings op Save voordat Authentication > Users wordt verlaten. Controleer of de gebruiker in de lijst verschijnt en open de vermelding opnieuw. User type moet Administrator zijn; Profile, Schedule for device access en Login restriction for device access, inclusief de toegevoegde IPv4-adressen, moeten overeenkomen met de bedoelde waarden. Ga pas daarna naar Services of MFA. Houd de bestaande beheersessie en het onafhankelijke herstelpad beschikbaar voor de volgende tests.

Lokale authenticatie behouden

Onder Authentication > Services > Administrator authentication methods moet de lokale database voor persoonlijke lokale beheerders geselecteerd zijn. De standaard-superbeheerder admin valt buiten deze methodenlijst, maar nieuw aangemaakte lokale beheerders niet.

Verwijder de lokale methode niet voordat het nieuwe account in een afzonderlijke browser succesvol is getest. Bij externe authenticatieservers bepaalt de volgorde waarheen een loginpoging eerst wordt gestuurd. Wijzigingen aan deze volgorde horen daarom in hetzelfde acceptatie- en rollbackplan als het account zelf.

XML API: neem geen tegenstrijdige moduswaarden over

Voor automatisering noemt de Sophos XML API-documentatie voor SFOS 22 en 23 de paden AdminAuthentication/AuthenticationMethods en AdminAuthentication/AuthenticationServerList/AuthenticationServer. Het voorbeeld toont SameAsFirewall/Custom voor het eerste pad en ServerName voor de server; dit is geen geverifieerde uitvoerbare modusselectie.

De parametertabel spreekt het voorbeeld tegen: voor AuthenticationMethods staat deze alleen het token toe dat letterlijk als ''on'' is geschreven. Ook lijken de beschrijvingen verwisseld: AuthenticationServer beschrijft het overnemen van de authenticatiemethode van de firewall, terwijl AuthenticationMethods de server beschrijft die bij het aanmelden wordt gebruikt. Hieruit kan noch een bevestigde selector noch een koppeling van on aan Custom worden afgeleid.

Totdat Sophos de waarden voor de specifieke doelbuild officieel heeft verduidelijkt, wordt daarom geen uitvoerbaar recept voor modusselectie gegeven. Behoud de lokale herstelmethode en de gedocumenteerde servervolgorde; een latere goedgekeurde wijziging hoort in het bestaande acceptatie- en rollbackplan.

Aanmelding met MFA beveiligen en bereikbaarheid beperken

Voor interactieve beheerders hoort MFA actief te zijn. Persoonlijke beheerders worden onder Authentication > Multi-factor authentication opgenomen voor Web admin console. Voor de standaardgebruiker admin geldt een afzonderlijke schakelaar onder Administration > Device access > MFA for default admin. MFA voor Sophos Firewall WebAdmin activeren beschrijft pilotgroep, tokenregistratie, Login Security en recovery. Test MFA eerst met één nieuwe beheerder, niet tegelijk met alle accounts.

WebAdmin blijft daarnaast beperkt tot beheernetwerken, VPN of nauw gedefinieerde bronnen. Een actieve Login restriction for device access maakt een brede WAN-vrijgave niet veilig. Omgekeerd vervangt een Local Service ACL het persoonlijke account en het bijbehorende rechtenprofiel niet.

Ook SSH wordt niet vrijgegeven door een succesvolle WebAdmin-test. SFOS accepteert voor directe SSH-login alleen de gebruikersnaam admin; een persoonlijke lokale WebAdmin-beheerder wordt daarom niet als SSH-account getest. SSH vereist daarnaast een afzonderlijke Device Access-beslissing. Het beheer van de public key van de standaardbeheerder en veilige SSH-toegang worden apart behandeld in Via SSH verbinding maken met Sophos Firewall.

Onder Administration > Admin and user settings staan twee afzonderlijke onderdelen: Administrator password complexity settings voor beheerders en User password complexity settings voor gebruikers. Schakel Enable password complexity check in elk onderdeel afzonderlijk in en stel de gewenste complexiteit in. De instelling voor beheerders vervangt die voor gebruikers niet. Kies de waarden volgens het eigen wachtwoordbeleid; hier wordt geen vaste minimumlengte of vast aantal tekens als productvereiste genoemd. Documenteer vóór een wijziging beide instellingen en hun eerdere waarden. Open de pagina na het opslaan opnieuw en controleer beide onderdelen afzonderlijk, terwijl de geteste hersteltoegang beschikbaar blijft.

Onder Administration > Admin and user settings vullen Administrator password complexity, Session Timeout en Block login de accountinstellingen aan. Deze waarden gelden voor het hele systeem en worden daarom niet agressief voor één account aangescherpt. Vooral Block login kan na mislukte pogingen het bron-IP-adres voor alle logindiensten blokkeren; vóór de test is een tweede beheerbron of consoletoegang nodig.

Noteer vóór een wijziging van Block login exact de status van het selectievakje, het aantal en tijdvenster van mislukte pogingen en de blokkeerduur. Zodra de drempel is bereikt, wordt het bron-IP geblokkeerd voor WebAdmin, CLI, VPN Portal en User Portal. Eén mislukte poging onder de drempel test deze blokkering niet; Sophos vermeldt ook dat een mislukte CAPTCHA niet als mislukte aanmeldpoging telt. Controleer in productie daarom eerst alleen of de waarden zijn opgeslagen en geldige aanmeldingen vanaf beide beheerbronnen blijven werken. Als een echte lockouttest nodig is, voer die dan in een onderhoudsvenster uit vanaf een geïsoleerde testbron totdat de drempel is bereikt. Controleer vervolgens de verwachte blokkering, wacht de gedocumenteerde blokkeerduur af of gebruik het onafhankelijke herstelpad en bevestig daarna een geldige aanmelding. Herstel bij onverwacht gedrag vanuit de open herstelsessie exact de eerdere waarden.

De optie Log out admin session after beëindigt inactieve WebAdmin-sessies standaard na 10 minuten. Als de optie wordt uitgeschakeld, blijft de sessie niet onbeperkt open: SFOS meldt deze na 30 minuten alsnog automatisch af. Uitschakelen is daarom geen methode voor permanente beheersessies; controleer het werkelijke gedrag met een testsessie.

Rechten en login veilig testen

Laat vóór de test het bestaande beheervenster en een onafhankelijke herstelmogelijkheid beschikbaar. Meerdere opzettelijke mislukte aanmeldingen zijn ongeschikt, omdat Block login het gedeelde bron-IP-adres tijdelijk voor andere logindiensten kan blokkeren.

1. Open een privébrowservenster en roep WebAdmin via de bedoelde FQDN vanuit het toegestane beheernetwerk op.
2. Log in met het nieuwe account en MFA.
3. Controleer of alle benodigde menu’s zichtbaar zijn en de bedoelde informatie kan worden gelezen.
4. Voer, als het profiel schrijfrechten bevat, een ongevaarlijke en vooraf goedgekeurde testwijziging uit met directe rollback.
5. Test de twee beperkingen afzonderlijk:
   • Bij None mag de betreffende configuratie niet zichtbaar of leesbaar zijn. Alleen een geweigerde wijziging is onvoldoende bewijs.
   • Bij Read-only moet de bedoelde configuratie leesbaar blijven, maar een verboden wijziging mag niet worden opgeslagen. Gebruik alleen een ongevaarlijke, vooraf goedgekeurde testactie met een voorbereide rollback.
   • Als het account al voor API-toegang wordt gebruikt, controleer dan de bedoelde API-leestoegang en geweigerde toegang afzonderlijk onder de bestaande beveiligingsmaatregelen voor bronnen, rechten en secrets. Schakel API-toegang niet uitsluitend in om een interactief WebAdmin-account te testen.
6. Test een gecontroleerde login vanaf een niet-toegestane bron maximaal één keer. Analyseer bij een onduidelijk resultaat eerst instellingen en logs en veroorzaak geen verdere mislukte pogingen.
7. Controleer de testwijziging en de gebruikte beheerder in de Configuration Audit Trail. Niet elk object levert daar evenveel details; controleer de technische werking daarnaast in de betrokken functie.
8. Log uit, log opnieuw in en migreer pas daarna het volgende account.

Controleer in een HA-cluster na een geplande failover bovendien een nieuwe aanmelding op de node die nu actief is. Een bestaande WebAdmin-sessie of de naadloze voortzetting daarvan is geen betrouwbaar succescriterium.

Logs en rapporten worden niet tussen HA-apparaten gesynchroniseerd: controleer bij diagnose Log viewer > System en de relevante authenticatiegebeurtenissen op beide apparaten. Sinds SFOS 22.0 MR1 wordt bij wijzigingen aan één firewall via Sophos Fusion (voorheen Sophos Central) de Sophos Fusion-gebruikersidentiteit vastgelegd en evalueren Entra ID SSO-sessies Conditional Access-beleid opnieuw. Controleer deze toewijzing na een update met een onschuldige testwijziging. Controleer vóór elke uitrol de doelbuild, het ondersteunde upgradepad en versiespecifieke blokkades in de SFOS 22-upgradecontrole en keur deze in de change goed; de release- en known-issuecontrole daarin bepaalt de uitrolbeslissing.

Een zichtbaar menu bewijst nog geen werkende schrijfrechten. Een verborgen menu bewijst niet dat andere toegewezen functies correct werken. Een positieve test, negatieve test en auditkoppeling horen daarom bij elkaar.

Accounts controleren en veilig verwijderen

Controleer beheerstoegangen regelmatig op eigenaar, taak, profiel, MFA, loginbron en laatste gebruik. Tijdelijke supportaccounts krijgen daarnaast een gedocumenteerde einddatum. Voor een tijdelijk Avanet-geval blijft de aparte procedure Avanet-supporttoegang op Sophos Firewall instellen bepalend.

Onderscheid dit account van fabrikanttoegang onder Diagnostics > Support access. Die genereert voor de gekozen duur een Access ID waarmee Sophos Support WebAdmin en de shell kan bereiken zonder beheerdersgegevens te ontvangen. De firewall maakt hiervoor via TCP 22 verbinding met *.apu.sophos.com; bovenliggende systemen moeten dit toestaan. Deel de Access ID alleen binnen de actieve supportcase, bewaak de status tijdens het werk en schakel Support access direct daarna uit, ook als de gekozen duur nog niet is verstreken.

Bij offboarding is een gecontroleerd proces veiliger dan het account direct te verwijderen:

1. Controleer of het account wordt gebruikt in API-scripts, wachtwoordkluizen, documentatie of supportprocessen.
2. Zet de status onder Authentication > Users op inactief.
3. Controleer in een privébrowser dat een nieuwe aanmelding niet meer mogelijk is.
4. Controleer actieve WebAdmin-sessies en recente wijzigingen afzonderlijk. Uitschakelen mag niet zonder controle als bewijs gelden dat elke bestaande sessie direct is beëindigd.
5. Verwijder of roteer MFA-tokens, secrets en externe toewijzingen die bij het account horen.
6. Verwijder de gebruiker na de afgesproken observatieperiode wanneer er geen afhankelijkheid meer bestaat.
7. Verwijder een niet meer benodigd aangepast profiel pas wanneer het aan geen enkele beheerder meer is toegewezen.

De standaardbeheerder valt buiten dit normale offboardingproces. Wanneer het wachtwoord of de MFA-toegang verloren is gegaan, helpt Het Sophos Firewall-adminwachtwoord herstellen bij de voorbereiding van de herstelprocedure.

Veelvoorkomende problemen afbakenen

Account bestaat, maar WebAdmin-aanmelding mislukt

Controleer deze punten in deze volgorde:

• User type staat daadwerkelijk op Administrator.
• De gebruiker is actief en het wachtwoord klopt.
• Local is geselecteerd onder Administrator authentication methods.
• Schedule for device access staat het huidige tijdstip toe.
• Login restriction for device access bevat het werkelijke IPv4-bronadres.
• MFA-token, systeemtijd en registratie zijn correct.
• Block login heeft het bron-IP-adres na mislukte pogingen niet geblokkeerd.
• Device Access of een Local Service ACL staat HTTPS vanaf deze bron toe.

Als de loginpagina helemaal niet bereikbaar is, begint de analyse bij Device Access, routing en bronadres. Is de pagina bereikbaar maar wordt alleen dit account geweigerd, dan zijn gebruiker, profiel, authenticatiemethode, Schedule, Login Restriction en MFA de waarschijnlijkste sporen.

Voor de tijdscorrelatie helpen het onderdeel Authentication in Log Viewer en access_server.log voor authenticatie en autorisatie. syslog.log vult dit aan met systeemgebeurtenissen en door beheerders veroorzaakte gebeurtenissen. Wijzigingen aan ondersteunde objecten worden afzonderlijk in configuration-audit.log gecontroleerd.

Account ziet te veel of te weinig

Controleer het toegewezen profiel en de uitgeklapte submenu’s. Read-only en Read-write kunnen binnen één hoofdmenu verschillend zijn ingesteld. Test daarna opnieuw met een nieuwe aanmelding en vertrouw niet alleen op de profielnaam.

Bij Managed by Central komt de rol uit Sophos Fusion en wordt deze niet bij de lokale gebruiker gewijzigd. Bij Entra SSO bepaalt de rol- of groepsmapping van de Entra-server welk lokaal Device Access-profiel wordt gebruikt.

WebAdmin werkt, maar API of SSH niet

Het Device Access-profiel geldt ook voor API-rechten, maar de API vereist daarnaast geactiveerde API-toegang en een toegestane bron. SSH is een afzonderlijke lokale dienst en geen geschikte succescontrole voor een beperkt WebAdmin-profiel. Een account krijgt niet automatisch SSH-toegang omdat WebAdmin-aanmelding werkt.

NC-177609 is specifiek gedocumenteerd voor SFOS 22.0 GA Respin Build 411: na een upgrade kunnen API-configuratiewijzigingen van een gemigreerde gebruiker worden geweigerd wanneer MFA actief is en de aanvraag geen one-time token bevat. Als het symptoom exact overeenkomt, documenteer dan de build en de migratiestatus van het account. De gedocumenteerde workaround vereist dat automatisering een speciaal API-account met minimale rechten gebruikt waarop MFA is uitgeschakeld of dat expliciet van MFA is uitgesloten; MFA blijft actief voor interactieve beheerders. De aangewezen API-eigenaar moet deze uitzondering goedkeuren en documenteren, een accounteigenaar en beoordelingsdatum vastleggen, bron en API-rechten beperken, het geheim in een kluis bewaren en roteren, gebruik bewaken en de uitzondering verwijderen zodra deze niet meer nodig is. Valideer na de wijziging met een ongevaarlijke leesaanvraag en daarna met een goedgekeurde, gecontroleerde schrijfbewerking met rollback. Sophos Firewall XML API-toegang beveiligen en de aangewezen API-eigenaar beheren samen deze workflow; leid de status van een oplossing niet af uit een latere build.

Operationele checklist

• De standaardbeheerder en herstelprocedure zijn getest en worden niet gedeeld.
• Iedere persoon gebruikt een eigen account.
• Profielen zijn afgeleid uit taken en de uitgeklapte submenu’s zijn gecontroleerd.
• Volledige toegang is beperkt tot de kleinst mogelijke groep personen.
• MFA, Schedule en loginbron passen bij het gebruiksdoel.
• WebAdmin is alleen bereikbaar vanaf de voorziene beheerbronnen.
• Positieve en negatieve rechtentests zijn uitgevoerd.
• Wijzigingen zijn met een persoonlijk beheeraccount in de Audit Trail traceerbaar, voor zover ondersteund.
• De eerdere toestand en accountoverschrijdende rollback voor profiel-, authenticatie- en blokkeerwijzigingen zijn gedocumenteerd.
• In HA zijn een nieuwe aanmelding en de afzonderlijke logs op beide apparaten gecontroleerd.
• API- en supportaccounts hebben een eigen eigenaar en levenscyclus.
• Offboarding omvat status, sessies, MFA, secrets en afhankelijkheden.

FAQ