Aanbevelingen voor identiteits- en toegangsbeheer

Van toepassing op deze aanbeveling voor de controlelijst voor beveiliging van Azure Well-Architected Framework:

SE:05	Implementeer strikte, voorwaardelijke en controleerbare identiteits- en toegangsbeheer (IAM) voor alle workloadgebruikers, teamleden en systeemonderdelen. Beperk de toegang uitsluitend tot waar nodig. Gebruik moderne industriestandaarden voor alle verificatie- en autorisatie-implementaties. Beperk en controleer grondig 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 het oogpunt van technische controle 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 geleverd over wie ze zijn.

Definities 

Termen	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 zijn toegestaan op basis van opgegeven criteria.
IdP	Een id-provider, zoals Microsoft Entra-id.
Persona	Een functie of een titel met een reeks verantwoordelijkheden en acties.
Vooraf gedeelde sleutels	Een type geheim dat wordt gedeeld tussen een provider en een consument en wordt gebruikt via een veilig en overeengekomen mechanisme.
Resource-id	Een identiteit die is gedefinieerd voor cloudresources die wordt beheerd door het platform.
Rol	Een set machtigingen waarmee wordt gedefinieerd wat een gebruiker of groep kan doen.
Bereik	Verschillende niveaus van de organisatiehiërarchie waar 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 systeem-id 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 element dat een beveiligingsprincipal wordt genoemd. Een beveiligingsgroep is een voorbeeld van een beveiligingsprincipal. Deze hiërarchische relatie vereenvoudigt het onderhoud en verbetert de consistentie. Omdat identiteitskenmerken niet op het afzonderlijke niveau worden verwerkt, wordt de kans op fouten ook verkleind. In dit artikel is de term identiteit inclusief beveiligingsprincipals.

De rol van een id-provider

Een id-provider (IdP) is een in de cloud gehoste service die gebruikers opslaat en beheert als digitale identiteiten.

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 vaak verbeterd op basis van de nieuwste aanvalsvectoren door elke dag miljarden signalen 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 aanvragende identiteit is vereist om een vorm van verifieerbare identificatie te bieden. Bijvoorbeeld:

• 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 afgehandeld door uw IdP.

Autorisatie

Autorisatie is een proces dat acties toestaat of weigert die zijn aangevraagd door de geverifieerde identiteit. 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 uitvoeren. Uw strategie moet alle use cases omvatten die de stromen verwerken die de workload of de onderdelen ervan bereiken (externe toegang) en stromen die van de workload naar andere bronnen (inside-out-toegang) bereiken.

Elke use-case heeft waarschijnlijk een eigen set besturingselementen die u moet ontwerpen met een uitgangspunt voor schending van de veronderstelling. 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 identiteitstoegangsspoor registreren. Als u dit doet, kunt u de besturingselementen valideren en kunt u de logboeken gebruiken voor nalevingscontroles.

Alle identiteiten voor verificatie bepalen

• Toegang buiten binnen. 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 van buitenaf nodig. 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 binnenuit. Uw toepassing moet toegang hebben tot andere resources. Bijvoorbeeld het lezen van of schrijven naar het gegevensplatform, het ophalen van geheimen uit het geheime archief en het vastleggen van telemetrie naar bewakingsservices. Het kan zelfs nodig zijn om toegang te krijgen tot services van derden. Voor deze toegangsbehoeften 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 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 onderverdeeld op het type toegang dat ze nodig hebben:

• Toegang tot gegevensvlak. Acties die plaatsvinden in het gegevensvlak, veroorzaken gegevensoverdracht voor toegang binnen of buiten binnen. Een toepassing leest bijvoorbeeld gegevens uit een database en schrijft gegevens naar een database, haalt geheimen op of schrijft logboeken naar een bewakingssink. Op onderdeelniveau worden berekeningen die installatiekopieën naar of van een register ophalen of pushen, beschouwd als bewerkingen op 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 zijn doorgaans gericht op gegevensvlakbewerkingen, terwijl bewerkingen vaak toegang hebben tot zowel besturings- als gegevensvlakken. Noteer de operationele acties die kunnen worden uitgevoerd op de resource om autorisatiebehoeften te identificeren. Zie Bewerkingen van Azure-resourceproviders voor meer informatie over de toegestane acties voor elke resource.

Autorisatie op basis van rollen opgeven

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

Neem een workload-identiteit als voorbeeld. De toepassing moet gegevensvlaktoegang hebben tot de database, dus lees- en schrijfacties naar de gegevensresource moeten zijn toegestaan. Heeft de toepassing echter toegang tot het geheime archief nodig? Wat is de impact op het systeem op het gebied van vertrouwelijkheid, integriteit en beschikbaarheid als de identiteit van de workload wordt aangetast door een slechte actor?

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 de machtigingen van gebruikers zijn beperkt tot hun taakvereisten, is het gemakkelijker om verdacht of niet-geautoriseerd gedrag in het systeem te identificeren.

Stel vragen als deze:

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

Het beperken van het niveau van toegang dat gebruikers, toepassingen of services hebben tot Azure-resources, vermindert de 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 alleen-lezentoegang nodig tot beveiligingskenmerken voor alle technische omgevingen. Dat niveau is voldoende om risicofactoren te beoordelen, mogelijke risicobeperkingen te identificeren en te rapporteren over de risico's.

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 individuele gebruikers kunnen meerdere standaardrollen uitvoeren. Gebruik in dit geval 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 de intentie niet doorgeven aan nieuwe resources die vergelijkbaar zijn. Dit kan een complexe verouderde configuratie maken die moeilijk te onderhouden is en een negatieve invloed heeft op zowel de beveiliging als de betrouwbaarheid.

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

Een rol heeft ook een gekoppeld bereik. De rol kan worden uitgevoerd in de toegestane beheergroep, het abonnement, de resourcegroep of het resourcebereik, of in een ander aangepast bereik. Zelfs als de identiteit een beperkte set machtigingen heeft, is het riskant om het bereik te verbreden met resources die zich buiten de taakfunctie van de identiteit bevinden. 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 door IdP geleverde RBAC om te profiteren van functies waarmee u consistent toegangsbeheer kunt toepassen en het strikt kunt intrekken.

Ingebouwde rollen gebruiken. Ze zijn ontworpen voor de meeste gebruiksvoorbeelden. 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 vergroot en automatisering complexer, uitdagender en kwetsbaarder maakt. Deze factoren hebben allemaal een negatieve invloed op de beveiliging.

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

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

Keuzes maken voor voorwaardelijke toegang

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 preventieve maatregel als om de straal van de ontploffing onder controle te houden.

• JIT-benaderingen (Just-In-Time) bieden de vereiste bevoegdheden alleen 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 van toepassing. U kunt bijvoorbeeld ook het apparaat, het netwerk en de locatie waaruit de toegang afkomstig is, gebruiken om beleidsregels in te stellen.

Gebruik krachtige besturingselementen die onbevoegde toegang filteren, detecteren en blokkeren, waaronder parameters zoals gebruikersidentiteit en -locatie, apparaatstatus, workloadcontext, 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 fulltimemedewerkers verstrekt. Een 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 in staat zijn om die differentiatie te bieden, ingebouwde functies te 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.

Accounts voor kritieke impact

Beheeridentiteiten brengen enkele van de grootste beveiligingsrisico's met zich mee, omdat de taken die ze uitvoeren bevoegde toegang vereisen tot een brede set van deze systemen en toepassingen. Inbreuk of misbruik kan een nadelig effect hebben op uw bedrijf en de informatiesystemen. Beveiliging van beheer is een van de meest kritieke beveiligingsgebieden.

Als u bevoegde toegang wilt beschermen tegen bepaalde kwaadwillende personen, moet u een volledige en doordachte benadering volgen 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 te verhogen.

• Voorkom permanente of permanente toegang met behulp van de JIT-functies van uw IdP. Voor glasbreuksituaties 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 omgevingen en koppel één identiteit aan de gebruiker of principal. Consistentie van identiteiten in cloud- en on-premises omgevingen vermindert menselijke fouten en de daaruit voortvloeiende beveiligingsrisico's. Teams in beide omgevingen die resources beheren, hebben een consistente, gezaghebbende bron nodig om te voldoen aan beveiligingsgaranties. Werk met uw centrale identiteitsteam om ervoor te zorgen dat identiteiten in hybride omgevingen worden gesynchroniseerd.

Risico: Er is een risico verbonden 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 de 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 beschikt over een proces 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 worden beschouwd als kwetsbare punten in het systeem. In de tweerichtingscommunicatie kunnen, als de provider of consument wordt gecompromitteerd, aanzienlijke beveiligingsrisico's worden geïntroduceerd. Deze sleutels kunnen ook lastig zijn omdat ze operationele processen introduceren.

Vermijd het gebruik van geheimen wanneer dat mogelijk is en overweeg om verificatie op basis van identiteit te gebruiken voor gebruikerstoegang tot de toepassing zelf, niet alleen tot de resources.

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

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

• Zorg ervoor dat u de mogelijkheid hebt om geheimen in te trekken.

• Pas operationele procedures toe voor het afhandelen van taken zoals sleutelrotatie en vervaldatum.

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

Ontwikkelomgevingen veilig houden

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

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

Een audittrail onderhouden

Een aspect van identiteitsbeheer is ervoor zorgen dat het systeem controleerbaar is. Controles valideren of de strategieën voor inbreuk op het vermoeden effectief zijn. Het onderhouden van een audittrail helpt u bij het volgende:

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

• Zwakke of ontbrekende verificatieprotocollen detecteren en inzicht krijgen in en inzichten over aanmeldingen van gebruikers en toepassingen.

• Evalueer de toegang van identiteiten tot de workload op basis van beveiligings- en nalevingsvereisten en houd rekening met het risico van gebruikersaccounts, de 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 welke acties 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 traceert en beheert identiteiten en de toegestane machtigingen en vereenvoudigt het algehele beheer om het risico op toezicht of menselijke fouten te minimaliseren.

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

• Microsoft Entra-id. Werknemers en ondernemingsresources.

• Microsoft Entra Externe ID. Partners.

• Azure AD B2C. Klanten.

• Microsoft Entra lijst met federatiecompatibiliteit. 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 naar Wat is er nieuw in Microsoft Entra-id te gaan.

Tradeoff: Microsof Microsoft Entra ID is een single point of failure, net als elke andere basisservice. 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.

Azure ondersteunt 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 beveiligingsprincipals 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 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 rolactivering op basis van tijd en goedkeuring te bieden voor rollen die zijn gekoppeld aan identiteiten met een 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 meer informatie over besturingselementen op basis van kenmerken.

Workload-identiteit

Microsoft Entra id kan de identiteit van uw toepassing verwerken. 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 beheerde identiteiten niet 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 Microsoft Entra voorwaardelijke toegang door een toegangsbeleid in te stellen op basis van uw operationele behoeften.

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

Groepstoegangsbeheer

In plaats van machtigingen te verlenen aan specifieke gebruikers, kunt u toegang tot groepen toewijzen 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 voor andere doeleinden gebruiken, zoals adressenlijsten.

Zie Beveiligd toegangsbeheer met behulp van groepen in Microsoft Entra-id voor meer informatie.

Detectie van bedreigingen

Microsoft Entra ID Protection kunt 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 hebben van reageren op een waarschuwing van verdachte activiteiten of proactief zoeken naar afwijkende gebeurtenissen in activiteitenlogboeken. UEBA (User and Entity Behavior Analytics) in Microsoft Sentinel maakt het eenvoudig om verdachte activiteiten te 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 is geblokkeerd in de standaardconfiguratie Microsoft Entra Connect Sync, dus u hoeft alleen te bevestigen dat u deze configuratie niet hebt aangepast.

Zie voor meer informatie over het filteren in Microsoft Entra-id Microsoft Entra Connect Sync: Filtering configureren.

Identiteitslogboekregistratie

Schakel diagnostische instellingen in op 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 wat het resultaat van die pogingen is. De verzamelde logboeken worden verzonden naar Azure Monitor.

Afweging: logboekregistratie brengt kosten met zich mee vanwege de gegevensopslag die wordt gebruikt voor het opslaan van de logboeken. Dit kan ook gevolgen hebben voor de prestaties, met name voor de code en logboekregistratieoplossingen die u aan de toepassing toevoegt.

Voorbeeld

In het volgende voorbeeld ziet u een identiteits-implementatie. 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 niet worden geconfronteerd met gebruikers, zoals Azure Key Vault en gegevensarchieven. Deze identiteiten beheren ook de toegang, via RBAC, tot het Azure-beheervlak voor workloadonderdelen, implementatieagents en teamleden.

• Workload-identiteiten. 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. Gebruikers- en operatorverificatie 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 veilig 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 Microsoft identity platform implementatie 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 worden ingeschakeld voor alle onderdelen via Azure Diagnostics of via code voor codeonderdelen.

Verwante koppelingen

• Zelfstudie: De rotatie 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 rollen Microsoft Entra
• 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: filteren configureren

Controlelijst voor beveiliging

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor beveiliging