Slučajno gurnut .env Tajne ili AWS ključevi za javni GitHub repo: zašto se brisanjem datoteke ne skriva¶

Shvatanje deset sekundi nakon trčanja git push origin main (ili okretanje privatnog spremišta u Public) da je vaše urezivanje uključivalo otvoreni tekst .env fajl, AWS AKIA... Pristupni ključ i tajni ključ, OpenAI/Anthropic API ključ, Stripe sk_live_... proizvodni token, URI baze podataka PostgreSQL/MongoDB sa lozinkom ili nešifrirani $HOME/.ssh/id_ed25519 privatni ključ je hitan slučaj s pet alarma za sajber sigurnost. Automatski botnet za prikupljanje akreditiva kontinuirano ispituje javnost GitHub Events Firehose (api.github.com/events) i klonirajte novouspostavljena urezivanja unutar 1,5 do 4 sekunde od vašeg git push dovršavanje. Što je još gore, gotovo svaki uspaničeni programer čini potpuno istu fatalnu grešku: briše .env datoteku lokalno, dodajte .env to .gitignore, i pritisnite drugo urezivanje pod nazivom "remove .env" ili "oops". ** Guranje drugog urezivanja koji briše .env ne skriva ništa**: tajna otvorenog teksta ostaje 100 posto čitljiva zauvijek unutar diff prethodnog urezivanja (git log -p), pa čak i ako silom pritisnete (git push --force) preko grane, nereferencirano urezivanje (dangling blob) ostaje javno dostupan putem svog direktnog GitHub URL-a i keširanih pogleda zahtjeva za povlačenjem dok se eksplicitno ne očisti. Ako su napadači već koristili propuštenu vjerodajnicu za implementaciju ransomwarea, otmicu vaše DNS domene ili zaključavanje vašeg zakupca u oblaku, konsultujte naše prateće vodiče na odgovor na ransomware i malver, otmica imena domena, istekli DNS i preuzimanje web stranice, i Google Workspace ili Microsoft 365 prilagođeno zaključavanje administratora domene. Ako curenje akreditiva utječe na sigurnost pacijenata u bolnici, fizičke industrijske kontrole ili infrastrukturu za hitne slučajeve, nazovite svoj lokalni broj za hitne slučajeve (911 u Sjedinjenim Državama i Kanadi, 112 širom Evropske unije, 999 u Ujedinjenom Kraljevstvu) ili provjerite naš međunarodni imenik brojevi za hitne slučajeve.

Uradi ovo sada¶

1. PRVO OPOZOVI, DEAKTIVIRAJTE I ROTIRAJTE svaku otkrivenu tajnu na konzoli provajdera - unutar prvih 120 sekundi - prije nego što potrošite jednu sekundu na trčanje git komande: Jednom kada tajna dotakne javno GitHub, GitLab ili Bitbucket spremište čak 3 sekunde, tretirajte taj ključ kao trajno spaljen i već u rukama automatiziranih napadača. Nema količine git reset --hard, git push --force, ili brisanje spremišta može izbrisati ključ iz baze podataka strugača bota koji je već preuzeo vaš urezivanje u drugom #2. Prijavite se na AWS IAM, Stripe, OpenAI, konzole baze podataka ili GitHub SSH postavke odmah i Deaktivirajte / Izbriši / Okrenite ključ odmah.
2. Provjerite svoje naplate u oblaku i dnevnike revizije (AWS CloudTrail, GCP Cloud Audit Logs, Stripe Logs) za prozor između vaših git push i vaš opoziv ključa: procurilo je da koriste automatizirani kriptomining botovi AWS_ACCESS_KEY_ID (AKIA...) vjerodajnice u roku od 30 do 90 sekundi za pokretanje GPU instanci maksimalne kvote (p4d.24xlarge / g5.48xlarge) u svim skrivenim AWS regijama (ap-east-1, me-south-1, af-south-1) i kreirajte backdoor IAM korisnike ili Lambda uporne kuke tako da ostaju unutar vašeg AWS naloga čak i nakon što izbrišete ključ koji je procurio.
3. NIKAD ne pritiskajte sekundu "Delete .env" commit - u stvari, kucanje "delete secret" ili "remove password" u poruci urezivanja privlači ciljane scraper botove: Hiljade skripti za aktere prijetnje posebno postavljaju upite GitHub-u Traži poruke urezivanja koje sadrže "remove .env", "delete key", "oops", i "remove credentials", zatim kliknite jedno urezivanje unazad u istoriji da ukradete ključ.
4. ** Prepišite cijelu historiju Git spremišta lokalno koristeći git filter-repo (ili BFG Repo-Cleaner) da biste izrezali datoteku ili redigovali niz lozinke iz svakog povijesnog urezivanja, stabla i oznake**: git filter-branch je službeno zastario Git projektom; koristiti git filter-repo --invert-paths --path .env (da nukirate fajl iz svih urezivanja) ili git filter-repo --replace-text expressions.txt (za zamjenu određenih nizova lozinki sa ***REMOVED*** unutar datoteka koda bez brisanja datoteka).
5. Prisilno gurnite sve grane i oznake (git push origin --force --all), I očisti GitHubove keširane poglede urezivanja na strani servera (dangling commits): Evo tajne koju većina programera ne zna: čak i nakon što pokrenete git filter-repo i git push --force, GitHubovi serveri održavaju stari SHA urezivanja živim u svom objektnom kešu (git cat-file), što znači da svako ko je snimio SHA urezivanje od 40 znakova iz API-ja javnih događaja i dalje može vidjeti github.com/user/repo/commit/<OLD_SHA>. U nastavku objašnjavamo kako odmah očistiti viseće kešove urezivanja putem GitHub podrške / API-ja ili brisanjem i ponovnim kreiranjem spremišta.
6. Instalirajte lokalni pre-commit tajni skener (gitleaks ili trufflehog) unutra .git/hooks/pre-commit prije nego što napišete još jedan red koda: 10 sekundi gitleaks protect --staged pre-commit hook pregledava svaku faznu liniju lokalno na vašem laptopu i blokovima git commit prije nego što neka tajna ikada napusti vašu mašinu.

Stablo odlučivanja: trenutno zadržavanje, rotacija i čišćenje Git istorije¶

Izvršite ovaj tok rada u strogom hronološkom redoslijedu (Opozovi PRVO -> DRUGO Upornost revizije -> Očisti Git historiju TREĆE):

flowchart TD
    Start["Tajna prebačena u javni repo (.env, AWS/GCP ključ, DB lozinka, Stripe/OpenAI ključ ili privatni SSH ključ)"] --> Step1["MINUTA 0 DO 2 (PRIORITET #1): Odmah opozovite / bacite svaki otkriveni ključ na konzoli dobavljača"]

    Step1 --> SecretType{"Koja je vrsta akreditiva bila unutar urezivanja?"}

    SecretType -->|"Ključ infrastrukture oblaka (AWS AKIA, GCP servisni račun JSON, Azure SP)"| CloudAudit["MINUTA 2 DO 10: Provjerite CloudTrail / Dnevnike aktivnosti -> Završi Rogue EC2/Compute instance u svim regijama -> Izbriši neovlaštene IAM korisnike/uloge/STS sesije"]

    SecretType -->|"URI baze podataka / lozinka (Postgres, MySQL, MongoDB, Redis, Supabase)"| DBAudit["MINUTE 2 DO 10: Rotirajte DB korisničku lozinku + ukinite aktivne veze (pg_terminate_backend) + zaključajte sigurnosnu grupu zaštitnog zida samo na IP-ove na bijeloj listi"]

    SecretType -->|"API token ili SSH ključ (Stripe, OpenAI, GitHub PAT, Slack, privatni SSH ključ)"| TokenAudit["MINUTA 2 DO 10: Ubacite API ključ na kontrolnu ploču / Uklonite javni SSH ključ iz $HOME/.ssh/authorized_keys & GitHub postavke -> Revizija nedavnih dnevnika korištenja API-ja"]

    CloudAudit --> RepoVisibility{"MINUTA 10 DO 20: Kako želite da očistite GitHub repozitorijum?"}
    DBAudit --> RepoVisibility
    TokenAudit --> RepoVisibility

    RepoVisibility -->|"Najbrže 100% brisanje predmemorije (bez kritičnih problema/povijest zvijezda za čuvanje)"| NukeRepo["1. Izbrišite čitavo spremište na GitHub postavkama. 2. Pokrenite git filter-repo lokalno za čišćenje istorije. 3. Kreirajte Fresh Repo & Push Clean historiju (trenutačno uništava sve keširane SHA-ove urezivanja)"]

    RepoVisibility -->|"Mora se očuvati postojeće repo zvijezde, problemi, PR-ovi i vilice"| RewriteRepo["1. Pokrenite git filter-repo (--invert-paths ili --replace-text). 2. Pokrenite git push --force --all & --tags. 3. Kontaktirajte GitHub podršku/portal podrške da očistite SHA predmemoriju visećeg urezivanja"]

Faza 1: Minuta 0 do 2 - Trenutni opoziv Cheat Sheet od strane provajdera¶

Ne otvarajte terminal za borbu s njim git rebase dok su vaši proizvodni ključevi još uvijek aktivni. Kliknite direktno na zahvaćenog provajdera u nastavku i prvo ukinite vjerodajnicu:

Faza 2: Minuta 2 do 10 - Provjera da li su napadači već kreirali backdoor (AWS / Cloud Container)¶

Ako ste procurili .env fajl je sadržavao AWS pristupni ključ (AKIA...), Google Cloud Service Account JSON ili Azure Service Principal, brisanje ključa koji je procurio je samo pola bitke. Morate provjeriti da automatizirani bot nije iskoristio tih 90 sekundi da uspostavi postojanost unutar vašeg računa u oblaku:

Forenzička revizija AWS nakon curenja u 6 tačaka¶

1. Provjeri AWS CloudTrail -> Event history za sve API pozive koje je izvršio procureo Access Key ID:
2. Otvorite AWS CloudTrail Console -> Istorija događaja.
3. Promijenite padajući izbornik za traženje iz Samo za čitanje u Access key ID i zalijepite procurilo AKIA... string.
4. Pogledajte svaki događaj zabilježen od trenutka kada ste trčali git push. Konkretno potražite: CreateUser, CreateAccessKey, AttachUserPolicy, CreateRole, AssumeRole, GetSessionToken, RunInstances (EC2), RequestSpotInstances, CreateFunction (Lambda), ili SendEmail (SES spam).
5. Opozovi sve aktivne privremene STS sesije koje je pokrenuo taj korisnik:
6. Čak i nakon što obrišete an AKIA... pristupni ključ, ako je napadač pozvao sts:GetSessionToken prije nego što ste izbrisali ključ, njihov privremeni ASIA... Token sesije ostaje važeći do 36 sati.
7. Ubiti sve aktivne privremeno STS tokene za tog IAM korisnika odmah, idite na IAM -> Users -> [Leaked User] -> Permissions -> Add inline policy i kliknite Revoke sessions (koji prilaže eksplicitno Deny * politika za bilo koji token izdat gdje aws:TokenIssueTime je ranije nego trenutno.).
8. Provjeri IAM -> Users i IAM -> Roles za novokreirane backdoor račune:
9. Sortiraj sve IAM korisnike prema Vrijemenu kreiranja. Izbrišite svakog nepoznatog korisnika (admin-backup, sys-monitor, support-bot) i provjerite Trust relationships karticu na vašim IAM ulogama kako biste bili sigurni da napadač nije dodao svoj vanjski ID AWS računa ("Principal": {"AWS": "arn:aws:iam::999999999999:root"}) kao principal od poverenja.
10. Koristite AWS Resource Explorer ili EC2 Global View da provjerite SVIH 30+ AWS regija za skrivene kriptominere:
11. Napadači rijetko pokreću instance kriptominiranja us-east-1 gdje ćete ih vidjeti na kontrolnoj tabli. Umjesto toga, lansiraju p4d, g5, ili c6i.32xlarge primjeri u ap-southeast-3 (Džakarta), me-central-1 (UAE), il-central-1 (Tel Aviv), ili sa-east-1 (São Paulo).
12. Otvoren EC2 Console -> EC2 Global View (koji skenira svaki omogućeni region u jednoj tabeli) i Odmah ukini sve neovlašćene instance.
13. Odmah otvorite AWS slučaj za naplatu podrške ako su lažne instance pokrenule račun:
14. Ako se bot zavrti $8,000 od EC2 GPU instanci prije nego što ste ih prekinuli, ne paničarite: nakon što ste osigurali račun, izbrisali ključ, omogućili root/IAM MFA, i uklonili ključ sa GitHuba, otvorite Slučaj za podršku za AWS račun i naplatu u kojem se objašnjava slučajni pritisak na GitHub i vaši koraci za popravljanje. AWS rutinski odobrava jednokratni kredit za oprost naplate dobre volje za slučajna curenja ključa GitHub-a nakon što njihov sigurnosni tim potvrdi da je spremište čisto.

Faza 3: Zašto brisanje datoteke u novom urezivanju ne uspije - i kako pravilno prepisati historiju sa git filter-repo¶

1. Zašto git rm .env && git commit -m "delete .env" potpuno je beskorisno¶

Git je sistem datoteka koji se može adresirati samo na sadržaj (Directed Acyclic Graph / DAG urezivanja, stabala i blob objekata): - Pretpostavimo Commit A1B2C3 dodano .env (Blob 998877). - Pretpostavimo da 2 minute kasnije trčite git rm .env, dodaj .env to .gitignore, i pritisnite Commit D4E5F6. - Dok neko pregleda trenutnu listu datoteka na vašoj GitHub početnoj stranici neće vidjeti .env, Povezivanje A1B2C3 i Blob 998877 su i dalje 100 posto dio spremišta. Svako ko se kandiduje git clone preuzimanja Blob 998877, svako ko klikne karticu "Urezivanje" na GitHubu može kliknuti A1B2C3 da pročitam vaše .env fajl u običnom tekstu i automatizovani alati (trufflehog git https://github.com/user/repo) skeniranje svakog povijesnog urezivanja za 2 sekunde.

2. Korak-po-korak: Brisanje datoteke ili tajnog niza u cijeloj historiji korištenja git filter-repo¶

Git projekat i GitHub zvanično preporučuju git-filter-repo (koji zamjenjuje spore, sklone greškama git filter-branch i čak je fleksibilniji od BFG Repo-Cleaner).

1. Instaliraj git-filter-repo (Traje 5 sekundi):

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

2. Napravite sigurnosnu kopiju svoje mape lokalnog spremišta prije ponovnog pisanja historije:

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

   (Napomena: Ako ste već premjestili svoj važeći .env datoteku, pobrinite se za čistu kopiju .env je sačuvan u /tmp/.env.safe izvan repo, jer git filter-repo će obrisati .env iz vašeg radnog direktorija.)
3. Odaberite opciju A (Obriši cijelu putanju datoteke kao .env ili id_rsa) ILI Opcija B (Uredi specifične tajne nizove unutar datoteka koda):
4. Opcija A: Potpuno uklonite .env (ili config/secrets.json) iz svakog urezivanja u historiji:

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

   (Zašto --invert-paths? Bez --invert-paths, git filter-repo --path .env čuva SAMO .env i briše sve ostalo. Kombinovanje --invert-paths --path .env kaže Gitu da zadrži sve OSIM .env preko svih urezivanja, grana i oznaka.)
5. Opcija B: Zadržite fajl koda (app.py / config.js), ali izbrišite tvrdo kodirani tajni niz iz svake istorijske verzije: Kreirajte tekstualni fajl /tmp/secrets-to-scrub.txt koji sadrži jedan tajni niz (ili regex) po redu:

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

   Sad trči 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. Dodaj .env to .gitignore tako da ga ne ponavljate za 5 minuta:

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

7. Ponovo dodajte svoj GitHub daljinski (git filter-repo namjerno uklanja origin kao sigurnosnu provjeru) i silom gurnite sve grane i oznake:

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

Faza 4: Skrivena GitHub keš zamka (Dangling Commits) i kako ga očistiti¶

Evo kritične forenzičke stvarnosti dokumentirane u GitHubovim službenim dokumentima (Uklanjanje osjetljivih podataka iz spremišta): - Kad trčiš git filter-repo i git push origin --force --all, svako urezivanje u vašem spremištu dobija potpuno novi SHA-1 heš od 40 znakova, a vaš main pokazivač grane se pomiče na novu čistu historiju. - MEĐutim, GitHubov backend Git server za pohranu NE prikuplja odmah smeće (git gc --prune=now) staro, nereferencirano urezivanje SHA. - To znači da ako je bot napadača snimio stari hash urezivanja (npr. a1b2c3d4...) iz javnog GitHub Events API-ja kada ste prvi put pritisnuli, i dalje se mogu otvoriti https://github.com/YOUR_USERNAME/YOUR_REPO/commit/a1b2c3d4... u bilo kojem web pretraživaču i pregledajte svoje .env datoteku čak i NAKON što ste prisilno gurnuli čistu historiju. Još gore, ako se tajna pojavi unutar Zahtjeva za povlačenje, refs/pull/12/head održava taj urezivanje trajno dostupnim.

Kako trenutno uništiti keširane/viseće urezivanja na GitHubovim serverima:¶

1. Metoda 1 (trenutno, 100% potpuno brisanje - najbolje ako repo nema kritičnih problema/PR-ova/zvjezdica):
2. Idite u svoje spremište na GitHub -> Settings -> Skrolujte do dna (Danger Zone) -> Kliknite Delete this repository.
3. Napravite potpuno novo spremište sa istim imenom na GitHubu i očistite ga git filter-repo lokalno spremište na njega (git push -u origin main).
4. Brisanje spremišta na GitHubu odmah razbija sve javne web prikaze starih keširanih SHA-ova urezivanja (404 Not Found).
5. Metoda 2 (Očuvanje zvijezda, problema i PR-ova - korištenje podrške za GitHub / čišćenje predmemorije):
6. Prvo uzmite tačan SHA heš od 40 znakova starog urezivanja koji je sadržavao tajnu (provjerite git reflog u vašoj sigurnosnoj mapi ili vašim GitHub e-porukama s obavijestima).
7. Otvorite GitHub podršku (support.github.com) i koristite automatizirani tok rada Ukloni osjetljive podatke / Očisti keširane prikaze urezivanja (pozivajući se na URL spremišta i tačan SHA(ove) urezivanja). Automatski alat GitHub Support-a pokreće trenutnu serversku stranu git gc čišćenje predmemorije koje poništava keširane web poglede i nereferencirane objekte bez brisanja vašeg spremišta.
8. Obavijestite sve saigrače/saradnike git clone svježe (NIKAD git pull):
9. Recite svakom programeru u svom timu: "NE trčite git pull i push." Ako kolega koji je ranije izvukao lošu commit trči git pull (koji spaja staru prljavu historiju sa novom prepisanom historijom) i gura, oni će gurnuti izbrisanu .env urezivanje odmah nazad na GitHub. Svaki saradnik mora ili izbrisati svoj lokalni folder i pokrenuti novi git clone, ili trči git fetch origin && git reset --hard origin/main.

Faza 5: Zauvijek sprječavanje budućih curenja (Gitleaks Pre-Commit Hook & GitHub Push zaštita)¶

Odvojite 60 sekundi odmah kako biste učinili matematički nemogućim ponovno slučajno upisivanje tajne:

1. Omogućite besplatan GitHub "Push Protection for Yourself" na cijelom vašem GitHub računu:
2. Idite na GitHub Settings (Postavke vašeg ličnog profila, gore desno) -> Code security and analysis (ili Code security).
3. Skrolujte do Secret scanning -> Omogući Push protection for yourself.
4. Kada je ovo uključeno, kad god trčite git push sa bilo kog računara u bilo koje javno ili privatno spremište, GitHubov server pregledava vašu dolaznu datoteku paketa prije prihvaćanja push: ako otkrije AWS ključ, OpenAI ključ, Stripe ključ, Privatni SSH ključ ili Slack token, GitHub odbija git push pravo u vašem terminalu prije nego što urezivanje ikad počne uživo.
5. Instaliraj gitleaks kao lokalac pre-commit zakačite svoj 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
   

Regionalni brojevi za hitne slučajeve i protokoli agencija¶

Ako slučajno GitHub guranje vjerodajnica dovede do neovlaštenog upada u regulirane lične podatke (PII / PHI), zdravstveni sistemi ili državna infrastruktura, slijede obavezne protokole obavještavanja o kršenju:

• Sjedinjene Američke Države i Kanada:
• Hitna životna sigurnost / prekid kritične infrastrukture: birajte 911 ako povreda infrastrukture utiče na rad bolnice ili kontrolu fizičke sigurnosti.
• Agencija za sajber sigurnost i sigurnost infrastrukture (CISA) & FBI (IC3): Ako su napadači koristili ključeve oblaka koji su procurili da eksfiltriraju podatke ili implementiraju zlonamjerni softver za iznudu, prijavite se CISA-i (1-844-Say-CISA / cisa.gov/report) i FBI centar za žalbe na internet kriminal (ic3.gov).
• Obavijest o kršenju podataka SEC, FTC i državnog tužioca: Ako CloudTrail / evidencija pristupa bazi podataka pokaže da je neovlaštena IP adresa pristupila ličnim podacima korisnika (PII) ili zdravstvene kartone (HIPAA ePHI) prije nego što je ključ koji je procurio povučen, odmah se konsultujte sa pravnim savjetnikom u vezi sa vremenskim rokovima za obavještavanje o kršenju podataka u državi i saveznim HHS OCR / FTC Pravilom zaštite izvještavanja.
• Kanadski centar za sajber sigurnost: Pozovite 1-833-CYBER-88 (1-833-292-3788) ili prijavite kršenje privatnosti pod PIPEDA Uredu komesara za privatnost Kanade (OPC).
• Ujedinjeno Kraljevstvo:
• Hitna pomoć: Pozovite 999 (ili 101 / Action Fraud 0300 123 2040 i Nacionalni centar za sajber sigurnost / NCSC at ncsc.gov.uk).
• Kancelarija Poverenika za informacije (ICO - 72-satni UK GDPR prozor): Ako je procurila vjerodajnica omogućila neovlašteni pristup ličnim podacima stanovnika Ujedinjenog Kraljevstva, Član 33 UK GDPR zahtijeva prijavljivanje kršenja ličnih podataka ICO (0303 123 1113) u roku od 72 sata od saznanja o kršenju.
• Evropska unija:
• Hitna pomoć: Pozovite 112 u svim zemljama članicama EU.
• Izvještavanje o incidentima, član 33 GDPR & NIS2 direktive: Organizacije koje podliježu EU GDPR moraju procijeniti da li je izlaganje akreditiva rezultiralo kršenjem povjerljivosti ličnih podataka (72-satno obavještenje nacionalnom tijelu za zaštitu podataka / DPA), dok su bitni/važni subjekti pod EU NIS2 Direktiva suočava se sa 24-satnim rokom za rano upozoravanje za svoje državljane CSIRT (BSI u Njemačkoj, ANSSI u Francuskoj, ACN u Italiji) za značajne sajber incidente.
• Australija i Novi Zeland:
• Hitna pomoć: Pozovite 000 u Australiji ili 111 na Novom Zelandu.
• Australski centar za sajber sigurnost (ACSC) i povrede podataka koje je potrebno prijaviti (OAIC): Pozovi 1300 CYBER1 (1300 292 371) za odgovor na incident i procjenu obaveza obavještavanja prema Uredu australskog povjerenika za informacije (OAIC) Kršenja podataka o kojima je potrebno obavijestiti (NDB) shema ili Zakon o privatnosti Novog Zelanda 2020. (Privacy Commissioner).
• Indija i azijsko-pacifički region:
• Hitna pomoć: Pozovite 112 u Indiji (ili 1930 za sajber kriminal).
• CERT-In Direktiva o obaveznom 6-satnom izvještavanju (Indija): Pod Indijski tim za hitne slučajeve (CERT-In) smjernice (No. 20(3)/2022-CERT-In), neovlašteni pristup oblaku/IT sistemima ili curenje podataka koje utiče na organizacije u Indiji mora se prijaviti incident@cert-in.org.in u roku od 6 sati od detekcije.

Često postavljana pitanja¶

Izbrisao sam .env datoteku i gurnuo novo urezivanje 30 sekundi nakon moje greške - da li i dalje trebam rotirati svoje API ključeve i lozinke baze podataka?¶

Da, 100 posto - rotirajte svaki taster odmah bez izuzetka. Akademske studije kibernetičke sigurnosti i telemetrija iz GitHub Secret Scanning potvrđuju da automatizirani botovi za prikupljanje akreditiva nadgledaju javni tok GitHub događaja (api.github.com/events) u realnom vremenu i preuzmite novo gurnute urezivanja unutar 1,5 do 5 sekundi. Još gore, guranje drugog urezivanja koje briše .env ostavlja cijeli otvoreni tekst .env datoteka koja se trajno nalazi unutar dif-a historije prvog urezivanja - i mnogi botovi posebno traže urezivanja koja brišu .env datoteke. Jednom kada je tajna gurnuta u javno spremište čak i na 1 sekundu, ona je zauvijek ugrožena; opoziv i rotiranje akreditiva na kontrolnoj tabli dobavljača je jedina stvar koja vas štiti.

Šta ako je spremište bilo PRIVATNI GitHub repo kada sam izvršio .env fajl, a ja samo želim da ga očistim pre nego što objavim repo sledeće nedelje?¶

Ako je spremište bilo 100 posto privatno cijelo vrijeme (i nijedna nepouzdana CI/CD aplikacija nije imala pristup), botovi scraper na javnom GitHub Events API-ju su imali ne već sam vidio tvoju tajnu. Međutim, NEMOJTE jednostavno izbrisati `.env` u novom urezivanju, a zatim okrenite repo sa privatnog na javno. U trenutku kada prebacite privatno spremište u javno, to je cijeli historijski graf urezivanja postaje javno - i botovi odmah skeniraju sva stara urezivanja u novom javnom repo-u. Prije nego što privatni repo učinite javnim, ili: (1) Pokrenite git filter-repo --invert-paths --path .env da uklonite fajl iz svih istorijskih urezivanja (i rotirajte ključeve u svakom slučaju radi najbolje prakse), ILI (2) Kopirajte čiste trenutne datoteke u potpuno novu fasciklu, pokrenite git init za čistu početnu istoriju od 1 urezivanja i objavite to novo spremište.

Zašto je AWS automatski priložio politiku pod nazivom AWSCompromisedKeyQuarantineV2 mom IAM korisniku, i zašto mi se još uvijek naplaćuje?¶

Zato što je AWS direktno partner s GitHub Secret Scanning-om, kad god AKIA... ključ se pojavljuje u javnom GitHub urezivanju, AWS-ov automatizirani sigurnosni sistem ga otkriva u roku od nekoliko minuta, otvara tiket za podršku i prilaže upravljanu politiku AWSCompromisedKeyQuarantineV2 (ili V3) tom IAM korisniku. Ta politika karantina blokira očigledne opasne radnje poput pokretanja novih ec2:RunInstances ili brisanje S3 buckets - ali NE ukida EC2 instance koje je napadač već pokrenuo tokom prvih 60 sekundi prije dodavanja politike, niti briše backdoor IAM korisnike ili privremene STS sesije koje je napadač već kreirao. I dalje morate ručno izbrisati ključ koji je procurio, provjerite EC2 Global View u svim regijama da ukinete lažne instance i provjerite CloudTrail za neovlaštene promjene IAM-a.

Koja je razlika između git filter-repo i BFG Repo-Cleaner, a zašto ne bih koristio git filter-branch?¶

git filter-grana je stara naslijeđena shell skripta ugrađena u rane verzije Gita koja je izuzetno spora na velikim spremištima, lako se pogrešno konfigurirati (ostavljajući rezervne reference u refs/original/ koji još uvijek sadrže vaše tajne.), i sada ispisuje službeno upozorenje o zastarjevanju od Gita koje vam govori da ga ne koristite. Oba git-filter-repo (napisano na Python-u i službeno odobreno od strane osnovnih Git održavača i GitHuba) i BFG Repo-Cleaner (napisano u Java/Scala) radi 10x do 100x brže i čisto prepisuje sva urezivanja, stabla i oznake. git-filter-repo danas se općenito preferira jer mijenja čak i vaše trenutno odjavljeno urezivanje (`HEAD`) bez potrebe za posebnim preliminarnim urezivanjem.

Kako neko još uvijek može vidjeti moje izbrisano urezivanje na GitHubu nakon što sam pokrenuo git filter-repo i git push --force?¶

u Gitu, `git push --force` samo ažurira referentni pokazivač grane (`refs/heads/main`) da ukaže na vaš novi prepisani lanac urezivanja; ima ne odmah obrišite stare nereferencirane ("viseće") objekte urezivanja pohranjene na pozadinskim serverima GitHub-a. Ako je bot snimio SHA hash od 40 znakova vašeg originalnog urezivanja kada je pogodio API javnih događaja, idite direktno na https://github.com/owner/repo/commit/<40-char-SHA> će i dalje učitavati to napušteno urezivanje iz GitHubove predmemorije objekata dok se ne pokrene sakupljanje smeća. Da odmah izbacite taj keširani prikaz izbrišite spremište na GitHub-u i ponovo ga kreirajte iz vašeg čistog lokalnog repo-a, ili pošaljite viseće urezivanje SHA GitHub podrška (`support.github.com`) za trenutno čišćenje keša na strani servera.

Šta ako je neko već kliknuo na "Fork" na mom javnom spremištu prije nego što sam pokrenuo git filter-repo?¶

Evo zašto Prvi korak je uvijek opozivanje i rotiranje akreditiva na kontrolnoj tabli dobavljača: trčanje git filter-repo i prisilno guranje u vaše vlastito spremište NE prepisuje urezivanja unutar nečijeg nezavisnog forka vašeg spremišta (osim ako ne izbrišete cijelo svoje roditeljsko spremište i kontaktirate GitHub podršku u vezi s osjetljivim podacima u forksovima). Nakon što opozovete AWS/API ključeve i rotirate lozinke baze podataka, svaka kopija stare .env datoteka koja se nalazi unutar vilice ili bot baze podataka treće strane postaje mrtav, beskorisni niz znakova koji više ne može pristupiti vašoj infrastrukturi.

Povezani vodiči¶

• Ransomware i zlonamjerni softver: trenutno obuzdavanje i oporavak
• Otmica imena domena, istekli DNS i preuzimanje web stranice
• Google Workspace ili Microsoft 365 prilagođeno zaključavanje administratora domene i spašavanje DNS-a
• Krađa identiteta i kompromitovani računi: hitno zaključavanje
• Slučajan rm -rf ili Shift-Delete na Linuxu, macOS-u ili Windowsu: trenutno ponovno montiranje samo za čitanje
• Brojevi za hitne slučajeve po zemljama

Izvori i službene upute¶

• GitHub zvanična sigurnosna dokumentacija (docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository): Uklanjanje osjetljivih podataka iz spremišta (git filter-repo, BFG Repo-Cleaner, Čišćenje predmemorije visećeg urezivanja i Push zaštita tajnog skeniranja).
• Amazon Web Services (AWS) Vodič za odgovor na sigurnosne incidente (docs.aws.amazon.com/security/): Odgovaranje na izložene AWS IAM pristupne ključeve (AWSCompromisedKeyQuarantineV2, Opoziv privremeno STS Sesije preko aws:TokenIssueTime, i CloudTrail Forenzička revizija).
• Nacionalni institut za standarde i tehnologiju (NIST) (Sjedinjene Američke Države): Specijalna publikacija 800-61 Rev. 2: Vodič za rukovanje incidentima u kompjuterskoj sigurnosti & SP 800-57: Preporuka za upravljanje ključevima (kompromitovani opoziv akreditiva i kriptografska rotacija).
• Otvorite projekat sigurnosti web aplikacija (OWASP): * Cheat Sheet za upravljanje tajnama (sprečavanje tvrdokodiranih akreditiva, tajno skeniranje prije urezivanja sa Gitleaks/TruffleHogi Ephemeral Runtime Secret Injection)*.
• Agencija za sajber sigurnost i sigurnost infrastrukture (CISA) (Sjedinjene Američke Države): Referentna tehnička arhitektura sigurnosti u oblaku i Priručnik za popravku kompromitovanih akreditiva.