Náhodne zatlačené .env Tajomstvá alebo kľúče AWS k verejnému úložisku GitHub: Prečo ho odstránenie súboru neskryje¶

Uvedomenie si desať sekúnd po behu git push origin main (alebo preklopením súkromného úložiska na Public), že váš záväzok obsahoval obyčajný text .env súbor, AWS AKIA... Prístupový kľúč a tajný kľúč, kľúč OpenAI/Anthropic API, pruh sk_live_... produkčný token, URI databázy PostgreSQL/MongoDB s heslom alebo nešifrované $HOME/.ssh/id_ed25519 Súkromný kľúč je núdzová situácia v oblasti kybernetickej bezpečnosti s piatimi poplachmi. Botnety s automatickým zberom poverení priebežne zisťujú verejné GitHub Events Firehose (api.github.com/events) a klonovať novo zaslané potvrdenia do 1,5 až 4 sekúnd od vášho git push dokončenie. Čo je horšie, takmer každý vývojár v panike robí presne tú istú fatálnu chybu: vymaže súbor .env súbor lokálne, pridajte .env do .gitignorea odošlite druhé potvrdenie s názvom "remove .env" alebo "oops". Odoslanie druhého odovzdania, ktoré odstráni .env nič neskrýva: tajomstvo otvoreného textu zostáva 100 percent čitateľné navždy v rámci rozdielu predchádzajúceho odovzdania (git log -p), a to aj v prípade, že stlačíte silou (git push --force) cez vetvu, nereferencovaný commit (dangling blob) zostáva verejne prístupná prostredníctvom svojej priamej adresy URL GitHub a zobrazení žiadosti o stiahnutie vo vyrovnávacej pamäti, kým nebude explicitne vymazaná. Ak uniknuté poverenia už útočníci použili na nasadenie ransomvéru, ukradnutie vašej domény DNS alebo uzamknutie vášho cloudového nájomcu, pozrite si naše sprievodné príručky na odpoveď na ransomvér a malvér, únos doménových mien, skončené DNS a prevzatie webových stránok, a Uzamknutie správcu vlastnej domény Google Workspace alebo Microsoft 365. Ak únik poverení ovplyvní bezpečnosť pacienta v nemocnici, fyzické priemyselné ovládacie prvky alebo infraštruktúru núdzového odoslania, zavolajte na miestne tiesňové číslo (911 v Spojených štátoch a Kanade, 112 v celej Európskej únii, 999 v Spojenom kráľovstve) alebo si pozrite náš medzinárodný adresár tiesňové čísla.

Urobte to teraz¶

1. NAJPRV ZRUŠTE, DEAKTIVUJTE A OTOČTE každé jedno odhalené tajomstvo na konzole poskytovateľa - v priebehu prvých 120 sekúnd - predtým, než stratíte jedinú sekundu behu git príkazy: Keď sa tajomstvo dotkne verejného úložiska GitHub, GitLab alebo Bitbucket čo i len na 3 sekundy, považujte tento kľúč za trvalo spálený a už ho majú v rukách automatizovaní útočníci. Žiadne množstvo git reset --hard, git push --force, alebo vymazanie úložiska môže vymazať kľúč z databázy scraper bota, ktorý už stiahol vaše odovzdanie v druhom #2. Prihláste sa práve teraz do nastavení AWS IAM, Stripe, OpenAI, databázových konzol alebo GitHub SSH a Deaktivujte / Vymažte / Okamžite prejdite kľúčom.
2. Auditujte svoju fakturáciu v cloude a denníky auditu (AWS CloudTrail, GCP Cloud Audit Logs, Stripe Logs) pre okno medzi vašimi git push a zrušenie vášho kľúča: Uniklo používanie automatizovaných robotov na kryptomináciu AWS_ACCESS_KEY_ID (AKIA...) poverenia do 30 až 90 sekúnd, aby sa roztočili inštancie GPU s maximálnou kvótou (p4d.24xlarge / g5.48xlarge) vo všetkých skrytých regiónoch AWS (ap-east-1, me-south-1, af-south-1) a vytvárať backdoor IAM užívateľov resp Lambda perzistenčné háčiky, takže zostanú vo vašom účte AWS aj po odstránení uniknutého kľúča.
3. NIKDY nestláčajte ani sekundu "Delete .env" commit - vlastne písanie "delete secret" alebo "remove password" v správe potvrdenia priťahuje cielené roboty škrabnutia: Tisíce skriptov aktérov hrozieb špecificky vyhľadávajú GitHub Hľadať správy potvrdenia obsahujúce "remove .env", "delete key", "oops", a "remove credentials", potom kliknite v histórii o jedno odovzdanie dozadu a ukradnite kľúč.
4. ** Prepíšte celú históriu úložiska Git lokálne pomocou git filter-repo (alebo BFG Repo-Cleaner) vyňať súbor alebo redigovať reťazec hesla z každého historického odovzdania, stromu a značky**: git filter-branch je oficiálne zastaraný projektom Git; použiť git filter-repo --invert-paths --path .env (na nuke súboru zo všetkých odovzdaní) alebo git filter-repo --replace-text expressions.txt (na nahradenie konkrétnych reťazcov hesiel ***REMOVED*** vnútri kódových súborov bez odstránenia súborov).
5. ** Vynútené zatlačenie všetkých vetiev a značiek (git push origin --force --all), A vyčistite zobrazenia potvrdenia uloženého vo vyrovnávacej pamäti servera GitHub (dangling commits)**: Toto je tajomstvo, ktoré väčšina vývojárov nepozná: dokonca aj po spustení git filter-repo a git push --force,Servery GitHub udržujú staré odovzdanie SHA nažive vo svojej vyrovnávacej pamäti objektov (git cat-file), čo znamená, že každý, kto zaznamenal 40-znakové odovzdanie SHA z verejného rozhrania Events API, môže stále zobraziť github.com/user/repo/commit/<OLD_SHA>. Nižšie vysvetľujeme, ako okamžite vyčistiť visiace vyrovnávacie pamäte odovzdania prostredníctvom podpory GitHub / API alebo odstránením a opätovným vytvorením úložiska.
6. Nainštalujte lokálny pre-commit tajný skener (gitleaks alebo trufflehog) vo vnútri .git/hooks/pre-commit predtým, než napíšete ďalší riadok kódu: 10 sekúnd gitleaks protect --staged hák vopred skontroluje každú fázovanú linku lokálne na vašom notebooku a zablokuje ju git commit skôr, než tajomstvo opustí váš stroj.

Rozhodovací strom: okamžité obmedzenie, rotácia a vyčistenie histórie Git¶

Vykonajte tento pracovný postup v prísnom chronologickom poradí (Zrušiť PRVÉ -> Trvanie auditu DRUHÉ -> Vyčistiť históriu Git TRETIE):

flowchart TD
    Start["Secret Pushed to Public Repo (.env, kľúč AWS/GCP, heslo DB, kľúč Stripe/OpenAI alebo súkromný kľúč SSH)"] --> Step1["MINÚTA 0 AŽ 2 (PRIORITA #1): Okamžite odvolajte / otočte každý odhalený kľúč v konzole poskytovateľa"]

    Step1 --> SecretType{"Aký typ poverenia bol vo vnútri výboru?"}

    SecretType -->|"Kľúč cloudovej infraštruktúry (AWS AKIA, GCP Service Account JSON, Azure SP)"| CloudAudit["2. AŽ 10. MINÚTA: Skontrolujte CloudTrail / Protokoly aktivít -> Ukončite Rogue EC2/výpočtové inštancie vo všetkých regiónoch -> Odstrániť neautorizovaných používateľov/role/relácie STS"]

    SecretType -->|"Identifikátor URI / heslo databázy (Postgres, MySQL, MongoDB, Redis, Supabase)"| DBAudit["2. AŽ 10. MINÚTA: Otočte používateľské heslo do databázy DB + zrušte aktívne pripojenia (pg_terminate_backend) + uzamknite skupinu zabezpečenia brány firewall len na adresy IP na zozname povolených"]

    SecretType -->|"API token alebo kľúč SSH (Stripe, OpenAI, GitHub PAT, Slack, súkromný kľúč SSH)"| TokenAudit["2. AŽ 10. MINÚTA: Zrolujte kľúč API na informačnom paneli / odstráňte verejný kľúč SSH z $HOME/.ssh/authorized_keys a nastavení GitHub -> Audit nedávnych protokolov používania rozhrania API"]

    CloudAudit --> RepoVisibility{"10. AŽ 20. MINÚTA: Ako chcete vyčistiť úložisko GitHub?"}
    DBAudit --> RepoVisibility
    TokenAudit --> RepoVisibility

    RepoVisibility -->|"Najrýchlejšie 100% vymazanie vyrovnávacej pamäte (žiadne kritické problémy/hviezdičková história, ktorá by sa mala uchovávať)"| NukeRepo["1. Odstráňte celé úložisko v nastaveniach GitHub. 2. Ak chcete vyčistiť históriu, spustite git filter-repo lokálne. 3. Vytvorte novú históriu repo & Push Clean History (okamžite zničí všetky uložené SHA)"]

    RepoVisibility -->|"Musí zachovať existujúce repo hviezdičky, problémy, PR a vidličky"| RewriteRepo["1. Spustite git filter-repo (--invert-paths alebo --replace-text). 2. Spustite git push --force --all & --tags. 3. Obráťte sa na portál podpory/podpory GitHub, aby ste vyčistili vyrovnávaciu pamäť visiaceho záväzku SHA"]

Fáza 1: Minúta 0 až 2 - Okamžité zrušenie Cheat Sheet od Poskytovateľa¶

neotvárajte terminál, s ktorým môžete bojovať git rebase kým sú vaše produkčné kľúče stále aktívne. Kliknite priamo na dotknutého poskytovateľa nižšie a najskôr zabite poverenie:

Fáza 2: 2. až 10. minúta - Kontrola, či si útočníci už nevytvorili zadné vrátka (AWS / Cloud Containment)¶

Ak váš unikol .env súbor obsahoval prístupový kľúč AWS (AKIA...), Google Cloud Service Account JSON alebo Azure Service Principal, odstránenie uniknutého kľúča je len polovica úspechu. Musíte overiť, či automatizovaný robot nepoužil týchto 90 sekúnd na vytvorenie trvalosti vo vašom cloudovom účte:

6-bodový forenzný audit AWS po úniku¶

1. Skontrolujte AWS CloudTrail -> Event history pre všetky volania API uskutočnené únikom Access Key ID:
2. Otvorte AWS CloudTrail Console -> História udalostí.
3. Zmeňte rozbaľovaciu ponuku vyhľadávania z Iba na čítanie na Access key ID a prilepte uniknuté AKIA... reťazec.
4. Pozrite sa na každú zaznamenanú udalosť od okamihu, keď ste spustili git push. Hľadajte konkrétne: CreateUser, CreateAccessKey, AttachUserPolicy, CreateRole, AssumeRole, GetSessionToken, RunInstances (EC2), RequestSpotInstances, CreateFunction (Lambda), príp SendEmail (SES spam).
5. Zrušte všetky aktívne dočasné STS relácie vytvorené týmto používateľom:
6. Dokonca aj po odstránení AKIA... prístupový kľúč, ak útočník zavolal sts:GetSessionToken pred odstránením kľúča ich dočasné ASIA... token relácie zostáva platný až 36 hodín.
7. Zabiť všetky aktívne dočasné STS tokeny pre daného používateľa IAM okamžite prejdite na IAM -> Users -> [Leaked User] -> Permissions -> Add inline policy a kliknite na Revoke sessions (ktorý je pripojený explicitne Deny * politika pre akýkoľvek token vydaný kde aws:TokenIssueTime je skôr ako teraz.).
8. Skontrolujte IAM -> Users a IAM -> Roles pre novovytvorené backdoor účty:
9. Zoradiť všetkých používateľov IAM podľa času vytvorenia. Odstráňte neznámeho používateľa (admin-backup, sys-monitor, support-bot) a overte si Trust relationships kartu vo svojich rolách IAM, aby ste sa uistili, že útočník nepridal svoje vlastné externé ID účtu AWS ("Principal": {"AWS": "arn:aws:iam::999999999999:root"}) ako dôveryhodný príkazca.
10. PoužiťAWS Resource Explorer** alebo EC2 Global View aby ste skontrolovali VŠETKÝCH 30+ AWS regiónov, či neobsahujú skryté kryptomíny**:
11. Útočníci zriedka spúšťajú inštancie kryptomeny us-east-1 kde ich uvidíte na palubnej doske. Namiesto toho sa spúšťajú p4d, g5, alebo c6i.32xlarge prípady v ap-southeast-3 (Jakarta), me-central-1 (SAE), il-central-1 (Tel Aviv) alebo sa-east-1 (São Paulo).
12. Otvoriť EC2 Console -> EC2 Global View (ktorá prehľadá každý povolený región v jednej tabuľke) a Okamžite ukončite všetky neoprávnené inštancie.
13. Okamžite otvorte prípad fakturácie podpory AWS, ak nečestným inštanciám vyšiel účet:
14. Ak sa bot otočil $8,000 inštancií EC2 GPU predtým, ako ste ich ukončili, neprepadajte panike: keď ste zabezpečili účet, odstránili kľúč, povolili root/IAM MFAa odstránili kľúč z GitHubu, otvorte Prípad podpory účtu AWS a fakturácie s vysvetlením náhodného push GitHub a vašich krokov na nápravu. AWS bežne udeľuje jednorazový kredit za odpustenie fakturácie dobrej vôle za náhodné úniky kľúčov GitHub, keď ich bezpečnostný tím overí, či je úložisko čisté.

Fáza 3: Prečo vymazanie súboru v novom potvrdení zlyhá - a ako správne prepísať históriu pomocou git filter-repo¶

1. Prečo git rm .env && git commit -m "delete .env" je úplne zbytočné¶

Git je súborový systém s adresným obsahom iba na pridávanie (Directed Acyclic Graph / DAG odovzdaní, stromov a objektov blob): - Predpokladajme, že Zaviazať sa A1B2C3 pridané .env (Blob 998877). - Predpokladajme, že o 2 minúty neskôr bežíte git rm .env, pridajte .env do .gitignorea stlačte Potvrdiť D4E5F6. - Keď si niekto prezerá aktuálny zoznam súborov na vašej domovskej stránke GitHub, neuvidí .env,Zaviazať sa A1B2C3 a Blob 998877 sú stále 100 percent súčasťou úložiska. Každý, kto spustí git clone sťahovania Blob 998877, môže kliknúť ktokoľvek, kto klikne na kartu "Záväzky" na GitHub A1B2C3 čítať svoje .env súbor vo formáte obyčajného textu a automatizované nástroje (trufflehog git https://github.com/user/repo) skenovanie každého jedného historického odovzdania za 2 sekundy.

2. Krok za krokom: Vymazanie súboru alebo tajného reťazca v celej histórii pomocou git filter-repo¶

Projekt Git a GitHub oficiálne odporúčajú git-filter-repo (ktorý nahrádza pomalý, náchylný na chyby git filter-branch a je ešte flexibilnejší ako BFG Repo-Cleaner).

1. Inštalovať git-filter-repo (Trvá 5 sekúnd):

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

2. Pred prepísaním histórie si vytvorte bezpečnostnú záložnú kópiu priečinka lokálneho úložiska:

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

   (Poznámka: Ak ste už presunuli svoje platné .env založte, uistite sa, že máte čistú kópiu .env je uložený v /tmp/.env.safe mimo repo, pretože git filter-repo zotrie sa .env aj z vášho pracovného adresára.)
3. Vyberte možnosť A (Vymazať celú cestu súboru ako .env alebo id_rsa) ALEBO Možnosť B (Upraviť špecifické tajné reťazce v súboroch kódu):
4. Možnosť A: Úplne odstráňte .env (alebo config/secrets.json) z každého odovzdania v histórii:

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

   (Prečo --invert-paths? Bez --invert-paths, git filter-repo --path .env uchováva LEN .env a vymaže všetko ostatné. Kombinovanie --invert-paths --path .env povie Gitu, aby si nechal všetko OKREM .env vo všetkých potvrdeniach, vetvách a značkách.)
5. Možnosť B: Ponechajte súbor s kódom (app.py / config.js), ale vymažte pevne zakódovaný tajný reťazec z každej historickej verzie: Vytvorte textový súbor /tmp/secrets-to-scrub.txt obsahujúci jeden tajný reťazec (alebo regulárny výraz) na riadok:

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

   Teraz bežte 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. Pridať .env do .gitignore aby ste to znova nespáchali o 5 minút:

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

7. Znova pridajte diaľkové ovládanie GitHub (git filter-repo zámerne odstraňuje origin ako bezpečnostnú kontrolu) a silou zatlačte všetky vetvy a štítky:

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

Fáza 4: Skrytá pasca vyrovnávacej pamäte GitHub (Dangling Commits) a Ako ho vyčistiť¶

Tu je kritická forenzná realita zdokumentovaná v Oficiálnych dokumentoch GitHubu (Odstránenie citlivých údajov z úložiska): - Keď bežíte git filter-repo a git push origin --force --all, každé odovzdanie vo vašom úložisku dostane úplne nový 40-znakový hash SHA-1 a váš main ukazovateľ vetvy sa presunie do novej čistej histórie. - VŠAK, backendový úložný server Git GitHub NEBUDE okamžite zbierať odpadky (git gc --prune=now) staré, neodkazované odovzdanie SHA. - To znamená, že ak robot útočníka zaznamenal starý hash odovzdania (napr. a1b2c3d4...) z verejného rozhrania GitHub Events API, keď ste ich prvýkrát stlačili, sa stále môžu otvárať https://github.com/YOUR_USERNAME/YOUR_REPO/commit/a1b2c3d4... v ľubovoľnom webovom prehliadači a zobrazte si svoj .env súbor aj PO vynútenom vymazaní histórie. Horšie, ak sa tajomstvo objavilo v Žiadosti o stiahnutie, refs/pull/12/head udržiava tento záväzok trvalo dosiahnuteľný.

Ako zničiť uloženie/visiace commity na serveroch GitHub práve teraz:¶

1. Metóda 1 (okamžité, 100 % úplné vymazanie - najlepšie, ak repo nemá žiadne kritické problémy/PR/hviezdičky):
2. Prejdite do svojho úložiska na GitHub -> Settings -> Prejdite nadol (Danger Zone) -> Kliknite Delete this repository.
3. Vytvorte úplne nové úložisko s rovnakým názvom na GitHub a posuňte svoje čisté git filter-repo miestne úložisko (git push -u origin main).
4. Odstránenie úložiska na GitHub okamžite preruší všetky verejné webové zobrazenia starých SHA odovzdania do vyrovnávacej pamäte (404 Not Found).
5. Metóda 2 (Zachovanie hviezdičiek, problémov a PR - pomocou podpory GitHub / vymazania vyrovnávacej pamäte):
6. Najprv si vezmite presný 40-znakový hash SHA starého odovzdania, ktoré obsahovalo tajomstvo (skontrolujte git reflog v záložnom priečinku alebo v e-mailoch s upozorneniami GitHub).
7. Otvoriť podporu GitHub (support.github.com) a použite automatizovaný pracovný postup Odstráňte citlivé údaje / Vyčistite zobrazenia odovzdania z vyrovnávacej pamäte (s odkazom na adresu URL úložiska a presné visiace príkazy SHA). Automatizovaný nástroj podpory GitHub beží na strane servera git gc vyčistenie vyrovnávacej pamäte, ktoré zruší platnosť webových pohľadov uložených vo vyrovnávacej pamäti a nereferencovaných objektov bez vymazania vášho archívu.
8. Upozorniť všetkých spoluhráčov / spolupracovníkov git clone čerstvé (NIKDY git pull):
9. Povedzte každému vývojárovi vo vašom tíme: „Nespúšťajte git pull a push." Ak kolega, ktorý predtým stiahol zlé odovzdanie, spustí git pull (ktorá spája starú špinavú históriu s novou prepísanou históriou) a stlačí, posunú vymazané .env odovzdať späť na GitHub. Každý spolupracovník musí buď odstrániť svoj lokálny priečinok a spustiť nový git clone, alebo spustiť git fetch origin && git reset --hard origin/main.

Fáza 5: Zabránenie budúcim únikom navždy (Gitleaks Pre-commit Hook & GitHub Push Protection)¶

Nájdite si teraz 60 sekúnd, aby bolo matematicky nemožné znova spáchať nejaké tajomstvo:

1. Povoliť GitHub zadarmo "Push Protection for Yourself" v celom vašom účte GitHub:
2. Prejdite na GitHub Settings (nastavenia vášho osobného profilu, vpravo hore) -> Code security and analysis (alebo Code security).
3. Prejdite na Secret scanning -> Povoliť Push protection for yourself.
4. Keď je toto zapnuté, kedykoľvek bežíte git push z akéhokoľvek počítača do akéhokoľvek verejného alebo súkromného úložiska, server GitHub skontroluje váš prichádzajúci súbor balíka pred prijatím push: ak zistí kľúč AWS, OpenAI, Stripe kľúč, súkromný kľúč SSH alebo Slack token, GitHub odmietne git push priamo vo vašom termináli ešte predtým, ako bude odovzdanie zverejnené.
5. Inštalovať gitleaks ako miestny pre-commit zaveste si notebook:

   # 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
   

Regionálne tiesňové čísla a protokoly agentúr¶

Ak náhodné zaslanie poverení GitHub vedie k neoprávnenému prieniku do regulovaných osobných údajov (PII / PHI), zdravotnícke systémy alebo vládna infraštruktúra sa riadia povinnými protokolmi oznamovania narušenia:

• Spojené štáty a Kanada:
• Núdzová životná bezpečnosť / výpadok kritickej infraštruktúry: Vytočte 911 ak narušenie infraštruktúry ovplyvní prevádzku nemocnice alebo kontroly fyzickej bezpečnosti.
• Agentúra pre kybernetickú bezpečnosť a bezpečnosť infraštruktúry (CISA) a FBI (IC3): Ak útočníci použili uniknuté cloudové kľúče na exfiltráciu údajov alebo nasadenie vydieračského malvéru, nahláste to CISA (1-844-Say-CISA / cisa.gov/report) a FBI Internet Crime Complaint Center (ic3.gov).
• Oznámenie SEC, FTC a generálneho prokurátora o porušení údajov: Ak protokoly prístupu do služby CloudTrail / databázy ukazujú, že k osobným údajom zákazníka pristupovala neoprávnená IP adresa (PII) alebo zdravotné záznamy (HIPAA ePHI) pred odvolaním uniknutého kľúča sa okamžite poraďte s právnym poradcom, pokiaľ ide o časový harmonogram oznamovania porušenia údajov štátu a federálne HHS OCR / pravidlo FTC Safeguards Rule.
• Kanadské centrum pre kybernetickú bezpečnosť: Zavolajte 1-833-CYBER-88 (1-833-292-3788) alebo nahláste porušenia ochrany osobných údajov pod PIPEDA na Úrad kanadského komisára pre ochranu osobných údajov (OPC).
• Spojené kráľovstvo:
• Pohotovostné služby: Vytočte 999 (alebo 101 / Akčný podvod 0300 123 2040 a Národné centrum kybernetickej bezpečnosti / NCSC pri ncsc.gov.uk).
• Úrad komisára pre informácie (ICO - 72-hodinové okno GDPR v Spojenom kráľovstve): Ak uniknuté poverenia umožnili neoprávnený prístup k osobným údajom obyvateľov Spojeného kráľovstva, článok 33 nariadenia GDPR v Spojenom kráľovstve vyžaduje hlásenie porušení ochrany osobných údajov, ktoré je potrebné oznámiť, ICO (0303 123 1113) do 72 hodín odkedy sa o porušení dozvedel.
• Európska únia:
• Pohotovostné služby: Vytočte 112 vo všetkých členských štátoch EÚ.
• Nahlasovanie incidentov podľa článku 33 GDPR a smernice NIS2: Organizácie, na ktoré sa vzťahuje EU GDPR, musia posúdiť, či vystavenie poverenia viedlo k porušeniu dôvernosti osobných údajov (72-hodinové oznámenie národnému úradu na ochranu údajov / DPA), zatiaľ čo podstatné/dôležité subjekty v rámci EÚ NIS2 Smernica čelí 24-hodinovému termínu včasného varovania svojmu štátnemu príslušníkovi CSIRT (BSI v Nemecku, ANSSI vo Francúzsku, ACN v Taliansku) za významné kybernetické incidenty.
• Austrália a Nový Zéland:
• Pohotovostné služby: Vytočte 000 v Austrálii alebo 111 na Novom Zélande.
• Austrálske centrum kybernetickej bezpečnosti (ACSC) a porušenia ochrany údajov podliehajúce oznamovacej povinnosti (OAIC): Volajte 1300 CYBER1 (1300 292 371) pre reakciu na incidenty a posúdenie oznamovacích povinností podľa Úradu austrálskeho informačného komisára (OAIC) Porušenia údajov podliehajúce oznamovacej povinnosti (NDB) systém alebo zákon o ochrane osobných údajov Nového Zélandu z roku 2020 (Privacy Commissioner).
• India a Ázia a Tichomorie:
• Pohotovostné služby: Vytočte 112 v Indii (alebo 1930 pre počítačovú kriminalitu).
• CERT-In Smernica o povinnom 6-hodinovom hlásení (India): Podľa Indického tímu pre počítačovú pohotovosť (CERT-In) trasa (No. 20(3)/2022-CERT-In), neoprávnený prístup do cloudových/IT systémov alebo úniky údajov ovplyvňujúce organizácie v Indii je potrebné nahlásiť na incident@cert-in.org.in do 6 hodín od zistenia.

Často kladené otázky¶

Vymazal som .env súbor a odoslal nový commit 30 sekúnd po mojej chybe - musím stále otáčať svoje kľúče API a heslá databázy?¶

Áno, 100 percent - otočte každý jeden kľúč okamžite bez výnimky. Akademické štúdie kybernetickej bezpečnosti a telemetria od GitHub Secret Scanning potvrdzujú, že roboty na automatizované získavanie poverení monitorujú verejný stream udalostí GitHub (api.github.com/events). 1,5 až 5 sekúnd. Horšie je zatlačenie druhého odovzdania, ktoré odstráni .env ponecháva celý čistý text .env súbor, ktorý je permanentne uložený v rozdiele histórie prvého odovzdania - a mnoho robotov špecificky hľadá odovzdania, ktoré sa odstránia .env súbory. Akonáhle sa tajomstvo presunie do verejného úložiska čo i len na 1 sekundu, je navždy prezradené; zrušenie a otočenie poverenia na dashboarde poskytovateľa je jediná vec, ktorá vás chráni.

Čo ak bol repozitár SÚKROMNÝM úložiskom GitHub, keď som sa zaviazal .env a chcem ho len vyčistiť pred zverejnením repo na budúci týždeň?¶

Ak bolo úložisko 100 percent súkromné po celý čas (a nemali prístup žiadne nedôveryhodné aplikácie CI/CD tretích strán) mali roboty scraper vo verejnom rozhraní GitHub Events API nie ešte videl tvoje tajomstvo. NEODSTRAŇUJTE však jednoducho `.env` v novom potvrdení a potom prepnite repo zo súkromného na verejné. Vo chvíli, keď preklopíte súkromné ​​úložisko na verejné, jeho celý historický graf odovzdania sa stane verejným - a roboti okamžite skenujú všetky staré commity v novom verejnom repo. Pred zverejnením súkromného repo: (1) Spustite git filter-repo --invert-paths --path .env na odstránenie súboru zo všetkých historických potvrdení (a aj tak otočenie kľúčov pre najlepší postup), ALEBO (2) Skopírujte čisté aktuálne súbory do úplne nového priečinka, spustite git init pre čistú počiatočnú históriu 1 potvrdenia a zverejnite tento nový archív.

Prečo AWS automaticky pripojilo politiku tzv AWSCompromisedKeyQuarantineV2 môjmu používateľovi IAM a prečo sa mi stále účtujú?¶

Pretože AWS spolupracuje priamo s GitHub Secret Scanning, kedykoľvek AKIA... kľúč sa objaví vo verejnom potvrdení GitHub, automatizovaný bezpečnostný systém AWS ho zistí v priebehu niekoľkých minút, otvorí podporný lístok a pripojí spravovanú politiku AWSCompromisedKeyQuarantineV2 (alebo V3) tomuto používateľovi IAM. Táto politika karantény blokuje zjavné nebezpečné akcie, ako je spustenie nového ec2:RunInstances alebo vymazanie vedier S3 - ale NEUKONČÍ inštancie EC2, ktoré už útočník spustil počas prvých 60 sekúnd pred pripojením politiky, ani neodstráni používateľov backdoor IAM alebo dočasné STS relácií, ktoré už útočník vytvoril. Uniknutý kľúč musíte ešte ručne odstrániť, skontrolujte EC2 Globálny pohľad vo všetkých regiónoch ukončiť nečestné inštancie a skontrolovať CloudTrail pre neoprávnené zmeny IAM.

Aký je rozdiel medzi git filter-repo a BFG Repo-Cleaner, a prečo by som nemal používať git filter-branch?¶

git filter-branch je starý starý skript shell zabudovaný do skorých verzií Gitu, ktorý je extrémne pomalý na veľkých úložiskách, ľahko sa zle konfiguruje (ponecháva záložné odkazy v refs/original/ ktoré stále obsahujú vaše tajomstvá.) a teraz vytlačí oficiálne varovanie o ukončení podpory od Gitu, ktoré vám povie, aby ste ho nepoužívali. Obaja git-filter-repo (napísané v Pythone a oficiálne schválené hlavnými správcami Git a GitHub) a BFG Repo-Cleaner (napísané v jazyku Java/Scala) bežať 10x až 100x rýchlejšie a čisto prepísať všetky commity, stromy a značky. git-filter-repo je dnes vo všeobecnosti preferovaný, pretože upravuje dokonca aj váš aktuálny odhlásený záväzok (`HEAD`) bez toho, aby sa najprv vyžadoval samostatný predbežný záväzok.

Ako si môže niekto stále prezerať moje odstránené odovzdanie na GitHub po spustení git filter-repo a git push --force?¶

V systéme Git `git push --force` iba aktualizuje referenčný ukazovateľ vetvy (`refs/heads/main`) ukázať na váš nový prepísaný reťazec odovzdania; to robí nie okamžite vymazať staré nereferencované („visiace“) objekty odovzdania uložené na backend serveroch GitHub. Ak robot zaznamenal 40-znakový hash SHA vášho pôvodného odovzdania, keď narazil na verejné rozhranie Events API, prejdite priamo na https://github.com/owner/repo/commit/<40-char-SHA> bude stále načítavať toto osamotené odovzdanie z vyrovnávacej pamäte objektov GitHubu, kým sa nespustí garbage collection. Okamžite odpáliť tento pohľad z vyrovnávacej pamäte odstráňte úložisko na GitHub a znova ho vytvorte z čistého lokálneho úložiskaalebo odošlite visiaci záväzok SHA Podpora GitHub (`support.github.com`) na okamžité vymazanie vyrovnávacej pamäte na strane servera.

Čo ak už niekto klikol na "Fork" na mojom verejnom úložisku predtým, ako som bežal git filter-repo?¶

Toto je dôvod Krok 1 je vždy zrušenie a otočenie poverení na informačnom paneli poskytovateľa: beh git filter-repo a nútené presunutie do vášho vlastného úložiska neprepisuje commity v nezávislom Forku niekoho iného vášho úložiska (pokiaľ nevymažete celé svoje nadradené úložisko a nekontaktujete podporu GitHub ohľadom citlivých údajov vo forkoch). Po odvolaní kľúčov AWS/API a otočení hesiel databázy môžete použiť akúkoľvek starú kópiu .env súbor, ktorý sa nachádza vo vidlici alebo databáze botov tretej strany, sa stáva mŕtvym, zbytočným reťazcom znakov, ktoré už nemajú prístup k vašej infraštruktúre.

Súvisiaci sprievodcovia¶

• Ransomvér a malvér: okamžité obmedzenie a obnovenie
• Únos názvu domény, vypršaný DNS a prevzatie webových stránok
• Uzamknutie správcu vlastnej domény Google Workspace alebo Microsoft 365 a záchrana DNS
• Phishing a napadnuté účty: núdzové uzamknutie
• Náhodné rm -rf alebo Shift-Delete v systéme Linux, macOS alebo Windows: okamžité opätovné pripojenie iba na čítanie
• Tiesňové čísla podľa krajiny

Zdroje a oficiálne pokyny¶

• Oficiálna bezpečnostná dokumentácia GitHub (docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository): Odstránenie citlivých údajov z úložiska (git filter-repo, BFG Repo-Cleaner, Vyčistenie vyrovnávacej pamäte s visiacim potvrdením a ochrana tlačením tajného skenovania).
• Amazon Web Services (AWS) Príručka reakcie na bezpečnostný incident (docs.aws.amazon.com/security/): Reakcia na odkryté prístupové kľúče AWS IAM (AWSCompromisedKeyQuarantineV2, Dočasné zrušenie STS Relácie cez aws:TokenIssueTime, a CloudTrail Forenzný audit).
• Národný inštitút pre štandardy a technológie (NIST) (Spojené štáty americké): Špeciálna publikácia 800-61 Rev. 2: Sprievodca riešením incidentov v oblasti počítačovej bezpečnosti a SP 800-57: Odporúčanie pre správu kľúčov (kompromisované zrušenie poverenia a kryptografická rotácia).
• Otvoriť projekt zabezpečenia webových aplikácií (OWASP): * Cheat Sheet pre správu tajomstiev (prevencia pevne zakódovaných poverení, predbežné overenie tajného skenovania s Gitleaks/TruffleHoga Ephemeral Runtime Secret Injection)*.
• Agentúra pre kybernetickú bezpečnosť a bezpečnosť infraštruktúry (CISA) (Spojené štáty americké): Príručka technickej referenčnej architektúry zabezpečenia cloudu a kompromitovaných poverení.