Sjekkliste for sikkerhetsherding av GCP for små og mellomstore team

Vanlige trusselveier i GCP

De fleste skyhendelser begynner med et lite hull i eierskap eller konfigurasjon. Se etter disse veiene før en angriper gjør det.

• En bruker, tjenestekonto eller arbeidsbelastningsidentitet med for vide tillatelser kan gjøre én stjålet legitimasjon til bred tilgang på tvers av prosjekter.
• Et eksponert administrasjonsendepunkt, en feilsøkingsport eller en for åpen brannmurregel kan omgå alle kontroller som er utformet for normal applikasjonstrafikk.
• En offentlig lagringsbøtte eller en for vidt avgrenset signert URL kan eksponere kundedata uten at applikasjonen synlig er kompromittert.
• Foreldede arbeidsbelastninger skaper varig risiko når gamle avbildninger, glemte navneområder, ubrukte tjenestekontoer og ressurser uten eier fortsatt kan distribueres.
• Manglende eller kortlivet revisjonsdokumentasjon gjør det vanskelig å fastslå hvem som endret en policy, når tilgangen begynte og hvilke data som ble nådd.
• En utestet sikkerhetskopi er bare et håp. Mislykkede gjenopprettinger, ufullstendig oppbevaring og utilgjengelige krypteringsnøkler kan gjøre en sikkerhetshendelse til et permanent tap.

Identitet og tilgang

Behandle identitet som det primære kontrollplanet. Hvert menneske, hver automatiseringsprosess og hver arbeidsbelastning bør ha sin egen identitet med et avgrenset formål.

Gjør ressursgrensen eksplisitt

Bruk organisasjonen og mapper til sikkerhetsrammer, og skill utvikling, staging og produksjon i egne prosjekter eller sterkere tillitsgrenser. Bruk organisasjonspolicyer på det høyeste praktisk mulige nivået, begrens hvilke tjenester som kan brukes, og unngå å dele produksjonsprosjekter mellom produkter som ikke hører sammen.

Tildel minste rolle med snevrest mulig omfang

Foretrekk forhåndsdefinerte eller tilpassede roller fremfor brede grunnleggende roller, tildel dem til grupper og arbeidsbelastningsidentiteter, og bruk IAM-betingelser der et ressursnavn eller en tagg kan begrense tilgangen. Gå gjennom ubrukte tillatelser, og fjern stående produksjonstilgang som bare hører hjemme i en break glass-prosess.

Fjern langlivet legitimasjon

Bruk Workload Identity Federation for GKE slik at pods får kortlivet legitimasjon uten eksporterte tjenestekontonøkler. Blokker oppretting og opplasting av nøkler med organisasjonspolicy der det er mulig, før oversikt over eventuelle gjenværende nøkler, og varsle om IAM-endringer med høy risiko i Cloud Audit Logs.

Nettverk og edge

Gå ut fra at en eller annen applikasjonsfeil før eller siden vil kunne nås fra nettverket. Begrens hva den feilen får tilgang til.

Start med å avvise alt, og legg til navngitte stier

Bruk VPC-brannmurregler etter prinsippet om minste privilegium og Kubernetes NetworkPolicies for pod-trafikk. Skill miljøer i separate nettverk, dokumenter hver vei for inngående trafikk, og fjern brede feilsøkingsregler som tillater administrasjonsporter eller alle protokoller fra store adresseområder.

Hold noder og kontrollplan private

Deaktiver eksterne IP-adresser på GKE-noder. Foretrekk det DNS-baserte private endepunktet for kontrollplanet, og når et IP-endepunkt ikke kan unngås, begrens det med autoriserte nettverk. Gi arbeidsbelastninger en bevisst valgt vei for utgående trafikk i stedet for bred internettilgang.

Publiser bare bevisst valgte offentlige tjenester

Eksponer applikasjoner gjennom en gjennomgått gateway eller lastbalanserer, ikke via tilfeldige pod- eller nodeadresser. Terminer TLS med administrerte sertifikater, begrens verter og stier for inngående trafikk, bruk grenser for forespørsler og forespørselsrate, og hold administrasjonsgrensesnitt bak identitetsbasert tilgang.

Data og hemmeligheter

Beskytt data i ro, under overføring og i bruk, og bevis deretter at du kan gjenopprette dem. Å finne og kartlegge dataene er en del av kontrollen.

Forhindre utilsiktet offentlig tilgang

Håndhev forhindring av offentlig tilgang og enhetlig tilgang på bøttenivå i Cloud Storage. Klassifiser bøtter etter sensitivitet, begrens tilgangen til objekter og nøkler, aktiver logging for data av høy verdi, og bruk kundeadministrerte krypteringsnøkler der risiko- eller samsvarsmodellen din krever det.

Hold hemmeligheter utenfor avbildninger og kildekode

Lagre legitimasjon i Secret Manager, og gi en bestemt arbeidsbelastningsidentitet tilgang til en bestemt hemmelighetsversjon. Roter hemmeligheter bevisst, unngå å kopiere dem inn i Git eller containeravbildninger, og ikke behandle vanlige Kubernetes Secrets som en fullstendig beskyttelsesgrense.

Test gjenoppretting, ikke bare at sikkerhetskopier lages

Definer mål for gjenopprettingspunkt og gjenopprettingstid (RPO/RTO), oppbevar kopier utenfor produksjonens feildomene, og beskytt tilgangen til sikkerhetskopier og krypteringsnøkler mot arbeidsbelastningsidentiteten. Gjenopprett til et isolert miljø etter en fast plan, verifiser dataene og registrer medgått tid og eventuelle manuelle trinn.

GKE-herding

GKE sikrer det administrerte kontrollplanet, men klyngekonfigurasjon, navneområder, admission-policyer og arbeidsbelastninger er fortsatt ditt ansvar å styre.

Gjør navneområder til den avtalte isolasjonsgrensen

Skill team og miljøer i navneområder eller klynger, bind snevre Kubernetes RBAC-roller der, og bruk ressurskvoter og NetworkPolicies. Unngå klyngeomfattende skrivetilgang for applikasjonsleveranser, og gi hver arbeidsbelastning sin egen tjenestekonto når den trenger en egen identitet.

Slipp bare inn avbildninger og konfigurasjoner du stoler på

Håndhev Pod Security-standarden Restricted eller tilsvarende Policy Controller-regler. Distribuer avbildninger via uforanderlig digest, skann dem for sårbarheter, bruk Binary Authorization der opprinnelse er viktig, og avvis uventet vertstilgang, rettighetseskalering og cluster-admin-bindinger.

Fjern unødvendige containerrettigheter

Kjør som ikke-root, fjern Linux-capabilities, bruk et skrivebeskyttet rotfilsystem der det er mulig, og bruk seccomp-profilen RuntimeDefault. Ikke monter tjenestekontotokenet uten behov, unngå privilegerte containere og vertsnavneområder, hold nodenes tjenestekonto minimal, og bruk Shielded Nodes sammen med Container-Optimized OS.

Deteksjon og gjenoppretting

Kontroller svikter. Stol på dokumentasjon og innøvde handlinger, ikke på tilliten til at ingen har gjort en feil.

Samle dokumentasjonen du kommer til å trenge

Oppbevar Cloud Audit Logs og GKE-system- og arbeidsbelastningslogger på et sentralt sted med en oppbevaringstid som samsvarer med undersøkelsesbehovene dine. Aktiver revisjonslogger for datatilgang selektivt for sensitive data, begrens tilgangen til logger, og registrer administrative endringer i IAM-, brannmur-, lagrings- og klyngekonfigurasjon.

Varsle om endringer med sikkerhetsmessig betydning

Varsle om offentlig eksponert lagring, brede brannmur- eller IAM-endringer, uventede tjenestekontonøkler, avvisninger fra admission control, eksponering av kontrollplanet, gjentatte autentiseringsfeil, deaktivert logging, mislykkede sikkerhetskopieringer og sertifikater som snart utløper. Send hvert varsel til en eier sammen med trinnene for å bekrefte eller avvise det.

Øv på hendelseshåndteringen

Skriv korte runbooks for lekket legitimasjon, eksponerte data, kompromitterte arbeidsbelastninger og tapte regioner eller prosjekter. Angi hvem som kan godkjenne inndemming, hvordan tilgang tilbakekalles, hvordan bevis bevares og hvordan tjenesten gjenopprettes. Test runbooks med personene som skal bruke dem.

En prioritert sjekkliste for 30, 60 og 90 dager

Hvis du starter fra en ufullstendig baseline, bør du legge opp arbeidet slik at eksponeringen reduseres først og senere gjennomganger blir repeterbare.

Dag 1 til 30: tett de åpenbare angrepsveiene

Kartlegg prosjekter og eiere, fjern ubrukt og langlivet legitimasjon, bekreft revisjonslogging, blokker offentlige bøtter, gå gjennom de bredeste brannmurreglene og IAM-tildelingene, identifiser hull i sikkerhetskopieringen av produksjon, og utbedre alle offentlige endepunkter uten eier. Tildel en eier og en frist for hvert funn.

Dag 31 til 60: gjør baselinen repeterbar

Flytt nettverks-, identitets- og arbeidsbelastningskonfigurasjon inn i gjennomgått infrastruktur som kode og GitOps-leveranser. Ta i bruk Workload Identity, private noder, Pod Security med standarden Restricted, kontroll av klarerte avbildninger, sentraliserte logger og varsler for endringene som betyr mest.

Dag 61 til 90: bevis det og oppretthold det

Kjør gjenopprettingstester og en tabletop-øvelse for hendelser, gå gjennom privilegert tilgang og utløp av unntak, skann avbildninger og avhengigheter på nytt, bekreft at eiere mottar varsler, og mål gapene som gjenstår. Legg kontrollene inn i en fast gjennomgangssyklus før dokumentasjonen blir utdatert.

Bruk denne sjekklisten som utgangspunkt. Snow Tree kan innføre baselinen gjennom drift av en administrert plattform eller et fokusert konsulentoppdrag.

Administrert plattform · Konsulenttjenester

Offisielle referanser

Bruk Googles gjeldende veiledning som den autoritative tekniske kilden når plattformstandarder eller produktfunksjoner endres.

• Google Cloud: Beste praksis for å herde din GKE-klynge
• Google Cloud: Beste praksis for GKE-sikkerhet