Kontrolní seznam pro posílení zabezpečení GCP pro malé a středně velké týmy

Běžné cesty hrozeb v GCP

Většina cloudových incidentů začíná malou mezerou ve vlastnictví nebo konfiguraci. Hledejte tyto cesty dříve, než to udělá útočník.

• Uživatel, servisní účet nebo identita úlohy s nadměrnými oprávněními může z jediných ukradených přihlašovacích údajů udělat široký přístup napříč projekty.
• Vystavený koncový bod pro správu, ladicí port nebo příliš benevolentní pravidlo firewallu mohou obejít všechna opatření navržená pro běžný provoz aplikace.
• Veřejný bucket úložiště nebo příliš široce platná podepsaná adresa URL mohou vyzradit zákaznická data, aniž by došlo k viditelnému napadení aplikace.
• Zastaralé úlohy vytvářejí trvalé riziko, pokud staré image, zapomenuté jmenné prostory, nepoužívané servisní účty a prostředky bez vlastníka zůstávají nasaditelné.
• Chybějící nebo krátce uchovávané auditní záznamy ztěžují zjištění, kdo změnil zásadu, kdy přístup začal a ke kterým datům se útočník dostal.
• Neotestovaná záloha je jen naděje. Neúspěšné obnovy, neúplné uchovávání a nedostupné šifrovací klíče mohou z bezpečnostní události udělat trvalou ztrátu dat.

Identita a přístup

Považujte identitu za primární řídicí rovinu. Každý člověk, automatizovaný proces i úloha by měli mít vlastní identitu s jasně vymezeným účelem.

Vymezte hranice prostředků explicitně

Používejte organizaci a složky pro ochranné mantinely a oddělte vývojové, testovací (staging) a produkční prostředí do samostatných projektů nebo silnějších hranic důvěry. Uplatňujte zásady organizace na nejvyšší rozumně možné úrovni, omezte používání služeb a nesdílejte produkční projekty mezi nesouvisejícími produkty.

Udělujte minimální roli v co nejužším rozsahu

Upřednostňujte předdefinované nebo vlastní role před širokými základními rolemi, přidělujte je skupinám a identitám úloh a používejte podmínky IAM tam, kde může přístup zúžit název prostředku nebo štítek. Kontrolujte nepoužívaná oprávnění a odeberte trvalý přístup do produkce, který má patřit jen do procesu nouzového přístupu (break-glass).

Odstraňte dlouhodobé přihlašovací údaje

Používejte Workload Identity Federation for GKE, aby pody získávaly krátkodobé přihlašovací údaje bez exportovaných klíčů servisních účtů. Kde je to možné, zablokujte vytváření a nahrávání klíčů pomocí zásad organizace, inventarizujte všechny zbývající klíče a nastavte upozornění na vysoce rizikové změny IAM v Cloud Audit Logs.

Síť a okraj sítě

Počítejte s tím, že nějaká chyba aplikace bude dříve či později dosažitelná ze sítě. Omezte, k čemu se přes tuto chybu lze dostat.

Začněte zákazem všeho a přidávejte pojmenované cesty

Používejte pravidla firewallu VPC podle principu nejnižších oprávnění a pro provoz podů Kubernetes NetworkPolicies. Oddělte prostředí do samostatných sítí, zdokumentujte každou cestu příchozího provozu a odstraňte široká ladicí pravidla, která povolují porty pro správu nebo všechny protokoly z velkých rozsahů adres.

Ponechte uzly a řídicí roviny privátní

Vypněte externí IP adresy na uzlech GKE. Upřednostňujte privátní koncový bod řídicí roviny založený na DNS, a pokud se koncovému bodu s IP adresou nelze vyhnout, omezte jej pomocí autorizovaných sítí. Místo širokého přístupu k internetu dejte úlohám záměrně navrženou cestu pro odchozí provoz.

Zveřejňujte jen záměrně veřejné služby

Zpřístupňujte aplikace přes zkontrolovanou bránu nebo nástroj pro vyrovnávání zatížení, ne přes náhodné adresy podů nebo uzlů. Ukončujte TLS na spravovaných certifikátech, omezte hostitele a cesty příchozího provozu, nastavte limity požadavků a jejich četnosti a administrační rozhraní ponechte za přístupem s ověřením identity.

Data a tajné údaje

Chraňte data v klidu, při přenosu i při používání a pak prokažte, že je dokážete obnovit. Vyhledávání dat je součástí kontroly.

Zabraňte nechtěnému veřejnému přístupu

Vynucujte prevenci veřejného přístupu a jednotný přístup na úrovni bucketu v Cloud Storage. Klasifikujte buckety podle citlivosti, omezte přístup k objektům a klíčům, zapněte protokolování pro data s vysokou hodnotou a používejte šifrovací klíče spravované zákazníkem tam, kde to vyžaduje váš model rizik nebo dodržování předpisů.

Neukládejte tajné údaje do image ani zdrojového kódu

Ukládejte přihlašovací údaje do Secret Manager a udělujte přístup konkrétní identitě úlohy ke konkrétní verzi tajného údaje. Tajné údaje plánovaně rotujte, nekopírujte je do Gitu ani do image kontejnerů a nepovažujte běžné Kubernetes Secrets za úplnou ochrannou hranici.

Testujte obnovu, nejen vytváření záloh

Stanovte cílový bod obnovy (RPO) a cílovou dobu obnovy (RTO), uchovávejte kopie mimo doménu selhání produkce a chraňte přístup k zálohám a šifrovacím klíčům před identitou úlohy. Pravidelně podle plánu obnovujte data do izolovaného prostředí, ověřte je a zaznamenejte dobu trvání a všechny ruční kroky.

Posílení zabezpečení GKE

GKE zabezpečuje spravovanou řídicí rovinu, ale konfigurace clusteru, jmenné prostory, zásady pro přijímání (admission) a úlohy zůstávají ve vaší správě.

Udělejte ze jmenných prostorů smlouvu o izolaci

Oddělte týmy a prostředí do jmenných prostorů nebo clusterů, navažte v nich úzké role Kubernetes RBAC a použijte kvóty prostředků a NetworkPolicies. Pro dodávání aplikací se vyhněte oprávnění k zápisu v celém clusteru a každé úloze, která potřebuje vlastní identitu, přidělte vlastní servisní účet.

Přijímejte jen image a konfigurace, kterým důvěřujete

Vynucujte standard Pod Security na úrovni restricted nebo ekvivalentní pravidla Policy Controller. Nasazujte image podle neměnného digestu, skenujte je na zranitelnosti, používejte Binary Authorization tam, kde záleží na původu, a odmítejte neočekávaný přístup k hostiteli, eskalaci oprávnění a vazby na roli cluster-admin.

Odeberte kontejnerům zbytečná oprávnění

Spouštějte kontejnery pod jiným uživatelem než root, odeberte linuxové capabilities, kde je to možné, používejte kořenový souborový systém jen pro čtení a použijte profil seccomp RuntimeDefault. Nepřipojujte token servisního účtu bez potřeby, vyhněte se privilegovaným kontejnerům a jmenným prostorům hostitele, udržujte oprávnění servisního účtu uzlu na minimu a používejte Shielded Nodes a Container-Optimized OS.

Detekce a obnova

Opatření selhávají. Spoléhejte na důkazy a nacvičené postupy, ne na důvěru, že nikdo neudělal chybu.

Sbírejte důkazy, které budete potřebovat

Uchovávejte Cloud Audit Logs a systémové protokoly i protokoly úloh GKE na centrálním místě s dobou uchovávání, která odpovídá potřebám vašich vyšetřování. Protokoly auditu přístupu k datům zapínejte selektivně pro citlivá data, omezte přístup k protokolům a zaznamenávejte administrativní změny IAM, firewallu, úložiště a konfigurace clusteru.

Upozorňujte na změny s bezpečnostním významem

Nastavte upozornění na veřejné vystavení úložiště, široké změny firewallu nebo IAM, neočekávané klíče servisních účtů, zamítnutí při přijímání (admission), vystavení řídicí roviny, opakovaná selhání ověřování, vypnuté protokolování, neúspěšné zálohy a končící platnost certifikátů. Každé upozornění směrujte vlastníkovi spolu s kroky, jak ho potvrdit nebo zamítnout.

Nacvičte reakci

Napište krátké runbooky pro uniklé přihlašovací údaje, zveřejněná data, napadené úlohy a ztracené regiony nebo projekty. Uveďte, kdo může schválit izolaci incidentu, jak odebrat přístup, jak zachovat důkazy a jak obnovit službu. Runbooky otestujte s lidmi, kteří je budou používat.

Kontrolní seznam s prioritami na 30, 60 a 90 dní

Pokud začínáte s neúplným základem, seřaďte práci tak, abyste nejprve snížili vystavení a pozdější kontroly byly opakovatelné.

Dny 1 až 30: uzavřete zjevné cesty

Inventarizujte projekty a jejich vlastníky, odstraňte nepoužívané a dlouhodobé přihlašovací údaje, ověřte protokolování auditu, zablokujte veřejné buckety, zkontrolujte nejširší pravidla firewallu a oprávnění IAM, zjistěte mezery v produkčních zálohách a opravte každý veřejný koncový bod bez vlastníka. Ke každému zjištění přiřaďte vlastníka a termín.

Dny 31 až 60: udělejte základ opakovatelným

Přesuňte konfiguraci sítě, identit a úloh do revidované infrastruktury jako kódu a do dodávání přes GitOps. Zaveďte Workload Identity, privátní uzly, Pod Security na úrovni restricted, kontroly důvěryhodných image, centralizované protokoly a upozornění na nejdůležitější změny.

Dny 61 až 90: prokažte účinnost a udržte ji

Proveďte testy obnovy a simulační cvičení incidentu (tabletop), zkontrolujte privilegovaný přístup a vypršení výjimek, znovu proskenujte image a závislosti, ověřte, že vlastníci dostávají upozornění, a změřte zbývající mezery. Zařaďte kontroly do pravidelného cyklu revizí dřív, než důkazy zastarají.

Použijte tento kontrolní seznam jako výchozí bod. Snow Tree může tento základ zavést v rámci provozu spravované platformy nebo cílené konzultační zakázky.

Spravovaná platforma · Konzultace

Oficiální zdroje

Když se změní výchozí nastavení platformy nebo možnosti produktů, považujte aktuální doporučení Googlu za technický zdroj pravdy.

• Google Cloud: Doporučené postupy pro posílení zabezpečení clusteru GKE
• Google Cloud: Doporučené postupy zabezpečení GKE