Google Workspace als optie voor bedrijfscontinuïteit bij storingen in Microsoft 365

Als Microsoft 365 uitvalt, is de eerste vraag die dan opkomt: hoe kunnen we ervoor zorgen dat iedereen weer aan het werk kan? Dat is een praktisch probleem op het gebied van bedrijfscontinuïteit, en Google Workspace kan daar een praktische oplossing voor bieden.

Voor de meeste bedrijven vormt Microsoft 365 de infrastructuur die de communicatie, de coördinatie en het bedrijf zelf draaiende houdt. Bij een storing in Microsoft 365 stromen de vragen binnen:

Kunnen mensen e-mails versturen en ontvangen?

Kunnen ze hun agenda's zien?

Heeft het management nog steeds toegang tot e-mail en agenda om de crisisaanpak te coördineren?

Kunnen teams die in contact staan met klanten nog steeds extern communiceren?

Hebben teamleden toegang tot de bestanden? Of moeten ze eerst wachten tot een back-up is teruggezet?

Deze vragen zijn nu belangrijker dan ooit, nu de regelgeving de lat voor operationele veerkracht en bedrijfscontinuïteit hoger legt.

Of je nu bezig bent met SOC 2 beschikbaarheidscontroles, navigeren NIS2 voorschriften inzake operationele veerkracht, of het afstemmen op kaders zoals NIST CSF 2.0 en ISO 22301, moet de afhankelijkheid van Microsoft 365 expliciet worden beoordeeld. Als strategie voor bedrijfscontinuïteit is het steeds minder verdedigbaar om uitsluitend te vertrouwen op de beschikbaarheid van Microsoft.

Dit heeft ertoe geleid dat technische teams steeds vaker naar ‘hot standby’-opties kijken, met name Google Workspace. Niet als vervanging voor Microsoft 365, en niet als traditionele back-uptool, maar als een tweede, onafhankelijke cloudomgeving die ervoor zorgt dat e-mail, agenda’s, bestanden en cruciale communicatie beschikbaar blijven tijdens een storing in Microsoft 365.

Dit is een totaal andere aanpak dan het gebruik van een back-upplatform voor Microsoft 365, zoals Veeam, Druva of een andere hersteloplossing, waarmee mailboxen, bestanden en andere gegevens na een incident kunnen worden hersteld. Hoe goed die platforms ook mogen zijn: als duizenden gebruikers binnen twee uur weer toegang moeten hebben tot hun inbox en agenda, volstaat een back-up alleen niet.

Google Workspace kan inderdaad de bedrijfscontinuïteit waarborgen tijdens een storing in Microsoft 365, met name voor e-mail, agenda’s, afspraken en crisiscommunicatie. Microsoft 365 blijft het primaire platform, terwijl Google Workspace een onafhankelijke continuïteitsomgeving biedt. Maar voor dit soort cross-cloud bedrijfscontinuïteitsmodel zijn de juiste architectuur en planning vereist: identiteit, e-mailroutering, synchronisatie, beveiliging, gebruikerstoegang en failback moeten allemaal worden ontworpen en getest voordat de storing zich voordoet, niet tijdens de storing.

Regelgeving en kaders zoals NIS2, DORA en het NIST Cybersecurity Framework leggen de lat hoger voor het voorkomen en beheersen van verstoringen van essentiële diensten en kritieke of belangrijke functies, hoewel hun toepassingsgebied, terminologie en juridische werking verschillen.

DORA definieert een “kritieke of belangrijke functie” aan de hand van de wezenlijke gevolgen die een verstoring ervan zou kunnen hebben voor de financiële prestaties, de continuïteit van de dienstverlening of wettelijke verplichtingen, terwijl NIS2 vereist maatregelen op het gebied van bedrijfscontinuïteit en crisisbeheer als onderdeel van het risicobeheer op het gebied van cyberbeveiliging. Daarnaast zijn er kaders zoals NIST-CDF resultaten op dit gebied aanpakken via de functies ‘Govern’, ‘Respond’ en ‘Recover’, waaronder incidentrespons, herstel en communicatie.

Ook al zijn de gebruikte termen niet consistent, blijft de praktische vraag:

Welke diensten en afhankelijkheden zijn cruciaal binnen uw organisatie?

Een praktische manier om hoogwaardige wettelijke vereisten om te zetten in continuïteitsplanning is het uitvoeren van een beoordeling van kritieke functies tegen grote afhankelijkheid van de cloud. De kernvraag is simpel:

Als deze clouddienst X uur lang niet beschikbaar is, overschrijden we dan een drempel op juridisch, operationeel, klantenservice-, veiligheids- of financieel gebied?

Voor Microsoft 365 moet die beoordeling het volgende omvatten:

• RTO en RPO: hoe snel de diensten weer moeten worden hervat, en hoeveel gegevensverlies aanvaardbaar is
• Explosieradius: welke functies, teams, klanten of processen hierdoor worden beïnvloed
• Concentratierisico: in hoeverre dit afhangt van een bepaalde aanbieder, huurder, regio of identiteitslaag
• Onderlinge afhankelijkheden: identiteit, sleutelbeheer, netwerktoegang, integraties en externe communicatiekanalen

Als je Microsoft 365 vanuit dat perspectief bekijkt, is het resultaat zelden geruststellend. E-mail, identiteitsbeheer, agenda’s en bestandstoegang blijken vaak operationele afhankelijkheden te zijn die een expliciete continuïteitsplanning vereisen, en niet alleen back-ups en herstelprocedures.

Regelgeving en normen schrijven geen specifieke continuïteitsarchitectuur of bepaalde leveranciers voor. Toch kunnen de eisen die daarin worden gesteld een directe invloed hebben op het ontwerp ervan:

• ISO 22301 dringt aan op duidelijk omschreven hersteldoelstellingen, gedocumenteerde procedures voor bedrijfscontinuïteit en regelmatige tests. Wanneer de mogelijke gevolgen voor de bedrijfsvoering dit rechtvaardigen, kan een ‘hot standby’-oplossing voor Microsoft 365 aangewezen zijn.
• Als uw organisatie een financiële instelling is, DORA vereist dat u het concentratierisico op het gebied van informatie- en communicatietechnologie (ICT) en de vervangbaarheid van leveranciers beoordeelt. Daarnaast zijn gedocumenteerde uitstapstrategieën vereist voor ICT-diensten die kritieke of belangrijke functies ondersteunen. Afhankelijk van de risicobeoordeling kan dit pleiten voor een ontwerp met alternatieve leveranciers of meerdere leveranciers, maar DORA schrijft geen specifieke architectuur voor.
• NIS2 past dezelfde logica toe op een bredere reeks essentiële en belangrijke entiteiten en neemt bedrijfscontinuïteit, noodherstel, crisisbeheer en de beveiliging van de toeleveringsketen expliciet op in haar maatregelen voor cyberbeveiligingsrisicobeheer. Hierdoor worden grote afhankelijkheden van cloud- en serviceproviders relevant voor de risicobeoordeling van de organisatie.
• In de VS zijn de functies ‘Govern’, ‘Respond’ en ‘Recover’ van NIST CSF 2.0 roepen op tot beproefde herstelplannen en risicobeheer in de toeleveringsketen, wat dezelfde vraag oproept: kunnen kritieke functies blijven draaien als een belangrijke leverancier uitvalt?

De architecturale vraag is hoe ervoor gezorgd kan worden dat kritieke functies blijven draaien wanneer de primaire provider niet beschikbaar is. Als een storing in Microsoft 365 deze functies kan onderbreken, heeft de organisatie wellicht een alternatieve omgeving nodig die al is ingericht, toegankelijk is en getest is. Dat risico is vaak groter dan het op het eerste gezicht lijkt, omdat Microsoft 365 niet uit één enkele afhankelijkheid bestaat, maar uit meerdere onderling verbonden afhankelijkheden.

Microsoft 365 brengt vier zaken samen die, afzonderlijk beschouwd, elk op zichzelf al een continuïteitsplan zouden rechtvaardigen:

• Communicatie (Exchange / Teams). Als de e-mailroutering of de chat uitvalt, komt het bedrijf in de praktijk stil te liggen, ook al zijn alle bestanden technisch gezien veilig.
• Kalender (Exchange / Teams). De planning en de toegang tot vergaderingen verlopen op dezelfde manier als bij e-mail, wat leidt tot een gebrek aan interne afstemming en gemiste externe vergaderingen, ook al is er technisch gezien niets "kwijtgeraakt"."
• Documenten (SharePoint / OneDrive). Bestanden moeten toegankelijk blijven, niet alleen herstelbaar zijn.
• Identiteit (Entra ID / Azure AD). Als de authenticatielaag uitvalt, maakt het niet uit of de rest nog wel werkt: niemand kan zich nog ergens aanmelden, ook niet bij apps van derden die gebruikmaken van dezelfde identiteitsprovider.

De verontrustende conclusie in dit stadium is meestal dat standaard back-upsoftware alleen het derde punt beschermt, en dan nog pas na een herstelperiode die 24 tot 48 uur kan duren. Er is in de tussentijd geen alternatieve plek waar mensen daadwerkelijk kunnen werken.

De oplossing die hier als eerste in je opkomt, is wellicht een tweede Microsoft-tenant. Helaas houdt deze oplossing geen stand bij nader inzien, omdat een storing beide tenants tegelijkertijd buiten werking zou kunnen stellen, zelfs als ze in verschillende Microsoft 365- of Azure-regio’s zijn ondergebracht. Regionale hosting betekent niet dat er sprake is van onafhankelijke storingsdomeinen, aangezien Entra ID en de kernservices van Microsoft 365 onderliggend nog steeds dezelfde wereldwijde infrastructuur delen.

Een tweede huurder voldoet op papier aan de eis "we hebben een reservehuurder", maar biedt onvoldoende onafhankelijkheid.

Dat is de reden waarom de zoektocht zich richt op een afzonderlijke hyperscaler. Niet omdat Google Workspace op zich betrouwbaarder is, maar omdat het een operationeel gescheiden infrastructuur en identiteitsstack biedt. Die scheiding kan helpen bij het aanpakken van de risico’s van ICT-concentratie en zorgen over bedrijfscontinuïteit, zoals die tot uiting komen in DORA en NIS2.