Întărirea backup-urilor Velero înainte ca ransomware-ul să le găsească primul

Velero rămâne unul dintre cele mai comune instrumente open-source pentru backup-ul, restaurarea și migrarea resurselor de cluster Kubernetes și a volumelor persistente. Pentru furnizorii de servicii gestionate care rulează multe clustere, cât de bine este configurat Velero — nu doar dacă este instalat — determină dacă un backup este cu adevărat util în timpul unui incident.

Succesul backup-ului nu este succesul restaurării

O sarcină de backup care se termină fără erori dovedește că datele au fost capturate, nu că pot fi repuse la loc. Operatorii de ransomware vizează tot mai des credențialele de backup și locațiile de stocare, știind că o cale de restaurare funcțională este diferența dintre un incident și o întrerupere. Exercițiile de restaurare, rulate conform unui program și înregistrate ca dovezi, sunt singura modalitate fiabilă de a ști că un backup va funcționa atunci când este nevoie de el.

Unde să concentrăm efortul de întărire

• Restricționați RBAC-ul acordat contului de serviciu al Velero la ceea ce necesită efectiv backup-ul și restaurarea, nu cluster-admin în mod implicit.
• Criptați backup-urile în repaus și păstrați cel puțin o copie în afara locației sau imutabilă, astfel încât un cluster compromis să nu poată distruge și propriile backup-uri.
• Separați calea de gestionare pentru stocarea backup-urilor de rețeaua de lucru ori de câte ori backend-ul de stocare permite acest lucru.
• Rotați și limitați credențialele pe care Velero le folosește pentru a accesa stocarea de obiecte, preferând tokenuri cu durată scurtă de viață în locul cheilor statice cu durată lungă.
• Tratați calea de restaurare în sine ca pe o capacitate de administrator de producție — oricine poate declanșa o restaurare poate, de obicei, să suprascrie datele live.

Ce nu acoperă Velero de unul singur

Velero face backup pentru obiectele Kubernetes și, cu plugin-ul potrivit, pentru datele volumelor persistente — nu protejează prin el însuși împotriva unui cluster compromis care își manipulează propriul program de backup și nu este un substitut pentru segmentarea la nivel de rețea. Asocierea lui cu stocare imutabilă, în afara locației, închide cel mai comun gol pe care MSP-urile îl văd în practică: backup-uri care există, dar rămân accesibile din același perimetru de explozie ca și clusterul pe care îl protejează.

Linia de bază care contează este lipsită de strălucire: copii criptate și în afara locației, acces restricționat și un exercițiu de restaurare care a fost efectiv rulat — nu doar programat.

Surse: GitHub — vmware-tanzu/velero, Documentația Velero.