Enterpriseontwerp voor identiteit en toegang

In Azure-omgevingen van ondernemingen moet identiteits- en toegangsbeheer kunnen meegroeien met honderden abonnementen, duizenden gebruikers en tientallen teams, die allemaal verschillende behoeften hebben op het gebied van toegang tot resources. Een goed ontworpen identiteitsmodel voorkomt zowel te ruime toegangsrechten (gebruikers met te veel toegang) als te beperkte toegangsrechten (gebruikers die hun werk niet kunnen doen). De basis bestaat uit Microsoft Entra ID in combinatie met Azure RBAC en hulpprogramma's voor beheer, zoals Privileged Identity Management (PIM).

Azure Role-Based Access Control (RBAC) verleent toegang via drie onderdelen:

• Beveiligingsprincipal — wie (gebruiker, groep, serviceprincipal of beheerde identiteit)
• Roldefinitie — wat (een set toegestane acties, bijvoorbeeld 'Contributor')
• Bereik — waar (beheergroep, abonnement, resourcegroep of afzonderlijke resource)

Door deze drie elementen te combineren ontstaat een roltoewijzing. Rollen worden overgenomen in de hiërarchie: een rol die op het niveau van een beheergroep is toegewezen, geldt voor alle onderliggende abonnementen.

Azure biedt meer dan 100 ingebouwde rollen voor veelvoorkomende scenario's (Owner, Contributor, Reader en servicespecifieke rollen). Voor de meeste gebruiksscenario's binnen ondernemingen zijn ingebouwde rollen voldoende. Als je echter machtigingen nodig hebt die niet overeenkomen met een ingebouwde rol — bijvoorbeeld een rol waarmee je VM's kunt lezen maar niet kunt verwijderen — kun je een aangepaste rol maken met precies de benodigde machtigingen, volgens het principe van minimale bevoegdheden.

Wijs waar mogelijk rollen toe aan Entra ID-groepen in plaats van aan afzonderlijke gebruikers. Wanneer je een rol aan een groep toewijst, nemen alle leden die rol over. Toegang toevoegen of verwijderen is dan een kwestie van een gebruiker aan de groep toevoegen of uit de groep verwijderen, in plaats van roltoewijzingen op meerdere bereiken te wijzigen. Dit vermindert de administratieve overhead aanzienlijk en zorgt ervoor dat teamleden die dezelfde functie uitvoeren, consistente toegang hebben.

Privileged Identity Management (PIM) is een Entra ID-service die tijdelijke bevoorrechte toegang (JIT) tot Azure-resources en Entra ID-rollen biedt. In plaats van permanente Owner- of Global Administrator-toegang te hebben, komen gebruikers in aanmerking voor bevoorrechte rollen en moeten ze activering aanvragen wanneer ze verhoogde toegang nodig hebben. Voor activering kan MFA, een motivatie en goedkeuring door een aangewezen goedkeurder vereist zijn.

PIM biedt verschillende beveiligingsvoordelen voor bedrijfsomgevingen:

• Verkleind aanvalsoppervlak — geen permanente beheerdersaccounts die gecompromitteerd kunnen worden
• Controlespoor — elke activering wordt vastgelegd met tijdstempel, motivatie en goedkeurder
• Toegangsbeoordelingen — PIM ondersteunt periodieke beoordelingen waarbij managers bevestigen welke gebruikers in aanmerking moeten blijven komen
• Tijdsgebonden toegang — zelfs goedgekeurde toegang verloopt automatisch, zodat vergeten verhoogde machtigingen geen risico blijven vormen

Een goed ontworpen RBAC-model voor ondernemingen heeft doorgaans de volgende lagen:

• Niveau van de beheergroep — brede leestoegang voor beheerteams; beleidstoewijzingen
• Niveau van het abonnement — Contributor-toegang op teamniveau voor applicatieteams die één abonnement beheren
• Niveau van de resourcegroep — servicespecifieke rollen (bijvoorbeeld Storage Blob Contributor voor een toepassing die alleen toegang tot blobs nodig heeft)
• Niveau van de resource — alleen voor uitzonderlijke gevallen waarin fijnmazige controle nodig is

Applicaties en geautomatiseerde processen mogen geen gebruikersaccounts gebruiken om zich bij Azure te verifiëren. Gebruik in plaats daarvan:

• Service-principals — applicatieregistraties in Entra ID met een client-id en geheim of certificaat; gebruikt door CI/CD-pijplijnen en on-premises automatisering
• Beheerde identiteiten — automatisch beheerde referenties voor resources die in Azure worden gehost (VM's, App Service, AKS); er zijn geen geheimen die je hoeft te beheren of te vernieuwen

Wijs de minimaal vereiste RBAC-rollen toe aan service-principals en beheerde identiteiten.

Beleid voor voorwaardelijke toegang in Entra ID voegt context toe aan verificatiebeslissingen. Voor het beheer van Azure-resources kun je vereisen dat beheerderstoegang (Azure-portal, CLI) alleen is toegestaan vanaf:

• Compatibele apparaten (beheerd door Intune)
• Benoemde locaties (bedrijfsnetwerk of VPN)
• Na MFA (altijd afgedwongen voor bevoorrechte acties)

Door voorwaardelijke toegang te combineren met PIM creëer je een zeer sterke beveiligingspositie voor beheerderstoegang tot Azure.

Met Entra ID-toegangsbeoordelingen kunnen beheerders periodiek controleren of gebruikers de toegang die aan hen is verleend nog nodig hebben. Beoordelingen kunnen worden gedelegeerd aan resource-eigenaren of managers. Zij beantwoorden per gebruiker 'Ja, deze persoon heeft nog steeds toegang nodig' of 'Nee, verwijder deze toegang'. Toegangsbeoordelingen kunnen elk kwartaal worden gepland en het verwijderen van toegang die niet langer is goedgekeurd automatiseren, zodat toegangsuitbreiding in de loop van de tijd wordt voorkomen.

Elke onderneming moet ten minste twee accounts voor noodtoegang (break-glass-accounts) onderhouden — Global Administrator-accounts die niet worden beschermd door vereisten voor voorwaardelijke toegang of MFA (in plaats daarvan gebruiken ze hardwarematige FIDO2-sleutels). Deze accounts worden alleen gebruikt wanneer Entra ID- of MFA-systemen niet beschikbaar zijn en normale beheerdersaccounts niet toegankelijk zijn. Het gebruik van een account voor noodtoegang moet onmiddellijk beveiligingswaarschuwingen activeren en streng worden gecontroleerd.

In deze les heb je geleerd dat enterprise-RBAC gebruikmaakt van toewijzingen op basis van groepen op het bereik van beheergroepen, abonnementen en resourcegroepen; dat Privileged Identity Management just-in-time-toegang biedt om permanente beheerdersrollen te elimineren; en dat beheerde identiteiten en service-principals voor verificatie van applicaties moeten worden gebruikt in plaats van gebruikersaccounts. Gefeliciteerd — je hebt het onderdeel over enterprise-architectuur en governance van het AZ-900-traject voltooid!