Sophos Firewall Google Workspace OIDC instellen

Met SFOS 23.0 kan Google Workspace als OpenID Connect (OIDC)-identiteitsprovider worden ingesteld voor WebAdmin, Captive Portal, VPN Portal en Remote Access IPsec en SSL VPN. Google controleert de identiteit; de firewall haalt daarnaast de groepslidmaatschappen op en past zijn eigen gebruikers-, VPN- en beheerdersrechten toe. Een succesvolle Google-aanmelding geeft daarom op zichzelf nog geen beheerderstoegang of toegang tot een intern netwerk.

Snelle route: Bereid een Google OAuth-webclient en een gedelegeerd serviceaccount voor, maak onder Authentication > Servers een OpenID Connect-server met IdP vendor: Google Workspace aan, registreer de daar weergegeven callback-URL’s bij Google, importeer groepen en schakel alleen de benodigde diensten om onder Authentication > Services. Controleer daarna met een pilotaccount de aanmelding, rechten en logs. De geteste lokale noodtoegang blijft behouden.

Deze handleiding beschrijft de SFOS-23-configuratie en is geen toezegging voor een specifieke vrijgegeven firmwarebuild. Vóór een update geldt de eigen firmware- en back-upplanning. Chromebook SSO en Google Directory Sync voor Sophos Fusion zijn andere integraties en vervangen deze OIDC-server op de firewall niet.

Vereisten en beveiligingsgrenzen

Verantwoordelijkheden vastleggen en de bestaande configuratie veiligstellen

Er zijn een Google Cloud-project, een Google Workspace-account met Super Admin-toegang voor de inrichting en een firewallbeheerder nodig. Cloud Console beheert de OAuth-client, API’s en het serviceaccount; Google Admin Console beheert gebruikers, groepen en Domain-wide delegation.

Vóór de pilot worden een configuratieback-up en een geteste lokale hersteltoegang voorbereid. Noteer daarnaast de bestaande authenticatieservers en hun volgorde per dienst, portalhostnamen, Device Access-toestemmingen, groeps- en VPN-toewijzingen en bestaande beheerdersprofielen. Houd tijdens de wijziging een sessie met volledige beheerdersrechten open; vanwege mogelijke time-outs is die geen vervanging voor de tweede toegang.

Leg vóór de eerste pilotaanmelding voor elke betrokken lokale identiteit onder Authentication > Users vast of het account al bestaat, evenals het bestaande User type, het toegewezen Profile en de accountstatus. Deze inventarisatie per account maakt deel uit van de vastgelegde eerdere toestand: een latere wijziging van de IdP-toewijzing of de Google-rol zet bestaande lokale beheerdersaccounts niet automatisch terug.

Voor de rechtenplanning blijven persoonlijke beheerders en Device Access-profielen van toepassing. Google SSO vervangt noch het least-privilege-principe, noch de beperking van toegestane beheerbronnen.

Eén consistente hostnaam gebruiken

De portalnaam moet behoren tot een registreerbaar domein met een openbare TLD. Een losse naam zoals firewall of een lokaal domein zoals firewall.local is niet geschikt voor Google OAuth-redirects. Gebruik dezelfde FQDN voor portaltoegang, redirect-URI’s en automatische portaldoorverwijzingen. Controleer DNS-resolutie en een vertrouwd HTTPS-certificaat dat bij de naam past vanuit de daadwerkelijk gebruikte clientnetwerken.

fw.example.com dient hier alleen als documentatievoorbeeld en wordt vervangen door de eigen geldige FQDN. Het is geen kant-en-klare redirect-URI. Neem het callbackpad en de dienstpoort later ongewijzigd over uit Show URLs; stel ze niet samen op basis van een voorbeeld. Gebruik voor deze procedure ook bij handmatige invoer een FQDN, geen IP-adres.

Beperkingen vóór de omschakeling controleren

Voor elke authenticatiedienst kan slechts één OIDC-IdP-server worden geselecteerd. Een bestaande Entra-toewijzing wordt daarom niet terloops aangevuld, maar bewust vervangen of ongewijzigd gelaten.
Voor hetzelfde domein kunnen gebruikers niet tegelijkertijd via Active Directory en Google Workspace worden gesynchroniseerd. Bestaande gebruikers en groepen hebben overeenkomstige Google-objecten nodig; oude objecten die niet kunnen worden gekoppeld, blijven handmatig beheerd.
De eigen MFA van de firewall wordt niet gebruikt voor Google OIDC. De MFA-vereiste wordt bij Google geconfigureerd en tijdens de pilot daadwerkelijk gecontroleerd. Lokale noodaccounts behouden hun eigen beveiliging.
In een HA-cluster ondersteunt Google SSO momenteel geen WebAdmin-aanmelding op het Auxiliary-apparaat. Daarvoor blijft een onafhankelijke lokale beheerroute noodzakelijk.
Voor Google SSO met Sophos Connect zijn Windows en clientversie 2.4 of hoger voorzien. De macOS-ondersteuning voor Entra betekent niet dat Google Workspace wordt ondersteund.

Alleen als Context-Aware Access (CAA) wordt gebruikt: Controleer vóór de pilot voor elke beoogde gebruiker of diens licentie/edition CAA ondersteunt. Controleer daarnaast of de concrete toepassing en aanmeldprocedure worden ondersteund en of het gewenste beleid daadwerkelijk aan de toepassing en de gebruikersgroep/organisatie-eenheid is toegewezen. Gebruikers met andere editions vallen niet onder het CAA-beleid, ook niet als dezelfde groep of organisatie-eenheid wordt geselecteerd; Endpoint Verification alleen bewijst niet dat een gebruiker voor CAA in aanmerking komt. CAA is optioneel en een premiumlicentie is geen vereiste voor gewone Google OIDC-authenticatie. Google-documentatie over SAML bewijst niet dat de Sophos OIDC-aanmeldprocedure wordt ondersteund. Toon vóór de vrijgave met nieuwe positieve en negatieve aanmeldtests voor de concrete toepassing, gebruikers en voorwaarden aan dat het beleid het gewenste effect heeft. Ontbrekende ondersteuning of een onverwacht succesvolle negatieve test blokkeert de vrijgave van de met CAA beveiligde aanmeldprocedure.

Google Workspace voorbereiden

OAuth-webclient aanmaken

Selecteer het juiste project in Google Cloud Console > APIs & Services > Credentials. Als Google eerst vraagt om het OAuth-toestemmingsscherm te configureren, rond dit dan af voor de eigen organisatie en de goedgekeurde gebruikersgroep; maak niet uitsluitend voor de test een algemene externe toegang mogelijk.
Open Create credentials > OAuth client ID en selecteer Application type: Web application.
Geef een herkenbare naam op, bijvoorbeeld SFOS-Google-SSO-Pilot, en maak de client aan.
Sla Client ID en Client secret onmiddellijk op in een goedgekeurde kluis voor secrets. Kopieer het secret niet naar screenshots, tickets of de wijzigingsdocumentatie.

De OAuth-client-ID identificeert de firewall bij de aanmelding. Dit is niet de numerieke ID van het serviceaccount die later voor de delegatie nodig is. De redirect-URI’s worden pas toegevoegd zodra de firewall ze heeft gegenereerd.

Serviceaccount en groepsopvraging instellen

De aanmelding en het opvragen van groepen gebruiken verschillende toegangen: de OAuth-client dient voor de interactieve aanmelding; het serviceaccount stelt de firewall in staat om Google Directory-informatie op te halen. Google levert groepslidmaatschappen niet zomaar als onderdeel van het normale OIDC-aanmeldantwoord.

Maak onder Google Cloud Console > IAM & admin > Service accounts > Create service account een afzonderlijk account voor deze integratie aan, bijvoorbeeld sfos-directory-reader.
Ken niet zonder meer Owner- of Editor-rollen toe omdat die een vermeende vereiste zouden zijn. Aanvullende IAM-rechten worden alleen goedgekeurd voor een aantoonbare taak.
Noteer in de details van het serviceaccount de numerieke Unique ID.
Kies onder Keys > Add key > Create new key het type JSON. Bewaar de gedownloade privésleutel beveiligd voor de latere upload naar de firewall en voorkom ongecontroleerde downloadkopieën.
Zoek onder APIs & Services > Library de Admin SDK API en activeer deze met Enable.

⚠️ Als Service account key creation is disabled verschijnt, wordt de inrichting stopgezet. Een organisatiebeleid wordt niet voor de hele organisatie uitgeschakeld om deze handleiding te kunnen vervolgen. De beveiligingsverantwoordelijke voor Google moet een beperkte, gedocumenteerde uitzondering goedkeuren, anders blijft de integratie geblokkeerd. De hier beschreven Sophos-configuratie vereist een JSON-sleutelbestand; een andere authenticatiemethode wordt niet als ongecontroleerd alternatief voorgesteld.

Domain-wide delegation beperken

Open als bevoegde Super Admin Google Admin Console > Security > Access and data control > API controls.
Voer onder Domain-wide delegation > Manage domain wide delegation > Add new de Unique ID van het serviceaccount in als Client ID, niet de ID van de OAuth-webclient.
Voer in OAuth scopes (comma-delimited) de twee benodigde leesscopes in:

https://www.googleapis.com/auth/admin.directory.group.readonly,https://www.googleapis.com/auth/admin.directory.group.member.readonly

Als ook WebAdmin via Google moet worden geauthenticeerd, voeg dan deze scope toe:

https://www.googleapis.com/auth/admin.directory.rolemanagement.readonly

Sla de delegatie op met Authorize en controleer de ID en de volledige lijst met scopes.

De scope-URL’s zijn vaste API-identificatoren, geen voorbeeldwaarden. Als Multi-party approval actief is, moet een andere Super Admin de delegatie goedkeuren. Wijzigingen kunnen tot 24 uur duren; maak in die periode niet overhaast een tweede delegatie met ruimere rechten aan. Domain-wide delegation staat toegang namens anderen toe binnen de Workspace-tenant en is daarom, ondanks de leesrechten, een beveiligingsrelevante toestemming. Wijs een verantwoordelijke eigenaar aan voor het serviceaccount, de sleutel-ID, het gedelegeerde beheerdersaccount, het doel en de beoordelingsdatum.

Afzonderlijke groepen voor firewallbeheerders voorbereiden

Voor een overzichtelijke start wordt groepstoewijzing aanbevolen. Maak onder Google Admin Console > Directory > Groups een groep aan die uitsluitend voor firewallbeheerders is bedoeld en voeg alleen de pilotbeheerders toe. Een groep SFOS-NOC-ReadOnly kan bijvoorbeeld worden gekoppeld aan een vooraf gecontroleerd alleen-lezenprofiel. De naam en het groepsadres zijn eigen organisatiewaarden; een gewone medewerkers- of VPN-groep krijgt geen WebAdmin-rechten.

Als alternatief kunnen onder Account > Admin roles aangepaste of vooraf gedefinieerde Google-beheerdersrollen worden toegewezen en kan in de firewallserver Roles worden gebruikt. Aangepaste rollen worden gekoppeld met de exacte rolnaam; vooraf gedefinieerde rollen vereisen hun specifieke IdP-waarde, niet simpelweg de zichtbare naam. Een bevestigd voorbeeld is Groups admin → _GROUPS_ADMIN_ROLE. Google-beheerdersrollen kunnen tegelijkertijd rechten geven in Google Admin Console. Ze worden daarom niet uitsluitend als handig firewalllabel toegekend; een afzonderlijke groep is doorgaans de beperktere keuze.

OIDC-server op de firewall configureren

Client, redirects en endpoints

Open WebAdmin via de geplande FQDN en ga naar Authentication > Servers > Add.
Selecteer Server type: OpenID Connect, een unieke Server name en IdP vendor: Google Workspace.
Voer Client ID en Client secret van de OAuth-webclient in.
Selecteer onder Redirect URIs de optie Use firewall URL. De firewall gebruikt de hostnaam uit de huidige WebAdmin-URL. Voer als alternatief met Enter manually de gecontroleerde eigen FQDN in.
Open Show URLs en kopieer de volledige URL’s voor Web admin console, Captive portal of VPN portal and remote access van de daadwerkelijk geplande diensten.
Laat de automatisch ingestelde Issuer URL https://accounts.google.com staan en gebruik Discover/Reset endpoint URLs. Authorization URL, Token URL, Logout URL, JWKS URL en User info URL worden via discovery ingevuld, niet op basis van aannames.

Identiteit, fallback en beheerdersrechten

Onder User attributes ondersteunen Display name en Username de waarden name of email; de gedocumenteerde standaardwaarde is voor beide name. Email address is vooraf ingevuld met email. Maak de keuze vóór de eerste pilotaanmelding: email kan de koppeling aan een uniek Workspace-aanmeldadres vereenvoudigen, maar moet passen bij bestaande firewallidentiteiten. Attribuutwaarden worden later niet terloops gewijzigd, omdat hierdoor andere accountkoppelingen kunnen ontstaan.

Voor uitsluitend VPN- of Captive Portal-gebruik blijft IdP authentication for firewall administrators uitgeschakeld. Voor WebAdmin wordt de optie bewust ingeschakeld en wordt elke toewijzing aangemaakt met IdP attribute, de exacte IdP value en Device access profile. Groeps- of rolwaarden worden overgenomen uit de eigen Google-configuratie, niet geraden op basis van de voorbeeldnaam.

De firewall controleert toewijzingsregels van boven naar beneden en gebruikt het eerste overeenkomende profiel. Een gebruiker in meerdere beheerdersgroepen moet daarom expliciet worden getest. Zonder passende beheerderstoewijzing krijgt de identiteit geen WebAdmin-toegang en kan deze als gewone gebruiker worden aangemaakt.

Kies onder Fallback group een bewust beperkte gebruikersgroep. Als de Google-groep niet op de firewall bestaat, wordt deze fallbackgroep gebruikt. Ook als de server onder Firewall authentication methods is geselecteerd, vervangt Default group deze OIDC-fallbacktoewijzing niet. Een VPN-groep met ruime rechten is geen veilige opvanggroep.

Serviceaccount controleren en hostnamen gelijkstellen

Voer onder Service account credentials > Email address het adres in van de Google Workspace Super Admin die voor deze toegang is voorzien. Hier hoort niet het e-mailadres van het serviceaccount te staan.
Selecteer onder JSON private key > Browse het beveiligde JSON-sleutelbestand van het afzonderlijke serviceaccount.
Voer Test connection uit. De test controleert de netwerkverbinding en toepassingsrechten. Hij bewijst nog niet dat de gebruikersaanmelding of beheerderstoewijzing correct is.
Sla op met Save.
Stel via Go to Admin and user settings onder When redirecting users to the captive portal or other interactive pages dezelfde portal-FQDN in: Use the firewall’s configured hostname of Use a different hostname, passend bij de eigen configuratie. Sla op met Apply.
Open in Google Cloud Console > APIs & Services > Credentials de OAuth-webclient en voer onder Authorized redirect URIs > Add URI elke eerder gekopieerde volledige callback-URL in. Sla op met Save en vergelijk teken voor teken.

Groepen, diensten en VPN beschikbaar stellen

Groepen importeren en beleidsregels toewijzen

Open onder Authentication > Servers de Assistant for importing groups van de Google-server. Alle groepen kunnen worden geïmporteerd, of specifieke groepen op basis van Display name en Mail. Selecteer voor de pilot alleen de benodigde gebruikersgroep. In de wizard kunnen Surfing quota, Access time, Network traffic en Traffic shaping worden toegewezen aan alle of afzonderlijke groepen.

De tijd op de firewall en bij Google moet gesynchroniseerd zijn, anders kan zelfs de groepsimport al mislukken. Controleer na de import de groepsnamen en de beoogde beleidsregels. Voor IPsec of SSL VPN moeten de nieuwe groepen daarnaast worden opgenomen in de betreffende VPN-beleidsregels. Een succesvolle import betekent nog geen VPN-toestemming.

Authenticatie per dienst omschakelen

Selecteer onder Authentication > Services de Google-server alleen bij de benodigde methoden:

Administrator authentication methods: WebAdmin.
Firewall authentication methods: Captive Portal.
VPN portal authentication methods: VPN Portal.
VPN (IPsec/dial-in/L2TP/PPTP) authentication methods: Remote Access IPsec; de naam van de lijst betekent niet dat OIDC wordt ondersteund voor elk daarin genoemd legacyprotocol.
SSL VPN authentication methods: Remote Access SSL VPN.

Sleep de server voor de gekozen dienst naar het begin van de lijst en gebruik per dienst Apply. Controleer de volgorde en lokale fallback aan de hand van de eerder gedocumenteerde situatie; Local wordt voor persoonlijke lokale beheerders niet terloops verwijderd. Niet-benodigde diensten blijven ongewijzigd.

Sophos Connect en bereikbaarheid

Google SSO gebruikt de VPN-portalpoort ook voor communicatie voor externe toegang. Voor deze toepassing moet onder Administration > Device access > Local service ACL toegang tot het VPN Portal vanuit WAN worden toegestaan. Plan daarbij bewust de toegestane bronnen en de daadwerkelijk benodigde bereikbaarheid; WebAdmin wordt hiervoor niet vanaf WAN toegankelijk gemaakt. De beperkingen worden beschreven in Device Access en Local Service ACL.

Bij gebruik van een provisioningbestand moeten IPsec, SSL VPN en VPN Portal dezelfde Google-server gebruiken. De waarde gateway komt overeen met de FQDN waarmee de redirects zijn gegenereerd. Zonder provisioningbestand moeten SSL VPN en VPN Portal eveneens dezelfde server gebruiken; IPsec kan een andere Google-server gebruiken. Wijzig daarom in bestaande VPN-bestanden niet blindelings alleen een authenticatieveld.

Na het instellen of wijzigen van de Google-configuratie moeten Windows-gebruikers hun configuratiebestand opnieuw importeren in Sophos Connect 2.4 of hoger. Pas daarna wordt een nieuwe verbinding getest. Op gedeelde endpoints moet voor volgende gebruikers een nieuwe SSO-aanmelding worden afgedwongen; een bestaande Google-sessie mag niet ongemerkt de volgende persoon aanmelden.

Optioneel: Captive Portal veilig gebruiken

Voor de betreffende gebruikersgebaseerde firewallregel zijn Match known users en Use web authentication for unknown users vereist. Schakel onder Authentication > Web authentication > Captive portal behavior voor dit portalverloop Show web page after sign-in in, kies In new browser window en schakel Use insecure HTTP instead of HTTPS uit. Sla de instellingen op met Apply; OIDC ondersteunt deze onveilige HTTP-modus niet.

Gebruikers laten het Captive Portal-venster open om zich expliciet af te melden. Inactiviteit of het sluiten van een tabblad beëindigt de Google SSO-sessie hier niet zoals bij andere portalmethoden. Na het afmelden blijft de Google-afmeldpagina zichtbaar. Credential login met gebruikersnaam en wachtwoord is geen vervanging voor deze tokengebaseerde Google OIDC-procedure.

Aanmelding en rechten valideren

Bij de validatie worden verbinding, identiteit en autorisatie afzonderlijk beoordeeld. Alle tests worden vastgelegd met tijdstip, account, dienst, clientversie en verwacht resultaat, zonder secrets of tokens te registreren.

Rond Test connection en een gerichte groepsimport succesvol af. Open daarna een privébrowservenster via de beoogde FQDN.
Meld een pilotbeheerder aan via Google en controleer de verwachte MFA-vereiste. Onder Authentication > Users moeten identiteit, beheerdersstatus en toegewezen profiel correct zijn.
Controleer met een positieve test de benodigde menu’s en met een negatieve test een geblokkeerd onderdeel. Een alleen-lezenaccount mag geen wijziging kunnen opslaan. Een gewoon VPN-account mag zich niet kunnen aanmelden bij WebAdmin.
Controleer een account waarvoor meerdere toewijzingsregels overeenkomen. Het profiel moet behoren bij de gedocumenteerde eerste overeenkomende regel, niet bij de vermeend sterkste rol.
Meld je afzonderlijk aan bij het VPN Portal en bouw met de opnieuw geïmporteerde Sophos Connect-configuratie een IPsec- of SSL VPN-tunnel op. Een goedgekeurde interne resource moet bereikbaar zijn; een niet-toegestane resource moet geblokkeerd blijven.
Meld je af en controleer opnieuw met een nieuwe sessie. Google-aanmelding, portaltoegang en VPN-tunnel zijn afzonderlijke succescriteria.
Correleer in Log viewer > Admin de WebAdmin-gebeurtenissen en in Log viewer > Authentication de Captive Portal-, VPN Portal-, IPsec- en SSL VPN-aanmeldingen. Voor verdere analyse is in de Advanced Shell oauth_sso_svc.log beschikbaar; debug- of herstartopdrachten zijn hiervoor geen vereiste.
Controleer de onafhankelijke lokale hersteltoegang opnieuw voordat meer gebruikers worden gemigreerd.

Beheerdersaccounts worden alleen aangemaakt of bijgewerkt bij een succesvolle WebAdmin-aanmelding. Een VPN- of Captive Portal-aanmelding synchroniseert geen beheerdersrol. Wijzigingen in Google-rollen worden daarom gevalideerd met een nieuwe WebAdmin-aanmelding, niet op basis van een succesvolle tunnel.

Fouten gericht afbakenen

Google meldt redirect_uri_mismatch

Vergelijk de betreffende volledige URL uit Show URLs met Authorized redirect URIs van de daadwerkelijk gebruikte OAuth-client: schema, FQDN, poort en pad moeten exact overeenkomen. Controleer daarna of de browser dezelfde hostnaam gebruikt en of de automatische portaldoorverwijzing naar deze naam verwijst. Test na de correctie een nieuwe aanmelding; wildcardredirects noch een overstap naar een IP-adres zijn de oplossing.

Test connection of groepsimport mislukt

Controleer eerst de systeemtijd en de netwerkverbinding. Controleer daarna Admin SDK API, een geldig JSON-sleutelbestand, het juiste gedelegeerde Super Admin-account en Domain-wide delegation met de numerieke serviceaccount-ID en de vereiste scopes. Controleer bij ontbrekende groepen daarnaast het importfilter Display name/Mail. Een fout wordt niet opgelost door algemene Cloud Owner-rechten of extra schrijfscopes toe te kennen.

Google-aanmelding werkt, WebAdmin weigert toegang

Controleer het groepslidmaatschap of de roltoewijzing bij Google, IdP authentication for firewall administrators, de exacte IdP value, de volgorde van de toewijzingsregels en het lokale Device access profile. Voer daarna een nieuwe WebAdmin-aanmelding uit en controleer Log viewer > Admin. Een eerdere VPN-aanmelding bewijst noch de toewijzing, noch dat de beheerder is bijgewerkt.

Portal werkt, tunnel of interne resource niet

Controleer de Windows- en Sophos Connect-versie, het opnieuw geïmporteerde configuratiebestand, de bereikbaarheid van het VPN Portal en de servertoewijzing per dienst. Controleer daarna het groepslidmaatschap in de VPN-beleidsregels en de regels voor de doelresource. Log viewer > Authentication toont de aanmelding; een succesvolle authenticatieregistratie alleen bewijst niet dat dataverkeer is toegestaan.

Context-Aware Access of opnieuw aanmelden werkt anders dan verwacht

Apparaatgebaseerde Google CAA-voorwaarden vereisen een ondersteunde browserprocedure en daadwerkelijk beschikbare gegevens voor endpointverificatie. Voor de beschreven testprocedure wordt Google Chrome met Endpoint Verification gebruikt. Een succesvolle Sophos Connect-aanmelding wordt niet beschouwd als bewijs dat elke apparaatgebaseerde CAA-voorwaarde is geëvalueerd.

CAA wordt geëvalueerd bij de authenticatie en beëindigt geen reeds actieve firewallsessie. Ook het herauthenticatie-interval van Google dwingt geen nieuwe aanmelding af voor een actieve VPN-sessie op de firewall. Controleer een nieuwe authenticatie na gecontroleerd afmelden of verbreken van de verbinding; bestaande sessies moeten bij offboarding afzonderlijk worden afgehandeld.

Beheer, offboarding en terugvalprocedure

Een wijziging aan groepen of rollen wordt gecontroleerd met een nieuwe aanmelding en positieve en negatieve tests. Bij het intrekken van iemands beheerdersrechten is alleen het wijzigen van de Google-rol niet voldoende: SFOS zet een bestaand beheerdersaccount niet automatisch terug naar een gewoon gebruikersaccount. Na controle van de afhankelijkheden en met een andere werkende beheerder moet het betreffende beheerdersaccount op de firewall worden verwijderd. Bij de volgende gewone aanmelding kan de firewall de gebruiker opnieuw aanmaken. Actieve WebAdmin- en VPN-sessies worden afzonderlijk gecontroleerd en beëindigd; het intrekken van groepslidmaatschap is geen bewezen onmiddellijke intrekking van sessies.

Voor het OAuth-secret en de serviceaccountsleutel worden een eigenaar, veilige opslag, beoordeling en rotatie vastgelegd. Bij een geplande rotatie blijft de oude sleutel alleen beschikbaar zolang de gedocumenteerde terugvalprocedure dit vereist. De nieuwe inloggegevens worden eerst gecontroleerd met Test connection, het ophalen van groepen en een nieuwe aanmelding, voordat oude inloggegevens worden ingetrokken. Bij compromittering wordt daarentegen het eigen incidentproces gevolgd; de geldigheid wordt niet verlengd ten gunste van een gemakkelijke rollback.

Bij een mislukte pilot worden vanuit de open sessie met volledige beheerdersrechten of via de lokale hersteltoegang de exact genoteerde eerdere diensttoewijzing en servervolgorde hersteld. Ook gewijzigde portalhostnamen, Device Access, groeps-/VPN-beleidsregels en beheerderstoewijzingen worden teruggezet naar hun respectieve eerdere toestand. Test daarna de lokale beheerdersaanmelding en de bestaande VPN-route in nieuwe sessies.

Vergelijk daarnaast via de onafhankelijk beschikbare toegang met volledige beheerdersrechten elk betrokken account onder Authentication > Users met de inventarisatie per account. Herstel bij bestaande accounts expliciet het eerdere User type, het toegewezen Profile en de accountstatus. Als het account hiervoor moet worden verwijderd en opnieuw aangemaakt, controleer dan eerst alle afhankelijkheden en stel de bestaande toewijzingen veilig. Verwijder beheerders- en gebruikersobjecten die uitsluitend tijdens de pilot zijn aangemaakt pas nadat hun afhankelijkheden van groepen, VPN, beleidsregels en andere onderdelen zijn gecontroleerd. Het terugzetten van een servertoewijzing of het verwijderen van een Google-rol vervangt dit accountherstel en deze opschoning niet en beëindigt geen bestaande sessie. Actieve WebAdmin-, portal- en VPN-sessies worden daarom afzonderlijk gecontroleerd en beëindigd. Toon tot slot in nieuwe sessies aan dat de eerdere lokale beheerderstoegang en VPN-toegang werken en dat een pilotidentiteit die niet meer bevoegd is, wordt geweigerd. Controleer bij herstelde bestaande accounts dat de oorspronkelijke rechten behouden zijn en dat de uitsluitend tijdens de pilot toegekende aanvullende rechten worden geweigerd.

Pas wanneer de terugvalprocedure werkt en er geen andere diensten van afhankelijk zijn, worden de uitsluitend voor de pilot aangemaakte redirect-URI’s, delegatietoestemmingen en inloggegevens gecontroleerd verwijderd. Gedeelde clients of serviceaccounts worden niet verwijderd zonder de afhankelijkheden te controleren. Een volledige configuratieback-up wordt alleen teruggezet binnen het goedgekeurde herstelvenster, omdat dit ook losstaande firewallwijzigingen kan terugdraaien.