Delen via

Beveiligingsbeheer: Identiteitsbeheer

  • Artikel

Identiteitsbeheer omvat besturingselementen voor het instellen van een veilige identiteit en toegangsbeheer met behulp van identiteits- en toegangsbeheersystemen, waaronder het gebruik van eenmalige aanmelding, sterke verificaties, beheerde identiteiten (en service-principals) voor toepassingen, voorwaardelijke toegang en bewaking van accountafwijkingen.

IM-1: Gecentraliseerd identiteits- en verificatiesysteem gebruiken

CIS-besturingselementen v8-id('s) NIST SP 800-53 r4 ID('s) PCI-DSS-id('s) v3.2.1
6.7, 12.5 AC-2, AC-3, IA-2, IA-8 7.2, 8.3

Beveiligingsprincipe: gebruik een gecentraliseerd identiteits- en verificatiesysteem om de identiteiten en verificaties van uw organisatie voor cloud- en niet-cloudresources te beheren.

Azure-richtlijnen: Azure Active Directory (Azure AD) is de identiteits- en verificatiebeheerservice van Azure. U moet Azure AD standaardiseren om de identiteit en verificatie van uw organisatie te beheren in:

  • Microsoft-cloudresources, zoals Azure Storage, Azure Virtual Machines (Linux en Windows), Azure Key Vault, PaaS en SaaS-toepassingen.
  • De resources van uw organisatie, zoals toepassingen in Azure, toepassingen van derden die worden uitgevoerd op uw bedrijfsnetwerkresources en SaaS-toepassingen van derden.
  • Uw bedrijfsidentiteiten in Active Directory door synchronisatie naar Azure AD om een consistente en centraal beheerde identiteitsstrategie te garanderen.

Voor de Azure-services die van toepassing zijn, vermijdt u het gebruik van lokale verificatiemethoden en gebruikt u in plaats daarvan Azure Active Directory om uw serviceverificaties te centraliseren.

Opmerking: zodra dit technisch haalbaar is, moet u on-premises Active Directory toepassingen migreren naar Azure AD. Dit kan een Azure AD Enterprise Directory, Business to Business-configuratie of Business to Consumer-configuratie zijn.

Azure-implementatie en aanvullende context:

AWS-richtlijnen: AWS IAM (Identity and Access Management) is de standaardservice voor identiteits- en verificatiebeheer van AWS. Gebruik AWS IAM om uw AWS-identiteit en toegangsbeheer te beheren. U kunt ook via AWS en Azure Single Sign-On (SSO) Azure AD gebruiken om de identiteit en het toegangsbeheer van AWS te beheren om te voorkomen dat dubbele accounts afzonderlijk worden beheerd in twee cloudplatforms.

AWS ondersteunt Enkele Sign-On waarmee u de identiteiten van derden van uw bedrijf (zoals Windows Active Directory of andere identiteitsarchieven) kunt overbruggen met de AWS-identiteiten om te voorkomen dat dubbele accounts worden gemaakt voor toegang tot AWS-resources.

AWS-implementatie en aanvullende context:

GCP-richtlijnen: het IAM-systeem (Identity and Access Management) van Google Cloud is de standaardservice voor identiteits- en verificatiebeheer van Google Cloud die wordt gebruikt voor Google Cloud Identity-accounts. Gebruik Google Cloud IAM om uw GCP-identiteits- en toegangsbeheer te beheren. U kunt ook via Google Cloud Identity en Azure Sigle Sign-On (SSO) Azure AD gebruiken om de identiteit en het toegangsbeheer van GCP te beheren om te voorkomen dat dubbele accounts afzonderlijk worden beheerd in een omgeving met meerdere clouds.

Google Cloud Identity is de id-provider voor alle Google-services. Het ondersteunt Enkele Sign-On waarmee u de identiteiten van derden van uw bedrijf (zoals Windows Active Directory of andere identiteitsarchieven) kunt overbruggen met Google Cloud-identiteiten om te voorkomen dat dubbele accounts worden gemaakt voor toegang tot GCP-resources.

Opmerking: Google Cloud Directory Sync gebruiken. Google biedt een connectorhulpprogramma dat kan worden geïntegreerd met de meeste LDAP-beheersystemen voor ondernemingen en identiteiten synchroniseert volgens een schema. Door een cloudidentiteitsaccount te configureren en Google Cloud Directory Sync te zingen, kunt u configureren welke van uw gebruikersaccounts, waaronder gebruikers, groepen en gebruikersprofielen, aliassen en meer, volgens een schema worden gesynchroniseerd tussen uw lokale identiteitsbeheersysteem en uw GCP-systeem.

GCP-implementatie en aanvullende context:

Belanghebbenden bij de beveiliging van klanten (meer informatie)::

IM-2: Identiteits- en verificatiesystemen beveiligen

CIS-besturingselementen v8-id('s) NIST SP 800-53 r4 ID('s) PCI-DSS-id('s) v3.2.1
5.4, 6.5 AC-2, AC-3, IA-2, IA-8, SI-4 8.2, 8.3

Beveiligingsprincipe: Beveilig uw identiteit en verificatiesysteem als een hoge prioriteit in de cloudbeveiligingspraktijk van uw organisatie. Algemene beveiligingscontroles zijn onder andere:

  • Bevoorrechte rollen en accounts beperken
  • Sterke verificatie vereisen voor alle bevoegde toegang
  • Activiteiten met een hoog risico bewaken en controleren

Azure-richtlijnen: gebruik de Azure AD beveiligingsbasislijn en de Azure AD Identity Secure Score om uw Azure AD identiteitsbeveiligingspostuur te evalueren en hiaten in de beveiliging en configuratie op te lossen. De Azure AD Identity Secure Score evalueert Azure AD voor de volgende configuraties:

  • Beperkte beheerdersrollen gebruiken
  • Beleid voor gebruikersrisico's inschakelen
  • Meer dan één globale beheerder aanwijzen
  • Beleid inschakelen om verouderde verificatie te blokkeren
  • Zorg ervoor dat alle gebruikers meervoudige verificatie kunnen voltooien voor veilige toegang
  • MFA vereisen voor beheerdersrollen
  • Selfservice voor wachtwoordherstel inschakelen
  • Wachtwoorden niet laten verlopen
  • Beleid voor aanmeldingsrisico's inschakelen
  • Gebruikers niet toestaan toestemming te verlenen aan niet-beheerde toepassingen

Gebruik Azure AD Identity Protection om identiteitsrisico's te detecteren, te onderzoeken en op te lossen. Gebruik Defender for Identity om uw on-premises Active Directory domein op dezelfde manier te beveiligen.

Opmerking: volg de gepubliceerde aanbevolen procedures voor alle andere identiteitsonderdelen, met inbegrip van uw on-premises Active Directory en eventuele mogelijkheden van derden, en de infrastructuren (zoals besturingssystemen, netwerken, databases) waarop ze worden gehost.

Azure-implementatie en aanvullende context:

AWS-richtlijnen: gebruik de volgende aanbevolen beveiligingsprocedures om uw AWS IAM te beveiligen:

  • Toegangssleutels voor aws-accounthoofdgebruikers instellen voor noodtoegang, zoals beschreven in PA-5 (Toegang voor noodgevallen instellen)
  • Volg de principes van minimale bevoegdheden voor toegangstoewijzingen
  • Gebruik IAM-groepen om beleidsregels toe te passen in plaats van afzonderlijke gebruikers.
  • Volg de richtlijnen voor sterke verificatie in IM-6 (Besturingselementen voor sterke verificatie gebruiken) voor alle gebruikers
  • Aws-organisaties SCP (servicebeheerbeleid) en machtigingsgrenzen gebruiken
  • IAM Access Advisor gebruiken om de toegang tot de service te controleren
  • IAM-referentierapport gebruiken om gebruikersaccounts en referentiestatus bij te houden

Opmerking: volg gepubliceerde best practices als u andere identiteits- en verificatiesystemen hebt, bijvoorbeeld de Azure AD beveiligingsbasislijn als u Azure AD gebruikt om aws-identiteit en -toegang te beheren.

AWS-implementatie en aanvullende context:

GCP-richtlijnen: gebruik de volgende aanbevolen beveiligingsprocedures om uw Google Cloud IAM- en Cloud Identity-services voor uw organisaties te beveiligen:

  • Stel een superbeheerdersaccount in voor toegang in noodgevallen door de aanbevelingen in PA-5 te volgen ('Noodtoegang instellen').
  • Maak een e-mailadres voor superbeheerders (als het superbeheerdersaccount van Google Workspace of Cloud Identity) en dit account mag niet specifiek zijn voor een bepaalde gebruiker voor het geval er noodherstel nodig is.
  • Principes van minimale bevoegdheden en scheiding van taken volgen
  • Vermijd het gebruik van superbeheerdersaccount voor dagelijkse activiteiten
  • Gebruik Google Cloud Identity-groepen om beleid toe te passen in plaats van beleid toe te passen op afzonderlijke gebruikers.
  • Volg de richtlijnen voor sterke verificatie zoals beschreven in IM-6 ('Krachtige verificatiebesturingselementen gebruiken') voor alle gebruikers met verhoogde bevoegdheden.
  • IAM-beleid gebruiken om de toegang tot resources te beperken
  • De organisatiebeleidsservice gebruiken om beperkingen voor resources te beheren en te configureren
  • IAM-auditlogboeken gebruiken in cloudcontrolelogboeken om bevoegde activiteiten te controleren

Opmerking: volg gepubliceerde best practices als u andere identiteit- en verificatiesystemen hebt, bijvoorbeeld de Azure AD beveiligingsbasislijn als u Azure AD gebruikt om GCP-identiteit en -toegang te beheren.

GCP-implementatie en aanvullende context:

Belanghebbenden bij de beveiliging van klanten (meer informatie):

IM-3: toepassingsidentiteiten veilig en automatisch beheren

CIS Controls v8 ID('s) NIST SP 800-53 r4 ID('s) PCI-DSS-id('s) v3.2.1
N.v.t. AC-2, AC-3, IA-4, IA-5, IA-9 N.v.t.

Beveiligingsprincipe: gebruik beheerde toepassingsidentiteiten in plaats van menselijke accounts te maken voor toepassingen om toegang te krijgen tot resources en code uit te voeren. Beheerde toepassingsidentiteiten bieden voordelen, zoals het verminderen van de blootstelling van referenties. Automatiseer de rotatie van referenties om de beveiliging van de identiteiten te garanderen.

Azure-richtlijnen: Gebruik beheerde Azure-identiteiten, die kunnen worden geverifieerd bij Azure-services en -resources die ondersteuning bieden voor Azure AD-verificatie. Referenties voor beheerde identiteiten worden volledig beheerd, geroteerd en beveiligd door het platform, waarbij in code vastgelegde referenties in broncode- of configuratiebestanden worden vermeden.

Voor services die geen beheerde identiteiten ondersteunen, gebruikt u Azure AD om een service-principal met beperkte machtigingen op resourceniveau te maken. Het wordt aanbevolen om service-principals te configureren met certificaatreferenties en terug te vallen op clientgeheimen voor verificatie.

Azure-implementatie en aanvullende context:

AWS-richtlijnen: gebruik AWS IAM-rollen in plaats van gebruikersaccounts te maken voor resources die deze functie ondersteunen. IAM-rollen worden beheerd door het platform op de back-end en de referenties worden tijdelijk en automatisch geroteerd. Dit voorkomt het maken van langetermijntoegangssleutels of een gebruikersnaam/wachtwoord voor toepassingen en in code vastgelegde referenties in broncode- of configuratiebestanden.

U kunt service-gekoppelde rollen gebruiken die zijn gekoppeld aan vooraf gedefinieerd machtigingsbeleid voor toegang tussen AWS-services in plaats van uw eigen rolmachtigingen voor de IAM-rollen aan te passen.

Opmerking: voor services die geen ondersteuning bieden voor IAM-rollen, gebruikt u toegangssleutels, maar volgt u de aanbevolen beveiligingsprocedures zoals IM-8 Beperk de blootstelling van referenties en geheimen om uw sleutels te beveiligen.

AWS-implementatie en aanvullende context:

GCP-richtlijnen: gebruik door Google beheerde serviceaccounts in plaats van door gebruikers beheerde accounts te maken voor resources die deze functie ondersteunen. Door Google beheerde serviceaccounts worden beheerd door het platform op de back-end en de sleutels van het serviceaccount zijn tijdelijk en worden automatisch geroteerd. Dit voorkomt het maken van langetermijntoegangssleutels of een gebruikersnaam/wachtwoord voor toepassingen en in code vastgelegde referenties in broncode- of configuratiebestanden.

Gebruik Beleidsinformatie om verdachte activiteiten voor serviceaccounts te begrijpen en te herkennen.

GCP-implementatie en aanvullende context:

Belanghebbenden bij de beveiliging van klanten (meer informatie):

IM-4: Server en services verifiëren

CIS Controls v8 ID('s) NIST SP 800-53 r4 ID('s) PCI-DSS-id('s) v3.2.1
N.v.t. IA-9 N.v.t.

Beveiligingsprincipe: verifieer externe servers en services aan de clientzijde om ervoor te zorgen dat u verbinding maakt met vertrouwde server en services. Het meest voorkomende serververificatieprotocol is TLS (Transport Layer Security), waarbij de clientzijde (vaak een browser of clientapparaat) de server verifieert door te controleren of het certificaat van de server is uitgegeven door een vertrouwde certificeringsinstantie.

Opmerking: wederzijdse verificatie kan worden gebruikt wanneer zowel de server als de client elkaar verifiëren.

Azure-richtlijnen: veel Azure-services ondersteunen standaard TLS-verificatie. Voor services die standaard geen ondersteuning bieden voor TLS-verificatie of die ONDERSTEUNING bieden voor het uitschakelen van TLS, moet u ervoor zorgen dat deze altijd is ingeschakeld voor de ondersteuning van de server-/clientverificatie. Uw clienttoepassing moet ook zijn ontworpen om de identiteit van de server/client te verifiëren (door het certificaat van de server te verifiëren dat is uitgegeven door een vertrouwde certificeringsinstantie) in de handshakefase.

Opmerking: Services zoals API Management en API Gateway ondersteunen wederzijdse TLS-verificatie.

Azure-implementatie en aanvullende context:

AWS-richtlijnen: veel AWS-services ondersteunen standaard TLS-verificatie. Voor services die standaard geen ondersteuning bieden voor TLS-verificatie of die ONDERSTEUNING bieden voor het uitschakelen van TLS, moet u ervoor zorgen dat deze altijd is ingeschakeld voor de ondersteuning van de server-/clientverificatie. Uw clienttoepassing moet ook zijn ontworpen om de identiteit van de server/client te verifiëren (door het certificaat van de server te verifiëren dat is uitgegeven door een vertrouwde certificeringsinstantie) in de handshakefase.

Opmerking: Services zoals API Gateway ondersteunen wederzijdse TLS-verificatie.

AWS-implementatie en aanvullende context:

GCP-richtlijnen: veel GCP-services ondersteunen standaard TLS-verificatie. Voor services die dit niet standaard ondersteunen of ondersteuning bieden voor het uitschakelen van TLS, moet u ervoor zorgen dat deze altijd is ingeschakeld om de server-/clientverificatie te ondersteunen. Uw clienttoepassing moet ook zijn ontworpen om de identiteit van de server/client te verifiëren (door het certificaat van de server te verifiëren dat is uitgegeven door een vertrouwde certificeringsinstantie) in de handshakefase.

Opmerking: Services zoals Cloud Load Balancing ondersteunen wederzijdse TLS-verificatie.

GCP-implementatie en aanvullende context:

Belanghebbenden bij de beveiliging van klanten (meer informatie):

IM-5: Eenmalige aanmelding (SSO) gebruiken voor toegang tot toepassingen

CIS Controls v8 ID('s) NIST SP 800-53 r4 ID('s) PCI-DSS-id('s) v3.2.1
12.5 IA-4, IA-2, IA-8 N.v.t.

Beveiligingsprincipe: gebruik eenmalige aanmelding (SSO) om de gebruikerservaring voor verificatie bij resources, waaronder toepassingen en gegevens in cloudservices en on-premises omgevingen, te vereenvoudigen.

Azure-richtlijnen: Gebruik Azure AD voor toegang tot workloadtoepassingen (klantgericht) via Azure AD eenmalige aanmelding (SSO), waardoor dubbele accounts minder nodig zijn. Azure AD biedt identiteits- en toegangsbeheer voor Azure-resources (in het beheervlak, waaronder CLI, PowerShell, de portal), cloudtoepassingen en on-premises toepassingen.

Azure AD ondersteunt ook eenmalige aanmelding voor bedrijfsidentiteiten zoals zakelijke gebruikersidentiteiten, evenals externe gebruikersidentiteiten van vertrouwde externe en openbare gebruikers.

Azure-implementatie en aanvullende context:

AWS-richtlijnen: gebruik AWS Cognito om de toegang tot de workloads van uw klantgerichte toepassingen te beheren via eenmalige aanmelding (SSO), zodat klanten hun identiteiten van derden kunnen overbruggingen van verschillende id-providers.

Voor SSO-toegang tot de systeemeigen AWS-resources (inclusief toegang tot aws-console of servicebeheer en toegang op gegevensvlakniveau), gebruikt u AWS Sigle Sign-On om de noodzaak van dubbele accounts te verminderen.

Met AWS SSO kunt u ook bedrijfsidentiteiten (zoals identiteiten van Azure Active Directory) koppelen aan AWS-identiteiten, evenals externe gebruikersidentiteiten van vertrouwde externe en openbare gebruikers.

AWS-implementatie en aanvullende context:

GCP-richtlijnen: Gebruik Google Cloud Identity om de toegang tot uw klantgerichte workloadtoepassing te beheren via Eenmalige aanmelding van Google Cloud Identity, waardoor dubbele accounts minder nodig zijn. Google Cloud Identity biedt identiteits- en toegangsbeheer voor GCP (in het beheervlak met inbegrip van Google Cloud CLI, consoletoegang), cloudtoepassingen en on-premises toepassingen.

Google Cloud Identity ondersteunt ook eenmalige aanmelding voor bedrijfsidentiteiten zoals zakelijke gebruikersidentiteiten van Azure AD of Active Directory, evenals externe gebruikersidentiteiten van vertrouwde externe en openbare gebruikers. GCP-implementatie en aanvullende context:

Belanghebbenden bij de beveiliging van klanten (meer informatie):

IM-6: Krachtige verificatiebesturingselementen gebruiken

CIS Controls v8 ID('s) NIST SP 800-53 r4 ID('s) 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

Beveiligingsprincipe: sterke verificatiecontroles (sterke verificatie zonder wachtwoord of meervoudige verificatie) afdwingen met uw gecentraliseerde identiteits- en verificatiebeheersysteem voor alle toegang tot resources. Verificatie op basis van wachtwoordreferenties alleen wordt beschouwd als verouderd, omdat het onveilig is en niet bestand is tegen populaire aanvalsmethoden.

Wanneer u sterke verificatie implementeert, configureert u eerst beheerders en bevoegde gebruikers om het hoogste niveau van de sterke verificatiemethode te garanderen, snel gevolgd door het implementeren van het juiste sterke verificatiebeleid voor alle gebruikers.

Opmerking: als verouderde verificatie op basis van wachtwoorden vereist is voor verouderde toepassingen en scenario's, moet u ervoor zorgen dat de aanbevolen procedures voor wachtwoordbeveiliging, zoals complexiteitsvereisten, worden gevolgd.

Azure-richtlijnen: Azure AD ondersteunt krachtige verificatiebesturingselementen via methoden zonder wachtwoord en meervoudige verificatie (MFA).

  • Verificatie zonder wachtwoord: gebruik verificatie zonder wachtwoord als uw standaardverificatiemethode. Er zijn drie opties beschikbaar voor verificatie zonder wachtwoord: Windows Hello voor Bedrijven, aanmelden via de telefoon van de Microsoft Authenticator-app en FIDO2-beveiligingssleutels. Daarnaast kunnen klanten on-premises verificatiemethoden zoals smartcards gebruiken.
  • Meervoudige verificatie: Azure MFA kan worden afgedwongen voor alle gebruikers, geselecteerde gebruikers of op het niveau per gebruiker op basis van aanmeldingsvoorwaarden en risicofactoren. Schakel Azure MFA in en volg Microsoft Defender voor cloudidentiteit en toegangsbeheeraanbeveling voor uw MFA-installatie.

Als verouderde verificatie op basis van wachtwoorden nog steeds wordt gebruikt voor Azure AD verificatie, moet u er rekening mee houden dat cloudaccounts (gebruikersaccounts die rechtstreeks in Azure zijn gemaakt) een standaardwachtwoordbeleid voor de basislijn hebben. En hybride accounts (gebruikersaccounts die afkomstig zijn van on-premises Active Directory) volgen het on-premises wachtwoordbeleid.

Voor toepassingen en services van derden die mogelijk standaard-id's en wachtwoorden hebben, moet u deze uitschakelen of wijzigen tijdens de eerste installatie van de service.

Azure-implementatie en aanvullende context:

AWS-richtlijnen: AWS IAM ondersteunt krachtige verificatiecontroles via meervoudige verificatie (MFA). MFA kan worden afgedwongen voor alle gebruikers, geselecteerde gebruikers of op het niveau per gebruiker op basis van gedefinieerde voorwaarden.

Als u bedrijfsaccounts uit een directory van derden (zoals Windows Active Directory) met AWS-identiteiten gebruikt, volgt u de respectieve beveiligingsrichtlijnen om sterke verificatie af te dwingen. Raadpleeg de Azure-richtlijnen voor dit besturingselement als u Azure AD gebruikt om AWS-toegang te beheren.

Opmerking: voor toepassingen van derden en AWS-services die mogelijk standaard-id's en wachtwoorden hebben, moet u deze uitschakelen of wijzigen tijdens de eerste installatie van de service.

AWS-implementatie en aanvullende context:

GCP-richtlijnen: Google Cloud Identity ondersteunt krachtige verificatiecontroles via meervoudige verificatie (MFA). MFA kan worden afgedwongen voor alle gebruikers, geselecteerde gebruikers of op het niveau per gebruiker op basis van gedefinieerde voorwaarden. Als u superbeheerdersaccounts voor cloudidentiteit (en werkruimte) wilt beveiligen, kunt u beveiligingssleutels en het Google Advanced Protection Program gebruiken voor maximale beveiliging.

Als u bedrijfsaccounts uit een directory van derden (zoals Windows Active Directory) gebruikt met Google Cloud-identiteiten, volgt u de respectieve beveiligingsrichtlijnen om sterke verificatie af te dwingen. Raadpleeg de Azure-richtlijnen voor dit besturingselement als u Azure AD gebruikt om toegang tot Google Cloud te beheren.

Gebruik Identity-Aware Proxy om een centrale autorisatielaag tot stand te brengen voor toepassingen die toegankelijk zijn via HTTPS, zodat u een model voor toegangsbeheer op toepassingsniveau kunt gebruiken in plaats van te vertrouwen op firewalls op netwerkniveau.

Opmerking: voor toepassingen van derden en GCP-services die mogelijk standaard-id's en wachtwoorden hebben, moet u deze uitschakelen of wijzigen tijdens de eerste installatie van de service.

GCP-implementatie en aanvullende context:

Belanghebbenden bij de beveiliging van klanten (meer informatie):

IM-7: toegang tot resources beperken op basis van voorwaarden

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

Beveiligingsprincipe: valideer expliciet vertrouwde signalen om gebruikerstoegang tot resources toe te staan of te weigeren, als onderdeel van een toegangsmodel zonder vertrouwen. Signalen die moeten worden gevalideerd, moeten sterke verificatie van gebruikersaccounts, gedragsanalyses van gebruikersaccounts, betrouwbaarheid van apparaten, lidmaatschap van gebruikers of groepen, locaties, enzovoort omvatten.

Azure-richtlijnen: gebruik Azure AD voorwaardelijke toegang voor gedetailleerdere toegangsbeheer op basis van door de gebruiker gedefinieerde voorwaarden, zoals het vereisen van gebruikersaanmelding van bepaalde IP-bereiken (of apparaten) om MFA te gebruiken. met Azure AD voorwaardelijke toegang kunt u toegangsbeheer afdwingen voor de apps van uw organisatie op basis van bepaalde voorwaarden.

Definieer de toepasselijke voorwaarden en criteria voor Azure AD voorwaardelijke toegang in de workload. Houd rekening met de volgende veelvoorkomende gebruiksvoorbeelden:

  • Multi-Factor Authentication vereisen voor gebruikers met beheerdersrollen
  • Multi-Factor Authentication vereisen voor Azure-beheertaken
  • Aanmeldingen blokkeren voor gebruikers die verouderde verificatieprotocollen gebruiken
  • Vertrouwde locaties voor registratie van Azure AD Multi-Factor Authentication vereisen
  • Toegang vanaf specifieke locaties blokkeren of verlenen
  • Riskant aanmeldingsgedrag blokkeren
  • Door de organisatie beheerde apparaten vereisen voor specifieke toepassingen

Opmerking: Gedetailleerde beheeropties voor verificatiesessies kunnen ook worden geïmplementeerd via Azure AD beleid voor voorwaardelijke toegang, zoals aanmeldingsfrequentie en permanente browsersessie.

Azure-implementatie en aanvullende context:

AWS-richtlijnen: maak IAM-beleid en definieer voorwaarden voor gedetailleerdere toegangsbeheer op basis van door de gebruiker gedefinieerde voorwaarden, zoals het vereisen van gebruikersaanmelding van bepaalde IP-bereiken (of apparaten) om meervoudige verificatie te gebruiken. Voorwaardeinstellingen kunnen één of meerdere voorwaarden en logica bevatten.

Beleidsregels kunnen worden gedefinieerd vanuit zes verschillende dimensies: beleid op basis van identiteit, op resources gebaseerd beleid, machtigingengrenzen, AWS Organizations Service Control Policy (SCP), Access Control Lists (ACL) en sessiebeleidsregels.

AWS-implementatie en aanvullende context:

GCP-richtlijnen: IAM-voorwaarden maken en definiëren voor gedetailleerdere op kenmerken gebaseerde toegangsbeheer op basis van door de gebruiker gedefinieerde voorwaarden, zoals het vereisen van gebruikersaanmelding van bepaalde IP-bereiken (of apparaten) om meervoudige verificatie te gebruiken. Voorwaarde-instellingen kunnen één of meerdere voorwaarden en logica bevatten.

Voorwaarden worden opgegeven in de rolbindingen van het beleid voor toestaan van een resource. Voorwaardenkenmerken zijn gebaseerd op de aangevraagde resource, bijvoorbeeld het type of de naam, of op details van de aanvraag, bijvoorbeeld de tijdstempel of het IP-adres van het doel.

GCP-implementatie en aanvullende context:

Belanghebbenden bij de beveiliging van klanten (meer informatie):

IM-8: Beperk de blootstelling van referenties en geheimen

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

Beveiligingsprincipe: zorg ervoor dat toepassingsontwikkelaars veilig referenties en geheimen verwerken:

  • Vermijd het insluiten van de referenties en geheimen in de code- en configuratiebestanden
  • Key Vault of een beveiligde sleutelopslagservice gebruiken om de referenties en geheimen op te slaan
  • Scannen op referenties in de broncode.

Opmerking: dit wordt vaak beheerd en afgedwongen via een beveiligd levenscyclusproces voor softwareontwikkeling (SDLC) en DevOps-beveiligingsproces.

Azure-richtlijnen: wanneer het gebruik van een beheerde identiteit geen optie is, moet u ervoor zorgen dat geheimen en referenties worden opgeslagen op beveiligde locaties, zoals Azure Key Vault, in plaats van ze in te sluiten in de code- en configuratiebestanden.

Als u Azure DevOps en GitHub gebruikt voor uw codebeheerplatform:

  • Implementeer Azure DevOps Credential Scanner om referenties in de code te identificeren.
  • Gebruik voor GitHub de systeemeigen functie voor het scannen van geheimen om referenties of andere vormen van geheimen in de code te identificeren.

Clients zoals Azure Functions, Azure Apps-services en VM's kunnen beheerde identiteiten gebruiken om veilig toegang te krijgen tot Azure Key Vault. Zie Besturingselementen voor gegevensbescherming met betrekking tot het gebruik van Azure Key Vault voor geheimenbeheer.

Opmerking: Azure Key Vault biedt automatische rotatie voor ondersteunde services. Voor geheimen die niet automatisch kunnen worden geroteerd, moet u ervoor zorgen dat ze regelmatig handmatig worden geroteerd en opgeschoond wanneer ze niet meer in gebruik zijn.

Azure-implementatie en aanvullende context:

AWS-richtlijnen: wanneer het gebruik van een IAM-rol voor toepassingstoegang geen optie is, moet u ervoor zorgen dat geheimen en referenties worden opgeslagen op beveiligde locaties zoals AWS Secret Manager of Systems Manager Parameter Store, in plaats van ze in te sluiten in de code- en configuratiebestanden.

Gebruik CodeGuru Reviewer voor statische codeanalyse waarmee de geheimen in code in uw broncode kunnen worden gedetecteerd.

Als u Azure DevOps en GitHub gebruikt voor uw codebeheerplatform:

  • Implementeer Azure DevOps Credential Scanner om referenties in de code te identificeren.
  • Gebruik voor GitHub de systeemeigen functie voor het scannen van geheimen om referenties of andere vormen van geheimen in de code te identificeren.

Opmerking: Secrets Manager biedt automatische rotatie van geheimen voor ondersteunde services. Voor geheimen die niet automatisch kunnen worden geroteerd, moet u ervoor zorgen dat ze regelmatig handmatig worden geroteerd en opgeschoond wanneer ze niet meer in gebruik zijn.

AWS-implementatie en aanvullende context:

GCP-richtlijnen: wanneer het gebruik van een door Google beheerd serviceaccount voor toegang tot toepassingen geen optie is, moet u ervoor zorgen dat geheimen en referenties worden opgeslagen op beveiligde locaties, zoals Secret Manager van Google Cloud, in plaats van ze in te sluiten in de code- en configuratiebestanden.

Gebruik de Google Cloud Code-extensie op IDE's (integrated development environment) zoals Visual Studio Code om geheimen die worden beheerd door Secret Manager te integreren in uw code.

Als u Azure DevOps of GitHub gebruikt voor uw codebeheerplatform:

  • Implementeer Azure DevOps Credential Scanner om referenties in de code te identificeren.
  • Gebruik voor GitHub de systeemeigen functie voor het scannen van geheimen om referenties of andere vormen van geheimen in de code te identificeren.

Opmerking: stel als best practice roulatieschema's in voor geheimen die zijn opgeslagen in Secret Manager.

GCP-implementatie en aanvullende context:

Belanghebbenden bij de beveiliging van klanten (meer informatie):

IM-9: Beveiligde gebruikerstoegang tot bestaande toepassingen

CIS Controls v8 ID('s) NIST SP 800-53 r4 ID('s) PCI-DSS-id('s) v3.2.1
6.7, 12.5 AC-2, AC-3, SC-11 N.v.t.

Beveiligingsprincipe: In een hybride omgeving, waarin u on-premises toepassingen of niet-systeemeigen cloudtoepassingen hebt die gebruikmaken van verouderde verificatie, kunt u oplossingen overwegen zoals Cloud Access Security Broker (CASB), toepassingsproxy, eenmalige aanmelding (SSO) om de toegang tot deze toepassingen te beheren, voor de volgende voordelen:

  • Gecentraliseerde sterke verificatie afdwingen
  • Riskante activiteiten van eindgebruikers bewaken en beheren
  • Activiteiten van riskante verouderde toepassingen bewaken en herstellen
  • Gevoelige gegevensoverdracht detecteren en voorkomen

Azure-richtlijnen: beveilig uw on-premises en niet-systeemeigen cloudtoepassingen met behulp van verouderde verificatie door ze te verbinden met:

  • Azure AD toepassingsproxy en configureer verificatie op basis van headers om eenmalige aanmelding (SSO) toegang tot de toepassingen toe te staan voor externe gebruikers, terwijl de betrouwbaarheid van zowel externe gebruikers als apparaten met Azure AD voorwaardelijke toegang expliciet wordt gecontroleerd. Gebruik indien nodig een SDP-oplossing (Software-Defined Perimeter) van derden die vergelijkbare functionaliteit kan bieden.
  • Microsoft Defender for Cloud Apps, die een CASB-service (Cloud Access Security Broker) bedient om gebruikerstoegang tot niet-goedgekeurde SaaS-toepassingen van derden te bewaken en te blokkeren.
  • Uw bestaande toepassingsleveringscontrollers en netwerken van derden.

Opmerking: VPN's worden vaak gebruikt voor toegang tot verouderde toepassingen en hebben vaak alleen basistoegangsbeheer en beperkte sessiebewaking.

Azure-implementatie en aanvullende context:

AWS-richtlijnen: volg de richtlijnen van Azure om uw on-premises en niet-systeemeigen cloudtoepassingen te beveiligen met behulp van verouderde verificatie door ze te verbinden met:

  • Azure AD toepassingsproxy en configureer headers om eenmalige aanmelding (SSO) toegang tot de toepassingen toe te staan voor externe gebruikers, terwijl de betrouwbaarheid van zowel externe gebruikers als apparaten met Azure AD voorwaardelijke toegang expliciet wordt gecontroleerd. Gebruik indien nodig een SDP-oplossing (Software-Defined Perimeter) van derden die vergelijkbare functionaliteit kan bieden.
  • Microsoft Defender for Cloud Apps, die fungeert als een CASB-service (Cloud Access Security Broker) voor het bewaken en blokkeren van gebruikerstoegang tot niet-goedgekeurde SaaS-toepassingen van derden.
  • Uw bestaande toepassingsleveringscontrollers en netwerken van derden

Opmerking: VPN's worden vaak gebruikt voor toegang tot verouderde toepassingen en hebben vaak alleen basistoegangsbeheer en beperkte sessiebewaking.

AWS-implementatie en aanvullende context:

GCP-richtlijnen: Gebruik Google Cloud Identity-Aware Proxy (IAP) voor het beheren van toegang tot HTTP-toepassingen buiten Google Cloud, inclusief on-premises toepassingen. IAP werkt met behulp van ondertekende headers of de GEBRUIKERS-API binnen een standaardomgeving van app-engine. Gebruik indien nodig een SDP-oplossing (Software-Defined Perimeter) van derden die vergelijkbare functionaliteit kan bieden.

U hebt ook de mogelijkheid om Microsoft Defender for Cloud Apps te gebruiken die fungeert als een CLOUD Access Security Broker (CASB)-service voor het bewaken en blokkeren van gebruikerstoegang tot niet-goedgekeurde SaaS-toepassingen van derden.

Opmerking: VPN's worden vaak gebruikt voor toegang tot verouderde toepassingen en hebben vaak alleen basistoegangsbeheer en beperkte sessiebewaking.

GCP-implementatie en aanvullende context:

Belanghebbenden bij de beveiliging van klanten (meer informatie):