--- title: "Checklist voor GCP-beveiligingshardening | Snow Tree" url: "https://www.snow-tree.com/nl/gcp-security-hardening/" --- Beveiligde GCP-infrastructuur # Checklist voor GCP-beveiligingshardening voor kleine en middelgrote teams Een praktische basislijn voor teams die productieworkloads op Google Cloud draaien zonder eigen beveiligingsafdeling. Begin waar de meest waarschijnlijke routes naar een ernstig incident het eenvoudigst te beperken zijn. ## Op deze pagina 1. [Veelvoorkomende GCP-dreigingspaden](https://www.snow-tree.com/nl/#threat-paths) 2. [Identiteit en toegang](https://www.snow-tree.com/nl/#identity) 3. [Netwerk en edge](https://www.snow-tree.com/nl/#network) 4. [Gegevens en secrets](https://www.snow-tree.com/nl/#data) 5. [GKE-hardening](https://www.snow-tree.com/nl/#gke) 6. [Detectie en herstel](https://www.snow-tree.com/nl/#detection) 7. [Een geprioriteerde checklist voor 30, 60 en 90 dagen](https://www.snow-tree.com/nl/#checklist) 8. [Officiële referenties](https://www.snow-tree.com/nl/#references) ## Veelvoorkomende GCP-dreigingspaden De meeste cloudincidenten beginnen met een klein gat in eigenaarschap of configuratie. Zoek deze paden voordat een aanvaller dat doet. - Een gebruiker, serviceaccount of workloadidentiteit met te veel rechten kan van één gestolen set inloggegevens brede toegang over meerdere projecten maken. - Een openlijk bereikbaar beheereindpunt, een debugpoort of een te ruime firewallregel kan elke maatregel omzeilen die voor normaal applicatieverkeer is ontworpen. - Een openbare opslagbucket of een ondertekende URL met een te ruime reikwijdte kan klantgegevens openbaar maken zonder dat de applicatie zichtbaar is gecompromitteerd. - Verouderde workloads vormen een blijvend risico wanneer oude images, vergeten namespaces, ongebruikte serviceaccounts en resources zonder eigenaar nog steeds kunnen worden geïmplementeerd. - Ontbrekend of kort bewaard auditbewijs maakt het moeilijk vast te stellen wie een beleid heeft gewijzigd, wanneer de toegang begon en welke gegevens zijn bereikt. - Een ongeteste back-up is niet meer dan hoop. Mislukte herstelacties, onvolledige retentie en ontoegankelijke versleutelingssleutels kunnen een beveiligingsgebeurtenis veranderen in permanent verlies. ## Identiteit en toegang Behandel identiteit als het primaire controlevlak. Elke persoon, elk automatiseringsproces en elke workload moet een eigen identiteit hebben met een afgebakend doel. ### Maak de resourcegrens expliciet Gebruik de organisatie en mappen voor vangrails en scheid ontwikkeling, staging en productie in aparte projecten of sterkere vertrouwensgrenzen. Pas organisatiebeleid toe op het hoogste haalbare niveau, beperk het gebruik van services en deel productieprojecten niet tussen producten die niets met elkaar te maken hebben. ### Ken de minimale rol toe op het kleinste bereik Geef de voorkeur aan vooraf gedefinieerde of aangepaste rollen boven brede basisrollen, ken ze toe aan groepen en workloadidentiteiten, en gebruik IAM-voorwaarden waar een resourcenaam of tag de toegang kan beperken. Controleer ongebruikte rechten en verwijder permanente productietoegang die alleen in een break-glass-proces thuishoort. ### Verwijder inloggegevens met een lange levensduur Gebruik Workload Identity Federation for GKE zodat pods kortlevende inloggegevens krijgen zonder geëxporteerde serviceaccountsleutels. Blokkeer het maken en uploaden van sleutels waar mogelijk met organisatiebeleid, inventariseer alle resterende sleutels en stel meldingen in voor risicovolle IAM-wijzigingen in Cloud Audit Logs. ## Netwerk en edge Ga ervan uit dat een fout in een applicatie vroeg of laat via het netwerk bereikbaar wordt. Beperk waartoe die fout toegang heeft. ### Begin met weigeren en sta benoemde paden toe Gebruik VPC-firewallregels volgens het principe van minimale rechten en Kubernetes NetworkPolicies voor podverkeer. Scheid omgevingen in afzonderlijke netwerken, documenteer elk ingresspad en verwijder brede debugregels die beheerpoorten of alle protocollen vanuit grote adresbereiken toestaan. ### Houd knooppunten en controlevlakken privé Schakel externe IP-adressen op GKE-knooppunten uit. Geef de voorkeur aan het op DNS gebaseerde privé-eindpunt van het controlevlak en beperk een IP-eindpunt, als dat onvermijdelijk is, met geautoriseerde netwerken. Geef workloads een bewust gekozen egresspad in plaats van brede internettoegang. ### Publiceer alleen bewust gekozen openbare services Maak applicaties toegankelijk via een gecontroleerde gateway of load balancer, niet via toevallige pod- of knooppuntadressen. Termineer TLS met beheerde certificaten, beperk ingresshosts en -paden, pas limieten voor verzoeken en verzoekfrequentie toe en plaats beheerinterfaces achter identiteitsbewuste toegang. ## Gegevens en secrets Bescherm gegevens in rust, tijdens overdracht en tijdens gebruik, en bewijs vervolgens dat u ze kunt herstellen. Gegevensdetectie maakt deel uit van de maatregel. ### Voorkom onbedoelde publieke toegang Dwing preventie van openbare toegang en uniforme toegang op bucketniveau af in Cloud Storage. Classificeer buckets op basis van gevoeligheid, beperk de toegang tot objecten en sleutels, schakel logboekregistratie in voor waardevolle gegevens en gebruik door de klant beheerde versleutelingssleutels waar uw risico- of compliancemodel dat vereist. ### Houd secrets buiten images en broncode Sla inloggegevens op in Secret Manager en verleen toegang aan een specifieke workloadidentiteit en secretversie. Roteer secrets bewust, kopieer ze niet naar Git of containerimages en beschouw gewone Kubernetes Secrets niet als een volledige beschermingsgrens. ### Test herstel, niet alleen het maken van back-ups Leg doelen vast voor herstelpunt en hersteltijd (RPO/RTO), bewaar kopieën buiten het foutdomein van productie en bescherm de toegang tot back-ups en versleutelingssleutels tegen de workloadidentiteit. Herstel volgens een vast schema naar een geïsoleerde omgeving, controleer de gegevens en leg de benodigde tijd en eventuele handmatige stappen vast. ## GKE-hardening GKE beveiligt het beheerde controlevlak, maar uw clusterconfiguratie, namespaces, admission-beleid en workloads blijven uw verantwoordelijkheid. ### Maak namespaces tot de afgesproken isolatiegrens Verdeel teams en omgevingen over namespaces of clusters, koppel daar nauw afgebakende Kubernetes RBAC-rollen aan en pas resourcequota en NetworkPolicies toe. Vermijd clusterbrede schrijftoegang voor applicatie-oplevering en geef elke workload een eigen serviceaccount wanneer die een aparte identiteit nodig heeft. ### Laat alleen images en configuraties toe die u vertrouwt Dwing de Pod Security-standaard Restricted of gelijkwaardige Policy Controller-regels af. Implementeer images op basis van een onveranderlijke digest, scan ze op kwetsbaarheden, gebruik Binary Authorization waar herkomst belangrijk is en weiger onverwachte hosttoegang, escalatie van bevoegdheden en cluster-admin-bindingen. ### Verwijder onnodige containerbevoegdheden Draai containers als niet-root, verwijder Linux-capabilities, gebruik waar mogelijk een alleen-lezen rootbestandssysteem en pas het seccomp-profiel RuntimeDefault toe. Koppel het serviceaccounttoken alleen aan als dat nodig is, vermijd geprivilegieerde containers en host-namespaces, houd het serviceaccount van de knooppunten minimaal en gebruik Shielded Nodes plus Container-Optimized OS. ## Detectie en herstel Maatregelen falen. Vertrouw op bewijs en geoefende acties, niet op de overtuiging dat niemand een fout heeft gemaakt. ### Verzamel het bewijs dat u nodig zult hebben Bewaar Cloud Audit Logs en GKE-systeem- en workloadlogboeken op een centrale bestemming met een bewaartermijn die past bij uw onderzoeksbehoeften. Schakel auditlogboeken voor gegevenstoegang selectief in voor gevoelige gegevens, beperk de toegang tot logboeken en registreer beheerwijzigingen aan IAM, firewall, opslag en clusterconfiguratie. ### Stel meldingen in voor wijzigingen die de beveiliging raken Stel meldingen in voor openbaar blootgestelde opslag, brede firewall- of IAM-wijzigingen, onverwachte serviceaccountsleutels, admission-weigeringen, blootstelling van het controlevlak, herhaalde authenticatiefouten, uitgeschakelde logboekregistratie, mislukte back-ups en verlopende certificaten. Stuur elke melding naar een eigenaar, met de stappen om deze te bevestigen of af te wijzen. ### Oefen de respons Schrijf korte runbooks voor gelekte inloggegevens, openbaar geworden gegevens, gecompromitteerde workloads en verloren regio's of projecten. Vermeld wie inperking mag autoriseren, hoe u toegang intrekt, hoe u bewijs veiligstelt en hoe u de service herstelt. Test de runbooks met de mensen die ze gaan gebruiken. ## Een geprioriteerde checklist voor 30, 60 en 90 dagen Als u begint vanuit een onvolledige basislijn, plan het werk dan zo dat eerst de blootstelling afneemt en latere beoordelingen herhaalbaar worden. ### Dag 1 tot en met 30: dicht de voor de hand liggende paden Inventariseer projecten en eigenaren, verwijder ongebruikte en langlevende inloggegevens, controleer of auditlogging actief is, blokkeer openbare buckets, beoordeel de ruimste firewallregels en IAM-toekenningen, breng hiaten in productieback-ups in kaart en pak elk openbaar eindpunt zonder eigenaar aan. Wijs aan elke bevinding een eigenaar en een deadline toe. ### Dag 31 tot en met 60: maak de basislijn herhaalbaar Breng netwerk-, identiteits- en workloadconfiguratie onder in beoordeelde infrastructure as code en GitOps-oplevering. Voer Workload Identity, privéknooppunten, Pod Security met de standaard Restricted, controles op vertrouwde images, gecentraliseerde logboeken en meldingen in voor de wijzigingen die er het meest toe doen. ### Dag 61 tot en met 90: toon het aan en houd het in stand Voer hersteltests en een tabletopoefening voor incidenten uit, beoordeel geprivilegieerde toegang en het verlopen van uitzonderingen, scan images en afhankelijkheden opnieuw, controleer of eigenaren meldingen ontvangen en meet de resterende hiaten. Neem de controles op in een terugkerende beoordelingscyclus voordat het bewijs verouderd raakt. Gebruik deze checklist als uitgangspunt. Snow Tree kan de basislijn invoeren via de exploitatie van een beheerd platform of via een gericht adviestraject. [Beheerd platform](https://www.snow-tree.com/nl/managed-platform/) [Advies](https://www.snow-tree.com/nl/consulting/) ## Officiële referenties Gebruik de actuele richtlijnen van Google als gezaghebbende technische bron wanneer platformstandaarden of productmogelijkheden veranderen. - [Google Cloud: Best practices voor het hardenen van uw GKE-cluster](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster) - [Google Cloud: Best practices voor GKE-beveiliging](https://docs.cloud.google.com/docs/security/gke-security-bps) Beheerd platform ## Laat Snow Tree uw software bouwen, hosten en beheren. [Start een project](mailto:support+snow-tree-platform-1-issue-@gitlab.snow-tree.com?subject=Snow%20Tree%20project)