
Eu tenho alguns servidores (virtuais). Eles fazem backup no Backblaze B2 usando uma chave de aplicativo.
Quero contratar uma pessoa para me ajudar a administrar esses servidores.
Quando essa pessoa obtém acesso root ao servidor (o que eu quero), ela também obtém acesso à chave do aplicativo B2. Isso significa que ele pode deletar o servidoreo backup.
Qual é um procedimento/configuração que eu poderia usar para me proteger contra esse caso extremo? Eu tenho backups offline, mas são mensais, enquanto os backups B2 são diários.
Responder1
Em alguns ambientes, você simplesmente divide o trabalho em duas equipes - uma equipe executa/protege os servidores, a outra executa/protege os backups.
a outra parte é, ainda mais importante: se o backup for gravável, especialmente do sistema que está sendo copiado, NÃO é um bom backup.
problema sistêmico em muitas ferramentas como o borg. é melhor se você puder (em um mundo de nuvem) enviar os backups para o AWS Glacier, enquanto os armazena no S3 com uma função que só pode criá-los. há cronogramas para exclusão e ninguém precisa fazer isso "rapidamente".
além disso, não se esqueça de que existem livros sobre esse assunto.
Responder2
Veja como fazer isso:
No Backblaze B2, crie uma chave de aplicativo que não possa excluir arquivos:
b2 create-key --bucket MyBucket MyKeyName listBuckets,listFiles,readFiles,writeFiles
Configure o backup para que ele use essa chave e não tente excluir arquivos de backup antigos. Por exemplo, em
duplicity
, não useremove-older-than
,remove-all-but-n-full
ouremove-all-inc-of-but-n-full
; emduply
, não usepurge
oupurgeIncr
.Para excluir backups antigos, defina configurações personalizadas de ciclo de vida no bucket; por exemplo, defina linhas que começam com
duplicity-full
para serem ocultadas após 360 dias e excluídas após outros 360; e assim por diante para arquivos começando comduplicity-inc
eduplicity-new
.
Atualizar:
Na verdade, o B2 não fornece nenhuma funcionalidade para "excluir um arquivo". Cada vez que você substitui o mesmo arquivo, ele mantém seu histórico, portanto um arquivo pode ter "versões" – a mais recente normalmente é a que você precisa. O que o B2 oferece é a funcionalidade de "ocultar" um arquivo. Quando você oculta um arquivo, na verdade você está gravando no histórico do arquivo que o arquivo foi "excluído", você meio que adiciona uma nova versão do arquivo que é o arquivo oculto ou excluído.
Exceto por isso, o B2 também oferece funcionalidade para realmente excluir versões de arquivos. Um usuário que não tem a permissão deleteFiles, na verdade, tem permissão para ocultar arquivos, mas não para excluir versões de arquivos.
Parece-me que a remove-...
funcionalidade da duplicidade deveria ser implementada ocultando arquivos. (Caberia então à configuração do bucket realmente excluir essas versões de arquivos ocultos após algum tempo.) No entanto, o back-end do B2 da duplicidade não faz isso; o que ele faz é excluir versões de arquivos.
Responder3
Na maioria das nuvens públicas, o acesso ssh ao servidor não significa que você pode excluir o servidor. Há uma diferença entre administrar no servidor e na conta da nuvem. Então, você pode separá-los. Você também pode dividir bastante as permissões, especialmente no Amazon AWS. Você pode dar permissão a alguém para reinicializar o servidor, mas não excluí-lo, por exemplo. E a AWS tem a opção de proteção contra exclusão em VMs.
A melhor prática, atualmente, é usar o gerenciamento de configuração como Chef/Puppet/Salt/Ansible para fazer quaisquer alterações em seus servidores e não realmente fazer login nos servidores.
Além disso, para AWS, você pode capturar instantâneos dos servidores quantas vezes quiser e esta é a maneira mais eficiente de fazer backup deles.