Remover dados confidenciais de um repositório

Sobre a remoção de dados confidenciais de um repositório

Ao alterar o histórico do repositório usando ferramentas como git-filter-repo, é fundamental entender as implicações. É necessário coordenar cuidadosamente com os colaboradores o processo de reescrever o histórico para que ele seja executado com êxito, e há uma série de efeitos colaterais que devem ser gerenciados.

É importante observar que, se os dados confidenciais que você precisa remover forem um segredo (por exemplo, senha/token/credencial), como costuma ser o caso, a primeira etapa será revogar e/ou alterar esse segredo. Após o segredo ser revogado ou alternado, ele não poderá mais ser usado para acesso, e isso pode ser suficiente para resolver o seu problema. Pode não ser necessário realizar as etapas extras de reescrever o histórico e remover o segredo.

Efeitos colaterais de reescrever o histórico

Reescrever o histórico traz alguns efeitos colaterais, que incluem:

•        **Alto risco de recontaminação**: infelizmente, é fácil voltar a efetuar push dos dados confidenciais para o repositório e fazer uma bagunça ainda maior.  Se um colega desenvolvedor tiver um clone anterior à reescrita e, depois da reescrita, simplesmente executar `git pull` seguido de `git push`, os dados confidenciais retornarão.  Eles precisam descartar o clone e clonar novamente ou seguir cuidadosamente várias etapas para limpar o clone deles primeiro.
  

•        **Risco de perder o trabalho de outros desenvolvedores**: se outros desenvolvedores continuarem atualizando branches que contêm os dados confidenciais enquanto você estiver tentando limpá-los, você precisará refazer a limpeza ou descartar o trabalho deles.
  

•        **Alteração dos hashes de commits**: A reescrita do histórico alterará os hashes dos commits que introduziram os dados sensíveis _e_ de todos os commits subsequentes.  Qualquer ferramenta ou automação que exigir que hashes de commit não sejam alterados será interrompida ou terá problemas.
  

•        **Desafios na proteção de filiais**: Se você tiver alguma proteção de filial que impeça a inserção forçada de dados, essas proteções precisarão ser desativadas (pelo menos temporariamente) para que os dados confidenciais sejam removidos.
  

•        **Visualização de diferenças quebrada para solicitações de pull fechadas**: A remoção dos dados confidenciais exigirá a remoção das referências internas usadas para exibir a visualização de diferenças em solicitações de pull, portanto, você não poderá mais ver essas diferenças.  Isso vale não apenas para a PR que introduziu os dados confidenciais, mas para qualquer PR baseada em uma versão do histórico posterior à mesclagem da PR com dados confidenciais (mesmo que essas PRs posteriores não tenham adicionado nem modificado nenhum arquivo com dados confidenciais).
  

•        **Interação ineficiente com solicitações de pull abertas**: alterações nos SHAs de commits resultarão em um diff de PR diferente, e os comentários no diff antigo do PR podem ser invalidados e perdidos, o que pode causar confusão para autores e revisores.  Recomendamos mesclar ou fechar todas as solicitações de pull abertas antes de remover arquivos do repositório.
  

•        **Perda de assinaturas em commits e tags**: as assinaturas de commits ou tags dependem dos hashes de commit. Como os hashes de commit são modificados por reescritas de histórico, as assinaturas deixarão de ser válidas e muitas ferramentas de reescrita de histórico (incluindo o `git-filter-repo`) simplesmente as removerão.  Na verdade, `git-filter-repo` também removerá as assinaturas de commits e as assinaturas de tags para commits anteriores à remoção dos dados sensíveis.  (Tecnicamente, é possível contornar isso usando a opção `--refs` para `git-filter-repo` caso seja necessário, mas, nesse caso, você precisará ter cuidado para garantir que todas as referências com dados confidenciais em seu histórico sejam especificadas e que os commits que introduziram esses dados confidenciais no seu intervalo estejam incluídos.)
  

•        **Direcionamento de outras pessoas para os dados confidenciais**: o Git foi criado com verificações de criptografia incorporadas nos identificadores de commit, de modo que pessoas mal-intencionadas não pudessem invadir um servidor e modificar o histórico sem serem detectadas.  Isso é útil da perspectiva de segurança, mas da perspectiva de dados confidenciais significa que expurgar esses dados é um processo de coordenação muito elaborado. Significa ainda que, quando você modifica o histórico, usuários atentos com um clone existente observarão a divergência de históricos e poderão usar isso para localizar com rapidez e facilidade os dados confidenciais que ainda estão no clone que você removeu do repositório central.
  

Sobre a exposição de dados confidenciais

A remoção de dados confidenciais de um repositório envolve quatro etapas gerais:

• Reescrever o repositório localmente usando git-filter-repo
• Atualize o repositório em GitHub usando seu histórico reescrito localmente
• Coordenar com colegas para limpar outros clones existentes
• Impedir repetições e evitar futuros vazamentos de dados confidenciais

Se você apenas reescrever o histórico e forçar o push, commits com dados confidenciais ainda poderão ser acessados em outros lugares:

• Em quaisquer clones ou forks do seu repositório
• Diretamente por meio de seus hashes SHA-1 em visualizações em cache no GitHub
• Por meio de quaisquer solicitações de pull que façam referências a eles

Não é possível remover dados confidenciais dos clones de outros usuários do seu repositório; você precisará enviar as instruções contidas em Garantir que as outras cópias foram limpas: clones de colegas no manual de git-filter-repo para que eles mesmos façam isso. No entanto, você pode remover permanentemente as exibições armazenadas em cache e as referências aos dados confidenciais em pull requests no GitHub entrando em contato com o conosco por meio do Portal de suporte do GitHub.

Se a confirmação que introduziu os dados confidenciais existir em qualquer fork, ela continuará acessível lá. Você precisará coordenar com os proprietários dos forks, pedindo-lhes para remover os dados confidenciais ou excluir o fork completamente. GitHub não é capaz de fornecer informações de contato para esses proprietários.

Considere essas limitações e desafios ao tomar a decisão de reescrever a história do repositório.

Como limpar um arquivo do histórico do repositório local usando o git-filter-repo

1. Instale a última versão da ferramenta git-filter-repo. É preciso ter uma versão com o sinalizador --sensitive-data-removal, o que significa, no mínimo, a versão 2.47. Você pode instalar o git-filter-repo manualmente ou usando um gerenciador de pacotes. Por exemplo, para instalar a ferramenta com HomeBrew, use o comando brew install.

   brew install git-filter-repo
   

   Para obter mais informações, confira INSTALL.md no repositório newren/git-filter-repo.

2. Clone o repositório no computador local. Confira Clonar um repositório.

   git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY
   

3. Navegue até o diretório de trabalho do repositório.

   cd YOUR-REPOSITORY
   

4. Execute um comando git-filter-repo para limpar os dados confidenciais.

   Se quiser excluir um arquivo específico de todos os branches/tags/referências, execute o seguinte comando substituindo PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA pelo caminho do Git para o arquivo que você deseja remover, não apenas o nome de arquivo (por exemplo, src/module/phone-numbers.txt):

   git-filter-repo --sensitive-data-removal --invert-paths --path PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA
   

   Importante

   Se o arquivo com os dados confidenciais existia em qualquer outro caminho (devido a ter sido movido ou renomeado), adicione um argumento --path extra para esse arquivo ou execute esse comando uma segunda vez nomeando o caminho alternativo.

   Se você quiser substituir todo o texto listado em ../passwords.txt em todos os arquivos não binários encontrados em qualquer lugar do histórico do repositório, execute o seguinte comando:

   git-filter-repo --sensitive-data-removal --replace-text ../passwords.txt
   

5. Verifique se você removeu tudo o que queria do histórico do repositório.

6. Descubra quantas pull requests serão afetadas negativamente por essa reescrita de histórico. Você precisará dessas informações abaixo.

   $ grep -c '^refs/pull/.*/head$' .git/filter-repo/changed-refs
   4
   

   Remova o -c para ver quais pull requests são afetadas:

   $ grep '^refs/pull/.*/head$' .git/filter-repo/changed-refs
   refs/pull/589/head
   refs/pull/602/head
   refs/pull/604/head
   refs/pull/605/head
   

   Essa saída inclui o número da solicitação de pull entre a segunda e a terceira barra. Se o número de pull requests afetadas for maior do que o esperado, você pode descartar esse clone sem efeitos nocivos e refazer a operação de reescrita ou abandonar a remoção dos dados confidenciais. Depois que você passar para a próxima etapa, a reescrita se tornará irreversível.

7. Quando estiver satisfeito com o estado do repositório, faça um push forçado das alterações locais para sobrescrever seu repositório em GitHub.com. Embora --force esteja implícito em --mirror, incluímos abaixo como um lembrete de que você está atualizando à força todos os ramificações, tags e refs, e descartando quaisquer alterações que outros possam ter feito nesses refs durante a limpeza do repositório.

   git push --force --mirror origin
   

   Esse comando não efetuará push de nenhuma referência que começa com refs/pull/, pois o GitHub marca as referências como somente leitura. Essas falhas de push serão abordadas na próxima seção. Em caso de falha no push de outras referências, é provável que você tenha a proteção de ramificação ativada para a ramificação em questão. Além disso, será necessário desativá-la temporariamente e refazer o push. Repita esta etapa até que as únicas falhas de atualização sejam as refs que começam com refs/pull/.

Remover completamente os dados do GitHub

Depois de usar git-filter-repo para remover os dados confidenciais e efetuar push das alterações para o GitHub, você precisa executar mais algumas etapas para remover por completo os dados do GitHub.

1. Entre em contato com o conosco por meio do Portal de suporte do GitHub e informe o seguinte:

   • O nome do proprietário e do repositório em questão (por exemplo, YOUR-USERNAME/YOUR-REPOSITORY).
   • O número de pull requests afetadas, encontradas na etapa anterior. Isso é usado pelo Suporte para verificar se você está ciente do quanto será afetado.
   • Os Primeiros Commits Alterados relatados pelo git-filter-repo (procure NOTE: First Changed Commit(s) na saída).
   • Se NOTE: There were LFS Objects Orphaned by this rewrite aparecer na saída do git-filter-repo (logo após o Primeiro Commit Alterado), mencione que você tinha objetos LFS órfãos e carregue o arquivo nomeado no tíquete também.

   Se você tiver limpado com êxito todas as referências que não sejam PRs e nenhum fork tiver referência aos dados confidenciais, o Suporte vai:

   • Desreferenciar ou excluir as PRs afetadas no GitHub.

   • Realizar uma coleta de lixo no servidor para remover definitivamente os dados confidenciais do armazenamento.

   • Remover as exibições armazenadas em cache.

   • Se objetos LFS estiverem envolvidos, exclua e/ou limpe os objetos LFS órfãos.

   Importante

   O Suporte do GitHub não removerá dados não confidenciais e só ajudará na remoção de dados confidenciais nos casos em que determinarmos que o risco não pode ser mitigado pela rotação das credenciais afetadas.

2. Os colaboradores devem realizar um rebase, e não uma fusão, de quaisquer ramificações que tenham criado a partir do histórico antigo (e corrompido) do seu repositório. Um commit de merge poderia reintroduzir o histórico antigo completo (ou parte dele) que você acabou de se dar ao trabalho de corrigir. Talvez eles também precisem realizar etapas adicionais; consulte Certifique-se de que outras cópias sejam limpas: clones de colegas no manual do git-filter-repo.

Evitar commits acidentais no futuro

Impedir que colaboradores façam commits acidentais pode ajudar a evitar que informações confidenciais sejam expostas. Para obter mais informações, confira Melhores práticas para evitar vazamentos de dados na sua organização.

Você pode realizar algumas ações para evitar commits ou pushes de itens que não devem ser compartilhados:

• Se os dados confidenciais provavelmente forem encontrados em um arquivo que não deve ser rastreado pelo git, adicione esse nome de arquivo a .gitignore (e faça commit e push dessa alteração para .gitignore para que outros desenvolvedores sejam protegidos).
• Evite embutir segredos em código. Use variáveis de ambiente ou serviços de gerenciamento de segredos como Azure Key Vault, AWS Secrets Manager ou HashiCorp Vault para gerenciar e injetar segredos em runtime.
• Crie um gancho de pré-commit para verificar dados confidenciais antes de serem commitados ou enviados a qualquer repositório, ou utilize uma ferramenta conhecida em um gancho de pré-commit, como git-secrets ou gitleaks. (Peça a cada colaborador que configure o gancho pré-commit que você escolher.)
• Use um programa visual como o GitHub Desktop ou o gitk para realizar o commit das alterações. Nos programas visuais, geralmente é mais fácil ver exatamente quais arquivos serão adicionados, excluídos e modificados em cada commit.
• Evite os comandos catch-all git add . e git commit -a na linha de comando: use git add filename e git rm filename para preparar os arquivos individualmente.
• Use git add --interactive para revisar e preparar alterações individualmente em cada arquivo.
• Use git diff --cached para revisar as alterações que você preparou para commit. Essa é a comparação exata que git commit produzirá, desde que você não use o sinalizador -a.
• Habilite a proteção por push para seu repositório para detectar e impedir que envios por push contendo segredos codificados sejam confirmados na sua base de código. Para saber mais, confira Sobre a proteção por push.

Leitura adicional

•         [
          `git-filter-repo` página de manual](https://htmlpreview.github.io/?https://github.com/newren/git-filter-repo/blob/docs/html/git-filter-repo.html), especialmente a subseção "Remoção de Dados Sensíveis" da seção "DISCUSSÃO".
  

•         [Pro Git: Ferramentas do Git – Reescrita do histórico](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)
  

•         [AUTOTITLE](/code-security/secret-scanning/introduction/about-secret-scanning)