Säkerhetsrekommendationer för identitet och åtkomst

Artikel
07/08/2024

I den här artikeln visas alla säkerhetsrekommendationer för identitet och åtkomst som du kan se i Microsoft Defender för molnet.

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.

Dricks

Om en rekommendationsbeskrivning säger Ingen relaterad princip beror det vanligtvis på att rekommendationen är beroende av en annan rekommendation.

Rekommendationen Slutpunktsskyddshälsofel bör till exempel åtgärdas förlitar sig på rekommendationen som kontrollerar om en slutpunktsskyddslösning är installerad (Slutpunktsskyddslösningen ska installeras). Den underliggande rekommendationen har en princip. Att begränsa principer till endast grundläggande rekommendationer förenklar principhanteringen.

Azure-identitets- och åtkomstrekommendationer

Högst 3 ägare bör utses för prenumerationer

Beskrivning: För att minska risken för intrång av komprometterade ägarkonton rekommenderar vi att du begränsar antalet ägarkonton till högst 3 (Relaterad princip: Högst 3 ägare bör utses för din prenumeration).

Allvarlighetsgrad: Hög

Konton med ägarbehörigheter för Azure-resurser ska vara MFA-aktiverade

Beskrivning: Om du bara använder lösenord för att autentisera dina användare lämnar du en attackvektor öppen. Användare använder ofta svaga lösenord för flera tjänster. Genom att aktivera multifaktorautentisering (MFA) ger du bättre säkerhet för dina konton, samtidigt som användarna kan autentisera till nästan alla program med enkel inloggning (SSO). Multifaktorautentisering är en process som användarna uppmanas att använda under inloggningsprocessen för en annan form av identifiering. Till exempel kan en kod skickas till deras mobiltelefon, eller så kan de bli ombedda att skanna fingeravtryck. Vi rekommenderar att du aktiverar MFA för alla konton som har ägarbehörighet för Azure-resurser för att förhindra intrång och attacker. Mer information och vanliga frågor finns här: Hantera multifaktorautentisering (MFA) för dina prenumerationer (ingen relaterad princip).

Allvarlighetsgrad: Hög

Konton med läsbehörigheter för Azure-resurser ska vara MFA-aktiverade

Beskrivning: Om du bara använder lösenord för att autentisera dina användare lämnar du en attackvektor öppen. Användare använder ofta svaga lösenord för flera tjänster. Genom att aktivera multifaktorautentisering (MFA) ger du bättre säkerhet för dina konton, samtidigt som användarna kan autentisera till nästan alla program med enkel inloggning (SSO). Multifaktorautentisering är en process som användarna uppmanas att använda under inloggningsprocessen för ytterligare en form av identifiering. Till exempel kan en kod skickas till deras mobiltelefon, eller så kan de bli ombedda att skanna fingeravtryck. Vi rekommenderar att du aktiverar MFA för alla konton som har läsbehörighet för Azure-resurser för att förhindra intrång och attacker. Mer information och vanliga frågor och svar finns här. (Ingen relaterad princip)

Allvarlighetsgrad: Hög

Konton med skrivbehörighet för Azure-resurser ska vara MFA-aktiverade

Beskrivning: Om du bara använder lösenord för att autentisera dina användare lämnar du en attackvektor öppen. Användare använder ofta svaga lösenord för flera tjänster. Genom att aktivera multifaktorautentisering (MFA) ger du bättre säkerhet för dina konton, samtidigt som användarna kan autentisera till nästan alla program med enkel inloggning (SSO). Multifaktorautentisering är en process som användarna uppmanas att använda under inloggningsprocessen för ytterligare en form av identifiering. Till exempel kan en kod skickas till deras mobiltelefon, eller så kan de bli ombedda att skanna fingeravtryck. Vi rekommenderar att du aktiverar MFA för alla konton som har skrivbehörighet för Azure-resurser för att förhindra intrång och attacker. Mer information och vanliga frågor finns här: Hantera multifaktorautentisering (MFA) för dina prenumerationer (ingen relaterad princip).

Allvarlighetsgrad: Hög

Azure Cosmos DB-konton bör använda Azure Active Directory som den enda autentiseringsmetoden

Beskrivning: Det bästa sättet att autentisera till Azure-tjänster är att använda rollbaserad åtkomstkontroll (RBAC). MED RBAC kan du upprätthålla principen för minsta behörighet och har stöd för möjligheten att återkalla behörigheter som en effektiv svarsmetod när den komprometteras. Du kan konfigurera ditt Azure Cosmos DB-konto för att framtvinga RBAC som den enda autentiseringsmetoden. När tillämpningen har konfigurerats nekas alla andra åtkomstmetoder (primära/sekundära nycklar och åtkomsttoken). (Ingen relaterad princip)

Allvarlighetsgrad: Medel

Blockerade konton med ägarbehörighet för Azure-resurser bör tas bort

Beskrivning: Konton som har blockerats från att logga in på Active Directory bör tas bort från dina Azure-resurser. Dessa konton kan vara mål för angripare som vill hitta sätt att komma åt dina data utan att märkas. (Ingen relaterad princip)

Allvarlighetsgrad: Hög

Blockerade konton med läs- och skrivbehörigheter för Azure-resurser bör tas bort

Allvarlighetsgrad: Hög

Inaktuella konton bör tas bort från prenumerationer

Beskrivning: Användarkonton som har blockerats från att logga in bör tas bort från dina prenumerationer. Dessa konton kan vara mål för angripare som vill hitta sätt att komma åt dina data utan att märkas. (Relaterad princip: Inaktuella konton bör tas bort från din prenumeration).

Allvarlighetsgrad: Hög

Inaktuella konton med ägarbehörigheter bör tas bort från prenumerationer

Allvarlighetsgrad: Hög

Diagnostikloggar i Key Vault ska vara aktiverade

Beskrivning: Aktivera loggar och behålla dem i upp till ett år. På så sätt kan du återskapa aktivitetsspår i undersökningssyfte när en säkerhetsincident inträffar eller nätverket komprometteras. (Relaterad princip: Diagnostikloggar i Key Vault ska vara aktiverade).

Allvarlighetsgrad: Låg

Externa konton med ägarbehörigheter bör tas bort från prenumerationer

Beskrivning: Konton med ägarbehörigheter som har olika domännamn (externa konton) bör tas bort från din prenumeration. Detta förhindrar oövervakad åtkomst. Dessa konton kan vara mål för angripare som vill hitta sätt att komma åt dina data utan att märkas. (Relaterad princip: Externa konton med ägarbehörigheter bör tas bort från din prenumeration).

Allvarlighetsgrad: Hög

Externa konton med läsbehörighet bör tas bort från prenumerationer

Beskrivning: Konton med läsbehörigheter som har olika domännamn (externa konton) bör tas bort från din prenumeration. Detta förhindrar oövervakad åtkomst. Dessa konton kan vara mål för angripare som vill hitta sätt att komma åt dina data utan att märkas. (Relaterad princip: Externa konton med läsbehörighet bör tas bort från din prenumeration).

Allvarlighetsgrad: Hög

Externa konton med skrivbehörigheter bör tas bort från prenumerationer

Beskrivning: Konton med skrivbehörigheter som har olika domännamn (externa konton) bör tas bort från din prenumeration. Detta förhindrar oövervakad åtkomst. Dessa konton kan vara mål för angripare som vill hitta sätt att komma åt dina data utan att märkas. (Relaterad princip: Externa konton med skrivbehörighet bör tas bort från din prenumeration).

Allvarlighetsgrad: Hög

Brandväggen ska vara aktiverad i Key Vault

Beskrivning: Nyckelvalvets brandvägg förhindrar obehörig trafik från att nå ditt nyckelvalv och ger ytterligare ett skyddslager för dina hemligheter. Aktivera brandväggen för att se till att endast trafik från tillåtna nätverk kan komma åt ditt nyckelvalv. (Relaterad princip: Brandväggen ska vara aktiverad i Key Vault).

Allvarlighetsgrad: Medel

Gästkonton med ägarbehörighet för Azure-resurser bör tas bort

Beskrivning: Konton med ägarbehörigheter som har etablerats utanför Azure Active Directory-klientorganisationen (olika domännamn) bör tas bort från dina Azure-resurser. Gästkonton hanteras inte enligt samma standarder som företagsklientidentiteter. Dessa konton kan vara mål för angripare som vill hitta sätt att komma åt dina data utan att märkas. (Ingen relaterad princip)

Allvarlighetsgrad: Hög

Gästkonton med läsbehörighet för Azure-resurser bör tas bort

Beskrivning: Konton med läsbehörigheter som har etablerats utanför Azure Active Directory-klientorganisationen (olika domännamn) bör tas bort från dina Azure-resurser. Gästkonton hanteras inte enligt samma standarder som företagsklientidentiteter. Dessa konton kan vara mål för angripare som vill hitta sätt att komma åt dina data utan att märkas. (Ingen relaterad princip)

Allvarlighetsgrad: Hög

Gästkonton med skrivbehörighet för Azure-resurser bör tas bort

Beskrivning: Konton med skrivbehörigheter som har etablerats utanför Azure Active Directory-klientorganisationen (olika domännamn) bör tas bort från dina Azure-resurser. Gästkonton hanteras inte enligt samma standarder som företagsklientidentiteter. Dessa konton kan vara mål för angripare som vill hitta sätt att komma åt dina data utan att märkas. (Ingen relaterad princip)

Allvarlighetsgrad: Hög

Key Vault-nycklar bör ha ett utgångsdatum

Beskrivning: Kryptografiska nycklar ska ha ett definierat förfallodatum och inte vara permanenta. Nycklar som är giltiga för alltid ger en potentiell angripare mer tid att kompromettera nyckeln. Vi rekommenderar att du anger förfallodatum för kryptografiska nycklar. (Relaterad princip: Key Vault-nycklar bör ha ett förfallodatum).

Allvarlighetsgrad: Hög

Key Vault-hemligheter bör ha ett utgångsdatum

Beskrivning: Hemligheter bör ha ett definierat förfallodatum och inte vara permanenta. Hemligheter som är giltiga för alltid ger en potentiell angripare mer tid att kompromettera dem. Vi rekommenderar att du anger förfallodatum för hemligheter. (Relaterad princip: Key Vault-hemligheter bör ha ett utgångsdatum).

Allvarlighetsgrad: Hög

Nyckelvalv bör ha rensningsskydd aktiverat

Beskrivning: Skadlig borttagning av ett nyckelvalv kan leda till permanent dataförlust. En skadlig insider i din organisation kan potentiellt ta bort och rensa nyckelvalv. Rensningsskydd skyddar dig mot insiderattacker genom att framtvinga en obligatorisk kvarhållningsperiod för mjuka borttagna nyckelvalv. Ingen i din organisation eller Microsoft kommer att kunna rensa dina nyckelvalv under kvarhållningsperioden för mjuk borttagning. (Relaterad princip: Nyckelvalv bör ha rensningsskydd aktiverat).

Allvarlighetsgrad: Medel

Nyckelvalv bör ha mjuk borttagning aktiverat

Beskrivning: Om du tar bort ett nyckelvalv utan mjuk borttagning tas alla hemligheter, nycklar och certifikat som lagras i nyckelvalvet bort permanent. Oavsiktlig borttagning av ett nyckelvalv kan leda till permanent dataförlust. Med mjuk borttagning kan du återställa ett nyckelvalv som tagits bort av misstag under en konfigurerbar kvarhållningsperiod. (Relaterad princip: Nyckelvalv bör ha mjuk borttagning aktiverat).

Allvarlighetsgrad: Hög

MFA ska vara aktiverat på konton med ägarbehörigheter för prenumerationer

Beskrivning: Multifaktorautentisering (MFA) ska aktiveras för alla prenumerationskonton med ägarbehörighet för att förhindra intrång i konton eller resurser. (Relaterad princip: MFA bör aktiveras på konton med ägarbehörighet för din prenumeration).

Allvarlighetsgrad: Hög

MFA ska vara aktiverat på konton med läsbehörigheter för prenumerationer

Beskrivning: Multifaktorautentisering (MFA) ska aktiveras för alla prenumerationskonton med läsbehörighet för att förhindra intrång i konton eller resurser. (Relaterad princip: MFA ska vara aktiverat på konton med läsbehörighet för din prenumeration).

Allvarlighetsgrad: Hög

MFA ska aktiveras på konton med skrivbehörighet för prenumerationer

Beskrivning: Multifaktorautentisering (MFA) ska aktiveras för alla prenumerationskonton med skrivbehörighet för att förhindra intrång i konton eller resurser. (Relaterad princip: MFA ska vara aktiverade konton med skrivbehörighet för din prenumeration).

Allvarlighetsgrad: Hög

Microsoft Defender för Key Vault ska vara aktiverat

Beskrivning: Microsoft Defender för molnet innehåller Microsoft Defender för Key Vault, vilket ger ytterligare ett lager med säkerhetsinformation. Microsoft Defender för Key Vault identifierar ovanliga och potentiellt skadliga försök att komma åt eller utnyttja Key Vault-konton.

Skydd mot den här planen debiteras enligt beskrivningen på sidan Defender-planer . Om du inte har några nyckelvalv i den här prenumerationen debiteras du inte. Om du senare skapar nyckelvalv för den här prenumerationen skyddas de automatiskt och avgifterna börjar. Läs mer om prisinformationen per region. Läs mer i Introduktion till Microsoft Defender för Key Vault. (Relaterad princip: Azure Defender för Key Vault ska vara aktiverat).

Allvarlighetsgrad: Hög

Behörigheter för inaktiva identiteter i din Azure-prenumeration bör återkallas

Beskrivning: Microsoft Defender för molnet har identifierat en identitet som inte har utfört någon åtgärd på någon resurs i din Azure-prenumeration under de senaste 45 dagarna. Vi rekommenderar att du återkallar behörigheter för inaktiva identiteter för att minska attackytan i din molnmiljö.

Allvarlighetsgrad: Medel

Privat slutpunkt ska konfigureras för Key Vault

Beskrivning: Privat länk ger ett sätt att ansluta Key Vault till dina Azure-resurser utan att skicka trafik via det offentliga Internet. Privat länk ger skydd på djupet mot dataexfiltrering. (Relaterad princip: Privat slutpunkt ska konfigureras för Key Vault).

Allvarlighetsgrad: Medel

Offentlig åtkomst för lagringskonto bör inte tillåtas

Beskrivning: Anonym offentlig läsåtkomst till containrar och blobar i Azure Storage är ett bekvämt sätt att dela data, men kan medföra säkerhetsrisker. För att förhindra dataintrång som orsakas av oönstrade anonym åtkomst rekommenderar Microsoft att du förhindrar offentlig åtkomst till ett lagringskonto om inte ditt scenario kräver det. (Relaterad princip: Offentlig åtkomst till lagringskontot bör inte tillåtas).

Allvarlighetsgrad: Medel

Det bör finnas fler än en ägare tilldelad till prenumerationer

Beskrivning: Utse fler än en prenumerationsägare för att få administratörsåtkomstredundans. (Relaterad princip: Det bör finnas fler än en ägare tilldelad till din prenumeration).

Allvarlighetsgrad: Hög

Giltighetsperioden för certifikat som lagras i Azure Key Vault får inte överstiga 12 månader

Beskrivning: Kontrollera att dina certifikat inte har en giltighetsperiod som överskrider 12 månader. (Relaterad princip: Certifikaten bör ha den angivna maximala giltighetsperioden).

Allvarlighetsgrad: Medel

Överetablerade Identiteter i Azure ska bara ha de behörigheter som krävs (förhandsversion)

Beskrivning: Överetablerade identiteter, eller över behörighetsidentiteter, använder inte många av sina beviljade behörigheter. Regelbundet rätt storlek behörigheter för dessa identiteter för att minska risken för missbruk av behörigheter, antingen oavsiktligt eller skadligt. Den här åtgärden minskar den potentiella explosionsradien under en säkerhetsincident.

Allvarlighetsgrad: Medel

Superidentiteter i din Azure-miljö bör tas bort (förhandsversion)

Beskrivning: Superidentitet är en mänsklig identitet eller arbetsbelastningsidentitet, till exempel användare, tjänsthuvudnamn och serverlösa funktioner som har administratörsbehörighet och som kan utföra alla åtgärder på alla resurser i infrastrukturen. Superidentiteter är extremt hög risk, eftersom missbruk av skadliga eller oavsiktliga behörigheter kan leda till katastrofala avbrott i tjänsten, tjänstförsämring eller dataläckage. Superidentiteter utgör ett stort hot mot molninfrastrukturen. För många superidentiteter kan skapa överdrivna risker och öka explosionsradien under ett intrång.

Allvarlighetsgrad: Medel

AWS-identitets- och åtkomstrekommendationer

Amazon Elasticsearch Service-domäner bör finnas i en VPC

Beskrivning: VPC kan inte innehålla domäner med en offentlig slutpunkt. Detta utvärderar inte konfigurationen för VPC-undernätsdirigering för att fastställa offentlig nåbarhet.

Allvarlighetsgrad: Hög

Amazon S3-behörigheter som beviljats andra AWS-konton i bucketprinciper bör begränsas

Beskrivning: Implementering av åtkomst med minst privilegier är grundläggande för att minska säkerhetsrisken och effekten av fel eller skadliga avsikter. Om en S3-bucketprincip tillåter åtkomst från externa konton kan det resultera i dataexfiltrering av ett insiderhot eller en angripare. Parametern "blacklistedactionpatterns" möjliggör en lyckad utvärdering av regeln för S3-bucketar. Parametern ger åtkomst till externa konton för åtgärdsmönster som inte ingår i listan "blacklistedactionpatterns".

Allvarlighetsgrad: Hög

Undvik att använda "rotkontot"

Beskrivning: Rotkontot har obegränsad åtkomst till alla resurser i AWS-kontot. Vi rekommenderar starkt att du undviker att använda det här kontot. Rotkontot är det mest privilegierade AWS-kontot. Om du minimerar användningen av det här kontot och antar principen om lägsta behörighet för åtkomsthantering minskar risken för oavsiktliga ändringar och oavsiktligt avslöjande av mycket privilegierade autentiseringsuppgifter.

Allvarlighetsgrad: Hög

AWS KMS-nycklar bör inte oavsiktligt tas bort

Beskrivning: Den här kontrollen kontrollerar om KMS-nycklar är schemalagda för borttagning. Kontrollen misslyckas om en KMS-nyckel har schemalagts för borttagning. KMS-nycklar kan inte återställas när de har tagits bort. Data som krypteras under en KMS-nyckel är också permanent oåterkalleliga om KMS-nyckeln tas bort. Om meningsfulla data har krypterats under en KMS-nyckel som har schemalagts för borttagning bör du överväga att dekryptera data eller omkryptera data under en ny KMS-nyckel om du inte avsiktligt utför en kryptografisk radering. När en KMS-nyckel har schemalagts för borttagning framtvingas en obligatorisk väntetid för att ge tid att ångra borttagningen, om den schemalades som ett fel. Standardvänteperioden är 30 dagar, men den kan minskas till så kort som sju dagar när KMS-nyckeln är schemalagd för borttagning. Under väntetiden kan den schemalagda borttagningen avbrytas och KMS-nyckeln tas inte bort. Mer information om hur du tar bort KMS-nycklar finns i Ta bort KMS-nycklar i utvecklarguiden för AWS Key Management Service.

Allvarlighetsgrad: Hög

Överetablerade AWS-identiteter bör endast ha nödvändiga behörigheter (förhandsversion)

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 definierat åtgärder och ansvarsområden, kan öka explosionsradien om en användare, nyckel eller resurs komprometteras. Ta bort onödiga behörigheter och upprätta granskningsprocesser för att uppnå de minst privilegierade behörigheterna.

Allvarlighetsgrad: Medel

AWS WAF Klassisk global webb-ACL-loggning ska vara aktiverad

Beskrivning: Den här kontrollen kontrollerar om loggning är aktiverat för en global webb-ACL för AWS WAF. Den här kontrollen misslyckas om loggning inte är aktiverad för webb-ACL:en. Loggning är en viktig del av att upprätthålla tillförlitlighet, tillgänglighet och prestanda för AWS WAF globalt. Det är ett affärs- och efterlevnadskrav i många organisationer och gör att du kan felsöka programbeteende. Den innehåller också detaljerad information om trafiken som analyseras av webb-ACL:en som är kopplad till AWS WAF.

Allvarlighetsgrad: Medel

CloudFront-distributioner bör ha ett standardrotobjekt konfigurerat

Beskrivning: Den här kontrollen kontrollerar om en Amazon CloudFront-distribution har konfigurerats för att returnera ett specifikt objekt som är standardrotobjektet. Kontrollen misslyckas om CloudFront-distributionen inte har konfigurerat ett standardrotobjekt. En användare kan ibland begära distributionens rot-URL i stället för ett objekt i distributionen. När detta inträffar kan du undvika att exponera innehållet i webbdistributionen genom att ange ett standardrotobjekt.

Allvarlighetsgrad: Hög

CloudFront-distributioner bör ha ursprungsåtkomstidentitet aktiverad

Beskrivning: Den här kontrollen kontrollerar om en Amazon CloudFront-distribution med Amazon S3 Origin-typen har ursprungsåtkomstidentitet (OAI) konfigurerad. Kontrollen misslyckas om OAI inte har konfigurerats. CloudFront OAI hindrar användare från att komma åt S3-bucketinnehåll direkt. När användarna kommer åt en S3-bucket direkt kringgår de effektivt CloudFront-distributionen och eventuella behörigheter som tillämpas på det underliggande S3-bucketinnehållet.

Allvarlighetsgrad: Medel

Validering av CloudTrail-loggfil ska vara aktiverat

Beskrivning: För att säkerställa ytterligare integritetskontroll av CloudTrail-loggar rekommenderar vi att du aktiverar filvalidering på alla CloudTrails.

Allvarlighetsgrad: Låg

CloudTrail ska vara aktiverat

Beskrivning: AWS CloudTrail är en webbtjänst som registrerar AWS API-anrop för ditt konto och levererar loggfiler till dig. Alla tjänster aktiverar inte loggning som standard för alla API:er och händelser. Du bör implementera ytterligare spårningsspår förutom CloudTrail och granska dokumentationen för varje tjänst i CloudTrail-tjänster och integreringar som stöds av CloudTrail.

Allvarlighetsgrad: Hög

CloudTrail-spår bör integreras med CloudWatch-loggar

Beskrivning: Förutom att samla in CloudTrail-loggar i en angiven S3-bucket för långsiktig analys kan realtidsanalys utföras genom att konfigurera CloudTrail för att skicka loggar till CloudWatch-loggar. För en spårning som är aktiverad i alla regioner i ett konto skickar CloudTrail loggfiler från alla dessa regioner till en Logggrupp för CloudWatch-loggar. Vi rekommenderar att CloudTrail-loggar skickas till CloudWatch-loggar för att säkerställa att AWS-kontoaktiviteten registreras, övervakas och larmas på lämpligt sätt. Att skicka CloudTrail-loggar till CloudWatch-loggar underlättar realtids- och historisk aktivitetsloggning baserat på användare, API, resurs och IP-adress, och ger möjlighet att upprätta larm och meddelanden för avvikande eller känslighetskontoaktivitet.

Allvarlighetsgrad: Låg

Databasloggning ska vara aktiverad

Beskrivning: Den här kontrollen kontrollerar om följande loggar för Amazon RDS är aktiverade och skickas till CloudWatch-loggar:

Oracle: (Alert, Audit, Trace, Listener)
PostgreSQL: (Postgresql, Upgrade)
MySQL: (Audit, Error, General, SlowQuery)
MariaDB: (Audit, Error, General, SlowQuery)
SQL Server: (Fel, agent)
Aurora: (Audit, Error, General, SlowQuery)
Aurora-MySQL: (Audit, Error, General, SlowQuery)
Aurora-PostgreSQL: (Postgresql, Upgrade). RDS-databaser bör ha relevanta loggar aktiverade. Databasloggning innehåller detaljerade poster över begäranden som görs till RDS. Databasloggar kan hjälpa till med säkerhets- och åtkomstgranskningar och kan hjälpa till att diagnostisera tillgänglighetsproblem.

Allvarlighetsgrad: Medel

Inaktivera direkt internetåtkomst för Amazon Sage Maker-notebook-instanser

Beskrivning: Direkt internetåtkomst bör inaktiveras för en Sage Maker Notebook-instans. Detta kontrollerar om fältet DirectInternetAccess är inaktiverat för notebook-instansen. Din instans ska konfigureras med en VPC och standardinställningen ska vara Inaktivera – Få åtkomst till Internet via en VPC. För att aktivera Internetåtkomst för att träna eller vara värd för modeller från en notebook-fil kontrollerar du att din VPC har en NAT-gateway och att din säkerhetsgrupp tillåter utgående anslutningar. Se till att åtkomsten till Sage Maker-konfigurationen endast är begränsad till behöriga användare och begränsa användarnas IAM-behörigheter för att ändra inställningar och resurser för Sage Maker.

Allvarlighetsgrad: Hög

Konfigurera inte åtkomstnycklar under den inledande användarkonfigurationen för alla IAM-användare som har ett konsollösenord

Beskrivning: AWS-konsolen standard kryssrutan för att skapa åtkomstnycklar till aktiverad. Detta resulterar i att många åtkomstnycklar genereras i onödan. Förutom onödiga autentiseringsuppgifter genererar det också onödigt hanteringsarbete vid granskning och rotation av dessa nycklar. Att kräva att ytterligare åtgärder vidtas av användaren efter att deras profil har skapats ger en starkare indikation på avsikten att åtkomstnycklar är [a] nödvändiga för deras arbete och [b] när åtkomstnyckeln har upprättats för ett konto som nycklarna kan användas någonstans i organisationen.

Allvarlighetsgrad: Medel

Se till att en supportroll har skapats för att hantera incidenter med AWS-support

Beskrivning: AWS tillhandahåller ett supportcenter som kan användas för incidentmeddelanden och incidenthantering, samt teknisk support och kundtjänst. Skapa en IAM-roll för att tillåta behöriga användare att hantera incidenter med AWS-support. När du implementerar lägsta behörighet för åtkomstkontroll kräver en IAM-roll en lämplig IAM-princip för att tillåta supportcenteråtkomst för att hantera incidenter med AWS-support.

Allvarlighetsgrad: Låg

Se till att åtkomstnycklar roteras var 90:e dag eller mindre

Beskrivning: Åtkomstnycklar består av ett åtkomstnyckel-ID och en hemlig åtkomstnyckel som används för att signera programmatiska begäranden som du gör i AWS. AWS-användare behöver sina egna åtkomstnycklar för att göra programmatiska anrop till AWS från AWS-kommandoradsgränssnittet (AWS CLI), Verktyg för Windows PowerShell, AWS SDK:er eller direkta HTTP-anrop med api:erna för enskilda AWS-tjänster. Vi rekommenderar att alla åtkomstnycklar roteras regelbundet. Roterande åtkomstnycklar minskar möjligheten för en åtkomstnyckel som är associerad med ett komprometterat eller avslutat konto som ska användas. Åtkomstnycklar 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: Medel

Kontrollera att AWS-konfigurationen är aktiverad i alla regioner

Beskrivning: AWS Config är en webbtjänst som utför konfigurationshantering av AWS-resurser som stöds i ditt konto och levererar loggfiler till dig. Den registrerade informationen innehåller konfigurationsobjektet (AWS-resursen), relationer mellan konfigurationsobjekt (AWS-resurser), eventuella konfigurationsändringar mellan resurser. Vi rekommenderar att du aktiverar AWS Config i alla regioner.

AWS-konfigurationsobjekthistoriken som registrerats av AWS Config möjliggör säkerhetsanalys, resursändringsspårning och efterlevnadsgranskning.

Allvarlighetsgrad: Medel

Kontrollera att CloudTrail är aktiverat i alla regioner

Beskrivning: AWS CloudTrail är en webbtjänst som registrerar AWS API-anrop för ditt konto och levererar loggfiler till dig. Den registrerade informationen omfattar IDENTITETen för API-anroparen, tiden för API-anropet, API-anroparens käll-IP-adress, begäransparametrarna och de svarselement som returneras av AWS-tjänsten. CloudTrail innehåller en historik över AWS API-anrop för ett konto, inklusive API-anrop som görs via hanteringskonsolen, SDK:er, kommandoradsverktyg och AWS-tjänster på högre nivå (till exempel CloudFormation). AWS API-anropshistoriken som skapats av CloudTrail möjliggör säkerhetsanalys, resursändringsspårning och efterlevnadsgranskning. Dessutom:

Om du kontrollerar att det finns ett spår för flera regioner ser du till att oväntad aktivitet som inträffar i annars oanvända regioner identifieras.
Om du kontrollerar att det finns en spårning i flera regioner ser du till att "Global Service Logging" är aktiverad för en spårning som standard för att samla in inspelning av händelser som genererats på globala AWS-tjänster.
För en spårning i flera regioner kontrollerar du att hanteringshändelser har konfigurerats för alla typer av läs-/skrivåtgärder som säkerställer registrering av hanteringsåtgärder som utförs på alla resurser i ett AWS-konto.

Allvarlighetsgrad: Hög

Se till att autentiseringsuppgifter som inte används i 90 dagar eller senare är inaktiverade

Beskrivning: AWS IAM-användare kan komma åt AWS-resurser med olika typer av autentiseringsuppgifter, till exempel lösenord eller åtkomstnycklar. Vi rekommenderar att alla autentiseringsuppgifter som inte har använts på 90 dagar eller senare tas bort eller inaktiveras. Om du inaktiverar eller tar bort onödiga autentiseringsuppgifter minskar du möjligheten att använda autentiseringsuppgifter som är associerade med ett komprometterat eller övergivet konto.

Allvarlighetsgrad: Medel

Se till att lösenordsprincipen för IAM upphör att gälla inom 90 dagar eller mindre

Beskrivning: IAM-lösenordsprinciper kan kräva att lösenord roteras eller upphör att gälla efter ett visst antal dagar. Vi rekommenderar att lösenordsprincipen upphör att gälla efter 90 dagar eller mindre. Om du minskar livslängden för lösenord ökar kontoåterhämtningen mot brute force-inloggningsförsök. Dessutom hjälper det att kräva regelbundna lösenordsändringar i följande scenarier:

Lösenord kan stjälas eller komprometteras ibland utan din vetskap. Detta kan inträffa via en systemkompromiss, programvarusårbarhet eller ett internt hot.
Vissa företags- och myndighetswebbfilter eller proxyservrar har möjlighet att avlyssna och registrera trafik även om den är krypterad.
Många använder samma lösenord för många system, till exempel arbete, e-post och personligt.
Komprometterade slutanvändares arbetsstationer kan ha en tangenttryckningsloggare.

Allvarlighetsgrad: Låg

Se till att IAM-lösenordsprincipen förhindrar återanvändning av lösenord

Beskrivning: IAM-lösenordsprinciper kan förhindra återanvändning av ett visst lösenord av samma användare. Vi rekommenderar att lösenordsprincipen förhindrar återanvändning av lösenord. Förhindra återanvändning av lösenord ökar kontoåterhämtningen mot brute force-inloggningsförsök.

Allvarlighetsgrad: Låg

Se till att IAM-lösenordsprincipen kräver minst en gemen bokstav

Beskrivning: Lösenordsprinciper används delvis för att framtvinga krav på lösenordskomplexitet. IAM-lösenordsprinciper kan användas för att säkerställa att lösenordet består av olika teckenuppsättningar. Vi rekommenderar att lösenordsprincipen kräver minst en gemen bokstav. Om du anger en princip för lösenordskomplexitet ökar kontoåterhämtningen mot brute force-inloggningsförsök.

Allvarlighetsgrad: Medel

Se till att IAM-lösenordsprincipen kräver minst ett nummer

Beskrivning: Lösenordsprinciper används delvis för att framtvinga krav på lösenordskomplexitet. IAM-lösenordsprinciper kan användas för att säkerställa att lösenordet består av olika teckenuppsättningar. Vi rekommenderar att lösenordsprincipen kräver minst ett nummer. Om du anger en princip för lösenordskomplexitet ökar kontoåterhämtningen mot brute force-inloggningsförsök.

Allvarlighetsgrad: Medel

Se till att IAM-lösenordsprincipen kräver minst en symbol

Beskrivning: Lösenordsprinciper används delvis för att framtvinga krav på lösenordskomplexitet. IAM-lösenordsprinciper kan användas för att säkerställa att lösenordet består av olika teckenuppsättningar. Vi rekommenderar att lösenordsprincipen kräver minst en symbol. Om du anger en princip för lösenordskomplexitet ökar kontoåterhämtningen mot brute force-inloggningsförsök.

Allvarlighetsgrad: Medel

Kontrollera att IAM-lösenordsprincipen kräver minst en versal

Beskrivning: Lösenordsprinciper används delvis för att framtvinga krav på lösenordskomplexitet. IAM-lösenordsprinciper kan användas för att säkerställa att lösenordet består av olika teckenuppsättningar. Vi rekommenderar att lösenordsprincipen kräver minst en versal. Om du anger en princip för lösenordskomplexitet ökar kontoåterhämtningen mot brute force-inloggningsförsök.

Allvarlighetsgrad: Medel

Se till att lösenordsprincipen för IAM kräver minst 14 längder

Beskrivning: Lösenordsprinciper används delvis för att framtvinga krav på lösenordskomplexitet. IAM-lösenordsprinciper kan användas för att säkerställa att lösenordet är minst en viss längd. Vi rekommenderar att lösenordsprincipen kräver en minsta lösenordslängd "14". Om du anger en princip för lösenordskomplexitet ökar kontoåterhämtningen mot brute force-inloggningsförsök.

Allvarlighetsgrad: Medel

Se till att multifaktorautentisering (MFA) är aktiverat för alla IAM-användare som har ett konsollösenord

Beskrivning: Multifaktorautentisering (MFA) lägger till ett extra skyddslager ovanpå ett användarnamn och lösenord. När MFA är aktiverat, när en användare loggar in på en AWS-webbplats, uppmanas de att ange användarnamn och lösenord samt en autentiseringskod från sin AWS MFA-enhet. Vi rekommenderar att MFA aktiveras för alla konton som har ett konsollösenord. Aktivering av MFA ger ökad säkerhet för konsolåtkomst eftersom det kräver att autentiseringsobjektet har en enhet som genererar en tidskänslig nyckel och har kunskap om en autentiseringsuppgift.

Allvarlighetsgrad: Medel

GuardDuty ska vara aktiverat

Beskrivning: För att ge ytterligare skydd mot intrång bör GuardDuty aktiveras på ditt AWS-konto och din region.

GuardDuty kanske inte är en fullständig lösning för varje miljö.

Allvarlighetsgrad: Medel

MFA för maskinvara ska vara aktiverat för "rotkontot"

Beskrivning: Rotkontot är den mest privilegierade användaren i ett konto. MFA lägger till ett extra skyddslager ovanpå ett användarnamn och lösenord. När MFA är aktiverat uppmanas en användare att ange användarnamn och lösenord och en autentiseringskod från sin AWS MFA-enhet när en användare loggar in på en AWS-webbplats. För nivå 2 rekommenderar vi att du skyddar rotkontot med en maskinvaru-MFA. En maskinvaru-MFA har en mindre attackyta än en virtuell MFA. En MFA för maskinvara drabbas till exempel inte av den attackyta som introducerades av den mobila smarttelefonen som en virtuell MFA finns på. När du använder maskinvara för MFA för många kan många konton skapa ett problem med hantering av logistiska enheter. Om detta inträffar bör du överväga att implementera den här rekommendationen på nivå 2 selektivt till de högsta säkerhetskontona. Du kan sedan tillämpa rekommendationen Nivå 1 på de återstående kontona.

Allvarlighetsgrad: Låg

IAM-autentisering bör konfigureras för RDS-kluster

Beskrivning: Den här kontrollen kontrollerar om ett RDS DB-kluster har IAM-databasautentisering aktiverat. IAM-databasautentisering möjliggör lösenordsfri autentisering till databasinstanser. Autentiseringen använder en autentiseringstoken. Nätverkstrafik till och från databasen krypteras med hjälp av SSL. Mer information finns i IAM-databasautentisering i Amazon Aurora-användarhandboken.

Allvarlighetsgrad: Medel

IAM-autentisering bör konfigureras för RDS-instanser

Beskrivning: Den här kontrollen kontrollerar om en RDS DB-instans har IAM-databasautentisering aktiverat. IAM-databasautentisering tillåter autentisering till databasinstanser med en autentiseringstoken i stället för ett lösenord. Nätverkstrafik till och från databasen krypteras med hjälp av SSL. Mer information finns i IAM-databasautentisering i Amazon Aurora-användarhandboken.

Allvarlighetsgrad: Medel

IAM-kundhanterade principer bör inte tillåta dekrypteringsåtgärder på alla KMS-nycklar

Beskrivning: Kontrollerar om standardversionen av IAM-kundhanterade principer tillåter att huvudkonton använder AWS KMS-dekrypteringsåtgärder på alla resurser. Den här kontrollen använder Zelkova, en automatiserad resonemangsmotor, för att verifiera och varna dig om principer som kan ge bred åtkomst till dina hemligheter över AWS-konton. Den här kontrollen misslyckas om åtgärderna "kms: Decrypt" eller "kms: ReEncryptFrom" tillåts på alla KMS-nycklar. Kontrollen utvärderar både anslutna och ej kopplade kundhanterade principer. Den kontrollerar inte infogade principer eller AWS-hanterade principer. Med AWS KMS styr du vem som kan använda dina KMS-nycklar och få åtkomst till dina krypterade data. IAM-principer definierar vilka åtgärder en identitet (användare, grupp eller roll) kan utföra på vilka resurser. Enligt rekommenderade säkerhetsmetoder rekommenderar AWS att du tillåter minst behörighet. Med andra ord bör du endast bevilja identiteter behörigheterna "kms:Decrypt" eller "kms:ReEncryptFrom" och endast för de nycklar som krävs för att utföra en uppgift. Annars kan användaren använda nycklar som inte är lämpliga för dina data. I stället för att bevilja behörigheter för alla nycklar ska du fastställa den minsta uppsättning nycklar som användarna behöver för att få åtkomst till krypterade data. Utforma sedan principer som gör det möjligt för användare att endast använda dessa nycklar. Tillåt till exempel inte behörigheten "kms: Dekryptera" på alla KMS-nycklar. Tillåt i stället endast "kms: Dekryptera" på nycklar i en viss region för ditt konto. Genom att anta principen om lägsta behörighet kan du minska risken för oavsiktligt avslöjande av dina data.

Allvarlighetsgrad: Medel

IAM-kundhanterade principer som du skapar bör inte tillåta jokerteckenåtgärder för tjänster

Beskrivning: Den här kontrollen kontrollerar om IAM-identitetsbaserade principer som du skapar har Tillåt-instruktioner som använder jokertecknet * för att bevilja behörigheter för alla åtgärder för alla tjänster. Kontrollen misslyckas om någon principsats innehåller "Effekt": "Tillåt" med "Åtgärd": "Tjänst:*". Följande instruktion i en princip resulterar till exempel i ett misslyckat resultat.

'Statement': [
{
  'Sid': 'EC2-Wildcard',
  'Effect': 'Allow',
  'Action': 'ec2:*',
  'Resource': '*'
}

Kontrollen misslyckas också om du använder "Effekt": "Tillåt" med "NotAction": "service:". I så fall ger Elementet NotAction åtkomst till alla åtgärder i en AWS-tjänst, förutom de åtgärder som anges i NotAction. Den här kontrollen gäller endast för kundhanterade IAM-principer. Den gäller inte för IAM-principer som hanteras av AWS. När du tilldelar behörigheter till AWS-tjänster är det viktigt att begränsa tillåtna IAM-åtgärder i dina IAM-principer. Du bör begränsa IAM-åtgärder till endast de åtgärder som behövs. Detta hjälper dig att etablera behörigheter med minst behörighet. Alltför tillåtande principer kan leda till behörighetseskalering om principerna är kopplade till ett IAM-huvudnamn som kanske inte kräver behörigheten. I vissa fall kanske du vill tillåta IAM-åtgärder som har ett liknande prefix, till exempel DescribeFlowLogs och DescribeAvailabilityZones. I dessa auktoriserade fall kan du lägga till ett suffix med jokertecken i det gemensamma prefixet. Till exempel ec2:Describe.

Den här kontrollen skickas om du använder en prefixerad IAM-åtgärd med ett suffix med jokertecken. Följande instruktion i en princip resulterar till exempel i en godkänd sökning.

 'Statement': [
{
  'Sid': 'EC2-Wildcard',
  'Effect': 'Allow',
  'Action': 'ec2:Describe*',
  'Resource': '*'
}

När du grupperar relaterade IAM-åtgärder på det här sättet kan du också undvika att överskrida storleksgränserna för IAM-principen.

Allvarlighetsgrad: Låg

IAM-principer bör endast kopplas till grupper eller roller

Beskrivning: Som standard har IAM-användare, grupper och roller ingen åtkomst till AWS-resurser. IAM-principer är det sätt på vilket privilegier beviljas användare, grupper eller roller. Vi rekommenderar att IAM-principer tillämpas direkt på grupper och roller men inte på användare. Att tilldela behörigheter på grupp- eller rollnivå minskar komplexiteten i åtkomsthanteringen i takt med att antalet användare ökar. Att minska komplexiteten i åtkomsthantering kan också minska möjligheten för ett huvudnamn att oavsiktligt ta emot eller behålla överdrivna privilegier.

Allvarlighetsgrad: Låg

IAM-principer som tillåter fullständiga administrativa behörigheter för ":" bör inte skapas

Beskrivning: IAM-principer är det sätt på vilket behörigheter beviljas användare, grupper eller roller. Det rekommenderas och anses vara ett standardsäkerhetsråd för att bevilja minst privilegier, det villa är att endast bevilja de behörigheter som krävs för att utföra en uppgift. Ta reda på vad användarna behöver göra och skapa sedan principer för dem som låter användarna endast utföra dessa uppgifter, i stället för att tillåta fullständig administrativ behörighet. Det är säkrare att börja med en minsta uppsättning behörigheter och bevilja ytterligare behörigheter efter behov, i stället för att börja med behörigheter som är för överseende och sedan försöka skärpa dem senare. Om du ger fullständig administrativ behörighet i stället för att begränsa till den minsta uppsättning behörigheter som användaren måste utföra exponeras resurserna för potentiellt oönskade åtgärder. IAM-principer som har en instruktion med "Effect": "Allow" with "Action": "" over "Resource": "" bör tas bort.

Allvarlighetsgrad: Hög

IAM-huvudkonton bör inte ha infogade IAM-principer som tillåter dekrypteringsåtgärder på alla KMS-nycklar

Beskrivning: Kontrollerar om de infogade principer som är inbäddade i dina IAM-identiteter (roll, användare eller grupp) tillåter AWS KMS-dekrypteringsåtgärder på alla KMS-nycklar. Den här kontrollen använder Zelkova, en automatiserad resonemangsmotor, för att verifiera och varna dig om principer som kan ge bred åtkomst till dina hemligheter över AWS-konton. Den här kontrollen misslyckas om kms:Decrypt eller kms:ReEncryptFrom åtgärder tillåts på alla KMS-nycklar i en infogad princip. Med AWS KMS styr du vem som kan använda dina KMS-nycklar och få åtkomst till dina krypterade data. IAM-principer definierar vilka åtgärder en identitet (användare, grupp eller roll) kan utföra på vilka resurser. Enligt rekommenderade säkerhetsmetoder rekommenderar AWS att du tillåter minst behörighet. Med andra ord bör du endast bevilja identiteter de behörigheter de behöver och endast för nycklar som krävs för att utföra en uppgift. Annars kan användaren använda nycklar som inte är lämpliga för dina data. I stället för att bevilja behörighet för alla nycklar ska du fastställa den minsta uppsättning nycklar som användarna behöver för att få åtkomst till krypterade data. Utforma sedan principer som gör att användarna endast kan använda dessa nycklar. Tillåt till exempel inte kms:Decrypt behörighet för alla KMS-nycklar. Tillåt dem i stället endast på nycklar i en viss region för ditt konto. Genom att anta principen om lägsta behörighet kan du minska risken för oavsiktligt avslöjande av dina data.

Allvarlighetsgrad: Medel

Lambda-funktioner bör begränsa offentlig åtkomst

Beskrivning: Resursbaserad princip för Lambda-funktionen bör begränsa den offentliga åtkomsten. Den här rekommendationen kontrollerar inte åtkomsten av interna huvudkonton. Se till att åtkomsten till funktionen endast är begränsad till auktoriserade huvudkonton genom att använda resursbaserade principer med minst privilegier.

Allvarlighetsgrad: Hög

MFA ska vara aktiverat för alla IAM-användare

Beskrivning: Alla IAM-användare bör ha multifaktorautentisering (MFA) aktiverat.

Allvarlighetsgrad: Medel

MFA ska vara aktiverat för "rotkontot"

Beskrivning: Rotkontot är den mest privilegierade användaren i ett konto. MFA lägger till ett extra skyddslager ovanpå ett användarnamn och lösenord. När MFA är aktiverat uppmanas en användare att ange användarnamn och lösenord och en autentiseringskod från sin AWS MFA-enhet när en användare loggar in på en AWS-webbplats. När du använder virtuell MFA för rotkonton rekommenderar vi att enheten som används inte är en personlig enhet. Använd i stället en dedikerad mobil enhet (surfplatta eller telefon) som du hanterar för att hålla debiterad och skyddad oberoende av enskilda personliga enheter. Detta minskar risken för att förlora åtkomsten till MFA på grund av enhetsförlust, enhetshandel eller om den person som äger enheten inte längre är anställd på företaget.

Allvarlighetsgrad: Låg

Lösenordsprinciper för IAM-användare bör ha starka konfigurationer

Beskrivning: Kontrollerar om kontots lösenordsprincip för IAM-användare använder följande minsta konfigurationer.

RequireUppercaseCharacters – Kräv minst ett versaler i lösenordet. (Standard = sant)
RequireLowercaseCharacters – Kräv minst ett gemener i lösenordet. (Standard = sant)
RequireNumbers – Kräv minst ett nummer i lösenordet. (Standard = sant)
MinimumPasswordLength – Minsta längd för lösenord. (Standard = 7 eller längre)
PasswordReusePrevention – Antal lösenord innan återanvändning tillåts. (Standard = 4)
MaxPasswordAge – Antal dagar innan lösenordet upphör att gälla. (Standard = 90)

Allvarlighetsgrad: Medel

Behörigheter för inaktiva identiteter i ditt AWS-konto bör återkallas

Beskrivning: Microsoft Defender för molnet har identifierat en identitet som inte har utfört någon åtgärd på någon resurs i ditt AWS-konto under de senaste 45 dagarna. Vi rekommenderar att du återkallar behörigheter för inaktiva identiteter för att minska attackytan i din molnmiljö.

Allvarlighetsgrad: Medel

Rotkontots åtkomstnyckel bör inte finnas

Beskrivning: Rotkontot är den mest privilegierade användaren i ett AWS-konto. AWS-åtkomstnycklar ger programmatisk åtkomst till ett visst AWS-konto. Vi rekommenderar att alla åtkomstnycklar som är associerade med rotkontot tas bort. Ta bort åtkomstnycklar som är associerade med rotkontots begränsningsvektorer som kontot kan komprometteras med. Om du tar bort rotåtkomstnycklarna kan du dessutom skapa och använda rollbaserade konton som är minst privilegierade.

Allvarlighetsgrad: Hög

S3-inställningen Blockera offentlig åtkomst ska vara aktiverad

Beskrivning: Om du aktiverar inställningen Blockera offentlig åtkomst för din S3-bucket kan du förhindra känsliga dataläckor och skydda din bucket från skadliga åtgärder.

Allvarlighetsgrad: Medel

S3-inställningen Blockera offentlig åtkomst ska vara aktiverad på bucketnivå

Beskrivning: Den här kontrollen kontrollerar om S3-bucketar har offentliga åtkomstblock på bucketnivå tillämpade. Den här kontrollen misslyckas om någon av följande inställningar är inställda på false:

ignorePublicAcls
blockPublicPolicy
blockPublicAcls
restrictPublicBuckets Blockera offentlig åtkomst på S3-bucketnivå tillhandahåller kontroller för att säkerställa att objekt aldrig har offentlig åtkomst. Offentlig åtkomst beviljas till bucketar och objekt via åtkomstkontrollistor (ACL), bucketprinciper eller både och. Om du inte tänker ha dina S3-bucketar offentligt tillgängliga bör du konfigurera funktionen Amazon S3 Blockera offentlig åtkomst på bucketnivå.

Allvarlighetsgrad: Hög

Offentlig läsåtkomst för S3-bucketar bör tas bort

Beskrivning: Om du tar bort offentlig läsåtkomst till din S3-bucket kan du skydda dina data och förhindra dataintrång.

Allvarlighetsgrad: Hög

Offentlig skrivåtkomst för S3-bucketar bör tas bort

Beskrivning: Om du tillåter offentlig skrivåtkomst till din S3-bucket kan du bli sårbar för skadliga åtgärder som att lagra data på din bekostnad, kryptera dina filer mot lösensumma eller använda din bucket för att använda skadlig kod.

Allvarlighetsgrad: Hög

Secrets Manager-hemligheter bör ha automatisk rotation aktiverad

Beskrivning: Den här kontrollen kontrollerar om en hemlighet som lagras i AWS Secrets Manager har konfigurerats med automatisk rotation. Secrets Manager hjälper dig att förbättra organisationens säkerhetsstatus. Hemligheter inkluderar databasautentiseringsuppgifter, lösenord och API-nycklar från tredje part. Du kan använda Secrets Manager för att lagra hemligheter centralt, kryptera hemligheter automatiskt, kontrollera åtkomsten till hemligheter och rotera hemligheter på ett säkert och automatiskt sätt. Secrets Manager kan rotera hemligheter. Du kan använda rotation för att ersätta långsiktiga hemligheter med kortsiktiga. Om du roterar dina hemligheter begränsas hur länge en obehörig användare kan använda en komprometterad hemlighet. Därför bör du rotera dina hemligheter ofta. Mer information om rotation finns i Rotera dina AWS Secrets Manager-hemligheter i användarhandboken för AWS Secrets Manager.

Allvarlighetsgrad: Medel

Stoppade EC2-instanser bör tas bort efter en angiven tidsperiod

Beskrivning: Den här kontrollen kontrollerar om några EC2-instanser har stoppats i mer än det tillåtna antalet dagar. En EC2-instans misslyckas med den här kontrollen om den stoppas längre än den maximala tillåtna tidsperioden, vilket som standard är 30 dagar. Ett misslyckat resultat indikerar att en EC2-instans inte har körts under en längre tid. Detta skapar en säkerhetsrisk eftersom EC2-instansen inte underhålls aktivt (analyseras, korrigeras, uppdateras). Om den senare startas kan bristen på korrekt underhåll leda till oväntade problem i din AWS-miljö. För att på ett säkert sätt underhålla en EC2-instans över tid i ett icke-körningstillstånd startar du den regelbundet för underhåll och stoppar den sedan efter underhåll. Helst är detta en automatiserad process.

Allvarlighetsgrad: Medel

Oanvända identiteter i AWS-miljön bör tas bort (förhandsversion)

Beskrivning: 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. Inaktiva IAM-identiteter med högriskbehörigheter i ditt AWS-konto kan vara utsatta för angrepp om de lämnas som de är och lämna organisationer öppna för missbruk eller utnyttjande av autentiseringsuppgifter. Genom att proaktivt identifiera och svara på oanvända identiteter kan du förhindra att obehöriga entiteter får åtkomst till dina AWS-resurser.

Allvarlighetsgrad: Medel

GCP-identitets- och åtkomstrekommendationer

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 Key Management Service 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:

Loggtypen är inställd 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-kryptonycklar 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 kontrollerar du att anonym och/eller offentlig åtkomst till en Cloud KMS-kryptonyckel 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. Med den inbyggda/fördefinierade IAM-rollen Cloud KMS CryptoKey Encrypter/Decrypter kan användaren/identiteten (med tillräcklig behörighet för berörda resurser) kryptera och dekryptera data i vila med hjälp av en krypteringsnyckel. 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 Crypto Key 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 administratörsaktivitets- och dataåtkomstloggar. Poster hjälper till att besvara frågorna om "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

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

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.

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

Behörigheter för inaktiva identiteter i ditt GCP-projekt bör återkallas

Beskrivning: Microsoft Defender för molnet har identifierat en identitet som inte har utfört någon åtgärd på någon resurs i ditt GCP-projekt under de senaste 45 dagarna. Vi rekommenderar att du återkallar behörigheter för inaktiva identiteter för att minska attackytan i din molnmiljö.

Allvarlighetsgrad: Medel

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 (förhandsversion)

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

Dela via

Säkerhetsrekommendationer för identitet och åtkomst

Azure-identitets- och åtkomstrekommendationer

AWS-identitets- och åtkomstrekommendationer

GCP-identitets- och åtkomstrekommendationer

Relaterat innehåll

Feedback

Feedback

Ytterligare resurser