Blindar las copias de seguridad de Velero antes de que el ransomware las encuentre primero

Velero sigue siendo una de las herramientas de código abierto más habituales para realizar copias de seguridad, restaurar y migrar recursos de clústeres de Kubernetes y volúmenes persistentes. Para los proveedores de servicios gestionados que operan muchos clústeres, lo bien configurado que esté Velero —no solo si está instalado— determina si una copia de seguridad resulta realmente útil durante un incidente.

El éxito de la copia no garantiza el de la restauración

Un trabajo de copia que termina sin errores demuestra que los datos se capturaron, no que puedan recuperarse. Los operadores de ransomware atacan cada vez más las credenciales y las ubicaciones de almacenamiento de las copias de seguridad, sabiendo que una ruta de restauración operativa marca la diferencia entre un incidente y una interrupción del servicio. Los simulacros de restauración, ejecutados de forma programada y registrados como evidencia, son la única forma fiable de saber que una copia funcionará cuando se necesite.

Dónde centrar los esfuerzos de blindaje

• Limite el RBAC otorgado a la cuenta de servicio de Velero a lo que realmente necesitan las copias y restauraciones, no al rol cluster-admin por defecto.
• Cifre las copias de seguridad en reposo y mantenga al menos una copia externa o inmutable, para que un clúster comprometido no pueda destruir también sus propias copias.
• Separe la ruta de gestión del almacenamiento de copias de seguridad de la red de cargas de trabajo siempre que el backend de almacenamiento lo permita.
• Rote y limite el alcance de las credenciales que Velero utiliza para acceder al almacenamiento de objetos, priorizando los tokens de vida corta frente a las claves estáticas de larga duración.
• Considere la propia ruta de restauración como una capacidad de administración de producción: cualquiera que pueda lanzar una restauración normalmente puede sobrescribir datos en vivo.

Lo que Velero no cubre por sí solo

Velero realiza copias de seguridad de los objetos de Kubernetes y, con el complemento adecuado, de los datos de los volúmenes persistentes; por sí solo no protege frente a un clúster comprometido que manipule su propia programación de copias ni sustituye a la segmentación a nivel de red. Combinarlo con almacenamiento externo inmutable cierra la brecha más habitual que los MSP observan en la práctica: copias que existen pero siguen siendo accesibles desde el mismo radio de impacto que el clúster que protegen.

La base que importa no es glamurosa: copias cifradas y externas, acceso restringido y un simulacro de restauración que se haya ejecutado de verdad, no solo programado.

Fuentes: GitHub — vmware-tanzu/velero, Documentación de Velero.