Corrigindo um segredo vazado em seu repositório

Introdução

Segredos, como chaves de API, tokens e credenciais, podem representar riscos de segurança significativos para sua equipe e organização se forem expostos inadvertidamente em sua base de código ou armazenados de forma inadequada.

Qualquer segredo vazado deve ser considerado como estando imediatamente comprometido, sendo essencial que você tome as medidas corretivas adequadas, como a revogação do segredo. Simplesmente remover o segredo da base de código, enviar um novo commit ou excluir e recriar o repositório não impede que o segredo seja explorado.

Este guia prático explica o que fazer se você acidentalmente adicionou um segredo ao seu repositório ou se foi alertado sobre um vazamento de segredos no seu repositório.

Pré-requisitos

• Você precisa ter pelo menos permissão de escrita no repositório.
• Opcional: Secret scanning is enabled for the repository.

  Observação

  Secret scanning é gratuito para repositórios públicos. Está disponível como parte do pacote GitHub Secret Protection para repositórios privados nos planos GitHub Team e GitHub Enterprise Cloud.

Etapa 1. Identifique o segredo e reúna o contexto.

Reúna o máximo de informações possível sobre o segredo vazado. Isso ajudará você a avaliar o risco e determinar o melhor curso de ação para a remediação.

1. Determine o tipo de segredo e seu provedor.
   • Por exemplo, o segredo é um GitHub personal access token (PAT), uma chave de API da OpenAI ou uma chave privada SSH?
2. Localize o repositório, o arquivo e a linha que contêm o segredo vazado.
3. Identifique o proprietário do segredo. Essa é a pessoa ou equipe que criou o segredo, ou é responsável por ele.
   • Verifique o arquivo CODEOWNERS do repositório para determinar a equipe responsável.
   • Utilize a ferramenta git log -S para ajudar a pesquisar o histórico de commits do seu repositório e identificar quem fez o commit do segredo.

Etapa 2. Avaliação do risco

A forma como você abordará a remediação será determinada pelos fatores de risco associados ao vazamento do segredo.

O recurso Secret scanning pode ajudar você a avaliar o risco associado a um alerta, mas se você ainda não ativou secret scanning, ainda pode fazer uma avaliação de risco com base nas informações disponíveis.

Opção 1. Secret scanning está ativado

Analise o alerta secret scanning associado ao vazamento, verificando os rótulos do alerta e quaisquer metadados disponíveis:

1. Verifique o status de validade do segredo para determinar se ele ainda está ativo. O alerta incluirá um status que descreve se o segredo está ativo, inativo ou se sua validade é desconhecida.

   Observação

   • As verificações de validade estão disponíveis apenas para determinados tipos de segredos. Para verificar se o seu tipo de segredo é compatível, consulte Padrões de varredura de segredos com suporte.
   • O provedor do segredo é sempre a fonte de verdade mais confiável para determinar a validade de um segredo.
2. Verifique o rótulo public exposure para determinar se o segredo foi vazado em um repositório público.
3. Verifique o rótulo multiple leaks para determinar se o segredo está exposto em vários locais.
4. Se o segredo for um PAT (Personal Access Type) do tipo GitHub, verifique os metadados do alerta para obter informações sobre quando o segredo foi usado pela última vez e seu escopo de acesso.
5. Avalie quais serviços ou aplicativos dependem do segredo e considere o potencial de inatividade ou interrupção caso o segredo seja revogado imediatamente.

Opção 2. Secret scanning não está habilitado

Se você ainda não habilitou o recurso secret scanning para o repositório, realize uma avaliação de risco com base no seguinte:

1. Verifique a visibilidade do repositório. O repositório é público?
2. Procure indícios de que o segredo foi usado recentemente. Há algum commit ou solicitação de pull recente que faça referência ao segredo? Existem logs ou trilhas de auditoria que mostrem o uso do segredo?
3. Analise o arquivo que contém o segredo e o contexto em que ele está inserido. O segredo é usado em um script de implantação de produção (risco maior) ou em um arquivo de teste (risco menor)? O segredo está associado a uma credencial de banco de dados ou chave de administrador (risco maior)?
4. Avalie quais serviços ou aplicativos dependem do segredo e considere o potencial de inatividade ou interrupção caso o segredo seja revogado imediatamente.

Etapa 3. Elabore uma estratégia de remediação

O próximo passo depende da avaliação de risco que você realizou na etapa anterior.

Aja rapidamente em casos de segredos de alto risco

Sistemas de varredura automatizados conseguem localizar segredos expostos publicamente em minutos. Elas podem ser exploradas por agentes maliciosos em questão de horas. Quanto mais tempo um segredo ativo permanecer exposto, maior será o potencial para violações graves.

Se o segredo for de alto risco (ou seja, se o segredo ainda estiver ativo, estiver exposto em um repositório público ou for uma credencial de produção), recomendamos que você:

1. Priorize a revogação imediata do segredo. Veja a Etapa 4.

   Observação

   Se você estiver preocupado com a possibilidade de indisponibilidade dos serviços, talvez queira primeiro gerar um novo segredo com as mesmas permissões, fazer com que o aplicativo comece a usar o novo token e, em seguida, revogar o segredo antigo.

2. Comunique-se com o proprietário do segredo (identificado na Etapa 1), os administradores do repositório e os responsáveis pela segurança durante ou após a revogação.

Planeje para segredos de risco médio a baixo

Se o segredo apresentar risco médio a baixo (ou seja, se o segredo não estiver mais ativo, estiver exposto em um repositório privado ou for uma credencial de teste ou desenvolvimento), você poderá planejar a estratégia de remediação de acordo:

1. Utilizando as informações coletadas na Etapa 1, localize a equipe responsável pelo segredo e alerte-a sobre o vazamento.
2. Explique o que vazou e quando. Explique que será necessário revogar o segredo, gerar um novo segredo e que os serviços afetados precisarão ser atualizados.
3. Informe os administradores do repositório e os responsáveis ​​pela segurança sobre o vazamento, explicando quaisquer ações corretivas necessárias ou já tomadas.
4. Planeje um cronograma para a revogação e o rodízio junto com a equipe apropriada para coordenar uma transição tranquila.

É importante corrigir até mesmo segredos de risco médio a baixo, pois eles ainda podem representar um risco tanto para a segurança quanto para a conformidade se permanecerem expostos.

Etapa 4. Revogar o segredo

Não basta simplesmente remover o segredo da sua base de código. A etapa de remediação mais importante é revogar o segredo junto ao provedor do segredo. Ao revogar o segredo, você reduz drasticamente o potencial de exploração do mesmo.

1. Utilizando as informações coletadas na Etapa 1, localize o site ou a documentação do fornecedor do segredo.

2. Siga as instruções do fornecedor para revogar o segredo. Normalmente, isso envolve acessar o portal do provedor e navegar até a seção onde o segredo é gerenciado.

   Caso não tenha acesso ao portal do provedor, entre em contato com o proprietário do segredo ou com o administrador do repositório relevante para obter ajuda na revogação do segredo.

3. Se necessário, gere um novo segredo para substituir o segredo revogado. Isso geralmente é necessário para restaurar a funcionalidade de serviços que dependiam do segredo original.

Passo 5: identificar e atualizar os serviços afetados

Em seguida, você precisa coordenar as atualizações em todos os serviços afetados que utilizam o segredo vazado e atualizá-los com o novo segredo.

Identify

1. Use a função de busca de código do GitHub para verificar todo o código, problemas e solicitações de pull em busca do segredo.
   • Pesquise em toda a sua organização usando org:YOUR-ORG "SECRET-STRING".
   • Pesquise seu repositório usando repo:YOUR-REPO "SECRET-STRING".
2. Verifique as chaves de implantação, os segredos e as variáveis armazenadas no repositório.
   • Clique em "Configurações" e, em seguida, em "Segurança", clique em Segredos e variáveis ou Implantar chaves.
3. Verifique se há algum aplicativo GitHub Apps instalado e alguma integração que possa usar o segredo.

Coordinate

1. Instrua Copilot a criar problemas (e subproblemas) para cada tarefa envolvida na atualização de um serviço afetado.
2. Caso haja várias partes interessadas envolvidas, crie um quadro de projeto para as questões a fim de acompanhar o progresso e facilitar a comunicação.

Atualize e verifique

1. Atualize seu aplicativo com o novo segredo, garantindo que ele utilize corretamente a nova credencial.

   Dica

   Uma forma segura de fornecer credenciais confidenciais para sua aplicação é através de um cofre digital. Por exemplo, você pode disponibilizar credenciais confidenciais para ações e fluxos de trabalho do GitHub por meio do armazenamento "Segredos e variáveis" na página de configurações do seu repositório.

2. Teste os serviços afetados para garantir que estejam funcionando corretamente com o novo segredo.

Etapa 6. Verifique se há acessos não autorizados

Assim que os serviços voltarem a funcionar, é importante verificar se ocorreu algum acesso não autorizado enquanto o segredo estava exposto.

1. Analise os registros de auditoria de GitHub em busca de eventos relacionados ao segredo e ao seu uso.

   • Registro de segurança da sua conta pessoal. Confira Revisar seus logs de segurança.
   • Registro de auditoria da sua organização. Confira Revisar o log de auditoria da organização.
   • Registro de auditoria para sua empresa. Confira Auditar eventos de log para sua empresa.

   Para os registros de auditoria em nível organizacional e empresarial, você pode pesquisar especificamente por eventos relacionados a um token de acesso. Consulte Identificar eventos de log de auditoria executados por um token de acesso (organizações) e Identificar eventos de log de auditoria executados por um token de acesso (empresas).

   O acesso aos registros de auditoria de GitHub depende da sua função, portanto, pode ser necessário entrar em contato com o proprietário da organização ou com o administrador corporativo caso você não tenha as permissões necessárias.

2. Analise os logs de auditoria do provedor de segredos.

   • Por exemplo, para segredos da Amazon Web Services (AWS), você pode verificar os registros do CloudTrail em busca de tentativas de acesso não autorizado usando o segredo vazado. Consulte a seção O que é o AWS CloudTrail? na documentação do AWS CloudTrail.

Etapa 7. Limpe o repositório

Embora você já tenha revogado e atualizado o segredo em sua base de código, o segredo ainda pode existir no histórico de commits do seu repositório. Idealmente, você deve procurar e remover todas as instâncias do segredo do seu repositório.

No entanto, limpar o histórico do Git pode ser um processo destrutivo e disruptivo, pois pode envolver o envio forçado de alterações para o repositório.

Em conjunto com os responsáveis ​​pela segurança do seu repositório, avalie cuidadosamente os efeitos da limpeza do histórico do repositório em relação às suas obrigações de conformidade ou segurança. Confira Remover dados confidenciais de um repositório.

Passo 8. Resolver o alerta

1. Feche o alerta secret scanning no repositório selecionando Fechar como e marcando o alerta como "Revogado".
2. Documente o incidente na base de conhecimento da sua equipe ou no sistema de gerenciamento de incidentes, incluindo as medidas tomadas para remediar o vazamento e quaisquer lições aprendidas.

Etapa 9. Evitar novos vazamentos

Lidar com vazamentos de informações confidenciais costuma ser um processo disruptivo, complicado e demorado. O foco no tratamento de informações confidenciais deve ser sempre a prevenção de vazamentos a todo custo:

1. Certifique-se de que a proteção contra push (parte de GitHub Secret Protection) esteja habilitada para o repositório, caso ainda não esteja. Explore a possibilidade de implementar controles de bypass rigorosos, para que apenas usuários confiáveis​possam ignorar a proteção contra notificações push. Confira Sobre a proteção por push.
2. Certifique-se de que a opção "Proteção contra envio de dados para usuários" esteja ativada em sua conta pessoal. Isso impede o envio acidental de segredos compatíveis para qualquer repositório público.
3. Defenda ou implemente as melhores práticas para a gestão de segredos dentro da sua equipe ou organização:
   • Utilize variáveis ​​de ambiente para armazenar segredos em vez de codificá-los diretamente no código.
   • Utilize ferramentas de gerenciamento de segredos, como o recurso "Segredos e variáveis" do GitHub, localizado na página de configurações do seu repositório, para armazenar e gerenciar segredos com segurança.
   • Rotacione os segredos regularmente para minimizar o impacto de possíveis vazamentos.
4. Documente os incidentes e as medidas corretivas para ajudar sua equipe a aprender com os erros do passado e aprimorar as práticas futuras.
5. Defenda e participe de treinamentos regulares de aprendizagem e segurança. Veja, por exemplo, o curso de Segurança Avançada GitHub do Microsoft Learn.

Leitura adicional

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

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

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

•         [AUTOTITLE](/get-started/learning-about-github/about-github-advanced-security)