Office 365 back-up: retentie is geen back-up
"Het staat in Microsoft 365, dus het is geback-upt." Die ene aanname zorgt bij Nederlandse MKB'ers voor meer permanent dataverlies dan ransomware. Microsoft draait een van de meest betrouwbare cloudplatformen ter wereld, maar betrouwbaarheid en back-up zijn twee verschillende garanties, en slechts een daarvan is Microsofts taak.
Het gedeelde-verantwoordelijkheidsmodel, in gewone taal
Microsofts eigen Shared Responsibility Model trekt een duidelijke lijn tussen wat Microsoft doet en wat u doet. Microsoft is verantwoordelijk voor het platform: Exchange Online, SharePoint, OneDrive en Teams draaiende, gepatcht en beschikbaar houden, dag en nacht. U bent verantwoordelijk voor de data daarin: wat er gebeurt met een e-mail nadat die is verwijderd, wat er gebeurt met een bestand nadat een medewerker uit dienst gaat, wat er gebeurt nadat ransomware een gesynchroniseerde OneDrive-map versleutelt. Microsoft schrijft zelf expliciet dat klanten bovenop de ingebouwde retentiefuncties een eigen dataprotectiestrategie nodig hebben. Die ene zin is de reden dat dit artikel bestaat, en de reden dat veel MKB'ers het gat pas ontdekken nadat ze iets kwijt zijn dat ze terug nodig hadden.
Waarom dit zoveel MKB'ers verrast
De meeste MKB'ers die overstapten van een eigen Exchange-server of fileserver hadden back-up als een zichtbare, aparte post: een NAS in een kast, een bandwissel, een contract met een back-upleverancier. De overstap naar Microsoft 365 haalde die zichtbare infrastructuur weg, en daarmee ook de zichtbare herinnering dat back-up iets is dat u zelf moet regelen. Er is niets onzorgvuldigs aan de migratie zelf; het onderwerp komt simpelweg niet meer vanzelf ter sprake in IT-planningsgesprekken, omdat Microsoft 365 aanvoelt als iets dat voor zichzelf zorgt. Dat klopt voor uptime. Dat klopt niet voor uw data.
Wat "native retentie" u echt geeft
Office 365 wordt geleverd met prullenbakken, versiegeschiedenis en retentie- of compliancebeleid. Die zijn echt nuttig, en echt geen back-up:
- Ze beschermen tegen kleine, recente vergissingen. Iemand verwijdert een e-mail of overschrijft een bestand een uur geleden; daar zijn ze precies voor gebouwd. Niet voor systematisch, vertraagd of grootschalig verlies.
- Ze zijn configureerbaar, en dus ook uit te zetten. Een beheerder, of een aanvaller die een beheeraccount heeft overgenomen, kan een retentiebeleid vanuit dezelfde tenant die het moet beschermen, verkorten of uitschakelen. Een back-up die buiten de tenant staat, onder aparte inloggegevens, is op die manier niet te bereiken.
- Ze zijn niet gebouwd voor point-in-time-herstel. "De hele SharePoint-site terugzetten zoals die er afgelopen dinsdag uitzag" is niet waar versiegeschiedenis of een prullenbak voor is bedoeld; ze herstellen losse items, geen consistente momentopname van een omgeving.
- Ze volgen het item, niet de hele omgeving. Retentiebeleid werkt per postvak, per site, per beleid. Reconstrueren hoe de postbus en OneDrive van een vertrekkende medewerker er samen op een bepaalde datum uitzagen, is niet waar het voor bedoeld is.
Waar het in de praktijk misgaat
Een handvol scenario's is verantwoordelijk voor het merendeel van de Microsoft 365-dataverlies-incidenten die we in de praktijk zien.
| Scenario | Wat native retentie doet | Wat het mist |
|---|---|---|
| Een medewerker vertrekt en IT verwijdert het account | Postvak of OneDrive blijft mogelijk kort bewaard, en wordt daarna definitief verwijderd | Geen eenvoudige manier om maanden later selectief alleen de bestanden terug te halen die een manager nodig heeft |
| Ransomware versleutelt gesynchroniseerde OneDrive- of SharePoint-bestanden | Versiegeschiedenis kan helpen, als die niet was uitgeschakeld of al is uitgeput | Grootschalige versleuteling kan de versielimieten inhalen, en synchronisatie kan de schade verder verspreiden |
| Een beheeraccount wordt overgenomen | De aanvaller erft dezelfde rechten als uw IT-beheerder, inclusief het kunnen wijzigen van retentie-instellingen | Het vangnet dat u beschermt, valt binnen dezelfde blast radius als de aanval |
| Onbedoelde bulkverwijdering tijdens een migratie, script of "opschoning" | De prullenbak vangt losse, recente verwijderingen op | Bulkverwijdering of late ontdekking valt vaak buiten dat venster |
| Een juridische bewaarplicht of langetermijn-complianceverplichting | Retentiebeleid kan data vasthouden | Het wijzigen ervan vergt nog altijd dezelfde beheertoegang die onder de loep zou moeten liggen |
Het patroon herhaalt zich in elke rij: het vangnet en de dreiging waartegen het moet beschermen, leven in hetzelfde systeem, beheerd met dezelfde inloggegevens.
Wat een echte Microsoft 365 back-up toevoegt
Een specifieke back-upoplossing voor Microsoft 365, met dekking van Exchange Online, SharePoint, OneDrive en Teams, dicht precies dat gat:
- Een kopie die buiten de tenant staat, zodat een overgenomen beheeraccount of een ransomware-incident binnen Microsoft 365 er niet bij kan, hem niet kan verwijderen of versleutelen.
- Retentie die u zelf regelt, onafhankelijk van wat Microsofts standaardinstellingen of uw eigen IT-beheerder op dit moment toepassen.
- Granulair, point-in-time-herstel: een e-mail, een bestand, een Teams-kanaal of een volledig postvak precies zoals het op een bepaalde datum was, in plaats van wat de prullenbak toevallig nog heeft.
- Dekking over alle werklasten, niet alleen mail. Teams-chatgeschiedenis en SharePoint-documentbibliotheken zijn de twee dingen die het vaakst worden vergeten wanneer een MKB ervan uitgaat dat "onze back-up Microsoft 365 dekt" zonder te checken wat er daadwerkelijk in zit.
Waar u op moet letten bij het kiezen
Niet elk product dat als "Microsoft 365 back-up" wordt verkocht, dekt hetzelfde. Controleer voordat u kiest:
- 1. Welke werklasten daadwerkelijk zijn inbegrepen. Exchange, OneDrive, SharePoint, Teams en Entra ID-objecten (Azure AD) zoals groepen, rechten en gedeelde postvakken worden vaak als aparte add-ons verkocht in plaats van standaard gebundeld.
- 2. Waar de back-updata wordt opgeslagen, en of die locatie voldoet aan uw verwachtingen rond dataresidentie onder de AVG.
- 3. Hoe herstel in de praktijk werkt. Kan een helpdeskmedewerker binnen enkele minuten een los bestand terugzetten, of vergt elk herstel een supportticket bij de leverancier?
- 4. De retentieduur, en of die vast is of aan te passen aan uw eigen complianceverplichtingen, die langer kunnen lopen dan Microsofts eigen standaardinstellingen.
- 5. Of restores daadwerkelijk worden getest. Een back-up die nooit is teruggezet, is een hoop, geen plan; exact dezelfde regel die geldt voor on-premises back-ups, geldt hier ook.
Wat het doorgaans kost
Een specifieke Microsoft 365-back-up wordt meestal per gebruiker, per maand gefactureerd, bovenop uw bestaande Microsoft 365-licentiekosten: een kleine, voorspelbare post in plaats van een project. Afgezet tegen de kosten van het definitief kwijtraken van een postvak tijdens een juridisch geschil, of het moeten uitleggen aan een klant waarom drie maanden gedeelde projectbestanden zijn verdwenen door ransomware, is het consistent een van de goedkoopste risicoreducerende maatregelen die een MKB aan zijn IT-budget kan toevoegen. Het is ook een van de snelst uit te rollen maatregelen: back-up toevoegen aan een bestaande tenant vergt geen downtime en geen verandering in hoe medewerkers al werken.
De uitrol in de praktijk
Back-up toevoegen aan een bestaande Microsoft 365-tenant is in de praktijk een kort project, geen migratie:
- 1. Inventariseer welke postvakken, sites en Teams dekking nodig hebben, en spreek retentieperiodes per datatype af met de business, niet alleen met IT.
- 2. Koppel de back-upoplossing aan de tenant via een dedicated service-account met alleen de rechten die het nodig heeft.
- 3. Draai de eerste back-up en controleer de dekking tegen de inventarisatie voordat u hem als productief beschouwt.
- 4. Plan en monitor de doorlopende back-ups, met meldingen die naar iemand gaan die daadwerkelijk actie onderneemt bij een storing.
- 5. Test een restore voordat u er echt een nodig heeft, en herhaal die test periodiek zodat u erop kunt blijven vertrouwen.
Veelgehoorde misvattingen, rechtgezet
"Microsoft back-upt alles automatisch." Microsoft back-upt zijn eigen infrastructuur voor zijn eigen disaster recovery; dat biedt het niet aan als dienst waarmee u zelf verwijderde of beschadigde data kunt terugzetten. Zie het gedeelte over gedeelde verantwoordelijkheid hierboven.
"Versiegeschiedenis is eigenlijk hetzelfde als back-up." Het beschermt tegen dezelfde categorie ongelukken als een back-up, maar niet tegen dezelfde reeks incidenten, en niet met onafhankelijke opslag of controle. Beide zijn nuttig; slechts een van de twee is een back-up.
"Wij zijn te klein om doelwit te zijn." Aanvallers richten zich juist op Microsoft 365-tenants omdat het platform veelvoorkomend is en op het gebied van back-up vaak onderbeschermd, ongeacht bedrijfsgrootte. Een kleine tenant is geen moeilijker doelwit; meestal juist een makkelijker.
"Onze IT-partner regelt dit al." Het loont om dit expliciet en schriftelijk te bevestigen in plaats van aan te nemen. "Wij beheren uw Microsoft 365-omgeving" betekent niet automatisch dat er een dedicated back-upproduct met onafhankelijke opslag draait; vraag specifiek wat er wordt geback-upt, waar, en voor hoe lang.
FAQ
Back-upt Microsoft mijn Office 365-data? Nee. Microsoft is verantwoordelijk voor het draaiende en beschikbaar houden van het platform. Uw data beschermen tegen verwijdering, ransomware of langetermijnverlies is uw verantwoordelijkheid onder Microsofts eigen Shared Responsibility Model.
Wat is het verschil tussen retentiebeleid en back-up? Retentiebeleid, zoals de prullenbak, versiegeschiedenis en compliance-holds, leeft binnen uw tenant en kan worden gewijzigd of uitgeschakeld door wie er beheertoegang heeft, inclusief een aanvaller die die toegang heeft overgenomen. Een back-up slaat een aparte kopie op buiten de tenant, onder onafhankelijke controle.
Wij gebruiken al OneDrive-synchronisatie en versiegeschiedenis; is dat niet genoeg? Het helpt bij kleine, recente, individuele vergissingen, maar is geen vervanging voor point-in-time-herstel van de hele tenant, en overleeft geen aanvaller die beheerinloggegevens overneemt of een grootschalige ransomware-aanval.
Wat gebeurt er met de postbus en OneDrive van een vertrokken medewerker als we die niet back-uppen? Afhankelijk van hoe het account wordt uitgeschreven, blijft de data mogelijk kort bewaard en wordt daarna definitief verwijderd, zonder eenvoudige manier om later alleen de bestanden terug te halen die een manager nodig heeft, tenzij die in een aparte back-up staan.
Is een Microsoft 365-back-up verplicht onder NIS2 of de AVG? Geen van beide kaders noemt een specifiek back-upproduct, maar beide verwachten dat organisaties passende, risicogebaseerde maatregelen nemen om data te beschermen en van incidenten te herstellen. Een dedicated back-up is een van de concreetste, aantoonbare manieren om dat te laten zien voor de data waar uw bedrijf dagelijks op draait.
Dicht het gat
Wilt u een helder beeld van wat er in uw Microsoft 365-omgeving daadwerkelijk beschermd is en wat niet? Onze Cloud & infrastructure dekt Microsoft 365-tenantbeheer en back-up, en combineert goed met onze Cybersecurity & identity als ransomware en accountovername onderdeel zijn van uw risicobeeld. Lees ook Ransomware voorkomen in het MKB voor hoe back-up past in een bredere verdediging.
