Kontrolný zoznam na posilnenie zabezpečenia GCP pre malé a stredne veľké tímy

Bežné cesty hrozieb v GCP

Väčšina cloudových incidentov začína malou medzerou v zodpovednosti alebo konfigurácii. Hľadajte tieto cesty skôr, ako to urobí útočník.

• Používateľ, servisný účet alebo identita záťaže s nadmernými oprávneniami môže z jedných ukradnutých prihlasovacích údajov urobiť široký prístup naprieč projektmi.
• Vystavený koncový bod na správu, ladiaci port alebo príliš benevolentné pravidlo firewallu môžu obísť všetky opatrenia navrhnuté pre bežnú prevádzku aplikácie.
• Verejný bucket úložiska alebo príliš široko platná podpísaná adresa URL môžu vyzradiť údaje zákazníkov bez viditeľného napadnutia aplikácie.
• Zastarané záťaže vytvárajú trvalé riziko, ak staré image, zabudnuté menné priestory, nepoužívané servisné účty a prostriedky bez vlastníka zostávajú nasaditeľné.
• Chýbajúce alebo krátko uchovávané auditné záznamy sťažujú zistenie, kto zmenil zásadu, kedy sa prístup začal a ku ktorým údajom sa útočník dostal.
• Neotestovaná záloha je len nádej. Neúspešné obnovy, neúplné uchovávanie a nedostupné šifrovacie kľúče môžu z bezpečnostnej udalosti urobiť trvalú stratu údajov.

Identita a prístup

Považujte identitu za primárnu riadiacu rovinu. Každý človek, automatizovaný proces aj záťaž by mali mať vlastnú identitu s jasne vymedzeným účelom.

Vymedzte hranice prostriedkov explicitne

Používajte organizáciu a priečinky na ochranné mantinely a oddeľte vývojové, testovacie (staging) a produkčné prostredie do samostatných projektov alebo silnejších hraníc dôvery. Uplatňujte zásady organizácie na najvyššej rozumne možnej úrovni, obmedzte používanie služieb a nezdieľajte produkčné projekty medzi nesúvisiacimi produktmi.

Udeľujte minimálnu rolu v čo najužšom rozsahu

Uprednostňujte preddefinované alebo vlastné roly pred širokými základnými rolami, prideľujte ich skupinám a identitám záťaží a používajte podmienky IAM tam, kde môže prístup zúžiť názov prostriedku alebo štítok. Kontrolujte nepoužívané oprávnenia a odstráňte trvalý prístup do produkcie, ktorý má patriť len do procesu núdzového prístupu (break-glass).

Odstráňte dlhodobé prihlasovacie údaje

Používajte Workload Identity Federation for GKE, aby pody dostávali krátkodobé prihlasovacie údaje bez exportovaných kľúčov servisných účtov. Kde je to možné, zablokujte vytváranie a nahrávanie kľúčov pomocou zásad organizácie, inventarizujte všetky zostávajúce kľúče a nastavte upozornenia na vysoko rizikové zmeny IAM v Cloud Audit Logs.

Sieť a okraj siete

Počítajte s tým, že nejaká chyba aplikácie bude skôr či neskôr dosiahnuteľná zo siete. Obmedzte, k čomu sa cez túto chybu dá dostať.

Začnite zákazom všetkého a pridávajte pomenované cesty

Používajte pravidlá firewallu VPC podľa princípu najnižších oprávnení a pre prevádzku podov Kubernetes NetworkPolicies. Oddeľte prostredia do samostatných sietí, zdokumentujte každú cestu prichádzajúcej prevádzky a odstráňte široké ladiace pravidlá, ktoré povoľujú porty na správu alebo všetky protokoly z veľkých rozsahov adries.

Ponechajte uzly a riadiace roviny privátne

Vypnite externé IP adresy na uzloch GKE. Uprednostňujte privátny koncový bod riadiacej roviny založený na DNS, a ak sa koncovému bodu s IP adresou nedá vyhnúť, obmedzte ho pomocou autorizovaných sietí. Namiesto širokého prístupu na internet dajte záťažiam zámerne navrhnutú cestu pre odchádzajúcu prevádzku.

Zverejňujte len zámerne verejné služby

Sprístupňujte aplikácie cez skontrolovanú bránu alebo nástroj na vyrovnávanie záťaže, nie cez náhodné adresy podov alebo uzlov. Ukončujte TLS na spravovaných certifikátoch, obmedzte hostiteľov a cesty prichádzajúcej prevádzky, nastavte limity požiadaviek a ich frekvencie a administračné rozhrania ponechajte za prístupom s overením identity.

Údaje a tajomstvá

Chráňte údaje v pokoji, pri prenose aj pri používaní a potom preukážte, že ich dokážete obnoviť. Vyhľadávanie údajov je súčasťou kontroly.

Zabráňte nechcenému verejnému prístupu

Vynucujte prevenciu verejného prístupu a jednotný prístup na úrovni bucketu v Cloud Storage. Klasifikujte buckety podľa citlivosti, obmedzte prístup k objektom a kľúčom, zapnite protokolovanie pre údaje s vysokou hodnotou a používajte šifrovacie kľúče spravované zákazníkom tam, kde to vyžaduje váš model rizík alebo dodržiavania predpisov.

Neukladajte tajomstvá do image ani zdrojového kódu

Ukladajte prihlasovacie údaje do Secret Manager a udeľujte prístup konkrétnej identite záťaže ku konkrétnej verzii tajomstva. Tajomstvá plánovane rotujte, nekopírujte ich do Gitu ani do image kontajnerov a nepovažujte bežné Kubernetes Secrets za úplnú ochrannú hranicu.

Testujte obnovu, nielen vytváranie záloh

Stanovte cieľový bod obnovy (RPO) a cieľový čas obnovy (RTO), uchovávajte kópie mimo domény zlyhania produkcie a chráňte prístup k zálohám a šifrovacím kľúčom pred identitou záťaže. Pravidelne podľa plánu obnovujte údaje do izolovaného prostredia, overte ich a zaznamenajte čas trvania a všetky manuálne kroky.

Posilnenie zabezpečenia GKE

GKE zabezpečuje spravovanú riadiacu rovinu, ale konfigurácia klastra, menné priestory, zásady prijímania (admission) a záťaže zostávajú vo vašej správe.

Urobte z menných priestorov izolačnú zmluvu

Oddeľte tímy a prostredia do menných priestorov alebo klastrov, naviažte v nich úzke roly Kubernetes RBAC a použite kvóty prostriedkov a NetworkPolicies. Pri dodávaní aplikácií sa vyhnite oprávneniu na zápis v celom klastri a každej záťaži, ktorá potrebuje vlastnú identitu, prideľte vlastný servisný účet.

Prijímajte len image a konfigurácie, ktorým dôverujete

Vynucujte štandard Pod Security na úrovni restricted alebo ekvivalentné pravidlá Policy Controller. Nasadzujte image podľa nemenného digestu, skenujte ich na zraniteľnosti, používajte Binary Authorization tam, kde záleží na pôvode, a odmietajte neočakávaný prístup k hostiteľovi, eskaláciu oprávnení a väzby na rolu cluster-admin.

Odoberte kontajnerom zbytočné oprávnenia

Spúšťajte kontajnery pod iným používateľom ako root, odoberte linuxové capabilities, kde je to možné, používajte koreňový súborový systém len na čítanie a použite profil seccomp RuntimeDefault. Nepripájajte token servisného účtu bez potreby, vyhnite sa privilegovaným kontajnerom a menným priestorom hostiteľa, udržiavajte oprávnenia servisného účtu uzla na minime a používajte Shielded Nodes a Container-Optimized OS.

Detekcia a obnova

Opatrenia zlyhávajú. Spoliehajte sa na dôkazy a nacvičené postupy, nie na dôveru, že nikto neurobil chybu.

Zhromaždite dôkazy, ktoré budete potrebovať

Uchovávajte Cloud Audit Logs a systémové protokoly aj protokoly záťaží GKE na centrálnom mieste s dobou uchovávania, ktorá zodpovedá potrebám vašich vyšetrovaní. Protokoly auditu prístupu k údajom zapínajte selektívne pre citlivé údaje, obmedzte prístup k protokolom a zaznamenávajte administratívne zmeny IAM, firewallu, úložiska a konfigurácie klastra.

Upozorňujte na zmeny s bezpečnostným významom

Nastavte upozornenia na verejné vystavenie úložiska, široké zmeny firewallu alebo IAM, neočakávané kľúče servisných účtov, zamietnutia pri prijímaní (admission), vystavenie riadiacej roviny, opakované zlyhania overenia, vypnuté protokolovanie, neúspešné zálohy a končiacu platnosť certifikátov. Každé upozornenie smerujte vlastníkovi spolu s krokmi, ako ho potvrdiť alebo zamietnuť.

Nacvičte reakciu

Napíšte krátke runbooky pre uniknuté prihlasovacie údaje, zverejnené údaje, napadnuté záťaže a stratené regióny alebo projekty. Uveďte, kto môže schváliť izoláciu incidentu, ako odobrať prístup, ako zachovať dôkazy a ako obnoviť službu. Runbooky otestujte s ľuďmi, ktorí ich budú používať.

Kontrolný zoznam s prioritami na 30, 60 a 90 dní

Ak začínate s neúplným základom, zoraďte prácu tak, aby ste najskôr znížili vystavenie a neskoršie kontroly boli opakovateľné.

Dni 1 až 30: uzavrite zjavné cesty

Inventarizujte projekty a ich vlastníkov, odstráňte nepoužívané a dlhodobé prihlasovacie údaje, overte protokolovanie auditu, zablokujte verejné buckety, skontrolujte najširšie pravidlá firewallu a oprávnenia IAM, zistite medzery v produkčných zálohách a opravte každý verejný koncový bod bez vlastníka. Ku každému zisteniu priraďte vlastníka a termín.

Dni 31 až 60: urobte základ opakovateľným

Presuňte konfiguráciu sietí, identít a záťaží do revidovanej infraštruktúry ako kódu a do dodávania cez GitOps. Zaveďte Workload Identity, privátne uzly, Pod Security na úrovni restricted, kontroly dôveryhodných image, centralizované protokoly a upozornenia na najdôležitejšie zmeny.

Dni 61 až 90: preukážte účinnosť a udržte ju

Vykonajte testy obnovy a simulačné cvičenie incidentu (tabletop), skontrolujte privilegovaný prístup a uplynutie výnimiek, znova preskenujte image a závislosti, overte, či vlastníci dostávajú upozornenia, a zmerajte zostávajúce medzery. Zaraďte kontroly do pravidelného cyklu revízií skôr, ako dôkazy zastarajú.

Použite tento kontrolný zoznam ako východiskový bod. Snow Tree môže tento základ zaviesť v rámci prevádzky spravovanej platformy alebo cielenej poradenskej zákazky.

Spravovaná platforma · Poradenstvo

Oficiálne zdroje

Keď sa zmenia predvolené nastavenia platformy alebo možnosti produktov, považujte aktuálne odporúčania Googlu za technický zdroj pravdy.

• Google Cloud: Osvedčené postupy na posilnenie zabezpečenia klastra GKE
• Google Cloud: Osvedčené postupy zabezpečenia GKE