Prístupový kľúč k AWS v histórii Gitu

Aplikácia beží na VPS u iného poskytovateľa, preto nemôže dostať IAM rolu ako server v AWS a do S3 sa prihlasuje dlhodobým prístupovým kľúčom IAM používateľa app-uploads. Ten mal pridelenú spravovanú politiku AmazonS3FullAccess, teda plný prístup ku všetkým bucketom v účte vrátane toho so zálohami databázy.

Pri odovzdávaní repozitára novému externému vývojárovi prebehla kontrola celej histórie nástrojom gitleaks (gitleaks git -v .). Našla prístupový kľúč AWS v súbore .env, ktorý bol omylom commitnutý pred vyše rokom a o dva dni neskôr zmazaný ďalším commitom. Zmazanie zo súboru ho z histórie neodstránilo. Každý, kto mal repozitár naklonovaný, ho mal na disku.

Kľúč bol stále aktívny, produkcia ho používala.

Kto ho mohol mať: súčasní aj bývalí vývojári, dvaja externisti, ich notebooky a každá služba s prístupom k repozitáru. S kľúčom sa dalo čítať, prepisovať a mazať súbory zákazníkov aj zálohy databázy.

Predpoklad: repozitár nikdy nebol verejný. Keby bol, treba počítať s tým, že kľúč už má niekto cudzí, pretože verejné repozitáre automaticky prehľadávajú boti práve kvôli takýmto kľúčom.

Tajomstvo bolo v súbore, ktorý nebol v .gitignore, a nič nekontrolovalo commity pred odoslaním. Git je navrhnutý tak, aby históriu uchovával. Zmazanie súboru v neskoršom commite neodstráni nič, čo je v predchádzajúcich.

Dopad zväčšila druhá príčina: aplikácia potrebovala nahrávať a čítať prílohy v jednom buckete, ale kľúč mal oprávnenia na celé S3. Únik jedného kľúča tak znamenal aj prístup k zálohám.

V konzole IAM je pri každom kľúči vidieť, kedy, v ktorom regióne a ku ktorej službe bol naposledy použitý. Posledné použitie zodpovedalo produkčnej aplikácii.

CloudTrail uchováva udalosti správy (management events), napríklad výpis bucketov alebo zmeny oprávnení, 90 dní aj bez akéhokoľvek nastavenia. V histórii udalostí sa dá filtrovať podľa prístupového kľúča. Volania z iných IP adries než z produkčného servera nenašli.

Čítanie a zápis jednotlivých objektov v S3 sú dátové udalosti (data events), ktoré CloudTrail predvolene nezaznamenáva, a zapnuté neboli. Preto sa nedá preukázať, že si nikto nestiahol súbory. Záznam o incidente to uvádza presne takto, nie ako záver, že k úniku nedošlo.

1. Rotácia bez výpadku: vytvoriť nový kľúč, nasadiť ho na server, overiť, že aplikácia funguje, starý kľúč deaktivovať a po niekoľkých dňoch bez chýb zmazať. Deaktivovaný kľúč sa dá pri probléme znova zapnúť, zmazaný nie.

2. Nový kľúč patrí používateľovi s politikou iba na to, čo aplikácia robí: nahrať a prečítať objekt v jednom prefixe jedného bucketu. K zálohám nemá prístup vôbec.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:GetObject"],
      "Resource": "arn:aws:s3:::rezervacie-prilohy/uploads/*"
    }
  ]
}

3. Tajomstvá mimo repozitára: .env je v .gitignore, v repozitári ostal iba .env.example s prázdnymi hodnotami. Na serveri je súbor čitateľný iba pre používateľa, pod ktorým beží aplikácia. Tajomstvá pre nasadzovanie sú v GitHub Actions secrets.

4. Kontrola pred aj po odoslaní: gitleaks beží ako pre-commit hook u vývojárov a znova v CI pri každom pull requeste, kde sa nedá obísť vypnutím hooku. Starý, už zneplatnený kľúč je v súbore .gitleaksignore zapísaný odtlačkom nálezu, inak by kontrola histórie v CI zlyhávala stále.

5. História: po rotácii je kľúč v histórii neplatný, a teda neškodný. Prepísať históriu (napríklad nástrojom git filter-repo) by šlo, ale všetci by museli repozitár naklonovať nanovo a kópie, ktoré už existujú, by to aj tak neodstránilo. Firma históriu neprepisovala a spolieha sa na rotáciu.

Zvážené alternatívy: keby aplikácia bežala v AWS, dlhodobý kľúč by vôbec nepotrebovala a dostávala by krátkodobé prihlasovacie údaje cez IAM rolu. Mimo AWS existuje IAM Roles Anywhere, ktorý však vyžaduje vlastnú certifikačnú autoritu, na tento tím zbytočne zložité. Blokovanie tajomstiev pri odoslaní (push protection) v súkromných repozitároch je na GitHube platená funkcia.

Rotácia robí uniknutý kľúč bezcenným: AWS deaktivovaný aj zmazaný kľúč odmietne, nech je uložený kdekoľvek. Preto je rotácia hlavné opatrenie a prepisovanie histórie by bolo iba kozmetické.

Zúžená politika obmedzuje dopad budúceho úniku. Kľúč, ktorý smie iba s3:PutObject a s3:GetObject v jednom prefixe, nevie vypísať buckety, mazať ani čítať zálohy.

gitleaks hľadá v zmenách vzory známych typov tajomstiev. Hook zachytí chybu skôr, než odíde z počítača, kontrola v CI zachytí prípad, keď hook niekto nemá alebo ho obíde.

Čo to nerieši: kľúč na serveri je stále dlhodobý a kto ovládne server, získa ho. Detekcia je založená na vzoroch, takže tajomstvo v neobvyklom formáte môže prejsť.