Reforçar os backups do Velero antes que o ransomware os encontre primeiro

O Velero continua a ser uma das ferramentas de código aberto mais comuns para fazer backups, restaurar e migrar recursos de clusters Kubernetes e volumes persistentes. Para os fornecedores de serviços geridos que gerem muitos clusters, o quão bem o Velero está configurado — e não apenas se está instalado — determina se um backup é realmente útil durante um incidente.

O sucesso do backup não é o sucesso do restauro

Uma tarefa de backup que termina sem erros prova que os dados foram capturados, não que possam ser repostos. Os operadores de ransomware visam cada vez mais especificamente as credenciais de backup e as localizações de armazenamento, sabendo que um caminho de restauro funcional é a diferença entre um incidente e uma indisponibilidade. Os exercícios de restauro, executados de forma programada e registados como prova, são a única forma fiável de saber se um backup funcionará quando for necessário.

Onde concentrar os esforços de reforço

• Restrinja o RBAC concedido à conta de serviço do Velero ao que o backup e o restauro realmente exigem, e não ao cluster-admin por predefinição.
• Encripte os backups em repouso e mantenha pelo menos uma cópia fora do local ou imutável, para que um cluster comprometido não possa também destruir os seus próprios backups.
• Separe o caminho de gestão do armazenamento de backups da rede de cargas de trabalho sempre que o backend de armazenamento o permitir.
• Rode e restrinja o âmbito das credenciais que o Velero utiliza para aceder ao armazenamento de objetos, privilegiando tokens de curta duração em vez de chaves estáticas de longa duração.
• Trate o próprio caminho de restauro como uma capacidade de administrador de produção — qualquer pessoa que possa acionar um restauro pode normalmente substituir dados em produção.

O que o Velero não cobre por si só

O Velero faz backup de objetos do Kubernetes e, com o plugin certo, de dados de volumes persistentes — não protege, por si só, contra um cluster comprometido que adultera a sua própria agenda de backups, e não substitui a segmentação ao nível da rede. Combiná-lo com armazenamento imutável e fora do local fecha a lacuna mais comum que os MSPs observam na prática: backups que existem, mas permanecem acessíveis a partir do mesmo raio de impacto do cluster que protegem.

A base que importa é pouco glamorosa: cópias encriptadas e fora do local, acesso restrito e um exercício de restauro que foi realmente executado — e não apenas agendado.

Fontes: GitHub — vmware-tanzu/velero, Documentação do Velero.