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

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 Central-beheerdersrollen. Een gebruiker die onder Authentication > Users als Managed by Central is gemarkeerd, wordt in Central beheerd en kan niet lokaal worden bewerkt.

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.

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

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. Voor een beheer-jumphost kan bijvoorbeeld 10.20.30.25 als Selected node worden gebruikt.

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.

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.

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

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. Open een onderdeel dat op None of Read-only staat. Het account mag daar geen verboden wijziging kunnen opslaan.
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.

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.

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

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.
• API- en supportaccounts hebben een eigen eigenaar en levenscyclus.
• Offboarding omvat status, sessies, MFA, secrets en afhankelijkheden.

FAQ