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 a equipe e a organização se expostos inadvertidamente em sua base de código ou armazenados incorretamente.

Considere qualquer segredo vazado como comprometido imediatamente. É essencial que você siga as etapas de correção adequadas, como revogar o segredo. Apenas remover o segredo da base de código, efetuar push de um novo commit ou excluir e recriar o repositório não impede que o segredo seja explorado.

Este guia de instruções explica o que fazer se você fizer commit acidentalmente de um segredo em seu repositório ou se for alertado sobre um vazamento de segredo no repositório.

Pré-requisitos

• Você tem pelo menos acesso de gravação ao repositório.
• Opcional: o Secret scanning está habilitado para opcional repositório.

  Observação

  O Secret scanning é gratuito para repositórios públicos. Ele está disponível como parte do GitHub Advanced Security para repositórios privados nos planos GitHub Team e GitHub Enterprise Cloud.

Etapa 1. Identificar o segredo e estabelecer o contexto

Colete o máximo possível de informações sobre o segredo vazado. Isso ajudará você a avaliar o risco e determinar a melhor maneira de fazer a correçã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, 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. Trata-se da pessoa ou da equipe que criou o segredo ou é responsável por ele.
   • Verifique o arquivo CODEOWNERS do repositório para determinar a equipe responsável.
   • Use git log -S para ajudar a pesquisar no histórico de commits de seu repositório e identificar quem fez commit do segredo.

Etapa 2. Avaliação do risco

A maneira como você aborda a correção será determinada pelos fatores de risco associados ao vazamento do segredo.

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

Opção 1. O Secret scanning está habilitado

Examine o alerta do secret scanning associado ao vazamento, verificando os rótulos do 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 descrevendo 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 segredo. Para verificar se o seu tipo de segredo tem suporte, 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 do GitHub, verifique os metadados do alerta para obter informações sobre quando ele 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 tempo de inatividade ou interrupção se você revogar imediatamente o segredo.

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

Se você ainda não tiver o 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 indicações de que o segredo foi usado recentemente. Há commits ou pull requests recentes que fazem referência ao segredo? Há logs ou trilhas de auditoria que mostram o segredo sendo usado?
3. Avalie o arquivo que contém o segredo e o contexto em torno dele. O segredo é usado em um script de implantação de produção (risco maior) ou em um arquivo de teste (risco mais baixo)? 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 tempo de inatividade ou interrupção se você revogar imediatamente o segredo.

Etapa 3. Criar uma estratégia de correção

A próxima etapa depende da avaliação de risco executada na etapa anterior.

Agir rapidamente em caso de segredos de alto risco

Scanners automatizados podem localizar segredos expostos publicamente em minutos. Eles podem ser explorados por criminosos em um intervalo de horas. Quando mais tempo um segredo ativo é deixado exposto, maior é o potencial de ocorrerem violações graves.

Se o segredo for de alto risco (ou seja, 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 do segredo imediatamente. Confira a Etapa 4.

   Observação

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

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

Planejar-se para segredos de médio a baixo risco

Se o segredo for de médio a baixo risco (ou seja, 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 correção adequadamente:

1. Usando as informações coletadas na Etapa 1, localize a equipe responsável pelo segredo e alerte-os sobre o vazamento do segredo.
2. Explique o que foi vazado e quando. Explique que você precisará revogar o segredo, gerar um novo segredo e que os serviços afetados exigirão atualização.
3. Informe os administradores do repositório e os líderes de segurança sobre o vazamento, explicando todas as ações de correção necessárias ou já executadas.
4. Planeje um horário para revogação e rotação junto com a equipe apropriada para coordenar uma transição suave.

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

Etapa 4. Revogar o segredo

Não é suficiente simplesmente remover o segredo da base de código. A etapa de correção mais importante é revogar o segredo com o provedor dele. Revogando o segredo, você reduz drasticamente o potencial para que ele seja explorado.

1. Usando as informações reunidas na Etapa 1, localize o site ou a documentação do provedor do segredo.

2. Siga as instruções do provedor para revogar o segredo. Normalmente, isso envolve fazer logon no portal do provedor e navegar até a seção em que o segredo é gerenciado.

   Se você não tiver 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 com a revogação do segredo.

3. Gere um novo segredo, se necessário, para substituir o segredo revogado. Geralmente isso é necessário para restaurar a funcionalidade para serviços que se baseiam no segredo original.

Etapa 5: Identificar e atualizar os serviços afetados

Em seguida, você precisa coordenar as atualizações para todos os serviços afetados usando o segredo vazado e atualizá-las com o novo segredo.

Identificar

1. Use a pesquisa de código do GitHub para verificar todos os códigos, issues e pull requests do segredo.
   • Pesquise em toda a organização usando org:YOUR-ORG "SECRET-STRING".
   • Pesquise em seu repositório usando repo:YOUR-REPO "SECRET-STRING".
2. Verifique as chaves de implantação armazenadas e os segredos e variáveis do repositório.
   • Clique em "Settings" e, em "Security," clique em Secrets and variables ou Deploy keys.
3. Verifique se há GitHub Apps instalados e integrações que possam usar o segredo.

Coordenada

1. Instrua o Copilot a criar issues (e issues secundários) para cada tarefa envolvida na atualização de um serviço afetado.
2. Se vários stakeholders estiverem envolvidos, crie um quadro de projeto para os issues para acompanhar o progresso e facilitar a comunicação.

Atualizar e verificar

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

   Dica

   Uma maneira segura de fornecer credenciais confidenciais para o aplicativo é por meio de um cofre. Por exemplo, você pode disponibilizar credenciais confidenciais para ações e fluxos de trabalho do GitHub por meio do repositório "Secrets and variables" 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. Verificar se há acesso não autorizado

Depois que os serviços voltarem a funcionar, é importante verificar se algum acesso não autorizado pode ter ocorrido enquanto o segredo foi exposto.

1. Examine os logs de auditoria do GitHub para eventos relacionados ao segredo e seu uso.

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

   Para logs de auditoria no nível da empresa e da organização, você pode pesquisar especificamente eventos relacionados a um token de acesso. Confira 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 do GitHub depende de sua função, portanto, talvez seja necessário entrar em contato com um proprietário da organização ou administrador da empresa se você não tiver as permissões necessárias.

2. Examine os logs de auditoria do provedor do segredo.

   • Por exemplo, para o Amazon Web Services (AWS), você pode verificar os logs do CloudTrail em caso de tentativas de acesso não autorizado usando o segredo vazado. Confira O que é o AWS CloudTrail? na documentação do AWS CloudTrail.

Etapa 7. Limpar o repositório

Embora você tenha revogado e atualizado o segredo em sua base de código, ele ainda pode existir no histórico de commits do repositório. Idealmente, pesquise e remova todas as instâncias do segredo do repositório.

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

Junto com os líderes de segurança do repositório, considere 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.

Etapa 8. Resolver o alerta

1. Feche o alerta do secret scanning no repositório selecionando Close as e marcando o alerta como "Revoked".
2. Documente o incidente na base de dados de conhecimento ou no sistema de gerenciamento de incidentes da sua equipe, incluindo as etapas adotadas para corrigir o vazamento e todas as lições aprendidas.

Etapa 9. Evitar vazamentos adicionais

Lidar com vazamentos de segredo geralmente é disruptivo, complicado e demorado. O foco para o tratamento de segredos sempre deve ser evitar vazamentos a qualquer custo:

1. Certifique-se de que a proteção por push (parte do GitHub Advanced Security) seja habilitada para o repositório, se ainda não estiver. Explore a implementação de controles de bypass estritos para que somente usuários confiáveis possam ignorar a proteção por push. Confira Sobre a proteção por push.
2. Verifique se você tem "Push protection for users" habilitado em sua conta pessoal, o que o protege contra o envio acidental de segredos com suporte para qualquer repositório público.
3. Defenda ou implemente práticas recomendadas para o gerenciamento de segredos em sua equipe ou organização:
   • Use variáveis de ambiente para armazenar segredos em vez de codificá-los na base de código.
   • Use ferramentas de gerenciamento de segredo, como o repositório "Secrets and variables" do GitHub, na página de configurações do repositório, para armazenar e gerenciar segredos com segurança.
   • Gire segredos regularmente para minimizar o impacto de possíveis vazamentos.
4. Documente incidentes e etapas de correção para ajudar sua equipe a aprender com erros anteriores e melhorar as práticas futuras.
5. Defenda e realize treinamentos regulares de segurança e aprendizado. Confira, por exemplo, o curso Segurança Avançada do GitHub do Microsoft Learn.

Leitura adicional

• Sobre a verificação de segredo
• Sobre a proteção por push
• Padrões de varredura de segredos com suporte
• Sobre a Segurança Avançada do GitHub