Säkerhetskontroll: Identitetshantering

Identitetshantering omfattar kontroller för att upprätta säkra identitets- och åtkomstkontroller med hjälp av identitets- och åtkomsthanteringssystem, inklusive användning av enkel inloggning, starka autentiseringar, hanterade identiteter (och tjänstens huvudnamn) för program, villkorlig åtkomst och övervakning av avvikelser i konton.

IM-1: Använd centraliserat identitets- och autentiseringssystem

CIS-kontroller v8 ID:n NIST SP 800-53 r4 ID:n PCI-DSS ID(er) v3.2.1
6.7, 12.5 AC-2, AC-3, IA-2, IA-8 7.2, 8.3

Säkerhetsprincip: Använd ett centraliserat identitets- och autentiseringssystem för att styra organisationens identiteter och autentiseringar för molnresurser och icke-molnresurser.


Azure-vägledning: Azure Active Directory (Azure AD) är Azures identitets- och autentiseringshanteringstjänst. Du bör standardisera Azure AD för att styra organisationens identitet och autentisering i:

  • Microsofts molnresurser, till exempel Azure Storage, Azure Virtual Machines (Linux och Windows), Azure Key Vault,PaaS- och SaaS-program.
  • Organisationens resurser, till exempel program i Azure, program från tredje part som körs på företagets nätverksresurser och SaaS-program från tredje part.
  • Dina företagsidentiteter i Active Directory genom synkronisering till Azure AD för att säkerställa en konsekvent och centralt hanterad identitetsstrategi.

För de Azure-tjänster som gäller bör du undvika att använda lokala autentiseringsmetoder och i stället använda Azure Active Directory för att centralisera dina tjänstautentiseringar.

Obs! Så snart det är tekniskt möjligt bör du migrera lokal Active Directory baserade program till Azure AD. Detta kan vara en Azure AD Företagskatalog, Business to Business-konfiguration eller Konfiguration av företag till konsument.

Azure-implementering och ytterligare kontext:


AWS-vägledning: AWS IAM (Identity and Access Management) är AWS standardtjänst för identitets- och autentiseringshantering. Använd AWS IAM för att styra din AWS-identitets- och åtkomsthantering. Via AWS och Azure Single Sign-On (SSO) kan du också använda Azure AD för att hantera identitets- och åtkomstkontroll för AWS för att undvika att hantera dubblettkonton separat på två molnplattformar.

AWS stöder enkel Sign-On som gör att du kan överbrygga företagets identiteter från tredje part (till exempel Windows Active Directory eller andra identitetslager) med AWS-identiteterna för att undvika att skapa dubblettkonton för att få åtkomst till AWS-resurser.

AWS-implementering och ytterligare kontext:


GCP-vägledning: Google Cloud IAM-systemet (Identity and Access Management) är Google Clouds standardtjänst för identitets- och autentiseringshantering som används för Google Cloud Identity-konton. Använd Google Cloud IAM för att styra din GCP-identitets- och åtkomsthantering. Via Google Cloud Identity och Azure Sigle Sign-On (SSO) kan du också använda Azure AD för att hantera identitets- och åtkomstkontrollen för GCP för att undvika att hantera dubblettkonton separat i en mutli-cloud-miljö.

Google Cloud Identity är identitetsprovidern för alla Google-tjänster. Den stöder single Sign-On som gör att du kan överbrygga företagets identiteter från tredje part (till exempel Windows Active Directory eller andra identitetslager) med Google Cloud-identiteter för att undvika att skapa dubblettkonton för att få åtkomst till GCP-resurser.

Obs! Använda Google Cloud Directory Sync. Google tillhandahåller anslutningsverktyg som integreras med de flesta LDAP-hanteringssystem för företag och synkroniserar identiteter enligt ett schema. Genom att konfigurera ett molnidentitetskonto och sjunga Google Cloud Directory Sync kan du konfigurera vilka av dina användarkonton – inklusive användare, grupper och användarprofiler, alias med mera – som ska synkroniseras enligt ett schema mellan ditt lokala identitetshanteringssystem och ditt GCP-system.

GCP-implementering och ytterligare kontext:


Intressenter för kundsäkerhet (Läs mer):

IM-2: Skydda identitets- och autentiseringssystem

CIS-kontroller v8 ID:n NIST SP 800-53 r4 ID:n PCI-DSS ID(er) v3.2.1
5.4, 6.5 AC-2, AC-3, IA-2, IA-8, SI-4 8.2, 8.3

Säkerhetsprincip: Skydda ditt identitets- och autentiseringssystem som en hög prioritet i organisationens molnsäkerhetspraxis. Vanliga säkerhetskontroller är:

  • Begränsa privilegierade roller och konton
  • Kräv stark autentisering för all privilegierad åtkomst
  • Övervaka och granska aktiviteter med hög risk

Azure-vägledning: Använd Azure AD säkerhetsbaslinje och Azure AD identitetssäkerhetspoäng för att utvärdera din Azure AD identitetssäkerhetsstatus och åtgärda säkerhets- och konfigurationsluckor. Azure AD Identity Secure Score utvärderar Azure AD för följande konfigurationer:

  • Använda begränsade administrativa roller
  • Aktivera användarriskprincip
  • Utse fler än en global administratör
  • Aktivera princip för att blockera äldre autentisering
  • Se till att alla användare kan slutföra multifaktorautentisering för säker åtkomst
  • Kräv MFA för administrativa roller
  • Aktivera lösenordsåterställning via självbetjäning
  • Upphör inte att gälla för lösenord
  • Aktivera principen för inloggningsrisk
  • Tillåt inte att användare beviljar medgivande till ohanterade program

Använd Azure AD Identity Protection för att identifiera, undersöka och åtgärda identitetsbaserade risker. Om du vill skydda din lokal Active Directory domän på samma sätt använder du Defender for Identity.

Obs! Följ publicerade metodtips för alla andra identitetskomponenter, inklusive dina lokal Active Directory och eventuella funktioner från tredje part, samt de infrastrukturer (till exempel operativsystem, nätverk och databaser) som är värdar för dem.

Azure-implementering och ytterligare kontext:


AWS-vägledning: Använd följande rekommenderade säkerhetsmetoder för att skydda din AWS IAM:

  • Konfigurera AWS-kontots rotanvändaråtkomstnycklar för åtkomst vid akutfall enligt beskrivningen i PA-5 (Konfigurera åtkomst vid akutfall)
  • Följ lägsta behörighetsprinciper för åtkomsttilldelningar
  • Använd IAM-grupper för att tillämpa principer i stället för enskilda användare.
  • Följ riktlinjerna för stark autentisering i IM-6 (Använd starka autentiseringskontroller) för alla användare
  • Använda AWS Organizations SCP (Service Control Policy) och behörighetsgränser
  • Använda IAM Access Advisor för att granska tjänståtkomst
  • Använda IAM-autentiseringsuppgiftsrapport för att spåra användarkonton och status för autentiseringsuppgifter

Obs! Följ publicerade metodtips om du har andra identitets- och autentiseringssystem, t.ex. följa Azure AD säkerhetsbaslinje om du använder Azure AD för att hantera AWS-identitet och åtkomst.

AWS-implementering och ytterligare kontext:


GCP-vägledning: Använd följande rekommenderade säkerhetsmetoder för att skydda dina Google Cloud IAM- och Cloud Identity-tjänster för dina organisationer:

  • Konfigurera ett superadministratörskonto för åtkomst vid akutfall genom att följa rekommendationerna i PA-5 ("Konfigurera åtkomst vid nödsituationer").
  • Skapa en superadministratörs-e-postadress (som superadministratörskontot för Google Workspace eller Cloud Identity) och det här kontot bör inte vara specifikt för en viss användare om en nödåterställning behövs.
  • Följ lägsta behörighet och ansvarsfördelningsprinciper
  • Undvik att använda superadministratörskontot för dagliga aktiviteter
  • Använd Google Cloud Identity-grupper för att tillämpa principer i stället för att tillämpa principer på enskilda användare.
  • Följ riktlinjerna för stark autentisering enligt beskrivningen i IM-6 ("Använd starka autentiseringskontroller") för alla användare som har förhöjd behörighet.
  • Använda IAM-principer för att begränsa åtkomsten till resurser
  • Använda organisationsprinciptjänsten för att styra och konfigurera begränsningar för resurser
  • Använda IAM-granskningsloggning i Cloud Audit-loggar för att granska privilegierade aktiviteter

Obs! Följ publicerade metodtips om du har andra identitets- och autentiseringssystem, t.ex. följa Azure AD säkerhetsbaslinje om du använder Azure AD för att hantera GCP-identitet och åtkomst.

GCP-implementering och ytterligare kontext:


Intressenter för kundsäkerhet (Läs mer):

IM-3: Hantera programidentiteter på ett säkert och automatiskt sätt

CIS-kontroller v8 ID:n NIST SP 800-53 r4 ID:n PCI-DSS ID(er) v3.2.1
Ej tillämpligt AC-2, AC-3, IA-4, IA-5, IA-9 Ej tillämpligt

Säkerhetsprincip: Använd hanterade programidentiteter i stället för att skapa mänskliga konton för program för att komma åt resurser och köra kod. Hanterade programidentiteter ger fördelar som att minska exponeringen av autentiseringsuppgifter. Automatisera rotationen av autentiseringsuppgifter för att säkerställa säkerheten för identiteterna.


Azure-vägledning: Använd hanterade Azure-identiteter som kan autentisera mot Azure-tjänster och resurser som stöder Azure AD autentisering. Autentiseringsuppgifterna för hanterade identiteter hanteras, roteras och skyddas av plattformen, vilket undviker hårdkodade autentiseringsuppgifter i källkods- eller konfigurationsfiler.

För tjänster som inte stöder hanterade identiteter använder du Azure AD för att skapa ett huvudnamn för tjänsten med begränsade behörigheter på resursnivå. Vi rekommenderar att du konfigurerar tjänstens huvudnamn med certifikatautentiseringsuppgifter och återgår till klienthemligheter för autentisering.

Azure-implementering och ytterligare kontext:


AWS-vägledning: Använd AWS IAM-roller i stället för att skapa användarkonton för resurser som stöder den här funktionen. IAM-roller hanteras av plattformen på serverdelen och autentiseringsuppgifterna är tillfälliga och roteras automatiskt. På så sätt undviker du att skapa långsiktiga åtkomstnycklar eller användarnamn/lösenord för program och hårdkodade autentiseringsuppgifter i källkods- eller konfigurationsfiler.

Du kan använda tjänstlänkade roller som är kopplade till fördefinierade behörighetsprinciper för åtkomst mellan AWS-tjänster i stället för att anpassa dina egna rollbehörigheter för IAM-rollerna.

Obs! För tjänster som inte stöder IAM-roller använder du åtkomstnycklar men följer rekommenderade säkerhetsmetoder som IM-8 Begränsa exponeringen av autentiseringsuppgifter och hemligheter för att skydda dina nycklar.

AWS-implementering och ytterligare kontext:


GCP-vägledning: Använd Google-hanterade tjänstkonton i stället för att skapa användarhanterade konton för resurser som stöder den här funktionen. Google-hanterade tjänstkonton hanteras av plattformen på serverdelen och tjänstkontonycklarna är tillfälliga och roteras automatiskt. På så sätt undviker du att skapa långsiktiga åtkomstnycklar eller användarnamn/lösenord för program och hårdkodade hårdkodade autentiseringsuppgifter i källkods- eller konfigurationsfiler.

Använd Principinformation för att förstå och identifiera misstänkt aktivitet för tjänstkonton.

GCP-implementering och ytterligare kontext:


Intressenter för kundsäkerhet (Läs mer):

IM-4: Autentisera server och tjänster

CIS-kontroller v8 ID:n NIST SP 800-53 r4 ID:n PCI-DSS ID(er) v3.2.1
Ej tillämpligt IA-9 Ej tillämpligt

Säkerhetsprincip: Autentisera fjärrservrar och tjänster från klientsidan för att säkerställa att du ansluter till betrodda servrar och tjänster. Det vanligaste protokollet för serverautentisering är TLS (Transport Layer Security), där klientsidan (ofta en webbläsare eller klientenhet) verifierar servern genom att verifiera att serverns certifikat har utfärdats av en betrodd certifikatutfärdare.

Obs! Ömsesidig autentisering kan användas när både servern och klienten autentiserar varandra.


Azure-vägledning: Många Azure-tjänster stöder TLS-autentisering som standard. För tjänster som inte stöder TLS-autentisering som standard, eller som stöder inaktivering av TLS, kontrollerar du att det alltid är aktiverat för server-/klientautentisering. Klientprogrammet bör också utformas för att verifiera server/klientidentitet (genom att verifiera serverns certifikat som utfärdats av en betrodd certifikatutfärdare) i handskakningsfasen.

Obs! Tjänster som API Management och API Gateway stöder ömsesidig TLS-autentisering.

Azure-implementering och ytterligare kontext:


AWS-vägledning: Många AWS-tjänster stöder TLS-autentisering som standard. För tjänster som inte stöder TLS-autentisering som standard, eller som stöder inaktivering av TLS, kontrollerar du att det alltid är aktiverat för server-/klientautentisering. Klientprogrammet bör också utformas för att verifiera server/klientidentitet (genom att verifiera serverns certifikat som utfärdats av en betrodd certifikatutfärdare) i handskakningsfasen.

Obs! Tjänster som API Gateway stöder ömsesidig TLS-autentisering.

AWS-implementering och ytterligare kontext:


GCP-vägledning: Många GCP-tjänster stöder TLS-autentisering som standard. För tjänster som inte stöder detta som standard eller som stöder inaktivering av TLS kontrollerar du att det alltid är aktiverat för att stödja server-/klientautentisering. Klientprogrammet bör också utformas för att verifiera server/klientidentitet (genom att verifiera serverns certifikat som utfärdats av en betrodd certifikatutfärdare) i handskakningsfasen.

Obs! Tjänster som molnbelastningsutjämning stöder ömsesidig TLS-autentisering.

GCP-implementering och ytterligare kontext:


Intressenter för kundsäkerhet (Läs mer):

IM-5: Använd enkel inloggning (SSO) för programåtkomst

CIS-kontroller v8 ID:n NIST SP 800-53 r4 ID:n PCI-DSS ID(er) v3.2.1
12.5 IA-4, IA-2, IA-8 Ej tillämpligt

Säkerhetsprincip: Använd enkel inloggning (SSO) för att förenkla användarupplevelsen för autentisering till resurser, inklusive program och data i molntjänster och lokala miljöer.


Azure-vägledning: Använd Azure AD för åtkomst till arbetsbelastningsprogram (kundriktad) via Azure AD enkel inloggning (SSO), vilket minskar behovet av duplicerade konton. Azure AD tillhandahåller identitets- och åtkomsthantering för Azure-resurser (i hanteringsplanet, inklusive CLI, PowerShell, portalen), molnprogram och lokala program.

Azure AD har också stöd för enkel inloggning för företagsidentiteter, till exempel företagsanvändaridentiteter, samt externa användaridentiteter från betrodda tredje part och offentliga användare.

Azure-implementering och ytterligare kontext:


AWS-vägledning: Använd AWS Cognito för att hantera åtkomst till dina kundriktade programarbetsbelastningar via enkel inloggning (SSO) så att kunderna kan överbrygga sina identiteter från tredje part från olika identitetsprovidrar.

För åtkomst med enkel inloggning till de inbyggda AWS-resurserna (inklusive åtkomst till AWS-konsolen eller tjänsthantering och åtkomst på dataplansnivå) använder du AWS Sigle Sign-On för att minska behovet av dubblettkonton.

Med enkel inloggning med AWS kan du också överbrygga företagsidentiteter (till exempel identiteter från Azure Active Directory) med AWS-identiteter, samt externa användaridentiteter från betrodda tredje part och offentliga användare.

AWS-implementering och ytterligare kontext:


GCP-vägledning: Använd Google Cloud Identity för att hantera åtkomst till ditt kundinriktade arbetsbelastningsprogram via enkel inloggning med Google Cloud Identity, vilket minskar behovet av duplicerade konton. Google Cloud Identity tillhandahåller identitets- och åtkomsthantering till GCP (i hanteringsplanet, inklusive Google Cloud CLI, konsolåtkomst), molnprogram och lokala program.

Google Cloud Identity stöder även enkel inloggning för företagsidentiteter, till exempel företagsanvändares identiteter från Azure AD eller Active Directory, samt externa användaridentiteter från betrodda tredje part och offentliga användare. GCP-implementering och ytterligare kontext:


Kunders säkerhetsintressenter (Läs mer):

SNABBMEDDELANDE 6: Använd starka autentiseringskontroller

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID:n PCI-DSS ID(s) v3.2.1
6.3, 6.4 AC-2, AC-3, IA-2, IA-5, IA-8 7.2, 8.2, 8.3, 8.4

Säkerhetsprincip: Framtvinga starka autentiseringskontroller (stark lösenordslös autentisering eller multifaktorautentisering) med ditt centraliserade system för identitets- och autentiseringshantering för all åtkomst till resurser. Enbart autentisering baserat på lösenordsautentiseringsuppgifter betraktas som äldre eftersom den är osäker och inte står upp mot populära angreppsmetoder.

När du distribuerar stark autentisering konfigurerar du först administratörer och privilegierade användare för att säkerställa den högsta nivån för den starka autentiseringsmetoden, snabbt följt av att lansera lämplig stark autentiseringsprincip för alla användare.

Obs! Om äldre lösenordsbaserad autentisering krävs för äldre program och scenarier ska du se till att bästa praxis för lösenordssäkerhet, till exempel komplexitetskrav, följs.


Azure-vägledning: Azure AD stöder starka autentiseringskontroller via lösenordslösa metoder och multifaktorautentisering (MFA).

  • Lösenordslös autentisering: Använd lösenordslös autentisering som standardautentiseringsmetod. Det finns tre alternativ för lösenordslös autentisering: Windows Hello för företag, microsoft Authenticator-appens telefoninloggning och FIDO2-säkerhetsnycklar. Dessutom kan kunder använda lokala autentiseringsmetoder, till exempel smartkort.
  • Multifaktorautentisering: Azure MFA kan tillämpas på alla användare, välja användare eller per användare baserat på inloggningsvillkor och riskfaktorer. Aktivera Azure MFA och följ Microsoft Defender för molnidentitets- och åtkomsthanteringsrekommendationer för din MFA-konfiguration.

Om äldre lösenordsbaserad autentisering fortfarande används för Azure AD autentisering bör du vara medveten om att endast molnbaserade konton (användarkonton som skapats direkt i Azure) har en standardprincip för baslinjelösenord. Och hybridkonton (användarkonton som kommer från lokal Active Directory) följer de lokala lösenordsprinciperna.

För program och tjänster från tredje part som kan ha standard-ID:er och lösenord bör du inaktivera eller ändra dem under den inledande tjänstkonfigurationen.

Azure-implementering och ytterligare kontext:


AWS-vägledning: AWS IAM stöder starka autentiseringskontroller via multifaktorautentisering (MFA). MFA kan tillämpas på alla användare, välja användare eller per användare baserat på definierade villkor.

Om du använder företagskonton från en tredjepartskatalog (till exempel Windows Active Directory) med AWS-identiteter följer du respektive säkerhetsvägledning för att framtvinga stark autentisering. Se Azure Guidance för den här kontrollen om du använder Azure AD för att hantera AWS-åtkomst.

Obs! För program från tredje part och AWS-tjänster som kan ha standard-ID:er och lösenord bör du inaktivera eller ändra dem under den inledande tjänstkonfigurationen.

AWS-implementering och ytterligare kontext:


GCP-vägledning: Google Cloud Identity stöder starka autentiseringskontroller via multifaktorautentisering (MFA). MFA kan tillämpas på alla användare, välja användare eller per användare baserat på definierade villkor. Om du vill skydda superadministratörskonton för molnidentitet (och arbetsyta) bör du överväga att använda säkerhetsnycklar och Google Advanced Protection-programmet för maximal säkerhet.

Om du använder företagskonton från en tredjepartskatalog (till exempel Windows Active Directory) med Google Cloud-identiteter följer du respektive säkerhetsvägledning för att framtvinga stark autentisering. Se Azure Guidance för den här kontrollen om du använder Azure AD för att hantera Åtkomst till Google Cloud.

Använd Identity-Aware Proxy för att upprätta ett centralt auktoriseringslager för program som används av HTTPS, så att du kan använda en åtkomstkontrollmodell på programnivå i stället för att förlita dig på brandväggar på nätverksnivå.

Obs! För program från tredje part och GCP-tjänster som kan ha standard-ID:er och lösenord bör du inaktivera eller ändra dem under den inledande tjänstkonfigurationen.

GCP-implementering och ytterligare kontext:


Kunders säkerhetsintressenter (Läs mer):

SNABBMEDDELANDE 7: Begränsa resursåtkomst baserat på villkor

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID:n PCI-DSS ID(s) v3.2.1
3.3, 6.4, 13.5 AC-2, AC-3, AC-6 7.2

Säkerhetsprincip: Verifiera uttryckligen betrodda signaler för att tillåta eller neka användare åtkomst till resurser, som en del av en åtkomstmodell med noll förtroende. Signaler att verifiera bör innehålla stark autentisering av användarkonto, beteendeanalys av användarkonto, enhetens pålitlighet, användar- eller gruppmedlemskap, platser och så vidare.


Azure-vägledning: Använd Azure AD villkorlig åtkomst för mer detaljerade åtkomstkontroller baserat på användardefinierade villkor, till exempel att kräva att användarinloggningar från vissa IP-intervall (eller enheter) använder MFA. Azure AD villkorlig åtkomst kan du framtvinga åtkomstkontroller för din organisations appar baserat på vissa villkor.

Definiera tillämpliga villkor och kriterier för Azure AD villkorlig åtkomst i arbetsbelastningen. Tänk på följande vanliga användningsfall:

  • Kräver multifaktorautentisering för användare med administrativa roller
  • Kräver multifaktorautentisering för Azure-hanteringsuppgifter
  • Blockera inloggningar för användare som försöker använda äldre autentiseringsprotokoll
  • Kräver betrodda platser för Azure AD multifaktorautentiseringsregistrering
  • Blockera eller bevilja åtkomst från specifika platser
  • Blockera riskfyllda inloggningsbeteenden
  • Kräva organisationshanterade enheter för specifika program

Obs! Detaljerade kontroller för hantering av autentiseringssessioner kan också implementeras via Azure AD princip för villkorlig åtkomst, till exempel inloggningsfrekvens och beständig webbläsarsession.

Azure-implementering och ytterligare kontext:


AWS-vägledning: Skapa en IAM-princip och definiera villkor för mer detaljerade åtkomstkontroller baserat på användardefinierade villkor, till exempel kräva att användarinloggningar från vissa IP-intervall (eller enheter) använder multifaktorautentisering. Villkorsinställningarna kan innehålla enkla eller flera villkor samt logik.

Principer kan definieras från sex olika dimensioner: identitetsbaserade principer, resursbaserade principer, behörighetsgränser, AWS Organisations service control policy (SCP) , Access Control Lists (ACL) och sessionsprinciper.

AWS-implementering och ytterligare kontext:


GCP-vägledning: Skapa och definiera IAM-villkor för mer detaljerade attributbaserade åtkomstkontroller baserat på användardefinierade villkor, till exempel att kräva att användarinloggningar från vissa IP-intervall (eller enheter) använder multifaktorautentisering. Villkorsinställningarna kan innehålla enkla eller flera villkor samt logik.

Villkor anges i rollbindningarna för en resurs tillåtna princip. Villkorsattribut baseras på den begärda resursen, till exempel dess typ eller namn, eller på information om begäran, till exempel dess tidsstämpel eller mål-IP-adress.

GCP-implementering och ytterligare kontext:


Kunders säkerhetsintressenter (Läs mer):

SNABBMEDDELANDE 8: Begränsa exponeringen av autentiseringsuppgifter och hemligheter

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID:n PCI-DSS ID(s) v3.2.1
16.9, 16.12 IA-5 3.5, 6.3, 8.2

Säkerhetsprincip: Se till att programutvecklare hanterar autentiseringsuppgifter och hemligheter på ett säkert sätt:

  • Undvik att bädda in autentiseringsuppgifter och hemligheter i kod- och konfigurationsfilerna
  • Använd nyckelvalv eller en säker nyckellagringstjänst för att lagra autentiseringsuppgifter och hemligheter
  • Sök efter autentiseringsuppgifter i källkoden.

Obs! Detta styrs och framtvingas ofta genom en säker livscykel för programvaruutveckling (SDLC) och DevOps-säkerhetsprocessen.


Azure-vägledning: När du använder en hanterad identitet är inte ett alternativ kontrollerar du att hemligheter och autentiseringsuppgifter lagras på säkra platser som Azure Key Vault, i stället för att bädda in dem i kod- och konfigurationsfilerna.

Om du använder Azure DevOps och GitHub för din kodhanteringsplattform:

  • Implementera Azure DevOps Credential Scanner för att identifiera autentiseringsuppgifter i koden.
  • För GitHub använder du funktionen för intern hemlighetsgenomsökning för att identifiera autentiseringsuppgifter eller någon annan form av hemligheter i koden.

Klienter som Azure Functions, Azure Apps-tjänster och virtuella datorer kan använda hanterade identiteter för att få åtkomst till Azure Key Vault på ett säkert sätt. Se Dataskyddskontroller som rör användningen av Azure Key Vault för hantering av hemligheter.

Obs! Azure Key Vault tillhandahåller automatisk rotation för tjänster som stöds. För hemligheter som inte kan roteras automatiskt kontrollerar du att de roteras manuellt regelbundet och rensas när de inte längre används.

Azure-implementering och ytterligare kontext:


AWS-vägledning: När du använder en IAM-roll för programåtkomst är inte ett alternativ kontrollerar du att hemligheter och autentiseringsuppgifter lagras på säkra platser som AWS Secret Manager eller Systems Manager Parameter Store, i stället för att bädda in dem i kod- och konfigurationsfilerna.

Använd CodeGuru Reviewer för statisk kodanalys som kan identifiera hemligheterna som är hårdkodade i källkoden.

Om du använder Azure DevOps och GitHub för din kodhanteringsplattform:

  • Implementera Azure DevOps Credential Scanner för att identifiera autentiseringsuppgifter i koden.
  • För GitHub använder du funktionen för intern hemlighetsgenomsökning för att identifiera autentiseringsuppgifter eller andra former av hemligheter i koden.

Obs! Secrets Manager tillhandahåller automatisk rotation av hemligheter för tjänster som stöds. För hemligheter som inte kan roteras automatiskt kontrollerar du att de roteras manuellt regelbundet och rensas när de inte längre används.

AWS-implementering och ytterligare kontext:


GCP-vägledning: När du använder ett Google-hanterat tjänstkonto för programåtkomst är inte ett alternativ, se till att hemligheter och autentiseringsuppgifter lagras på säkra platser som Google Cloud Secret Manager i stället för att bädda in dem i kod- och konfigurationsfilerna.

Använd Google Cloud Code-tillägget i IDE:s (integrerad utvecklingsmiljö) som Visual Studio Code för att integrera hemligheter som hanteras av Secret Manager i koden.

Om du använder Azure DevOps eller GitHub för din kodhanteringsplattform:

  • Implementera Azure DevOps Credential Scanner för att identifiera autentiseringsuppgifter i koden.
  • För GitHub använder du funktionen för intern hemlighetsgenomsökning för att identifiera autentiseringsuppgifter eller andra former av hemligheter i koden.

Obs! Konfigurera rotationsscheman för hemligheter som lagras i Secret Manager som bästa praxis.

GCP-implementering och ytterligare kontext:


Kunders säkerhetsintressenter (Läs mer):

SNABBMEDDELANDE 9: Skydda användaråtkomst till befintliga program

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID:n PCI-DSS ID(s) v3.2.1
6.7, 12.5 AC-2, AC-3, SC-11 Ej tillämpligt

Säkerhetsprincip: I en hybridmiljö, där du har lokala program eller icke-inbyggda molnprogram med äldre autentisering, bör du överväga lösningar som cloud access security broker (CASB), programproxy, enkel inloggning (SSO) för att styra åtkomsten till dessa program för följande fördelar:

  • Framtvinga en centraliserad stark autentisering
  • Övervaka och kontrollera riskfyllda slutanvändaraktiviteter
  • Övervaka och åtgärda riskfyllda äldre programaktiviteter
  • Identifiera och förhindra överföring av känsliga data

Azure-vägledning: Skydda dina lokala och icke-inbyggda molnprogram med äldre autentisering genom att ansluta dem till:

  • Azure AD Programproxy och konfigurera rubrikbaserad autentisering för att tillåta enkel inloggning (SSO) åtkomst till program för fjärranvändare, samtidigt som du uttryckligen validerar tillförlitligheten för både fjärranvändare och enheter med Azure AD villkorlig åtkomst. Om det behövs använder du en lösning från tredje part Software-Defined Perimeter (SDP) som kan erbjuda liknande funktioner.
  • Microsoft Defender for Cloud Apps, som betjänar en CASB-tjänst (Cloud Access Security Broker) för att övervaka och blockera användaråtkomst till icke godkända SaaS-program från tredje part.
  • Dina befintliga programleveranskontrollanter och nätverk från tredje part.

Obs! VPN används ofta för att komma åt äldre program och har ofta bara grundläggande åtkomstkontroll och begränsad sessionsövervakning.

Azure-implementering och ytterligare kontext:


AWS-vägledning: Följ Azures vägledning för att skydda dina lokala och icke-inbyggda molnprogram med äldre autentisering genom att ansluta dem till:

  • Azure AD Programproxy och konfigurera rubrikbaserad för att tillåta enkel inloggning (SSO) åtkomst till program för fjärranvändare, samtidigt som du uttryckligen validerar tillförlitligheten för både fjärranvändare och enheter med Azure AD villkorlig åtkomst. Om det behövs använder du en lösning från tredje part Software-Defined Perimeter (SDP) som kan erbjuda liknande funktioner.
  • Microsoft Defender for Cloud Apps, som fungerar som en CASB-tjänst (Cloud Access Security Broker) för att övervaka och blockera användaråtkomst till icke godkända SaaS-program från tredje part.
  • Dina befintliga kontrollanter och nätverk för programleverans från tredje part

Obs! VPN används ofta för att komma åt äldre program och har ofta bara grundläggande åtkomstkontroll och begränsad sessionsövervakning.

AWS-implementering och ytterligare kontext:


GCP-vägledning: Använd Google Cloud Identity-Aware Proxy (IAP) för att hantera åtkomst till HTTP-baserade program utanför Google Cloud, inklusive program lokalt. IAP fungerar med signerade huvuden eller användar-API:et i en App Engine-standardmiljö. Om det behövs använder du lösningen Software-Defined Perimeter (SDP) från tredje part som kan erbjuda liknande funktioner.

Du har också möjlighet att använda Microsoft Defender for Cloud Apps som fungerar som en CASB-tjänst (Cloud Access Security Broker) för att övervaka och blockera användaråtkomst till icke godkända SaaS-program från tredje part.

Obs! VPN används ofta för att komma åt äldre program och har ofta bara grundläggande åtkomstkontroll och begränsad sessionsövervakning.

GCP-implementering och ytterligare kontext:

Kunders säkerhetsintressenter (Läs mer):