Säkerhetsrekommendationer för GCP-resurser (Google Cloud Platform)

Artikel
03/13/2024

Den här artikeln innehåller alla rekommendationer som du kan se i Microsoft Defender för molnet om du ansluter ett GCP-konto (Google Cloud Platform) med hjälp av sidan Miljöinställningar. Rekommendationerna som visas i din miljö baseras på de resurser som du skyddar och på din anpassade konfiguration.

Mer information om åtgärder som du kan vidta som svar på dessa rekommendationer finns i Åtgärda rekommendationer i Defender för molnet.

Din säkerhetspoäng baseras på antalet säkerhetsrekommendationer som du har slutfört. Om du vill bestämma vilka rekommendationer som ska lösas först kan du titta på allvarlighetsgraden för varje rekommendation och dess potentiella effekt på din säkerhetspoäng.

GCP-beräkningsrekommendationer

Virtuella datorer för beräkningsmotorn bör använda det containeroptimerade operativsystemet

Beskrivning: Den här rekommendationen utvärderar konfigurationsegenskapen för en nodpool för nyckel/värde-paret, "imageType": "COS".

Allvarlighetsgrad: Låg

Identifiering och åtgärd på slutpunkt konfigurationsproblem bör lösas på virtuella GCP-datorer

Beskrivning: Lös alla identifierade konfigurationsproblem med den installerade lösningen Slutpunktsidentifiering och svar (Identifiering och åtgärd på slutpunkt) för att skydda virtuella datorer från de senaste hoten och säkerhetsriskerna.
Obs! För närvarande gäller den här rekommendationen endast för resurser med Microsoft Defender för Endpoint (MDE) aktiverat.

Allvarlighetsgrad: Hög

Identifiering och åtgärd på slutpunkt lösning ska installeras på virtuella GCP-datorer

Beskrivning: Installera en lösning för slutpunktsidentifiering och svar (Identifiering och åtgärd på slutpunkt) för att skydda virtuella datorer. Identifiering och åtgärd på slutpunkt hjälper till att förhindra, identifiera, undersöka och svara på avancerade hot. Använd Microsoft Defender för servrar för att distribuera Microsoft Defender för Endpoint. Om resursen klassificeras som "Inte felfri" har den inte någon Identifiering och åtgärd på slutpunkt lösning som stöds installerad [Place Holder-länk – Läs mer]. Om du har en Identifiering och åtgärd på slutpunkt lösning installerad som inte kan identifieras av den här rekommendationen kan du undanta den.

Allvarlighetsgrad: Hög

Se till att "Blockera projektomfattande SSH-nycklar" är aktiverat för VM-instanser

Beskrivning: Vi rekommenderar att du använder instansspecifika SSH-nycklar i stället för att använda vanliga/delade projektomfattande SSH-nycklar för att få åtkomst till instanser. Projektomfattande SSH-nycklar lagras i Compute/Project-meta-data. Projektomfattande SSH-nycklar kan användas för att logga in på alla instanser i projektet. Med hjälp av projektomfattande SSH-nycklar underlättas SSH-nyckelhanteringen, men om de komprometteras utgör det en säkerhetsrisk som kan påverka alla instanser i projektet. Vi rekommenderar att du använder instansspecifika SSH-nycklar som kan begränsa attackytan om SSH-nycklarna komprometteras.

Allvarlighetsgrad: Medel

Se till att beräkningsinstanser startas med avskärmad virtuell dator aktiverad

Beskrivning: För att skydda mot avancerade hot och se till att startinläsaren och den inbyggda programvaran på dina virtuella datorer är signerade och otampererade rekommenderar vi att Beräkningsinstanser startas med avskärmad virtuell dator aktiverad. Avskärmade virtuella datorer är virtuella datorer (VM) på Google Cloud Platform som förstärkts av en uppsättning säkerhetskontroller som hjälper till att försvara mot rootkits och bootkits. Avskärmad virtuell dator erbjuder verifierbar integritet för dina vm-instanser för beräkningsmotorn, så du kan vara säker på att dina instanser inte har komprometterats av skadlig kod på start- eller kernelnivå eller rootkits. Den avskärmade virtuella datorns verifierbara integritet uppnås med hjälp av säker start, vTPM-aktiverad virtuell plattformsmodul (vTPM) och integritetsövervakning. Avskärmade VM-instanser kör inbyggd programvara som är signerad och verifierad med Hjälp av Googles certifikatutfärdare, vilket säkerställer att instansens inbyggda programvara är oförändrad och upprättar roten för förtroende för säker start. Integritetsövervakning hjälper dig att förstå och fatta beslut om tillståndet för dina vm-instanser och den avskärmade virtuella datorns vTPM aktiverar uppmätt start genom att utföra de mått som behövs för att skapa en känd bra startbaslinje, kallad integritetsprincipens baslinje. Baslinjen för integritetsprincipen används för jämförelse med mått från efterföljande VM-start för att avgöra om något har ändrats. Säker start hjälper till att säkerställa att systemet endast kör autentisk programvara genom att verifiera den digitala signaturen för alla startkomponenter och stoppa startprocessen om signaturverifieringen misslyckas.

Allvarlighetsgrad: Hög

Se till att "Aktivera anslutning till serieportar" inte är aktiverat för VM-instansen

Beskrivning: Interagera med en seriell port kallas ofta seriekonsolen, som liknar att använda ett terminalfönster, eftersom indata och utdata helt och hållet är i textläge och det finns inget grafiskt gränssnitt eller musstöd. Om du aktiverar den interaktiva seriekonsolen på en instans kan klienter försöka ansluta till den instansen från valfri IP-adress. Därför bör stöd för interaktiv seriekonsol inaktiveras. En virtuell datorinstans har fyra virtuella serieportar. Att interagera med en seriell port liknar att använda ett terminalfönster, eftersom indata och utdata helt och hållet är i textläge och det finns inget grafiskt gränssnitt eller musstöd. Instansens operativsystem, BIOS och andra entiteter på systemnivå skriver ofta utdata till serieportarna och kan acceptera indata som kommandon eller svar på frågor. Vanligtvis använder dessa entiteter på systemnivå den första serieporten (port 1) och seriell port 1 kallas ofta seriekonsolen. Den interaktiva seriekonsolen stöder inte IP-baserade åtkomstbegränsningar, till exempel IP-tillåtna listor. Om du aktiverar den interaktiva seriekonsolen på en instans kan klienter försöka ansluta till den instansen från valfri IP-adress. På så sätt kan vem som helst ansluta till den instansen om de känner till rätt SSH-nyckel, användarnamn, projekt-ID, zon och instansnamn. Därför bör stöd för interaktiv seriekonsol inaktiveras.

Allvarlighetsgrad: Medel

Se till att databasflaggan "log_duration" för Cloud SQL PostgreSQL-instansen är inställd på "på"

Beskrivning: Om du aktiverar inställningen log_hostname loggas varaktigheten för varje slutförd instruktion. Detta loggar inte frågans text och fungerar därför annorlunda än flaggan log_min_duration_statement. Det går inte att ändra den här parametern när sessionen har startats. Att övervaka den tid det tar att köra frågorna kan vara avgörande för att identifiera eventuella resursproblem och utvärdera serverns prestanda. Ytterligare steg som belastningsutjämning och användning av optimerade frågor kan vidtas för att säkerställa serverns prestanda och stabilitet. Den här rekommendationen gäller för PostgreSQL-databasinstanser.

Allvarlighetsgrad: Låg

Se till att databasflaggan "log_executor_stats" för Cloud SQL PostgreSQL-instansen är inställd på "off"

Beskrivning: PostgreSQL-utföraren ansvarar för att köra planen som överlämnats av PostgreSQL-planeraren. Kören bearbetar planen rekursivt för att extrahera den nödvändiga uppsättningen rader. Flaggan "log_executor_stats" styr inkluderingen av Prestandastatistik för PostgreSQL-kören i PostgreSQL-loggarna för varje fråga. Flaggan "log_executor_stats" möjliggör en rå profileringsmetod för loggning av prestandastatistik för PostgreSQL-köre, vilket även om det kan vara användbart för felsökning kan öka mängden loggar avsevärt och ha prestandakostnader. Den här rekommendationen gäller för PostgreSQL-databasinstanser.

Allvarlighetsgrad: Låg

Se till att databasflaggan "log_min_error_statement" för Cloud SQL PostgreSQL-instansen är inställd på Fel eller striktare

Beskrivning: Flaggan "log_min_error_statement" definierar den minsta allvarlighetsgrad för meddelanden som betraktas som en feluttryck. Meddelanden för felmeddelanden loggas med SQL-instruktionen. Giltiga värden är "DEBUG5", "DEBUG4", "DEBUG3", "DEBUG2", "DEBUG1", "INFO", "NOTICE", "WARNING", "ERROR", "LOG", "FATAL" och "PANIC". Varje allvarlighetsgrad innehåller de efterföljande nivåerna som nämns ovan. Se till att värdet FEL eller striktare anges. Granskning hjälper till att felsöka driftsproblem och tillåter även kriminalteknisk analys. Om "log_min_error_statement" inte är inställt på rätt värde kan det hända att meddelanden inte klassificeras som felmeddelanden på rätt sätt. Med tanke på allmänna loggmeddelanden som felmeddelanden skulle göra är det svårt att hitta faktiska fel och endast överväga strängare allvarlighetsnivåer eftersom felmeddelanden kan hoppa över faktiska fel för att logga sina SQL-instruktioner. Flaggan "log_min_error_statement" ska vara inställd på "ERROR" eller striktare. Den här rekommendationen gäller för PostgreSQL-databasinstanser.

Allvarlighetsgrad: Låg

Se till att databasflaggan "log_parser_stats" för Cloud SQL PostgreSQL-instansen är inställd på "off"

Beskrivning: PostgreSQL-planeraren/optimeraren ansvarar för att parsa och verifiera syntaxen för varje fråga som tas emot av servern. Om syntaxen är korrekt skapas ett "parsningsträd" annars genereras ett fel. Flaggan "log_parser_stats" styr införandet av parserprestandastatistik i PostgreSQL-loggarna för varje fråga. Flaggan "log_parser_stats" möjliggör en rå profileringsmetod för loggning av parserprestandastatistik, vilket även om det kan vara användbart för felsökning kan öka mängden loggar avsevärt och ha prestandaomkostnader. Den här rekommendationen gäller för PostgreSQL-databasinstanser.

Allvarlighetsgrad: Låg

Se till att databasflaggan "log_planner_stats" för Cloud SQL PostgreSQL-instansen är inställd på "off"

Beskrivning: Samma SQL-fråga kan köras på flera sätt och ändå ge olika resultat. PostgreSQL-planeraren/optimeraren ansvarar för att skapa en optimal körningsplan för varje fråga. Flaggan "log_planner_stats" styr inkluderingen av Prestandastatistik för PostgreSQL-planeraren i PostgreSQL-loggarna för varje fråga. Flaggan "log_planner_stats" möjliggör en rå profileringsmetod för loggning av Prestandastatistik för PostgreSQL-planerare, vilket även om det kan vara användbart för felsökning kan öka mängden loggar avsevärt och ha prestandakostnader. Den här rekommendationen gäller för PostgreSQL-databasinstanser.

Allvarlighetsgrad: Låg

Se till att databasflaggan "log_statement_stats" för Cloud SQL PostgreSQL-instansen är inställd på "off"

Beskrivning: Flaggan "log_statement_stats" styr inkluderingen av prestandastatistik från slutpunkt till slutpunkt för en SQL-fråga i PostgreSQL-loggarna för varje fråga. Detta kan inte aktiveras med annan modulstatistik (log_parser_stats, log_planner_stats, log_executor_stats). Flaggan "log_statement_stats" möjliggör en rå profileringsmetod för loggning av prestandastatistik från slutpunkt till slutpunkt för en SQL-fråga. Detta kan vara användbart för felsökning men kan öka mängden loggar avsevärt och ha prestandakostnader. Den här rekommendationen gäller för PostgreSQL-databasinstanser.

Allvarlighetsgrad: Låg

Kontrollera att Beräkningsinstanser inte har offentliga IP-adresser

Beskrivning: Beräkningsinstanser bör inte konfigureras för att ha externa IP-adresser. För att minska attackytan bör beräkningsinstanser inte ha offentliga IP-adresser. I stället bör instanser konfigureras bakom lastbalanserare för att minimera instansens exponering för Internet. Instanser som skapats av GKE bör undantas eftersom vissa av dem har externa IP-adresser och inte kan ändras genom att redigera instansinställningarna. Dessa virtuella datorer har namn som börjar med gke och är märkta goog-gke-node.

Allvarlighetsgrad: Hög

Kontrollera att instanser inte har konfigurerats för att använda standardtjänstkontot

Beskrivning: Vi rekommenderar att du konfigurerar instansen så att den inte använder standardkontot för Compute Engine-tjänsten eftersom den har rollen Redigerare i projektet. Standardkontot för Compute Engine-tjänsten har rollen Redigerare i projektet, vilket ger läs- och skrivåtkomst till de flesta Google Cloud Services. För att skydda mot privilegiereskaleringar om den virtuella datorn komprometteras och förhindra att en angripare får åtkomst till hela projektet rekommenderar vi att du inte använder standardtjänstkontot för Compute Engine. I stället bör du skapa ett nytt tjänstkonto och endast tilldela de behörigheter som behövs av din instans. Standardkontot för Compute Engine-tjänsten heter [PROJECT_NUMBER]- compute@developer.gserviceaccount.com. Virtuella datorer som skapats av GKE bör undantas. Dessa virtuella datorer har namn som börjar med gke och är märkta goog-gke-node.

Allvarlighetsgrad: Hög

Kontrollera att instanser inte har konfigurerats för att använda standardtjänstkontot med fullständig åtkomst till alla moln-API:er

Beskrivning: För att stödja principen om minsta behörighet och förhindra potentiell behörighetseskalering rekommenderar vi att instanser inte tilldelas standardtjänstkontot "Beräkningsmotorns standardtjänstkonto" med omfånget "Tillåt fullständig åtkomst till alla moln-API:er". Tillsammans med möjligheten att skapa, hantera och använda användarhanterade anpassade tjänstkonton, tillhandahåller Google Compute Engine standardtjänstkontot "Compute Engine default service account" för en instans för åtkomst till nödvändiga molntjänster. Rollen "Projektredigerare" tilldelas till "Standardtjänstkonto för Beräkningsmotor" och därför har det här tjänstkontot nästan alla funktioner för alla molntjänster förutom fakturering. Men när "Beräkningsmotorns standardtjänstkonto" har tilldelats till en instans kan det fungera i tre omfång.

Tillåt standardåtkomst: Tillåter endast minsta åtkomst som krävs för att köra en instans (minst privilegier).
Tillåt fullständig åtkomst till alla moln-API:er: Tillåt fullständig åtkomst till alla moln-API:er/tjänster (för mycket åtkomst).
Ange åtkomst för varje API: Gör att instansadministratören endast kan välja de API:er som behövs för att utföra specifika affärsfunktioner som förväntas av instansen När en instans har konfigurerats med "Beräkningsmotorns standardtjänstkonto" med omfånget "Tillåt fullständig åtkomst till alla moln-API:er", baserat på IAM-roller som tilldelats till användarens åtkomst till instansen, kan det göra det möjligt för användaren att utföra molnåtgärder/API-anrop som användaren inte ska utföra, vilket leder till en lyckad behörighetseskalering. Virtuella datorer som skapats av GKE bör undantas. Dessa virtuella datorer har namn som börjar med "gke-" och är märkta "goog-gke-node".

Allvarlighetsgrad: Medel

Kontrollera att IP-vidarebefordran inte är aktiverat på instanser

Beskrivning: Beräkningsmotorinstansen kan inte vidarebefordra ett paket om inte paketets käll-IP-adress matchar IP-adressen för instansen. På samma sätt levererar GCP inte ett paket vars mål-IP-adress skiljer sig från IP-adressen för den instans som tar emot paketet. Båda funktionerna krävs dock om du vill använda instanser för att dirigera paket. Vidarebefordran av datapaket bör inaktiveras för att förhindra dataförlust eller avslöjande av information. Compute Engine-instansen kan inte vidarebefordra ett paket om inte paketets käll-IP-adress matchar IP-adressen för instansen. På samma sätt levererar GCP inte ett paket vars mål-IP-adress skiljer sig från IP-adressen för den instans som tar emot paketet. Båda funktionerna krävs dock om du vill använda instanser för att dirigera paket. Om du vill aktivera den här käll- och mål-IP-kontrollen inaktiverar du fältet canIpForward, som gör att en instans kan skicka och ta emot paket med icke-matchande mål- eller käll-IP-adresser.

Allvarlighetsgrad: Medel

Kontrollera att databasflaggan "log_checkpoints" för Cloud SQL PostgreSQL-instansen är inställd på "på"

Beskrivning: Kontrollera att log_checkpoints databasflaggan för Cloud SQL PostgreSQL-instansen är inställd på på. Om du aktiverar log_checkpoints loggas kontrollpunkter och omstartspunkter i serverloggen. Viss statistik ingår i loggmeddelandena, inklusive antalet skrivna buffertar och den tid det tar att skriva dem. Den här parametern kan bara anges i postgresql.conf-filen eller på serverns kommandorad. Den här rekommendationen gäller för PostgreSQL-databasinstanser.

Allvarlighetsgrad: Låg

Kontrollera att databasflaggan "log_lock_waits" för Cloud SQL PostgreSQL-instansen är inställd på "på"

Beskrivning: Om du aktiverar flaggan "log_lock_waits" för en PostgreSQL-instans skapas en logg för alla sessionsvänte som tar längre tid än den tilldelade "deadlock_timeout"-tiden för att hämta ett lås. Tidsgränsen för dödläget definierar tiden för att vänta på ett lås innan du kontrollerar om det finns några villkor. Frekventa överkörningar vid dödlägestimeout kan vara en indikation på ett underliggande problem. Loggning av sådana väntetider på lås genom att aktivera flaggan log_lock_waits kan användas för att identifiera dåliga prestanda på grund av låsningsfördröjningar eller om en särskilt utformad SQL försöker svälta resurser genom att hålla lås under alltför lång tid. Den här rekommendationen gäller för PostgreSQL-databasinstanser.

Allvarlighetsgrad: Låg

Kontrollera att databasflaggan "log_min_duration_statement" för Cloud SQL PostgreSQL-instansen är inställd på -1

Beskrivning: Flaggan "log_min_duration_statement" definierar den minsta körningstiden för en instruktion i millisekunder där den totala varaktigheten för instruktionen loggas. Se till att "log_min_duration_statement" har inaktiverats, dvs. värdet -1 har angetts. Loggning av SQL-instruktioner kan innehålla känslig information som inte ska registreras i loggar. Den här rekommendationen gäller för PostgreSQL-databasinstanser.

Allvarlighetsgrad: Låg

Kontrollera att databasflaggan "log_min_messages" för Cloud SQL PostgreSQL-instansen är korrekt inställd

Beskrivning: Flaggan "log_min_error_statement" definierar den minsta allvarlighetsgrad för meddelanden som betraktas som en feluttryck. Meddelanden för felmeddelanden loggas med SQL-instruktionen. Giltiga värden är "DEBUG5", "DEBUG4", "DEBUG3", "DEBUG2", "DEBUG1", "INFO", "NOTICE", "WARNING", "ERROR", "LOG", "FATAL" och "PANIC". Varje allvarlighetsgrad innehåller de efterföljande nivåerna som nämns ovan. Obs! Om du vill inaktivera misslyckade loggningsinstruktioner ställer du in den här parametern på PANIC. ERROR anses vara inställningen för bästa praxis. Ändringar bör endast göras i enlighet med organisationens loggningsprincip. Granskning hjälper till att felsöka driftsproblem och tillåter även kriminalteknisk analys. Om "log_min_error_statement" inte är inställt på rätt värde kan det hända att meddelanden inte klassificeras som felmeddelanden på rätt sätt. Med tanke på allmänna loggmeddelanden som felmeddelanden skulle det göra det svårt att hitta faktiska fel, men med tanke på endast strängare allvarlighetsnivåer eftersom felmeddelanden kan hoppa över faktiska fel för att logga sina SQL-instruktioner. Flaggan "log_min_error_statement" ska anges i enlighet med organisationens loggningsprincip. Den här rekommendationen gäller för PostgreSQL-databasinstanser.

Allvarlighetsgrad: Låg

Kontrollera att databasflaggan "log_temp_files" för Cloud SQL PostgreSQL-instansen är inställd på "0"

Beskrivning: PostgreSQL kan skapa en tillfällig fil för åtgärder som sortering, hashning och tillfälliga frågeresultat när dessa åtgärder överskrider "work_mem". Flaggan "log_temp_files" styr loggningsnamn och filstorleken när den tas bort. Om du konfigurerar "log_temp_files" till 0 loggas all temporär filinformation, medan positiva värden endast loggar filer vars storlek är större än eller lika med det angivna antalet kilobyte. Värdet "-1" inaktiverar temporär filinformationsloggning. Om alla temporära filer inte loggas kan det vara svårare att identifiera potentiella prestandaproblem som kan bero på antingen dålig programkodning eller avsiktliga resurssvältningsförsök.

Allvarlighetsgrad: Låg

Se till att virtuella datordiskar för kritiska virtuella datorer är krypterade med krypteringsnyckel som tillhandahålls av kunden

Beskrivning: CSEK (Customer-Supplied Encryption Keys) är en funktion i Google Cloud Storage och Google Compute Engine. Om du anger egna krypteringsnycklar använder Google din nyckel för att skydda de Google-genererade nycklar som används för att kryptera och dekryptera dina data. Som standard krypterar Google Compute Engine alla vilande data. Compute Engine hanterar och hanterar den här krypteringen åt dig utan några ytterligare åtgärder från din sida. Men om du vill styra och hantera den här krypteringen själv kan du ange egna krypteringsnycklar. Som standard krypterar Google Compute Engine alla vilande data. Compute Engine hanterar och hanterar den här krypteringen åt dig utan några ytterligare åtgärder från din sida. Men om du vill styra och hantera den här krypteringen själv kan du ange egna krypteringsnycklar. Om du anger dina egna krypteringsnycklar använder Compute Engine din nyckel för att skydda de Google-genererade nycklar som används för att kryptera och dekryptera dina data. Endast användare som kan ange rätt nyckel kan använda resurser som skyddas av en krypteringsnyckel som tillhandahålls av kunden. Google lagrar inte dina nycklar på sina servrar och kan inte komma åt dina skyddade data om du inte anger nyckeln. Det innebär också att om du glömmer eller förlorar din nyckel finns det inget sätt för Google att återställa nyckeln eller återställa data som krypterats med den förlorade nyckeln. Minst affärskritiska virtuella datorer ska ha virtuella datordiskar krypterade med CSEK.

Allvarlighetsgrad: Medel

GCP-projekt bör ha automatisk etablering i Azure Arc aktiverad

Beskrivning: För fullständig insyn i säkerhetsinnehållet från Microsoft Defender för servrar bör GCP VM-instanser anslutas till Azure Arc. För att säkerställa att alla berättigade VM-instanser automatiskt tar emot Azure Arc aktiverar du automatisk avetablering från Defender för molnet på GCP-projektnivå. Läs mer om Azure Arc och Microsoft Defender för servrar.

Allvarlighetsgrad: Hög

GCP VM-instanser ska vara anslutna till Azure Arc

Beskrivning: Anslut dina virtuella GCP-datorer till Azure Arc för att få fullständig insyn i säkerhetsinnehållet i Microsoft Defender för servrar. Läs mer om Azure Arc och om Microsoft Defender för servrar i hybridmolnmiljö.

Allvarlighetsgrad: Hög

GCP VM-instanser bör ha os-konfigurationsagenten installerad

Beskrivning: Om du vill ta emot de fullständiga funktionerna i Defender för servrar med automatisk konfiguration av Azure Arc bör GCP-virtuella datorer ha os-konfigurationsagenten aktiverad.

Allvarlighetsgrad: Hög

GKE-klustrets funktion för automatisk reparation ska vara aktiverad

Beskrivning: Den här rekommendationen utvärderar hanteringsegenskapen för en nodpool för nyckel/värde-paret, "key": "autoRepair", "value": true.

Allvarlighetsgrad: Medel

GKE-klustrets funktion för automatisk uppgradering bör vara aktiverad

Beskrivning: Den här rekommendationen utvärderar hanteringsegenskapen för en nodpool för nyckel/värde-paret, "key": "autoUpgrade", "value": true.

Allvarlighetsgrad: Hög

Övervakning av GKE-kluster ska vara aktiverat

Beskrivning: Den här rekommendationen utvärderar om egenskapen monitoringService för ett kluster innehåller den plats som molnövervakning ska använda för att skriva mått.

Allvarlighetsgrad: Medel

GCP-containerrekommendationer

[Förhandsversion] Containeravbildningar i GCP-registret bör ha sårbarhetsresultat lösta

Beskrivning: Defender för molnet söker igenom dina registeravbildningar efter kända säkerhetsrisker (CVE) och ger detaljerade resultat för varje skannad avbildning. Genom att genomsöka och åtgärda säkerhetsrisker för containeravbildningar i registret kan du upprätthålla en säker och tillförlitlig leverantörskedja för programvara, minska risken för säkerhetsincidenter och säkerställa efterlevnad av branschstandarder.

Allvarlighetsgrad: Hög

Typ: Sårbarhetsbedömning

[Förhandsversion] Containrar som körs i GCP bör ha sårbarhetsresultat lösta

Beskrivning: Defender för molnet skapar en inventering av alla containerarbetsbelastningar som för närvarande körs i dina Kubernetes-kluster och tillhandahåller sårbarhetsrapporter för dessa arbetsbelastningar genom att matcha de avbildningar som används och de sårbarhetsrapporter som skapats för registeravbildningarna. Genomsökning och reparation av sårbarheter i containerarbetsbelastningar är viktigt för att säkerställa en robust och säker leverantörskedja för programvara, minska risken för säkerhetsincidenter och säkerställa efterlevnad av branschstandarder.

Allvarlighetsgrad: Hög

Typ: Sårbarhetsbedömning

Avancerad konfiguration av Defender för containrar ska vara aktiverad på GCP-anslutningsappar

Beskrivning: Microsoft Defender för containrar tillhandahåller molnbaserade Kubernetes-säkerhetsfunktioner, inklusive miljöhärdning, arbetsbelastningsskydd och körningsskydd. Aktivera alla avancerade konfigurationsinställningar för att säkerställa att lösningen är korrekt etablerad och att den fullständiga uppsättningen funktioner är tillgängliga.

Allvarlighetsgrad: Hög

GKE-kluster bör ha Microsoft Defender-tillägget för Azure Arc installerat

Beskrivning: Microsoft Defender-klustertilläggettillhandahåller säkerhetsfunktioner för dina GKE-kluster. Tillägget samlar in data från ett kluster och dess noder för att identifiera säkerhetsrisker och hot. Tillägget fungerar med Azure Arc-aktiverade Kubernetes. Läs mer om Microsoft Defender för molnet säkerhetsfunktioner för containerbaserade miljöer.

Allvarlighetsgrad: Hög

GKE-kluster bör ha Azure Policy-tillägget installerat

Beskrivning: Azure Policy-tillägget för Kubernetes utökar Gatekeeper v3, en webhook för åtkomstkontrollanter för Open Policy Agent (OPA), för att tillämpa skalbara tillämpningsåtgärder och skydd på dina kluster på ett centraliserat och konsekvent sätt. Tillägget fungerar med Azure Arc-aktiverade Kubernetes.

Allvarlighetsgrad: Hög

Microsoft Defender för containrar ska vara aktiverat på GCP-anslutningsappar

Beskrivning: Microsoft Defender för containrar tillhandahåller molnbaserade Kubernetes-säkerhetsfunktioner, inklusive miljöhärdning, arbetsbelastningsskydd och körningsskydd. Aktivera containerplan på GCP-anslutningsappen för att förstärka säkerheten i Kubernetes-kluster och åtgärda säkerhetsproblem. Läs mer om Microsoft Defender för containrar.

Allvarlighetsgrad: Hög

GKE-klustrets funktion för automatisk reparation ska vara aktiverad

Beskrivning: Den här rekommendationen utvärderar hanteringsegenskapen för en nodpool för nyckel/värde-paret, "key": "autoRepair", "value": true.

Allvarlighetsgrad: Medel

GKE-klustrets funktion för automatisk uppgradering bör vara aktiverad

Beskrivning: Den här rekommendationen utvärderar hanteringsegenskapen för en nodpool för nyckel/värde-paret, "key": "autoUpgrade", "value": true.

Allvarlighetsgrad: Hög

Övervakning av GKE-kluster ska vara aktiverat

Beskrivning: Den här rekommendationen utvärderar om egenskapen monitoringService för ett kluster innehåller den plats som molnövervakning ska använda för att skriva mått.

Allvarlighetsgrad: Medel

Loggning för GKE-kluster ska vara aktiverad

Beskrivning: Den här rekommendationen utvärderar om egenskapen loggingService för ett kluster innehåller den plats som Molnloggning ska använda för att skriva loggar.

Allvarlighetsgrad: Hög

GKE-webbinstrumentpanelen bör inaktiveras

Beskrivning: Den här rekommendationen utvärderar kubernetesDashboard-fältet för egenskapen addonsConfig för nyckel/värde-paret, "disabled": false.

Allvarlighetsgrad: Hög

Äldre auktorisering bör inaktiveras i GKE-kluster

Beskrivning: Den här rekommendationen utvärderar egenskapen legacyAbac för ett kluster för nyckel/värde-paret, "enabled": true.

Allvarlighetsgrad: Hög

Auktoriserade nätverk för kontrollplan ska vara aktiverade i GKE-kluster

Beskrivning: Den här rekommendationen utvärderar egenskapen masterAuthorizedNetworksConfig för ett kluster för nyckel/värde-paret, "enabled": false.

Allvarlighetsgrad: Hög

GKE-kluster bör ha alias-IP-intervall aktiverade

Beskrivning: Den här rekommendationen utvärderar om fältet useIPAliases i ipAllocationPolicy i ett kluster är inställt på false.

Allvarlighetsgrad: Låg

GKE-kluster bör ha privata kluster aktiverade

Beskrivning: Den här rekommendationen utvärderar om fältet enablePrivateNodes i egenskapen privateClusterConfig är inställt på false.

Allvarlighetsgrad: Hög

Nätverksprincipen ska vara aktiverad i GKE-kluster

Beskrivning: Den här rekommendationen utvärderar fältet networkPolicy i egenskapen addonsConfig för nyckel/värde-paret, "disabled": true.

Allvarlighetsgrad: Medel

Rekommendationer för dataplan

Alla säkerhetsrekommendationer för Kubernetes-dataplanet stöds för GCP när du har aktiverat Azure Policy för Kubernetes.

GCP-datarekommendationer

Kontrollera att databasflaggan "3625 (spårningsflagga)" för Cloud SQL Server-instansen är inställd på "off"

Beskrivning: Vi rekommenderar att du anger databasflaggan "3625 (spårningsflagga)" för Cloud SQL Server-instansen till "off". Spårningsflaggor används ofta för att diagnostisera prestandaproblem eller för att felsöka lagrade procedurer eller komplexa datorsystem, men de kan också rekommenderas av Microsoft Support för att hantera beteende som påverkar en viss arbetsbelastning negativt. Alla dokumenterade spårningsflaggor och de som rekommenderas av Microsoft Support stöds fullt ut i en produktionsmiljö när de används enligt anvisningarna. "3625(spårningslogg)" Begränsar mängden information som returneras till användare som inte är medlemmar i den fasta sysadmin-serverrollen genom att maskera parametrarna för vissa felmeddelanden med hjälp av "******". Detta kan bidra till att förhindra att känslig information avslöjas. Därför rekommenderar vi att du inaktiverar den här flaggan. Den här rekommendationen gäller för SQL Server-databasinstanser.

Allvarlighetsgrad: Medel

Se till att databasflaggan "externa skript aktiverade" för SQL Server-instansen i molnet är inställd på "off"

Beskrivning: Vi rekommenderar att du ställer in databasflaggan "externa skript aktiverade" för att cloud SQL Server-instansen ska inaktiveras. Med "externa skript aktiverade" kan skript köras med vissa fjärrspråkstillägg. Den här egenskapen är AV som standard. När Advanced Analytics Services har installerats kan du välja att ange den här egenskapen till true. Eftersom funktionen "Externa skript aktiverade" tillåter att skript utanför SQL, till exempel filer som finns i ett R-bibliotek, körs, vilket kan påverka systemets säkerhet negativt, bör detta därför inaktiveras. Den här rekommendationen gäller för SQL Server-databasinstanser.

Allvarlighetsgrad: Hög

Se till att databasflaggan "fjärråtkomst" för SQL Server-instansen i molnet är inställd på "off"

Beskrivning: Vi rekommenderar att du anger databasflaggan "fjärråtkomst" för Cloud SQL Server-instansen till "off". Alternativet "fjärråtkomst" styr körningen av lagrade procedurer från lokala servrar eller fjärrservrar där instanser av SQL Server körs. Det här standardvärdet för det här alternativet är 1. Detta ger behörighet att köra lokala lagrade procedurer från fjärrservrar eller fjärrlagrade procedurer från den lokala servern. För att förhindra att lokala lagrade procedurer körs från en fjärrserver eller fjärranslutna procedurer från att köras på den lokala servern måste detta inaktiveras. Alternativet Fjärråtkomst styr körningen av lokala lagrade procedurer på fjärrservrar eller fjärranslutna procedurer på den lokala servern. Funktionen "Fjärråtkomst" kan missbrukas för att starta en DoS-attack (Denial-of-Service) på fjärrservrar genom att avinläsning av frågebearbetning till ett mål, därför bör detta inaktiveras. Den här rekommendationen gäller för SQL Server-databasinstanser.

Allvarlighetsgrad: Hög

Kontrollera att databasflaggan "skip_show_database" för Cloud SQL Mysql-instansen är inställd på "på"

Beskrivning: Vi rekommenderar att du anger databasflaggan "skip_show_database" för Cloud SQL Mysql-instansen till "på". Databasflaggan "skip_show_database" hindrar personer från att använda SHOW DATABASES-instruktionen om de inte har behörigheten SHOW DATABASES. Detta kan förbättra säkerheten om du är orolig för att användare ska kunna se databaser som tillhör andra användare. Dess effekt beror på SHOW DATABASES-behörigheten: Om variabelvärdet är PÅ tillåts SHOW DATABASES-instruktionen endast för användare som har behörigheten SHOW DATABASES, och instruktionen visar alla databasnamn. Om värdet är AV tillåts SHOW DATABASES för alla användare, men visar bara namnen på de databaser som användaren har SHOW DATABASES eller annan behörighet för. Den här rekommendationen gäller för Mysql-databasinstanser.

Allvarlighetsgrad: Låg

Kontrollera att en standardkundhanterad krypteringsnyckel (CMEK) har angetts för alla BigQuery-datauppsättningar

Beskrivning: BigQuery krypterar som standard data i vila genom att använda kuvertkryptering med hjälp av Googles hanterade kryptografiska nycklar. Data krypteras med hjälp av datakrypteringsnycklarna och själva datakrypteringsnycklarna krypteras ytterligare med hjälp av nyckelkrypteringsnycklar. Detta är sömlöst och kräver inga ytterligare indata från användaren. Men om du vill ha större kontroll kan kundhanterade krypteringsnycklar (CMEK) användas som krypteringsnyckelhanteringslösning för BigQuery Data Sets. BigQuery krypterar som standard data som vila genom att använda kuvertkryptering med hjälp av Googles hanterade kryptografiska nycklar. Detta är sömlöst och kräver inga ytterligare indata från användaren. För större kontroll över krypteringen kan kundhanterade krypteringsnycklar (CMEK) användas som krypteringsnyckelhanteringslösning för BigQuery Data Sets. Om du anger en cmek (Default Customer-managed encryption key) för en datauppsättning ser du till att alla tabeller som skapas i framtiden använder den angivna CMEK:en om ingen annan tillhandahålls. Obs! Google lagrar inte dina nycklar på sina servrar och kan inte komma åt dina skyddade data om du inte anger nyckeln. Det innebär också att om du glömmer eller förlorar din nyckel finns det inget sätt för Google att återställa nyckeln eller återställa data som krypterats med den förlorade nyckeln.

Allvarlighetsgrad: Medel

Kontrollera att alla BigQuery-tabeller är krypterade med kundhanterad krypteringsnyckel (CMEK)

Beskrivning: BigQuery krypterar som standard data i vila genom att använda kuvertkryptering med hjälp av Googles hanterade kryptografiska nycklar. Data krypteras med hjälp av datakrypteringsnycklarna och själva datakrypteringsnycklarna krypteras ytterligare med hjälp av nyckelkrypteringsnycklar. Detta är sömlöst och kräver inga ytterligare indata från användaren. Men om du vill ha större kontroll kan kundhanterade krypteringsnycklar (CMEK) användas som krypteringsnyckelhanteringslösning för BigQuery Data Sets. Om CMEK används används CMEK för att kryptera datakrypteringsnycklarna i stället för att använda Google-hanterade krypteringsnycklar. BigQuery krypterar som standard data som vila genom att använda kuvertkryptering med hjälp av Googles hanterade kryptografiska nycklar. Detta är sömlöst och kräver inga ytterligare indata från användaren. För större kontroll över krypteringen kan kundhanterade krypteringsnycklar (CMEK) användas som krypteringsnyckelhanteringslösning för BigQuery-tabeller. CMEK används för att kryptera datakrypteringsnycklarna i stället för att använda google-hanterade krypteringsnycklar. BigQuery lagrar tabellen och CMEK-associationen och krypteringen/dekrypteringen görs automatiskt. Om du tillämpar standardkundhanterade nycklar på BigQuery-datauppsättningar ser du till att alla nya tabeller som skapas i framtiden krypteras med cmek, men befintliga tabeller måste uppdateras för att kunna använda CMEK individuellt. Obs! Google lagrar inte dina nycklar på sina servrar och kan inte komma åt dina skyddade data om du inte anger nyckeln. Det innebär också att om du glömmer eller förlorar din nyckel finns det inget sätt för Google att återställa nyckeln eller återställa data som krypterats med den förlorade nyckeln.

Allvarlighetsgrad: Medel

Se till att BigQuery-datauppsättningar inte är anonymt eller offentligt tillgängliga

Beskrivning: Vi rekommenderar att IAM-principen för BigQuery-datauppsättningar inte tillåter anonym och/eller offentlig åtkomst. Genom att bevilja behörigheter till allaAnvändare eller allaAuthenticatedUsers kan vem som helst komma åt datauppsättningen. Sådan åtkomst kanske inte är önskvärd om känsliga data lagras i datamängden. Se därför till att anonym och/eller offentlig åtkomst till en datauppsättning inte tillåts.

Allvarlighetsgrad: Hög

Kontrollera att Cloud SQL-databasinstanser har konfigurerats med automatiserade säkerhetskopieringar

Beskrivning: Vi rekommenderar att alla SQL-databasinstanser är inställda för att aktivera automatiserade säkerhetskopieringar. Säkerhetskopior är ett sätt att återställa en Cloud SQL-instans för att återställa förlorade data eller återställa från ett problem med den instansen. Automatiserade säkerhetskopior måste ställas in för alla instanser som innehåller data som ska skyddas mot förlust eller skada. Den här rekommendationen gäller för SQL Server-, PostgreSql-, MySql generation 1- och MySql generation 2-instanser.

Allvarlighetsgrad: Hög

Se till att Sql-databasinstanser i molnet inte är öppna för världen

Beskrivning: Databasservern bör endast acceptera anslutningar från betrodda nätverk/IP-adresser och begränsa åtkomsten från världen. För att minimera attackytan på en databasserverinstans bör endast betrodda/kända och nödvändiga IP-adresser godkännas för att ansluta till den. Ett auktoriserat nätverk bör inte ha IP-adresser/nätverk konfigurerade till "0.0.0.0/0", vilket ger åtkomst till instansen var som helst i världen. Observera att auktoriserade nätverk endast gäller för instanser med offentliga IP-adresser.

Allvarlighetsgrad: Hög

Kontrollera att Cloud SQL-databasinstanser inte har offentliga IP-adresser

Beskrivning: Vi rekommenderar att du konfigurerar andra generationens Sql-instans för att använda privata IP-adresser i stället för offentliga IP-adresser. För att minska organisationens attackyta bör Cloud SQL-databaser inte ha offentliga IP-adresser. Privata IP-adresser ger förbättrad nätverkssäkerhet och kortare svarstid för ditt program.

Allvarlighetsgrad: Hög

Se till att Cloud Storage-bucketen inte är anonymt eller offentligt tillgänglig

Beskrivning: Vi rekommenderar att IAM-principen i Cloud Storage-bucketen inte tillåter anonym eller offentlig åtkomst. Om du tillåter anonym eller offentlig åtkomst får vem som helst behörighet att komma åt bucketinnehåll. Sådan åtkomst kanske inte önskas om du lagrar känsliga data. Se därför till att anonym eller offentlig åtkomst till en bucket inte tillåts.

Allvarlighetsgrad: Hög

Se till att Cloud Storage-bucketar har enhetlig åtkomst på bucketnivå aktiverat

Beskrivning: Vi rekommenderar att enhetlig åtkomst på bucketnivå aktiveras på Cloud Storage-bucketar. Vi rekommenderar att du använder enhetlig åtkomst på bucketnivå för att förena och förenkla hur du beviljar åtkomst till dina Cloud Storage-resurser. Cloud Storage erbjuder två system för att ge användare behörighet att komma åt dina bucketar och objekt: Cloud Identity and Access Management (Cloud IAM) och Åtkomstkontrollistor (ACL).
Dessa system fungerar parallellt – för att en användare ska få åtkomst till en Molnlagringsresurs behöver bara ett av systemen bevilja användaren behörighet. Moln-IAM används i hela Google Cloud och gör att du kan bevilja en mängd olika behörigheter på bucket- och projektnivå. ACL:er används endast av Cloud Storage och har begränsade behörighetsalternativ, men de gör att du kan bevilja behörigheter per objekt.

För att stödja ett enhetligt behörighetssystem har Cloud Storage enhetlig åtkomst på bucketnivå. Med den här funktionen inaktiveras ACL:er för alla Cloud Storage-resurser: åtkomst till Cloud Storage-resurser beviljas sedan exklusivt via Cloud IAM. Om du aktiverar enhetlig åtkomst på bucketnivå garanteras att inget objekt i bucketen är offentligt tillgängligt om en lagringshink inte är offentligt tillgänglig.

Allvarlighetsgrad: Medel

Kontrollera att beräkningsinstanser har konfidentiell databehandling aktiverat

Beskrivning: Google Cloud krypterar vilande data och under överföring, men kunddata måste dekrypteras för bearbetning. Konfidentiell databehandling är en banbrytande teknik som krypterar data som används medan de bearbetas. Miljöer för konfidentiell databehandling håller data krypterade i minnet och på andra platser utanför den centrala bearbetningsenheten (CPU). Konfidentiella virtuella datorer använder funktionen Säker krypterad virtualisering (SEV) i AMD EPYC-processorer. Kunddata förblir krypterade när de används, indexeras, efterfrågas eller tränas på. Krypteringsnycklar genereras i maskinvara, per virtuell dator och kan inte exporteras. Tack vare inbyggda maskinvaruoptimeringar av både prestanda och säkerhet finns det ingen betydande prestandaförseelse för konfidentiella databehandlingsarbetsbelastningar. Med konfidentiell databehandling kan kundernas känsliga kod och andra data krypteras i minnet under bearbetningen. Google har inte åtkomst till krypteringsnycklarna. Konfidentiell virtuell dator kan hjälpa till att minska oron för risker relaterade till antingen beroende av Googles infrastruktur eller Google Insiders åtkomst till kunddata i klartext.

Allvarlighetsgrad: Hög

Se till att kvarhållningsprinciper på logg bucketar har konfigurerats med bucketlås

Beskrivning: Om du aktiverar kvarhållningsprinciper på logg bucketar skyddas loggar som lagras i molnlagrings bucketar från att skrivas över eller tas bort av misstag. Vi rekommenderar att du konfigurerar kvarhållningsprinciper och konfigurerar Bucket Lock på alla lagringshink som används som loggmottagare. Loggar kan exporteras genom att skapa en eller flera mottagare som innehåller ett loggfilter och ett mål. När Stackdriver Logging tar emot nya loggposter jämförs de med varje mottagare. Om en loggpost matchar filtret för en mottagare skrivs en kopia av loggposten till målet. Mottagare kan konfigureras för att exportera loggar i lagrings bucketar. Vi rekommenderar att du konfigurerar en datakvarhållningsprincip för dessa molnlagrings bucketar och låser principen för datakvarhållning. och därmed permanent förhindra att policyn reduceras eller tas bort. På så sätt, om systemet någonsin komprometteras av en angripare eller en obehörig insider som vill täcka sina spår, bevaras aktivitetsloggarna definitivt för kriminaltekniska och säkerhetsundersökningar.

Allvarlighetsgrad: Låg

Kontrollera att Cloud SQL-databasinstansen kräver att alla inkommande anslutningar använder SSL

Beskrivning: Vi rekommenderar att du framtvingar alla inkommande anslutningar till SQL-databasinstansen för att använda SSL. SQL-databasanslutningar om de har fastnat (MITM); kan avslöja känsliga data som autentiseringsuppgifter, databasfrågor, frågeutdata osv. För säkerhet rekommenderar vi att du alltid använder SSL-kryptering när du ansluter till din instans. Den här rekommendationen gäller för Instanser av Postgresql, MySql generation 1 och MySql generation 2.

Allvarlighetsgrad: Hög

Kontrollera att databasflaggan "innesluten databasautentisering" för Cloud SQL på SQL Server-instansen är inställd på "off"

Beskrivning: Vi rekommenderar att du anger databasflaggan "innesluten databasautentisering" för Cloud SQL på SQL Server-instansen är inställd på "off". En innesluten databas innehåller alla databasinställningar och metadata som krävs för att definiera databasen och har inga konfigurationsberoenden på instansen av databasmotorn där databasen är installerad. Användare kan ansluta till databasen utan att autentisera en inloggning på databasmotornivå. Genom att isolera databasen från databasmotorn kan du enkelt flytta databasen till en annan instans av SQL Server. Inneslutna databaser har vissa unika hot som bör förstås och minimeras av SQL Server Database Engine-administratörer. De flesta hoten är relaterade till autentiseringsprocessen ANVÄNDARE MED LÖSENORD, som flyttar autentiseringsgränsen från databasmotornivån till databasnivå. Därför rekommenderas att du inaktiverar den här flaggan. Den här rekommendationen gäller för SQL Server-databasinstanser.

Allvarlighetsgrad: Medel

Kontrollera att databasflaggan "kors db ownership chaining" för Cloud SQL Server-instansen är inställd på "off"

Beskrivning: Vi rekommenderar att du anger databasflaggan "kors db ownership chaining" för Cloud SQL Server-instansen till "off". Använd alternativet korsdatabasägarskap för länkning för att konfigurera ägarskapslänkning mellan databaser för en instans av Microsoft SQL Server. Med det här serveralternativet kan du styra korsdatabasägarlänkning på databasnivå eller tillåta korsdatabasägarkoppling för alla databaser. Aktivering av "korsdatabasägarskap" rekommenderas inte om inte alla databaser som hanteras av SQL Server-instansen måste delta i korsdatabasägarlänkning och du är medveten om säkerhetskonsekvenserna av den här inställningen. Den här rekommendationen gäller för SQL Server-databasinstanser.

Allvarlighetsgrad: Medel

Kontrollera att databasflaggan "local_infile" för en Sql Mysql-instans i molnet är inställd på "off"

Beskrivning: Vi rekommenderar att du ställer in local_infile databasflaggan för en Cloud SQL MySQL-instans till av. Flaggan local_infile styr lokal kapacitet på serversidan för LOAD DATA-instruktioner. Beroende på inställningen local_infile nekar eller tillåter servern lokal datainläsning av klienter som har LOCAL aktiverat på klientsidan. Starta mysqld med local_infile inaktiverad för att uttryckligen få servern att vägra LOKALA LOAD DATA-instruktioner (oavsett hur klientprogram och bibliotek konfigureras vid byggtid eller körning). local_infile kan också ställas in vid körning. På grund av säkerhetsproblem som är associerade med flaggan local_infile rekommenderar vi att du inaktiverar den. Den här rekommendationen gäller för MySQL-databasinstanser.

Allvarlighetsgrad: Medel

Kontrollera att loggmåttfiltret och aviseringarna finns för ändringar av IAM-behörigheter för Cloud Storage

Beskrivning: Vi rekommenderar att ett måttfilter och larm upprättas för Cloud Storage Bucket IAM-ändringar. Övervakning av ändringar i molnlagrings bucketbehörigheter kan minska den tid som krävs för att identifiera och korrigera behörigheter för känsliga molnlagrings bucketar och objekt i bucketen.

Allvarlighetsgrad: Låg

Kontrollera att loggmåttfiltret och aviseringarna finns för konfigurationsändringar för SQL-instanser

Beskrivning: Vi rekommenderar att ett måttfilter och larm upprättas för konfigurationsändringar för SQL-instanser. Övervakning av ändringar i SQL-instanskonfigurationsändringar kan minska den tid som krävs för att identifiera och korrigera felkonfigurationer som görs på SQL-servern. Nedan visas några av de konfigurerbara alternativen som kan påverka säkerhetsstatusen för en SQL-instans:

Aktivera automatiska säkerhetskopieringar och hög tillgänglighet: Felkonfiguration kan påverka affärskontinuitet, haveriberedskap och hög tillgänglighet negativt
Auktorisera nätverk: Felkonfiguration kan öka exponeringen för ej betrodda nätverk

Allvarlighetsgrad: Låg

Se till att det bara finns GCP-hanterade tjänstkontonycklar för varje tjänstkonto

Beskrivning: Användarhanterade tjänstkonton ska inte ha användarhanterade nycklar. Alla som har åtkomst till nycklarna kommer att kunna komma åt resurser via tjänstkontot. GCP-hanterade nycklar används av molnplattformstjänster som App Engine och Compute Engine. Dessa nycklar kan inte laddas ned. Google behåller nycklarna och roterar dem automatiskt ungefär varje vecka. Användarhanterade nycklar skapas, kan laddas ned och hanteras av användare. De löper ut 10 år från skapandet. För användarhanterade nycklar måste användaren ta över ägarskapet för viktiga hanteringsaktiviteter, bland annat:

Nyckellagring
Nyckeldistribution
Återkallande av nycklar
Nyckelrotation
Skydda nycklarna från obehöriga användare
Nyckelåterställning

Även med viktiga försiktighetsåtgärder för ägare kan nycklar lätt läckas av vanliga utvecklingsfel som att kontrollera nycklar i källkoden eller lämna dem i katalogen Nedladdningar eller av misstag lämna dem på supportbloggar/kanaler. Vi rekommenderar att du förhindrar användarhanterade tjänstkontonycklar.

Allvarlighetsgrad: Låg

Se till att databasflaggan "användaranslutningar" för SQL Server-instansen i molnet har angetts efter behov

Beskrivning: Vi rekommenderar att du anger databasflaggan "användaranslutningar" för Cloud SQL Server-instansen enligt ett organisationsdefinierat värde. Alternativet "användaranslutningar" anger det maximala antalet samtidiga användaranslutningar som tillåts på en instans av SQL Server. Det faktiska antalet tillåtna användaranslutningar beror också på vilken version av SQL Server du använder, och även gränserna för ditt program eller program och maskinvara. SQL Server tillåter högst 32 767 användaranslutningar. Eftersom användaranslutningar är ett dynamiskt alternativ (självkonfigurering) justerar SQL Server det maximala antalet användaranslutningar automatiskt efter behov, upp till det högsta tillåtna värdet. Om till exempel bara 10 användare är inloggade allokeras 10 användaranslutningsobjekt. I de flesta fall behöver du inte ändra värdet för det här alternativet. Standardvärdet är 0, vilket innebär att de maximala (32 767) användaranslutningarna tillåts. Den här rekommendationen gäller för SQL Server-databasinstanser.

Allvarlighetsgrad: Låg

Se till att databasflaggan "användaralternativ" för SQL Server-instansen i molnet inte har konfigurerats

Beskrivning: Vi rekommenderar att databasflaggan "användaralternativ" för Cloud SQL Server-instansen inte konfigureras. Alternativet "användaralternativ" anger globala standardvärden för alla användare. En lista över standardalternativ för frågebearbetning upprättas under en användares arbetssession. Med alternativet användaralternativ kan du ändra standardvärdena för SET-alternativen (om serverns standardinställningar inte är lämpliga). En användare kan åsidosätta dessa standardvärden med hjälp av SET-instruktionen. Du kan konfigurera användaralternativ dynamiskt för nya inloggningar. När du har ändrat inställningen för användaralternativ använder nya inloggningssessioner den nya inställningen. aktuella inloggningssessioner påverkas inte. Den här rekommendationen gäller för SQL Server-databasinstanser.

Allvarlighetsgrad: Låg

Loggning för GKE-kluster ska vara aktiverad

Beskrivning: Den här rekommendationen utvärderar om egenskapen loggingService för ett kluster innehåller den plats som Molnloggning ska använda för att skriva loggar.

Allvarlighetsgrad: Hög

Objektversionshantering ska aktiveras på lagrings bucketar där mottagare konfigureras

Beskrivning: Den här rekommendationen utvärderar om det aktiverade fältet i bucketens versionsegenskap är inställt på true.

Allvarlighetsgrad: Hög

Överetablerade identiteter i projekt bör undersökas för att minska PCI (Permission Creep Index)

Beskrivning: Överetablerade identiteter i projekt bör undersökas för att minska PCI (Permission Creep Index) och skydda infrastrukturen. Minska PCI genom att ta bort oanvända behörighetstilldelningar med hög risk. Hög PCI återspeglar risker som är associerade med identiteter med behörigheter som överskrider deras normala eller nödvändiga användning.

Allvarlighetsgrad: Medel

Projekt som har kryptografiska nycklar bör inte ha användare med ägarbehörighet

Beskrivning: Den här rekommendationen utvärderar IAM-tillåtna principer i projektmetadata för huvudnamn tilldelade roller/ägare.

Allvarlighetsgrad: Medel

Lagrings bucketar som används som en loggmottagare bör inte vara offentligt tillgängliga

Beskrivning: Den här rekommendationen utvärderar IAM-principen för en bucket för huvudnamnen allUsers eller allAuthenticatedUsers, som beviljar offentlig åtkomst.

Allvarlighetsgrad: Hög

GCP IdentityAndAccess-rekommendationer

Kryptografiska nycklar ska inte ha fler än tre användare

Beskrivning: Den här rekommendationen utvärderar IAM-principer för nyckelringar, projekt och organisationer och hämtar huvudnamn med roller som gör att de kan kryptera, dekryptera eller signera data med hjälp av Cloud KMS-nycklar: roller/ägare, roller/cloudkms.cryptoKeyEncrypterDecrypter, roller/cloudkms.cryptoKeyEncrypter, roller/cloudkms.cryptoKeyDecrypter, roller/cloudkms.signer och roller/cloudkms.signerVerifier.

Allvarlighetsgrad: Medel

Kontrollera att API-nycklar inte har skapats för ett projekt

Beskrivning: Nycklar är osäkra eftersom de kan visas offentligt, till exempel från en webbläsare, eller så kan de nås på en enhet där nyckeln finns. Vi rekommenderar att du använder standardautentiseringsflödet i stället.

Säkerhetsrisker som är förknippade med att använda API-nycklar visas nedan:

API-nycklar är enkla krypterade strängar
API-nycklar identifierar inte användaren eller programmet som gör API-begäran
API-nycklar är vanligtvis tillgängliga för klienter, vilket gör det enkelt att identifiera och stjäla en API-nyckel

För att undvika säkerhetsrisken vid användning av API-nycklar rekommenderar vi att du använder standardautentiseringsflödet i stället.

Allvarlighetsgrad: Hög

Kontrollera att API-nycklar endast är begränsade till API:er som programmet behöver åtkomst till

Beskrivning: API-nycklar är osäkra eftersom de kan visas offentligt, till exempel från en webbläsare, eller så kan de nås på en enhet där nyckeln finns. Vi rekommenderar att du begränsar API-nycklar till att endast använda (anropa) API:er som krävs av ett program.

Säkerhetsrisker som är förknippade med att använda API-nycklar finns nedan:

API-nycklar är enkla krypterade strängar
API-nycklar identifierar inte användaren eller programmet som gör API-begäran
API-nycklar är vanligtvis tillgängliga för klienter, vilket gör det enkelt att identifiera och stjäla en API-nyckel

Mot bakgrund av dessa potentiella risker rekommenderar Google att du använder standardautentiseringsflödet i stället för API-Keys. Det finns dock begränsade fall där API-nycklar är lämpligare. Om det till exempel finns ett mobilprogram som behöver använda API:et för Google Cloud Translation, men annars inte behöver en serverdelsserver, är API-nycklar det enklaste sättet att autentisera till det API:et.

För att minska angreppsytorna genom att ge minsta möjliga behörighet kan API-Nycklar begränsas till att endast använda (anropa) API:er som krävs av ett program.

Allvarlighetsgrad: Hög

Kontrollera att API-nycklar är begränsade till användning av endast angivna värdar och appar

Beskrivning: Obegränsade nycklar är osäkra eftersom de kan visas offentligt, till exempel från en webbläsare, eller så kan de nås på en enhet där nyckeln finns. Vi rekommenderar att du begränsar API-nyckelanvändningen till betrodda värdar, HTTP-refererare och appar.

Säkerhetsrisker som är förknippade med att använda API-nycklar visas nedan:

API-nycklar är enkla krypterade strängar
API-nycklar identifierar inte användaren eller programmet som gör API-begäran
API-nycklar är vanligtvis tillgängliga för klienter, vilket gör det enkelt att identifiera och stjäla en API-nyckel

Mot bakgrund av dessa potentiella risker rekommenderar Google att du använder standardautentiseringsflödet i stället för API-nycklar. Det finns dock begränsade fall där API-nycklar är lämpligare. Om det till exempel finns ett mobilprogram som behöver använda API:et för Google Cloud Translation, men annars inte behöver en serverdelsserver, är API-nycklar det enklaste sättet att autentisera till det API:et.

För att minska angreppsvektorer kan API-Nycklar endast begränsas till betrodda värdar, HTTP-refererare och program.

Allvarlighetsgrad: Hög

Kontrollera att API-nycklar roteras var 90:e dag

Beskrivning: Vi rekommenderar att du roterar API-nycklar var 90:e dag.

Säkerhetsrisker som är förknippade med att använda API-nycklar visas nedan:

API-nycklar är enkla krypterade strängar
API-nycklar identifierar inte användaren eller programmet som gör API-begäran
API-nycklar är vanligtvis tillgängliga för klienter, vilket gör det enkelt att identifiera och stjäla en API-nyckel

På grund av dessa potentiella risker rekommenderar Google att du använder standardautentiseringsflödet i stället för API-nycklar. Det finns dock begränsade fall där API-nycklar är lämpligare. Om det till exempel finns ett mobilprogram som behöver använda API:et för Google Cloud Translation, men annars inte behöver en serverdelsserver, är API-nycklar det enklaste sättet att autentisera till det API:et.

När en nyckel har stulits har den ingen giltighetstid, vilket innebär att den kan användas på obestämd tid om inte projektägaren återkallar eller återskapar nyckeln. Roterande API-nycklar minskar möjligheten för en åtkomstnyckel som är associerad med ett komprometterat eller avslutat konto som ska användas.

API-nycklar bör roteras för att säkerställa att data inte kan nås med en gammal nyckel som kan ha förlorats, knäckts eller stulits.

Allvarlighetsgrad: Hög

Kontrollera att KMS-krypteringsnycklar roteras inom 90 dagar

Beskrivning: Google Cloud nyckelhanteringstjänst (KMS) lagrar kryptografiska nycklar i en hierarkisk struktur som är utformad för användbar och elegant hantering av åtkomstkontroll. Formatet för rotationsschemat beror på vilket klientbibliotek som används. För gcloud-kommandoradsverktyget måste nästa rotationstid vara i formatet "ISO" eller "RFC3339", och rotationsperioden måste vara i formatet "INTEGER[UNIT]," där enheterna kan vara en av sekunderna, minuterna (m), timmarna (h) eller dagarna (d). Ange en nyckelrotationsperiod och starttid. En nyckel kan skapas med en angiven "rotationsperiod", vilket är tiden mellan när nya nyckelversioner genereras automatiskt. En nyckel kan också skapas med en angiven nästa rotationstid. En nyckel är ett namngivet objekt som representerar en "kryptografisk nyckel" som används för ett specifikt syfte. Nyckelmaterialet, de faktiska bitar som används för "kryptering", kan ändras med tiden när nya nyckelversioner skapas. En nyckel används för att skydda vissa "datakorus". En samling filer kan krypteras med samma nyckel och personer med "dekryptera" behörigheter för den nyckeln skulle kunna dekryptera dessa filer. Därför är det nödvändigt att se till att "rotationsperioden" är inställd på en viss tid.

Allvarlighetsgrad: Medel

Se till att loggmåttfilter och aviseringar finns för tilldelningar/ändringar av projektägarskap

Beskrivning: För att förhindra onödiga tilldelningar av projektägarskap till användare/tjänstkonton och ytterligare missbruk av projekt och resurser bör alla "roller/ägare"-tilldelningar övervakas. Medlemmar (användare/tjänstkonton) med en rolltilldelning till primitiv roll "roller/ägare" är projektägare. Projektägaren har alla behörigheter för projektet som rollen tillhör. Dessa sammanfattas nedan:

Alla visningsbehörigheter för alla GCP-tjänster i projektet
Behörigheter för åtgärder som ändrar tillståndet för alla GCP-tjänster i projektet
Hantera roller och behörigheter för ett projekt och alla resurser i projektet
Om du konfigurerar fakturering för ett projekt som beviljar ägarrollen till en medlem (användare/tjänstkonto) kan medlemmen ändra IAM-principen (Identitets- och åtkomsthantering). Bevilja därför ägarrollen endast om medlemmen har ett legitimt syfte att hantera IAM-principen. Det beror på att projektets IAM-princip innehåller känsliga åtkomstkontrolldata. Att ha en minimal uppsättning användare som tillåts hantera IAM-principer förenklar alla granskningar som kan vara nödvändiga. Projektägarskapet har den högsta behörighetsnivån för ett projekt. För att undvika missbruk av projektresurser bör de projektägartilldelnings-/ändringsåtgärder som nämns ovan övervakas och varnas för berörda mottagare.
Skicka inbjudningar till projektägarskap
Godkännande/avvisande av inbjudan till projektägarskap av användaren
Lägga role\Owner till i ett användar-/tjänstkonto
Ta bort ett användar-/tjänstkonto från role\Owner

Allvarlighetsgrad: Låg

Kontrollera att oslogin är aktiverat för ett projekt

Beskrivning: Om du aktiverar os-inloggning binder SSH-certifikat till IAM-användare och underlättar effektiv SSH-certifikathantering. Om du aktiverar osLogin ser du till att SSH-nycklar som används för att ansluta till instanser mappas med IAM-användare. Om du återkallar åtkomsten till IAM-användaren återkallas alla SSH-nycklar som är associerade med den specifika användaren. Det underlättar centraliserad och automatiserad hantering av SSH-nyckelpar, vilket är användbart i hanteringsfall som svar på komprometterade SSH-nyckelpar och/eller återkallande av externa/tredje part/leverantörsanvändare. Om du vill ta reda på vilken instans som gör att projektet är felfritt kan du läsa rekommendationen "Se till att oslogin är aktiverat för alla instanser".

Allvarlighetsgrad: Medel

Kontrollera att oslogin är aktiverat för alla instanser

Allvarlighetsgrad: Medel

Kontrollera att Cloud Audit-loggning är korrekt konfigurerad för alla tjänster och alla användare från ett projekt

Beskrivning: Vi rekommenderar att Cloud Audit Logging konfigureras för att spåra alla administratörsaktiviteter och läsa, skriva åtkomst till användardata.

Cloud Audit Logging har två granskningsloggar för varje projekt, mapp och organisation: Administratörsaktivitet och Dataåtkomst.

Administratörsaktivitetsloggar innehåller loggposter för API-anrop eller andra administrativa åtgärder som ändrar konfigurationen eller metadata för resurser. Granskningsloggar för administratörsaktivitet är aktiverade för alla tjänster och kan inte konfigureras.
Data Access-granskningsloggar registrerar API-anrop som skapar, ändrar eller läser användarangivna data. Dessa är inaktiverade som standard och bör vara aktiverade. Det finns tre typer av granskningslogginformation för Data Access:

Administratören läste: Registrerar åtgärder som läser metadata eller konfigurationsinformation. Granskningsloggar för administratörsaktivitet registrerar skrivningar av metadata och konfigurationsinformation som inte kan inaktiveras.
Läs data: Registrerar åtgärder som läser användarbaserade data.
Dataskrivning: Registrerar åtgärder som skriver användarspecifika data.

Vi rekommenderar att en effektiv standardgranskningskonfiguration konfigureras på ett sådant sätt att:

logtype är inställt på DATA_READ (för att logga spårning av användaraktivitet) och DATA_WRITES (för att logga ändringar/manipulering av användardata).
granskningskonfiguration är aktiverat för alla tjänster som stöds av funktionen Data Access-granskningsloggar.
Loggar ska registreras för alla användare, det vill ex. det finns inga undantagna användare i något av granskningskonfigurationsavsnitten. Detta säkerställer att åsidosättande av granskningskonfigurationen inte strider mot kravet.

Allvarlighetsgrad: Medel

Se till att Cloud KMS-kryptonycklar inte är anonymt eller offentligt tillgängliga

Beskrivning: Vi rekommenderar att IAM-principen på Cloud KMS "cryptokeys" begränsar anonym och/eller offentlig åtkomst. Om du beviljar behörigheter till "allUsers" eller "allAuthenticatedUsers" kan vem som helst komma åt datauppsättningen. Sådan åtkomst kanske inte är önskvärd om känsliga data lagras på platsen. I det här fallet ska du se till att anonym och/eller offentlig åtkomst till en Cloud KMS"cryptokey" inte tillåts.

Allvarlighetsgrad: Hög

Beskrivning: Använd autentiseringsuppgifter för företagsinloggning i stället för personliga konton, till exempel Gmail-konton. Vi rekommenderar att fullständigt hanterade Företags Google-konton används för ökad synlighet, granskning och kontroll av åtkomst till Molnplattformsresurser. Gmail-konton som är baserade utanför användarens organisation, till exempel personliga konton, bör inte användas i affärssyfte.

Allvarlighetsgrad: Hög

Se till att IAM-användare inte har tilldelats rollerna Användar- eller tjänstkontotokenskapare för tjänstkonto på projektnivå

Beskrivning: Vi rekommenderar att du tilldelar rollerna "Service Account User (iam.serviceAccountUser)" och "Service Account Token Creator (iam.serviceAccountTokenCreator)" till en användare för ett specifikt tjänstkonto i stället för att tilldela rollen till en användare på projektnivå. Ett tjänstkonto är ett särskilt Google-konto som tillhör ett program eller en virtuell dator i stället för en enskild slutanvändare. Application/VM-Instance använder tjänstkontot för att anropa tjänstens Google API så att användarna inte är direkt inblandade. Förutom att vara en identitet är ett tjänstkonto en resurs som har IAM-principer kopplade till sig. Dessa principer avgör vem som kan använda tjänstkontot. Användare med IAM-roller för att uppdatera App Engine- och Compute Engine-instanserna (till exempel App Engine Deployer eller Compute Instance Admin) kan effektivt köra kod som de tjänstkonton som används för att köra dessa instanser och indirekt få åtkomst till alla resurser som tjänstkontona har åtkomst till. På samma sätt kan SSH-åtkomst till en Compute Engine-instans också ge möjlighet att köra kod som instans/tjänstkonto. Baserat på affärsbehov kan det finnas flera användarhanterade tjänstkonton som konfigurerats för ett projekt. Om du beviljar rollerna "iam.serviceAccountUser" eller "iam.serviceAserviceAccountTokenCreatorccountUser" till en användare för ett projekt får användaren åtkomst till alla tjänstkonton i projektet, inklusive tjänstkonton som kan skapas i framtiden. Detta kan leda till utökade privilegier med hjälp av tjänstkonton och motsvarande "Compute Engine-instanser". För att implementera bästa praxis för "lägsta behörigheter" bör IAM-användare inte tilldelas rollerna "Tjänstkontoanvändare" eller "Skapare av tjänstkontotoken" på projektnivå. I stället bör dessa roller tilldelas till en användare för ett specifikt tjänstkonto, vilket ger användaren åtkomst till tjänstkontot. Med "Tjänstkontoanvändare" kan en användare binda ett tjänstkonto till en långvarig jobbtjänst, medan rollen "Skapare av tjänstkontotoken" gör det möjligt för en användare att direkt personifiera (eller hävda) identiteten för ett tjänstkonto.

Allvarlighetsgrad: Medel

Beskrivning: Vi rekommenderar att principen "Separation av uppgifter" tillämpas när KMS-relaterade roller tilldelas användare. Med den inbyggda/fördefinierade IAM-rollen "Cloud KMS Admin" kan användaren/identiteten skapa, ta bort och hantera tjänstkonton. Den inbyggda/fördefinierade IAM-rollen "Cloud KMS CryptoKey Encrypter/Decrypter" gör det möjligt för användaren/identiteten (med tillräcklig behörighet för berörda resurser) att kryptera och dekryptera data i vila med hjälp av en krypteringsnyckel(er). Med den inbyggda/fördefinierade IAM-rollen Cloud KMS CryptoKey Encrypter kan användaren/identiteten (med tillräcklig behörighet för berörda resurser) kryptera data i vila med hjälp av en krypteringsnyckel. Med den inbyggda/fördefinierade IAM-rollen "Cloud KMS CryptoKey Decrypter" kan användaren/identiteten (med tillräcklig behörighet för berörda resurser) dekryptera data i vila med hjälp av en krypteringsnyckel. Ansvarsfördelning är konceptet att se till att en individ inte har alla nödvändiga behörigheter för att kunna slutföra en skadlig åtgärd. I Cloud KMS kan detta vara en åtgärd som att använda en nyckel för att komma åt och dekryptera data som en användare normalt inte ska ha åtkomst till. Ansvarsfördelning är en affärskontroll som vanligtvis används i större organisationer, som är avsedd att hjälpa till att undvika säkerhets- eller sekretessincidenter och -fel. Det anses vara bästa praxis. Inga användare ska ha Cloud KMS Admin och någon av rollerna "Cloud KMS CryptoKey Encrypter/Decrypter", "Cloud KMS CryptoKey Encrypter", "Cloud KMS CryptoKey Decrypter" tilldelade samtidigt.

Allvarlighetsgrad: Hög

Beskrivning: Vi rekommenderar att principen "Ansvarsfördelning" tillämpas när tjänstkontorelaterade roller tilldelas användare. Med den inbyggda/fördefinierade IAM-rollen "Tjänstkontoadministratör" kan användaren/identiteten skapa, ta bort och hantera tjänstkonton. Med den inbyggda/fördefinierade IAM-rollen "Tjänstkontoanvändare" kan användaren/identiteten (med tillräcklig behörighet för Beräkning och App Engine) tilldela tjänstkonton till appar/beräkningsinstanser. Ansvarsfördelning är konceptet att se till att en individ inte har alla nödvändiga behörigheter för att kunna slutföra en skadlig åtgärd. I Cloud IAM – tjänstkonton kan detta vara en åtgärd som att använda ett tjänstkonto för att komma åt resurser som användaren normalt inte ska ha åtkomst till. Ansvarsfördelning är en affärskontroll som vanligtvis används i större organisationer, som är avsedd att hjälpa till att undvika säkerhets- eller sekretessincidenter och -fel. Det anses vara bästa praxis. Ingen användare ska ha rollerna "Tjänstkontoadministratör" och "Tjänstkontoanvändare" tilldelade samtidigt.

Allvarlighetsgrad: Medel

Kontrollera att tjänstkontot inte har administratörsbehörighet

Beskrivning: Ett tjänstkonto är ett särskilt Google-konto som tillhör ett program eller en virtuell dator, i stället för till en enskild slutanvändare. Programmet använder tjänstkontot för att anropa tjänstens Google API så att användarna inte är direkt inblandade. Vi rekommenderar att du inte använder administratörsåtkomst för ServiceAccount. Tjänstkonton representerar säkerhet på tjänstnivå för resurser (program eller en virtuell dator) som kan fastställas av de roller som tilldelats till den. Registrering av ServiceAccount med administratörsbehörighet ger fullständig åtkomst till ett tilldelat program eller en virtuell dator. En ServiceAccount-åtkomstinnehavare kan utföra kritiska åtgärder som att ta bort, uppdatera ändringsinställningar osv. utan att användaren kan ingripa. Därför rekommenderar vi att tjänstkonton inte har administratörsbehörighet.

Allvarlighetsgrad: Medel

Kontrollera att mottagare har konfigurerats för alla loggposter

Beskrivning: Vi rekommenderar att du skapar en mottagare som exporterar kopior av alla loggposter. Detta kan hjälpa dig att aggregera loggar från flera projekt och exportera dem till en SIEM (Security Information and Event Management). Loggposter lagras i Stackdriver-loggning. Om du vill aggregera loggar exporterar du dem till en SIEM. Om du vill behålla dem längre rekommenderar vi att du konfigurerar en loggmottagare. Export innebär att du skriver ett filter som väljer de loggposter som ska exporteras och väljer ett mål i Cloud Storage, BigQuery eller Cloud Pub/Sub. Filtret och målet lagras i ett objekt som kallas mottagare. Kontrollera att alla loggposter exporteras till mottagare genom att se till att det inte finns något filter konfigurerat för en mottagare. Mottagare kan skapas i projekt, organisationer, mappar och faktureringskonton.

Allvarlighetsgrad: Låg

Kontrollera att loggmåttfiltret och aviseringarna finns för ändringar i granskningskonfigurationen

Beskrivning: Google Cloud Platform-tjänster (GCP) skriver granskningsloggposter till loggarna för administratörsaktivitet och dataåtkomst för att besvara frågorna "vem gjorde vad, var och när?" i GCP-projekt. Information om molngranskningsloggning innehåller identiteten för API-anroparen, tiden för API-anropet, API-anroparens käll-IP-adress, begäransparametrarna och svarselementen som returneras av GCP-tjänster. Molngranskningsloggning innehåller en historik över GCP API-anrop för ett konto, inklusive API-anrop som görs via konsolen, SDK:er, kommandoradsverktyg och andra GCP-tjänster. Administratörsaktivitet och dataåtkomstloggar som skapats av molngranskningsloggning möjliggör säkerhetsanalys, resursändringsspårning och efterlevnadsgranskning. Om du konfigurerar måttfiltret och aviseringarna för ändringar i granskningskonfigurationen ser du till att det rekommenderade tillståndet för granskningskonfigurationen bibehålls så att alla aktiviteter i projektet kan granskas när som helst.

Allvarlighetsgrad: Låg

Kontrollera att loggmåttfiltret och aviseringarna finns för ändringar av anpassad roll

Beskrivning: Vi rekommenderar att ett måttfilter och larm upprättas för ändringar i rollskapande, borttagning och uppdatering av aktiviteter för identitets- och åtkomsthantering (IAM). Google Cloud IAM tillhandahåller fördefinierade roller som ger detaljerad åtkomst till specifika Google Cloud Platform-resurser och förhindrar oönskad åtkomst till andra resurser. Men för att tillgodose organisationsspecifika behov ger Cloud IAM även möjlighet att skapa anpassade roller. Projektägare och administratörer med rollen Organisationsrolladministratör eller rollen IAM-rolladministratör kan skapa anpassade roller. Övervakning av rollskapande, borttagning och uppdatering av aktiviteter hjälper dig att identifiera eventuella överprivilegierade roller i ett tidigt skede.

Allvarlighetsgrad: Låg

Se till att användarhanterade/externa nycklar för tjänstkonton roteras var 90:e dag eller mindre

Beskrivning: Tjänstkontonycklar består av ett nyckel-ID (Private_key_Id) och en privat nyckel som används för att signera programmatiska begäranden som användare gör till Googles molntjänster som är tillgängliga för det specifika tjänstkontot. Vi rekommenderar att alla tjänstkontonycklar roteras regelbundet. Om du roterar tjänstkontonycklar minskar du möjligheten att använda en åtkomstnyckel som är associerad med ett komprometterat eller avslutat konto. Tjänstkontonycklar bör roteras för att säkerställa att data inte kan nås med en gammal nyckel som kan ha förlorats, knäckts eller stulits. Varje tjänstkonto är associerat med ett nyckelpar som hanteras av Google Cloud Platform (GCP). Den används för tjänst-till-tjänst-autentisering i GCP. Google roterar nycklarna dagligen. GCP ger möjlighet att skapa ett eller flera användarhanterade nyckelpar (kallas även externa nyckelpar) för användning utanför GCP (till exempel för användning med programstandardautentiseringsuppgifter). När ett nytt nyckelpar skapas måste användaren ladda ned den privata nyckeln (som inte behålls av Google).

Med externa nycklar ansvarar användarna för att skydda den privata nyckeln och andra hanteringsåtgärder, till exempel nyckelrotation. Externa nycklar kan hanteras av IAM-API:et, kommandoradsverktyget gcloud eller sidan Tjänstkonton i Google Cloud Platform Console.

GCP underlättar upp till 10 externa tjänstkontonycklar per tjänstkonto för att underlätta nyckelrotation.

Allvarlighetsgrad: Medel

GKE-webbinstrumentpanelen bör inaktiveras

Beskrivning: Den här rekommendationen utvärderar kubernetesDashboard-fältet för egenskapen addonsConfig för nyckel/värde-paret, "disabled": false.

Allvarlighetsgrad: Hög

Äldre auktorisering bör inaktiveras i GKE-kluster

Beskrivning: Den här rekommendationen utvärderar egenskapen legacyAbac för ett kluster för nyckel/värde-paret, "enabled": true.

Allvarlighetsgrad: Hög

Redis IAM-rollen bör inte tilldelas på organisations- eller mappnivå

Beskrivning: Den här rekommendationen utvärderar IAM-tillåtna principer i resursmetadata för huvudnamn tilldelade roller/redis.admin, roller/redis.editor, roller/redis.viewer på organisations- eller mappnivå.

Allvarlighetsgrad: Hög

Tjänstkonton bör ha begränsad projektåtkomst i ett kluster

Beskrivning: Den här rekommendationen utvärderar konfigurationsegenskapen för en nodpool för att kontrollera om inget tjänstkonto har angetts eller om standardtjänstkontot används.

Allvarlighetsgrad: Hög

Användare bör ha minst behörighet med detaljerade IAM-roller

Beskrivning: Den här rekommendationen utvärderar IAM-principen i resursmetadata för alla huvudnamn som tilldelats roller/ägare, roller/författare eller roller/läsare.

Allvarlighetsgrad: Hög

Superidentiteter i GCP-miljön bör tas bort

Beskrivning: En superidentitet har en kraftfull uppsättning behörigheter. Superadministratörer är mänskliga identiteter eller arbetsbelastningsidentiteter som har åtkomst till alla behörigheter och alla resurser. De kan skapa och ändra konfigurationsinställningar för en tjänst, lägga till eller ta bort identiteter och komma åt eller till och med ta bort data. Dessa identiteter lämnas oövervakade och utgör en betydande risk för missbruk av behörigheter om de överträds.

Allvarlighetsgrad: Hög

Oanvända identiteter i GCP-miljön bör tas bort

Beskrivning: Det är absolut nödvändigt att identifiera oanvända identiteter eftersom de utgör betydande säkerhetsrisker. Dessa identiteter omfattar ofta dåliga metoder, till exempel överdrivna behörigheter och felhanterade nycklar som lämnar organisationer öppna för missbruk av autentiseringsuppgifter eller utnyttjande och ökar resursens attackyta. Inaktiva identiteter är mänskliga och icke-mänskliga entiteter som inte har utfört någon åtgärd på någon resurs under de senaste 90 dagarna. Tjänstkontonycklar kan bli en säkerhetsrisk om de inte hanteras noggrant.

Allvarlighetsgrad: Medel

Överetablerade GCP-identiteter bör endast ha nödvändiga behörigheter

Beskrivning: En överetablerad aktiv identitet är en identitet som har åtkomst till privilegier som de inte har använt. Överetablerade aktiva identiteter, särskilt för icke-mänskliga konton som har mycket definierade åtgärder och ansvarsområden, kan öka explosionsradien i händelse av att en användare, nyckel eller resurs komprometterar principen om minsta behörighetstillstånd att en resurs endast ska ha åtkomst till de exakta resurser som behövs för att fungera. Den här principen utvecklades för att hantera risken för komprometterade identiteter som ger en angripare åtkomst till en mängd olika resurser.

Allvarlighetsgrad: Medel

GCP-nätverksrekommendationer

Klustervärdar ska konfigureras för att endast använda privata, interna IP-adresser för åtkomst till Google-API:er

Beskrivning: Den här rekommendationen utvärderar om egenskapen privateIpGoogleAccess för ett undernät är inställd på false.

Allvarlighetsgrad: Hög

Beräkningsinstanser bör använda en lastbalanserare som är konfigurerad för att använda en HTTPS-målproxy

Beskrivning: Den här rekommendationen utvärderar om egenskapen selfLink för targetHttpProxy-resursen matchar målattributet i vidarebefordringsregeln och om vidarebefordransregeln innehåller ett loadBalancingScheme-fält inställt på Externt.

Allvarlighetsgrad: Medel

Auktoriserade nätverk för kontrollplan ska vara aktiverade i GKE-kluster

Beskrivning: Den här rekommendationen utvärderar egenskapen masterAuthorizedNetworksConfig för ett kluster för nyckel/värde-paret, "enabled": false.

Allvarlighetsgrad: Hög

Regeln för nekande av utgående trafik ska anges i en brandvägg för att blockera oönskad utgående trafik

Beskrivning: Den här rekommendationen utvärderar om egenskapen destinationRanges i brandväggen är inställd på 0.0.0.0/0 och den nekade egenskapen innehåller nyckel/värde-paret IPProtocol: "all".

Allvarlighetsgrad: Låg

Se till att brandväggsregler för instanser bakom IAP (IAP) endast tillåter trafik från Google Cloud Loadbalancer (GCLB) hälsokontroll och proxyadresser

Beskrivning: Åtkomst till virtuella datorer bör begränsas av brandväggsregler som endast tillåter IAP-trafik genom att se till att endast anslutningar som anges av IAP tillåts. För att säkerställa att belastningsutjämning fungerar korrekt bör hälsokontroller också tillåtas. IAP ser till att åtkomsten till virtuella datorer styrs genom att inkommande begäranden autentiseras. Men om den virtuella datorn fortfarande är tillgänglig från andra IP-adresser än IAP kan det fortfarande vara möjligt att skicka oautentiserade begäranden till instansen. Var noga med att se till att belastningskontrollerna inte blockeras eftersom detta hindrar lastbalanseraren från att känna till den virtuella datorns hälsotillstånd korrekt och belastningsutjämningen på rätt sätt.

Allvarlighetsgrad: Medel

Se till att äldre nätverk inte finns för ett projekt

Beskrivning: För att förhindra användning av äldre nätverk bör ett projekt inte ha konfigurerat ett äldre nätverk. Äldre nätverk har ett enda IPv4-prefixintervall för nätverket och en enda gateway-IP-adress för hela nätverket. Nätverket är globalt i omfånget och omfattar alla molnregioner. Undernät kan inte skapas i ett äldre nätverk och kan inte växla från äldre till automatiska eller anpassade undernätsnätverk. Äldre nätverk kan påverka projekt med hög nätverkstrafik och är föremål för en enda konkurrenspunkt eller ett fel.

Allvarlighetsgrad: Medel

Se till att databasflaggan "log_hostname" för Cloud SQL PostgreSQL-instansen är korrekt inställd

Beskrivning: PostgreSQL loggar endast IP-adressen för de anslutande värdarna. Flaggan "log_hostname" styr loggningen av "värdnamn" utöver de IP-adresser som loggas. Prestandaträffen beror på konfigurationen av miljön och konfigurationen av värdnamnsmatchningen. Den här parametern kan bara anges i filen "postgresql.conf" eller på serverns kommandorad. Loggning av värdnamn kan medföra omkostnader för serverprestanda som för varje instruktion som loggas, DNS-matchning krävs för att konvertera IP-adress till värdnamn. Beroende på konfigurationen kan detta vara försumbart. Dessutom kan IP-adresserna som loggas matchas till deras DNS-namn senare när loggarna granskas, exklusive de fall där dynamiska värdnamn används. Den här rekommendationen gäller för PostgreSQL-databasinstanser.

Allvarlighetsgrad: Låg

Se till att inga HTTPS- eller SSL-proxylastbalanserare tillåter SSL-principer med svaga chiffersviter

Beskrivning: SSL-principer (Secure Sockets Layer) avgör vilka TLS-funktioner (Transport Layer Security) som klienter får använda när de ansluter till lastbalanserare. För att förhindra användning av osäkra funktioner bör SSL-principer använda (a) minst TLS 1.2 med MODERN-profilen. eller (b) RESTRICTED-profilen, eftersom den i praktiken kräver att klienter använder TLS 1.2 oavsett den valda lägsta TLS-versionen. eller (3) en ANPASSAD profil som inte stöder någon av följande funktioner: TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA

Lastbalanserare används för att effektivt distribuera trafik över flera servrar. Både SSL-proxy och HTTPS-lastbalanserare är externa lastbalanserare, vilket innebär att de distribuerar trafik från Internet till ett GCP-nätverk. GCP-kunder kan konfigurera SSL-principer för lastbalanserare med en lägsta TLS-version (1.0, 1.1 eller 1.2) som klienter kan använda för att upprätta en anslutning, tillsammans med en profil (kompatibel, modern, begränsad eller anpassad) som anger tillåtna chiffersviter. För att följa användare som använder inaktuella protokoll kan GCP-lastbalanserare konfigureras för att tillåta osäkra chiffersviter. I själva verket använder GCP:s standardprincip för SSL en lägsta TLS-version av 1.0 och en kompatibel profil, vilket möjliggör det bredaste utbudet av osäkra chiffersviter. Därför är det enkelt för kunderna att konfigurera en lastbalanserare utan att ens veta att de tillåter inaktuella chiffersviter.

Allvarlighetsgrad: Medel

Kontrollera att DNS-loggning i molnet är aktiverad för alla VPC-nätverk

Beskrivning: Cloud DNS-loggning registrerar frågorna från namnservrarna i din VPC till Stackdriver. Loggade frågor kan komma från virtuella datorer med beräkningsmotorn, GKE-containrar eller andra GCP-resurser som etablerats i den virtuella datorn. Säkerhetsövervakning och kriminalteknik kan inte enbart bero på IP-adresser från VPC-flödesloggar, särskilt med tanke på dynamisk IP-användning av molnresurser, HTTP-routning av virtuella värdar och annan teknik som kan dölja DNS-namnet som används av en klient från IP-adressen. Övervakning av Cloud DNS-loggar ger insyn i DNS-namn som begärs av klienterna i VPC. Dessa loggar kan övervakas för avvikande domännamn, utvärderas mot hotinformation och Obs! För fullständig avbildning av DNS måste brandväggen blockera utgående UDP/53 (DNS) och TCP/443 (DNS över HTTPS) för att förhindra att klienten använder den externa DNS-namnservern för matchning.

Allvarlighetsgrad: Hög

Kontrollera att DNSSEC är aktiverat för Cloud DNS

Beskrivning: Cloud Domain Name System (DNS) är ett snabbt, tillförlitligt och kostnadseffektivt domännamnssystem som driver miljontals domäner på Internet. Med DNSSEC (Domain Name System Security Extensions) i Cloud DNS kan domänägare vidta enkla åtgärder för att skydda sina domäner mot DNS-kapning och man-in-the-middle och andra attacker. DNSSEC (Domain Name System Security Extensions) ökar säkerheten i DNS-protokollet genom att dns-svar kan verifieras. Att ha en tillförlitlig DNS som översätter ett domännamn som www.example.com dess associerade IP-adress är en allt viktigare byggsten i dagens webbaserade program. Angripare kan kapa den här processen med domän-/IP-sökning och omdirigera användare till en skadlig webbplats via DNS-kapning och man-in-the-middle-attacker. DNSSEC hjälper till att minska risken för sådana attacker genom att kryptografiskt signera DNS-poster. Därför hindrar det angripare från att utfärda falska DNS-svar som kan vilseleda webbläsare till skändliga webbplatser.

Allvarlighetsgrad: Medel

Kontrollera att RDP-åtkomsten är begränsad från Internet

Beskrivning: GCP-brandväggsregler är specifika för ett VPC-nätverk. Varje regel tillåter eller nekar trafik när dess villkor uppfylls. Dess villkor gör det möjligt för användare att ange typen av trafik, till exempel portar och protokoll, och källan eller målet för trafiken, inklusive IP-adresser, undernät och instanser. Brandväggsregler definieras på VPC-nätverksnivå och är specifika för det nätverk där de definieras. Reglerna i sig kan inte delas mellan nätverk. Brandväggsregler stöder endast IPv4-trafik. När du anger en källa för en ingressregel eller ett mål för en utgående regel efter adress kan en IPv4-adress eller IPv4-block i CIDR-notation användas. Generisk (0.0.0.0/0) inkommande trafik från Internet till en VPC- eller VM-instans med RDP på port 3389 kan undvikas. GCP-brandväggsregler i ett VPC-nätverk. Dessa regler gäller för utgående (utgående) trafik från instanser och inkommande (inkommande) trafik till instanser i nätverket. Utgående och inkommande trafikflöden styrs även om trafiken stannar i nätverket (till exempel instans-till-instans-kommunikation). För att en instans ska ha utgående Internetåtkomst måste nätverket ha en giltig Internet-gatewayväg eller anpassad väg vars mål-IP har angetts. Den här vägen definierar helt enkelt sökvägen till Internet för att undvika det mest allmänna mål-IP-intervallet (0.0.0.0/0) som anges från Internet via RDP med standardport 3389. Allmän åtkomst från Internet till ett specifikt IP-intervall bör begränsas.

Allvarlighetsgrad: Hög

Kontrollera att RSASHA1 inte används för nyckelsigneringsnyckeln i CLOUD DNSSEC

Beskrivning: DNSSEC-algoritmnummer i det här registret kan användas i CERT RRs. Zonsignering (DNSSEC) och transaktionssäkerhetsmekanismer (SIG(0) och TSIG) använder särskilda delmängder av dessa algoritmer. Algoritmen som används för nyckelsignering bör vara rekommenderad och bör vara stark. DNSSEC-algoritmnummer (Domain Name System Security Extensions) i det här registret kan användas i CERT RRs. Zonsignering (DNSSEC) och transaktionssäkerhetsmekanismer (SIG(0) och TSIG) använder särskilda delmängder av dessa algoritmer. Algoritmen som används för nyckelsignering bör vara rekommenderad och bör vara stark. När du aktiverar DNSSEC för en hanterad zon eller skapar en hanterad zon med DNSSEC kan användaren välja DNSSEC-signeringsalgoritmerna och typen denial-of-existence. Att ändra DNSSEC-inställningarna gäller endast för en hanterad zon om DNSSEC inte redan är aktiverat. Om du behöver ändra inställningarna för en hanterad zon där den har aktiverats stänger du av DNSSEC och återaktiverar den med olika inställningar.

Allvarlighetsgrad: Medel

Kontrollera att RSASHA1 inte används för zonsigneringsnyckeln i CLOUD DNSSEC

Beskrivning: DNSSEC-algoritmnummer i det här registret kan användas i CERT RRs. Zonsignering (DNSSEC) och transaktionssäkerhetsmekanismer (SIG(0) och TSIG) använder särskilda delmängder av dessa algoritmer. Algoritmen som används för nyckelsignering bör vara rekommenderad och bör vara stark. DNSSEC-algoritmnummer i det här registret kan användas i CERT RRs. Zonsignering (DNSSEC) och transaktionssäkerhetsmekanismer (SIG(0) och TSIG) använder särskilda delmängder av dessa algoritmer. Algoritmen som används för nyckelsignering bör vara rekommenderad och bör vara stark. När du aktiverar DNSSEC för en hanterad zon eller skapar en hanterad zon med DNSSEC kan du välja DNSSEC-signeringsalgoritmerna och typen denial-of-existence. Att ändra DNSSEC-inställningarna gäller endast för en hanterad zon om DNSSEC inte redan är aktiverat. Om det finns behov av att ändra inställningarna för en hanterad zon där den har aktiverats stänger du av DNSSEC och återaktiverar den med olika inställningar.

Allvarlighetsgrad: Medel

Kontrollera att SSH-åtkomsten är begränsad från Internet

Beskrivning: GCP-brandväggsregler är specifika för ett VPC-nätverk. Varje regel tillåter eller nekar trafik när dess villkor uppfylls. Dess villkor gör det möjligt för användaren att ange typen av trafik, till exempel portar och protokoll, och källan eller målet för trafiken, inklusive IP-adresser, undernät och instanser. Brandväggsregler definieras på VPC-nätverksnivå och är specifika för det nätverk där de definieras. Reglerna i sig kan inte delas mellan nätverk. Brandväggsregler stöder endast IPv4-trafik. När du anger en källa för en ingressregel eller ett mål för en utgående regel efter adress kan endast en IPv4-adress eller IPv4-block i CIDR-notation användas. Generisk (0.0.0.0/0) inkommande trafik från Internet till VPC- eller VM-instans med SSH på port 22 kan undvikas. GCP-brandväggsregler i ett VPC-nätverk gäller för utgående (utgående) trafik från instanser och inkommande (inkommande) trafik till instanser i nätverket. Utgående och inkommande trafikflöden styrs även om trafiken stannar i nätverket (till exempel instans-till-instans-kommunikation). För att en instans ska ha utgående Internetåtkomst måste nätverket ha en giltig Internet-gatewayväg eller anpassad väg vars mål-IP har angetts. Den här vägen definierar helt enkelt sökvägen till Internet för att undvika det mest allmänna mål-IP-intervallet (0.0.0.0/0) som anges från Internet via SSH med standardporten "22". Allmän åtkomst från Internet till ett specifikt IP-intervall måste begränsas.

Allvarlighetsgrad: Hög

Kontrollera att standardnätverket inte finns i ett projekt

Beskrivning: För att förhindra användning av "standardnätverk" bör ett projekt inte ha ett "standardnätverk". Standardnätverket har en förkonfigurerad nätverkskonfiguration och genererar automatiskt följande osäkra brandväggsregler:

default-allow-internal: Tillåter inkommande anslutningar för alla protokoll och portar mellan instanser i nätverket.
default-allow-ssh: Tillåter inkommande anslutningar på TCP-port 22 (SSH) från valfri källa till valfri instans i nätverket.
default-allow-rdp: Tillåter inkommande anslutningar på TCP-port 3389(RDP) från valfri källa till valfri instans i nätverket.
default-allow-icmp: Tillåter inkommande ICMP-trafik från valfri källa till valfri instans i nätverket.

Dessa automatiskt skapade brandväggsregler blir inte granskningsloggade och kan inte konfigureras för att aktivera brandväggsregelloggning. Dessutom är standardnätverket ett automatiskt lägesnätverk, vilket innebär att dess undernät använder samma fördefinierade intervall med IP-adresser, och därför går det inte att använda Cloud VPN eller VPC Network Peering med standardnätverket. Baserat på organisationens säkerhet och nätverkskrav bör organisationen skapa ett nytt nätverk och ta bort standardnätverket.

Allvarlighetsgrad: Medel

Kontrollera att loggmåttfiltret och aviseringarna finns för VPC-nätverksändringar

Beskrivning: Vi rekommenderar att ett måttfilter och larm upprättas för ändringar i VPC-nätverket (Virtual Private Cloud). Det går att ha mer än en VPC i ett projekt. Dessutom är det möjligt att skapa en peer-anslutning mellan två virtuella datorer som gör att nätverkstrafik kan dirigeras mellan virtuella datorer. Genom att övervaka ändringar i en VPC kan du se till att VPC-trafikflödet inte påverkas.

Allvarlighetsgrad: Låg

Kontrollera att loggmåttfiltret och aviseringarna finns för ändringar av VPC Network Firewall-regeln

Beskrivning: Vi rekommenderar att ett måttfilter och larm upprättas för regeländringar för virtuellt privat moln (VPC) nätverksbrandvägg. Övervakning av regelhändelser för skapa eller uppdatera brandvägg ger insikter om ändringar i nätverksåtkomsten och kan minska den tid det tar att identifiera misstänkt aktivitet.

Allvarlighetsgrad: Låg

Kontrollera att loggmåttfiltret och aviseringarna finns för VPC-nätverksvägsändringar

Beskrivning: Vi rekommenderar att ett måttfilter och larm upprättas för ändringar av VPC-nätverksvägen (Virtual Private Cloud). GCP-vägar (Google Cloud Platform) definierar de sökvägar som nätverkstrafiken tar från en virtuell datorinstans till ett annat mål. Det andra målet kan finnas i organisationens VPC-nätverk (till exempel en annan virtuell dator) eller utanför det. Varje väg består av ett mål och ett nästa hopp. Trafik vars mål-IP ligger inom målintervallet skickas till nästa hopp för leverans. Genom att övervaka ändringar i routningstabeller ser du till att all VPC-trafik flödar genom en förväntad sökväg.

Allvarlighetsgrad: Låg

Kontrollera att databasflaggan "log_connections" för Cloud SQL PostgreSQL-instansen är inställd på "på"

Beskrivning: Om du aktiverar inställningen log_connections loggas varje försök till anslutning till servern, tillsammans med att klientautentiseringen har slutförts. Det går inte att ändra den här parametern när sessionen har startats. PostgreSQL loggar inte anslutningsförsök som standard. Om du aktiverar inställningen log_connections skapas loggposter för varje anslutningsförsök samt lyckad slutförande av klientautentisering, vilket kan vara användbart vid felsökning av problem och för att fastställa eventuella ovanliga anslutningsförsök till servern. Den här rekommendationen gäller för PostgreSQL-databasinstanser.

Allvarlighetsgrad: Medel

Kontrollera att databasflaggan "log_disconnections" för Cloud SQL PostgreSQL-instansen är inställd på "på"

Beskrivning: Om du aktiverar inställningen log_disconnections loggas slutet av varje session, inklusive sessionsvaraktigheten. PostgreSQL loggar inte sessionsinformation som varaktighet och sessionsslut som standard. Om du aktiverar inställningen log_disconnections skapas loggposter i slutet av varje session, vilket kan vara användbart vid felsökning av problem och fastställa ovanliga aktiviteter under en tidsperiod. Den log_disconnections och log_connections arbeta hand i hand och i allmänhet skulle paret aktiveras/inaktiveras tillsammans. Den här rekommendationen gäller för PostgreSQL-databasinstanser.

Allvarlighetsgrad: Medel

Kontrollera att VPC-flödesloggar är aktiverade för varje undernät i ett VPC-nätverk

Beskrivning: Flödesloggar är en funktion som gör det möjligt för användare att samla in information om IP-trafik som går till och från nätverksgränssnitt i organisationens VPC-undernät. När en flödeslogg har skapats kan användaren visa och hämta sina data i Stackdriver-loggning. Vi rekommenderar att flödesloggar aktiveras för varje affärskritiskt VPC-undernät. VPC-nätverk och undernät ger logiskt isolerade och säkra nätverkspartitioner där GCP-resurser kan startas. När flödesloggar är aktiverade för ett undernät börjar virtuella datorer i undernätet rapportera om alla TCP-flöden (Transmission Control Protocol) och UDP-flöden (User Datagram Protocol). Varje virtuell dator tar exempel på TCP- och UDP-flöden som den ser, inkommande och utgående, om flödet är till eller från en annan virtuell dator, en värd i det lokala datacentret, en Google-tjänst eller en värd på Internet. Om två virtuella GCP-datorer kommunicerar och båda finns i undernät som har VPC-flödesloggar aktiverade rapporterar båda de virtuella datorerna flödena. Flödesloggar stöder följande användningsfall: 1. Nätverksövervakning. 2. Förstå nätverksanvändning och optimera kostnader för nätverkstrafik. 3. Nätverkstekniker. 4. Flödesloggar för säkerhetsanalys i realtid ger insyn i nätverkstrafik för varje virtuell dator i undernätet och kan användas för att identifiera avvikande trafik eller insikter under säkerhetsarbetsflöden.

Allvarlighetsgrad: Låg

Loggning av brandväggsregel ska vara aktiverad

Beskrivning: Den här rekommendationen utvärderar egenskapen logConfig i brandväggsmetadata för att se om den är tom eller innehåller nyckel/värde-paret "enable": false.

Allvarlighetsgrad: Medel

Brandväggen ska inte konfigureras för att vara öppen för offentlig åtkomst

Beskrivning: Den här rekommendationen utvärderar sourceRanges och tillåtna egenskaper för en av två konfigurationer:

Egenskapen sourceRanges innehåller 0.0.0.0/0 och den tillåtna egenskapen innehåller en kombination av regler som innehåller protokoll eller protokoll:port, förutom följande: icmp tcp:22 tcp:443 tcp:3389 udp:3389 sctp:22

Egenskapen sourceRanges innehåller en kombination av IP-intervall som innehåller alla icke-privata IP-adresser och den tillåtna egenskapen innehåller en kombination av regler som tillåter antingen alla tcp-portar eller alla udp-portar.

Allvarlighetsgrad: Hög