In mijn vorige blog legde ik uit waarom je storage je laatste verdedigingslinie is tegen ransomware en waarom traditionele backups alleen niet meer volstaan. In deze blog ga ik een stap verder: ik deel het high‑level referentiedesign dat ik als consultant gebruik als startpunt voor elke NetApp‑omgeving waar ransomware‑weerbaarheid een serieuze eis is.
Dit is geen theoretisch model. Het is het ontwerp dat ik keer op keer aanpas aan de situatie van een klant, maar waarvan de basisprincipes altijd overeind blijven.
Veel organisaties pakken ransomwarebescherming ad hoc aan. Er wordt een feature aangezet hier, een extra backup ingericht daar, en na verloop van tijd is er een lappendeken van maatregelen ontstaan zonder samenhang. Het resultaat: bij een daadwerkelijk incident weet niemand precies welke kopieën er zijn, hoe oud ze zijn, of ze vertrouwd kunnen worden.
Een referentiedesign dwingt je om vooraf na te denken over de volgende vragen:
Hoeveel lagen bescherming heb ik nodig?
Hoe zijn die lagen van elkaar gescheiden?
Wie mag wat beheren, en via welke paden?
Wat is mijn herstelstrategie per laag?
Met een helder antwoord op die vragen bouw je geen losse eilandjes, maar een samenhangende verdedigingslinie.
Mijn standaardarchitectuur bestaat altijd uit minimaal drie lagen. Elke laag heeft een eigen doel, eigen beheer en een bewust beperkte verbinding met de lagen ernaast.
Dit is de laag waar je productie‑workloads draaien: virtuele machines, databases, file shares, applicaties. De primary storage levert performance en beschikbaarheid, maar is ook de eerste laag die een aanvaller zal proberen te raken.
Op deze laag richt ik altijd het volgende in:
Regelmatige snapshots met meerdere retentieniveaus: kort voor snelle recovery, langer voor het geval een aanval pas later wordt ontdekt.
Automatische ransomware‑detectie op basis van I/O‑patronen, zodat verdachte activiteit direct een signaal geeft.
Strikte toegangscontrole: RBAC, scheiding tussen beheer‑ en dataverkeer, geen generieke beheeraccounts.
De primary laag is bewust niet de enige verdedigingslinie. Hoe goed je hem ook inricht, een aanvaller met voldoende toegang kan hier schade aanrichten. Alles wat hier misgaat, moet opvangbaar zijn door de lagen eronder.
De tweede laag bevat kopieën van de data op de primary omgeving. Dit kan een fysiek of logisch gescheiden systeem zijn, op een andere locatie of in een ander netwerksegment. De kern van deze laag is isolatie: een aanvaller die de primary omgeving heeft gecompromitteerd, mag hier niet zomaar bij kunnen.
Op deze laag gelden de volgende principes:
Replicatie vanuit de primary omgeving via gecontroleerde, gemonitorde verbindingen.
Retentie van meerdere herstelpunten, zodat je niet alleen kunt terugvallen op de meest recente kopie.
Beperkte en gescheiden beheertoegang: de beheeraccounts voor deze laag zijn niet dezelfde als die voor de primary omgeving.
Optioneel: immutability op geselecteerde datasets, zodat ook hier kopieën niet zomaar verwijderd of gewijzigd kunnen worden.
In veel omgevingen dient deze laag ook als disaster recovery omgeving: bij een calamiteit kunnen workloads hier worden opgestart terwijl de primary omgeving wordt hersteld.
De derde laag is het ultieme vangnet: een zo veel mogelijk geïsoleerde omgeving waar een beperkte, maar cruciale set data wordt bewaard. Een cyber vault is niet bedoeld voor alle data, maar voor de datasets die bij een incident absoluut beschikbaar moeten zijn.
De belangrijkste kenmerken van een cyber vault:
Air‑gap: de verbinding naar de vault is niet continu open, maar wordt alleen tijdens korte, geplande vensters geactiveerd voor replicatie.
Immutable snapshots: data in de vault kan niet worden overschreven of verwijderd, ook niet door een beheerder met volledige rechten.
Minimale beheeraccess: de vault wordt beheerd via strikt gecontroleerde, geauditeerde paden. Geen overlap met de beheeraccounts van de primary of secundaire omgeving.
Geïsoleerd herstelnetwerk: bij een incident kun je vanuit de vault herstellen in een schone, geïsoleerde omgeving om reinfectie te voorkomen.
In een latere blog ga ik dieper in op het ontwerp van een cyber vault. Voor nu is het belangrijk te begrijpen dat dit de laag is die je beschermt, ook als alles in de lagen erboven misgaat.
Een architectuur met drie lagen is pas waardevol als de datastromen tussen die lagen bewust zijn ontworpen. Twee principes staan daarin centraal.
Unidirectionele datastroom: data stroomt altijd van primary naar secundair naar vault, nooit andersom. Een aanvaller die de primary omgeving beheerst, kan daarmee geen data in de vault overschrijven of verwijderen.
Beperkte connectiviteit: de verbindingen tussen de lagen zijn zo smal mogelijk. Er is geen permanente, brede netwerkverbinding tussen primary en vault. Poorten zijn dicht, tenzij expliciet nodig voor replicatie, en die replicatievensters zijn kort en gemonitord.
Dit klinkt eenvoudig, maar in de praktijk is het een van de punten waar ik bij klanten de meeste uitdagingen zie. Beheer wil gemak, en gemak leidt vaak tot bredere verbindingen dan nodig. Discipline op dit punt is geen eenmalige maatregel, maar een ongoing verantwoordelijkheid.
Het referentiedesign is in essentie een toepassing van Zero Trust op de storage‑laag: vertrouw niets standaard, verifieer alles en beperk toegang tot wat strikt noodzakelijk is.
Concreet betekent dat:
Geen gedeelde beheeraccounts tussen de lagen.
Multi‑Admin Verification voor kritieke acties zoals het verwijderen van snapshots of het wijzigen van replicatiepolicies.
Logging van alle beheeracties, zodat je achteraf altijd kunt reconstrueren wie wat heeft gedaan.
Netwerksegmentatie: beheerverkeer loopt over aparte paden, gescheiden van dataverkeer.
Zero Trust is geen product dat je aanschaft, maar een ontwerpprincipe dat je doorvoert in elke keuze die je maakt.
Dit referentiedesign is een startpunt, geen eindpunt. In de praktijk pas ik het aan op basis van:
Omvang en complexiteit van de omgeving: een middelgrote organisatie met één datacenter heeft andere behoeften dan een enterprise met meerdere locaties.
Risicoprofiel: hoe kritiek is de data, wat zijn de compliance‑eisen, hoe hoog is de kans op een aanval?
Budget en capaciteit: niet elke organisatie kan direct een volledige cyber vault inrichten. Dan begin ik met de primaire en secundaire laag en bouw ik stap voor stap uit.
Het belangrijkste is dat je bewuste keuzes maakt en die keuzes documenteert. Een gedocumenteerd ontwerp, ook al is het nog niet volledig, is altijd beter dan een ongedocumenteerde omgeving die toevallig redelijk werkt.
In de komende blogs werk ik elke laag van dit ontwerp verder uit:
Blog 3: Welke ONTAP‑features zet ik standaard aan op de primary laag, en hoe configureer ik ze?
Blog 4: Hoe werkt automatische detectie van ransomware op storageniveau, en hoe koppel ik dat aan mijn monitoring?
Blog 5: Hoe ziet een herstelrunbook eruit in de praktijk, van de eerste alert tot volledig herstel?
Blog 6: Hoe ontwerp ik een cyber vault die echt geïsoleerd is?
Heb je vragen over dit referentiedesign, of wil je weten hoe het past bij jouw specifieke omgeving? Laat het weten in de comments of neem direct contact op.
Dit is deel 2 van de blogserie “Mijn standaard NetApp ransomware architectuur: een blueprint voor elke omgeving” Deel 1 lees je hier.
