Os backups de produção precisam de credenciais separadas?

Um backup só é uma cópia de recuperação se um incidente que danifique a produção também não puder apagar essa cópia. Parece óbvio, até você examinar as credenciais por trás de um job automatizado. Em muitas configurações, um único token lê dados ativos, grava um backup, lista backups antigos, exclui cópias para cumprir a retenção, altera o destino e inicia restaurações. Entregue esse token a um agente autônomo e uma chamada de API equivocada ou comprometida poderá transformar uma interrupção de produção em uma falha de recuperação.

A solução não é uma política de permissões maior, escrita em uma linguagem mais sofisticada. Dê aos dados ativos e aos dados de recuperação limites de ação separados. A credencial que opera a produção não deve remover cópias de recuperação. A credencial que grava um backup não deve alterar sua retenção. Uma restauração deve ter sua própria aprovação, pois move dados sensíveis de volta para um ambiente ativo. Cada limite deve fazer uma solicitação incorreta falhar antes que ela cause consequências.

Este é um problema de projeto, não de fornecedor. O mesmo padrão vale quando as cópias ficam em armazenamento de objetos, um cofre de backups gerenciado, snapshots, um appliance físico ou uma segunda conta de nuvem. A imutabilidade do armazenamento importa. A administração separada também. Mas nenhuma das duas ajuda se a identidade de uso normal de um agente ainda puder acionar os controles destrutivos ao redor delas.

Uma cópia de backup não é separada se uma identidade puder apagá-la

Uma cópia de recuperação precisa sobreviver aos modos de falha esperados na produção, incluindo o uso indevido de uma credencial privilegiada. Se a mesma identidade de agente puder chamar tanto delete production database quanto delete recovery vault, você tem dados duplicados, não uma recuperação isolada.

As equipes costumam chamar isso de separação porque produção e backups usam buckets, pastas, regiões ou nomes de recursos diferentes. Isso é organização do armazenamento. Não é separação de acesso. Um único principal com acesso amplo pode atravessar todos esses limites em poucas solicitações.

O teste é simples: pegue a credencial disponível para o agente de produção e pergunte o que ela pode fazer sem outra pessoa, outra identidade ou um plano de controle fisicamente distinto. Se ela puder fazer qualquer uma das ações abaixo, terá influência demais sobre a recuperação:

• Excluir permanentemente um ponto de recuperação ou uma versão de objeto.
• Encurtar a retenção, ignorá-la ou remover uma retenção.
• Desativar a replicação ou redirecionar cópias futuras.
• Alterar o acesso à criptografia de modo que a restauração falhe.
• Excluir um cofre de backups, projeto, conta ou contêiner de armazenamento.

A parte incômoda é que um agente talvez nunca receba uma instrução explícita para excluir backups. Um modelo pode escolher um comando de limpeza amplo demais. Um wrapper de ferramenta pode associar uma operação de aparência inocente a um endpoint destrutivo. Um repositório comprometido pode convencer o agente a usar quaisquer credenciais que já estejam disponíveis. A proteção precisa funcionar quando a solicitação estiver errada, não apenas quando o prompt fizer sentido.

Há dois raios de impacto diferentes para controlar. O primeiro é o dano ao plano de dados: um agente altera ou exclui dados do negócio. O segundo é o dano ao plano de recuperação: um agente remove as cópias, desativa o caminho até elas ou torna impossível descriptografá-las. A maioria das equipes investe no primeiro e deixa o segundo ligado ao mesmo papel de administrador.

Essa decisão geralmente vem da conveniência. A limpeza da retenção precisa de permissão para excluir backups expirados, então o job de backup recebe direitos amplos de exclusão. Um teste de restauração precisa de um papel privilegiado, então a mesma integração recebe esse papel. Um engenheiro quer um único segredo no CI, então o papel acumula todas as permissões. Cada atalho é compreensível. Juntos, eles dão a uma credencial de automação rotineira autoridade sobre a última linha de recuperação.

Gravar um backup e administrar sua vida útil são tarefas diferentes

O gravador de backup precisa de um caminho restrito e repetível. O administrador de retenção precisa de autoridade para alterar ou remover cópias. Um operador de recuperação precisa de autoridade para ler uma cópia selecionada e introduzi-la em um destino controlado. Tratar tudo isso como uma única tarefa é o que transforma uma identidade de backup em algo perigoso.

Uma divisão útil tem quatro classes de ação:

1. Captura lê a fonte de produção indicada e cria um novo artefato de recuperação.
2. Depósito grava esse artefato em um destino definido, com os atributos de retenção exigidos.
3. Recuperação lê um artefato selecionado e o restaura apenas em um destino permitido.
4. Administração altera retenção, retenções legais, configurações do cofre, replicação, acesso à criptografia ou regras de exclusão.

A captura e o depósito muitas vezes podem ser executados sem supervisão. A recuperação normalmente deve exigir uma aprovação nova, pois pode mover uma grande quantidade de informações sensíveis para um runtime novo. A administração deve ficar completamente fora do caminho normal do agente, exceto por procedimentos de emergência estreitos e aprovados separadamente.

Não confunda limpeza com captura. A expiração automática é desejável, mas isso não significa que o gravador precise ter autoridade permanente para excluir. Prefira regras de ciclo de vida controladas pelo sistema de recuperação ou por um papel separado de retenção. Se a plataforma obrigar o gravador a excluir seus próprios backups antigos, dê a ele permissão apenas dentro de uma área de staging curta e dedicada. Replique as cópias concluídas para um destino protegido onde esse gravador não possa excluí-las nem alterá-las.

Essa distinção revela uma falha conhecida. Um agente de banco de dados executa uma exportação a cada hora. Seu papel pode gravar em recovery/incoming/, listar o prefixo e excluir arquivos antigos. Meses depois, a equipe de armazenamento muda o destino para recovery/. O limite do prefixo desaparece, e o agente passa a ter direitos de exclusão sobre os dados de recuperação atuais. O job continua verde. O problema só aparece quando alguém precisa da cópia.

Use nomes separados que expressem a intenção nas próprias permissões. backup-writer, backup-retention-admin e restore-operator são mais claros que um único papel chamado backup-service. Nomes claros não impõem acesso, mas tornam muito mais difícil aprovar uma revisão sem examiná-la.

Credenciais separadas precisam levar a autoridades separadas

Criar duas chaves de API para o mesmo papel de administrador amplo não serve para nada. Credenciais separadas só importam quando levam a autoridades diferentes de uma forma que um invasor, um script defeituoso ou um agente não possa unir.

Comece com um mapa pequeno de acesso. Anote cada fonte, destino, credencial e operação destrutiva. Inclua a conta ou assinatura de nuvem, não apenas o caminho de armazenamento. O mapa deve responder a perguntas que os diagramas de aplicativos costumam ignorar:

• Qual identidade cria a cópia?
• Qual identidade pode excluir uma cópia existente antes da expiração programada?
• Qual identidade pode reduzir a retenção ou acionar um bypass?
• Qual identidade pode alterar a replicação, o bloqueio do cofre ou as chaves de criptografia necessárias para restaurar?
• Qual identidade pode restaurar dados em uma rede que alcança a produção?

Se a resposta para três ou mais perguntas for a mesma identidade de serviço, separe as ações antes de adicionar mais automação.

Um projeto mínimo e prático se parece com isto:

As identidades podem ficar inicialmente no mesmo provedor, mas precisam ter papéis, credenciais e caminhos de aprovação distintos. Uma separação melhor coloca o destino protegido em outra conta, controlada por um grupo administrativo diferente. Uma separação mais forte acrescenta um provedor de identidade independente ou um ambiente de recuperação que os administradores de produção não possam modificar silenciosamente. Não adie a divisão inicial enquanto espera pela estrutura de contas perfeita.

Uma conta separada ainda falha se um superadministrador de produção puder assumir o papel de administrador de recuperação sempre que quiser. Isso pode ser aceitável para uma organização pequena sem outra opção, mas chame as coisas pelo nome: é separação administrativa por convenção. É mais fraca que um limite que exige outra pessoa, um fator de hardware ou uma aprovação externa.

A imutabilidade impede uma classe de exclusão, não toda falha de recuperação

O armazenamento imutável protege cópias existentes contra alteração ou exclusão durante um período de retenção. Ele não prova que novas cópias continuam chegando, que contêm os dados corretos, que as chaves de criptografia continuam disponíveis ou que um operador consegue restaurá-las. É um controle importante, mas não pode sustentar sozinho todo o plano de recuperação.

A orientação StopRansomware da CISA recomenda manter backups offline e garantir que os dados de backup sejam criptografados e imutáveis. A recomendação faz sentido porque invasores frequentemente atacam os sistemas de backup depois de alcançar a produção. Ela não deve ser entendida como permissão para colocar uma credencial de administrador do cofre na mesma automação que opera o aplicativo.

O S3 Object Lock da Amazon torna essa distinção concreta. No modo de conformidade, uma versão de objeto protegida não pode ser sobrescrita nem excluída por nenhum usuário, incluindo o usuário raiz da conta, antes da data de retenção. No modo de governança, um chamador com s3:BypassGovernanceRetention pode substituir a proteção se fizer explicitamente uma solicitação de bypass. A documentação da Amazon observa ainda que o console inclui automaticamente esse cabeçalho de bypass para um chamador que tenha permissão.

O modo de governança é útil, especialmente enquanto você descobre qual período de retenção pode assumir. Ele não é o mesmo que um limite rígido se a credencial do agente tiver autoridade de bypass. Não entregue s3:BypassGovernanceRetention a um agente só porque alguém quer que uma tarefa de limpeza pare de falhar. Corrija o projeto do ciclo de vida.

A retenção em modo de conformidade tem um custo: um período incorreto pode preservar dados por mais tempo que o esperado, e você não poderá encurtá-lo. Decida isso deliberadamente. Escolha os períodos de retenção com base nos requisitos de recuperação, obrigações legais, sensibilidade dos dados, custo e tempo necessário para descobrir uma invasão. Uma configuração genérica copiada de outra equipe não é um plano.

Há outra armadilha no armazenamento de objetos com versionamento. Uma solicitação simples de exclusão pode criar um marcador de exclusão em vez de remover permanentemente uma versão antiga do objeto. Isso pode fazer uma restauração parecer quebrada para um operador que navega pela visualização mais recente, mesmo que a versão protegida ainda exista. O procedimento de recuperação precisa explicar como identificar e recuperar a versão necessária. Um objeto que não pode ser excluído, mas que ninguém consegue encontrar durante um incidente, está apenas parcialmente protegido.

Coloque os controles destrutivos de backup atrás de outra aprovação

A criação rotineira de backups deve ser entediante. Uma nova sessão de agente pode precisar de aprovação para usar uma credencial de gravador de backup, mas as chamadas individuais de captura e depósito não devem exigir atenção humana se estiverem restritas à fonte e ao destino previstos. As pessoas aprendem rapidamente a aprovar prompts repetitivos sem lê-los.

Ações destrutivas ou irreversíveis merecem outro tratamento. Remover uma cópia de recuperação, encurtar a retenção, alterar um destino de replicação, desativar um bloqueio do cofre, exportar material de descriptografia ou restaurar em um ambiente acessível pela produção deve parar para uma aprovação nova e específica. A aprovação deve descrever a ação solicitada em linguagem simples e identificar a credencial, o destino e o impacto.

Aprovação ruim: Permitir operação de backup?

Aprovação útil: Permitir que backup-retention-admin remova 14 pontos de recuperação expirados de archive-vault? Esta ação não pode ser revertida para cópias que não estejam sob retenção imutável.

A formulação importa porque permite ao revisor rejeitar uma solicitação tecnicamente autorizada, mas operacionalmente errada. Um agente de produção que de repente peça para modificar um cofre de recuperação deve parecer estranho antes que alguém precise interpretar o nome de uma ação do IAM.

A aprovação não substitui as permissões. Um revisor pode aprovar a solicitação errada, especialmente às 2 da manhã, quando um incidente já encheu a tela de alertas. O limite de permissões precisa tornar as ações perigosas indisponíveis ao gravador normal. A aprovação então trata do conjunto menor de ações que continuam possíveis de propósito.

O Sallyport segue esse padrão quando um agente de programação precisa chamar uma API de backup ou executar uma tarefa de backup baseada em SSH: mantenha a credencial no cofre do aplicativo, permita que a sessão normal use apenas a credencial de gravação e marque as credenciais de administração da recuperação para aprovação a cada uso. O agente recebe o resultado da ação, não o segredo.

Essa configuração também resolve uma preocupação prática com agentes de longa duração. Não aprove um processo uma vez e presuma que todas as ações futuras dele merecem a mesma confiança. Um processo novo deve estabelecer sua própria sessão. Uma credencial sensível deve exigir consentimento próprio a cada chamada, mesmo quando o processo já tenha acesso rotineiro ao backup.

Um fragmento de política deve tornar a chamada errada impossível

As revisões de permissões ficam muito mais claras quando você testa a solicitação que nunca quer que seja bem-sucedida. O exemplo a seguir ilustra um papel de depósito no estilo S3. Ele só pode colocar um objeto novo em um prefixo atribuído. Não tem DeleteObject, bypass de retenção, autoridade sobre a política do bucket nem permissão para ler o arquivo de volta.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "WriteNewRecoveryArtifacts",
      "Effect": "Allow",
      "Action": ["s3:PutObject"],
      "Resource": "arn:aws:s3:::recovery-archive-prod/incoming/database/*"
    },
    {
      "Sid": "DenyRecoveryAdministration",
      "Effect": "Deny",
      "Action": [
        "s3:DeleteObject",
        "s3:DeleteObjectVersion",
        "s3:BypassGovernanceRetention",
        "s3:PutObjectRetention",
        "s3:PutObjectLegalHold",
        "s3:PutBucketPolicy",
        "s3:DeleteBucket"
      ],
      "Resource": "*"
    }
  ]
}

Este é um exemplo de formato, não uma política para colar sem análise. Uma implantação real pode precisar de cabeçalhos de criptografia, ações de upload multipart, uma restrição de bucket ou um papel separado para um serviço de replicação. O ponto é que ninguém que leia a política deve ficar em dúvida sobre a capacidade dessa identidade de excluir um artefato de recuperação. A resposta precisa estar visível.

Execute um teste negativo após cada alteração de permissão. Com a credencial de depósito ativa, uma exclusão deve falhar de uma forma que seus logs possam registrar:

aws s3api delete-object \
  --bucket recovery-archive-prod \
  --key incoming/database/2026-07-22/backup.sql.zst

Um resultado saudável se parece com isto:

An error occurred (AccessDenied) when calling the DeleteObject operation:
User is not authorized to perform: s3:DeleteObject on resource:
arn:aws:s3:::recovery-archive-prod/incoming/database/2026-07-22/backup.sql.zst

Depois, teste a ação que o papel deve executar. Envie um artefato canário inofensivo, verifique se suas configurações de retenção aparecem como esperado e confirme que o agente não consegue alterá-las depois. Um projeto de permissões que ainda não passou por um teste negativo continua sendo apenas um diagrama.

Não deixe a credencial do administrador de retenção ao lado da credencial de gravação “para emergências”. Emergências criam a maior pressão para usar o segredo amplo. Mantenha essa credencial em um armazenamento separado e exija uma rota de aprovação diferente ou um segundo operador.

A recuperação pode vazar dados mesmo quando a exclusão está bloqueada

As equipes geralmente descrevem a restauração como um caminho seguro. Ela é mais segura que excluir um backup, mas ainda é uma ação privilegiada. Restaurar um banco de dados de clientes em um ambiente de desenvolvimento improvisado pode expor segredos de produção, dados pessoais, registros de pagamento ou tokens internos. Restaurar uma imagem em uma rede com conectividade de produção também pode introduzir credenciais antigas e serviços inseguros.

Uma ação de restauração precisa de restrições adequadas ao sistema recuperado. No mínimo, especifique o ponto de recuperação de origem, a conta ou projeto de destino, a rede de destino e o grupo de acesso pretendido. Se a plataforma oferecer uma sandbox de restauração, use-a. Caso contrário, crie um destino restrito, com controles de saída e sem rota para a produção por padrão.

Separe a aprovação da restauração da aprovação do backup por outro motivo: o operador de recuperação pode precisar acessar dados protegidos para leitura, enquanto o gravador de backup não deveria. Essa autoridade de leitura pode ser mais sensível que a de gravação. Um job de exportação pode produzir dados criptografados sem nunca ver o texto simples. Um job de restauração geralmente o materializa.

Um bom exercício de restauração responde a mais que “o comando terminou?”. Ele verifica se:

• O horário selecionado corresponde ao cenário do incidente.
• O artefato pode ser descriptografado com a identidade de recuperação pretendida.
• O aplicativo inicia com uma configuração isolada.
• Os registros e o esquema esperados aparecem.
• O ambiente temporário restaurado é destruído ou mantido sob suas próprias regras de acesso.

Não execute exercícios apenas contra a cópia mais fácil do dia anterior. Escolha pontos de recuperação mais antigos, fontes de dados diferentes e situações em que uma versão de objeto ou chave de criptografia precise ser selecionada deliberadamente. A restauração difícil é a que ensina se o runbook descreve a realidade.

O caminho da falha geralmente começa com uma solicitação inofensiva

Considere um agente de programação com acesso a um banco de dados de produção e à CLI de um provedor de nuvem. Ele recebe uma solicitação para reduzir custos de armazenamento depois que um ambiente de testes acumulou exportações antigas. O agente lista um prefixo amplo de armazenamento, encontra objetos grandes e envia um comando de exclusão. O engenheiro queria limpar arquivos de staging. A credencial alcança tanto o staging quanto o arquivo porque um curinga era conveniente.

Se o arquivo usa versionamento comum, o comando pode adicionar marcadores de exclusão e fazer as cópias atuais desaparecerem de uma listagem normal. Se o arquivo usa retenção de governança e a credencial inclui autoridade de bypass, a solicitação pode remover versões de forma definitiva. Se usa retenção de conformidade, a solicitação de exclusão falha, exatamente o tipo de falha desejado.

Agora mude apenas o projeto das credenciais. O agente pode usar uma credencial de limpeza do staging para o caminho de testes e uma credencial de depósito, somente para novas gravações, no arquivo. Nenhuma das duas pode listar ou excluir objetos de recuperação protegidos. A solicitação falha antes de se transformar em um incidente. Um administrador de recuperação pode depois analisar a questão de custos com uma aprovação separada e decidir se as regras de ciclo de vida precisam ser ajustadas.

É por isso que credenciais amplas de armazenamento são piores do que parecem. O comando em si pode ser comum. O resultado destrutivo vem de uma identidade que atravessa limites que a tarefa nunca precisou atravessar.

Mantenha um registro de auditoria das ações de recuperação permitidas e negadas. O registro das negações prova que um controle foi acionado. O registro das ações permitidas informa qual processo usou qual credencial, o que acessou e quando. No Sallyport, o diário de sessões e o diário de atividades fornecem esses dois níveis de evidência, e sp audit verify pode verificar a cadeia de hashes offline sem acesso ao cofre. Isso é útil depois de um incidente, pois um relatório de backup que diz “sucesso” não consegue explicar uma solicitação administrativa suspeita.

Os relatórios de backup devem mostrar autoridade, não apenas sucesso

A maioria dos painéis de backup informa se um job terminou e quanto de dados foi copiado. Acrescente uma segunda visão: qual autoridade fez a alteração, que operação tentou executar e se o sistema a aceitou. A segurança da recuperação falha silenciosamente quando todos os relatórios reduzem a autorização a um selo verde ou vermelho do job.

Para cada execução de backup, registre o identificador da fonte, o identificador do destino, a versão do artefato ou ID do ponto de recuperação, a classe da credencial, o estado da retenção e o resultado. Para cada ação negada, registre contexto suficiente para investigar sem armazenar segredos ou cargas sensíveis. O registro deve permitir distinguir um backup completo de um upload falho, uma expiração rotineira do ciclo de vida de uma exclusão manual e uma chamada destrutiva bloqueada de uma permissão ausente que precisa ser revisada.

Não conceda amplo acesso de leitura ao armazenamento de recuperação apenas para que um agente produza um relatório detalhado. Muitos provedores oferecem endpoints de metadados, relatórios de inventário ou chamadas de status com escopo restrito. Se o agente precisar ler um manifesto, escreva um manifesto separado contendo identificadores, checksums, horários de captura e estado da retenção, em vez de um catálogo de dados de clientes.

Uma revisão semanal útil faz quatro perguntas:

1. Toda fonte esperada criou um artefato recuperável?
2. Alguma identidade tentou alterar retenção, exclusão ou replicação?
3. A credencial atual do gravador consegue acessar ações de administração da recuperação?
4. Um exercício de restauração provou que uma cópia antiga selecionada consegue iniciar o aplicativo de forma isolada?

Se a equipe não conseguir responder a essas perguntas com seus registros, melhore os registros antes de presumir que o projeto de backup funciona.

Crie o limite antes de automatizar mais

Comece pela credencial que seu agente ou job de CI já possui. Remova sua capacidade de excluir cópias de recuperação, ignorar a retenção, alterar retenções, mudar a replicação, modificar configurações do cofre e administrar a conta de recuperação. Depois, crie uma identidade de depósito que possa gravar apenas onde deve. Essa mudança fecha um caminho comum entre uma instrução ruim e um dano irreversível.

Em seguida, transfira os controles de ciclo de vida e retenção para uma identidade administrativa distinta. Acrescente retenção imutável para a janela de recuperação que sua organização consegue defender. Coloque a restauração em um destino restrito e exija uma aprovação específica antes que dados sensíveis reapareçam em qualquer lugar fora do runtime normal. Por fim, execute um exercício que tente tanto o backup esperado quanto a exclusão proibida.

Seu projeto de backup estará pronto para agentes quando um agente puder criar uma cópia de recuperação sem possuir autoridade para destruí-la. Até lá, a automação apenas torna o erro compartilhado mais rápido.