Ustekabean bultzatuta .env GitHub Repo publiko baterako sekretuak edo AWS gakoak: zergatik fitxategia ezabatzeak ez du ezkutatzen¶

Korrika egin eta hamar segundora konturatzea git push origin main (edo biltegi pribatu bat irauli Public) zure konpromisoak testu arrunta zuela .env fitxategia, AWS bat AKIA... Sarbide-gakoa eta gako sekretua, OpenAI/Anthropic API gakoa, Stripe bat sk_live_... produkzio-tokena, PostgreSQL/MongoDB datu-basearen URI bat pasahitzarekin edo zifratu gabeko bat $HOME/.ssh/id_ed25519 gako pribatua bost alarmako zibersegurtasun larrialdi bat da. Kredentzialak biltzeko botnet automatizatuek etengabe galdetzen dute publikoa GitHub Events Firehose (api.github.com/events) eta klonatu bultzatu berri diren konpromezuak zuretik 1,5 eta 4 segundoko epean. git push osatuz. Okerrago, izututa dauden garatzaile guztiek akats larri bera egiten dute: ezabatzen dute .env fitxategi lokalean, gehitu .env to .gitignore, eta bultzatu izenburuko bigarren konpromezu bat "remove .env" edo "oops". ** Ezabatzen duen bigarren konpromezu bat bultzatzea .env ez du ezer ezkutatzen**: testu arrunteko sekretua ehuneko 100ean irakurgarri geratzen da betirako aurreko konpromisoaren desberdintasunaren barruan (git log -p), eta indarrez bultzatzen baduzu ere (git push --force) adarraren gainean, erreferentziarik gabeko konpromisoa (dangling blob) publikoki eskuragarri izaten jarraitzen du GitHub URL zuzeneko eta cacheko Pull Request ikuspegien bidez esplizituki garbitu arte. Filtratutako kredentziala erasotzaileek dagoeneko erabili badute ransomwarea zabaltzeko, zure DNS domeinua bahitzeko edo zure hodeiko maizterrak blokeatzeko, kontsultatu gure gidaliburuak. ransomware eta malware erantzuna, domeinu-izenen bahiketa, iraungitako DNS eta webgunearen jabegoa, eta Google Workspace edo Microsoft 365 domeinu pertsonalizatuko administratzaileen blokeoa. Kredentzial-isuri batek ospitaleko pazientearen segurtasunari, industria-kontrol fisikoei edo larrialdietarako bidalketa-azpiegiturei eragiten badie, deitu zure tokiko larrialdi-zenbakira (911 Estatu Batuetan eta Kanadan, 112 Europar Batasun osoan, 999 Erresuma Batuan) edo begiratu gure nazioarteko direktorioa larrialdi zenbakiak.

Egin hau orain¶

1. ** ERREBOKATU, DESAKTIBATU ETA BIRATIKATU hornitzailearen kontsolan agerian dauden sekretu guztiak LEHENENGO - lehen 120 segundoetan - segundo bakar bat korrika alferrik galdu baino lehen git komandoak**: sekretu batek GitHub, GitLab edo Bitbucket biltegi publiko bat ukitzen duenean 3 segundoz ere, ** tratatu gako hori behin betiko erreta eta erasotzaile automatizatuen esku dagoela**. Zenbatekorik ez git reset --hard, git push --force, edo biltegia ezabatzeak gako bat ezabatu dezake dagoeneko zure konpromezua bigarren #2-n deskargatu duen scraper bot baten datu-basetik. Hasi saioa AWS IAM, Stripe, OpenAI, datu-base kontsoletan edo GitHub SSH ezarpenetan oraintxe bertan eta Desaktibatu / Ezabatu / Biratu giltza berehala.
2. ** Ikuskatu zure hodeiko fakturazio eta auditoretza erregistroak (AWS CloudTrail, GCP Cloud Audit Logs, Stripe Logs) zure arteko leihorako git push eta zure gakoa ezeztatzea**: kriptominazio automatikoko bot-ek filtratutakoak erabiltzen dituzte AWS_ACCESS_KEY_ID (AKIA...) kredentzialak 30 eta 90 segundotan gehienez kuota GPU instantziak abiarazteko (p4d.24xlarge / g5.48xlarge) ezkutuko AWS eskualde guztietan (ap-east-1, me-south-1, af-south-1) eta sortu backdoor IAM erabiltzaileak edo Lambda iraunkortasun-kakoak, zure AWS kontuaren barruan gera daitezen, filtratutako gakoa ezabatu ondoren ere.
3. Inoiz ez sakatu segundo bat "Delete .env" konprometitu - hain zuzen ere, idazten "delete secret" edo "remove password" konpromiso-mezu batean zuzendutako scraper bot-ak erakartzen ditu: Mehatxu-aktoreen script-ek GitHub-en bilaketak egiten dituzte konprometitutako mezuak. "remove .env", "delete key", "oops", eta "remove credentials", eta, ondoren, egin klik historian atzera egin den bat gakoa lapurtzeko.
4. ** Berridatzi Git biltegiaren historia osoa lokalean erabiliz git filter-repo (edo BFG Repo-Cleaner) fitxategia ezabatzeko edo pasahitz-katea konpromezu, zuhaitz eta etiketa historiko guztietatik kentzeko**: git filter-branch Git proiektuak ofizialki zaharkituta dago; erabili git filter-repo --invert-paths --path .env (konpromiso guztietatik fitxategi bat nukeatzeko) edo git filter-repo --replace-text expressions.txt (Pasahitz kate espezifikoak ordezkatzeko ***REMOVED*** kode fitxategien barruan fitxategiak ezabatu gabe).
5. Bultsatu behartu adar eta etiketa guztiak (git push origin --force --all), ETA garbitu GitHub-en zerbitzariaren cacheko konpromezu-ikuspegiak (dangling commits): Hona hemen garatzaile gehienek ezagutzen ez duten sekretua: exekutatu ondoren ere git filter-repo eta git push --force, GitHub-en zerbitzariek konpromezu SHA zaharra bizirik mantentzen dute beren objektuen cachean (git cat-file), hau da, gertaeren API publikotik 40 karaktereko konpromezuaren SHA grabatu duen edonork ikus dezake oraindik github.com/user/repo/commit/<OLD_SHA>. Jarraian, GitHub euskarria / API bidez edo biltegia ezabatu eta birsortuz berehala garbitu zintzilik dauden konpromezuen cacheak nola garbitu azaltzen dugu.
6. ** Instalatu lokal bat pre-commit eskaner sekretua (gitleaks edo trufflehog) barruan .git/hooks/pre-commit beste kode lerro bat idatzi aurretik**: 10 segundo gitleaks protect --staged pre-commit hook zure ordenagailu eramangarrian eta blokeetan mailakako lerro guztiak ikuskatzen ditu lokalean git commit sekretu batek zure makina utzi aurretik.

Erabakien zuhaitza: berehalako eustea, errotazioa eta Git historiako garbiketa¶

Exekutatu lan-fluxu hau ordena kronologiko zorrotzean (Ezeztatu LEHENENGOA -> Ikuskaritza Iraunkortasuna BIGARREN -> Garbitu Git Historia HIRUGARRENA):

flowchart TD
    Start["Repo publikora bidalitako sekretua (.env, AWS/GCP gakoa, DB pasahitza, Stripe/OpenAI gakoa edo SSH gako pribatua)"] --> Step1["0-2 MINUTUAK (LEHENTASUNA # 1): Errebokatu / Biratu agerian dauden gako guztiak hornitzailearen kontsolan berehala"]

    Step1 --> SecretType{"Zer kredentzial mota zegoen konpromisoaren barruan?"}

    SecretType -->|"Hodeiko azpiegituraren gakoa (AWS AKIA, GCP zerbitzu-kontua JSON, Azure SP)"| CloudAudit["2-10 MINUTUAK: Egiaztatu CloudTrail/Aktibitateen Erregistroak -> Amaitu Rogue EC2/Compute Instantziak eskualde guztietan -> Ezabatu baimendu gabeko IAM erabiltzaileak/Rolak/STS saioak"]

    SecretType -->|"Datu-basearen URI / Pasahitza (Postgres, MySQL, MongoDB, Redis, Supabase)"| DBAudit["2-10 MINUTUAK: Biratu DB Erabiltzailearen pasahitza + Kill Active Connections (pg_terminate_backend) + Blokeatu Firewall Security Group zerrenda zuriko IPetarako soilik"]

    SecretType -->|"API Token edo SSH gakoa (Stripe, OpenAI, GitHub PAT, Slack, SSH gako pribatua)"| TokenAudit["MINUTUAREN 2tik 10ra: Iretzi API gakoa Arbelean / Kendu SSH gako publikoa $HOME/.ssh/authorized_keys eta GitHub ezarpenetatik -> Ikuskatu azken APIaren erabilera-erregistroak"]

    CloudAudit --> RepoVisibility{"10. MINUTUtik 20ra: nola garbitu nahi duzu GitHub biltegia?"}
    DBAudit --> RepoVisibility
    TokenAudit --> RepoVisibility

    RepoVisibility -->|"% 100eko cache garbiketa bizkorrena (ez dago gorde beharreko arazo kritikorik/izar-historiarik)"| NukeRepo["1. Ezabatu Biltegi osoa GitHub ezarpenetan. 2. Exekutatu git filter-repo Lokalki Garbitu Historiarako. 3. Sortu Repo freskoa eta Garbitu historiaren bultzada (berehala suntsitzen ditu cachean gordetako konpromiso-SH guztiak)"]

    RepoVisibility -->|"Dauden repo izarrak, arazoak, PRak eta sardexkak gorde behar ditu"| RewriteRepo["1. Exekutatu git filter-repo (--invert-paths edo --replace-text). 2. Exekutatu git push --force --all & --tags. 3. Jarri harremanetan GitHub-en laguntza / laguntza-ataria Dangling Commit SHA cachea garbitzeko"]

1. fasea: 0tik 2rako minutua - Hornitzailearen berehalako errebokatze-orria¶

Ez ireki terminal bat borrokatzeko git rebase produkzio-gakoak aktibo dauden bitartean. Egin klik zuzenean beheko kaltetutako hornitzailean eta hil lehenik kredentziala:

2. fasea: 2tik 10era - Erasotzaileek atzeko ate bat sortu duten ala ez egiaztatzea (AWS / Hodeiaren edukiera)¶

Zure filtrazioa bada .env fitxategiak AWS Sarbide gako bat zuen (AKIA...), Google Cloud Service Account JSON edo Azure Service Principal, filtratutako gakoa ezabatzea borrokaren erdia baino ez da. Egiaztatu behar duzu robot automatizatu batek ez zituela erabili 90 segundo horiek zure hodeiko kontuaren barruan iraunkortasuna ezartzeko:

6 puntuko AWS Leak osteko Auzitegiko Ikuskaritza¶

1. Egiaztatu AWS CloudTrail -> Event history Filtratuak egindako API dei guztietarako Access Key ID:
2. Ireki AWS CloudTrail Console -> Gertaeren historia.
3. Aldatu goitibeherako bilaketa Irakurtzeko soilik izatetik Access key ID eta itsatsi filtratutakoa AKIA... katea.
4. Begiratu exekutatu zaren minututik erregistratutako gertaera guztiak git push. Zehazki bilatu: CreateUser, CreateAccessKey, AttachUserPolicy, CreateRole, AssumeRole, GetSessionToken, RunInstances (EC2), RequestSpotInstances, CreateFunction (Lambda), edo SendEmail (SES spam).
5. Aldi baterako aktiboa ezeztatu STS Erabiltzaile horrek sortutako saioak:
6. bat ezabatu ondoren ere AKIA... sarbide-gakoa, erasotzaileak deitu badu sts:GetSessionToken gakoa ezabatu baino lehen, haien aldi baterako ASIA... saio-tokenak 36 orduz iraungo du.
7. Aldi baterako aktibo guztiak hiltzeko STS IAM erabiltzaile horrentzako tokenak berehala, joan ** ataleraIAM -> Users -> [Leaked User] -> Permissions -> Add inline policy** eta egin klik Revoke sessions (esplizitu bat eransten duena Deny * non jaulkitako edozein token politika aws:TokenIssueTime oraintxe baino lehenagokoa da.).
8. Egiaztatu IAM -> Users eta IAM -> Roles sortu berri diren atzeko atzeko kontuetarako:
9. Ordenatu IAM erabiltzaile guztiak Sorkuntza-orduaren arabera. Ezabatu erabiltzaile ezezagun bat (admin-backup, sys-monitor, support-bot) eta egiaztatu Trust relationships zure IAM Rolen fitxan, erasotzaileak ez duela bere kanpoko AWS kontu ID propioa gehitu ziurtatzeko ("Principal": {"AWS": "arn:aws:iam::999999999999:root"}) konfiantzazko nagusi gisa.
10. ErabiliAWS Resource Explorer** edo EC2 Global View 30+ AWS eskualde GUZTIAK egiaztatzeko ezkutuko kriptominatzaileen bila**:
11. Erasotzaileek oso gutxitan abiarazten dituzte kriptografia-minazio-instantziak us-east-1 non ikusiko dituzu zure aginte-panelean. Horren ordez, martxan jartzen dute p4d, g5, edo c6i.32xlarge kasuak -nap-southeast-3 (Jakarta),me-central-1 (EAU), il-central-1 (Tel Aviv), edo sa-east-1 (São Paulo).
12. Ireki EC2 Console -> EC2 Global View (gaitutako eskualde guztiak taula bakarrean aztertzen dituena) eta Amaitu baimenik gabeko instantzia guztiak berehala.
13. Ireki AWS Support fakturazio kasu bat berehala instantzia maltzurren batek faktura bat sortzen badu:
14. Bot bat piztuko balitz $8,000 EC2 GPU instantzia horiek amaitu baino lehen, ez zaitez izutu: kontua ziurtatu ondoren, gakoa ezabatu, root/IAM gaituta MFA, eta GitHub-etik giltza kendu, ireki AWS kontua eta fakturaziorako laguntza kasua GitHub ustekabeko bultzada eta zure konponketa-urratsak azalduz. AWS-k ohiko borondate oneko fakturaziorako barkamen-kreditu bat ematen du ustekabean GitHub gakoen filtrazioengatik, segurtasun-taldeak biltegia garbi dagoela egiaztatzen duenean.

3. fasea: zergatik huts egiten duen fitxategia ezabatzeak konpromiso berri batean - eta nola behar bezala berridatzi historiarekin git filter-repo¶

1. Zergatik git rm .env && git commit -m "delete .env" guztiz alferrikakoa da¶

Git eranskinak soilik edukia helbideratu daitekeen fitxategi-sistema da (Directed Acyclic Graph / DAG konpromisoen, zuhaitzen eta blob objektuen artean): - Demagun Konprometitu A1B2C3 gehitu .env (Blob 998877). - Demagun 2 minutu geroago korrika egiten duzula git rm .env, gehitu .env to .gitignore, eta bultzatu Konprometitu D4E5F6. - Norbaitek zure GitHub-eko orri nagusian uneko fitxategien zerrenda arakatzen duen bitartean ez du ikusiko .env, Konprometitu A1B2C3 eta Blob 998877 biltegiaren ehuneko 100 dira oraindik. Exekutatzen duen edonor git clone deskargak Blob 998877, GitHub-eko "Konpromisoak" fitxan klik egiten duen edonork egin dezake klik A1B2C3 zure irakurtzeko .env fitxategia testu arruntean eta tresna automatizatuetan (trufflehog git https://github.com/user/repo) eskaneatu konpromezu historiko bakoitza 2 segundotan.

2. Urratsez urrats: Fitxategi edo kate sekretu bat ezabatzea Historia GUZTIAN erabiliz git filter-repo¶

Git proiektua eta GitHub-ek ofizialki gomendatzen dute git-filter-repo (motela eta akatsetarako joera duena ordezkatzen duena git filter-branch eta are malguagoa da BFG Repo-Cleaner).

1. ** Instalatu git-filter-repo** (5 segundo behar dira):

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

2. Egin historia berridatzi aurretik tokiko biltegiaren karpetaren segurtasun kopia bat:

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

   (Oharra: dagoeneko aldatu baduzu zure baliozkoa .env fitxategia atera, ziurtatu kopia garbi bat duzula .env bertan gordetzen da /tmp/.env.safe repotik kanpo, zeren git filter-repo garbituko du .env zure laneko direktoriotik ere.)
3. Aukeratu A aukera (Ezabatu fitxategi-bide osoa bezala .env edo id_rsa) EDO B aukera (Redact sekretu espezifikoak kode fitxategien barruan):
4. A aukera: erabat kendu .env (edo config/secrets.json) historiako konpromiso guztietatik:

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

   (Zergatik --invert-paths? gabe --invert-paths, git filter-repo --path .env BAKARRIK mantentzen du .env eta gainerako guztia ezabatzen du. Konbinatuz --invert-paths --path .env Git-i esaten dio dena IZAN IZAN dezala .env konpromiso, adar eta etiketa guztietan.)
5. B aukera: gorde kode fitxategia (app.py / config.js), baina kendu gogor kodetutako kate sekretua bertsio historiko guztietan: Sortu testu-fitxategi bat /tmp/secrets-to-scrub.txt lerro bakoitzeko kate sekretu bat (edo regex) duena:

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

   Orain korrika 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. ** Gehitu .env to .gitignore beraz, hemendik 5 minutura ez duzu berriro konpromisoa hartu**:

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

7. Gehitu berriro GitHub urruneko urruneko (git filter-repo nahita kentzen du origin segurtasun egiaztapen gisa) eta behartu behartu adar eta etiketa guztiak:

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

4. fasea: Ezkutuko GitHub cache-tranpa (Dangling Commits) eta Nola garbitu¶

Hona hemen GitHub-en Dokumentu Ofizialetan dokumentatutako errealitate forentse kritikoa (Datu sentikorrak biltegi batetik kentzea): - Korrika egiten duzunean git filter-repo eta git push origin --force --all, zure biltegiko konpromiso bakoitzak 40 karaktereko SHA-1 hash berri-berri bat jasotzen du, eta zure main adar erakuslea historia garbi berrira mugitzen da. - Hala ere, GitHub-en backend Git biltegiratze zerbitzariak EZ du berehala zabor-biltzen (git gc --prune=now) erreferentziarik gabeko SHA konpromiso zaharra. - Horrek esan nahi du erasotzaile baten bot-ak commit hash zaharra grabatu badu (adibidez, a1b2c3d4...) GitHub Events API publikotik bultzatu zenuenean, oraindik ireki daitezke https://github.com/YOUR_USERNAME/YOUR_REPO/commit/a1b2c3d4... edozein web arakatzailetan eta ikusi zure .env fitxategia garbiketa-historia behartu ONDOREN ere. Okerrago, sekretua Pull Request baten barruan agertzen bada, refs/pull/12/head konpromiso hori betirako eskura mantentzen du.

Nola suntsitu cachean/zintzilik dauden konpromisoak GitHub-en zerbitzarietan oraintxe bertan:¶

1. ** 1. metodoa (berehala, % 100 osoa garbitu - Hobe errepo-k Arazo/PR/Izar larririk ez badu)**:
2. Joan zure biltegira GitHub-en -> Settings -> Joan behealdera (Danger Zone) -> Egin klik Delete this repository.
3. Sortu biltegi berri bat GitHub-en izen bera duen eta garbitu git filter-repo tokiko biltegia (git push -u origin main).
4. GitHub-en biltegia ezabatzeak berehala apurtzen ditu cachean gordetako SHA zaharren web-ikuspegi publiko guztiak (404 Not Found).
5. 2. Metodoa (Izarrak, Arazoak eta PRak gordetzea - GitHub euskarria / Cache Purge erabiliz):
6. Lehenik eta behin, hartu sekretua zuen konpromiso zaharraren 40 karaktereko SHA hash zehatza (ikusi git reflog babeskopia karpetan edo GitHub jakinarazpen-mezu elektronikoetan).
7. Ireki GitHub euskarria (support.github.com) eta erabili Kendu datu sentikorrak / Garbitu cacheko konpromezu-ikuspegiak lan-fluxua (biltegiaren URLa eta zintzilikatutako konpromiso SHA(k) zehatza erreferentzia eginez). GitHub Support-en tresna automatizatuak zerbitzariaren aldean berehala exekutatzen du git gc cacheko web-ikuspegiak eta erreferentziarik gabeko objektuak baliogabetzen dituen cache garbiketa, zure biltegia ezabatu gabe.
8. ** Jakinarazi taldekide / kolaboratzaile guztiei git clone freskoa (inoiz ez git pull)***:
9. Esan zure taldeko garatzaile guztiei: "EZ exekutatu git pull eta bultzatu." Lehengo konpromiso txarra atera duen lankide batek korrika egiten badu git pull (historia zikin zaharra eta berridatzitako historia berriarekin batzen dituena) eta bultzatzen du, ** ezabatutakoa bultzatuko dute .env konprometitu berriro GitHub-era.** Kolaboratzaile bakoitzak bere karpeta lokala ezabatu eta berri bat exekutatu behar du git clone, edo korrika git fetch origin && git reset --hard origin/main.

5. Fasea: Etorkizuneko ihesak betiko saihestea (Gitleaks Konpromisoaren aurreko Hook eta GitHub Push Babesa)¶

Hartu 60 segundo oraintxe bertan sekretu bat ustekabean berriro egitea matematikoki ezinezkoa izan dadin:

1. Gaitu GitHub doan "Push Protection for Yourself" zure GitHub kontu osoan:
2. Joan GitHub-era Settings (zure profil pertsonalaren ezarpenak, goiko eskuinaldean) -> Code security and analysis (edo Code security).
3. Joan Secret scanning -> Gaitu Push protection for yourself.
4. Hau aktibatuta, korrika egiten duzun bakoitzean git push edozein ordenagailutik edozein biltegi publiko edo pribatura, GitHub-en zerbitzariak zure sarrerako pakete-fitxategia ikuskatzen du * push-a onartu aurretik: AWS gako, OpenAI gako, Stripe gako, SSH gako pribatu edo Slack token bat detektatzen badu, GitHub-ek baztertzen du. git push zuzenean zure terminalean konpromezua martxan jarri baino lehen.
5. ** Instalatu gitleaks bertako gisa pre-commit engantxatu zure ordenagailu eramangarria**:

   # 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
   

Eskualdeko larrialdi-zenbakiak eta agentziaren protokoloak¶

GitHub-en ustekabeko kredentzialak bultzatzeak datu pertsonal arautuetan baimenik gabe sartzea eragiten badu (PII / PHI), osasun-sistemek edo gobernu-azpiegiturek, arau-hausteak jakinarazteko derrigorrezko protokoloak jarraitzen dituzte:

• Estatu Batuak eta Kanada:
• Larrialdietako bizitza-segurtasuna / Azpiegitura kritikoen etenaldia: markatu 911 Azpiegitura-hauste batek ospitaleko funtzionamenduari edo segurtasun fisikoko kontrolei eragiten badie.
• Zibersegurtasun eta Azpiegituren Segurtasun Agentzia (CISA) eta FBI (IC3): Erasotzaileek filtratutako hodeiko gakoak erabili badituzte datuak kanporatzeko edo estortsio-malwarea zabaltzeko, jakinarazi CISA-ri (1-844-Say-CISA / cisa.gov/report) eta FBI Internet Crime Complaint Center (ic3.gov).
• SEC, FTC eta Estatuko Fiskal Nagusiaren Datuen Urraketen Jakinarazpena: CloudTrail / datu-basearen sarbide-erregistroek baimenik gabeko IP helbide batek bezeroaren datu pertsonalak atzitu dituela erakusten badute (PII) edo osasun erregistroak (HIPAA ePHI) Filtratutako gakoa baliogabetu baino lehen, kontsultatu berehala aholkulari juridikoari estatuko datu-hausteen jakinarazpen-epeei eta HHS OCR / FTC Bermeen Araua txosten federalei buruz.
• Kanadako Zibersegurtasun Zentroa: deitu 1-833-CYBER-88 (1-833-292-3788) edo eman pribatutasun-urraketak azpian PIPEDA Kanadako Pribatutasun Komisarioaren Bulegoari (OPC).
• Erresuma Batua:
• Larrialdi Zerbitzuak: Markatu 999 (edo 101 / Ekintza Iruzurra 0300 123 2040 eta National Cyber Security Center / NCSC etan ncsc.gov.uk).
• Informazio Komisarioaren Bulegoa (ICO - 72 orduko Erresuma Batuko GDPR leihoa): Filtratutako kredentzial batek Erresuma Batuko egoiliarren datu pertsonaletara baimenik gabe atzitzea baimentzen badu, **Erresuma Batuko GDPRren 33. artikuluak ICO-ri jakinaraz daitezkeen datu pertsonalen urraketak salatzea eskatzen du (0303 123 1113) arau-haustearen berri izan eta 72 orduko epean.
• Europar Batasuna:
• Larrialdi Zerbitzuak: Markatu 112 EBko estatu kide guztietan.
• GDPR 33. artikuluan eta NIS2 Zuzentarauko Gorabeheren Jakinarazpena: EBko GDPR-aren menpeko erakundeek egiaztatu behar dute kredentzialaren esposizioak datu pertsonalen konfidentzialtasuna urratu duen ala ez (72 orduko jakinarazpena Datuak Babesteko Agintaritza Nazionalari / DPA), EBren pean funtsezko/garrantzitsuak diren entitateak NIS2 Zuzentarauak 24 orduko abisu goiztiarreko epemuga aurre egin behar dio euren herrialdeari CSIRT (BSI Alemanian, ANSSI Frantzian, ACN Italian) ziber-gertakari garrantzitsuengatik.
• Australia eta Zelanda Berria:
• Larrialdi Zerbitzuak: Markatu 000 Australian edo 111 Zelanda Berrian.
• Australiako Zibersegurtasun Zentroa (ACSC) & Jakinaraz daitezkeen datuen urraketak (OAIC): Deitu1300 CYBER1 (1300 292 371) gertakariei erantzuteko, eta ebaluatu jakinarazpen-betebeharrak Australiako Informazio Komisarioaren Bulegoaren arabera (OAIC) Jakinaraz daitezkeen datu-hausteak (NDB) eskema edo Zeelanda Berriko 2020ko Pribatutasun Legea (Privacy Commissioner).
• India eta Asia-Pazifikoa:
• Larrialdi Zerbitzuak: Markatu 112 Indian (edo 1930 ziberdelituarengatik).
• CERT-en Derrigorrezko 6 orduko Txostenaren Zuzentaraua (India): Indian Ordenagailuen Larrialdiei Erantzuteko Taldearen azpian (CERT-In) jarraibideak (No. 20(3)/2022-CERT-In), hodeiko/IT sistemetarako baimenik gabeko sarbidea edo Indiako erakundeei eragiten dieten datu-filtrazioei jakinarazi behar zaie incident@cert-in.org.in detektatu eta 6 orduko epean.

Maiz egiten diren galderak¶

Ezabatu dut .env fitxategia eta akatsa egin eta 30 segundora konpromezu berri bat bultzatu du - oraindik nire API gakoak eta datu-basearen pasahitzak biratu behar al ditut?¶

Bai, ehuneko 100 - biratu tekla bakoitza berehala salbuespenik gabe. GitHub Secret Scanning-en zibersegurtasuneko ikasketa akademikoek eta telemetriak baieztatu dute kredentzialak biltzeko automatizatutako robotek GitHub Gertaeren korronte publikoa kontrolatzen dutela (api.github.com/events) denbora errealean eta deskargatu barnean bultzatu berri diren konpromisoak 1,5 eta 5 segundo. Okerrago, ezabatzen duen bigarren konpromezu bat bultzatzea .env testu arrunt osoa uzten du .env fitxategia betirako lehen konpromezuaren historiaren desberdintasunaren barruan dago - eta bot askok ezabatzen duten konpromisoak bilatzen dituzte bereziki .env fitxategiak. Sekretu bat biltegi publiko batera segundo batean ere eraman ondoren, betirako arriskuan jartzen da; hornitzailearen aginte-panelean kredentzialak ezeztatu eta biratzea da babesten zaituen gauza bakarra.

Zer gertatuko litzateke biltegia GitHub-eko repo PRIBATUA balitz konprometitu nuenean .env fitxategia, eta garbitu nahi dut hurrengo astean repo publiko egin aurretik?¶

Biltegia balitz Ehuneko 100 pribatua denbora osoan (eta ez zuen hirugarrenen CI/CD aplikazio fidagarririk izan), GitHub Events API publikoko scraper bot-ek izan dute ez oraindik ikusi duzu zure sekretua. Hala ere, EZ ezabatu besterik gabe `.env` konpromiso berri batean eta, ondoren, irauli repo Pribatutik Publikora. Biltegi pribatu bat Publikora iraultzen duzun momentuan, bere konpromiso historikoaren grafiko osoa publiko bihurtzen da - eta bot-ek berehala eskaneatzen dituzte kommit zahar guztiak errepo publiko berrian. Repo pribatu bat publiko egin aurretik, hau da: (1) Exekutatu git filter-repo --invert-paths --path .env fitxategia konpromezu historiko guztietatik kentzeko (eta biratu teklak hala ere praktika onak lortzeko), EDO (2) Kopiatu uneko fitxategi garbiak karpeta berri batean, exekutatu git init 1-konpromisoaren hasierako historia garbi bat lortzeko, eta argitaratu biltegi berri hori.

Zergatik erantsi zuen AWS-k automatikoki izeneko politika bat AWSCompromisedKeyQuarantineV2 nire IAM erabiltzaileari, eta zergatik oraindik fakturatzen ari naiz?¶

AWS GitHub Secret Scanning-ekin zuzenean elkartzen delako, noiznahi AKIA... gakoa GitHub-eko konpromiso publiko batean agertzen da, AWS-ren segurtasun-sistema automatizatuak minutu gutxitan detektatzen du, laguntza-txartel bat irekitzen du eta kudeatutako politika eransten du. AWSCompromisedKeyQuarantineV2 (edo V3) IAM erabiltzaile horri. Berrogeiaren politika horrek ekintza arriskutsu agerikoak blokeatzen ditu, besteak abian jartzea ec2:RunInstances edo S3 kuboak ezabatzea - baina EZ ditu amaitzen erasotzaileak abian jarri dituen EC2 instantziarik gidalerroa erantsi baino lehen 60 segundoetan, ezta atzeko ateko IAM erabiltzaileak edo aldi baterako ezabatzen ere. STS erasotzaileak dagoeneko sortu dituen saioak. Oraindik eskuz ezabatu behar duzu filtratutako gakoa, egiaztatu EC2 Global View Eskualde guztietan, instantzia malkartsuak amaitzeko, eta egiaztatu CloudTrail baimenik gabeko IAM aldaketetarako.

Zein da arteko aldea git filter-repo eta BFG Repo-Cleaner, eta zergatik ez dut erabili behar git filter-branch?¶

git iragazki-adarra Git-en lehen bertsioetan eraikitako ondare shell script zaharra da, oso motela biltegi handietan, gaizki konfiguratzen dena (kopia-erreferentziak utziz). erreferentzia/jatorrizkoa/ oraindik zure sekretuak dauzkatenak.), eta orain Git-en zaharkitze-abisu ofizial bat inprimatzen du ez erabiltzeko esaten dizu. Biak git-filter-repo (Python-en idatzia eta Git nagusien mantentzaileek eta GitHub-ek ofizialki onartzen dute) eta BFG Repo-Cleaner (Java/Scala-n idatzia) exekutatu 10 eta 100 aldiz azkarrago eta garbi idatzi konpromezu, zuhaitz eta etiketa guztiak. git-filter-repo Oro har, gaur egun hobesten da zure uneko egiaztatutako konpromisoa ere aldatzen duelako (`HEAD`) aldez aurretiko konpromiso bereizia eskatu gabe.

Nola ikus dezake norbaitek GitHub-en nire ezabatutako konpromisoa korrika egin ondoren git filter-repo eta git push --force?¶

Git-en, `git push --force` soilik eguneratzen du adar erreferentzia erakuslea (`refs/heads/main`) zure berridatzitako konpromezu-kate berria seinalatzea; egiten du ez berehala ezabatu erreferentziarik gabeko ("zintzilik") konprometitutako objektu zaharrak GitHub-en backend zerbitzarietan gordeta. Bot batek zure jatorrizko konpromisoaren 40 karaktereko SHA hash-a grabatu badu Gertaerak API publikora jo zuenean, zuzenean nabigatu. https://github.com/owner/repo/commit/<40-char-SHA> oraindik ere kargatuko du umezurtz konpromezu hori GitHub-en objektuen cachetik zabor bilketa exekutatu arte. Cacheko ikuspegi hori berehala ukitzeko, gainera ezabatu GitHub-eko biltegia eta birsortu zure tokiko biltegi garbitik, edo bidali SHA-ri zintzilik dagoen konpromisoa GitHub laguntza (`support.github.com`) zerbitzariaren alboko cache berehala garbitzeko.

Zer gertatuko da norbaitek nire biltegi publikoan "Fork" klik egin badu exekutatu aurretik git filter-repo?¶

Horregatik 1. urratsa beti da hornitzailearen paneleko kredentzialak baliogabetzen eta biratzen: korrika git filter-repo eta zure biltegira indarrez bultzatzea EZ du berridazten beste norbaiten Fork independentearen barruan zure biltegiaren (zure gurasoen biltegi osoa ezabatzen baduzu eta GitHub laguntza-zerbitzuarekin harremanetan jartzen ez baduzu sardexketako datu sentikorren inguruan). AWS/API gakoak ezeztatu eta datu-basearen pasahitzak biratu ondoren, zaharraren edozein kopia .env Hirugarrenen sardexka edo bot datu-base baten barruan dagoen fitxategia karaktere-kate hil eta alferrikako bihurtzen da, jada zure azpiegitura sartu ezin daitekeena.

Erlazionatutako gidak¶

• Ransomwarea eta malwarea: berehala eustea eta berreskuratzea
• Domeinu-izenen bahiketa, iraungitako DNS eta webgunearen jabegoa
• Google Workspace edo Microsoft 365 domeinu pertsonalizatuko administratzailearen blokeoa eta DNS erreskate
• Phishing eta arriskuan dauden kontuak: larrialdiko blokeoa
• Ustekabean rm -rf edo Shift-Delete Linux, macOS edo Windows-en: berehalako irakurtzeko soilik muntatu
• Larrialdi zenbakiak herrialdeka

Iturriak eta orientabide ofiziala¶

• GitHub Segurtasun Dokumentazio Ofiziala (docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository): * Datu sentikorrak biltegi batetik kentzea (git filter-repo, BFG Repo-Cleaner, Dangling Commit Cache Purging eta Secret Scanning Push Protection)*.
• Amazon Web Services (AWS) Segurtasun Istripuei Erantzun Gida (docs.aws.amazon.com/security/): * Erakutsitako AWS IAM sarbide-gakoei erantzutea (AWSCompromisedKeyQuarantineV2, Aldi baterako baliogabetzea STS Saioak bidez aws:TokenIssueTime, eta CloudTrail Auzitegiko Ikuskaritza)*.
• Arau eta Teknologia Institutu Nazionala (NIST) (Estatu Batuak): Argitalpen Berezia 800-61 Rev. 2: Informatika-segurtasuneko gorabeherak kudeatzeko gida eta SP 800-57: Gakoen kudeaketarako gomendioa (Kredentzialak baliogabetzea eta biraketa kriptografikoa).
• Ireki Web Aplikazioen Segurtasun Proiektua (OWASP): Sekretuak kudeatzeko iruzur-orria (Kredentzialak gogor kodetuak saihestea, Aurre-konpromiso sekretua eskaneatzearekin Gitleaks/TruffleHog, eta Ephemeral Runtime Secret Injection).
• Zibersegurtasun eta Azpiegituren Segurtasun Agentzia (CISA) (Estatu Batuak): Cloud Security Technical Reference Architecture and Compromised Credential Remediation Playbook.