Velero-back-ups verharden voordat ransomware ze als eerste vindt

Velero blijft een van de meest gebruikte open-sourcetools voor het back-uppen, herstellen en migreren van Kubernetes-clusterresources en persistente volumes. Voor managed service providers die veel clusters beheren, bepaalt hoe goed Velero is geconfigureerd — en niet alleen of het is geïnstalleerd — of een back-up tijdens een incident daadwerkelijk bruikbaar is.

Back-upsucces is geen restore-succes

Een back-upjob die zonder fouten eindigt, bewijst dat de gegevens zijn vastgelegd, niet dat ze ook kunnen worden teruggezet. Ransomware-aanvallers richten zich steeds vaker specifiek op back-upcredentials en opslaglocaties, omdat ze weten dat een werkend restore-pad het verschil is tussen een incident en een storing. Restore-oefeningen, uitgevoerd volgens een schema en vastgelegd als bewijs, zijn de enige betrouwbare manier om te weten dat een back-up werkt wanneer die nodig is.

Waarop u zich bij het verharden moet richten

• Beperk de RBAC die aan het serviceaccount van Velero is toegekend tot wat back-up en restore daadwerkelijk nodig hebben, niet standaard cluster-admin.
• Versleutel back-ups at rest en bewaar ten minste één kopie offsite of immutable, zodat een gecompromitteerd cluster niet ook zijn eigen back-ups kan vernietigen.
• Scheid het beheerpad voor back-upopslag van het workloadnetwerk waar de storage-backend dat toestaat.
• Roteer en beperk de credentials die Velero gebruikt om objectopslag te bereiken, en geef de voorkeur aan kortlevende tokens boven langlevende statische sleutels.
• Behandel het restore-pad zelf als een beheercapaciteit voor productie — iedereen die een restore kan starten, kan doorgaans live gegevens overschrijven.

Wat Velero niet zelf dekt

Velero maakt back-ups van Kubernetes-objecten en, met de juiste plug-in, van persistente volumegegevens — het beschermt op zichzelf niet tegen een gecompromitteerd cluster dat zijn eigen back-upschema manipuleert, en het is geen vervanging voor segmentatie op netwerkniveau. De combinatie met immutable, offsite opslag dicht het meest voorkomende gat dat MSP's in de praktijk zien: back-ups die bestaan maar bereikbaar blijven vanuit dezelfde blast radius als het cluster dat ze beschermen.

De basis die er echt toe doet, is weinig glamoureus: versleutelde en offsite kopieën, beperkte toegang en een restore-oefening die daadwerkelijk is uitgevoerd — niet alleen ingepland.

Bronnen: GitHub — vmware-tanzu/velero, Velero-documentatie.