Empurrado acidentalmente .env Segredos ou chaves AWS para um repositório público do GitHub: por que a exclusão do arquivo não o oculta¶

Percebendo dez segundos depois de correr git push origin main (ou lançando um repositório privado para Public) que seu commit incluiu um texto simples .env arquivo, um AWS AKIA... Chave de acesso e chave secreta, uma chave de API OpenAI/Anthropic, um Stripe sk_live_... token de produção, um URI de banco de dados PostgreSQL/MongoDB com senha ou um URI não criptografado $HOME/.ssh/id_ed25519 a chave privada é uma emergência de segurança cibernética de cinco alarmes. Botnets automatizados de coleta de credenciais pesquisam continuamente o público GitHub Events Firehose (api.github.com/events) e clonar commits recém-enviados dentro de 1,5 a 4 segundos do seu git push completando. Pior ainda, quase todos os desenvolvedores em pânico cometem exatamente o mesmo erro fatal: excluem o .env arquivo localmente, adicione .env para .gitignoree envie um segundo commit intitulado "remove .env" ou "oops". Enviando um segundo commit que exclui .env não esconde nada: o segredo do texto simples permanece 100% legível para sempre dentro do diff do commit anterior (git log -p), e mesmo se você forçar o push (git push --force) sobre a ramificação, o commit não referenciado (dangling blob) permanece acessível publicamente por meio de seu URL direto do GitHub e visualizações de solicitação pull em cache até que seja explicitamente eliminado. Se a credencial vazada já tiver sido usada por invasores para implantar ransomware, sequestrar seu domínio DNS ou bloquear seu locatário de nuvem, consulte nossos guias complementares em resposta a ransomware e malware, sequestro de nome de domínio, DNS expirado e controle de sitee Bloqueio de administrador de domínio personalizado do Google Workspace ou Microsoft 365. Se um vazamento de credencial afetar a segurança do paciente do hospital, os controles industriais físicos ou a infraestrutura de despacho de emergência, ligue para o número de emergência local (911 nos Estados Unidos e no Canadá, 112 em toda a União Europeia, 999 no Reino Unido) ou consulte nosso diretório internacional de números de emergência.

Faça isso agora¶

1. REVOGAR, DESATIVAR E GIRAR todos os segredos expostos no console do provedor PRIMEIRO - nos primeiros 120 segundos - antes de perder um único segundo em execução git comandos: quando um segredo atinge um repositório público GitHub, GitLab ou Bitbucket por até 3 segundos, trate essa chave como permanentemente queimada e já nas mãos de invasores automatizados. Nenhuma quantidade de git reset --hard, git push --force, ou excluir o repositório pode apagar uma chave do banco de dados de um scraper bot que já baixou seu commit no segundo nº 2. Faça login nas configurações AWS IAM, Stripe, OpenAI, consoles de banco de dados ou GitHub SSH agora mesmo e Desative/Exclua/Role a chave imediatamente.
2. **Audite seu Cloud Billing e registros de auditoria (AWS CloudTrail, GCP Cloud Audit Logs, Stripe Logs) para a janela entre o seu git push e sua revogação de chave **: uso de bots de criptografia automatizados vazados AWS_ACCESS_KEY_ID (AKIA...) credenciais dentro de 30 a 90 segundos para ativar instâncias de GPU com cota máxima (p4d.24xlarge / g5.48xlarge) em todas as regiões ocultas da AWS (ap-east-1, me-south-1, af-south-1) e criar usuários IAM backdoor ou Lambda ganchos de persistência para que permaneçam dentro de sua conta AWS mesmo depois de você excluir a chave vazada.
3. NUNCA pressione um segundo "Delete .env" commit - na verdade, digitando "delete secret" ou "remove password" em uma mensagem de commit atrai bots scraper direcionados: Milhares de scripts de atores de ameaças consultam especificamente o GitHub Search por mensagens de commit contendo "remove .env", "delete key", "oops"e "remove credentials"e clique em um commit retroativo no histórico para roubar a chave.
4. Reescreva todo o histórico do repositório Git localmente usando git filter-repo (ou BFG Repo-Cleaner) para extirpar o arquivo ou editar a string de senha de cada commit histórico, árvore e tag: git filter-branch está oficialmente obsoleto pelo projeto Git; usar git filter-repo --invert-paths --path .env (para destruir um arquivo de todos os commits) ou git filter-repo --replace-text expressions.txt (para substituir sequências de senha específicas por ***REMOVED*** dentro de arquivos de código sem excluir os arquivos).
5. Forçar o push de todas as ramificações e tags (git push origin --force --all), E limpe as visualizações de commit em cache do lado do servidor do GitHub (dangling commits): Aqui está o segredo que a maioria dos desenvolvedores não conhece: mesmo depois de executar git filter-repo e git push --force, Os servidores do GitHub mantêm o antigo commit SHA ativo em seu cache de objetos (git cat-file), o que significa que qualquer pessoa que gravou o commit SHA de 40 caracteres da API pública de eventos ainda pode visualizar github.com/user/repo/commit/<OLD_SHA>. Explicamos abaixo como limpar imediatamente caches de commit pendentes por meio do suporte/API do GitHub ou excluindo e recriando o repositório.
6. **Instale um local pre-commit scanner secreto (gitleaks ou trufflehog) dentro .git/hooks/pre-commit antes de escrever outra linha de código **: um período de 10 segundos gitleaks protect --staged o gancho de pré-confirmação inspeciona cada linha preparada localmente em seu laptop e bloqueia git commit antes que um segredo possa sair da sua máquina.

Árvore de decisão: contenção imediata, rotação e eliminação do histórico do Git¶

Execute este fluxo de trabalho em ordem cronológica estrita (Revogar PRIMEIRO -> Persistência de auditoria SEGUNDO -> Limpar histórico do Git TERCEIRO):

flowchart TD
    Start["Segredo enviado para repositório público (.env, chave AWS/GCP, senha do banco de dados, chave Stripe/OpenAI ou chave SSH privada)"] --> Step1["MINUTO 0 A 2 (PRIORIDADE #1): Revogar/Rolar todas as chaves expostas no console do provedor imediatamente"]

    Step1 --> SecretType{"Que tipo de credencial estava dentro do commit?"}

    SecretType -->|"Chave de infraestrutura em nuvem (AWS AKIA, conta de serviço GCP JSON, Azure SP)"| CloudAudit["MINUTO 2 A 10: Verifique CloudTrail/logs de atividades -> Encerrar instâncias de EC2/computação não autorizadas em todas as regiões -> Excluir usuários/funções/sessões STS não autorizados do IAM"]

    SecretType -->|"URI/senha do banco de dados (Postgres, MySQL, MongoDB, Redis, Supabase)"| DBAudit["MINUTO 2 A 10: Alterar a senha do usuário do banco de dados + eliminar conexões ativas (pg_terminate_backend) + bloquear o grupo de segurança do firewall apenas para IPs na lista de permissões"]

    SecretType -->|"Token de API ou chave SSH (Stripe, OpenAI, GitHub PAT, Slack, chave SSH privada)"| TokenAudit["MINUTO 2 A 10: Role a chave da API no painel / Remova a chave SSH pública de $HOME/.ssh/authorized_keys e configurações do GitHub -> Auditar registros recentes de uso da API"]

    CloudAudit --> RepoVisibility{"MINUTO 10 A 20: Como você deseja limpar o repositório GitHub?"}
    DBAudit --> RepoVisibility
    TokenAudit --> RepoVisibility

    RepoVisibility -->|"Limpeza de cache 100% mais rápida (sem problemas críticos/histórico de estrelas para manter)"| NukeRepo["1. Exclua todo o repositório nas configurações do GitHub. 2. Execute git filter-repo localmente para limpar o histórico. 3. Crie novo repositório e histórico de limpeza por push (destrói instantaneamente todos os SHAs de commit em cache)"]

    RepoVisibility -->|"Deve preservar estrelas, problemas, relações públicas e garfos de repositório existentes"| RewriteRepo["1. Execute git filter-repo (--invert-paths ou --replace-text). 2. Execute git push --force --all & --tags. 3. Entre em contato com o suporte / portal de suporte do GitHub para limpar o cache SHA de commit pendente"]

Fase 1: Minuto 0 a 2 - Folha de dicas de revogação imediata pelo provedor¶

Não abra um terminal para brigar git rebase enquanto suas chaves de produção ainda estão ativas. Clique diretamente no provedor afetado abaixo e elimine a credencial primeiro:

Fase 2: Minuto 2 a 10 - Verificando se os invasores já criaram um backdoor (AWS/contenção de nuvem)¶

Se você vazou .env arquivo continha uma ** chave de acesso AWS (AKIA...)**, Google Cloud Service Account JSON ou Azure Service Principal, excluir a chave vazada é apenas metade da batalha. Você deve verificar se um bot automatizado não usou esses 90 segundos para estabelecer persistência dentro de sua conta na nuvem:

A auditoria forense pós-vazamento da AWS de 6 pontos¶

1. Verificar AWS CloudTrail -> Event history para todas as chamadas de API feitas pelo vazamento Access Key ID:
2. Abra o Console do AWS CloudTrail -> Histórico de eventos.
3. Altere o menu suspenso de pesquisa de Somente leitura para Access key ID e cole o que vazou AKIA... corda.
4. Veja todos os eventos registrados desde o minuto em que você executou git push. Procure especificamente: CreateUser, CreateAccessKey, AttachUserPolicy, CreateRole, AssumeRole, GetSessionToken, RunInstances (EC2), RequestSpotInstances, CreateFunction (Lambda), ou SendEmail (spam SES).
5. Revogar qualquer temporário ativo STS sessões geradas por esse usuário:
6. Mesmo depois de excluir um AKIA... chave de acesso, se o invasor ligou sts:GetSessionToken antes de você excluir a chave, seu temporário ASIA... o token de sessão permanece válido por até 36 horas.
7. Para matar todos os temporários ativos STS tokens para esse usuário IAM imediatamente, vá para IAM -> Users -> [Leaked User] -> Permissions -> Add inline policy e clique em Revoke sessions (que anexa um explícito Deny * política para qualquer token emitido onde aws:TokenIssueTime é mais cedo do que agora.).
8. Verificar IAM -> Users e IAM -> Roles para contas backdoor recém-criadas:
9. Classifique todos os usuários do IAM por Hora de criação. Exclua qualquer usuário desconhecido (admin-backup, sys-monitor, support-bot) e verifique o Trust relationships em suas funções do IAM para garantir que o invasor não adicionou seu próprio ID de conta externo da AWS ("Principal": {"AWS": "arn:aws:iam::999999999999:root"}) como um principal confiável.
10. Usar AWS Resource Explorer ou EC2 Global View para verificar TODAS as mais de 30 regiões da AWS em busca de criptomineradores ocultos:
11. Os invasores raramente lançam instâncias de criptomineração em us-east-1 onde você os verá em seu painel. Em vez disso, eles lançam p4d, g5, ou c6i.32xlarge instâncias em ap-southeast-3 (Jacarta), me-central-1 (Emirados Árabes Unidos), il-central-1 (Tel Aviv), ou sa-east-1 (São Paulo).
12. Abrir EC2 Console -> EC2 Global View (que verifica todas as regiões habilitadas em uma única tabela) e Encerrar quaisquer instâncias não autorizadas imediatamente.
13. Abra um caso de cobrança do AWS Support imediatamente se instâncias não autorizadas gerarem uma fatura:
14. Se um bot girasse $8,000 das instâncias de GPU EC2 antes de encerrá-las, não entre em pânico: depois de proteger a conta, excluir a chave, ativar root/IAM MFAe removeu a chave do GitHub, abra um Caso de suporte de cobrança e conta da AWS explicando o push acidental do GitHub e suas etapas de correção. A AWS concede rotineiramente um crédito único de perdão de cobrança de boa vontade para vazamentos acidentais de chaves do GitHub, uma vez que sua equipe de segurança verifica se o repositório está limpo.

Fase 3: Por que a exclusão do arquivo em um novo commit falha - e como reescrever corretamente o histórico com git filter-repo¶

1. Por que git rm .env && git commit -m "delete .env" é completamente inútil¶

Git é um sistema de arquivos endereçável por conteúdo somente por acréscimo (Directed Acyclic Graph / DAG de commits, árvores e objetos blob): - Suponha Comprometer A1B2C3 adicionado .env (Blob 998877). - Suponha que 2 minutos depois você corra git rm .env, adicione .env para .gitignoree pressione Commit D4E5F6. - Enquanto alguém navegando na lista de arquivos atual na sua página inicial do GitHub não verá .env, ** Confirmar A1B2C3 e Blob 998877 ainda fazem 100% parte do repositório.** Qualquer pessoa que execute git clone downloads Blob 998877, qualquer pessoa que clicar na guia "Commits" no GitHub pode clicar A1B2C3 para ler o seu .env arquivo em texto simples e ferramentas automatizadas (trufflehog git https://github.com/user/repo) verifica cada commit histórico em 2 segundos.

2. Passo a passo: Apagando um arquivo ou string secreta em TODO o histórico usando git filter-repo¶

O projeto Git e o GitHub recomendam oficialmente git-filter-repo (que substitui o lento e sujeito a erros git filter-branch e é ainda mais flexível do que BFG Repo-Cleaner).

1. Instalar git-filter-repo (Leva 5 segundos):

   # On macOS (Homebrew):
   brew install git-filter-repo
   
   # On Linux / Windows (via pip / apt):
   pip3 install git-filter-repo
   

2. Faça uma cópia de segurança da pasta do seu repositório local antes de reescrever o histórico:

   cp -r $HOME/projects/my-repo $HOME/projects/my-repo-backup
   cd $HOME/projects/my-repo
   

   (Nota: Se você já moveu seu válido .env arquivar, certifique-se de uma cópia limpa de .env é salvo em /tmp/.env.safe fora do repo, porque git filter-repo vai limpar .env do seu diretório de trabalho também.)
3. Escolha a opção A (apagar todo o caminho do arquivo, como .env ou id_rsa) OU Opção B (redigir sequências secretas específicas dentro de arquivos de código):
4. Opção A: remover completamente .env (ou config/secrets.json) de cada commit no histórico:

   git filter-repo --invert-paths --path .env --force
   

   (Por que --invert-paths? Sem --invert-paths, git filter-repo --path .env mantém SOMENTE .env e exclui todo o resto. Combinando --invert-paths --path .env diz ao Git para manter tudo, EXCETO .env em todos os commits, ramificações e tags.)
5. Opção B: Mantenha o arquivo de código (app.py / config.js), mas limpe a string secreta codificada de cada versão histórica: Crie um arquivo de texto /tmp/secrets-to-scrub.txt contendo uma string secreta (ou regex) por linha:

   AKIAIOSFODNN7EXAMPLE==>REDACTED_AWS_KEY
   sk_live_51NzExampleSecretKey999==>REDACTED_STRIPE_KEY
   regex:postgres:\/\/non_at_chars@==>postgres://REDACTED_DB_CREDENTIALS@
   

   Agora corra git filter-repo --replace-text:

   git filter-repo --replace-text /tmp/secrets-to-scrub.txt --force
   shred -u /tmp/secrets-to-scrub.txt 2>/dev/null || rm -P /tmp/secrets-to-scrub.txt
   

6. Adicionar .env para .gitignore então você não confirma novamente daqui a 5 minutos:

   echo ".env" >> .gitignore
   echo "*.pem" >> .gitignore
   git add .gitignore
   git commit -m "chore: update gitignore rules"
   

7. ** Adicione novamente seu GitHub remoto (git filter-repo remove intencionalmente origin como uma verificação de segurança) e forçar o push de todas as ramificações e tags**:

   git remote add origin git@github.com:YOUR_USERNAME/YOUR_REPO.git
   git push origin --force --all
   git push origin --force --tags
   

Fase 4: A armadilha oculta do cache do GitHub (Dangling Commits) e como purgá-lo¶

Aqui está uma realidade forense crítica documentada em Documentos oficiais do GitHub (Removendo dados confidenciais de um repositório): - Quando você corre git filter-repo e git push origin --force --all, cada commit em seu repositório recebe um hash SHA-1 totalmente novo de 40 caracteres, e seu main o ponteiro da ramificação move-se para o novo histórico limpo. - NO ENTANTO, o servidor de armazenamento back-end Git do GitHub NÃO coleta lixo imediatamente (git gc --prune=now) o commit SHA antigo e não referenciado. - Isso significa que se o bot do invasor gravou o hash de commit antigo (por exemplo, a1b2c3d4...) da API pública do GitHub Events quando você fez o push pela primeira vez, eles ainda poderão abrir https://github.com/YOUR_USERNAME/YOUR_REPO/commit/a1b2c3d4... em qualquer navegador da web e visualize seu .env arquivo mesmo DEPOIS de você forçar o histórico de limpeza. Pior ainda, se o segredo aparecesse dentro de uma Solicitação Pull, refs/pull/12/head mantém esse commit permanentemente acessível.

Como destruir commits em cache/pendentes nos servidores do GitHub agora mesmo:¶

1. Método 1 (limpeza instantânea e 100% completa - melhor se o repositório não tiver problemas/PRs/estrelas críticos):
2. Vá para o seu repositório no GitHub -> Settings -> Role até o final (Danger Zone) -> Clique Delete this repository.
3. Crie um repositório totalmente novo com exatamente o mesmo nome no GitHub e envie sua limpeza git filter-repo repositório local para ele (git push -u origin main).
4. Excluir o repositório no GitHub interrompe imediatamente todas as visualizações públicas da web de SHAs de commit antigos em cache (404 Not Found).
5. Método 2 (preservar estrelas, problemas e PRs - usando suporte do GitHub/limpeza de cache):
6. Primeiro, pegue o hash SHA exato de 40 caracteres do commit antigo que continha o segredo (verifique git reflog na sua pasta de backup ou nos e-mails de notificação do GitHub).
7. Abra ** Suporte do GitHub (support.github.com)** e use o fluxo de trabalho automatizado Remover dados confidenciais/Purge cached commit views (referenciando o URL do repositório e o(s) SHA(s) de commit pendente exato(s). A ferramenta automatizada do suporte do GitHub executa um servidor imediato git gc limpeza de cache que invalida as visualizações da web em cache e objetos não referenciados sem excluir seu repositório.
8. Notifique todos os colegas de equipe/colaboradores para git clone fresco (NUNCA git pull):
9. Diga a todos os desenvolvedores da sua equipe: "NÃO execute git pull e push." Se um colega de trabalho que fez o commit incorreto anteriormente executar git pull (que mescla o antigo histórico sujo com o novo histórico reescrito) e empurra, **eles enviarão o excluído .env confirme novamente no GitHub. ** Cada colaborador deve excluir sua pasta local e executar uma nova git cloneou corra git fetch origin && git reset --hard origin/main.

Fase 5: Prevenir para sempre vazamentos futuros (Gitleaks Gancho de pré-confirmação e proteção contra push do GitHub)¶

Reserve 60 segundos agora para tornar matematicamente impossível cometer acidentalmente um segredo novamente:

1. ** Habilite o GitHub gratuitamente "Push Protection for Yourself" em toda a sua conta GitHub**:
2. Vá para GitHub Settings (suas configurações de perfil pessoal, canto superior direito) -> Code security and analysis (ou Code security).
3. Role até Secret scanning -> Habilitar Push protection for yourself.
4. Com isso ativado, sempre que você executar git push de qualquer computador para qualquer repositório público ou privado, o servidor do GitHub inspeciona seu packfile recebido antes de aceitar o push: se detectar uma chave AWS, chave OpenAI, chave Stripe, chave SSH privada ou token Slack, GitHub rejeita o git push bem no seu terminal antes do commit entrar no ar.
5. Instalar gitleaks como local pre-commit conecte seu laptop:

   # Install gitleaks:
   brew install gitleaks   # (or download binary on Linux/Windows)
   
   # Add a pre-commit hook inside your repository (.git/hooks/pre-commit):
   cat << 'EOF' > .git/hooks/pre-commit
   # /usr/bin/env bash
   gitleaks protect --verbose --redact --staged
   if test $? -ne 0; then
     echo "COMMIT BLOCKED BY GITLEAKS: High-entropy secret or API key detected in staged changes."
     exit 1
   fi
   EOF
   chmod +x .git/hooks/pre-commit
   

Números de emergência regionais e protocolos de agências¶

Se um envio acidental de credenciais do GitHub levar a uma invasão não autorizada em dados pessoais regulamentados (PII / PHI), sistemas de saúde ou infraestrutura governamental seguem protocolos obrigatórios de notificação de violação:

• Estados Unidos e Canadá:
• Interrupção emergencial de segurança de vida/infraestrutura crítica: Disque 911 se uma violação da infraestrutura afetar as operações hospitalares ou os controles de segurança física.
• Agência de Segurança Cibernética e de Infraestrutura (CISA) e FBI (IC3): Se os invasores usaram chaves de nuvem vazadas para exfiltrar dados ou implantar malware de extorsão, informe CISA (1-844-Say-CISA / cisa.gov/report) e o Centro de denúncias de crimes na Internet do FBI (ic3.gov).
• Notificação de violação de dados da SEC, FTC e procurador-geral do estado: se os registros de acesso ao banco de dados/CloudTrail mostrarem que um endereço IP não autorizado acessou dados pessoais do cliente (PII) ou registros de saúde (HIPAA ePHI) antes que a chave vazada seja revogada, consulte imediatamente um advogado sobre os cronogramas estaduais de notificação de violação de dados e relatórios federais HHS OCR/FTC Safeguards Rule.
• Centro Canadense de Segurança Cibernética: Ligue 1-833-CYBER-88 (1-833-292-3788) ou denunciar violações de privacidade em PIPEDA ao Escritório do Comissário de Privacidade do Canadá (OPC).
• Reino Unido:
• Serviços de Emergência: Disque 999 (ou 101 / Ação Fraude 0300 123 2040 e o Centro Nacional de Segurança Cibernética / NCSC em ncsc.gov.uk).
• Gabinete do Comissário de Informação (ICO - Janela de 72 horas do GDPR do Reino Unido): Se uma credencial vazada permitiu acesso não autorizado a dados pessoais de residentes do Reino Unido, o Artigo 33 do GDPR do Reino Unido exige o relato de violações de dados pessoais notificáveis ao ICO (0303 123 1113) dentro de 72 horas após tomar conhecimento da violação.
• União Europeia:
• Serviços de Emergência: Disque 112 em todos os estados membros da UE.
• Artigo 33 do GDPR e Relatório de Incidentes da Diretiva NIS2: As organizações sujeitas ao RGPD da UE devem avaliar se a exposição da credencial resultou em uma violação da confidencialidade dos dados pessoais (notificação de 72 horas à Autoridade Nacional de Proteção de Dados / DPA), enquanto entidades essenciais/importantes no âmbito da UE NIS2 Diretiva enfrentam um prazo de notificação de alerta antecipado de 24 horas aos seus países CSIRT (BSI na Alemanha, ANSSI na França, ACN na Itália) para incidentes cibernéticos significativos.
• Austrália e Nova Zelândia:
• Serviços de Emergência: Disque 000 na Austrália ou 111 na Nova Zelândia.
• Centro Australiano de Segurança Cibernética (ACSC) e violações de dados notificáveis (OAIC): Ligue 1300 CYBER1 (1300 292 371) para resposta a incidentes e avaliar as obrigações de notificação no âmbito do Escritório do Comissário de Informação Australiano (OAIC) Violações de dados notificáveis (NDB) esquema ou Lei de Privacidade da Nova Zelândia de 2020 (Privacy Commissioner).
• Índia e Ásia-Pacífico:
• Serviços de Emergência: Disque 112 na Índia (ou 1930 para crimes cibernéticos).
• Diretiva de relatórios obrigatórios de 6 horas CERT-In (Índia): Em Equipe indiana de resposta a emergências informáticas (CERT-In) direções (No. 20(3)/2022-CERT-In), o acesso não autorizado a sistemas de nuvem/TI ou vazamentos de dados que afetem organizações na Índia devem ser relatados a **incident@cert-in.org.in dentro de 6 horas ** após a detecção.

Perguntas frequentes¶

Eu apaguei o .env arquivo e enviei um novo commit 30 segundos após meu erro - ainda preciso girar minhas chaves de API e senhas de banco de dados?¶

Sim, 100 por cento - gire todas as teclas imediatamente, sem exceção. Estudos acadêmicos de segurança cibernética e telemetria do GitHub Secret Scanning confirmam que os bots automatizados de coleta de credenciais monitoram o fluxo público de eventos do GitHub (api.github.com/events) em tempo real e baixar commits recém-enviados dentro 1,5 a 5 segundos. Pior, enviar um segundo commit que exclui .env deixa todo o texto simples .env arquivo permanentemente dentro da diferença de histórico do primeiro commit - e muitos bots procuram especificamente por commits que excluem .env arquivos. Depois que um segredo é enviado para um repositório público por apenas 1 segundo, ele fica comprometido para sempre; revogar e alternar a credencial no painel do provedor é a única coisa que protege você.

E se o repositório fosse um repositório PRIVADO do GitHub quando eu confirmei o .env arquivo, e eu só quero limpá-lo antes de tornar o repositório público na próxima semana?¶

Se o repositório fosse 100 por cento privado o tempo todo (e nenhum aplicativo CI/CD de terceiros não confiável teve acesso), os scraper bots na API pública de eventos do GitHub têm não vi seu segredo ainda. No entanto, NÃO simplesmente exclua `.env` em um novo commit e depois mude o repositório de Privado para Público. No momento em que você transforma um repositório privado em Público, ele gráfico de commit histórico completo torna-se público - e os bots verificam imediatamente todos os commits antigos no repositório recém-público. Antes de tornar público um repositório privado: (1) Execute git filter-repo --invert-paths --path .env para retirar o arquivo de todos os commits históricos (e girar as chaves de qualquer maneira para melhores práticas), OU (2) Copie os arquivos atuais limpos para uma pasta totalmente nova, execute git iniciar para um histórico inicial limpo de 1 commit e publique esse novo repositório.

Por que a AWS anexou automaticamente uma política chamada AWSCompromisedKeyQuarantineV2 para meu usuário IAM e por que ainda estou sendo cobrado?¶

Como a AWS tem parceria direta com o GitHub Secret Scanning, sempre que um AKI... chave aparece em um commit público do GitHub, o sistema de segurança automatizado da AWS a detecta em minutos, abre um tíquete de suporte e anexa a política gerenciada AWSCompromisedKeyQuarantineV2 (ou V3) para esse usuário do IAM. Essa política de quarentena bloqueia ações obviamente perigosas, como o lançamento de novos ec2:RunInstances ou excluindo buckets S3 - mas NÃO encerra instâncias do EC2 que o invasor já lançou durante os primeiros 60 segundos antes da política ser anexada, nem exclui usuários backdoor IAM ou temporários STS sessões que o invasor já criou. Você ainda deve excluir manualmente a chave vazada, verifique Visão global do EC2 em todas as regiões para encerrar instâncias não autorizadas e verificar CloudTrail para alterações não autorizadas do IAM.

Qual é a diferença entre git filter-repo e BFG Repo-Cleaner, e por que não devo usar git filter-branch?¶

git filter-branch é um script de shell legado antigo incorporado nas versões anteriores do Git que é extremamente lento em repositórios grandes, fácil de configurar incorretamente (deixando referências de backup em referências/original/ que ainda contém seus segredos.) e agora imprime um aviso oficial de descontinuação do Git informando para você não usá-lo. Ambos repositório git-filter (escrito em Python e endossado oficialmente pelos principais mantenedores do Git e GitHub) e Limpador de repositório BFG (escrito em Java/Scala) executa 10x a 100x mais rápido e reescreve de forma limpa todos os commits, árvores e tags. repositório git-filter é geralmente preferido hoje porque modifica até mesmo o seu commit atual com check-out (`HEAD`) sem exigir primeiro um commit preliminar separado.

Como alguém ainda pode ver meu commit excluído no GitHub depois que eu executei? git filter-repo e git push --force?¶

No Git, `git push --force` apenas atualiza o ponteiro de referência de ramificação (`refs/heads/main`) para apontar para sua nova cadeia de commits reescrita; isso acontece não exclua imediatamente os objetos de commit antigos não referenciados ("pendentes") armazenados nos servidores back-end do GitHub. Se um bot gravou o hash SHA de 40 caracteres do seu commit original quando atingiu a API pública de eventos, navegando diretamente para https://github.com/owner/repo/commit/<40-char-SHA> ainda carregará esse commit órfão do cache de objetos do GitHub até que a coleta de lixo seja executada. Para destruir essa visualização em cache imediatamente, exclua o repositório no GitHub e recrie-o a partir do seu repositório local limpoou envie o SHA de commit pendente para Suporte GitHub (`support.github.com`) para uma limpeza imediata do cache do lado do servidor.

E se alguém já clicou em "Fork" no meu repositório público antes de eu executar git filter-repo?¶

É por isso A etapa 1 é sempre revogar e alternar as credenciais no painel do provedor: correndo repositório de filtro git e push forçado para seu próprio repositório NÃO reescreve commits dentro do Fork independente de outra pessoa do seu repositório (a menos que você exclua todo o seu repositório pai e entre em contato com o suporte do GitHub sobre dados confidenciais em forks). Depois de revogar as chaves AWS/API e alternar as senhas do banco de dados, qualquer cópia do antigo .env O arquivo localizado dentro de um fork ou banco de dados de bot de terceiros torna-se uma sequência de caracteres morta e inútil que não pode mais acessar sua infraestrutura.

Guias relacionados¶

• Ransomware e malware: contenção e recuperação imediatas
• Sequestro de nome de domínio, DNS expirado e controle de site
• Bloqueio de administrador de domínio personalizado do Google Workspace ou Microsoft 365 e resgate de DNS
• Phishing e contas comprometidas: bloqueio de emergência
• rm -rf ou Shift-Delete acidental no Linux, macOS ou Windows: remontagem imediata somente leitura
• Números de emergência por país

Fontes e orientações oficiais¶

• Documentação oficial de segurança do GitHub (docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository): Remoção de dados confidenciais de um repositório (git filter-repo, BFG Repo-Cleaner, limpeza de cache de confirmação pendente e proteção contra push de verificação secreta).
• Amazon Web Services (AWS) Guia de resposta a incidentes de segurança (docs.aws.amazon.com/security/): Respondendo a chaves de acesso AWS IAM expostas (AWSCompromisedKeyQuarantineV2, Revogando Temporariamente STS Sessões via aws:TokenIssueTimee CloudTrail Auditoria Forense).
• Instituto Nacional de Padrões e Tecnologia (NIST) (Estados Unidos): Publicação Especial 800-61 Rev. 2: Guia de Tratamento de Incidentes de Segurança Informática e SP 800-57: Recomendação para gerenciamento de chaves (revogação de credenciais comprometidas e rotação criptográfica).
• Abra o projeto de segurança de aplicativos da Web (OWASP): Folha de dicas de gerenciamento de segredos (evitando credenciais codificadas, verificação de segredo pré-commit com Gitleaks/TruffleHoge injeção secreta de tempo de execução efêmera).
• Agência de Segurança Cibernética e de Infraestrutura (CISA) (Estados Unidos): Arquitetura de referência técnica de segurança em nuvem e manual de correção de credenciais comprometidas.