Spinto accidentalmente .env Segreti o chiavi AWS per un repository GitHub pubblico: perché l'eliminazione del file non lo nasconde¶

Realizzarlo dieci secondi dopo aver corso git push origin main (o sfogliando un repository privato in Public) che il tuo commit includeva un testo in chiaro .env file, un AWS AKIA... Chiave di accesso e chiave segreta, una chiave API OpenAI/Anthropic, una Stripe sk_live_... token di produzione, un URI di database PostgreSQL/MongoDB con password o un file non crittografato $HOME/.ssh/id_ed25519 la chiave privata è un'emergenza di sicurezza informatica a cinque allarmi. Le botnet automatizzate per la raccolta delle credenziali interrogano continuamente il pubblico GitHub Events Firehose (api.github.com/events) e clonare i commit appena inviati entro 1,5-4 secondi dal tuo git push completando. Peggio ancora, quasi tutti gli sviluppatori in preda al panico commettono esattamente lo stesso errore fatale: cancellano il file .env file localmente, aggiungi .env a .gitignoree invia un secondo commit intitolato "remove .env" o "oops". Spingendo un secondo commit che elimina .env non nasconde nulla: il segreto in testo normale rimane leggibile al 100% per sempre all'interno del diff del commit precedente (git log -p), e anche se si spinge forzatamente (git push --force) sul ramo, il commit senza riferimenti (dangling blob) rimane accessibile pubblicamente tramite il suo URL GitHub diretto e le visualizzazioni Pull Request memorizzate nella cache finché non vengono esplicitamente eliminate. Se le credenziali trapelate sono già state utilizzate dagli aggressori per distribuire ransomware, prendere il controllo del tuo dominio DNS o bloccare il tuo tenant cloud, consulta le nostre guide complementari su risposta a ransomware e malware, dirottamento del nome di dominio, DNS scaduto e acquisizione del sito web, e Blocco dell'amministratore di dominio personalizzato di Google Workspace o Microsoft 365. Se una perdita di credenziali ha un impatto sulla sicurezza dei pazienti ospedalieri, sui controlli fisici industriali o sull'infrastruttura di gestione delle emergenze, chiama il numero di emergenza locale (911 negli Stati Uniti e in Canada, 112 in tutta l’Unione Europea, 999 nel Regno Unito) o consulta la nostra directory internazionale di numeri di emergenza.

Fallo adesso¶

1. REVOCARE, DISATTIVARE E RUOTARE PRIMA ogni singolo segreto esposto sulla console del provider - entro i primi 120 secondi - prima di sprecare un solo secondo in esecuzione git comandi: una volta che un segreto tocca un repository pubblico GitHub, GitLab o Bitbucket anche per 3 secondi, considera la chiave come bruciata in modo permanente e già nelle mani di aggressori automatizzati. Nessuna quantità di git reset --hard, git push --forceoppure l'eliminazione del repository può cancellare una chiave dal database di un bot scraper che ha già scaricato il tuo commit al secondo n. 2. Accedi subito ad AWS IAM, Stripe, OpenAI, console di database o alle impostazioni SSH di GitHub e Disattiva/Elimina/Esegui il rollio della chiave immediatamente.
2. Controlla la fatturazione Cloud e i log di controllo (AWS CloudTrail, GCP Cloud Audit Logs, Stripe Logs) per la finestra tra i tuoi git push e la revoca della chiave: i bot automatizzati di cryptomining utilizzano leaked AWS_ACCESS_KEY_ID (AKIA...) credenziali entro 30-90 secondi per avviare le istanze GPU con quota massima (p4d.24xlarge / g5.48xlarge) in tutte le regioni AWS nascoste (ap-east-1, me-south-1, af-south-1) e creare utenti IAM backdoor o Lambda hook di persistenza in modo che rimangano all'interno del tuo account AWS anche dopo aver eliminato la chiave trapelata.
3. Non spingere MAI per un secondo "Delete .env" commit - in effetti, digitando "delete secret" o "remove password" in un messaggio di commit attira bot mirati di scraper: migliaia di script di autori di minacce interrogano specificatamente GitHub Cerca messaggi di commit contenenti "remove .env", "delete key", "oops", e "remove credentials", quindi fai clic su un commit indietro nella cronologia per rubare la chiave.
4. Riscrivi l'intera cronologia del repository Git localmente utilizzando git filter-repo (o BFG Repo-Cleaner) per eliminare il file o oscurare la stringa della password da ogni commit, albero e tag storico: git filter-branch è ufficialmente deprecato dal progetto Git; utilizzare git filter-repo --invert-paths --path .env (per bombardare un file da tutti i commit) o git filter-repo --replace-text expressions.txt (per sostituire stringhe di password specifiche con ***REMOVED*** all'interno dei file di codice senza eliminare i file).
5. Forza il push di tutti i rami e i tag (git push origin --force --all) ED elimina le visualizzazioni di commit memorizzate nella cache lato server di GitHub (dangling commits): Ecco il segreto che la maggior parte degli sviluppatori non conosce: anche dopo aver eseguito git filter-repo e git push --force, I server di GitHub mantengono vivo il vecchio commit SHA nella cache degli oggetti (git cat-file), il che significa che chiunque abbia registrato il commit SHA di 40 caratteri dall'API pubblica degli eventi può comunque visualizzarlo github.com/user/repo/commit/<OLD_SHA>. Di seguito spieghiamo come eliminare immediatamente le cache dei commit pendenti tramite il supporto GitHub/API o eliminando e ricreando il repository.
6. Installa un file locale pre-commit scanner segreto (gitleaks o trufflehog) dentro .git/hooks/pre-commit prima di scrivere un'altra riga di codice: A 10 secondi gitleaks protect --staged Il gancio pre-commit ispeziona ogni linea organizzata localmente sul tuo laptop e si blocca git commit prima che un segreto possa mai lasciare la tua macchina.

Albero decisionale: contenimento immediato, rotazione ed eliminazione della cronologia Git¶

Esegui questo flusso di lavoro in rigoroso ordine cronologico (Revoca FIRST -> Audit Persistence SECOND -> Purge Git History TERZO):

flowchart TD
    Start["Invio segreto al repository pubblico (.env, chiave AWS/GCP, password DB, chiave Stripe/OpenAI o chiave SSH privata)"] --> Step1["MINUTO DA 0 A 2 (PRIORITÀ N. 1): revoca/ripristina immediatamente ogni chiave esposta sulla console del provider"]

    Step1 --> SecretType{"Che tipo di credenziali erano all'interno del commit?"}

    SecretType -->|"Chiave dell'infrastruttura cloud (AWS AKIA, account di servizio GCP JSON, Azure SP)"| CloudAudit["MINUTI DA 2 A 10: controlla CloudTrail/registri attività -> Interrompi EC2 non autorizzati/istanze di calcolo in tutte le regioni -> Elimina utenti IAM/ruoli/sessioni STS non autorizzati"]

    SecretType -->|"URI/password del database (Postgres, MySQL, MongoDB, Redis, Supabase)"| DBAudit["MINUTO DA 2 A 10: Ruota la password dell'utente DB + Elimina le connessioni attive (pg_terminate_backend) + Blocca il gruppo di sicurezza del firewall solo sugli IP autorizzati"]

    SecretType -->|"Token API o chiave SSH (Stripe, OpenAI, GitHub PAT, Slack, chiave SSH privata)"| TokenAudit["MINUTI DA 2 A 10: Riproduci la chiave API nella dashboard / Rimuovi la chiave SSH pubblica da $HOME/.ssh/authorized_keys e Impostazioni GitHub -> Controlla i registri di utilizzo recenti dell'API"]

    CloudAudit --> RepoVisibility{"MINUTO DA 10 A 20: Come vuoi eliminare il repository GitHub?"}
    DBAudit --> RepoVisibility
    TokenAudit --> RepoVisibility

    RepoVisibility -->|"Cancellazione della cache al 100% più veloce (nessun problema critico/cronologia delle stelle da conservare)"| NukeRepo["1. Elimina l'intero repository nelle impostazioni di GitHub. 2. Esegui git filter-repo localmente per pulire la cronologia. 3. Crea un nuovo repository e pulisci la cronologia (distrugge istantaneamente tutti gli SHA di commit memorizzati nella cache)"]

    RepoVisibility -->|"È necessario preservare le stelle, i problemi, i PR e i fork dei repository esistenti"| RewriteRepo["1. Esegui git filter-repo (--invert-paths o --replace-text). 2. Esegui git push --force --all & --tags. 3. Contatta il supporto GitHub/il portale di supporto per eliminare la cache SHA del commit pendente"]

Fase 1: Minuti da 0 a 2 - Foglio informativo sulla revoca immediata da parte del Fornitore¶

Non aprire un terminale con cui combattere git rebase mentre le tue chiavi di produzione sono ancora attive. Fai clic direttamente sul fornitore interessato di seguito e elimina prima la credenziale:

Fase 2: Minuti da 2 a 10: verificare se gli aggressori hanno già creato una backdoor (AWS/contenimento nel cloud)¶

Se sei trapelato .env il file conteneva una chiave di accesso AWS (AKIA...), Google Cloud Service Account JSON o Azure Service Principal, l'eliminazione della chiave trapelata è solo metà dell'opera. Devi verificare che un bot automatizzato non abbia utilizzato quei 90 secondi per stabilire la persistenza all'interno del tuo account cloud:

L'audit forense post-leak di AWS in 6 punti¶

1. Controllo AWS CloudTrail -> Event history per tutte le chiamate API effettuate dal leaked Access Key ID:
2. Apri la Console AWS CloudTrail -> Cronologia eventi.
3. Modifica il menu a discesa di ricerca da Sola lettura a Access key ID e incolla il file trapelato AKIA... corda.
4. Guarda tutti gli eventi registrati dal momento in cui hai corso git push. Cerca nello specifico: CreateUser, CreateAccessKey, AttachUserPolicy, CreateRole, AssumeRole, GetSessionToken, RunInstances (EC2), RequestSpotInstances, CreateFunction (Lambda), o SendEmail (Spam SES).
5. Revocare qualsiasi temporaneo attivo STS sessioni generate da quell'utente:
6. Anche dopo aver eliminato un file AKIA... chiave di accesso, se l'aggressore ha chiamato sts:GetSessionToken prima di eliminare la chiave, la loro temporanea ASIA... il token di sessione rimane valido fino a 36 ore.
7. Per uccidere tutti gli attivi temporanei STS token per quell'utente IAM immediatamente, vai a IAM -> Users -> [Leaked User] -> Permissions -> Add inline policye clicca Revoke sessions (che allega un esplicito Deny * politica per qualsiasi token emesso dove aws:TokenIssueTime è prima di adesso.).
8. Controllo IAM -> Users e IAM -> Roles per gli account backdoor appena creati:
9. Ordina tutti gli utenti IAM per Ora di creazione. Elimina qualsiasi utente sconosciuto (admin-backup, sys-monitor, support-bot) e verificare il Trust relationships scheda sui ruoli IAM per assicurarsi che l'autore dell'attacco non abbia aggiunto il proprio ID account AWS esterno ("Principal": {"AWS": "arn:aws:iam::999999999999:root"}) come principale di fiducia.
10. UtilizzaAWS Resource Explorer** o EC2 Global View per verificare la presenza di cryptominer nascosti in TUTTE le oltre 30 regioni AWS**:
11. Gli aggressori raramente avviano istanze di cryptomining in us-east-1 dove li vedrai sulla tua dashboard. Invece, si lanciano p4d, g5, o c6i.32xlarge istanze in ap-southeast-3 (Giakarta), me-central-1 (EAU), il-central-1 (Tel Aviv), o sa-east-1 (San Paolo).
12. Aprire EC2 Console -> EC2 Global View (che analizza ogni regione abilitata in una singola tabella) e termina immediatamente qualsiasi istanza non autorizzata.
13. Apri immediatamente un caso di fatturazione AWS Support se le istanze non autorizzate hanno ricevuto una fattura:
14. Se un bot si avviasse $8,000 di istanze GPU EC2 prima di terminarle, niente panico: una volta protetto l'account, eliminato la chiave, abilitato root/IAM MFAe hai rimosso la chiave da GitHub, apri un caso di supporto per account AWS e fatturazione che spiega il push accidentale di GitHub e le fasi di risoluzione. AWS concede regolarmente un credito una tantum di condono della fatturazione di buona volontà per perdite accidentali di chiavi GitHub una volta che il team di sicurezza verifica che il repository sia pulito.

Fase 3: perché l'eliminazione del file in un nuovo commit non riesce e come riscrivere correttamente la cronologia con git filter-repo¶

1. Perché git rm .env && git commit -m "delete .env" è completamente inutile¶

Git è un filesystem indirizzabile al contenuto di sola aggiunta (Directed Acyclic Graph / DAG di commit, alberi e oggetti blob): - Supponiamo che Commit A1B2C3 aggiunto .env (Blob 998877). - Supponiamo che 2 minuti dopo corri git rm .env, aggiungi .env a .gitignoree premi Conferma D4E5F6. - Mentre qualcuno che esplora l'elenco dei file correnti sulla tua home page GitHub non vedrà .env, Impegna A1B2C3 e Blob 998877 fanno ancora parte al 100% del repository. Chiunque esegua git clone download Blob 998877, chiunque faccia clic sulla scheda "Commit" su GitHub può fare clic A1B2C3 per leggere il tuo .env file in testo semplice e strumenti automatizzati (trufflehog git https://github.com/user/repo) scansiona ogni singolo commit storico in 2 secondi.

2. Passo dopo passo: cancellare un file o una stringa segreta in TUTTA la cronologia utilizzando git filter-repo¶

Il progetto Git e GitHub consigliano ufficialmente git-filter-repo (che sostituisce il file lento e soggetto a errori git filter-branch ed è ancora più flessibile di BFG Repo-Cleaner).

1. Installare git-filter-repo (Richiede 5 secondi):

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

2. Crea una copia di backup di sicurezza della cartella del repository locale prima di riscrivere la cronologia:

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

   (Nota: se hai già spostato il tuo file valid .env archiviare, assicurarsi che una copia pulita di .env viene salvato in /tmp/.env.safe fuori dal repository, perché git filter-repo pulirà .env anche dalla tua directory di lavoro.)
3. Scegli l'opzione A (Cancella un intero percorso di file come .env o id_rsa) OPPURE Opzione B (Redigi stringhe segrete specifiche all'interno dei file di codice):
4. Opzione A: rimuovere completamente .env (o config/secrets.json) da ogni commit nella cronologia:

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

   (Perché --invert-paths? Senza --invert-paths, git filter-repo --path .env mantiene SOLO .env e cancella tutto il resto. Combinando --invert-paths --path .env dice a Git di mantenere tutto TRANNE .env attraverso tutti i commit, i rami e i tag.)
5. Opzione B: conservare il file del codice (app.py / config.js), ma cancella la stringa segreta codificata da ogni versione storica: Crea un file di testo /tmp/secrets-to-scrub.txt contenente una stringa segreta (o regex) per riga:

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

   Ora corri 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. Aggiungi .env a .gitignore quindi non impegnarlo nuovamente tra 5 minuti:

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

7. Aggiungi nuovamente il tuo telecomando GitHub (git filter-repo rimuove intenzionalmente origin come controllo di sicurezza) e forzare tutti i rami e i tag:

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

Fase 4: La trappola nascosta della cache di GitHub (Dangling Commits) e come eliminarlo¶

Ecco una realtà forense critica documentata nei Documenti ufficiali di GitHub (Rimozione di dati sensibili da un repository): - Quando corri git filter-repo e git push origin --force --all, ogni commit nel tuo repository riceve un nuovissimo hash SHA-1 di 40 caratteri e il tuo main il puntatore del ramo si sposta nella nuova cronologia pulita. - TUTTAVIA, il server di archiviazione Git backend di GitHub NON esegue immediatamente la raccolta dei rifiuti (git gc --prune=now) il vecchio commit SHA senza riferimenti. - Ciò significa che se il bot di un utente malintenzionato ha registrato il vecchio hash di commit (ad esempio, a1b2c3d4...) dall'API GitHub Events pubblica al primo invio, possono ancora aprirsi https://github.com/YOUR_USERNAME/YOUR_REPO/commit/a1b2c3d4... in qualsiasi browser web e visualizzare il tuo .env file anche DOPO aver forzato la pulizia della cronologia. Peggio ancora, se il segreto apparisse all'interno di una Richiesta Pull, refs/pull/12/head mantiene il commit permanentemente raggiungibile.

Come distruggere subito i commit memorizzati nella cache/pendenti sui server GitHub:¶

1. Metodo 1 (cancellazione istantanea e completa al 100% - Ideale se il repository non presenta problemi critici/PR/stelle):
2. Vai al tuo repository su GitHub -> Settings -> Scorri fino in fondo (Danger Zone) -> Fare clic Delete this repository.
3. Crea un repository nuovo di zecca con lo stesso identico nome su GitHub e spingi il tuo clean git filter-repo repository locale ad esso (git push -u origin main).
4. L'eliminazione del repository su GitHub interrompe immediatamente tutte le visualizzazioni Web pubbliche dei vecchi SHA di commit memorizzati nella cache (404 Not Found).
5. Metodo 2 (Preservare stelle, problemi e PR - Utilizzo del supporto GitHub/Eliminazione della cache):
6. Innanzitutto, prendi l'hash SHA esatto di 40 caratteri del vecchio commit che conteneva il segreto (controlla git reflog nella cartella di backup o nelle email di notifica di GitHub).
7. Apri Supporto GitHub (support.github.com) e utilizzare il flusso di lavoro automatizzato Rimuovi dati sensibili/Elimina viste commit memorizzate nella cache (facendo riferimento all'URL del repository e agli SHA/i di commit pendenti esatti). Lo strumento automatizzato di GitHub Support viene eseguito immediatamente sul lato server git gc pulizia della cache che invalida le visualizzazioni Web memorizzate nella cache e gli oggetti senza riferimenti senza eliminare il repository.
8. Avvisare tutti i compagni di squadra/collaboratori a git clone fresco (MAI git pull):
9. Di' a ogni sviluppatore del tuo team: "NON eseguire git pull e spingi." Se un collega che ha eseguito il commit errato in precedenza viene eseguito git pull (che unisce la vecchia storia sporca con la nuova storia riscritta) e spinge, spingeranno la cancellata .env esegui nuovamente il commit su GitHub. Ogni collaboratore deve eliminare la propria cartella locale ed eseguirne una nuova git cloneo correre git fetch origin && git reset --hard origin/main.

Fase 5: Prevenire per sempre fughe di informazioni future (Gitleaks Hook pre-commit e protezione push GitHub)¶

Prenditi subito 60 secondi per rendere matematicamente impossibile commettere nuovamente accidentalmente un segreto:

1. Abilita GitHub gratuitamente "Push Protection for Yourself" nell'intero account GitHub:
2. Vai su GitHub Settings (impostazioni del tuo profilo personale, in alto a destra) -> Code security and analysis (o Code security).
3. Scorri fino a Secret scanning -> Abilita Push protection for yourself.
4. Con questa opzione attivata, ogni volta che corri git push da qualsiasi computer a qualsiasi repository pubblico o privato, il server di GitHub ispeziona il file di pacchetto in entrata prima di accettare il push: se rileva una chiave AWS, una chiave OpenAI, una chiave Stripe, una chiave SSH privata o un token Slack, GitHub rifiuta il git push direttamente nel tuo terminale prima che il commit diventi attivo.
5. Installare gitleaks come locale pre-commit aggancia il tuo 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
   

Numeri di emergenza regionali e protocolli d'agenzia¶

Se un push accidentale delle credenziali GitHub porta a un'intrusione non autorizzata nei dati personali regolamentati (PII / PHI), i sistemi sanitari o le infrastrutture governative, seguono protocolli obbligatori di notifica delle violazioni:

• Stati Uniti e Canada:
• Interruzione di emergenza per la sicurezza della vita/infrastrutture critiche: comporre 911 se una violazione delle infrastrutture influisce sulle operazioni ospedaliere o sui controlli di sicurezza fisica.
• Agenzia per la sicurezza informatica e delle infrastrutture (CISA) e FBI (IC3): se gli aggressori hanno utilizzato chiavi cloud trapelate per sottrarre dati o distribuire malware a scopo di estorsione, segnalarlo a CISA (1-844-Say-CISA / cisa.gov/report) e il Centro reclami sulla criminalità su Internet dell'FBI (ic3.gov).
• Notifica di violazione dei dati da parte di SEC, FTC e Procuratore generale dello Stato: se CloudTrail/i registri di accesso al database mostrano che un indirizzo IP non autorizzato ha avuto accesso ai dati personali del cliente (PII) o cartelle cliniche (HIPAA ePHI) prima che la chiave trapelata venga revocata, consultare immediatamente un consulente legale in merito alle tempistiche di notifica statale di violazione dei dati e alla segnalazione federale HHS OCR/FTC Safeguards Rule.
• Centro canadese per la sicurezza informatica: chiamare1-833-CYBER-88 (1-833-292-3788) o segnalare violazioni della privacy sotto PIPEDA al Ufficio del Commissario per la Privacy del Canada (OPC).
• Regno Unito:
• Servizi di emergenza: componi 999 (o 101 / Azione antifrode 0300 123 2040 e il Centro Nazionale per la Sicurezza Informatica / NCSC a ncsc.gov.uk).
• Ufficio del Commissario per le informazioni (ICO - Finestra GDPR del Regno Unito di 72 ore): se una credenziale trapelata consente l'accesso non autorizzato ai dati personali dei residenti nel Regno Unito, l'Articolo 33 del GDPR del Regno Unito richiede di segnalare le violazioni dei dati personali soggette a notifica all'ICO (0303 123 1113) entro 72 ore dal venire a conoscenza della violazione.
• Unione Europea:
• Servizi di emergenza: componi 112in tutti gli stati membri dell'UE.
• Articolo 33 del GDPR e Segnalazione di incidenti della Direttiva NIS2: le organizzazioni soggette al GDPR dell'UE devono valutare se l'esposizione delle credenziali ha comportato una violazione della riservatezza dei dati personali (notifica entro 72 ore all'autorità nazionale per la protezione dei dati/ DPA), mentre le entità essenziali/importanti ai sensi dell'UE NIS2 La Direttiva deve rispettare un termine ultimo di 24 ore per la segnalazione di preallarme al proprio cittadino CSIRT (BSI in Germania, ANSSI in Francia, ACN in Italia) per incidenti informatici significativi.
• Australia e Nuova Zelanda:
• Servizi di emergenza: componi 000 in Australia o 111in Nuova Zelanda.
• Centro australiano per la sicurezza informatica (ACSC) e violazioni dei dati soggette a notifica (OAIC): Chiamata 1300 CYBER1 (1300 292 371) per la risposta agli incidenti e valutare gli obblighi di notifica ai sensi dell'Ufficio del Commissario australiano per le informazioni (OAIC) Violazioni dei dati soggette a notifica (NDB) o il New Zealand Privacy Act 2020 (Privacy Commissioner).
• India e Asia-Pacifico:
• Servizi di emergenza: componi 112 in India (o 1930per la criminalità informatica).
• Direttiva CERT-In sulla segnalazione obbligatoria entro 6 ore (India): nell'ambito del Team indiano di risposta alle emergenze informatiche (CERT-In) direzioni (No. 20(3)/2022-CERT-In), l'accesso non autorizzato ai sistemi cloud/IT o le fughe di dati che interessano le organizzazioni in India devono essere segnalati a incident@cert-in.org.in entro 6 ore dal rilevamento.

Domande frequenti¶

Ho eliminato il .env file e ho inviato un nuovo commit 30 secondi dopo il mio errore: devo ancora ruotare le mie chiavi API e le password del database?¶

Sì, al 100%: ruota immediatamente ogni singolo tasto, senza eccezioni. Studi accademici sulla sicurezza informatica e telemetria di GitHub Secret Scanning confermano che i bot automatizzati per la raccolta di credenziali monitorano il flusso pubblico di eventi GitHub (api.github.com/events) in tempo reale e scaricare i nuovi commit all'interno Da 1,5 a 5 secondi. Peggio ancora, spingendo un secondo commit che elimina .env lascia l'intero testo in chiaro .env file che si trova permanentemente all'interno della cronologia del primo commit diff - e molti bot cercano specificamente i commit che eliminano .env file. Una volta che un segreto è stato inserito in un archivio pubblico anche per 1 secondo, viene compromesso per sempre; revocare e ruotare le credenziali dalla dashboard del fornitore è l'unica cosa che ti tutela.

Cosa succederebbe se il repository fosse un repository GitHub PRIVATO quando ho eseguito il commit del file .env file e voglio semplicemente ripulirlo prima di rendere pubblico il repository la prossima settimana?¶

Se il repository fosse Privato al 100%. per tutto il tempo (e nessuna app CI/CD di terze parti non attendibile ha avuto accesso), i bot scraper sull'API GitHub Events pubblica hanno non ho già visto il tuo segreto. Tuttavia, NON eliminare semplicemente `.env` in un nuovo commit e quindi capovolgere il repository da Privato a Pubblico. Nel momento in cui passi da un repository privato a Pubblico, è intero grafico dei commit storici diventa pubblico e i bot scansionano immediatamente tutti i vecchi commit nel nuovo repository pubblico. Prima di rendere pubblico un repository privato: (1) Esegui git filter-repo --invert-paths --path .env per rimuovere il file da tutti i commit storici (e ruotare comunque le chiavi per la migliore pratica), OPPURE (2) Copiare i file correnti puliti in una cartella nuova di zecca, eseguire git init per una cronologia iniziale pulita con 1 commit e pubblicare il nuovo repository.

Perché AWS ha collegato automaticamente una policy chiamata AWSCompromisedKeyQuarantineV2 al mio utente IAM e perché ricevo ancora addebiti?¶

Poiché AWS collabora direttamente con GitHub Secret Scanning, ogni volta che un AKI... viene visualizzata in un commit GitHub pubblico, il sistema di sicurezza automatizzato di AWS la rileva in pochi minuti, apre un ticket di supporto e allega la policy gestita AWSCompromisedKeyQuarantineV2 (o V3) a quell'utente IAM. Quella politica di quarantena blocca azioni ovvie e pericolose come il lancio di nuovi ec2:RunInstances o eliminando i bucket S3 - ma NON termina le istanze EC2 già avviate dall'autore dell'attacco durante i primi 60 secondi prima che la policy fosse allegata, né elimina gli utenti IAM backdoor o gli utenti temporanei STS sessioni già create dall'aggressore. È comunque necessario eliminare manualmente la chiave trapelata, controlla Visione globale EC2 in tutte le regioni per terminare le istanze non autorizzate e controllare CloudTrail per modifiche IAM non autorizzate.

Qual è la differenza tra git filter-repo e BFG Repo-Cleaner, e perché non dovrei usarlo git filter-branch?¶

git filtro-ramo èun vecchio script di shell legacy integrato nelle prime versioni di Git che è estremamente lento su repository di grandi dimensioni, facile da configurare in modo errato (lasciando i riferimenti di backup in riferimenti/originale/ che contengono ancora i tuoi segreti.), e ora stampa un avviso ufficiale di deprecazione da parte di Git che ti dice di non usarlo. Entrambi git-filter-repo (scritto in Python e ufficialmente approvato dai principali manutentori di Git e GitHub) e BFG Repo-Cleaner (scritto in Java/Scala) funziona da 10 a 100 volte più velocemente e riscrive in modo pulito tutti i commit, gli alberi e i tag. git-filter-repo è generalmente preferito oggi perché modifica anche il tuo attuale commit di check-out (`HEAD`) senza richiedere prima un commit preliminare separato.

Come può qualcuno continuare a visualizzare il mio commit eliminato su GitHub dopo averlo eseguito git filter-repo e git push --force?¶

In Git, `git push --force` aggiorna solo il puntatore di riferimento del ramo (`refs/heads/main`) per puntare alla nuova catena di commit riscritta; lo fa non eliminare immediatamente i vecchi oggetti di commit senza riferimenti ("pendenti") archiviati sui server backend di GitHub. Se un bot ha registrato l'hash SHA di 40 caratteri del tuo commit originale quando ha raggiunto l'API pubblica degli eventi, accedendo direttamente a https://github.com/owner/repo/commit/<40-char-SHA> caricherà comunque il commit orfano dalla cache degli oggetti di GitHub fino all'esecuzione della garbage collection. Anche per distruggere immediatamente quella vista memorizzata nella cache elimina il repository su GitHub e ricrealo dal tuo repository locale pulitoo inviare il commit SHA pendente a Supporto GitHub (`support.github.com`) per un'eliminazione immediata della cache lato server.

Cosa succederebbe se qualcuno avesse già fatto clic su "Fork" nel mio repository pubblico prima che eseguissi? git filter-repo?¶

Questo è il motivo Il passaggio 1 prevede sempre la revoca e la rotazione delle credenziali nel dashboard del provider: corsa repository filtro git e forzare l'invio al tuo repository NON riscrive i commit all'interno del fork indipendente di qualcun altro del tuo repository (a meno che non elimini l'intero repository principale e contatti il ​​supporto GitHub in merito ai dati sensibili nei fork). Dopo aver revocato le chiavi AWS/API e ruotato le password del database, qualsiasi copia del vecchio .env il file che si trova all'interno di un database fork o bot di terze parti diventa una stringa di caratteri morta e inutile che non può più accedere alla tua infrastruttura.

Guide correlate¶

• Ransomware e malware: contenimento e ripristino immediati
• Dirottamento del nome di dominio, DNS scaduto e acquisizione del sito web
• Blocco dell'amministratore di dominio personalizzato di Google Workspace o Microsoft 365 e ripristino DNS
• Phishing e account compromessi: lockdown d'emergenza
• rm -rf accidentale o Shift-Delete su Linux, macOS o Windows: rimontaggio immediato in sola lettura
• Numeri di emergenza per paese

Fonti e indicazioni ufficiali¶

• Documentazione ufficiale sulla sicurezza di GitHub (docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository): Rimozione di dati sensibili da un repository (git filter-repo, BFG Repo-Cleaner, Eliminazione cache commit pendente e Protezione push scansione segreta).
• Servizi Web di Amazon (AWS) Guida alla risposta agli incidenti di sicurezza (docs.aws.amazon.com/security/): Risposta alle chiavi di accesso AWS IAM esposte (AWSCompromisedKeyQuarantineV2, Revoca Temporanea STS Sessioni tramite aws:TokenIssueTime, e CloudTrail Revisione forense).
• Istituto nazionale di standard e tecnologia (NIST) (Stati Uniti): Pubblicazione speciale 800-61 Rev. 2: Guida alla gestione degli incidenti di sicurezza informatica e SP 800-57: Raccomandazione per la gestione delle chiavi (revoca credenziali compromesse e rotazione crittografica).
• Apri progetto di sicurezza dell'applicazione Web (OWASP): Foglio informativo sulla gestione dei segreti (prevenzione di credenziali codificate, scansione pre-impegnativa dei segreti con Gitleaks/TruffleHoge Iniezione segreta di runtime effimera).
• Agenzia per la sicurezza informatica e le infrastrutture (CISA) (Stati Uniti): Architettura di riferimento tecnico per la sicurezza cloud e playbook per la correzione delle credenziali compromesse.