Fyrir slysni ýtt .env Leyndarmál eða AWS lyklar að opinberri GitHub verslun: Af hverju að eyða skránni felur hana ekki¶

Að átta sig á tíu sekúndum eftir hlaup git push origin main (eða fletti einkageymslu yfir í Public) að skuldbindingin þín innihélt látlausan texta .env skrá, AWS AKIA... Aðgangslykill og leynilykill, OpenAI/Anthropic API lykill, Stripe sk_live_... framleiðslutákn, PostgreSQL/MongoDB gagnagrunns URI með lykilorði eða ódulkóðuðu $HOME/.ssh/id_ed25519 einkalykill er neyðarástand með fimm viðvörunum á netöryggi. Sjálfvirk auðkennisuppskeru botnets skoða stöðugt almenning GitHub Events Firehose (api.github.com/events) og klónaðu nýlega ýttu skuldbindingar innan 1,5 til 4 sekúndna frá því git push klára. Það sem verra er, næstum allir hræddir verktaki gera nákvæmlega sömu banvænu mistökin: þeir eyða .env skrá á staðnum, bæta við .env til .gitignore, og ýttu á aðra skuldbindingu sem heitir "remove .env" eða "oops". ** Að ýta á annarri skuldbindingu sem eyðir .env felur ekkert**: leyndarmál textans er 100 prósent læsilegt að eilífu inni í diff fyrri skuldbindingarinnar (git log -p), og jafnvel þó þú þvingar (git push --force) yfir útibúið, skuldbindingin sem ekki er vísað til (dangling blob) er áfram aðgengilegt almenningi í gegnum beina GitHub vefslóð sína og skyndiminni Pull Request skoðanir þar til þær eru hreinsaðar sérstaklega. Ef lekið skilríki hefur þegar verið notað af árásarmönnum til að dreifa lausnarhugbúnaði, ræna DNS léninu þínu eða læsa skýleigjanda þínum, skaltu skoða fylgileiðbeiningar okkar á ransomware og malware svar, rænt lén, útrunnið DNS og yfirtaka vefsíðu, og Google Workspace eða Microsoft 365 sérsniðið lénsstjórnunarlokun. Ef skilríkisleki hefur áhrif á öryggi sjúklinga á sjúkrahúsi, líkamlegt iðnaðareftirlit eða innviði neyðarsendingar skaltu hringja í neyðarnúmerið þitt (911 í Bandaríkjunum og Kanada, 112 víðsvegar um Evrópusambandið, 999 í Bretlandi) eða skoðaðu alþjóðlega skrána okkar yfir neyðarnúmer.

Gerðu þetta núna¶

1. AFTALA, AFVIRKJA OG SNOÐU hverju einasta afhjúpuðu leyndarmáli á stjórnborði þjónustuveitunnar FYRST - á fyrstu 120 sekúndunum - áður en þú eyðir einni sekúndu í að keyra git skipanir: Þegar leyndarmál snertir opinbera GitHub, GitLab eða Bitbucket geymslu í jafnvel 3 sekúndur, meðhöndlaðu þann lykil sem varanlega brenndan og þegar í höndum sjálfvirkra árásarmanna. Ekkert magn af git reset --hard, git push --force, eða að eyða geymslunni getur eytt lykli úr gagnagrunni scraper botni sem þegar hefur hlaðið niður skuldbindingunni þinni í seinni #2. Skráðu þig inn á AWS IAM, Stripe, OpenAI, gagnagrunnstölvur eða GitHub SSH stillingar núna og Slökkva / Eyða / Rúlla lyklinum strax.
2. ** Endurskoðaðu skýjareikninga og endurskoðunarskrár (AWS CloudTrail, GCP Cloud Audit Logs, Stripe Logs) fyrir gluggann á milli þín git push og afturköllun lykla þíns**: Sjálfvirk dulritunarvélanotkun lekur AWS_ACCESS_KEY_ID (AKIA...) skilríki innan 30 til 90 sekúndna til að snúa upp hámarkskvóta GPU tilvik (p4d.24xlarge / g5.48xlarge) yfir öll falin AWS svæði (ap-east-1, me-south-1, af-south-1) og búðu til bakdyra IAM notendur eða Lambda viðvarandi krókar svo þeir haldist inni á AWS reikningnum þínum, jafnvel eftir að þú eyðir lyklinum sem leki.
3. ** ALDREI ýta á sekúndu "Delete .env" skuldbinda sig - í raun vélritun "delete secret" eða "remove password" í commit skilaboðum laðar að sér markvissa scraper bots**: Þúsundir ógn-leikara forskrifta spyrja sérstaklega GitHub Leita að commit skilaboðum sem innihalda "remove .env", "delete key", "oops", og "remove credentials", smelltu svo á eina skuldbindingu afturábak í sögunni til að stela lyklinum.
4. Skrifaðu alla Git geymslusöguna á staðnum með því að nota git filter-repo (eða BFG Repo-Cleaner) til að fjarlægja skrána eða fjarlægja lykilorðsstrenginn úr hverri sögulegri skuldbindingu, tré og merki: git filter-branch er opinberlega afskrifað af Git verkefninu; nota git filter-repo --invert-paths --path .env (til að nudda skrá úr öllum skuldbindingum) eða git filter-repo --replace-text expressions.txt (til að skipta út tilteknum lykilorðastrengjum fyrir ***REMOVED*** inni í kóðaskrám án þess að eyða þeim).
5. Þrýstu á allar greinar og merki (git push origin --force --all), OG hreinsa GitHub's server-side cached commit views (dangling commits): Hér er leyndarmálið sem flestir forritarar vita ekki: jafnvel eftir að þú hefur keyrt git filter-repo og git push --force, Netþjónar GitHub halda gamla commit SHA lifandi í skyndiminni þeirra (git cat-file), sem þýðir að allir sem tóku upp 40 stafa skuldbindingu SHA frá opinbera Events API geta samt skoðað github.com/user/repo/commit/<OLD_SHA>. Við útskýrum hér að neðan hvernig á að hreinsa tafarlaust hangandi commit skyndiminni í gegnum GitHub Support / API eða með því að eyða og endurskapa geymsluna.
6. Settu upp staðbundið pre-commit leynilegur skanni (gitleaks eða trufflehog) inni .git/hooks/pre-commit áður en þú skrifar aðra kóðalínu: 10 sekúndur gitleaks protect --staged pre-commit krókur skoðar hverja sviðsetta línu á staðnum á fartölvunni þinni og blokkum git commit áður en leyndarmál getur yfirgefið vélina þína.

Ákvörðunartré: tafarlaus innilokun, snúningur og hreinsun Git sögu¶

Framkvæma þetta verkflæði í ströngri tímaröð (Afturkalla FIRST -> Endurskoðunarþol SECOND -> Hreinsa Git sögu ÞRIÐJA):

flowchart TD
    Start["Leyndarmál ýtt til opinberrar endursölu (.env, AWS/GCP lykill, DB lykilorð, Stripe/OpenAI lykill eða einka SSH lykill)"] --> Step1["MÍNÚTA 0 TIL 2 (Forgangur #1): Afturkalla / rúlla öllum óljósum lyklum strax á stjórnborði veitenda"]

    Step1 --> SecretType{"Hvers konar skilríki var inni í skuldbindingunni?"}

    SecretType -->|"Cloud Infrastructure Key (AWS AKIA, GCP Service Account JSON, Azure SP)"| CloudAudit["MÍNÚTA 2 TIL 10: Athugaðu CloudTrail / athafnaskrár -> Lokaðu Rogue EC2/Compute tilvik á öllum svæðum -> Eyða óviðkomandi IAM notendum/hlutverkum/STS lotum"]

    SecretType -->|"URI / lykilorð gagnagrunns (Postgres, MySQL, MongoDB, Redis, Supabase)"| DBAudit["MÍNÚTA 2 TIL 10: Snúa DB notandalykilorði + drepa virkar tengingar (pg_terminate_backend) + Læsa öryggishóp eldveggs á hvítlista IP-tölu eingöngu"]

    SecretType -->|"API tákn eða SSH lykill (Stripe, OpenAI, GitHub PAT, Slack, Private SSH Key)"| TokenAudit["MÍNÚTA 2 TIL 10: Rúllaðu API lykli í mælaborði / Fjarlægðu opinberan SSH lykil af $HOME/.ssh/authorized_keys & GitHub stillingum -> Endurskoðun nýlegra forritaskila notkunarskráa"]

    CloudAudit --> RepoVisibility{"MÍNÚTA 10 TIL 20: Hvernig viltu hreinsa GitHub geymsluna?"}
    DBAudit --> RepoVisibility
    TokenAudit --> RepoVisibility

    RepoVisibility -->|"Hraðasta 100% skyndiminniþurrkun (ekkert mikilvægt vandamál/stjörnusögu að geyma)"| NukeRepo["1. Eyddu öllu geymslunni á GitHub stillingum. 2. Keyrðu git filter-repo Locally til að hreinsa sögu. 3. Búðu til ferska endurhverfu og ýttu hreina sögu (eyðir samstundis öllum Cached Commit SHAs)"]

    RepoVisibility -->|"Verður að varðveita núverandi Repo stjörnur, málefni, PR og gaffla"| RewriteRepo["1. Keyrðu git filter-repo (--invert-paths eða --replace-text). 2. Keyrðu git push --force --all & --tags. 3. Hafðu samband við GitHub Support / Support Portal til að hreinsa Dangling Commit SHA Cache"]

Áfangi 1: Mínúta 0 til 2 - Svindlari fyrir strax afturköllun eftir veitanda¶

Opnaðu ekki flugstöð til að berjast við git rebase meðan framleiðslulyklarnir þínir eru enn virkir. Smelltu beint á viðkomandi þjónustuaðila hér að neðan og drepðu skilríkin fyrst:

Áfangi 2: Mínúta 2 til 10 - Athugaðu hvort árásarmenn hafi þegar búið til bakdyr (AWS / skýjainnihald)¶

Ef þú lekur .env skráin innihélt AWS Access Key (AKIA...), Google Cloud Service Account JSON eða Azure Service Principal, að eyða lyklinum sem leki er aðeins hálf baráttan. Þú verður að staðfesta að sjálfvirkur láni hafi ekki notað þessar 90 sekúndur til að koma á þrautseigju inni á skýjareikningnum þínum:

6-punkta AWS réttarúttekt eftir leka¶

1. ** Athugaðu AWS CloudTrail -> Event history fyrir öll API símtöl sem lekið er Access Key ID**:
2. Opnaðu AWS CloudTrail stjórnborðið -> Atburðarsaga.
3. Breyttu uppflettivalmyndinni úr skrifvarinn í Access key ID og límdu lekið AKIA... strengur.
4. Horfðu á alla atburði sem skráðir eru frá því að þú hljóp git push. Leitaðu sérstaklega að: CreateUser, CreateAccessKey, AttachUserPolicy, CreateRole, AssumeRole, GetSessionToken, RunInstances (EC2), RequestSpotInstances, CreateFunction (Lambda), eða SendEmail (SES ruslpóstur).
5. ** Afturkalla alla virka tímabundna STS lotur sem sá notandi fæddi**:
6. Jafnvel eftir að þú eyðir AKIA... aðgangslykill, ef árásarmaðurinn hringdi sts:GetSessionToken áður en þú eyddir lyklinum, tímabundin ASIA... lotulykill er í gildi í allt að 36 klukkustundir.
7. Til að drepa alla virka tímabundið STS tákn fyrir þann IAM notanda strax, farðu í IAM -> Users -> [Leaked User] -> Permissions -> Add inline policy og smelltu Revoke sessions (sem fylgir skýrt Deny * stefnu fyrir hvaða tákn sem gefið er út hvar aws:TokenIssueTime er fyrr en núna.).
8. ** Athugaðu IAM -> Users og IAM -> Roles fyrir nýstofnaða bakdyrareikninga**:
9. Raða öllum IAM notendum eftir Sköpunartíma. Eyða öllum ókunnugum notendum (admin-backup, sys-monitor, support-bot) og staðfestu Trust relationships flipann á IAM hlutverkunum þínum til að ganga úr skugga um að árásarmaðurinn hafi ekki bætt við eigin ytri AWS reikningsauðkenni ("Principal": {"AWS": "arn:aws:iam::999999999999:root"}) sem traustur skólastjóri.
10. NotaAWS Resource Explorer** eða EC2 Global View til að athuga ÖLL 30+ AWS svæði fyrir falin dulmálsmenn**:
11. Árásarmenn hefja sjaldan dulritunartilvik í us-east-1 þar sem þú munt sjá þær á mælaborðinu þínu. Þess í stað hefja þeir p4d, g5, eða c6i.32xlarge tilvik í ap-southeast-3 (Jakarta), me-central-1 (UAE), il-central-1 (Tel Aviv), eða sa-east-1 (São Paulo).
12. Opið EC2 Console -> EC2 Global View (sem skannar hvert virkt svæði í einni töflu) og Ljúka öllum óviðkomandi tilvikum strax.
13. Opnaðu AWS stuðningsinnheimtutilfelli strax ef svikulir tilvik hlupu upp reikning:
14. Ef botni spratt upp $8,000 af EC2 GPU tilvikum áður en þú hættir þeim, ekki örvænta: þegar þú hefur tryggt reikninginn, eytt lyklinum, virkjað rót/IAM MFA, og fjarlægði lykilinn af GitHub, opnaðu AWS Account and Billing Support Case sem útskýrir fyrir slysni GitHub ýtuna og úrbótaskref þín. AWS veitir reglulega einu sinni eftirgjöf fyrir viðskiptavild innheimtuinneign fyrir óvart GitHub lykilleka þegar öryggisteymi þeirra hefur staðfest að geymslan sé hrein.

3. áfangi: Hvers vegna mistekst að eyða skránni í nýrri skuldbindingu - og hvernig á að endurskrifa sögu rétt með git filter-repo¶

1. Hvers vegna git rm .env && git commit -m "delete .env" er algjörlega ónýtt¶

Git er skráakerfi sem hægt er að nota eingöngu við innihald (Directed Acyclic Graph / DAG af skuldbindingum, trjám og kubbshlutum): - Segjum sem svo að Skuldu A1B2C3 bætt við .env (Blob 998877). - Segjum sem svo að þú hleypur 2 mínútum síðar git rm .env, bæta við .env til .gitignore, og ýttu á Commit D4E5F6. - Þó að einhver sem skoðar núverandi skráarlistann á GitHub heimasíðunni þinni mun ekki sjá .env, Skuldu A1B2C3 og Blob 998877 eru enn 100 prósent hluti af geymslunni. Allir sem reka git clone niðurhal Blob 998877, allir sem smella á flipann "Skuldir" á GitHub geta smellt A1B2C3 að lesa þitt .env skrá í einföldum texta og sjálfvirkum verkfærum (trufflehog git https://github.com/user/repo) skannaðu hverja einustu sögulegu skuldbindingu á 2 sekúndum.

2. Skref-fyrir-skref: Eyða skrá eða leynistreng yfir alla sögu með því að nota git filter-repo¶

Git verkefnið og GitHub mæla opinberlega með git-filter-repo (sem kemur í stað hægfara, villuhættu git filter-branch og er jafnvel sveigjanlegri en BFG Repo-Cleaner).

1. Setja upp git-filter-repo (Tekur 5 sekúndur):

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

2. Taktu öryggisafrit af staðbundinni geymslumöppu áður en þú endurskrifar ferilinn:

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

   (Athugið: Ef þú hefur þegar flutt gilt .env skrá út, vertu viss um að hreint afrit af .env er vistað í /tmp/.env.safe utan endurhverfunnar, vegna þess git filter-repo mun þurrka .env úr vinnuskránni þinni líka.)
3. Veldu valkost A (eyddu allri skráarslóð eins og .env eða id_rsa) EÐA Valkostur B (Lýta tiltekna leynistrengi inni í kóðaskrám):
4. ** Valkostur A: Fjarlægja algjörlega .env (eða config/secrets.json) frá öllum skuldbindingum sögunnar**:

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

   (Af hverju --invert-paths? Án --invert-paths, git filter-repo --path .env heldur AÐEINS .env og eyðir öllu öðru. Sameining --invert-paths --path .env segir Git að geyma allt NEMA .env yfir allar skuldbindingar, útibú og merkingar.)
5. Valkostur B: Haltu kóðaskránni (app.py / config.js), en skrúfaðu harðkóðaða leynistrenginn úr hverri sögulegu útgáfu: Búðu til textaskrá /tmp/secrets-to-scrub.txt sem inniheldur einn leynilegan streng (eða regex) í hverri línu:

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

   Hlaupa nú 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. Bæta við .env til .gitignore svo þú skuldbindur það ekki aftur eftir 5 mínútur:

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

7. Bættu GitHub fjarstýringunni við aftur (git filter-repo fjarlægir viljandi origin sem öryggisathugun) og þvingaðu allar greinar og merki:

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

Áfangi 4: The Hidden GitHub Cache Trap (Dangling Commits) og hvernig á að hreinsa það¶

Hér er mikilvægur réttar veruleiki skjalfestur í Opinberu skjölum GitHub (Fjarlægir viðkvæm gögn úr geymslu): - Þegar þú hleypur git filter-repo og git push origin --force --all, hver commit í geymslunni þinni fær glænýtt 40 stafa SHA-1 hass, og main greinarbendill færist í nýja hreina sögu. - HINSAMLEG, bakenda Git geymsluþjónn GitHub safnar EKKI rusli strax (git gc --prune=now) gamla, óvísaða skuldbindingu SHA. - Það þýðir að ef vélmenni árásaraðila tók upp gamla commit hassið (t.d., a1b2c3d4...) frá opinbera GitHub Events API þegar þú ýttir fyrst, þau geta samt opnað https://github.com/YOUR_USERNAME/YOUR_REPO/commit/a1b2c3d4... í hvaða vafra sem er og skoðaðu þína .env skrá jafnvel EFTIR að þú þvingaðir hreina sögu. Verra, ef leyndarmálið birtist í Pull Request, refs/pull/12/head heldur þeirri skuldbindingu til frambúðar.

Hvernig á að eyða skyndiminni / dinglandi skuldbindingum á netþjónum GitHub núna:¶

1. Aðferð 1 (Instant, 100% Complete Wipe - Best ef endurhverfan hefur engin mikilvæg vandamál/PRs/stjörnur):
2. Farðu í geymsluna þína á GitHub -> Settings -> Skrunaðu til botns (Danger Zone) -> Smelltu Delete this repository.
3. Búðu til glænýja geymslu með nákvæmlega sama nafni á GitHub og ýttu á hreint git filter-repo staðbundin geymsla til þess (git push -u origin main).
4. Að eyða geymslunni á GitHub brýtur samstundis allar opinberar vefskoðanir á gömlum skyndiminni commit SHA (404 Not Found).
5. Aðferð 2 (Varðveita stjörnur, málefni og PR - Notkun GitHub stuðning / skyndiminni hreinsun):
6. Fyrst skaltu grípa nákvæma 40 stafa SHA hassið af gamla commitinu sem innihélt leyndarmálið (athugaðu git reflog í varamöppunni þinni eða GitHub tilkynningapóstinum þínum).
7. Opna GitHub stuðningur (support.github.com) og notaðu sjálfvirka Fjarlægja viðkvæm gögn / Hreinsa skyndiminni commit skoðanir vinnuflæði (vísar til slóð geymslunnar og nákvæma dangling commit SHA(s)). Sjálfvirkt tól GitHub Support keyrir strax netþjónahlið git gc skyndiminnishreinsun sem ógildir skyndiminni vefskoðana og hluti sem ekki er vísað til án þess að eyða geymslunni þinni.
8. Látið alla liðsfélaga / samstarfsaðila vita um það git clone ferskt (ALDREI git pull):
9. Segðu hverjum forritara í teyminu þínu: "EKKI hlaupa git pull og ýttu." Ef vinnufélagi sem dró illa framið fyrr hleypur git pull (sem sameinar gamla óhreina söguna við nýju endurskrifuðu söguna) og ýtir á, þeir munu ýta á eytt .env skuldbinda sig strax aftur á GitHub. Sérhver þátttakandi verður annað hvort að eyða staðbundinni möppu og keyra ferska git clone, eða hlaupa git fetch origin && git reset --hard origin/main.

Áfangi 5: Koma í veg fyrir framtíðarleka að eilífu (Gitleaks Pre-Commit Hook & GitHub Push Protection)¶

Taktu þér 60 sekúndur núna til að gera það stærðfræðilega ómögulegt að fremja aftur leyndarmál óvart:

1. ** Virkja GitHub ókeypis "Push Protection for Yourself" yfir allan GitHub reikninginn þinn**:
2. Farðu á GitHub Settings (Persónustillingar þínar, efst til hægri) -> Code security and analysis (eða Code security).
3. Skrunaðu að Secret scanning -> Virkja Push protection for yourself.
4. Með kveikt á þessu, hvenær sem þú hleypur git push frá hvaða tölvu sem er í ** hvaða** sem er opinbera eða einkageymsla, þjónn GitHub skoðar pakkaskrána þína áður en tekur við ýtunni: ef hún finnur AWS lykil, OpenAI lykil, Stripe lykil, Private SSH lykil eða Slack token, GitHub hafnar git push beint í flugstöðinni þinni áður en skuldbindingin fer í loftið.
5. Setja upp gitleaks sem heimamaður pre-commit krækja í fartölvuna þína:

   # 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
   

Svæðisbundin neyðarnúmer og samskiptareglur stofnunarinnar¶

Ef ýtt á GitHub skilríki fyrir slysni leiðir til óviðkomandi innrásar í eftirlitsskyld persónuupplýsingar (PII / PHI), heilbrigðiskerfi eða innviðir stjórnvalda, fylgja lögboðnum samskiptareglum um tilkynningar um brot:

• Bandaríkin og Kanada:
• Lífsöryggi í neyðartilvikum / truflun á mikilvægum innviðum: Hringdu 911 ef innviðabrot hefur áhrif á starfsemi sjúkrahúsa eða líkamlegt öryggiseftirlit.
• Stofnun netöryggis og innviðaöryggis (CISA) & FBI (IC3): Ef árásarmenn notuðu leka skýjalykla til að síast út úr gögnum eða dreifa fjárkúgun spilliforritum, tilkynntu til CISA (1-844-Say-CISA / cisa.gov/report) og FBI Internet Crime Complaint Center (ic3.gov).
• Tilkynning um gagnabrot frá SEC, FTC og ríkissaksóknara: Ef CloudTrail / gagnagrunnsaðgangsskrár sýna að óviðkomandi IP-tala hafi fengið aðgang að persónulegum upplýsingum viðskiptavina (PII) eða heilsufarsskrár (HIPAA ePHI) Áður en lykillinn sem lekið var var afturkallaður skaltu tafarlaust hafa samband við lögfræðing varðandi tilkynningar um gagnabrot ríkisins og alríkis HHS OCR / FTC öryggisreglur tilkynningar.
• Canadian Center for Cyber Security: Hringdu í 1-833-CYBER-88 (1-833-292-3788) eða tilkynna persónuverndarbrot skv PIPEDA til skrifstofu persónuverndarfulltrúa Kanada (OPC).
• Bretland:
• Neyðarþjónusta: Hringdu í 999 (eða 101 / Aðgerðarsvik 0300 123 2040 og National netöryggismiðstöðin / NCSC kl ncsc.gov.uk).
• ** Embætti upplýsingafulltrúa (ICO - 72 stunda GDPR gluggi í Bretlandi)**: Ef skilríkjum sem lekið var leyfði óviðkomandi aðgang að persónuupplýsingum íbúa í Bretlandi, krefst Grein 33 í GDPR í Bretlandi tilkynningarskylda persónuupplýsingabrot til ICO (0303 123 1113) innan 72 klukkustunda frá því að vitað var um brotið.
• Evrópusambandið:
• Neyðarþjónusta: Hringdu í 112 í öllum aðildarríkjum ESB.
• GDPR grein 33 & NIS2 tilskipun atvikatilkynninga: Stofnanir sem falla undir EU GDPR verða að meta hvort persónuskilríkisáhætta hafi leitt til brots á trúnaði persónuupplýsinga (72 klst. tilkynning til innlendrar Persónuverndar / DPA), en nauðsynlegar/mikilvægar aðilar undir ESB NIS2 Tilskipun stendur frammi fyrir 24 klukkustunda viðvörunarfresti til landsmanna sinna CSIRT (BSI í Þýskalandi, ANSSI í Frakklandi, ACN á Ítalíu) vegna mikilvægra netatvika.
• Ástralía og Nýja Sjáland:
• Neyðarþjónusta: Hringdu í 000 í Ástralíu eða 111 á Nýja Sjálandi.
• Ástralska netöryggismiðstöðin (ACSC) & tilkynningaskyld gagnabrot (OAIC): Hringja 1300 CYBER1 (1300 292 371) fyrir viðbrögð við atvikum og meta tilkynningarskyldu samkvæmt skrifstofu ástralska upplýsingafulltrúans (OAIC) Tilkynningarskyld gagnabrot (NDB) kerfi eða Nýja Sjálands persónuverndarlög 2020 (Privacy Commissioner).
• Indland og Asíu-Kyrrahaf:
• Neyðarþjónusta: Hringdu í 112 á Indlandi (eða 1930 fyrir netglæpi).
• CERT-In skyldubundin 6-klukkutíma tilkynningartilskipun (Indland): Undir indverskt tölvuneyðarviðbragðsteymi (CERT-In) leiðarlýsing (No. 20(3)/2022-CERT-In), skal tilkynna óviðkomandi aðgang að skýja-/upplýsingakerfum eða gagnaleka sem hefur áhrif á stofnanir á Indlandi til incident@cert-in.org.in innan 6 klukkustunda frá greiningu.

Algengar spurningar¶

Ég eyddi .env skrá og ýtti á nýjan commit 30 sekúndum eftir mistök mín - þarf ég samt að snúa API lyklum mínum og gagnagrunnslykilorðum?¶

Já, 100 prósent - snúðu hverjum einasta takka strax án undantekninga. Akademískar netöryggisrannsóknir og fjarmælingar frá GitHub Secret Scanning staðfesta að sjálfvirkir vélmenni til að safna skilríkjum fylgjast með opinberum GitHub Events straumi (api.github.com/events) í rauntíma og hlaðið niður nýlegum skuldbindingum innan 1,5 til 5 sekúndur. Það sem verra er, að ýta á annað commit sem eyðir .env skilur allan textann eftir .env skrá sem situr varanlega inni í sögunni í fyrstu commit - og margir vélmenni leita sérstaklega að commits sem eyða .env skrár. Þegar leyndarmáli hefur verið ýtt í opinbera geymslu í jafnvel eina sekúndu, er því hætt að eilífu; afturkalla og snúa skilríkjunum á mælaborði veitunnar er það eina sem verndar þig.

Hvað ef geymslan væri PRIVATE GitHub endurhverf þegar ég framdi .env skrá, og ég vil bara hreinsa hana upp áður en endurhverfið er opinbert í næstu viku?¶

Ef geymslan væri 100 prósent Einkamál allan tímann (og engin ótraust CI/CD forrit frá þriðja aðila höfðu aðgang), hafa skrapbottar á opinberu GitHub Events API ekki séð leyndarmál þitt enn. Hins vegar skaltu EKKI einfaldlega eyða `.env` í nýrri skuldbindingu og flettu síðan endurhverfunni úr Private í Public. Um leið og þú snýrð einkageymslu yfir í Public, þá er það allt sögulegt skuldbindingargraf verður opinbert - og vélmenni skanna strax allar gamlar skuldbindingar í nýlega opinbera endurhverfunni. Áður en einkaafgreiðsla er opinber, annað hvort: (1) Hlaupa git filter-repo --invert-paths --path .env til að fjarlægja skrána frá öllum sögulegum skuldbindingum (og snúa lyklunum samt til að fá bestu æfingu), EÐA (2) Afritaðu hreinu núverandi skrár í glænýja möppu, keyrðu git init fyrir hreina upphafssögu með 1 skuldbindingu og birtu þá nýju geymslu.

Hvers vegna hengdi AWS sjálfkrafa við stefnu sem heitir AWSCompromisedKeyQuarantineV2 til IAM notandans og hvers vegna fæ ég enn reikning?¶

Vegna þess að AWS er í beinu samstarfi við GitHub Secret Scanning, hvenær sem er AKIA... lykill birtist í opinberri GitHub skuldbindingu, sjálfvirkt öryggiskerfi AWS skynjar það innan nokkurra mínútna, opnar stuðningsmiða og hengir við stýrðu stefnuna AWSCompromisedKeyQuarantineV2 (eða V3) til þess IAM notanda. Sú sóttkvíarstefna hindrar augljósar hættulegar aðgerðir eins og að hefja nýjar ec2:RunInstances eða eyða S3 fötum - en það stöðvar EKKI EC2-tilvik sem árásarmaðurinn hefur þegar sett af stað á fyrstu 60 sekúndunum áður en stefnan var tengd, né eyðir IAM-notendum bakdyra eða tímabundnum STS lotur sem árásarmaðurinn hefur þegar búið til. Þú verður samt að eyða lyklinum sem leki handvirkt, athugaðu EC2 Global View á öllum svæðum til að stöðva fantur tilvik og athuga CloudTrail fyrir óheimilar IAM breytingar.

Hver er munurinn á milli git filter-repo og BFG Repo-Cleaner, og hvers vegna ætti ég ekki að nota git filter-branch?¶

git filter-útibú er gamalt gamalt skeljaforskrift sem er innbyggt í fyrstu útgáfur af Git sem er afar hægt á stórum geymslum, auðvelt að misstilla (skilið öryggisafrit eftir í refs/original/ sem enn innihalda leyndarmál þín.), og prentar nú opinbera afskriftaviðvörun frá Git sem segir þér að nota það ekki. Bæði git-filter-repo (skrifað í Python og opinberlega samþykkt af kjarna Git viðhaldsaðilum og GitHub) og BFG Repo-Cleaner (skrifað í Java/Scala) keyrðu 10x til 100x hraðar og endurskrifaðu hreint öll skuldbindingar, tré og merki. git-filter-repo er almennt valinn í dag vegna þess að það breytir jafnvel núverandi útskráningu þinni (`HEAD`) án þess að krefjast sérstakrar bráðabirgðasamþykktar fyrst.

Hvernig getur einhver samt skoðað eytt skuldbindinguna mína á GitHub eftir að ég hljóp git filter-repo og git push --force?¶

Í Git, `git push --force` uppfærir aðeins grein tilvísunarbendill (`refs/heads/main`) að benda á nýju endurskrifuðu skuldbindingarkeðjuna þína; það gerir það ekki eyða strax gömlu ótilvísuðu ("dangling") commit hlutunum sem eru geymdir á bakendaþjónum GitHub. Ef láni skráði 40 stafa SHA kjötkássa upprunalega skuldbindingarinnar þinnar þegar það snerti opinbera Events API, flettirðu beint til https://github.com/owner/repo/commit/<40-char-SHA> mun samt hlaða þeim munaðarlausu skuldbindingu úr skyndiminni GitHub þar til sorpsöfnunin er í gangi. Að kjarnorka þá skyndiminni sýn strax, annaðhvort eyddu geymslunni á GitHub og endurskapaðu það úr hreinu staðbundnu geymslunni þínu, eða sendu dangling skuldbinda SHA til GitHub stuðningur (`support.github.com`) fyrir tafarlausa hreinsun skyndiminni á netþjóni.

Hvað ef einhver hefði þegar smellt á "Fork" á opinberu geymslunni minni áður en ég hljóp git filter-repo?¶

Þetta er ástæðan Skref 1 er alltaf að afturkalla og snúa skilríkjunum á mælaborði veitunnar: hlaupandi git filter-repo og þvinga til eigin geymslu endurskrifar EKKI skuldbindingar inni í sjálfstæðum Fork einhvers annars af geymslunni þinni (nema þú eyðir allri móðurgeymslunni þinni og hafir samband við GitHub Support varðandi viðkvæm gögn í gafflum). Þegar þú hefur afturkallað AWS/API lyklana og snúið lykilorðum gagnagrunnsins, hvaða afrit af gömlu .env skrá sem situr í gagnagrunni þriðja aðila gaffals eða botnagagnagrunns verður dauður, gagnslaus strengur af stöfum sem hafa ekki lengur aðgang að innviðum þínum.

Tengdir leiðsögumenn¶

• Ransomware og malware: tafarlaus innilokun og endurheimt
• Ránun léns, útrunnið DNS og yfirtaka vefsíðu
• Google Workspace eða Microsoft 365 sérsniðið lénsstjórnendalokun og DNS-björgun
• Vefveiðar og reikningar í hættu: neyðarlokun
• Óviljandi rm -rf eða Shift-Delete á Linux, macOS eða Windows: tafarlaus skrifvarinn endurtenging
• Neyðarnúmer eftir löndum

Heimildir og opinberar leiðbeiningar¶

• GitHub opinber öryggisskjöl (docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository): Fjarlægir viðkvæm gögn úr geymslu (git filter-repo, BFG Repo-Cleaner, Dangling Commit Cache Purging og Secret Scanning Push Protection).
• Amazon vefþjónusta (AWS) Leiðbeiningar um viðbrögð við öryggisatvikum (docs.aws.amazon.com/security/): Að bregðast við óvarnum AWS IAM aðgangslyklum (AWSCompromisedKeyQuarantineV2, Afturköllun tímabundið STS Fundir í gegnum aws:TokenIssueTime, og CloudTrail Réttarendurskoðun).
• National Institute of Standards and Technology (NIST) (Bandaríkin): Sérstök rit 800-61 Rev. 2: Leiðbeiningar um meðferð tölvuöryggisatvika & SP 800-57: Tilmæli um lykilstjórnun (afturköllun skilríkis í hættu og dulritunarsnúningur).
• Opna öryggisverkefni fyrir vefforrit (OWASP): Svindlari fyrir leyndarmálstjórnun (koma í veg fyrir harðkóðaða skilríki, leynileg skönnun fyrir skuldbindingu með Gitleaks/TruffleHog, og Ephemeral Runtime Secret Injection).
• Stofnun netöryggis og innviðaöryggis (CISA) (Bandaríkin): Cloud Security Technical Reference Architecture and Compromised Credential Remediation Playbook.