Opinião: Permissões: Escreva, mas não leia por motivos de segurança?

Opinião: Permissões: Escreva, mas não leia por motivos de segurança?

Tenho vários sistemas conectados e estou pensando em configurar um servidor separado para backups incrementais e completos.

Para também evitar a perda de todos os sistemas/backups no caso de um deles ser comprometido, estou pensando em tornar isso um tipo de caixa suspensa, com um compartilhamento somente gravação montado em cada sistema para o qual os backups são enviados.

Pretendo que, caso algo seja atacado, o backup possa ser exposto ou enviado ao sistema afetado por meio de um compartilhamento somente leitura recém-criado e depois restaurado a partir daí - mas o sistema em si não pode ser acessado.

Um de nossos concorrentes perdeu recentemente todo o seu negócio porque até mesmo seus backups estavam conectados – então eles não tinham nada para restaurar.

Também baixarei backups completos em intervalos adequados.

Por favor, faça buracos no meu plano.

Obrigado.

Responder1

Por favor, faça buracos no meu plano.

Claro. Apenas remover a leitura não evita problemas. Qualquer tentativa de modificação requer permissões de gravação. Um invasor ainda pode escrever o arquivo vazio (ele só precisa saber onde o arquivo está).

Por que não bloquear nada nesse disco em relação aos backups, exceto para anexar novos dados?

Configuração possível:

/backups/20160911/backup.tar.gz
/backups/20160912/backup.tar.gz
/backups/20160913/backup.tar.gz

Crie um script que faça

chattr -R +a /backups/
chattr -R +i /backups/*.tar.gz

+isignifica “imutável”; nada pode ser feito com esses arquivos ou diretórios. Nem mesmo o root pode alterá-lo (isso inclui remover, editar, escrever, adicionar novos arquivos. Qualquer coisa). Até o root precisa remover isso (com -i) antes que o root possa fazer algo com esses arquivos.

+asignifica "acrescentar"; Mesmas regras -icom 1 exceção. Ninguém está autorizado a fazer alterações no arquivo ou diretórioexceto adicionar a ele. E novamente: até mesmo o root precisa remover isso (com um -a) antes que o arquivo ou diretório possa ser alterado onde a alteração não está acrescentando nada a ele.

(acima pode precisar de alguns ajustes. 1 arquivo de backup grande pode não ser a melhor abordagem. Algo com subdiretórios e arquivo pode ser melhor. Portanto, isso precisaria de um ajuste nessas 2 linhas: por exemplo, SOMENTE faça isso em diretórios antigos e faça "hoje" manualmente quando o backup for concluído.

chattr -R +i /backups/{not_today}
chattr -R +a /backups/{today}

Faça com que este script seja executado em intervalos para que, se a qualquer momento alguém alterar algo dentro /backups/dele, redefina as permissões para todos os backups.

Diretórios e arquivos podem ser adicionados a "hoje" e após a conclusão do backup você poderá adicionar o +i manualmente. Crie uma boa senha de administrador e ninguém além do administrador irá mexer nesses arquivos. Sempre.

A propósito: considere também armazenar backups online. Temos nossos backups em várias instâncias do Google (temos 3 sistemas ativos em 3 continentes que compartilham os dados, cada um criando uma instância substituta em outro continente e cada um compartilha um sistema de backup).

Responder2

Remova a readpermissão dos arquivos ou diretórios que você deseja ilegíveis.

As permissões são:

u - Owner
g - group
o - others

Desative leitura para todos e direito para todos que você deseja que tenham acesso de gravação.

$ chmod -R ugo-r [path]

O diretório [caminho] e todos os seus arquivos e subdiretórios terão este atributo. Neste caso, o -r(sem acesso de leitura).

Responder3

Nada é tão seguro quanto backups desconectados. Baixe seus backups em uma unidade externa e desconecte-o da rede após copiar o backup para ele. Obtenha várias unidades e gire-as.

Por exemplo, compre 5 unidades de 1 TB (custo total <US$ 300). Atribua 3 deles como backups diários; todos os dias, conecte um e copie o backup nele e depois desconecte. Atribua um como backup semanal e outro mensal e faça o mesmo.

Mantenha algumas das unidades em um segundo local em caso de incêndio ou roubo.

Essa abordagem protege você contra muitas ameaças diferentes de perda de dados.

Se o seu sistema for totalmente baseado em servidor, use um equivalente em nuvem. Configure alguns servidores em diferentes provedores (amazon, google, azure). Conecte-se diariamente a outro servidor e faça o sftp do seu backup nesse servidor e depois desconecte. Mantenha várias cópias para não fazer backup de uma boa cópia.

Mas nada é tão impossível de hackear quanto uma cópia física que você desconecta de qualquer rede e mantém em um local externo.

informação relacionada