TL;DR – Samenvatting
"E-mailcontinuïteit" betekent voor iedereen iets anders. Vroeger was het niet iets waar de meeste organisaties slapeloze nachten van hadden. Als je jaren geleden een Exchange- of Microsoft 365-beheerder had gevraagd, zou die je hebben verteld dat e-mailstoringen vanzelf weer verdwenen, en daar had hij gelijk in. De infrastructuur van Microsoft is echt goed, SMTP zet e-mails in de wachtrij en de meeste storingen zijn van korte duur.
Dat is niet langer het volledige beeld. Zelfs als de stroomonderbrekingen niet lang duren, is de vraag niet langer alleen:
“Komt de e-mail er uiteindelijk wel?”
In plaats daarvan is het nu:
“Kan de organisatie blijven functioneren als er geen e-mail is?”
Elke storing in Microsoft 365 leidt tot productiviteitsverlies, vertragingen in de communicatie en gemiste zakelijke kansen, en dit effect is vooral merkbaar in grote organisaties.
Daarnaast zijn er nalevingskaders zoals NIS2, DORAen SOC 2 versterken deze verschuiving naar bedrijfscontinuïteit. Dergelijke kaders maken deel uit van een bredere trend in de regelgeving die organisaties ertoe aanzet verder te gaan dan alleen back-up en herstel, en zich te richten op het handhaven van de operationele capaciteit tijdens storingen, cyberincidenten en dienstonderbrekingen.
Wil je meteen weten hoe Google Workspace, in combinatie met Microsoft 365, de bedrijfscontinuïteit kan waarborgen?
Back-ups beschermen gegevens. E-mailcontinuïteit ondersteunt de operationele veerkracht.
Als je aan een back-upoplossing voor Microsoft 365 denkt, zou je je normaal gesproken zorgen maken over het herstellen van gegevens na een incident.
Oplossingen voor e-mailcontinuïteit zijn daarentegen bedoeld om de communicatie, agenda’s en samenwerking draaiende te houden tijdens het incident.
Dat onderscheid is van belang bij:
- Storingen in Microsoft 365,
- uitsluitingen van huurders,
- gevallen van ransomware,
- identiteitsproblemen,
- of cyberaanvallen.
De echte vraag is:
Hoe kunnen gebruikers hun werkzaamheden voortzetten terwijl de primaire omgeving niet beschikbaar is?
Dit is ook waar twee maatstaven, waar elk gesprek over BCP/DR uiteindelijk op uitkomt, van pas komen: RTO en RPO.
In een traditionele discussie over back-ups wordt RTO doorgaans gemeten als de tijd die nodig is om het getroffen systeem of de getroffen gegevens te herstellen, terwijl RPO de ouderdom van het herstelpunt weergeeft (met andere woorden: hoeveel recente gegevens er mogelijk ontbreken).
In een discussie over e-mailcontinuïteit worden vaak dezelfde maatstaven gehanteerd op het niveau van de bedrijfsfunctie: bij RTO gaat het om de vraag hoe lang de organisatie kan wachten voordat gebruikers weer kunnen communiceren, en bij RPO gaat het om de vraag hoe actueel de stand-by-communicatieomgeving moet zijn.
Dat onderscheid is van belang voor NIS2, DORA, SOC 2 en soortgelijke discussies over veerkracht en naleving, omdat het erom gaat of de bedrijfsfunctie tijdens de verstoring kan blijven functioneren.
Een vergelijking van de benaderingen voor e-mailcontinuïteit in Microsoft 365
Zodra de eis verandert in “ervoor zorgen dat mensen met elkaar blijven communiceren tijdens de verstoring,” de architecturale vraagstukken voor IT worden dan veel interessanter.
Is een eenvoudige noodpostbusdienst voldoende? Moeten we rekening houden met verschillende regio’s? Moeten we onze eigen infrastructuur ter plaatse gebruiken?
Er zijn verschillende benaderingen en afwegingen waarmee rekening moet worden gehouden om het niveau van bedrijfscontinuïteit te bereiken dat de onderneming daadwerkelijk nodig heeft. In de onderstaande tabel worden de belangrijkste benaderingen met elkaar vergeleken; deze zullen we hieronder nader toelichten.
| Aanpak | Hoofdgedachte | Voorbeelden van tools en leveranciers | Sterke punten | Veelvoorkomende zorgen |
|---|---|---|---|---|
| Cloudgebaseerde continuïteitsdiensten | Noodcontinuïteitsplatform dat door een derde partij wordt gehost | Mimecast, Retarus, Trend Micro | Snelle inzet Lagere operationele kosten |
Beperkte continuïteit na afloop van de noodwebmail |
| Tweede Microsoft 365-tenant | Aparte Microsoft 365-omgeving die is voorbereid op failover | Microsoft 365 | Het vertrouwde Microsoft-ecosysteem Cloud-native architectuur |
Afhankelijkheid van een ecosysteem van één leverancier, concentratierisico |
| Exchange-server op locatie | Onafhankelijke Exchange-omgeving, gesynchroniseerd met Microsoft 365 | Microsoft, CB Exchange Server Sync | Operationele onafhankelijkheid en zeggenschap Een vertrouwd Microsoft-ecosysteem voor eindgebruikers |
Aanvullende infrastructuur en onderhoud |
| Google Workspace als hot standby | Een onafhankelijke Google Workspace-omgeving die is gesynchroniseerd met Microsoft 365 | Google Workspace-bedrijfscontinuïteit, CB Exchange Server Sync voor Google Workspace | Onafhankelijkheid van verschillende cloudomgevingen Kan worden uitgebreid naar SharePoint/ Google Drive |
Verschillende gebruikerservaring, identiteit en weergave |
Welk model het meest geschikt is, hangt af van het operationele risicoprofiel van de organisatie, de nalevingsverplichtingen en de tolerantie ten aanzien van uitval. Laten we elke optie eens nader bekijken.
Optie 1: Cloudgebaseerde diensten voor e-mailcontinuïteit
Dit is een van de traditionele benaderingen. Leveranciers zoals Mimecast, Retarus en Trend Micro bieden cloudgebaseerde continuïteitsplatforms aan die toegang tot e-mailboxen in noodgevallen, e-mailroutering en tijdelijke communicatiediensten mogelijk maken.
De voordelen zijn een snelle implementatie en lagere operationele kosten.
Bedrijfsteams vragen zich echter vaak af in hoeverre deze platforms daadwerkelijk operationele continuïteit bieden, afgezien van tijdelijke toegang tot webmail. Kunnen gebruikers nog steeds agenda’s op elkaar afstemmen, met gedeelde mailboxen werken en na het incident soepel terugkeren naar Microsoft 365?
Optie 2: Secundaire Microsoft 365-tenant
Sommige organisaties maken gebruik van een secundaire Microsoft 365-tenant voor failover, soms in een andere regio, om de kans op regionale dienstonderbrekingen te verkleinen.
Dit kan de veerkracht vergroten, vooral als de secundaire tenant is opgezet met afzonderlijke beheerfuncties, routering, toegangsbeleidsregels en herstelprocedures. Regio-overschrijdende implementatie neemt echter niet de bredere afhankelijkheid van het Microsoft-cloudecosysteem weg.
Er is ook nog een subtieler punt: als de secundaire tenant zich via dezelfde identiteitsprovider authentificeert als de productieomgeving (meestal dezelfde Entra ID-tenant), dan kan een incident of storing op het gebied van identiteitsbeheer beide omgevingen tegelijk treffen.
Optie 3: Exchange-server op locatie, gesynchroniseerd met Microsoft 365
Een derde aanpak is het onderhouden van een onafhankelijke Exchange-serveromgeving die gesynchroniseerd is met Microsoft 365.
Een voorbeeld hiervan is het gebruik van een Exchange-server op locatie, gesynchroniseerd met Microsoft 365.
In dit model:
- Microsoft 365 blijft het belangrijkste operationele platform,
- De Exchange-server is de onafhankelijke continuïteitsomgeving,
- CB Exchange Server Sync voor BCP via Connecting Software zorgt ervoor dat deze twee met elkaar worden gesynchroniseerd.
Synchronisatie kan het volgende omvatten:
- brievenbussen,
- kalenders,
- contacten,
- openbare mappen,
- distributiegroepen,
- en GAL-synchronisatie.
Omdat deze omgeving on-premises draait met een eigen Active Directory, hoeft deze geen identiteitslaag te delen met de Microsoft 365-tenant. Dat is een belangrijk verschil met optie 2: een op identiteit gebaseerde aanval op de cloudtenant breidt zich niet automatisch uit naar de on-premises Exchange-omgeving, wat direct van belang is voor de hierboven genoemde scenario’s van "identiteitsstoringen" en "tenant-lockout".
Omdat de oplossing on-premises wordt uitgevoerd, is dit ook de beste keuze als uw organisatie dit soort oplossing nodig heeft in een air-gapped netwerk. De on-premises-versie kan in combinatie met datadiodes worden gebruikt om dat scenario mogelijk te maken.
Waarom sommige organisaties de voorkeur geven aan deze architectuur
Voor organisaties met strengere eisen op het gebied van operationele veerkracht kan deze aanpak het volgende bieden:
- operationele onafhankelijkheid van Microsoft 365,
- de bekende Outlook en de continuïteit van de kalender,
- meer controle over de infrastructuur en failover,
- ondersteuning voor gereguleerde of geïsoleerde omgevingen,
- onafhankelijkheid van de productietentant,
- en een lager risico op wolkconcentratie.
Organisaties die ook gebruikmaken van SharePoint en documentsamenwerking, kunnen bovendien strategieën voor documentsynchronisatie implementeren met behulp van Secure Sync for SharePoint van Connecting Software, om SharePoint veilig te synchroniseren tussen onafhankelijke of geïsoleerde omgevingen.
Optie 4: Google Workspace als hot standby
Een vierde aanpak volgt dezelfde logica als optie 3, maar wisselt het stand-byplatform om: in plaats van een Exchange-server op locatie is de onafhankelijke omgeving Google Workspace, die via […] continu gesynchroniseerd blijft met Microsoft 365. .
Dit biedt organisaties een cloudoverschrijdende failover-optie waarbij ze helemaal niet afhankelijk zijn van het Microsoft-ecosysteem. Dit kan van belang zijn in verband met concentratierisico’s en is ook populair bij organisaties die al delen van hun activiteiten via Google Workspace uitvoeren. Zelfs bij organisaties die dat niet doen, zijn gebruikers vaak uit eigen ervaring bekend met Google Workspace, wat van pas komt tijdens een failover.
In een volgend artikel zullen we deze architectuur, het identiteitsmodel ervan en de specifieke afwegingen die daarbij een rol spelen nader toelichten.
Ontdek hoe je met Google Workspace een hot standby kunt realiseren voor bedrijfscontinuïteit door Connecting Software
Failover: het herstelvenster verwijderen
Bij de traditionele aanpak van back-ups en herstel moest er bij een storing nog steeds iemand een herstelbewerking uitvoeren voordat iedereen weer aan het werk kon.
Dat brengt twee problemen met zich mee: de handmatige tussenkomst die nodig is en de tijd die het herstel in beslag neemt, die evenredig is aan de hoeveelheid gegevens die moet worden hersteld. Bij grote tenants is het niet ongebruikelijk dat de RTO’s in dagen worden gemeten.
Cloudgebaseerde diensten voor e-mailcontinuïteit bieden hiervoor een tijdelijke oplossing, maar hebben beperkte mogelijkheden.
Een gesynchroniseerde stand-byomgeving maakt die stap overbodig. Omdat je beschikt over een voortdurend bijgewerkte kopie van mailboxen, agenda’s en uiteindelijk ook documenten, kun je gebruikers gewoon naar die omgeving doorverwijzen, waarna ze gewoon verder kunnen werken. Het is een failover zonder herstelvenster. De omgeving is direct inzetbaar en actueel, waardoor het herstelvenster niet meer hoeft te worden meegenomen in de RTO-berekening.
U zult die kosten moeten afwegen tegen de kosten die ontstaan doordat uw gebruikers geen toegang hebben tot e-mail, agenda’s en andere inhoud van hun mailbox, in termen van productiviteitsverlies, misgelopen deals en eventuele nalevingskosten.
Failback: handmatige afstemming vermijden
Failover is slechts het halve verhaal. Op een gegeven moment komt de primaire omgeving weer online en moeten gebruikers terugkeren naar die omgeving. Dit is de failback-fase, waarin de echte vraag is wat er gebeurt met de e-mails die zijn verzonden en ontvangen, de wijzigingen in de agenda en de bewerkingen aan documenten die in de stand-by-omgeving zijn uitgevoerd, zonder dat er gegevens verloren gaan of duplicaten ontstaan.
Moeten nieuwe e-mails, wijzigingen in de agenda en bewerkte documenten handmatig weer in de productomgeving worden verwerkt? Dit is voor niemand een leuke klus, want het is precies het soort handmatige stap dat fouten, verwarring over versies en vertragingen veroorzaakt.
Bij bidirectionele synchronisatie gebeurt die afstemming automatisch: wijzigingen die tijdens de storing zijn aangebracht, worden zonder tussenkomst van IT teruggestuurd naar Microsoft 365 zodra de primaire omgeving is hersteld. De enige gegevens die risico lopen, zijn de wijzigingen die zijn aangebracht binnen het meest recente synchronisatie-interval, oftewel de tijd tussen twee opeenvolgende synchronisatierondes. Als het interval vijf minuten bedraagt, is de praktische RPO ongeveer vijf minuten aan wijzigingen, en niet de volledige duur van de storing. U kunt het terugschakelen afstemmen op uw synchronisatie-interval om de RPO tot nul te reduceren
Het is goed om te weten dat er een afweging moet worden gemaakt met betrekking tot het polling-interval: door het te verkorten daalt de RPO, maar ; door het te verlengen neemt de overhead af, maar wordt de periode waarin gegevensverlies kan optreden groter.
Er bestaat niet één “juiste” e-mailarchitectuur.
De juiste oplossing hangt af van:
- operationele afhankelijkheid van Microsoft 365,
- aanvaardbare stilstandtijd,
- wettelijke voorschriften,
- interne IT-capaciteiten,
- en doelstellingen op het gebied van operationele veerkracht.
Organisaties met bescheiden behoeften kunnen volkomen tevreden zijn met cloudgebaseerde continuïteitsdiensten.
Organisaties die onder NIS2 of DORA vallen, of die aan strenge veerkrachtvereisten moeten voldoen, hebben mogelijk behoefte aan grotere operationele onafhankelijkheid en betere failover-mogelijkheden.
Laatste gedachten
Microsoft 365 biedt een uitstekende beschikbaarheid.
Maar beschikbaarheid alleen is geen garantie voor operationele veerkracht.
Organisaties beseffen steeds meer dat de continuïteit van e-mail, agenda’s en samenwerking van essentieel belang is om de bedrijfsvoering tijdens verstoringen op peil te houden.
Want tijdens een echte stroomstoring is de belangrijkste vraag niet:
“Kunnen we het later inhalen?”
Het is:
"Kunnen we doorgaan met onze activiteiten?"
Ontdek hoe je met Google Workspace een hot standby kunt realiseren voor bedrijfscontinuïteit door Connecting Software
Meer informatie over bedrijfscontinuïteit en noodherstel
Over de auteur
Door Ana Neto, technisch adviseur op Connecting Software.
"Ik ben software engineer sinds 1997, met een recentere liefde voor schrijven en spreken in het openbaar. Heb je vragen of opmerkingen over dit artikel? Ik zou graag je feedback horen, laat hieronder een reactie achter!"
