matthew-waring-MJAoiige14E-unsplash

Microsoft 365 backup en restore: een gecompliceerde relatie

Nu steeds meer organisaties hun e-mail communicatie en documentopslag naar de Microsoft cloud verhuizen en daar ook intern via Teams chat gaan communiceren krijg ik meer vragen over backup en restore.  Het verschil tussen backup voor veiligheid en recordsmanagement voor compliance veronderstel ik bekend, hoewel er ook relevante raakvlakken zijn, waarover hieronder meer. Belangrijkste vraag is telkens: heeft mijn Microsoft 365 tenant een afzonderlijke backup voorziening nodig? En: wat kunnen we verwachten van backup en – vooral – restore van informatie? Lastig aan het onderwerp is dat vrijwel alle bronnen op het internet belangen hebben in de backup & restore branche. Een enkele leverancier daargelaten moeten we het vooral hebben van de zeldzame onafhankelijke geesten die de kat de bel aanbinden.

Waarom een backup?

Een backup is een voorziening waarvan je hoopt dat die vooral niet nodig is. Informatie die per ongeluk of moedwillig is verwijderd, beschadigd of ongevraagd versleuteld moet, soms na dagen, soms pas na jaren, kunnen worden hersteld (restored) uit periodiek aangemaakte kopieën (backup). Liefst met al hun functionaliteit en aanhangende gegevens intact. Technisch beheerders hebben dat jaar en dag gedaan met hun on premises fileshares, mailboxen en applicaties. Backups zijn eigenlijk en oneigenlijk gebruikt om mailboxen terug te zetten en verloren gewaande bonnetjes te vinden. Vaak om dàt te vinden wat eigenlijk gearchiveerd had moeten zijn of wat juist volgens regels al lang vernietigd had moeten worden. De verkoopargumenten voor Microsoft 365 back & restore worden op dit moment vooral gekoppeld aan begrijpelijke ransomware-angst, maar ook wat overtrokken schade-vrees door verongelijkte (‘disgruntled’) systeembeheerders die ‘rogue’ zouden gaan. Een ander belangrijk terugkerend argument is de beperking van restore mogelijkheden in Microsoft 365 zelf.

Voorkomen is beter…

Allereerst raakt de noodzaak van backup aan de noodzaak om schade te voorkomen. Je koopt immers geen kluis om vervolgens de buitendeuren open te laten staan. Uit nieuw Microsoft onderzoek blijkt dat slechts een minderheid van 22% van organisaties en bedrijven gebruik maakt van MFA (multi factor authentication, bv via een code op je mobiel). Terwijl MFA en andere beveiligingsmaatregelen bijna 100% van aanvallen kunnen opvangen. Daar komt bij dat cloud oplossingen als Microsoft 365 sowieso veiliger blijken dan on premises applicaties en platforms. Terwijl vorig jaar de geslaagde Hafnium-aanvallen op Exchange Server installaties volop in het nieuws waren, is Microsoft 365, ondanks de grote groei gedurende de pandemie, de dans vooralsnog ontsprongen, moeten ook – of zelfs – backup leveranciers toegeven. Exchange Online in Microsoft 365 is daarmee per definitie een bewezen, veiliger keuze. En dat is waarom specialisten als Tony Redmond “consider the attack by Hafnium a wake-up call for those still running on-premises servers. It should provide the impetus for a push to move email from on-premises Exchange to Exchange Online.”

Veiligheidsmaatregelen die Microsoft in onder andere gebruikersaanmelding, binnenkomend dataverkeer en uploads heeft getroffen zijn deels ingebakken in het platform, deels te configureren door beheer. Dat betekent dat als organisaties bijvoorbeeld moedwillig van MFA afzien (en ik ken verhalen van directeuren die het ‘liever niet’ hadden…) ze de veiligheid aanzienlijk verminderen. Hetzelfde geldt ook voor maatregelen tegen data lekkage (zoals DLP – data loss prevention) en voor device beheer. Geen actie = een grotere kans op ongelukken.

Wat Microsoft zelf doet

Microsoft neemt ook maatregelen voor de veiligheid van opgeslagen informatie die wellicht minder bekend, want onzichtbaar zijn, zoals Exchange Native Data Protection voor wereldwijd zo’n 5,5 miljard Exchange Online mailboxen op 275000 servers:

“Every mailbox database in Microsoft 365 is hosted in a database availability group (DAG) and replicated to geographically separate datacenters within the same region. (…) But in all cases, every mailbox database has four copies that are distributed across multiple datacenters, thereby ensuring that mailbox data is protected from software, hardware, and even datacenter failures.

Out of these four copies, three of them are configured as highly available. The fourth copy is configured as a lagged database copy. The lagged database copy is not intended for individual mailbox recovery or mailbox item recovery. Its purpose is to provide a recovery mechanism for the rare event of system-wide, catastrophic logical corruption.”

Daarbij zijn maatregelen van kracht die moeten voorkomen dat de mailbox kopieën ingeval van een incident de een na de ander zouden worden geïnfecteerd. Bedenk verder dat in Exchange Online mailboxen niet alleen e-mail wordt opgeslagen maar in een verborgen map óók de compliance exemplaren van Teams chat en kanaalpostings.

SharePoint Online  – en daarmee OneDrive – maakt gebruik van een vergelijkbaar mechanisme waarbij alle data tweevoudig in afzonderlijke datacenters binnen dezelfde regio wordt opgeslagen:

“SharePoint has a custom-built solution for storage of customer data in Azure Storage. Every file is simultaneously written into both a primary and a secondary datacenter region. If writes to either Azure region fail, the file save will fail. After the contents are written into Azure Storage, checksums are stored separately with metadata, and are used to ensure that the committed write is identical to the original file sent to SharePoint during all future reads. This same technique is used in all workflows to prevent propagation of any corruption that should occur.”

Verwijderde teamsite herstellen vanuit SharePoint beheercentrum

In SharePoint en OneDrive zijn in tijd beperkte mogelijkheden ingebouwd om verloren documenten, mappen, documentbibliotheken (gedurende 30 dagen) of gehele teamsites te herstellen (uiterlijk 93 dagen plus ca 2 weken). Het is opmerkelijk dat je daarbij wel teamsites 93 dagen lang kan herstellen, maar de bijbehorende autorisatie Groep maar 30 dagen. Dat je binnen die beperkte tijd zal moeten handelen maakt dat je beter maatregelen treft om risico’s van incidentele verwijdering te beperken.

Versie beheer op documenten is standaard en kan naar wens verder worden geconfigureerd (max aantal, major/minor versies).

Gebruiker kan niet een met retentielabel gearchiveerd item in SharePoint verwijderen (afhankelijk van configuratie)

Maar ook de recordsmanagement functies vanuit het Compliance Center bieden extra bescherming, omdat daarmee kan worden geregeld dat gebruikers items niet kunnen verwijderen en bovendien dat sites met gearchiveerde items niet kunnen worden verwijderd door functioneel beheer. Diezelfde bescherming, voor de maximale duur van een bewaartermijn (1 dag t/m permanent), kan ook worden geboden aan e-mail, chat en kanaalposts in Exchange Online. Weet overigens wat je doet als je met recordsmanagement in Microsoft 365 aan de slag gaat, test dit nooit in een productie tenant, want configuratie fouten zouden juist tot informatieverlies kunnen leiden (zoals ze bij KPMG ook weten).

Naast archivering is het mogelijk mailboxen en OneDrives bij vertrek van medewerkers te behouden, naar wens te archiveren en kunnen standaardtermijnen voor verwijdering worden verlengd.

Restore, maar wat krijg je dan terug?

Hoewel archivering in Microsoft 365 helpt om schade door verwijdering te voorkomen, is er dus  een beperkte tijdspanne waarbinnen restore met standaard Microsoft middelen mogelijk is. Dat kan een overweging voor backup zijn. Maar is alle informatie en alle functionaliteit met een externe oplossing, lokaal of in de cloud, wel te back-uppen en terug te zetten? Het antwoord is: de meeste informatie, maar niet alles kan door backup oplossingen uit de markt worden opgeslagen. En nee, ook is niet alles in de zelfde vorm weer terug te plaatsen. Daarbij komt dat verschillende oplossingen in de markt verschillende beperkingen kennen. Maar dat niet alle reclame die deze marktpartijen maken daarover even helder of correct is.

Documenten en e-mailberichten in SharePoint, OneDrive en Exchange kunnen de meeste backup leveranciers wel aan. Ze spreken zelf wel van ‘disaster recovery’. Het is wel de grote vraag waar een ‘disaster’ uit zou moeten bestaan met de afzonderlijke datacenters en redundante opslag door Microsoft zelf. Want als de schade beperkt is, kan Microsoft die daardoor zelf oplossen en als de schade desastreus is (zoals bij permanente/onherstelbare uitval van meerdere datacenters), is het de vraag naar welke infrastructuur je dan de backup nog zou kunnen restoren.

Problematischer dan bestands backup voor documenten en mail is de complexiteit van Microsoft Teams. Een deel van de informatie is door backup oplossingen wel veilig te stellen, maar voor andere informatie ontbreken APIs of is het onmogelijk de informatie uit de verschillende bronnen weer samen te stellen en te restoren naar het team in de Teams applicatie. Teams bevat zoveel verschillende typen informatie (chat, documenten, agenda’s, taken, etc.) en verschillen tussen sterk gelijkende functionaliteiten (chat in 1-1 chat, standaard kanalen, privé kanalen) dat externe backup oplossingen een lappendeken van wel en niet ondersteunde functies tonen.

Check de tabel in Redmond’s recent (jan. ’22) bijgewerkte artikel over Teams backup: “If you want to backup Teams, you need to understand what data is used with Teams in your tenant. Once you know that, you can figure out how to solve the backup problem.”

Check voor beperkingen van oplossingen uit de markt de tabel in dit stuk, al is deze door één belanghebbende partij samengesteld (mei ’21) en bevat het artikel wel reclame, onjuist gebruik van begrip ’retentie’ in de Prullenbak functie  en een warrig advies over Teams archivering met Bewaarbeleid (retention policies).

Wat vindt Microsoft eigenlijk zelf van externe backup?

Microsoft is over twee dingen expliciet:

“De beste manier om te voorkomen dat het slachtoffer wordt van ransomware, is door preventieve maatregelen te implementeren en hulpprogramma’s te hebben die uw organisatie beschermen tegen elke stap die aanvallers nemen om uw systemen te infiltreren. U kunt uw on-premises blootstelling verminderen door uw organisatie over te brengen naar een cloudservice.

“U moet ervan uitgaan dat u op een bepaald moment het slachtoffer wordt van een ransomware-aanval. Een van de belangrijkste stappen die u kunt nemen om uw gegevens te beveiligen en te voorkomen dat u moet betalen, is een betrouwbaar back-up- en herstelplan voor uw bedrijfskritische informatie te hebben. Aangezien aanvallers van ransomware veel hebben geïnvesteerd in het neutraliseren van back-uptoepassingen en besturingssysteemfuncties zoals volume shadow copy, is het essentieel om back-ups te hebben die niet toegankelijk zijn voor kwaadwillende aanvallers.

Wat Microsoft betreft is backup slechts één van de vele best practices die een organisatie zou moeten toepassen  – en de meeste maatregelen zijn van preventieve aard.

Samenvattend

Als organisatie zou je eerst maatregelen moeten willen nemen die de veiligheid van de informatie vergroten. Migratie naar de cloud is daarbij tot heden veiliger gebleken dan on premise blijven. Onder andere MFA, device management, (geautomatiseerd) recordsmanagement en Exchange migratie dragen aantoonbaar bij. Zeker organisaties die E5 licenties hebben ingekocht zouden deze meer moeten uitnutten voor betere bescherming, bijvoorbeeld door retention labels en retention policies toe te passen. Voorts adviseert Microsoft externe backup. Backup en restore voor Exchange, SharePoint en OneDrive bieden aanvullende bescherming waar incidenten met verwijderde bestanden die niet door recordsmanagement met retention labels of retention policies waren beschermd na meer dan drie maanden afwezigheid worden opgemerkt. Stel je vóór aanschaf van een backup oplossing wel op de hoogte van eventuele beperkingen voor restore, vooral voor Microsoft Teams data.


Afbeelding: Matthew Waring, Unsplash

 

Laat een reactie achter

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *