Tajné kľúče a konfigurácia v cloude: ako ich bezpečne spravovať

01Rozlíšte tajné údaje a bežnú konfiguráciu

Adresa služby, zvolený jazyk a limit veľkosti prílohy sú konfigurácia. Heslo databázy, privátny kľúč alebo token s oprávnením odosielať správy sú tajné údaje. Niektoré nastavenia sú citlivé aj bez hesla, preto ich posudzujte podľa použitia. Toto rozlíšenie pomôže zvoliť miesto uloženia, prístupové práva a spôsob zmeny.

Správca tajných údajov uchováva a poskytuje chránené hodnoty. Nemá automaticky slúžiť ako databáza všetkých nastavení aplikácie. Aj dokumentácia Azure Key Vault tieto účely odlišuje. Ak do jedného úložiska vložíte všetko, zbytočne rozšírite prístup a prevádzkovú závislosť bežných zmien od služby určenej pre tajné údaje.

Začnite inventárom bez vypisovania skutočných hodnôt. Pri každom tajnom údaji evidujte účel, vlastníka, závislú službu, prostredie a postup výmeny. Označte, či ide o prístupový token, certifikát alebo kľúč na dešifrovanie uložených dát. Tieto typy sa nesmú spravovať jedným nerozlíšeným pravidlom.

Spýtajte sa aj na menej viditeľné miesta: notebooky, automatizácie, staré exporty, interné návody a nástroje podpory. Záznam o existencii kľúča má umožniť jeho nájdenie a bezpečnú výmenu. Nemá sa stať ďalšou tabuľkou plnou hesiel, ku ktorej dostane prístup každý člen projektu.

02Uloženie pomôže len s primeranými oprávneniami

Šifrované úložisko nezabráni úniku, ak oprávnená identita dokáže čítať všetky hodnoty. Prideľte aplikácii iba tajné údaje, ktoré potrebuje na svoju úlohu. Oddelte oprávnenie čítať hodnotu, vytvoriť novú verziu a meniť prístupové pravidlá. Nie každý človek, ktorý nasadzuje aplikáciu, musí vidieť produkčné heslo.

Samostatne nastavte vývoj, testovanie a produkciu. Testovacia aplikácia nemá používať produkčný platobný token ani databázové konto. Rozdelenie prispôsobte cloudovej hierarchii a tímu: môžu pomôcť oddelené projekty, účty alebo úložiská. Podstatná je overená hranica oprávnení, ktorú samotné odlišné pomenovanie tajného údaja nevytvorí.

Pri prístupe služby k úložisku využite podporovanú identitu pracovnej záťaže alebo spravovanú identitu, ak je pre vaše prostredie vhodná. Znižujete tým potrebu uložiť ďalší dlhodobý prístupový kľúč len na načítanie ostatných. Google Cloud aj Azure takéto postupy opisujú, ale konkrétne nastavenie závisí od platformy a spôsobu prevádzky.

Ľudský prístup majte viazaný na osobné konto a evidovaný účel. Pri odchode člena tímu odoberte jeho oprávnenia a posúďte tajné údaje, ktoré mohol skopírovať. Zrušenie prístupu k úložisku neodstráni hodnotu z jeho predchádzajúcej kópie. O potrebe výmeny rozhoduje aj spôsob použitia a riziko.

03Skontrolujte cestu kľúča až do aplikácie

Privilegovaný tajný kľúč neposielajte do webového JavaScriptu ani do balíka mobilnej aplikácie. Ak klient potrebuje vykonať citlivú operáciu, nech ju sprostredkuje server po kontrole identity a oprávnenia používateľa. Niektoré služby poskytujú zámerne verejné identifikátory; tie rozlišujte od hodnôt, ktoré umožňujú prístup k dátam alebo účtovanie.

Pri automatickom nasadení rozhodnite, kedy služba tajný údaj načíta. Môže ho dostať prostredníctvom podporovanej integrácie alebo načítať pri spustení. Sledujte, či počas zostavovania nevzniká jeho kópia v obraze kontajnera alebo archíve. Produkčný kľúč často nie je potrebný na samotné vytvorenie aplikačného balíka.

Premenná prostredia je spôsob odovzdania hodnoty, nie automatická ochrana. Hodnota môže uniknúť cez diagnostiku, výpis procesu alebo knižnicu, ktorá zaznamenáva nastavenia. Vyberte podporovaný spôsob podľa platformy a obmedzte prístup k bežiacej službe. Vyskúšajte aj chybový priebeh, v ktorom býva logovanie podrobnejšie.

Ak sa kľúč dostal do repozitára, jeho odstránenie z posledného súboru nevyrieši platnosť pôvodnej hodnoty. GitHub dokumentuje kontrolu histórie aj následnú rotáciu odhalených prihlasovacích údajov. Ochranu pri odosielaní zmien a skenovanie považujte za pomoc pri prevencii a odhalení, spolu s procesom reakcie.

04Rotácia musí zahŕňať službu aj jej klientov

Rotácia znamená pripraviť novú hodnotu, nastaviť ju v cieľovej službe, nasadiť jej použitie a overiť výsledok. Potom sa podľa možností služby zruší stará hodnota. Samotné pridanie verzie do úložiska nemusí zmeniť databázové heslo ani token u externého dodávateľa. Potrebujete rozumieť obidvom stranám prepojenia.

Niektoré služby umožňujú dočasne používať dva kľúče, iné vyžadujú presnejšie koordinovanú zmenu. Pripravte postup pre všetkých konzumentov vrátane dávkových úloh, ktoré sa spúšťajú zriedkavo. Ak na ne zabudnete, problém sa môže objaviť až po úspešnom nasadení hlavnej aplikácie.

Vyberte, ako aplikácia pracuje s verziou. Pevne určená verzia umožňuje kontrolované nasadenie, no vyžaduje jej aktualizáciu. Automatické použitie najnovšej hodnoty môže zjednodušiť zmenu, ale treba zvládnuť neplatnú verziu a načítanie za behu. Google pri správe verzií odporúča kontrolované nasadenie konkrétnej verzie; neprenášajte ho bez posúdenia na každú službu.

Výmenu prístupového tokenu odlíšte od výmeny šifrovacieho kľúča. Staršie dáta môžu na dešifrovanie potrebovať pôvodný kľúč. Jeho bezhlavé vymazanie by mohlo zneprístupniť obsah aj zálohy. Postup musí riešiť nové šifrovanie, existujúce dáta a obnovu podľa možností použitého systému.

Pri plánovanej rotácii si pripravte kontrolu úspechu a bezpečný postup pri zlyhaní. Pri podozrení na kompromitáciu sa zasa nespoliehajte na návrat k odhalenému tokenu. Návrat aplikácie do prevádzky a zastavenie neoprávneného prístupu musia byť súčasťou jedného koordinovaného rozhodnutia.

05Logujte udalosť, hodnotu držte mimo záznamu

Pre audit potrebujete vedieť, ktorá identita čítala alebo menila tajný údaj, kedy a s akým výsledkom. Nepotrebujete jeho obsah. Nastavte dostupné prístupové logy a upozornenia podľa rizika. Samostatne posudzujte bežné načítanie aplikáciou a neobvyklé hromadné čítanie alebo zmenu oprávnení.

Prejdite logy nasadenia, aplikácie aj podpory. Skúste neplatné prihlasovanie a chybu externej služby a overte, či odpoveď neobsahuje celý autorizačný údaj. Pri záznamoch požiadaviek odstráňte citlivé hlavičky a parametre. Kontrolu uskutočnite aj na miestach, kde sa záznamy exportujú do ďalšieho nástroja.

Pri incidente určte vlastníka zneplatnenia, zavedenia náhrady a preverenia následkov. Zistite rozsah oprávnení, možné obdobie použitia a dostupné dôkazy. Ak to prostredie umožňuje, obmedzte aj podozrivú identitu alebo cestu prístupu. Postup nemá skončiť označením upozornenia za vybavené po vymazaní citlivého textu.

Zároveň neopravujte incident ďalším rozosielaním kľúča. Do komunikačného záznamu patrí identifikátor tajného údaja, stav a zodpovednosť. Novú hodnotu poskytuje schválený mechanizmus. Tak zostane priebeh vysvetliteľný aj ľuďom, ktorí potrebujú koordinovať obnovu, no nemajú oprávnenie kľúč čítať.

06Pripravte výpadok úložiska a obnovu prístupu

Aplikácia môže zlyhať pri spustení, ak úložisko tajných údajov nie je dostupné. Určte, ako dlho smie používať už načítanú hodnotu a ako rešpektuje jej zneplatnenie. Vyrovnávacia pamäť môže obmedziť počet požiadaviek a závislosť od krátkeho výpadku, ale zároveň vytvára ďalšie miesto s citlivým obsahom.

Overte správanie pri súčasnom štarte viacerých inštancií a pri obmedzení počtu požiadaviek. Nečakané opakované načítanie môže predĺžiť nasadenie alebo zaťažiť službu. Nastavenie musí zohľadniť frekvenciu zmien, limity platformy aj cenu. Tajný údaj nie je potrebné čítať nanovo pri každej bežnej operácii používateľa.

Núdzový prístup pripravte tak, aby bol chránený, kontrolovateľný a použiteľný aj pri zlyhaní bežnej cesty. Dokumentácia OWASP upozorňuje na závislosti obnovy od prístupových údajov. Ak sú všetky údaje potrebné na obnovu uložené v nefunkčnej službe, samotný návod tímu nepomôže.

Pri nenahraditeľných šifrovacích kľúčoch overte aj obnovu podporovaným spôsobom. Nestačí vedieť, že existuje záloha objektu. Skontrolujte, kde sa dá obnoviť, kto má potrebné oprávnenia a či následne otvoríte závislé dáta. Podmienky cloudových služieb sa líšia, preto skúšku prispôsobte konkrétnemu produktu.

07Zaveďte spravovanie po menších celkoch

Vyberte jednu produkčnú integráciu a vytvorte celý overený postup: identita, uloženie, načítanie, rotácia a incident. Až potom prenášajte ostatné kľúče. Pri každom presune odstráňte nepotrebné kópie a aktualizujte návod. Pôvodné platné hodnoty zneplatnite podľa koordinovaného postupu, aby migrácia nezostala len presunom textu.

Téma nadväzuje na citlivé údaje v cloude a na bezpečnosť dát v systémoch na mieru. Tu sa sústreďte na konkrétnu cestu oprávnenia. Každý tajný údaj má mať vlastníka, primeraný rozsah a vyskúšaný postup zmeny.

Pri odovzdaní prevádzky nech zastupujúci kolega vykoná skúšku podľa návodu bez pomoci autora. Zaznamenajte nejasné kroky a chýbajúce oprávnenia. Tak preveríte použiteľnosť procesu, ktorá sa pri jednorazovom úspešnom nasadení nemusí ukázať. Výsledkom má byť spravovateľný prístup počas celej životnosti aplikácie.

08Časté otázky o tajných údajoch v cloude