Herautorisatie is geen M365-herstelbewijs

Een back-updienst kan weer open zijn terwijl er sinds de onderbreking nog geen nieuwe herstelkopie bestaat. ConnectWise schreef dat op 30 oktober zelf. Ik vind daarom dat een Microsoft 365-back-up pas aantoonbaar herstelbaar is wanneer na herautorisatie een nieuwe snapshot slaagt én een beheerder die kopie kan terugzetten via een toegangspad dat niet afhankelijk is van dezelfde tenant- of MSP-beheerroute.

De laatst zichtbare update in het ConnectWise Trust Center meldde dat back-up en herstel beschikbaar waren voor opnieuw geautoriseerde Microsoft 365-tenants. ConnectWise waarschuwde dat herautorisatie op zichzelf niet bevestigt dat back-ups zijn hervat. ConnectWise vroeg partners om te controleren of nieuwe snapshots succesvol afronden en wees erop dat de snapshotgeschiedenis de onderbreking tussen het laatste oude en het eerste nieuwe herstelpunt laat zien.

Een M365-back-up is pas aantoonbaar herstelbaar wanneer na herautorisatie minstens één nieuwe snapshot succesvol is afgerond en een beheerder die kopie ook echt kan terugzetten. Die restore moet via een toegangspad werken dat niet afhankelijk is van dezelfde tenant- of MSP-beheerroute. Een dienstmelding of autorisatiescherm bewijst geen van beide.

Een geopende dienst is nog geen werkende back-up

De formulering van ConnectWise maakt een belangrijk onderscheid dat in veel dashboards wegvalt. Een dienst kan beschikbaar zijn, een tenant kan opnieuw zijn geautoriseerd en een oude archiefkopie kan bewaard zijn. Dat zijn drie verschillende feiten. Geen ervan zegt op zichzelf dat de volgende geplande kopie is voltooid.

Dat verschil is praktisch. Herautorisatie herstelt toestemming tussen de Microsoft 365-tenant en de back-upapplicatie. De stap vertelt de dienst dat zij opnieuw data mag ophalen. Zij bewijst niet dat de taak daarna werkelijk draaide, de verwachte workloads meenam en een bruikbaar herstelpunt opleverde. Daarvoor moet een nieuwe snapshot zichtbaar zijn als geslaagd, met een tijdstip dat na de herautorisatie ligt.

De onderbreking bij ConnectWise liet zien waarom dat geen administratief detail is. Toen de geplande taken stilvielen, konden nieuwe of gewijzigde gegevens buiten bestaande herstelpunten vallen, ook als de opgeslagen archieven volgens ConnectWise versleuteld en geïsoleerd bleven. Die twee uitspraken botsen niet. Een oude kopie kan intact zijn terwijl zij voor het bestand van gisteren al te oud is. Stel dat een organisatie heeft afgesproken dat klantmail maximaal 24 uur oud mag zijn bij herstel. Dat is in dit voorbeeld de eigen hersteldoelstelling, geen algemene norm. Als na herautorisatie alleen een oudere kopie bestaat, is de dienst bereikbaar maar voldoet het herstelpunt niet aan de afspraak. De kosten verschijnen dan als reconstructiewerk: medewerkers moeten klantvragen, open offertes en wijzigingen uit losse berichten en gesprekken opnieuw samenstellen. De precieze europrijs verschilt per bedrijf, maar het gat in de werkgeschiedenis is zichtbaar. De stilgevallen back-ups en het risico op een gat tussen herstelpunten maken dat verschil concreet.

Ik zou daarom een groene status nooit vertalen naar “de organisatie is weer beschermd”. Die status vertelt hoogstens dat een onderdeel van de dienst bereikbaar is. Een geslaagde snapshot vertelt dat er een nieuw herstelpunt is gemaakt. Zelfs dan weet je nog niet of je er iets uit kunt terugzetten. Herstelbaarheid is een keten van bewijzen, niet één statuslampje.

Een snapshot is nog geen terugzetting

Een snapshot laat zien dat data op een moment is vastgelegd. Een restore test iets anders: kan de beheerder het juiste herstelpunt vinden, kan de dienst de inhoud ontsleutelen en terugzetten, en komt die inhoud aan op een plek waar een gebruiker er iets mee kan? Een taak die als geslaagd staat, beantwoordt die vragen niet allemaal.

Neem dezelfde organisatie, met een gedeelde mailbox en een offerte die na een foutieve wijziging moet worden hersteld. De eerste nieuwe snapshot na herautorisatie kan netjes zijn afgerond, terwijl niemand ooit heeft gecontroleerd of de juiste versie van dat bericht terug te halen is binnen de afgesproken grens van 24 uur. Een kleine proefrestore naar een testmap of een afgesproken testlocatie laat zien of de hele route werkt zonder meteen een complete mailbox terug te zetten over actuele gegevens heen.

De proef is geen volledige rampenoefening en moet zich ook niet voordoen als bewijs voor iedere workload. Hij maakt wel zichtbaar waar de verbinding tussen kopie en gebruik breekt. Een hersteld bericht dat niet opent, een verkeerde versie, ontbrekende bijlagen of een restore die alleen lukt met de oorspronkelijke MSP-beheerder zijn allemaal relevante uitkomsten. “De taak was groen” verbergt die verschillen.

Dit is dezelfde reden waarom een herstelproces niet eindigt zodra een leverancier zijn dienst weer bereikbaar noemt. Bij een SaaS-storing moet je daarna nog vaststellen welke wijzigingen ontbraken en of die gecontroleerd zijn teruggebracht. Een herstelrunbook dat serviceherstel scheidt van reconciliatie en vrijgave beschrijft die bredere logica voor bedrijfsgegevens. Bij back-up hoort de proefrestore bij hetzelfde besluit: pas na een geslaagde terugzetting weet je of een herstelpunt ook werkbaar is.

Ik zou de proef klein houden, maar niet symbolisch. Kies iets dat de organisatie echt nodig kan hebben, zoals een bericht met bijlage, een SharePoint-bestand of een OneDrive-document. Leg vast welk herstelpunt is gebruikt, naar welke locatie is teruggezet, met welke beheeridentiteit en wat de eigenaar inhoudelijk heeft gecontroleerd. Zo kan een volgende beheerder dezelfde controle herhalen en ziet een auditor waar het bewijs vandaan komt.

De kopie moet buiten de gewone beheerlijn bereikbaar zijn

Er is nog een tweede vraag die in een geslaagde snapshot niet zit: wie kan de restore starten als de gewone beheerroute uitvalt? Een kopie kan buiten de productietenant staan en toch afhankelijk zijn van dezelfde identiteit, dezelfde MSP-console, hetzelfde toestel voor multifactorauthenticatie of dezelfde beheerder die de toegang beheert. Dan is de opslag misschien gescheiden, maar de sleutel tot herstel niet.

Dat is geen theoretische scheiding. Microsofts analyse van de ConnectWise-inbraak beschrijft hoe een applicatie-identiteit met eerder verleende tenantrechten zelfstandig Microsoft 365 kon benaderen. Herstelmaatregelen in de omgeving van een leverancier halen zulke rechten in afzonderlijke klanttenants niet automatisch weg. De herstelmaatregelen bij de leverancier trekken tenantrechten niet automatisch in klantomgevingen terug. Dat vraagt om meer dan alleen bevestigen dat de leverancier zijn eigen accounts heeft gereset.

NIST maakt het onderliggende principe expliciet voor opslag en cyberherstelkopieën. Het adviseert om herstelkopieën gescheiden van productie op te slaan en vanuit een aparte beheeromgeving te beheren die niet met gewone productie- of back-upgegevens toegankelijk is. Dat is geen kant-en-klaar Microsoft 365-ontwerp. Het geeft wel een heldere maatstaf: herstel mag niet volledig vastzitten aan dezelfde identiteit en omgeving die je probeert te herstellen.

Ook Microsofts richtlijn voor Entra-noodtoegang draait om getest kunnen inloggen wanneer de normale beheerroute faalt. Microsoft vraagt om noodaccounts minstens iedere 90 dagen te valideren en te controleren of een bevoegde beheerder ze echt kan gebruiken. Dat principe hoort ook thuis in de back-upafspraak: een alternatieve route bestaat pas wanneer iemand bevoegd is, de gegevens kan vinden en de route aantoonbaar werkt.

Met onafhankelijk bedoel ik niet een achterdeur buiten toestemming om. Een restore naar dezelfde Microsoft 365-tenant heeft nog steeds een geldige bestemming en passende rechten nodig. Ik bedoel dat herstel niet alleen kan starten vanuit één MSP-account of één federatieve aanmeldroute die met diezelfde tenant verdwijnt. Een tweede, goed beveiligde beheeridentiteit of een rechtstreeks klantpad naar de back-updienst kan dat risico verkleinen. De leverancier moet duidelijk maken welke onderdelen ook in een tenant- of MSP-storing blijven werken en welke niet.

De proef maakt afhankelijkheden zichtbaar

Stel dat de eerste nieuwe snapshot na herautorisatie is afgerond, maar het herstelportaal alleen via het account van de vaste beheerpartner bereikbaar is. De kopie is dan nieuw, maar de klant kan nog steeds niet zelf vaststellen of terugzetten. Als juist dat account, de beheerde laptop of de centrale MSP-omgeving tijdelijk niet beschikbaar is, valt de herstelroute samen met de storing die zij moest opvangen.

Een kleine restore via een tweede, vooraf afgesproken beheerroute maakt die afhankelijkheid meetbaar. Het resultaat hoeft niet ingewikkeld te zijn. De beheerder moet kunnen aantonen welk herstelpunt is gekozen, welke rechten zijn gebruikt, waar de data terechtkwam en of het resultaat bruikbaar was. Als één van die onderdelen alleen via de primaire MSP-route werkt, is dat geen reden om het testresultaat mooier te formuleren. Het is een beperking die op tafel hoort voordat er een incident is.

Dat betekent ook dat een proefrestore slechts een afgebakende claim bewijst. Een test van één bestand zegt niets over iedere mailbox, Teams-inhoud of Entra-configuratie. Hij bewijst wel dat die specifieke kopie, voor die gegevenssoort, via die toegangsroute kon worden teruggezet. Die bescheiden formulering is waardevoller dan een brede belofte over “volledige bescherming” die nooit is getest.

Om eerlijk te zijn, extra toegang kan ook risico geven

Er is een serieuze tegenwerping. Meer accounts, uitzonderingsrechten en handmatige restores vergroten de kans op misbruik en maken beheer ingewikkelder. Een kleine organisatie wil niet voor elke leverancier een tweede beheeromgeving onderhouden. ConnectWise zei bovendien dat bestaande archieven versleuteld, geïsoleerd en bewaard bleven, zonder aanwijzing dat ze waren aangetast. Als de dienst weer beschikbaar is, kan het redelijk voelen om op die verklaring en de dagelijkse monitoring te vertrouwen.

Die redenering heeft een kern van waarheid. Een extra identiteit die nooit wordt gecontroleerd, kan zelf een zwakke plek worden. En een restore op productie is geen onschuldige proef: die kan actuele gegevens overschrijven of verwarring veroorzaken. Ik pleit dus niet voor onbeperkte noodaccounts, een tweede back-upleverancier bij iedere organisatie of een volledige herstelrun na elke wijziging.

Maar die bezwaren pleiten voor een kleine, beheerste test, niet voor het overslaan ervan. Beperk de alternatieve toegang tot wie haar nodig heeft, bescherm haar apart, registreer gebruik en oefen de route op een veilige testlocatie. Herhaal de controle wanneer de toestemming, leverancier of beheerconstructie wezenlijk verandert. Zo test je een concreet herstelpad zonder dagelijkse bedrijfsdata op het spel te zetten.

De verklaring dat een archief intact is, beantwoordt een andere vraag dan of een nieuwe snapshot is gemaakt. Een geslaagde snapshot beantwoordt weer een andere vraag dan of je haar kunt terugzetten. En een terugzetting via de enige beheerder bewijst nog niet dat je tijdens uitval van die beheerroute kunt handelen. Die grenzen zijn geen wantrouwen jegens een leverancier. Ze voorkomen dat drie verschillende beweringen worden samengevoegd tot één geruststellend groen vinkje.

Een groene status kan rust geven en een nieuwe snapshot kan een herstelpunt vastleggen. Maar pas wanneer iemand die kopie via een geteste, afzonderlijk beheerde route kan terugzetten, verandert een belofte in herstelvermogen. Een back-up bewaart een moment uit het verleden; de toegang ertoe bepaalt of dat moment ook beschikbaar blijft wanneer de gewone weg ernaartoe wegvalt.