root geram os backups, coloque-os onde a conta de privilégio limitado pode acessá-los e chown à conta de privilégio limitado.
/home/backup/current.zip da máquina de origem para a máquina local.
As informações a serem armazenadas em backup não são extraordinariamente confidenciais [conversas públicas / privadas, senhas de contas para os serviços que estão sendo armazenados em backup, etc.]. Não é nada como cartões de crédito, informações de saúde, etc.
Estou confiante de que o restante do processo de backup [restauração, frequência de backups, etc.] funcionará para minha satisfação.
Você deve usar a criptografia chave pública neste cenário, quando seus backups externos forem armazenados por terceiros.
Dessa forma, a máquina que está sendo submetida a backup tem apenas sua própria chave pública e, portanto, só pode criar backups. Você armazena a chave privada offline e a usa apenas para restaurações.
Soluções de backup, como o Bareos, já suportam criptografia de chave pública ou você pode integrá-lo com facilidade em sua configuração existente com o GPG.
Sua configuração parece bastante sólida - embora eu seja realmente um grande defensor do software de backup para fazer backups.
Ofereço o seguinte esquema baseado em Bacula (e / ou BaReOS):
Nas máquinas que estão sendo submetidas a backup
Instalar o agente Bacula e configurar um certificado de criptografia específico da máquina.
(A chave de descriptografia não precisa ser armazenada nessas máquinas, pois é necessária apenas para restaurações).
Seus backups serão iniciados da mesma forma que qualquer backup Bacula "normal" e serão criptografados usando o certificado especificado.
No diretor do Bacula ( A máquina solicitando os backups )
Configure seu agendamento de backup conforme apropriado para sua organização (Full & Incrementals).
No Bacula Storage Server ( A máquina em que os backups são gravados )
Você não precisa fazer nada de especial, mas geralmente é recomendável ter o servidor de armazenamento fora do local ou sincronizar os backups fora do site usando rsync ou equivalente.
Isso é efetivamente equivalente ao seu esboço acima, mas não requer acesso SSH & tarefas agendadas. Além disso, você ganha alguns outros benefícios:
É difícil para um invasor vandalizar os backups.
O acesso a uma das máquinas que estão sendo submetidas a backup não permite que você exclua / sobrescreva backups - tudo isso é controlado pelo diretor.
É difícil para um atacante vandalizar as máquinas que estão sendo copiadas.
Com as chaves de descriptografia armazenadas off-line, um invasor não pode restaurar dados para as máquinas que estão sendo submetidas a backup (o backup não será descriptografado), portanto, mesmo que tenham acesso ao Diretor, não poderão solicitar uma restauração.
Seus backups são bastante seguros.
Como eles são criptografados antes de deixar a máquina de origem (e somente descriptografados na máquina de destino durante a restauração), alguém pegando uma cópia de seus backups está recebendo dados inutilizáveis (criptografados). Isso é mais uma preocupação se seus dados forem confidenciais, mas também significa que seu backup não pode ser adulterado (e, portanto, não pode ser usado para restaurar dados corrompidos / mal-intencionados em seus servidores se alguém obtiver acesso ao servidor de armazenamento) .
Você está usando "software de backup real"
Isso é útil quando você precisa "restaurar o documento em que eu estava trabalhando na quinta-feira" - você pode recuperar aquele arquivo sem precisar extrair (ou copiar) todo o arquivo.
O lado negativo? O agente de backup precisa ser executado como raiz (ou pelo menos como um usuário que possa ler todos os dados dos quais você deseja fazer backup). Os agentes são bastante seguros, mas há sempre uma chance de que exista uma falha desconhecida que possa apresentar uma possível avenida de ataque.
Fique por dentro dos seus patches e você deve estar bem.