Aanbevelingen voor identiteits- en toegangsbeheer

Is van toepassing op deze aanbeveling voor de controlelijst voor Azure Well-Architected Framework Security:

SE:05	Implementeer strikt, voorwaardelijk en controleerbaar identiteits- en toegangsbeheer (IAM) voor alle workloadgebruikers, teamleden en systeemonderdelen. Beperk de toegang tot uitsluitend indien nodig. Gebruik moderne industriestandaarden voor alle verificatie- en autorisatie-implementaties. Beperk en controleer de toegang die niet is gebaseerd op identiteit.

In deze handleiding worden de aanbevelingen beschreven voor het verifiëren en autoriseren van identiteiten die toegang proberen te krijgen tot uw workloadresources.

Vanuit technisch beheerperspectief is identiteit altijd de primaire perimeter. Dit bereik omvat niet alleen de randen van uw workload. Het bevat ook afzonderlijke onderdelen die zich in uw workload bevinden. Typische identiteiten zijn onder andere:

• Mensen. Toepassingsgebruikers, beheerders, operators, auditors en slechte actoren.

• Systemen. Workloadidentiteiten, beheerde identiteiten, API-sleutels, service-principals en Azure-resources.

• Anoniem. Entiteiten die geen bewijs hebben verstrekt over wie ze zijn.

Definities 

Voorwaarde	Definitie
Verificatie (AuthN)	Een proces dat verifieert dat een identiteit is wie of wat het zegt.
Autorisatie (AuthZ)	Een proces waarmee wordt gecontroleerd of een identiteit gemachtigd is om een aangevraagde actie uit te voeren.
Voorwaardelijke toegang	Een set regels waarmee acties worden toegestaan op basis van opgegeven criteria.
IdP	Een id-provider, zoals Microsoft Entra-id.
Persona	Een functie of een functie met een set verantwoordelijkheden en acties.
Vooraf gedeelde sleutels	Een type geheim dat wordt gedeeld tussen een provider en consument en wordt gebruikt via een veilig en overeengekomen mechanisme.
Resource-id	Een identiteit die is gedefinieerd voor cloudresources die worden beheerd door het platform.
Role	Een set machtigingen waarmee wordt gedefinieerd wat een gebruiker of groep kan doen.
Bereik	Verschillende niveaus van organisatiehiërarchie waarbij een rol mag worden uitgevoerd. Ook een groep functies in een systeem.
Beveiligingsprincipal	Een identiteit die machtigingen biedt. Dit kan een gebruiker, een groep of een service-principal zijn. Alle groepsleden krijgen hetzelfde toegangsniveau.
Gebruikersidentiteit	Een identiteit voor een persoon, zoals een werknemer of een externe gebruiker.
Workload-identiteit	Een systeemidentiteit voor een toepassing, service, script, container of ander onderdeel van een workload die wordt gebruikt om zichzelf te verifiëren bij andere services en resources.

Notitie

Een identiteit kan worden gegroepeerd met andere, vergelijkbare identiteiten onder een bovenliggend item dat een beveiligingsprincipaal wordt genoemd. Een beveiligingsgroep is een voorbeeld van een beveiligingsprincipaal. Deze hiërarchische relatie vereenvoudigt het onderhoud en verbetert de consistentie. Omdat identiteitskenmerken niet op individueel niveau worden verwerkt, wordt de kans op fouten ook verminderd. In dit artikel is de term identiteit inclusief beveiligingsprinciplen.

De rol van een id-provider

Een id-provider (IdP) is een in de cloud gehoste service waarmee gebruikers als digitale identiteiten worden opgeslagen en beheerd.

Profiteer van de mogelijkheden van een vertrouwde IdP voor uw identiteits- en toegangsbeheer. Implementeer geen aangepaste systemen om een IdP te vervangen. IdP-systemen worden regelmatig verbeterd op basis van de nieuwste aanvalsvectoren door miljarden signalen per dag over meerdere tenants vast te leggen. Microsoft Entra ID is de IdP voor het Azure-cloudplatform.

Verificatie

Verificatie is een proces waarmee identiteiten worden geverifieerd. De aangevraagde identiteit is vereist om een vorm van verifieerbare identificatie op te geven. Voorbeeld:

• Een gebruikersnaam en wachtwoord.

• Een vooraf gedeeld geheim, zoals een API-sleutel die toegang verleent.

• Een SAS-token (Shared Access Signature).

• Een certificaat dat wordt gebruikt in wederzijdse TLS-verificatie.

Het verificatieproces moet zoveel mogelijk worden verwerkt door uw IdP.

Autorisatie

Autorisatie is een proces dat acties toestaat of weigert die door de geverifieerde identiteit worden aangevraagd. De actie kan operationeel zijn of gerelateerd zijn aan resourcebeheer.

Autorisatie vereist dat u machtigingen toewijst aan de identiteiten, wat u moet doen met behulp van de functionaliteit van uw IdP.

Belangrijke ontwerpstrategieën

Als u een holistische weergave wilt krijgen van de identiteitsbehoeften voor een workload, moet u de stromen, workloadassets en persona's catalogiseren, en de acties die de assets en persona's zullen uitvoeren. Uw strategie moet betrekking hebben op alle gebruiksvoorbeelden die de stromen verwerken die de workload of de bijbehorende onderdelen (externe toegang) bereiken en stromen die van de werkbelasting naar andere bronnen (binnen-buitentoegang) contact opnemen.

Elke use-case heeft waarschijnlijk een eigen set besturingselementen die u moet ontwerpen met een uitgangspunt voor inbreuk. Identificeer de voorwaardelijke keuzes op basis van de identiteitsvereisten van de use-case of de persona's. Vermijd het gebruik van één oplossing voor alle use cases. Omgekeerd moeten de besturingselementen niet zo gedetailleerd zijn dat u onnodige beheeroverhead introduceert.

U moet het identiteitstoegangspad registreren. Dit helpt bij het valideren van de besturingselementen en u kunt de logboeken gebruiken voor nalevingscontroles.

Alle identiteiten voor verificatie bepalen

• Externe toegang. Uw identiteitsontwerp moet alle gebruikers verifiëren die toegang hebben tot de workload voor verschillende doeleinden. Bijvoorbeeld een eindgebruiker die toegang heeft tot de toepassing door API's aan te roepen.

  Op gedetailleerd niveau hebben onderdelen van de workload mogelijk ook toegang nodig van buiten. Bijvoorbeeld een operator die toegang nodig heeft via de portal of toegang tot de berekening om opdrachten uit te voeren.

  Beide zijn voorbeelden van gebruikersidentiteiten met verschillende persona's .

• Toegang tot binnenuit. Uw toepassing moet toegang krijgen tot andere resources. Bijvoorbeeld het lezen van of schrijven naar het gegevensplatform, het ophalen van geheimen uit het geheime archief en het vastleggen van telemetriegegevens naar bewakingsservices. Het kan zelfs nodig zijn om toegang te krijgen tot services van derden. Voor deze toegang is een workloadidentiteit vereist, waardoor de toepassing zichzelf kan verifiëren bij de andere resources.

  Het concept is van toepassing op onderdeelniveau. In het volgende voorbeeld heeft de container mogelijk toegang nodig tot implementatiepijplijnen om de configuratie op te halen. Voor deze toegangsbehoeften is een resource-id vereist.

Al deze identiteiten moeten worden geverifieerd door uw IdP.

Hier volgt een voorbeeld van hoe identiteit kan worden geïmplementeerd in een architectuur:

Acties voor autorisatie bepalen

Vervolgens moet u weten wat elke geverifieerde identiteit probeert te doen, zodat deze acties kunnen worden geautoriseerd. De acties kunnen worden gedeeld door het type toegang dat ze nodig hebben:

• Toegang tot het gegevensvlak. Acties die plaatsvinden in het gegevensvlak, veroorzaken gegevensoverdracht voor binnen- of buitentoegang. Een toepassing die bijvoorbeeld gegevens uit een database leest en gegevens naar een database schrijft, geheimen ophaalt of logboeken schrijft naar een bewakingssink. Op onderdeelniveau worden berekeningen die installatiekopieën naar of vanuit een register ophalen of pushen, beschouwd als bewerkingen in het gegevensvlak.

• Toegang tot besturingsvlak. Acties die plaatsvinden in het besturingsvlak zorgen ervoor dat een Azure-resource wordt gemaakt, gewijzigd of verwijderd. Bijvoorbeeld wijzigingen in resource-eigenschappen.

Toepassingen richten zich doorgaans op bewerkingen op gegevensvlakken, terwijl bewerkingen vaak toegang hebben tot besturings- en gegevensvlakken. Als u autorisatiebehoeften wilt identificeren, moet u rekening houden met de operationele acties die op de resource kunnen worden uitgevoerd. Zie Bewerkingen van de Azure-resourceprovider voor informatie over de toegestane acties voor elke resource.

Autorisatie op basis van rollen opgeven

Op basis van de verantwoordelijkheid van elke identiteit autoriseert u acties die moeten worden toegestaan. Een identiteit mag niet meer doen dan nodig is. Voordat u autorisatieregels instelt, moet u een duidelijk beeld hebben van wie of wat er aanvragen doet, wat die rol mag doen en in welke mate dit kan. Deze factoren leiden tot keuzes die identiteit, rol en bereik combineren.

Bekijk een workloadidentiteit als voorbeeld. De toepassing moet toegang hebben tot de gegevenslaag tot de database, dus lees- en schrijfacties naar de gegevensresource moeten zijn toegestaan. Heeft de toepassing echter toegang tot het geheime archief nodig? Als de workloadidentiteit wordt aangetast door een slechte actor, wat zou de impact zijn op het systeem, wat is de vertrouwelijkheid, integriteit en beschikbaarheid?

Roltoewijzing

Een rol is een set machtigingen die is toegewezen aan een identiteit. Wijs rollen toe waarmee alleen de identiteit de taak kan voltooien en niet meer. Wanneer gebruikersmachtigingen zijn beperkt tot hun taakvereisten, is het eenvoudiger om verdacht of niet-geautoriseerd gedrag in het systeem te identificeren.

Stel vragen zoals deze:

• Is alleen-lezentoegang voldoende?
• Heeft de identiteit machtigingen nodig om resources te verwijderen?

Als u het toegangsniveau beperkt dat gebruikers, toepassingen of services hebben voor Azure-resources, vermindert u het potentiële kwetsbaarheid voor aanvallen. Als u alleen de minimale machtigingen verleent die nodig zijn om specifieke taken uit te voeren, wordt het risico op een geslaagde aanval of onbevoegde toegang aanzienlijk verminderd. Beveiligingsteams hebben bijvoorbeeld alleen-lezentoegang nodig tot beveiligingskenmerken voor alle technische omgevingen. Dat niveau is voldoende om risicofactoren te beoordelen, potentiële risicobeperking te identificeren en over de risico's te rapporteren.

Er zijn scenario's waarin gebruikers meer toegang nodig hebben vanwege de organisatiestructuur en teamorganisatie. Er kan sprake zijn van overlapping tussen verschillende rollen of dat individuele gebruikers meerdere standaardrollen kunnen uitvoeren. In dit geval gebruikt u meerdere roltoewijzingen die zijn gebaseerd op de bedrijfsfunctie in plaats van een aangepaste rol te maken voor elk van deze gebruikers. Hierdoor zijn de rollen eenvoudiger te beheren.

Vermijd machtigingen die specifiek verwijzen naar afzonderlijke resources of gebruikers. Gedetailleerde en aangepaste machtigingen zorgen voor complexiteit en verwarring, omdat ze niet de intentie doorgeven aan nieuwe resources die vergelijkbaar zijn. Dit kan een complexe verouderde configuratie maken die moeilijk te onderhouden is en negatieve gevolgen heeft voor zowel beveiliging als betrouwbaarheid.

Compromis: Een gedetailleerde benadering voor toegangsbeheer maakt betere controle en bewaking van gebruikersactiviteiten mogelijk.

Een rol heeft ook een gekoppeld bereik. De rol kan worden uitgevoerd op de toegestane beheergroep, abonnement, resourcegroep of resourcebereik, of op een ander aangepast bereik. Zelfs als de identiteit een beperkte set machtigingen heeft, is het riskant om het bereik te verbreed om resources op te nemen die buiten de functie van de identiteit vallen. Leestoegang tot alle broncode en gegevens kan bijvoorbeeld gevaarlijk zijn en moet worden beheerd.

U wijst rollen toe aan identiteiten met behulp van op rollen gebaseerd toegangsbeheer (RBAC). Gebruik altijd RBAC van idP om te profiteren van functies waarmee u toegangsbeheer consistent kunt toepassen en deze strikt kunt intrekken.

Ingebouwde rollen gebruiken. Ze zijn ontworpen om de meeste gebruiksvoorbeelden te behandelen. Aangepaste rollen zijn krachtig en soms nuttig, maar u moet ze reserveren voor scenario's waarin ingebouwde rollen niet werken. Aanpassing leidt tot complexiteit die verwarring verhoogt en automatisering complexer, uitdagender en kwetsbaarder maakt. Deze factoren hebben allemaal een negatieve invloed op de beveiliging.

Verkreed rollen die beginnen met minimale bevoegdheden en voeg meer toe op basis van uw operationele of gegevenstoegangsbehoeften. Uw technische teams moeten duidelijke richtlijnen hebben voor het implementeren van machtigingen.

Als u fijnmazige controle op RBAC wilt, voegt u voorwaarden toe aan de roltoewijzing op basis van context, zoals acties en kenmerken.

Keuzes voor voorwaardelijke toegang maken

Geef niet alle identiteiten hetzelfde toegangsniveau. Baseer uw beslissingen op twee belangrijke factoren:

• Tijd. Hoe lang de identiteit toegang heeft tot uw omgeving.

• Bevoegdheid. Het machtigingsniveau.

Deze factoren sluiten elkaar niet uit. Een gecompromitteerde identiteit met meer bevoegdheden en onbeperkte toegangsduur kan meer controle krijgen over het systeem en de gegevens of die toegang gebruiken om de omgeving te blijven wijzigen. Beperk deze toegangsfactoren zowel als een preventieve maatregel en om de straalstraal te regelen.

• JIT-benaderingen (Just-In-Time) bieden alleen de vereiste bevoegdheden wanneer ze nodig zijn.

• Just Enough Access (JEA) biedt alleen de vereiste bevoegdheden.

Hoewel tijd en bevoegdheden de primaire factoren zijn, zijn er andere voorwaarden die van toepassing zijn. U kunt bijvoorbeeld ook het apparaat, netwerk en de locatie gebruiken waaruit de toegang afkomstig is om beleid in te stellen.

Gebruik krachtige besturingselementen die onbevoegde toegang filteren, detecteren en blokkeren, waaronder parameters zoals gebruikersidentiteit en locatie, apparaatstatus, context van workload, gegevensclassificatie en afwijkingen.

Uw workload moet bijvoorbeeld worden geopend door identiteiten van derden, zoals leveranciers, partners en klanten. Ze hebben het juiste toegangsniveau nodig in plaats van de standaardmachtigingen die u aan fulltime werknemers verstrekt. Duidelijke differentiatie van externe accounts maakt het gemakkelijker om aanvallen te voorkomen en te detecteren die afkomstig zijn van deze vectoren.

Uw keuze van IdP moet die differentiatie kunnen bieden, ingebouwde functies bieden die machtigingen verlenen op basis van de minste bevoegdheden en ingebouwde bedreigingsinformatie bieden. Dit omvat het bewaken van toegangsaanvragen en aanmeldingen. De Azure IdP is Microsoft Entra-id. Zie de sectie Azure-facilitering van dit artikel voor meer informatie.

Kritieke impactaccounts beveiligen

Beheeridentiteiten introduceren enkele van de grootste beveiligingsrisico's, omdat voor de taken die ze uitvoeren bevoorrechte toegang tot een brede set van deze systemen en toepassingen is vereist. Inbreuk of misbruik kan een schadelijk effect hebben op uw bedrijf en haar informatiesystemen. De beveiliging van het beheer is een van de meest kritieke beveiligingsgebieden.

Voor het beveiligen van bevoegde toegang tegen bepaalde aanvallers moet u een volledige en doordachte benadering nemen om deze systemen te isoleren van risico's. Hier volgen enkele strategieën:

• Minimaliseer het aantal kritieke impactaccounts.

• Gebruik afzonderlijke rollen in plaats van bevoegdheden voor bestaande identiteiten op te heffen.

• Voorkom permanente of permanente toegang met behulp van de JIT-functies van uw IdP. Voor onderbrekingsglassituaties volgt u een noodtoegangsproces.

• Gebruik moderne toegangsprotocollen , zoals verificatie zonder wachtwoord of meervoudige verificatie. Externaliseer deze mechanismen naar uw IdP.

• Belangrijke beveiligingskenmerken afdwingen met behulp van beleid voor voorwaardelijke toegang.

• Beheeraccounts buiten gebruik stellen die niet worden gebruikt.

Gebruik één identiteit in verschillende omgevingen en koppel één identiteit aan de gebruiker of principal. Consistentie van identiteiten in cloud- en on-premises omgevingen vermindert menselijke fouten en de resulterende beveiligingsrisico's. Teams in beide omgevingen die resources beheren, hebben een consistente, gezaghebbende bron nodig om te voldoen aan beveiligingsgaranties. Werk samen met uw centrale identiteitsteam om ervoor te zorgen dat identiteiten in hybride omgevingen worden gesynchroniseerd.

Risico: er is een risico dat is gekoppeld aan het synchroniseren van identiteiten met hoge bevoegdheden. Een aanvaller kan volledige controle krijgen over on-premises assets en dit kan leiden tot een geslaagde inbreuk op een cloudaccount. Evalueer uw synchronisatiestrategie door accounts te filteren die kunnen worden toegevoegd aan het kwetsbaarheid voor aanvallen.

Processen instellen voor het beheren van de identiteitslevenscyclus

Toegang tot identiteiten mag niet langer duren dan de resources waartoe de identiteiten toegang hebben. Zorg ervoor dat u een proces hebt voor het uitschakelen of verwijderen van identiteiten wanneer er wijzigingen zijn in de teamstructuur of softwareonderdelen.

Deze richtlijnen zijn van toepassing op broncodebeheer, gegevens, besturingsvlakken, workloadgebruikers, infrastructuur, hulpprogramma's, de bewaking van gegevens, logboeken, metrische gegevens en andere entiteiten.

Stel een identiteitsbeheerproces in om de levenscyclus van digitale identiteiten, gebruikers met hoge bevoegdheden, externe/gastgebruikers en workloadgebruikers te beheren. Implementeer toegangsbeoordelingen om ervoor te zorgen dat wanneer identiteiten de organisatie of het team verlaten, hun workloadmachtigingen worden verwijderd.

Geheimen op basis van niet-identiteit beveiligen

Toepassingsgeheimen zoals vooraf gedeelde sleutels moeten als kwetsbare punten in het systeem worden beschouwd. Als de provider of consument in twee richtingen wordt gecompromitteerd, kunnen er aanzienlijke beveiligingsrisico's worden geïntroduceerd. Deze sleutels kunnen ook lastig zijn omdat ze operationele processen introduceren.

Wanneer u dat kunt, vermijdt u het gebruik van geheimen en kunt u overwegen om verificatie op basis van identiteiten te gebruiken voor gebruikerstoegang tot de toepassing zelf, niet alleen voor de bijbehorende resources.

De volgende lijst bevat een overzicht van de richtlijnen. Zie Aanbevelingen voor toepassingsgeheimen voor meer informatie.

• Behandel deze geheimen als entiteiten die dynamisch kunnen worden opgehaald uit een geheim archief. Ze moeten niet in code worden vastgelegd in uw toepassingscode, IaC-scripts, implementatiepijplijnen of in een ander artefact.

• Zorg ervoor dat u geheimen kunt intrekken.

• Operationele procedures toepassen waarmee taken, zoals sleutelrotatie en vervaldatum, worden verwerkt.

Zie De rotatie van een geheim automatiseren voor resources met twee sets verificatiereferenties en zelfstudie: Frequentie van automatische rotatie van certificaten in Key Vault bijwerken voor informatie over rotatiebeleid.

Ontwikkelomgevingen veilig houden

Alle code- en scripts, pijplijnhulpprogramma's en broncodebeheersystemen moeten worden beschouwd als workloadassets. Toegang tot schrijfbewerkingen moet worden beveiligd met automatisering en peer review. Leestoegang tot broncode moet worden beperkt tot rollen op basis van noodzaak tot kennis. Codeopslagplaatsen moeten versiebeheer hebben en beoordelingen van beveiligingscode door collega's moeten een reguliere procedure zijn die is geïntegreerd met de ontwikkelingslevenscyclus. U moet een proces hebben dat resources regelmatig scant en de meest recente beveiligingsproblemen identificeert.

Gebruik workloadidentiteiten om toegang te verlenen tot resources vanuit implementatieomgevingen, zoals GitHub.

Een audittrail onderhouden

Eén aspect van identiteitsbeheer is ervoor te zorgen dat het systeem controleerbaar is. Controles controleren of er sprake is van een effectieve inbreukstrategieën. Als u een audittrail onderhoudt, kunt u het volgende doen:

• Controleer of de identiteit is geverifieerd met sterke verificatie. Elke actie moet traceerbaar zijn om repudiation-aanvallen te voorkomen.

• Detecteer zwakke of ontbrekende verificatieprotocollen en krijg inzicht in en inzichten over aanmeldingen van gebruikers en toepassingen.

• Evalueer de toegang van identiteiten naar de workload op basis van beveiligings- en nalevingsvereisten en overweeg risico's van gebruikersaccounts, apparaatstatus en andere criteria en beleidsregels die u instelt.

• Voortgang of afwijking van nalevingsvereisten bijhouden.

De meeste resources hebben toegang tot het gegevensvlak. U moet weten welke identiteiten toegang hebben tot resources en de acties die ze uitvoeren. U kunt deze informatie gebruiken voor beveiligingsdiagnose.

Zie Aanbevelingen voor beveiligingsbewaking en bedreigingsanalyse voor meer informatie.

Azure-facilitering

U wordt aangeraden altijd moderne verificatieprotocollen te gebruiken die rekening houden met alle beschikbare gegevenspunten en voorwaardelijke toegang gebruiken. Microsoft Entra ID biedt identiteits- en toegangsbeheer in Azure. Het omvat het beheervlak van Azure en is geïntegreerd met de gegevensvlakken van de meeste Azure-services. Microsoft Entra-id is de tenant die is gekoppeld aan het workloadabonnement. Het houdt identiteiten en hun toegestane machtigingen bij en beheert en vereenvoudigt het algehele beheer om het risico op toezicht of menselijke fouten te minimaliseren.

Deze mogelijkheden zijn systeemeigen geïntegreerd in dezelfde Microsoft Entra-identiteit en hetzelfde machtigingsmodel voor gebruikerssegmenten:

• Microsoft Entra-id. Werknemers en ondernemingsresources.

• Microsoft Entra Externe ID. Partners.

• Azure AD B2C. Klanten.

• Compatibiliteitslijst voor Microsoft Entra-federatie. Federatieoplossingen van derden.

U kunt Microsoft Entra ID gebruiken voor verificatie en autorisatie van aangepaste toepassingen via Microsoft Authentication Library (MSAL) of platformfuncties, zoals verificatie voor web-apps. Het omvat het beheervlak van Azure, de gegevensvlakken van de meeste Azure-services en integratiemogelijkheden voor uw toepassingen.

U kunt op de hoogte blijven door te gaan naar wat er nieuw is in Microsoft Entra ID.

Compromis: Microsoft Entra ID is een single point of failure, net als elke andere fundamentele service. Er is geen tijdelijke oplossing totdat de storing is opgelost door Microsoft. De uitgebreide functieset van Microsoft Entra weegt echter op tegen het risico van het gebruik van aangepaste oplossingen.

ondersteuning voor Azure open protocollen zoals OAuth2 en OpenID Connect. U wordt aangeraden deze standaardverificatie- en autorisatiemechanismen te gebruiken in plaats van uw eigen stromen te ontwerpen.

Azure RBAC

Azure RBAC vertegenwoordigt beveiligingsprinciplen in Microsoft Entra-id. Alle roltoewijzingen worden uitgevoerd via Azure RBAC. Profiteer van ingebouwde rollen die de meeste machtigingen bieden die u nodig hebt. Zie Ingebouwde rollen in Microsoft Entra voor meer informatie.

Hier volgen enkele gebruiksvoorbeelden:

• Door gebruikers toe te wijzen aan rollen, kunt u de toegang tot Azure-resources beheren. Zie Overzicht van op rollen gebaseerd toegangsbeheer in Microsoft Entra ID voor meer informatie.

• U kunt Privileged Identity Management gebruiken om op tijd gebaseerde en op goedkeuring gebaseerde rolactivering te bieden voor rollen die zijn gekoppeld aan identiteiten met hoge impact. Zie Wat is Privileged Identity Management? voor meer informatie.

Zie Best practices voor Azure RBAC voor meer informatie over RBAC.

Zie Wat is Azure ABAC? voor informatie over besturingselementen op basis van kenmerken.

Workload-identiteit

Microsoft Entra ID kan de identiteit van uw toepassing afhandelen. De service-principal die aan de toepassing is gekoppeld, kan het toegangsbereik dicteren.

Zie Wat zijn workloadidentiteiten? voor meer informatie.

De service-principal wordt ook geabstraheerd wanneer u een beheerde identiteit gebruikt. Het voordeel is dat Azure alle referenties voor de toepassing beheert.

Niet alle services ondersteunen beheerde identiteiten. Als u geen beheerde identiteiten kunt gebruiken, kunt u service-principals gebruiken. Het gebruik van service-principals verhoogt echter uw beheeroverhead. Zie Wat zijn beheerde identiteiten voor Azure-resources? voor meer informatie.

Resource-id

Het concept van beheerde identiteiten kan worden uitgebreid naar Azure-resources. Azure-resources kunnen beheerde identiteiten gebruiken om zichzelf te verifiëren bij andere services die ondersteuning bieden voor Microsoft Entra-verificatie. Zie Azure-services die beheerde identiteiten kunnen gebruiken voor toegang tot andere services voor meer informatie.

Beleid voor voorwaardelijke toegang

Voorwaardelijke toegang beschrijft uw beleid voor een toegangsbeslissing. Als u voorwaardelijke toegang wilt gebruiken, moet u de beperkingen begrijpen die vereist zijn voor de use-case. Configureer voorwaardelijke toegang van Microsoft Entra door een toegangsbeleid voor dat beleid in te stellen op basis van uw operationele behoeften.

Zie Voorwaardelijke toegang: Gebruikers, groepen en workloadidentiteiten voor meer informatie.

Toegangsbeheer voor groepen

In plaats van machtigingen te verlenen aan specifieke gebruikers, wijst u toegang toe aan groepen in Microsoft Entra-id. Als er geen groep bestaat, werkt u samen met uw identiteitsteam om er een te maken. Vervolgens kunt u groepsleden buiten Azure toevoegen en verwijderen en ervoor zorgen dat de machtigingen actueel zijn. U kunt de groep ook gebruiken voor andere doeleinden, zoals adressenlijsten.

Zie Toegangsbeheer beveiligen met behulp van groepen in Microsoft Entra ID voor meer informatie.

Detectie van bedreigingen

Microsoft Entra ID Protection kan u helpen bij het detecteren, onderzoeken en oplossen van identiteitsrisico's. Zie Wat is Identity Protection? voor meer informatie.

Detectie van bedreigingen kan de vorm aannemen van reageren op een waarschuwing van verdachte activiteiten of proactief zoeken naar afwijkende gebeurtenissen in activiteitenlogboeken. Met UEBA (User and Entity Behavior Analytics) in Microsoft Sentinel kunt u eenvoudig verdachte activiteiten detecteren. Zie Geavanceerde bedreigingen identificeren met UEBA voor meer informatie.

Hybride systemen

Synchroniseer in Azure geen accounts met Microsoft Entra ID met hoge bevoegdheden in uw bestaande Active Directory. Deze synchronisatie wordt geblokkeerd in de standaardconfiguratie van Microsoft Entra Connect Sync, dus u hoeft alleen te bevestigen dat u deze configuratie niet hebt aangepast.

Zie Microsoft Entra Connect Sync: Filtering configureren voor meer informatie over filteren in Microsoft Entra ID.

Identiteitslogboekregistratie

Schakel diagnostische instellingen in voor Azure-resources om informatie te verzenden die u als audittrail kunt gebruiken. De diagnostische informatie laat zien welke identiteiten toegang proberen te krijgen tot welke resources en het resultaat van deze pogingen. De verzamelde logboeken worden verzonden naar Azure Monitor.

Afweging: voor logboekregistratie worden kosten in rekening gebracht vanwege de gegevensopslag die wordt gebruikt voor het opslaan van de logboeken. Dit kan ook een invloed hebben op de prestaties, met name op de code en op logboekregistratieoplossingen die u aan de toepassing toevoegt.

Opmerking

In het volgende voorbeeld ziet u een identiteitsuitvoering. Verschillende typen identiteiten worden samen gebruikt om de vereiste toegangsniveaus te bieden.

Identiteitsonderdelen

• Door het systeem beheerde identiteiten. Microsoft Entra ID biedt toegang tot servicegegevensvlakken die geen gebruikers tegenkomen, zoals Azure Key Vault en gegevensarchieven. Deze identiteiten beheren ook de toegang via RBAC naar het Azure-beheervlak voor workloadonderdelen, implementatieagents en teamleden.

• Workloadidentiteiten. De toepassingsservices in het AKS-cluster (Azure Kubernetes Service) gebruiken workloadidentiteiten om zichzelf te verifiëren bij andere onderdelen in de oplossing.

• Beheerde identiteiten. Systeemonderdelen in de clientrol maken gebruik van door het systeem beheerde identiteiten, waaronder buildagents.

• Menselijke identiteiten. Verificatie van gebruikers en operatoren wordt gedelegeerd aan Microsoft Entra-id of Microsoft Entra-id (systeemeigen, B2B of B2C).

De beveiliging van vooraf gedeelde geheimen is essentieel voor elke toepassing. Azure Key Vault biedt een beveiligd opslagmechanisme voor deze geheimen, waaronder Redis en geheimen van derden.

Er wordt een rotatiemechanisme gebruikt om ervoor te zorgen dat geheimen niet worden aangetast. Tokens voor de implementatie van het Microsoft Identity Platform van OAuth 2 en OpenID Connect worden gebruikt om gebruikers te verifiëren.

Azure Policy wordt gebruikt om ervoor te zorgen dat identiteitsonderdelen zoals Key Vault RBAC gebruiken in plaats van toegangsbeleid. JIT en JEA bieden traditionele permanente machtigingen voor menselijke operators.

Toegangslogboeken zijn ingeschakeld voor alle onderdelen via Azure Diagnostics of via code voor codeonderdelen.

Verwante koppelingen

• Zelfstudie: Het rouleren van een geheim automatiseren voor resources met twee sets verificatiereferenties
• Zelfstudie: Frequentie van automatische rotatie van certificaten bijwerken in Key Vault
• Wat is er nieuw in Microsoft Entra ID?
• Ingebouwde Microsoft Entra-rollen
• Overzicht van op rollen gebaseerd toegangsbeheer in Microsoft Entra ID
• Wat zijn workloadidentiteiten?
• Wat zijn beheerde identiteiten voor Azure-resources?
• Voorwaardelijke toegang: gebruikers, groepen en workloadidentiteiten
• Microsoft Entra Connect Sync: filtering configureren

Controlelijst voor beveiliging

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor beveiliging