Tjekliste til GCP-sikkerhedshærdning for små og mellemstore teams

Almindelige trusselsveje i GCP

De fleste cloudhændelser begynder med et lille hul i ejerskab eller konfiguration. Se efter disse veje, før en angriber gør det.

• En bruger, tjenestekonto eller workloadidentitet med for mange tilladelser kan forvandle ét stjålet sæt legitimationsoplysninger til bred adgang på tværs af projekter.
• Et eksponeret administrationsslutpunkt, en fejlfindingsport eller en for tilladende firewallregel kan omgå alle kontroller, der er designet til normal applikationstrafik.
• En offentlig lagerbucket eller en for bredt afgrænset signeret URL kan afsløre kundedata, uden at applikationen synligt er kompromitteret.
• Forældede workloads skaber en varig risiko, når gamle images, glemte namespaces, ubrugte tjenestekonti og ressourcer uden ejer fortsat kan udrulles.
• Manglende eller kortlivet revisionsdokumentation gør det svært at fastslå, hvem der ændrede en politik, hvornår adgangen begyndte, og hvilke data der blev tilgået.
• En utestet backup er kun et håb. Mislykkede gendannelser, ufuldstændig opbevaring og utilgængelige krypteringsnøgler kan gøre en sikkerhedshændelse til et permanent tab.

Identitet og adgang

Behandl identitet som det primære kontrolplan. Hvert menneske, hver automatiseringsproces og hver workload bør have sin egen identitet med et afgrænset formål.

Gør ressourcegrænsen eksplicit

Brug organisationen og mapper til sikkerhedsrammer, og adskil udvikling, staging og produktion i separate projekter eller stærkere tillidsgrænser. Anvend organisationspolitikker på det højeste praktisk mulige niveau, begræns brugen af tjenester, og undgå at dele produktionsprojekter mellem produkter, der ikke hører sammen.

Tildel den mindste rolle med det snævreste omfang

Foretræk foruddefinerede eller tilpassede roller frem for brede basisroller, tildel dem til grupper og workloadidentiteter, og brug IAM-betingelser, hvor et ressourcenavn eller et tag kan indsnævre adgangen. Gennemgå ubrugte tilladelser, og fjern stående produktionsadgang, der kun hører hjemme i en break glass-proces.

Fjern langlivede legitimationsoplysninger

Brug Workload Identity Federation for GKE, så pods får kortlivede legitimationsoplysninger uden eksporterede tjenestekontonøgler. Bloker oprettelse og upload af nøgler med organisationspolitik, hvor det er muligt, lav en oversigt over eventuelle resterende nøgler, og opsæt advarsler om højrisiko-IAM-ændringer i Cloud Audit Logs.

Netværk og edge

Gå ud fra, at en eller anden applikationsfejl før eller siden vil kunne nås fra netværket. Begræns, hvad den fejl kan få adgang til.

Start med at afvise alt, og tilføj navngivne stier

Brug VPC-firewallregler efter princippet om mindste rettighed og Kubernetes NetworkPolicies til pod-trafik. Adskil miljøer i separate netværk, dokumentér hver ingress-sti, og fjern brede debugregler, der tillader administrationsporte eller alle protokoller fra store adresseområder.

Hold noder og kontrolplaner private

Deaktiver eksterne IP-adresser på GKE-noder. Foretræk det DNS-baserede private kontrolplanslutpunkt, og begræns det med autoriserede netværk, når et IP-slutpunkt ikke kan undgås. Giv workloads en bevidst valgt sti til udgående trafik i stedet for bred internetadgang.

Udgiv kun bevidst valgte offentlige tjenester

Eksponer applikationer via en gennemgået gateway eller load balancer, ikke via tilfældige pod- eller nodeadresser. Terminer TLS med administrerede certifikater, begræns ingress-værter og -stier, anvend grænser for anmodninger og anmodningsrate, og hold administrationsgrænseflader bag identitetsbaseret adgang.

Data og hemmeligheder

Beskyt data i hvile, under overførsel og under brug, og bevis derefter, at du kan gendanne dem. At finde og kortlægge data er en del af kontrollen.

Undgå utilsigtet offentlig adgang

Håndhæv forebyggelse af offentlig adgang og ensartet adgang på bucketniveau i Cloud Storage. Klassificer buckets efter følsomhed, begræns adgangen til objekter og nøgler, aktiver logning for data af høj værdi, og brug kundeadministrerede krypteringsnøgler, hvor din risiko- eller compliancemodel kræver det.

Hold hemmeligheder ude af images og kildekode

Gem legitimationsoplysninger i Secret Manager, og giv en bestemt workloadidentitet adgang til en bestemt hemmelighedsversion. Roter hemmeligheder bevidst, undgå at kopiere dem ind i Git eller containerimages, og betragt ikke almindelige Kubernetes Secrets som en fuldstændig beskyttelsesgrænse.

Test gendannelse, ikke kun oprettelse af backup

Fastlæg mål for gendannelsespunkt og gendannelsestid (RPO/RTO), opbevar kopier uden for produktionens fejldomæne, og beskyt adgangen til backup og krypteringsnøgler mod workloadidentiteten. Gendan til et isoleret miljø efter en fast plan, verificer dataene, og registrer den forløbne tid og eventuelle manuelle trin.

GKE-hærdning

GKE sikrer det administrerede kontrolplan, men klyngekonfiguration, namespaces, admission-politikker og workloads er stadig dit ansvar at styre.

Gør namespaces til den aftalte isolationsgrænse

Adskil teams og miljøer i namespaces eller klynger, bind snævre Kubernetes RBAC-roller dér, og anvend ressourcekvoter og NetworkPolicies. Undgå klyngedækkende skriveadgang til udrulning af applikationer, og giv hver workload sin egen tjenestekonto, når den har brug for en særskilt identitet.

Tillad kun images og konfigurationer, du har tillid til

Håndhæv Pod Security-standarden Restricted eller tilsvarende Policy Controller-regler. Udrul images via uforanderlige digests, scan dem for sårbarheder, brug Binary Authorization, hvor herkomst er vigtig, og afvis uventet værtsadgang, privilegieeskalering og cluster-admin-bindinger.

Fjern unødvendige containerrettigheder

Kør som ikke-root, fjern Linux-capabilities, brug et skrivebeskyttet rodfilsystem, hvor det er muligt, og anvend seccomp-profilen RuntimeDefault. Monter ikke tjenestekontotokenet uden behov, undgå privilegerede containere og værtsnamespaces, hold nodernes tjenestekonto minimal, og brug Shielded Nodes sammen med Container-Optimized OS.

Detektion og genopretning

Kontroller svigter. Stol på dokumentation og indøvede handlinger, ikke på tilliden til, at ingen har begået en fejl.

Indsaml den dokumentation, du får brug for

Opbevar Cloud Audit Logs samt GKE-system- og workloadlogs på en central destination med en opbevaringsperiode, der matcher dine behov for undersøgelser. Aktivér auditlogs for dataadgang selektivt for følsomme data, begræns adgangen til logs, og registrer administrative ændringer af IAM-, firewall-, lager- og klyngekonfiguration.

Opsæt advarsler om ændringer med sikkerhedsmæssig betydning

Opsæt advarsler om offentligt eksponeret lager, brede firewall- eller IAM-ændringer, uventede tjenestekontonøgler, afvisninger fra admission control, eksponering af kontrolplanet, gentagne godkendelsesfejl, deaktiveret logning, mislykkede sikkerhedskopier og certifikater, der er ved at udløbe. Send hver advarsel til en ejer sammen med trinene til at bekræfte eller afvise den.

Øv responsen

Skriv korte runbooks for lækkede legitimationsoplysninger, offentligt eksponerede data, kompromitterede workloads og mistede regioner eller projekter. Angiv, hvem der kan godkende inddæmning, hvordan adgang tilbagekaldes, hvordan beviser bevares, og hvordan tjenesten genoprettes. Test runbooks med de personer, der skal bruge dem.

En prioriteret tjekliste for 30, 60 og 90 dage

Hvis du starter fra en ufuldstændig baseline, bør du lægge arbejdet i en rækkefølge, der først reducerer eksponeringen og gør senere gennemgange gentagelige.

Dag 1 til 30: luk de åbenlyse veje

Lav en oversigt over projekter og ejere, fjern ubrugte og langlivede legitimationsoplysninger, bekræft revisionslogning, bloker offentlige buckets, gennemgå de bredeste firewallregler og IAM-tildelinger, identificer huller i backup af produktion, og ret alle offentlige slutpunkter uden ejer. Tildel en ejer og en frist til hvert fund.

Dag 31 til 60: gør baselinen gentagelig

Flyt netværks-, identitets- og workloadkonfiguration over i gennemgået infrastruktur som kode og GitOps-leverancer. Indfør Workload Identity, private noder, Pod Security med standarden Restricted, kontrol af betroede images, centraliserede logs og advarsler for de ændringer, der betyder mest.

Dag 61 til 90: bevis det, og hold det ved lige

Kør gendannelsestests og en tabletop-øvelse for hændelser, gennemgå privilegeret adgang og udløb af undtagelser, scan images og afhængigheder igen, bekræft, at ejere modtager advarsler, og mål de huller, der er tilbage. Læg kontrollerne ind i en tilbagevendende gennemgangscyklus, før dokumentationen bliver forældet.

Brug denne tjekliste som udgangspunkt. Snow Tree kan indføre baselinen gennem drift af en administreret platform eller et fokuseret konsulentforløb.

Administreret platform · Konsulentydelser

Officielle referencer

Brug Googles aktuelle vejledning som den autoritative tekniske kilde, når platformens standarder eller produktfunktioner ændres.

• Google Cloud: Bedste fremgangsmåder til at hærde din GKE-klynge
• Google Cloud: Bedste praksis for GKE-sikkerhed