Sophos Firewall WAF beveiligen met MFA

Met Sophos Firewall WAF MFA kun je webapplicaties die via de Web Application Firewall worden gepubliceerd, extra beveiligen met Multi-Factor Authentication. Dit is vooral nuttig voor interne portalen, beheerdersinterfaces, klantgebieden of partnertoegang, die weliswaar via HTTPS bereikbaar moeten zijn, maar niet alleen door de applicatie zelf beschermd moeten worden.

WAF-MFA vervangt geen veilige applicatie, geen patchbeheer en geen goed toegangsbeheer. Het is een voorliggende beschermingslaag op de firewall. De firewall controleert eerst de aanmelding en de tweede factor voordat de toegang tot de beveiligde webserver wordt doorgestuurd.

De versie is belangrijk: geïntegreerde MFA voor WAF is een SFOS 22-functie. Op oudere firmwareversies moeten WAF-publicaties met andere architecturen worden gepland, bijvoorbeeld externe authenticatie, een dedicated reverse proxy, VPN of ZTNA.

Voor de basispublicatie van een webserver via WAF volg je eerst de handleiding Sophos Firewall WAF: Webserver veilig publiceren. Dit artikel richt zich op de voorliggende authenticatie en MFA.

Gebruik en planning

Wanneer WAF-MFA zinvol is

WAF-MFA is vooral krachtig wanneer een webapplicatie vanuit het internet bereikbaar moet zijn, maar niet openbaar voor alle bezoekers bedoeld is.

Typische gebruikssituaties:

• interne portalen met externe toegang
• beheerdersinterfaces van bedrijfsapplicaties
• partner- of klantenportalen met een beperkte gebruikersgroep
• legacy-webapplicaties zonder eigen sterke MFA
• applicaties waarbij extra toegangsbeveiliging voor de backend gewenst is

Voor openbare websites, winkels of informatiesites is WAF-MFA meestal niet geschikt, omdat elke bezoeker eerst een firewall-aanmelding zou zien. Bij complexe privéapplicaties kan ZTNA, SSE of een speciale reverse proxy zinvoller zijn dan WAF-MFA. Sophos WAF ondersteunt WebDAV niet; applicaties zoals Nextcloud zijn daarom geen ondersteunde WAF-publicaties. Plan daarvoor een andere architectuur met passende firewallregels en eigen toegangsbeveiliging; publiceren zonder WAF neemt de authenticatie en applicatiebeveiliging daarvan niet automatisch over.

WAF beschermt op Layer 7 onder meer tegen manipulatie van cookies, URL’s en formulieren. De webserver, Protection Policy en Authentication Policy worden via de WAF-regel gekoppeld; maximaal 60 WAF-regels zijn ondersteund. Beheer de WAF-service onder System services > Services. Een herstart beïnvloedt de gepubliceerde applicaties en is geen eerste stap bij een individuele aanmeldfout.

Wanneer WAF-MFA niet voldoende is

WAF-MFA is een voorliggende toegangslaag. Deze laag beantwoordt echter niet elke architectuurvraag. Vooral bij kritieke portalen moet je bewust beslissen of de applicatie überhaupt openbaar bereikbaar moet zijn.

• Applicatie is alleen bedoeld voor enkele interne gebruikers: VPN, ZTNA, vaste bronnetwerken of een niet-openbare publicatie controleren.
• Applicatie bevat bijzonder gevoelige gegevens: Backend-rechten, logging, audit trail en applicatiesessies aanvullend controleren.
• Applicatie heeft WebDAV nodig: Kies een andere architectuur; een pilot maakt ontbrekende WAF-ondersteuning niet tot een ondersteunde oplossing. Controleer voor andere speciale protocollen de compatibiliteit afzonderlijk vóór de uitrol.
• Externe partners gebruiken de toegang zelden: Token-uitrol, supportproces en fallback bijzonder duidelijk documenteren.
• Backend heeft eigen aanmelding en rollen: WAF-MFA alleen als extra laag beschouwen, niet als vervanging voor backend-rollen.

Als een portal wereldwijd bereikbaar blijft, mag MFA niet de enige maatregel zijn. Vaste bronnetwerken, landbeperkingen, Threat Feeds, beschermingsprofielen en goede backend-patches verminderen het risico verder.

Vereisten

Voor de installatie moeten deze punten duidelijk zijn:

• De webapplicatie is al gepland of gepubliceerd via een WAF-regel.
• De firewall draait op SFOS 22 of nieuwer.
• Gebruikers of groepen zijn aanwezig op de firewall, bijvoorbeeld lokaal, via AD, LDAP of RADIUS.
• De gebruikers kunnen hun OTP-token instellen.
• De systeemtijd van de firewall is correct en NTP werkt.
• Voor de WAF-regel wordt HTTPS met een passend certificaat gebruikt.
• Het is duidelijk of de backend-webserver eigen authenticatie nodig heeft of dat de firewall de aanmelding volledig moet overnemen.
• Een testgebruiker en een administratieve fallback-toegang zijn aanwezig.

⚠️ MFA voor WAF moet eerst met een pilotgroep worden getest. Een verkeerde combinatie van MFA-groep, WAF-authenticatiebeleid en backend-authenticatie kan legitieme gebruikers buitensluiten of een applicatie schijnbaar “kapot” maken.

Pilot, fallback en verantwoordelijkheden plannen

WAF-MFA werkt voor de eigenlijke applicatie. Daarom moet je de uitrol niet behandelen als een normale firewall-regel, maar als een wijziging in het aanmeldproces van de applicatie. Gebruikers zien eerst de aanmelding van de Sophos Firewall en pas daarna, afhankelijk van de backend, de eigenlijke applicatie.

Voor het inschakelen moeten deze punten vaststaan:

• Welke gebruikersgroep test eerst?
• Wie kan de toegang weer uitschakelen als de aanmelding mislukt?
• Is er een tweede admin-toegang die niet afhankelijk is van dezelfde WAF-regel, hetzelfde portal of dezelfde testgebruiker?
• Welke applicatiedelen moeten na succesvolle login worden getest?
• Wie controleert reverseproxy.log, Log Viewer en backend-logs bij fouten?
• Hoe worden gebruikers geïnformeerd over token, sessieverloop en mogelijke tweede backend-aanmelding?

Een veelgemaakte planningsfout is het vermengen van firewall-authenticatie en backend-authenticatie. De WAF kan gebruikers voor de backend controleren. Dat betekent echter niet automatisch dat de applicatie zelf geen eigen aanmelding, rollencontrole of sessiebeheer meer nodig heeft. Vooral bij beheerdersportalen en klantgegevens moeten de backendrechten bewust behouden blijven.

Als de gepubliceerde dienst alleen voor enkele personen bedoeld is, moet je naast MFA ook de bronnen beperken. Voor de basispublicatie en bronbeperking past Sophos Firewall WAF: Webserver veilig publiceren. Als gebruikersrechten of Remote-Access-MFA algemeen gepland worden, helpt MFA voor Sophos Firewall WebAdmin, VPN Portal en Remote Access activeren.

Een rollback moet voor het inschakelen voorbereid zijn. Praktisch betekent dit: oude werkende toegangsmanier documenteren, WAF-regel en authenticatiebeleid benoemen, verantwoordelijke persoon vaststellen en een tijdstip kiezen waarop gebruikersfeedback en logcontrole mogelijk zijn. Als de applicatie bedrijfskritisch is, moet WAF-MFA eerst voor een testdomein, een pilotgroep of een onderhoudsvenster worden geactiveerd.

Configuratie

Bouwstenen van de configuratie

Voor WAF-MFA moeten meerdere instellingen op elkaar aansluiten:

• MFA-instelling: Bepaalt welke gebruikers MFA gebruiken en of Web application firewall wordt beschermd.
• WAF Authentication Policy: Bepaalt loginmodus, gebruikers/groepen, template en sessiegedrag.
• WAF rule: Verbindt de gepubliceerde webserver met de Authentication Policy.
• Backend authentication forwarding: Bepaalt of de firewall inloggegevens aan de webserver doorgeeft.
• Token-uitrol: Zorgt ervoor dat gebruikers hun OTP-code daadwerkelijk kunnen genereren.

Het belangrijkste verschil: MFA wordt niet alleen globaal geactiveerd. De betreffende WAF-regel moet ook een passend authenticatiebeleid gebruiken.

MFA voor WAF activeren

Het menupad is:

Authentication > Multi-factor authentication

Stappen:

1. Onder One-time password (OTP) kies je ofwel All users of Specific users and groups.
2. Voeg bij Specific users and groups de betreffende gebruikers of groepen toe.
3. Activeer Generate OTP token with next sign-in als gebruikers hun token zelf bij de volgende login moeten instellen.
4. Onder Require MFA for activeer je de optie Web application firewall.
5. Stel OTP hash algorithm en indien nodig OTP timestep settings bewust in. De standaardwaarden zijn 30 seconden voor Default token timestep, 2 voor Maximum verification code offset en 10 voor Maximum initial verification code offset.
6. Configuratie opslaan.

Wanneer Generate OTP token with next sign-in actief is, wordt User portal automatisch geselecteerd. Gebruikers melden zich eerst aan bij VPN portal of User portal en scannen daar de QR-code. De standaardbeheerder kan in plaats daarvan de WebAdmin-console gebruiken wanneer MFA voor diens WebAdmin-aanmelding wordt afgedwongen. Deze onboardingstap moet werken vóór de eerste WAF-toegang. De algemene MFA-planning is beschreven in MFA voor Sophos Firewall WebAdmin, VPN Portal en Remote Access activeren.

De twee offsetwaarden zijn niet de normale oplossing voor een onjuiste klok. Bij een timestep van 30 seconden accepteert een Maximum verification code offset van 2 bijvoorbeeld een nog ongebruikte code uit de voorgaande 60 seconden. Een groter venster maakt aanmelden toleranter, maar verlengt ook de geldigheid van oudere codes. Corrigeer eerst NTP en de klok van de telefoon en wijzig de offset alleen om een gedocumenteerde reden.

Token-uitrol en gebruikerscommunicatie voorbereiden

WAF-MFA faalt in de praktijk vaak niet door de eigenlijke WAF-regel, maar door de token-uitrol. Gebruikers moeten weten waar de QR-code verschijnt, welke app gebruikt moet worden, hoe lang een sessie geldig is en of er na de firewall-aanmelding nog een tweede aanmelding bij de applicatie volgt.

Voordat je de WAF-regel in productie activeert, moet je vaststellen:

• Token-creatie: Waar stelt de gebruiker de OTP-token in?
• Portal-toegang: Is User Portal of een ander bedoeld pad naar de QR-code bereikbaar voor de betreffende gebruikers?
• Authenticator-app: Welke app is goedgekeurd en met het gekozen algoritme getest?
• Fallback: Wie kan een verloren of defect token resetten?
• Noodcodes: Is duidelijk of en hoe extra eenmalige passcodes in supportgevallen mogen worden uitgegeven?
• Supportcase: Welke informatie heeft de helpdesk nodig bij loginproblemen?
• Communicatie: Welke loginvolgorde zien gebruikers vanaf de go-live?

Als Generate OTP token with next sign-in wordt gebruikt, moet de eerste login gecontroleerd worden getest. Hierbij is het belangrijk of gebruikers de QR-code in het verwachte portal zien en of ze daarna met wachtwoord plus OTP succesvol toegang krijgen tot de WAF-applicatie. De portalen zelf zijn beschreven in Sophos Firewall Portalen: WebAdmin, User Portal en VPN Portal indelen.

Voor veel firewallservices wordt de OTP-code verwerkt als combinatie van wachtwoord en passcode. Gebruikerscommunicatie en het helpdesk-runbook moeten daarom duidelijk aangeven welk invoerscherm gebruikers werkelijk zien en of wachtwoord en OTP gescheiden of gecombineerd moeten worden ingevoerd. Bij WAF-MFA met Form-gebaseerde login is dit extra belangrijk, omdat een tweede backend-login anders snel als “MFA defect” wordt gezien.

Sophos Authenticator moet niet meer als nieuwe standaardapp worden gepland, omdat de app sinds 2022 End of Life is. In de praktijk moeten Intercept X for Mobile, Google Authenticator, Microsoft Authenticator, Duo Mobile, Okta Verify of een intern goedgekeurde app worden getest. Niet alleen de naam van de app telt, maar of deze het gekozen algoritme, de timestep en de QR-code van de firewall correct ondersteunt.

Ook het mobiele besturingssysteem telt bij de uitrol. QR-scanning in de Okta-app werkt voor deze tokens niet op iOS of Android. Op iOS geldt dezelfde beperking ook voor Google Authenticator, Duo en Microsoft Authenticator. In die gevallen moet de gebruiker het Base32 secret handmatig invoeren. Neem dit op in de gebruikershandleiding; een correcte firewallconfiguratie kan anders defect lijken wanneer het runbook alleen QR-scanning beschrijft.

Voor helpdesk en operatie moet minimaal gedocumenteerd zijn:

• gepubliceerde hostnaam van de WAF-applicatie
• betreffende gebruikersgroep
• gebruikt authenticatiebeleid
• gebruikte OTP-algoritme
• toegestane authenticator-app
• procedure voor token-reset
• verwachte melding bij verkeerd wachtwoord of verkeerde OTP
• loglocaties voor eerste controle: Log Viewer en reverseproxy.log

Vooral bij externe partners of zelden gebruikte portalen moet de eerste login niet pas tijdens een noodsituatie in productie plaatsvinden. Een korte pilot met normale gebruikers onthult vaak problemen die beheerders in hun eigen test niet zien: afwijkende authenticator-app, ontbrekende portaltoegang, onduidelijke tweede backend-aanmelding of sessietime-outs die voor de applicatie te kort zijn.

WAF Authentication Policy aanmaken

Het menupad is:

Web server > Authentication policies

Voor WAF-MFA moet de clientmodus op Form worden ingesteld. Formuliergebaseerde authenticatie maakt sessiecookies aan en biedt een aparte logout; de firewall beheert de aanmelding via het formulier en de sessies.

Stappen:

1. Open Add.
2. Geef een duidelijke naam, bijvoorbeeld WAF_MFA_Portal_Users.
3. Kies bij Mode de optie Form.
4. Kies een passend Authentication template.
5. Selecteer de gebruikers of groepen die toegang krijgen tot deze WAF-publicatie.
6. Kies bewust de Authentication forwarding mode.
7. Stel Session timeout en Session lifetime in passend bij de applicatie.
8. Opslaan.

De SFOS 23 XML-API-documentatie beschrijft uitsluitend voor de clientmodus Form de optionele parameter RedirectToRequestedURL met de waarden Enable en Disable. Met Enable wordt de gebruiker na succesvolle authenticatie teruggeleid naar de oorspronkelijk opgevraagde URL. De documentatie vermeldt hiervoor geen standaardwaarde; de naam van de API-parameter is geen bevestigde veldnaam in de GUI. De omleiding vervangt noch authenticatie noch controle van toegangsrechten.

Authentication forwarding correct kiezen

De Authentication forwarding mode bepaalt wat er tussen firewall en backend gebeurt.

• None: Geen backend-authenticatie door de firewall; de authenticatie aan de voorkant blijft actief. Voor het verwijderen van een Basic-header die de client meestuurt is daarnaast Remove basic header relevant.
• Basic: De firewall geeft gebruikersnaam en wachtwoord via HTTP Basic Authentication door aan de backend.

Als de applicatie geen eigen authenticatie nodig heeft of de voorliggende firewall-aanmelding voldoende moet zijn, is None vaak schoner. Als de backend zelf HTTP Basic Authentication verwacht, moet de forwarding-modus bij de applicatie passen.

Bij None moet men ook controleren of Remove basic header moet worden ingesteld. Daarmee wordt voorkomen dat een door de client verzonden Basic Authentication-header onnodig naar de webserver wordt doorgestuurd. Dit is vooral belangrijk wanneer oude clients, opgeslagen browsergegevens of eerdere publicaties nog Basic-headers genereren.

⚠️ Basic Authentication moet alleen met HTTPS worden gebruikt. Bovendien moet duidelijk zijn of de backend echt de door de firewall doorgegeven inloggegevens moet verwerken.

De clientmodus Basic maakt geen sessiecookies aan en biedt geen aparte logout. Sophos vereist daarom de clientmodus Form voor WAF-MFA. Onafhankelijk daarvan moet de Authentication forwarding mode bij de backend passen.

In de clientmodus Basic is Basic prompt alleen de tekst in het browservenster. In de forwarding-modus Basic voegt Username affix de ingestelde prefix of suffix toe wanneer alleen een gebruikersnaam wordt ingevoerd. Controleer volledig gekwalificeerde aanmeldnamen apart om dubbele domeinen of suffixen bij de backend te voorkomen. HTTP Basic volgt RFC 7617; de codering versleutelt de inloggegevens niet.

Authentication Policy in de WAF-regel gebruiken

De WAF-regel wordt bewerkt onder Rules and policies > Firewall rules. De actie is Protect with web server protection. De volgende checklist en de koppeling via Protected servers hebben betrekking op SFOS 22; voor SFOS 23 zijn daarnaast de hierna beschreven expliciete controles per pad onder Traffic routing vereist.

Bij het opslaan van een WAF-regel worden alle regels voor webserverbeveiliging opnieuw gestart. Bestaande verbindingen via die regels gaan verloren en moeten opnieuw worden opgebouwd. Stem de wijziging af met de beheerders van alle betrokken applicaties tijdens een geschikt wijzigingsvenster, bewaar de vorige instellingen en controleer daarna de bereikbaarheid, aanmelding met OTP en backendtoegang. Dit effect en het herstelpad zijn hier niet op een appliance getest.

In de betreffende WAF-regel moeten deze punten op elkaar aansluiten:

• Juiste Hosted address en luisterpoort.
• Juiste domein en passend HTTPS-certificaat.
• Juiste beveiligde webserver.
• Gewenst Authentication policy geselecteerd.
• Gebruikersgroep in het authenticatiebeleid past bij de MFA-groep.
• Toegangsbeperkingen via Allowed client networks, landen of Threat Feeds zijn bewust ingesteld.

Voor openbare of sterk blootgestelde portalen mag MFA niet de enige beveiligingsmaatregel zijn. Land- en bronbeperking is beschreven in Sophos Firewall: Landen en kwaadaardige IP’s blokkeren. Voor dynamische blokkeerlijsten past Sophos Firewall Threat Feeds.

SFOS 23: MFA aan elk portaalpad toewijzen

De regelactie Protect with web server protection alleen is niet voldoende. Voor elk te beschermen portaalpad op elke gepubliceerde hostnaam en in elke bijbehorende WAF-regel moet de padconfiguratie kloppen; de bestaande MFA-stappen en sessielimieten blijven ongewijzigd.

1. Bewerk of voeg onder Traffic routing elk beschermd portaalpad toe en stel Action > Protect in. Wijs de bedoelde backend-objecten uit Web server > Web servers toe.
2. Selecteer in het veld Authentication het bedoelde authenticatiebeleid. Dit moet de clientmodus Form gebruiken en de bedoelde gebruikersgroep bevatten; de groepstoewijzing moet aansluiten op de MFA-configuratie. Controleer Allowed client networks en verdere bron- en toegangsbeperkingen, inclusief bewust gekozen netwerk- en landblokkeringen, per pad.
3. Als alleen bepaalde portaalpaden zijn toegestaan, behoud / dan met Block als opvangroute. Als Protect voor / is bedoeld om de volledige applicatie te publiceren, wijs daar dan dezelfde bedoelde authenticatie en passende toegangsbeperkingen toe. Controleer alternatieve paden en hostnamen expliciet op gelijkwaardige bescherming of bedoelde blokkering.
4. Behoud de bestaande tests voor succesvolle login met wachtwoord en OTP, backend-functie, logout, sessieverloop en opnieuw inloggen. Een onjuiste OTP en gebruikers buiten de toegestane groep moeten worden geweigerd; alternatieve paden of hostnamen mogen geen onbeschermde toegang bieden. Correleer het clientresultaat met WAF-, authenticatie- en backend-logs.

Documentatiegrens bij Passthrough: Het regeloverzicht beschrijft authenticatie als een functie van Protect; tegelijkertijd biedt de instellingentabel voor de routingactie Passthrough een veld Authentication. Deze spanning bewijst noch MFA-afdwinging noch MFA-omzeiling bij Passthrough. Baseer vereiste WAF-MFA daarom op expliciet geconfigureerde Protect-paden, niet op onbevestigd Passthrough-gedrag. Stem noodzakelijke WebSocket-tunnels afzonderlijk af met de verantwoordelijken voor WAF-routing en authenticatie.

Basic with passthrough duidt een authenticatiemodus aan voor het doorgeven van inloggegevens; Passthrough onder Traffic routing is daarentegen een routingactie voor de afhandeling van verkeer. De vergelijkbare naam impliceert geen MFA-eigenschap. Voor de basispublicatie moeten de verantwoordelijken de SFOS 23-padconfiguratie samen met de MFA-toewijzing controleren: het ongewijzigde Sophos-tutorial over bescherming tegen aanvallen is geen volledige SFOS 23-routinghandleiding, en WAF-regels ondersteunen alleen IPv4.

Een Authentication Template veilig aanpassen

Maak een eigen formulier onder Web server > Authentication templates > Add. In de HTML moeten het formulier met action="<?login_path?>" en method="POST" en de velden httpd_username en httpd_password behouden blijven. Voor MFA moet ook otp_field aanwezig zijn. Als deze elementen worden verwijderd of hernoemd, kan het aanmelden mislukken terwijl de pagina er correct uitziet.

Voor afbeeldingen, stijlen en scripts biedt SFOS onder meer de placeholders <?assets_path?>, <?admin_contact?>, <?company_logo?> en <?company_text?>. Uploadbare assets zijn beperkt tot .jpg, .jpeg, .png, .ico, .css en .js. Test het template eerst met een pilotgebruiker; productiegegevens, externe trackers en niet-gecontroleerd JavaScript horen niet op de aanmeldpagina.

Voer na Add een naam in, selecteer het HTML-bestand en de bijbehorende assets, kies Upload en daarna Save. Selecteer het opgeslagen template in het Form-authenticatiebeleid. Dit minimale formulier behoudt de vereiste technische namen; het is een documentair voorbeeld, geen op een appliance getest template:

<form action="<?login_path?>" method="POST">
  <label>Username <input name="httpd_username" type="text"></label>
  <label>Password <input name="httpd_password" type="password"></label>
  <?otp_field?><label>OTP <input name="otp_field" type="password"></label><?otp_field?>
  <button type="submit">Login</button>
</form>

Tegenstrijdigheden in de templatedocumentatie: Een kort wachtwoordvoorbeeld gebruikt type="text", terwijl de velddefinitie en het volledige voorbeeld type="password" tonen. Houd het wachtwoord daarom gemaskeerd. Een opmerking noemt bovendien alleen <?login_path?> als vervangen variabele, maar de optionele tabel beschrijft ook vervanging van <?assets_path?> en <?admin_contact?>. Dit bevestigt niet het gedrag van iedere firmwareversie. Controleer vóór de uitrol het weergegeven formulier, assetpaden, OTP-invoer en aanmelden met een pilotgroep; vervang een werkend template niet zonder validatie.

<?assets_path?> verwijst naar het pad van de geüploade ondersteunende bestanden, bijvoorbeeld in <link rel="stylesheet" href="<?assets_path?>/stylesheet.css">. Zo kunnen afbeeldingen en CSS buiten het formulier blijven. De veldbeschrijving koppelt <?admin_contact?> aan Administration > Notification settings > Email settings > Send notifications to email address; controleer of dat adres openbaar mag worden weergegeven. Vervang <?company_logo?> door het eigen logopad en <?company_text?> door de gewenste zichtbare tekst, zonder automatische vervanging aan te nemen. Bij zichtbare placeholders of aanmeldfouten keer je terug naar het opgeslagen werkende template en onderzoek je de oorzaak met support in plaats van MFA uit te schakelen.

Sessies en time-out plannen

Bij formuliergebaseerde WAF-authenticatie werkt de firewall met sessies. In het authenticatiebeleid stel je in:

• Session timeout: na welke inactiviteit gebruikers zich opnieuw moeten aanmelden
• Session lifetime: hoe lang een aanmelding maximaal geldig blijft

Daarnaast is er onder Web server > General settings het maximale aantal gelijktijdige sessies voor formuliergebaseerde reverse-proxy-authenticatie. De standaardwaarde is 25,000, het ondersteunde bereik is 100 tot 100,000.

Maximum sessions wordt gedeeld door alle WAF-regels met Form-authenticatie. Bij het bereiken van de limiet sluit de firewall oude of verlopen sessies om nieuwe toe te laten. Herhaalde aanmeldverzoeken kunnen dus ook door de globale capaciteit ontstaan, niet alleen door de time-out van één beleid.

Korte sessies verhogen de veiligheid, maar kunnen gebruikers storen. Zeer lange sessies zijn comfortabeler, maar verhogen het risico dat een gestolen of gedeelde browsertoegang langer bruikbaar blijft. Voor beheerdersportalen moet je eerder conservatief beginnen en het gedrag in de praktijk observeren.

Als zeer veel gebruikers of meerdere WAF-portalen dezelfde firewall gebruiken, moet de globale sessielimiet niet pas bij foutmeldingen worden gecontroleerd. Form-gebaseerde WAF-authenticatie is een gedeelde reverse-proxy-bedrijfsparameter en hoort daarom in capaciteits- en monitoringoverwegingen.

Globale WAF-instellingen veilig beheren

Web server > General settings geldt voor alle beschermde webservers, niet alleen voor het MFA-portaal. Sla vóór wijzigingen de waarden op, breng betrokken applicaties en clientcompatibiliteit in kaart en plan een onderhoudsvenster en herstelroute. Deze aanwijzingen zijn documentair gecontroleerd; de effecten en rollback zijn niet op een appliance getest.

Slow HTTP protection beperkt het wachten op onvolledige requestheaders. Bij een Slow HTTP-DoS houden langzaam binnenkomende delen verbindingen bezet totdat de capaciteit op is:

• Soft limit: minimale tijd om een requestheader te ontvangen.
• Hard limit: maximale tijd om de header te ontvangen.
• Extension rate: hoeveelheid gegevens in bytes; iedere overschrijding verlengt de soft-time-out met één seconde.
• Skipped networks/hosts: gerichte uitzonderingen. Gebruik alleen IP-hosttypen IP en Network, geen IP ranges of IP lists. Brede uitzonderingen halen ook ongewenste clients uit de bescherming.

Controleer na aanpassingen normale en langzame legitieme clients en de overige WAF-applicaties. Neem geen willekeurige time-outs over als algemene oplossing voor aanmeldproblemen.

TLS version settings bepaalt de toegestane clientverbindingen. De gedocumenteerde profielen verschillen ook in hun ciphers:

• TLS v1 or later: zonder SSLv3; legacyprofiel, niet aanbevolen voor nieuwe portalen.
• TLS v1.1 or later: zonder SSLv3 en TLSv1; eveneens geen moderne uitrolstandaard.
• TLS v1.2 (wide compatibility): alleen TLSv1.2, inclusief niet-aanbevolen legacyciphers.
• TLS v1.2 (strict): alleen TLSv1.2 met aanbevolen ciphers.
• TLS v1.3: alleen TLSv1.3-ciphers.

Controleer eerst de clientondersteuning; bijvoorbeeld IE 8 of ouder en Windows XP kunnen niet met TLS 1.2 verbinden. Maak legacycompatibiliteit niet mogelijk door de beveiliging zonder onderscheid te verlagen. Test een strikt profiel eerst met de werkelijk benodigde clients en alle gepubliceerde applicaties.

Bij Custom TLS gebruiken Protocols, Cipher suite en TLS v1.3 cipher suite only OpenSSL-syntaxis. TLSv1.3-ciphers horen alleen in het aparte TLSv1.3-veld, niet in Cipher suite. Ongeldige protocollen of ciphers kunnen verhinderen dat Apache start en WAF verstoren. Experimenteer niet met Custom TLS in productie zonder gevalideerde instellingen; herstel bij uitval de opgeslagen waarden en controleer de servicestatus en HTTPS-toegang tot alle betrokken portalen.

SFOS 23 – Worker customization: De firewall berekent WAF-capaciteit op basis van CPU en RAM. De berekende waarden zijn voor de hardware geoptimaliseerd; meestal is wijzigen niet nodig. Hogere waarden kunnen WAF-prestaties en resourcegebruik verslechteren. Activeer Use custom worker profile alleen na zorgvuldige beoordeling van capaciteit en impact, niet als algemene aanmeldfix:

• Start servers: workerprocessen bij de start van de webserver.
• Server limit: maximaal aantal workerprocessen.
• Minimum spare threads: minimumaantal beschikbare vrije threads.
• Maximum spare threads: grens voor vrije threads waarboven overtollige threads worden verwijderd.
• Threads per child: maximaal aantal threads per workerproces.
• Asynchronous request worker factor: stuurt processchaling voor asynchrone verbindingen en requests.

Kopieer geen universele getallen van andere systemen. Sla de uitgangswaarden op, observeer representatieve belasting en resources en test aanmelden, OTP, sessies en backend-toegang opnieuw na iedere gemotiveerde wijziging. Herstel bij verslechtering de opgeslagen uitgangsconfiguratie; een geslaagde rollback wordt hier niet geclaimd.

WAF-authenticatie via de XML API automatiseren

Voor de automatisering horen drie afzonderlijke objecten bij elkaar: FormTemplate levert het aanmeldformulier, ReverseAuthentication definieert de client- en backend-authenticatie, en FirewallRule koppelt de policy aan de publicatie of de bijbehorende paden. Maak eerst een back-up van de werkende sjabloon, de policy en alle regels die deze gebruiken. Toegang, expliciete schrijfbewerkingen, beoordeling van antwoorden en veilige herhalingen worden uitgelegd in Toegang tot de Sophos Firewall XML API beveiligen. De volgende informatie beschrijft de SFOS-22/23-referenties, niet een op een appliance geteste schrijfprocedure. Controleer vóór wijzigingen de API help van de geïnstalleerde build; voer geen schrijfbewerkingen uit bij onduidelijke velden of uploadkoppelingen.

Clientmodus, backend en sessies uit elkaar houden

In het object ReverseAuthentication worden Name, VirtualWebserverMode en RealWebserverMode als verplichte velden beschreven. Name staat maximaal 60 tekens toe. VirtualWebserverMode kiest Basic of Form voor de client; de gedocumenteerde standaardwaarde Basic is geen MFA-aanbeveling. Voor WAF-MFA blijft Form vereist. BasicPrompt is de optionele Basic-meldingstekst met maximaal 255 tekens. FormTemplate verwijst in de Form-modus naar de opgeslagen sjabloon. UserGroupList bevat herhaalbare UserGroup-items voor bestaande gebruikers of groepen; deze selectie moet nog steeds overeenkomen met de MFA-groep. Het woord Mode in opmerkingen over de toepasbaarheid is geen aanvullend gedocumenteerde XML-tag.

RealWebserverMode kiest onafhankelijk daarvan Basic of None voor de backend; ook hier noemt de tabel Basic als standaardwaarde. Bij Basic hoort UsernameAffix bij de backend-aanmelding. Prefix en Suffix zijn optionele teksten met elk maximaal 255 tekens en zijn alleen bedoeld voor de bijbehorende affixselectie. Bij None is in plaats daarvan RemoveBasicHeader met Enable of Disable relevant. De daar vermelde standaardwaarde ON is op zichzelf geen toegestane invoerwaarde; gebruik expliciete waarden alleen na controle van de build. De bestaande controles voor HTTPS, backend en gebruikersnamen blijven vereist.

Neem tegenstrijdigheden niet over in een payload: Voor UsernameAffix toont het XML-voorbeeld None/Prefix/Suffix/PrefixAndSuffix, terwijl de tabel Basic, Prefix, Suffix, PrefixandSuffix en tegelijk de standaardwaarde None noemt. Raad noch de schrijfwijze, noch aanvullende keuzewaarden. Ook toont het voorbeeld SessionTimeout en SessionLifetime als schakelaars, de bijbehorende Limit-velden als integer en de Scope-velden als Hours/Minutes/Days. De tabel bevestigt voor SessionTimeoutLimit het bereik van 1 tot 9999, maar verwisselt bij SessionLifetime en SessionLifetimeLimit integer en schakelaar; waarden zoals ON en 8 Hours passen niet consistent bij de gegevenstypen. Deze inconsistenties onderbouwen geen betrouwbare standaardwaarden of uitvoerbare sessieconfiguratie. Bevestig de gewenste inactiviteitsgrens en maximale levensduur in de geïnstalleerde build, lees de opgeslagen toestand terug en voer de bestaande tests voor sessies, uitloggen en opnieuw inloggen uit. De SFOS-23-uitbreiding RedirectToRequestedURL en de afzonderlijke terugleidingstest blijven hiervan onafhankelijk.

Sjabloon en bijbehorende bestanden toewijzen

De FormTemplate-referentie toont FormTemplate als object met Name, Description, Template en Assets, met daaronder herhaalbare Asset-items. Name en Template zijn verplichte velden: de naam staat maximaal 60 tekens toe, Template is een string met maximaal 255 tekens voor het selecteren en uploaden van de HTML-sjabloon. Description is optioneel. De optionele Asset-strings staan elk maximaal 255 tekens toe en meerdere waarden voor gebruikte afbeeldingen, stylesheets of JavaScript-bestanden.

Het voorbeeld laat Template en Asset leeg. Daarmee legt het geen multipart-onderdeelnamen, bestandspaden, Base64-codering of rechtstreeks overdraagbare HTML-inhoud vast. Pas geen certificaat-uploadkoppeling toe op FormTemplates. Gebruik zonder bevestigd uploadcontract de bestaande GUI-volgorde Upload > Save en selecteer daarna de opgeslagen sjabloon via FormTemplate in de Form-policy. De vereiste formuliervelden en toegestane asset-bestandstypen uit de vorige paragraaf blijven gelden. Controleer het gerenderde formulier, de assets en de OTP-aanmelding met een testgebruiker; alleen het succesvol opslaan van een object bewijst niet dat het formulier werkt.

Authentication Policy aan de regel koppelen

Bij FirewallRule betreft deze toewijzing de WAF-tak HTTPBasedPolicy, niet NetworkPolicy of UserPolicy. De parametertabel beschrijft Authentication als een optionele scalaire string voor een Authentication Policy. In het padvoorbeeld staat de bijbehorende toewijzing als AccessPaths > AccessPath > auth_profile. De opmerking in het voorbeeld scheidt de regelbrede variant met Authentication en broncontroles van AccessPaths; deze onderbouwt geen willekeurige combinatie of automatische overerving. Meng regelbrede en padgebonden schrijfwijzen niet zonder controle en neem niet aan dat een op de firewall aanwezige policy al elk pad beschermt.

In SFOS 23 beschrijft de tabel path als een verplichte array van strings met meerdere waarden, maximaal 63 tekens, zonder komma en met UTF-8-ondersteuning; SFOS 22 noemt hier een scalair. Het voorbeeld gebruikt zowel path als Path. backend is in de SFOS-23-tabel optioneel; dat is geen toezegging dat een beschermd portaal zonder backend werkt. Het nieuwe padgebonden action toont letterlijk 0/1/2/3, zonder betrouwbare koppeling aan de GUI-acties. Raad geen numerieke toewijzing en stel deze waarden niet gelijk aan het netwerkveld Action. Routing, backend en beschermingsprofiel worden uitgelegd in WAF: webservers veilig publiceren.

Lees voor de authenticatiewijziging eerst de daadwerkelijke hostnamen en paden van de doelregel, wijs de gewenste Form-policy toe per beschermd pad en vergelijk vervolgens de opgeslagen toestand met de gewenste toestand. Controleer alle alternatieve paden, hostnamen en regels, evenals een onjuiste OTP en gebruikers buiten de groep. Daarbij blijven de al beschreven Protect-controles, de documentatiegrens voor Passthrough en het wijzigingsvenster voor WAF-regels ongewijzigd van toepassing.

Objectantwoorden beoordelen vóór een retry

De volgende toewijzingen zijn XML-statuswaarden en letterlijke, niet uitgewerkte Message.*-symbolen uit de referentie, geen HTTP-statuscodes of aangetoonde meldingsteksten tijdens runtime. Voor de FirewallRule-koppeling zijn vooral de verschillen tussen Add en Edit belangrijk:

• Add firewall rule: 200 / Message.FWRuleAddSuccess, 500 / Message.FWRuleAddFail, 502 / Message.FWRuleRecordExists.
• Edit firewall rule: 200 / Message.FWRuleEditSuccess, 202 / Message.FirewallRuleUpdateWithRename, 500 / Message.FWRuleEditFail, 502 / Message.FWRuleUpdateRecordExist. Lees bij 202 ook de daadwerkelijke naam en alle toewijzingen terug.
• Verschillende toewijzingen: Add 541 / Message.VHIPRangeConflict, Edit 541 / Message.FWRuleFailMaxUser; Add 543 / Message.CannotSetupRedirectionFromHTTP, Edit 543 / Message.CannotUseDefaultPort; Add 544 / Message.CannotUseDefaultPort, Edit 544 / Message.CannotSetupRedirectionFromHTTP. Dezelfde code alleen is niet voldoende voor de interpretatie.
• Andere onderscheidende regels: Edit 552 / Message.CannotImportDiffPolicytypeWithSameName; Add 554 / Message.CannotUseFQDNWildCardAsProtectedServer, Edit 554 / Message.CannotUpdateFQDNWildCardAsProtectedServer.
• Delete firewall rule: 200 / Message.FWDelSuccess, 500 / Message.FWRuleDeleteFail, 596 / Message.CMLOCALOperationrestriction. 596 staat ook bij Add en Edit; stel de daadwerkelijke machtigings- en beheertoestand vast en omzeil deze niet door blind te herhalen of te verwijderen. Een regel verwijderen is geen herstelmethode voor een ontbrekende authenticatiekoppeling.

Ook de twee voorafgaande objecten hebben eigen antwoorden:

• Add Authentication Policy: 200 / Message.ReverseAuthAddSuccess, 500 / Message.ReverseAuthAddFail, 502 / Message.ReverseAuthRecodExist.
• Edit Authentication Policy: 200 / Message.ReverseAuthUpdateSuccess, 500 / Message.ReverseAuthUpdateFail.
• Add FormTemplate: 200 / Message.FormTemplateAddSuccess, 500 / Message.FormTemplateAddFail.
• Edit FormTemplate: 200 / Message.FormTemplateUpdateSuccess, 500 / Message.FormTemplateUpdateFail, 502 / Message.FormTemplateRecodExist. De schrijfwijze Recod in deze symbolen blijft letterlijk behouden; leid daaruit geen aanvullende status voor een andere bewerking af.

Leg de bewerking, de code, het daadwerkelijke antwoord en de opgeslagen toestand van sjabloon, policy en doelregel gezamenlijk vast. Controleer bij fouten, waarschuwingen of een onduidelijk antwoord eerst wat werkelijk is overgenomen; omzeil dit niet door een tweede naam, een bredere groep of een onbeschermd pad te gebruiken. Stop bij onduidelijke syntaxis of uploadtoewijzing en schakel Support in met opgeschoonde gegevens. Pas na bevestigde opslag volgen de bestaande positieve en negatieve tests voor MFA, backend, sessies, uitloggen, terugleiding en alternatieve paden. Documentatiecontrole vervangt geen acceptatietest op de eigen firewall.

OTP-algoritme en authenticator-app

SFOS 22 ondersteunt naast SHA1 ook SHA256 en SHA512 voor OTP-tokens. Dit is vanuit veiligheidsoogpunt zinvol, maar werkt alleen als de gebruikte authenticator-app het gekozen algoritme ondersteunt.

Belangrijke punten:

• SHA256 of SHA512 zijn veiliger dan SHA1.
• Niet elke authenticator-app ondersteunt deze algoritmen in deze context.
• Microsoft Authenticator kan bij SHA256 of SHA512 wel de QR-code scannen, maar de aanmelding kan daarna mislukken.
• Als het algoritme wordt gewijzigd, moeten oude tokens worden verwijderd en opnieuw worden gescand.
• Wijzigingen aan de token-timestep gelden alleen voor nieuw gegenereerde tokens en moeten passen bij de gebruikte app.

Voor een uitrol naar productie moet je de gewenste app en het algoritme met een kleine pilotgroep testen. Pas daarna moeten bestaande gebruikers breed worden gemigreerd.

Als een gebruiker de app verliest of het algoritme wordt gewijzigd, is het vaak niet genoeg om de gebruikerscommunicatie te herhalen. Onder Authentication > Multi-factor authentication > Issued tokens kunnen tokens worden gereset of extra eenmalige codes worden gegenereerd. Dit proces moet intern geregeld zijn omdat het een sterke veiligheidsimpact heeft.

Validatie en beheer

Testplan na de installatie

Na de configuratie moet je niet alleen controleren of de inlogpagina verschijnt. Het is belangrijk om het volledige toegangspad te testen.

1. Gebruik een externe browser of extern testnetwerk.
2. Open de WAF-URL met een gebruiker uit de toegestane groep.
3. Test login met correct wachtwoord en OTP.
4. Test login met onjuiste OTP.
5. Test gebruiker buiten de toegestane groep.
6. Controleer sessieverloop na inactiviteit.
7. Controleer backend-functie van de applicatie.
8. Controleer Log Viewer en reverseproxy.log op opvallendheden.
9. Controleer logout, opnieuw inloggen en sessieverloop met dezelfde browser.
10. Test met een tweede hostname of alternatief pad als de applicatie meerdere WAF-regels gebruikt.

Om ook het terugleiden naar de opgevraagde URL op SFOS 23 te testen, open je zonder geldige WAF-sessie een daadwerkelijk beschermde URL met een pad anders dan /. Controleer na een succesvolle login met wachtwoord en OTP, met RedirectToRequestedURL op Enable, of precies de oorspronkelijk opgevraagde URL wordt bereikt en of de backend-toegang de bedoelde rechten respecteert. Een geslaagde omleiding alleen bewijst geen MFA of toegangsrecht; alle bovenstaande tests voor weigering, backend, sessies, logout, opnieuw inloggen en alternatieve paden blijven nodig.

Voor de logbestanden helpt Sophos Firewall Troubleshooting: Services en Logs. WAF-gebeurtenissen hangen meestal aan de Reverse Proxy en verschijnen daarnaast in de Log Viewer.

Voor de acceptatie moet elk testgeval aan een zichtbaar resultaat worden gekoppeld:

• Gebruiker: Firewall-login verschijnt, OTP wordt gevraagd, daarna opent de verwachte applicatie.
• Sophos Firewall: Log Viewer en reverseproxy.log tonen toegestane of geweigerde WAF-authenticatie.
• Authenticatiebron: AD, LDAP, RADIUS of lokale gebruikersbron toont de verwachte succesvolle of mislukte login.
• Backend: Applicatie bereikt de juiste gebruikers- of gaststatus en toont geen onverwachte tweede foutpagina.

Als alleen de browser succesvol lijkt, maar er geen bijbehorende logs zichtbaar zijn, is de acceptatie onvolledig. Controleer dan of de juiste WAF-regel wordt toegepast, of het authenticatiebeleid echt actief is en of de logs op de verwachte locatie terechtkomen.

Go-live en werking na de activering

Na een succesvolle test moet WAF-MFA niet zomaar breed worden ingeschakeld en daarna worden vergeten. De eerste uren na de livegang zijn belangrijk, omdat echte gebruikers andere browsers, andere authenticator-apps, opgeslagen wachtwoorden, oude bladwijzers en andere sessiestatussen meebrengen dan een beheerderstest.

Voor de livegang is een beknopt beheerplan zinvol:

• Uitrolgroep: eerst pilotgroep, daarna andere gebruikersgroepen.
• Supportvenster: Helpdesk of verantwoordelijke beheerders tijdens de eerste logins bereikbaar houden.
• Monitoring: Log Viewer, reverseproxy.log en authenticatiebron observeren.
• Token-reset: duidelijke procedure voor verloren of verkeerd ingestelde OTP-tokens.
• Sessiegedrag: Session timeout en Session lifetime na werkelijk gebruik controleren.
• Terugvalpad: WAF-regel, Authentication Policy en wijzigingsstappen gedocumenteerd houden.

Bij bedrijfskritische applicaties moet je de livegang niet plannen op een moment waarop niemand inlogproblemen goed kan controleren. Beter is een gecontroleerd venster met testgebruikers uit verschillende groepen, daarna een korte evaluatie van de logs en pas daarna de uitbreiding naar andere gebruikers.

Na enkele dagen moet de configuratie opnieuw worden gecontroleerd:

• Zijn er gebruikers die MFA omzeilen omdat ze via een andere WAF-regel of een andere URL toegang hebben?
• Wordt de toegang nog steeds alleen voor de geplande groepen toegestaan?
• Passen sessieduur en inactiviteits-time-out bij de applicatie?
• Worden geweigerde logins en tokenproblemen in de praktijk daadwerkelijk gezien?
• Zijn er ondersteuningsgevallen die wijzen op onduidelijke gebruikerscommunicatie of een verkeerde authenticator-app?
• Zijn oude testregels, testdomeinen of tijdelijke uitzonderingen weer verwijderd?

Deze nazorg is vooral belangrijk als meerdere hostnamen, paden of WAF-regels naar dezelfde applicatie wijzen. Anders kan het gebeuren dat een pad netjes met MFA is beveiligd, maar een tweede pad nog steeds zonder voorliggende authenticatie bereikbaar blijft.

Problemen oplossen

Andere veelvoorkomende fouten

• Authentication Policy gebruikt niet Form: Het MFA-gedrag past niet bij de verwachte WAF-configuratie.
• Sophos Authenticator als nieuwe standaardapp gepland: De app is EOL en mag niet meer als basis voor een nieuwe uitrol worden gebruikt.
• Fallback-toegang hangt van dezelfde WAF-regel af: Beheerders kunnen de wijziging bij een fout niet meer goed terugdraaien.
• Token-uitrol is niet getest: Gebruikers falen bij de eerste login, hoewel de WAF-regel technisch correct is.
• Tweede URL of WAF-regel blijft zonder MFA actief: Gebruikers omzeilen onbedoeld de voorliggende MFA.
• Tijdelijke pilotuitzonderingen worden niet verwijderd: De productiebeveiliging is inconsistent en moeilijk te auditen.

MFA wordt niet gevraagd

Controleer eerst of Web application firewall onder Require MFA for is geactiveerd. Controleer daarna of de WAF-regel echt een authenticatiebeleid gebruikt en of dit beleid de verwachte gebruikers of groepen bevat.

Login werkt, maar de applicatie opent niet

Dan ligt het probleem vaak na de firewall-aanmelding. Controleer backend-bereikbaarheid, certificaat, hostheader, pad, beschermingsbeleid en authenticatie-forwarding. Als de backend eigen authenticatie verwacht, moet de forwarding-modus daarbij passen.

Gebruiker kan zich na algoritmewijziging niet aanmelden

Als van SHA1 naar SHA256 of SHA512 is overgeschakeld, moeten bestaande tokens worden verwijderd en opnieuw worden gescand. Bovendien moet de authenticator-app het nieuwe algoritme ondersteunen.

Backend vraagt na succesvolle MFA opnieuw om login

Op SFOS 22.0 GA Respin Build 411 kan NC-177509 optreden: de Form-gebaseerde WAF-MFA slaagt, maar daarna vraagt de backend om een extra aanmelding die niet kan worden omzeild. De OTP-code wordt niet van het wachtwoord gescheiden voordat de firewall de inloggegevens naar de backend doorstuurt. Dit probleem is opgelost vanaf SFOS 22.0 MR1 Build 490.

De correctie voor de niet-verwijderde OTP-code heeft ook referentie NC-177201. De ID’s zijn niet uitwisselbaar: NC-177509 koppelt getroffen en gecorrigeerde builds, terwijl NC-177201 de specifieke fixtekst aanduidt. Vermeld in een supportcase daarom het symptoom, de build en beide referenties.

Controleren:

• WAF Authentication Policy gebruikt Form.
• Authentication forwarding mode is actief en past bij de backend-applicatie.
• De betrokken WAF-regel gebruikt precies deze Authentication Policy.
• De fout treedt op na succesvolle MFA, niet al bij de firewall-login.
• reverseproxy.log, Log Viewer en het backend-accesslog dekken hetzelfde testmoment af.
• De gebruikte SFOS-versie is gecontroleerd.

Bewaar op een getroffen GA-systeem reverseproxy.log, de Log Viewer-gegevens en het backend-log en plan een update naar MR1 Build 490 of nieuwer. Als een snelle update niet mogelijk is, wijzig de authenticatiestroom dan niet zonder validatie; gebruik de bewaarde gegevens om een Sophos-supportcase te openen. Verzwak MFA niet en wijzig Authentication forwarding niet zonder analyse: None past alleen wanneer de backend geen doorgestuurde inloggegevens nodig heeft. Neem bij productieportalen testgebruikers, rollback en gebruikerscommunicatie mee in het plan.

Te veel of oude sessies

Controleer sessietime-out, sessieduur en de globale WAF-sessie-instellingen. In productieomgevingen moet duidelijk zijn of lange sessies gewenst zijn of dat gebruikers na inactiviteit snel opnieuw moeten worden geauthenticeerd.

Checklist

• WAF-regel is gedocumenteerd en extern getest.
• HTTPS-certificaat past bij de gepubliceerde hostnaam.
• MFA geldt voor de juiste gebruikersgroep.
• Require MFA for > Web application firewall is geactiveerd.
• WAF Authentication Policy gebruikt Form.
• Authenticatie-forwarding past bij de backend-applicatie.
• Token-uitrol, portaltoegang en helpdeskprocedure zijn voorbereid.
• Sessietime-out en sessieduur zijn bewust ingesteld.
• OTP-app en hash-algoritme zijn getest.
• Fallback-admin-toegang is aanwezig.
• Rollback en verantwoordelijke persoon zijn gedocumenteerd.
• Authenticatiebron en backend-login zijn apart gecontroleerd.
• Log Viewer en reverseproxy.log zijn na de test gecontroleerd.
• Go-live-ondersteuningsvenster en token-resetprocedure zijn vastgesteld.
• Alternatieve hostnamen, paden en WAF-regels zijn op MFA-omzeiling gecontroleerd.
• Tijdelijke pilotuitzonderingen zijn na de uitrol verwijderd.

Veelgestelde vragen