Identiteits- en toegangsmodel¶
Deze pagina beschrijft de gedachte achter toegangsbeheer op het platform. Hoe je als afnemer toegang aanvraagt en activeert, staat bij Toegang, groepen en PIM. De exacte groepen van een spoke staan in de Spoke JSON-referentie.
Principes¶
- Maak het dagelijkse werk autonoom: een team hoort geen ticket nodig te hebben voor gewone taken.
- Rollen met hoge privileges op tenant- of platformniveau worden altijd beschermd door PIM en geautoriseerd door mensen van de klantorganisatie, niet door de managed-serviceprovider.
- Houd het model eenvoudig, om complexiteit in de implementatie te voorkomen.
- Platformrollen worden toegekend op management groups en overgeërfd door de subscriptions eronder. Workloadrollen worden toegekend op de subscription en overgeërfd door de resources erin.
- Rollen en PIM-toewijzingen gaan naar groepen, nooit naar individuele gebruikersaccounts die interactief inloggen.
Layers en soorten rollen¶
Rollen bestaan op drie lagen.
| Laag | Wat het beschrijft | Verantwoordelijk |
|---|---|---|
| Business | De rollen die aan een persoon hangen: functietitel, functie, afdeling, locatie | De organisatie (bijvoorbeeld HR richt zakelijke gebruikers in en beheert ze) |
| Workload | De rollen op het niveau van een workload, een bedrijfsoplossing die meerdere nauw verwante applicaties kan bevatten | Het platform levert voor elke workload een standaardset technische rollen. Extra rollen zijn mogelijk, maar het workload team deployt en configureert ze. |
| Applicatie | Rollen binnen één applicatie, meestal eigen aan die applicatie | Het workload team |
Rollen zijn daarnaast technisch of functioneel, omdat ze andere expertise vragen:
| Type | Focus | Voorbeelden |
|---|---|---|
| Technisch | De binnenkant van de workload of applicatie: ontwikkeling, deployment, onderhoud. Hoge privileges op de infrastructuur. | Resources deployen, configuratie wijzigen |
| Functioneel | De buitenkant: bedrijfsadministratie in de applicatie, zoals het beheren van zakelijke gebruikers of workflows. Geen infrastructuurprivileges. Wordt vaker gedelegeerd aan mensen in andere teams. | Applicatiegebruikers beheren |
Workloadrollen¶
Een typische workload heeft vier technische rollen. Elke rol wordt ondersteund door een Entra ID security group die de rechten in de Azure portal, Azure DevOps en andere services beheert.
| Rol | Betekenis |
|---|---|
| Owner | Is eigenaar van de workload en uiteindelijk verantwoordelijk voor alles erin |
| Approver | Keurt wijzigingen en verhoogde toegang tot productie goed, bijvoorbeeld PIM-aanvragen |
| Engineer | Verantwoordelijk voor de implementatie van de workload en houdt er toezicht op |
| Reader | Leestoegang, voor gasten en ondersteunende engineers of architecten |
De MCP spoke baseline maakt per spoke vier groepen aan: Owners, Contributors, Readers en Support, en stelt in of
elke rol permanent is of in PIM moet worden geactiveerd, met of zonder goedkeuring (zie
Toegang, groepen en PIM). Wie goedkeurt, wordt ingesteld in de PIM-instellingen van de
spoke-groepen. Een platform kan extra groepen toevoegen voor rollen op applicatieniveau.
Note
Ontwerp je zelf een rollenset bovenop de spoke-groepen, houd dan duidelijk wie de eigenaar van elke groep is: de eigenaar van de workloadgroep is eigenaar van de approver-, engineer- en reader-groepen.
Spoke-groepen en de spoke service principal¶
De vier groepen van een spoke hebben een vaste betekenis op de subscription:
| Groep | Rol op de subscription | Opmerkingen |
|---|---|---|
Owners |
Owner | Inclusief toegangsbeheer. De spoke service principal is permanent lid |
Contributors |
Contributor | Alles behalve het instellen van privileges |
Readers |
Reader | Alleen lezen |
Support |
Geen | Heeft zelf geen privileges. Hij bestaat zodat support-medewerkers van het platformteam via PIM bij de Owners-groep kunnen komen |
Voor Key Vault en storage krijgt elke groep permanente leestoegang tot het data plane, en Contributors en Owners kunnen daarnaast via PIM verhoogde rollen activeren. De spoke service principal is Owner op de subscription, Key Vault Administrator op de Key Vault en Storage Blob Data Owner op het storage account, en krijgt geen secret als federated credentials worden gebruikt. Details, en hoe je de rolmap overschrijft: Spoke canvas.
De deployment die dit allemaal aanmaakt, wordt begrensd door een administrative unit: hij kan alleen groepen in die unit beheren. Zo houdt de deployment-identiteit kleine privileges. Zie Wat de deployment-identiteit nodig heeft.
Toegang krijgen tot een workload¶
| Pad | Wanneer | Waarom |
|---|---|---|
| De aanvrager vraagt de workload owner, die de persoon aan de teamgroep toevoegt | Normaal | Toegang is beperkt tot één workload en geautoriseerd door de eigenaar ervan |
| Een platform engineer activeert een Reader-, Contributor- of Owner-rol op een management group | Alleen bij noodgevallen | Geeft toegang tot alle resources onder die management group. Minder gewenst. Altijd via PIM en met een reden. |
Platformrollen¶
Platformrollen gebruiken dezelfde principes met een bredere scope.
| Principe | Detail |
|---|---|
| Toegekend op management groups | De kernrollen van het platform worden op management groups ingesteld en overgeërfd |
| Altijd via PIM | Contributor en Owner op platformscope zijn nooit permanent |
| Een extern platformteam werkt als gast | De engineers van de managed-serviceprovider zijn meestal gasten in de klanttenant. Sommige ingebouwde policies markeren gastaccounts met schrijf- of ownerrechten; zie Governance. |
Microsoft Defender for Cloud¶
Autorisatie in Defender for Cloud volgt de Azure-rollen op de subscription:
| Actie | Security Reader | Security Admin | Contributor | Owner |
|---|---|---|---|---|
| Alerts en aanbevelingen bekijken | Ja | Ja | Ja | Ja |
| Securitypolicy bewerken en initiatives toewijzen | Nee | Ja | Nee | Ja |
| Defender-plannen in- of uitschakelen | Nee | Ja | Ja | Ja |
| Een aanbeveling toepassen (Fix) | Nee | Nee | Ja | Ja |
Dit komt overeen met de Microsoft-documentatie. Controleer het voordat je erop vertrouwt.
Break-glass-accounts¶
Je kunt jezelf buitensluiten uit de tenant als inloggen of de activering van een geprivilegieerde rol mislukt. Verklein dat risico met emergency access-accounts:
- Maak er minimaal twee aan. Ze zijn niet aan een persoon toegewezen.
- Gebruik ze alleen bij noodgevallen waarin de normale beheerdersaccounts niet kunnen worden gebruikt.
- Bewaar de credentials veilig (bijvoorbeeld in een vault en een fysieke kluis). Bepaal wie toegang heeft.
- Beschouw elke aanmelding met deze accounts als hoog risico: stel er een alert op in en monitor ze.
- Volg de actuele Microsoft-richtlijnen voor emergency access-accounts, inclusief hoe je met conditional access omgaat.
Alle rollen en accounts met privileges op tenantniveau zijn standaard hoog risico en moeten worden gemonitord als ze worden gebruikt.
Service principals¶
Spoke-deployments gebruiken een service principal per spoke. Zie Wat je krijgt en Service principal en credentials. Geef de voorkeur aan federated credentials boven secrets, en roteer secrets voordat ze verlopen (Operationele verantwoordelijkheden).