--- title: "Checklista för säkerhetshärdning av GCP | Snow Tree" url: "https://www.snow-tree.com/sv/gcp-security-hardening/" --- Säker GCP-infrastruktur # Checklista för säkerhetshärdning av GCP för små och medelstora team En praktisk baslinje för team som kör produktionsarbetsbelastningar på Google Cloud utan en egen säkerhetsavdelning. Börja där de mest sannolika vägarna till en allvarlig incident är lättast att minska. ## På den här sidan 1. [Vanliga hotvägar i GCP](https://www.snow-tree.com/sv/#threat-paths) 2. [Identitet och åtkomst](https://www.snow-tree.com/sv/#identity) 3. [Nätverk och edge](https://www.snow-tree.com/sv/#network) 4. [Data och hemligheter](https://www.snow-tree.com/sv/#data) 5. [GKE-härdning](https://www.snow-tree.com/sv/#gke) 6. [Detektering och återhämtning](https://www.snow-tree.com/sv/#detection) 7. [En prioriterad checklista för 30, 60 och 90 dagar](https://www.snow-tree.com/sv/#checklist) 8. [Officiella referenser](https://www.snow-tree.com/sv/#references) ## Vanliga hotvägar i GCP De flesta molnincidenter börjar med en liten lucka i ansvar eller konfiguration. Leta efter de här vägarna innan en angripare gör det. - En användare, ett tjänstkonto eller en arbetsbelastningsidentitet med för breda behörigheter kan göra en enda stulen autentiseringsuppgift till bred åtkomst i flera projekt. - En exponerad hanteringsslutpunkt, en felsökningsport eller en för tillåtande brandväggsregel kan kringgå alla kontroller som är utformade för normal applikationstrafik. - En offentlig lagringsbucket eller en för brett utformad signerad URL kan exponera kunddata utan att applikationen synligt har komprometterats. - Inaktuella arbetsbelastningar skapar en bestående risk när gamla avbildningar, bortglömda namnrymder, oanvända tjänstkonton och resurser utan ägare fortfarande kan driftsättas. - Saknade eller kortlivade granskningsunderlag gör det svårt att avgöra vem som ändrade en policy, när åtkomsten började och vilka data som nåddes. - En otestad säkerhetskopia är bara ett hopp. Misslyckade återställningar, ofullständig kvarhållning och otillgängliga krypteringsnycklar kan förvandla en säkerhetshändelse till en permanent förlust. ## Identitet och åtkomst Behandla identitet som det primära kontrollplanet. Varje människa, varje automatiseringsprocess och varje arbetsbelastning bör ha en egen identitet med ett avgränsat syfte. ### Gör resursgränsen tydlig Använd organisationen och mappar som skyddsräcken och dela upp utveckling, staging och produktion i separata projekt eller starkare förtroendegränser. Tillämpa organisationspolicyer på högsta praktiskt möjliga nivå, begränsa vilka tjänster som får användas och undvik att dela produktionsprojekt mellan produkter som inte hör ihop. ### Tilldela minsta möjliga roll i snävast möjliga omfång Föredra fördefinierade eller anpassade roller framför breda grundroller, tilldela dem till grupper och arbetsbelastningsidentiteter och använd IAM-villkor där ett resursnamn eller en tagg kan begränsa åtkomsten. Granska oanvända behörigheter och ta bort stående produktionsåtkomst som bara hör hemma i en break glass-process. ### Ta bort autentiseringsuppgifter med lång livslängd Använd Workload Identity Federation for GKE så att poddar får kortlivade autentiseringsuppgifter utan exporterade tjänstkontonycklar. Blockera skapande och uppladdning av nycklar med organisationspolicy där det är möjligt, inventera eventuella kvarvarande nycklar och larma om IAM-ändringar med hög risk i Cloud Audit Logs. ## Nätverk och edge Utgå från att något programfel förr eller senare kommer att kunna nås från nätverket. Begränsa vad det felet kan komma åt. ### Börja med att neka allt och lägg till namngivna vägar Använd VPC-brandväggsregler enligt principen om minsta behörighet och Kubernetes NetworkPolicies för poddtrafik. Dela upp miljöer i separata nätverk, dokumentera varje väg för inkommande trafik och ta bort breda felsökningsregler som tillåter hanteringsportar eller alla protokoll från stora adressintervall. ### Håll noder och kontrollplan privata Inaktivera externa IP-adresser på GKE-noder. Föredra den DNS-baserade privata slutpunkten för kontrollplanet, och när en IP-slutpunkt inte går att undvika, begränsa den med auktoriserade nätverk. Ge arbetsbelastningar en avsiktlig väg för utgående trafik i stället för bred internetåtkomst. ### Publicera bara avsiktligt valda offentliga tjänster Exponera applikationer via en granskad gateway eller lastbalanserare, inte via oavsiktligt exponerade podd- eller nodadresser. Terminera TLS med hanterade certifikat, begränsa värdar och sökvägar för inkommande trafik, tillämpa begränsningar för förfrågningar och anropsfrekvens och håll administrationsgränssnitt bakom identitetsmedveten åtkomst. ## Data och hemligheter Skydda data i vila, under överföring och vid användning, och bevisa sedan att du kan återställa dem. Att hitta och kartlägga data är en del av kontrollen. ### Förhindra oavsiktlig offentlig åtkomst Tillämpa förhindrande av offentlig åtkomst och enhetlig åtkomst på bucketnivå i Cloud Storage. Klassificera buckets efter känslighet, begränsa åtkomsten till objekt och nycklar, aktivera loggning för data med högt värde och använd kundhanterade krypteringsnycklar där din risk- eller efterlevnadsmodell kräver det. ### Håll hemligheter borta från avbildningar och källkod Lagra autentiseringsuppgifter i Secret Manager och ge en specifik arbetsbelastningsidentitet åtkomst till en specifik hemlighetsversion. Rotera hemligheter medvetet, undvik att kopiera dem till Git eller containeravbildningar och behandla inte vanliga Kubernetes Secrets som en fullständig skyddsgräns. ### Testa återställning, inte bara att säkerhetskopior skapas Definiera mål för återställningspunkt och återställningstid (RPO/RTO), behåll kopior utanför produktionens feldomän och skydda åtkomsten till säkerhetskopior och krypteringsnycklar mot arbetsbelastningsidentiteten. Återställ regelbundet enligt schema till en isolerad miljö, verifiera data och dokumentera hur lång tid det tog och eventuella manuella steg. ## GKE-härdning GKE skyddar det hanterade kontrollplanet, men klusterkonfiguration, namnrymder, admission-policyer och arbetsbelastningar är fortfarande ditt ansvar. ### Gör namnrymder till isoleringsgränsen Dela upp team och miljöer i namnrymder eller kluster, bind snävt avgränsade Kubernetes RBAC-roller där och tillämpa resurskvoter och NetworkPolicies. Undvik klusteromfattande skrivåtkomst för applikationsleverans och ge varje arbetsbelastning ett eget tjänstkonto när den behöver en egen identitet. ### Släpp bara in avbildningar och konfigurationer som du litar på Tillämpa Pod Security-standarden Restricted eller motsvarande Policy Controller-regler. Driftsätt avbildningar via oföränderlig digest, skanna dem efter sårbarheter, använd Binary Authorization där ursprunget spelar roll och avvisa oväntad värdåtkomst, behörighetseskalering och cluster-admin-bindningar. ### Ta bort onödiga containerbehörigheter Kör som icke-root, ta bort Linux-capabilities, använd ett skrivskyddat rotfilsystem där det är möjligt och tillämpa seccomp-profilen RuntimeDefault. Montera inte tjänstkontotoken utan behov, undvik privilegierade containrar och värdnamnrymder, håll nodernas tjänstkonto minimalt och använd Shielded Nodes tillsammans med Container-Optimized OS. ## Detektering och återhämtning Kontroller fallerar. Förlita dig på bevis och inövade åtgärder, inte på tron att ingen har gjort ett misstag. ### Samla in de bevis du kommer att behöva Spara Cloud Audit Logs samt GKE:s system- och arbetsbelastningsloggar på en central plats med en lagringstid som motsvarar dina utredningsbehov. Aktivera granskningsloggar för dataåtkomst selektivt för känsliga data, begränsa åtkomsten till loggar och registrera administrativa ändringar av IAM, brandvägg, lagring och klusterkonfiguration. ### Larma om ändringar som påverkar säkerheten Larma om offentligt exponerad lagring, breda brandväggs- eller IAM-ändringar, oväntade tjänstkontonycklar, avvisningar vid admission, exponering av kontrollplanet, upprepade autentiseringsfel, inaktiverad loggning, misslyckade säkerhetskopieringar och certifikat som håller på att gå ut. Skicka varje larm till en ägare tillsammans med stegen för att bekräfta eller avfärda det. ### Öva på incidenthanteringen Skriv korta runbooks för läckta autentiseringsuppgifter, exponerade data, komprometterade arbetsbelastningar och förlorade regioner eller projekt. Ange vem som kan godkänna begränsningsåtgärder, hur åtkomst återkallas, hur bevis bevaras och hur tjänsten återställs. Testa runbooks med de personer som ska använda dem. ## En prioriterad checklista för 30, 60 och 90 dagar Om du utgår från en ofullständig baslinje, ordna arbetet så att exponeringen minskar först och senare granskningar blir repeterbara. ### Dag 1 till 30: täpp till de uppenbara vägarna Inventera projekt och ägare, ta bort oanvända och långlivade autentiseringsuppgifter, bekräfta granskningsloggning, blockera offentliga buckets, granska de bredaste brandväggsreglerna och IAM-tilldelningarna, identifiera luckor i säkerhetskopieringen av produktion och åtgärda alla offentliga slutpunkter utan ägare. Tilldela en ägare och ett förfallodatum till varje fynd. ### Dag 31 till 60: gör baslinjen repeterbar Flytta konfigurationen av nätverk, identitet och arbetsbelastningar till granskad infrastruktur som kod och GitOps-leverans. Inför Workload Identity, privata noder, Pod Security med standarden Restricted, kontroller av betrodda avbildningar, centraliserade loggar och larm för de ändringar som betyder mest. ### Dag 61 till 90: bevisa och upprätthåll det Kör återställningstester och en tabletop-övning för incidenter, granska privilegierad åtkomst och när undantag löper ut, skanna avbildningar och beroenden igen, verifiera att ägare får larm och mät de luckor som återstår. Lägg in kontrollerna i en återkommande granskningscykel innan bevisen blir inaktuella. Använd den här checklistan som utgångspunkt. Snow Tree kan införa baslinjen genom drift av en hanterad plattform eller ett fokuserat konsultuppdrag. [Hanterad plattform](https://www.snow-tree.com/sv/managed-platform/) [Konsulttjänster](https://www.snow-tree.com/sv/consulting/) ## Officiella referenser Använd Googles aktuella vägledning som den auktoritativa tekniska källan när plattformens standardinställningar eller produktfunktioner ändras. - [Google Cloud: Bästa metoder för att härda ditt GKE-kluster](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster) - [Google Cloud: Bästa metoder för GKE-säkerhet](https://docs.cloud.google.com/docs/security/gke-security-bps) Hanterad plattform ## Låt Snow Tree bygga, hosta och drifta programvaran. [Starta ett projekt](mailto:support+snow-tree-platform-1-issue-@gitlab.snow-tree.com?subject=Snow%20Tree%20project)