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 tutorial explica o que fazer se você tiver acidentalmente confirmado um segredo em seu repositório ou se tiver sido alertado sobre um vazamento secreto em seu repositório.

Pré-requisitos

• Você precisa ter pelo menos permissão de escrita no repositório.
• Opcional: Secret scanning está habilitado para o repositório.

  Observação

  Secret scanning é gratuito para repositórios públicos. Ele está disponível como parte de 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 GitHubpersonal access token (PAT), uma chave de API OpenAI, 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.

Secret scanning pode ajudá-lo a avaliar o risco associado a um alerta, mas se você ainda não tiver secret scanning habilitado, ainda poderá executar uma avaliação de risco com base nas informações disponíveis para você.

Opção 1.

Secret scanning está habilitado

Examine o secret scanning alerta associado ao vazamento, verificando os rótulos de alerta e todos os 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 GitHub PAT, verifique os metadados de 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 tiver secret scanning habilitado para o repositório, execute 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 pesquisa de código do GitHub para verificar todo o código, problemas e pull requests 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á quaisquer GitHub Apps instalados e integrações que possam usar o segredo.

Coordinate

1. Instrua Copilot a criar tarefas (e subtarefas) para cada tarefa envolvida na atualização de um serviço afetado. Consulte Usando GitHub Copilot para criar ou atualizar problemas.
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 GitHub ações e fluxos de trabalho por meio do repositório "Segredos e variáveis" na página de configurações do 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. Revise os logs 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 logs de auditoria de GitHub depende da sua função, portanto talvez seja necessário entrar em contato com um proprietário da organização ou um administrador da empresa se você não tiver 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 secret scanning alerta 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. Verifique se a proteção por push (parte de GitHub Secret Protection) está 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 Proteção por Notificações 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.
   • Use ferramentas de gerenciamento de segredos como GitHubo repositório "Segredos e variáveis" na página de configurações do 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 GitHub Advanced Security do Microsoft Learn.