Identiteits- en toegangsbeheer voor landingszone

Nadat u uw identiteitsarchitectuur hebt geïdentificeerd, moet u de autorisatie en toegang voor resources in toepassings- en platformlandingszones beheren. Overweeg welke resources elke geverifieerde principal toegang heeft tot en toegang nodig heeft tot en hoe u het risico van onbevoegde toegang tot uw resources kunt beperken. Zie Ontwerp van identiteitsarchitectuur voor aanbevelingen voor identiteitsarchitectuur.

Overzicht

Het ontwerpdomein voor identiteits- en toegangsbeheer biedt richtlijnen om u te helpen bij het implementeren van het enterprisetoegangsmodel in Azure en bij het implementeren en beveiligen van beheervlakken. Wanneer u het ontwerpprincipe van democratisering van abonnementen opneemt, kan uw applicatieteam hun eigen werklasten beheren binnen de beleidsrichtlijnen die door het platformteam worden ingesteld. Deze aanpak volgt ook het principe van governance gebaseerd op beleid.

Het platformteam is verantwoordelijk voor het inrichten van nieuwe landingszones of abonnementen voor toepassingen. Wanneer ze een landingszone inrichten voor een toepassingseigenaar, moet het platformteam deze configureren met de juiste toegangsbeheer, zodat de eigenaar van de toepassing zijn eigen resources kan beheren. De eigenaar van de toepassing moet gebruikers en groepen kunnen maken en beheren binnen Microsoft Entra ID en rollen toewijzen aan deze gebruikers en groepen. De eigenaar van de toepassing kan vervolgens de toegang tot hun eigen resources beheren en zo nodig de toegang tot andere gebruikers en groepen delegeren. De landingszone moet ook een optionele netwerkverbinding hebben met Active Directory-domein Services (AD DS) of Microsoft Entra Domain Services in het Microsoft Identity Platform-abonnement, afhankelijk van de vereisten van de toepassing.

Op rollen gebaseerd toegangsbeheer van Azure (RBAC) gebruiken om beheerderstoegang tot Azure-resources te beheren. Overweeg of gebruikers machtigingen nodig hebben voor een beperkt bereik, zoals een beheerder voor één toepassing of een breed bereik, zoals een netwerkbeheerder voor meerdere toepassingsworkloads. In beide gevallen volgt u het principe van just-enough access (JEA) en zorgt u ervoor dat de gebruiker alleen de rollen heeft die vereist zijn voor hun normale activiteiten. Gebruik waar nodig aangepaste rollen en Microsoft Entra Privileged Identity Management (PIM) om Just-In-Time-toegang (JIT) af te dwingen, zodat beheerders alleen bevoorrechte rollen hebben wanneer ze actief vereist zijn. Hoewel het platformteam verantwoordelijk is voor de basis voor identiteits- en toegangsbeheer, zijn zowel platform- als toepassingsteams consumenten van de service en moeten ze dezelfde principes volgen.

Identiteits- en toegangsbeheer is belangrijk voor een succesvolle scheiding van de ene landingszone van een andere en de isolatie van workloads binnen een organisatie. Het is een kritiek ontwerpgebied voor zowel platform- als toepassingslandingszones.

Als uw organisatie een abonnementsdistributieproces gebruikt, kunt u veel van de toegangs- en identiteitsconfiguraties voor toepassingslandingszones automatiseren. Implementeer abonnementsautomaat om het maken van landingszones te standaardiseren en zodat toepassingsteams hun eigen resources kunnen beheren.

Ontwerpoverwegingen

Sommige organisaties delen services tussen meerdere toepassingen. Er kan bijvoorbeeld een gecentraliseerde integratieservice zijn die wordt gebruikt door verschillende onafhankelijke toepassingen. Houd in dat scenario rekening met welke services centraal worden beheerd en welke worden gedevoluleerd aan toepassingsteams en begrijp waar beveiligingsgrenzen moeten worden afgedwongen. Het geven van beheerderstoegang van toepassingsteams tot de gedeelde service kan nuttig zijn voor de productiviteit van ontwikkelaars, maar biedt mogelijk meer toegang dan vereist is.

Het beheren van toepassingsresources die geen grensoverschrijdende beveiliging overschrijden, kan worden gedelegeerd aan toepassingsteams. Overweeg ook andere aspecten te delegeren die nodig zijn voor het handhaven van beveiliging en naleving. Door gebruikers resources in een veilig beheerde omgeving te laten inrichten, kunnen organisaties profiteren van de flexibele aard van de cloud en schending van kritieke beveiligings- of governancegrenzen voorkomen.

RBAC

Belangrijk

Klassieke resources en klassieke beheerders zijn op 31 augustus 2024 buiten gebruik gesteld. Verwijder overbodige medebeheerders en gebruik Azure RBAC voor gedetailleerd toegangsbeheer.

Inzicht in het verschil tussen Microsoft Entra ID-rollen en Azure RBAC-rollen.

• Microsoft Entra ID-rollen beheren de beheerdersbevoegdheden voor services voor de hele tenant, zoals Microsoft Entra-id en andere Microsoft-services, waaronder Microsoft Teams, Microsoft Exchange Online en Microsoft Intune.

• Azure RBAC-rollen bepalen de administratieve rechten voor Azure-resources, zoals virtuele machines, abonnementen en resourcegroepen.

• De rollen Azure RBAC-eigenaar en Beheerders van gebruikerstoegang kunnen de roltoewijzingen in Azure-resources wijzigen. Standaard is de rol Globale beheerder van Microsoft Entra niet gemachtigd om de toegang tot Azure-resources te beheren. Deze moet expliciet worden ingeschakeld. Voor meer informatie, zie Verhoog de toegang om alle Azure-abonnementen en beheergroepen te beheren.

Belangrijk

Microsoft raadt u aan rollen te gebruiken met de minste machtigingen. Dit helpt de beveiliging voor uw organisatie te verbeteren. Globale beheerder is een zeer bevoorrechte rol die moet worden beperkt tot scenario's voor noodgevallen wanneer u geen bestaande rol kunt gebruiken.

In het volgende diagram ziet u de relatie tussen Microsoft Entra ID-rollen en Azure RBAC-rollen:

Diagram met de relatie tussen Microsoft Entra ID en Azure RBAC-rollen.

• U kunt rollentoewijzingsgroepen maken en Microsoft Entra-rollen toewijzen aan de groepen als u de isAssignableToRole eigenschap instelt op true. Alleen groepen met deze eigenschappenset zijn beveiligd. De enige rollen die het lidmaatschap van een groep kunnen wijzigen, zijn globale beheerders, beheerders met bevoorrechte rollen of de eigenaar van de groep.

• Alleen sommige rollen kunnen het wachtwoord of de instellingen voor meervoudige verificatie (MFA) opnieuw instellen voor een andere beheerder. Deze beperking voorkomt dat onbevoegde beheerders de referenties van een account met hogere bevoegdheden opnieuw instellen om meer machtigingen te krijgen.

• Als de ingebouwde rollen van Azure niet voldoen aan de specifieke behoeften van uw organisatie, kunt u uw eigen aangepaste rollen maken. Net als ingebouwde rollen kunt u aangepaste rollen toewijzen aan gebruikers, groepen en service-principals op tenant-, beheergroep-, abonnements- en resourcegroepbereiken. Probeer waar mogelijk ingebouwde Azure-rollen te gebruiken en maak alleen aangepaste rollen wanneer dat nodig is.

• Bij het ontwerpen van uw strategie voor toegangsbeheer, hoort u op de hoogte te zijn van de servicelimieten voor rollen, roltoewijzingen en aangepaste rollen.

• Sommige Azure RBAC-rollen ondersteunen kenmerken, zoals op kenmerken gebaseerd toegangsbeheer (ABAC), of roltoewijzingsvoorwaarden. Wanneer u voorwaarden gebruikt, kunnen beheerders dynamisch rollen toewijzen op basis van de kenmerken van de resource. U kunt bijvoorbeeld de rol Inzender voor opslagblobgegevens toewijzen, maar alleen voor blobs met een specifieke indextag in plaats van alle blobs in een container.

• U kunt ingebouwde en aangepaste RBAC-rollen gebruiken met Microsoft.Authorization/roleAssignments/write of Microsoft.Authorization/roleAssignments/delete machtigingen voor het maken, verwijderen en bijwerken van roltoewijzingen. Iedereen met deze rol kan bepalen wie schrijf-, lees- en verwijdermachtigingen heeft voor elke resource in het toewijzingsbereik. Teamleden van platform- of toepassingslandingszones moeten overwegen hoe u bevoorrechte rollen kunt delegeren aan andere gebruikers en groepen om hen de benodigde autonomie te verlenen. Om ervoor te zorgen dat de toegangsprincipes met minimale bevoegdheden worden nageleefd, kunnen ze voorwaarden gebruiken om gebruikers te delegeren.

Ontwerpaanaanvelingen

Algemene aanbevelingen

• Dwing Microsoft Entra multifactor-authenticatie (MFA) af voor gebruikers die rechten hebben op de Azure-omgeving, waaronder het platformabonnement, het toepassingsabonnement en de Microsoft Entra-ID-huurder. Veel nalevingsframeworks vereisen de handhaving van multifactorauthenticatie. MFA helpt bij het verminderen van het risico op diefstal van referenties en onbevoegde toegang. Als u onbevoegde toegang tot gevoelige informatie wilt voorkomen, moet u ervoor zorgen dat u gebruikers met lezerrollen in MFA-beleid opneemt.

Belangrijk

Gebruik phishingbestendige MFA om uw gebruikers te beschermen tegen phishingaanvallen. Traditionele MFA-methoden zoals sms, e-mail en pushmeldingen zijn kwetsbaar voor sociale engineering, man-in-the-middle tactieken en gebruikersmoeheid. Phishing-bestendige MFA elimineert de meest voorkomende inbreukvectoren en vermindert het risico op aanvallen op basis van referenties.

• Gebruik Microsoft Entra Conditional Access beleid voor gebruikers met rechten voor de Azure-omgeving. Voorwaardelijke toegang is een andere functie waarmee een beheerde Azure-omgeving wordt beschermd tegen onbevoegde toegang. Toepassings- en platformbeheerders moeten beleidsregels voor voorwaardelijke toegang hebben die het risicoprofiel van hun rol weerspiegelen. U kunt bijvoorbeeld vereisten hebben om beheeractiviteiten alleen uit te voeren vanaf specifieke locaties of specifieke werkstations. Of de aanmeldingsrisicotolerantie voor gebruikers met beheerderstoegang tot Azure-resources is mogelijk lager dan voor standaard Microsoft Entra ID-gebruikers.

• Schakel Microsoft Defender for Identity in om gebruikersidentiteiten te beveiligen en gebruikersreferenties te beveiligen. Defender for Identity maakt deel uit van Microsoft Defender XDR. U kunt Defender for Identity gebruiken om verdachte gebruikersactiviteiten te identificeren en tijdlijnen voor incidenten op te halen. U kunt deze ook gebruiken met voorwaardelijke toegang om verificatiepogingen met een hoog risico te weigeren. Implementeer Defender for Identity-sensoren op on-premises domeincontrollers en domeincontrollers in het identiteitsabonnement van Azure.

• Gebruik Microsoft Sentinel om dreigingsinformatie en onderzoeksfuncties te bieden. Sentinel maakt gebruik van logboeken van Azure Monitor-logboeken, Microsoft Entra-id, Microsoft 365 en andere services om proactieve detectie, onderzoek en reactie van bedreigingen te bieden.

• Beheertoegang scheiden van niet-beheerderstoegang, dagelijkse toegang, zoals surfen op internet en toegang tot e-mail. Web en e-mail zijn veelvoorkomende aanvalsvectoren. Wanneer een gebruikersaccount wordt aangetast, is het minder waarschijnlijk dat er sprake is van een beveiligingsschending als het account niet wordt gebruikt voor beheerderstoegang.

  • Gebruik aparte, alleen-cloudaccounts voor bevoorrechte rollen. Gebruik niet hetzelfde account voor dagelijks gebruik dat u doet voor bevoegd beheer. Bevoorrechte Microsoft Entra ID en Azure RBAC-rollen zijn gemarkeerd als PRIVILEGED in de Azure-portal en in de documentatie.

  • Voor niet-privileged functierollen die Azure-toepassingsbronnen kunnen beheren, kunt u overwegen of u afzonderlijke beheerdersaccounts nodig hebt of gebruik Microsoft Entra PIM om de beheertoegang te controleren. PIM zorgt ervoor dat het account alleen de vereiste machtigingen heeft wanneer dat nodig is en dat de machtigingen worden verwijderd wanneer de taak is voltooid (ook wel Just-In-Time-toegang genoemd).

• Als u roltoewijzingen beter beheerbaar wilt maken, wijst u geen rollen rechtstreeks toe aan gebruikers. Wijs in plaats daarvan rollen toe aan groepen om het aantal roltoewijzingen te minimaliseren, wat een limiet heeft voor elk abonnement.

  • Gebruik Microsoft Entra PIM voor groepen om just-in-time beheer toegang controles toe te passen op geprivilegieerde gebruikers. Overweeg om groepslidmaatschap te beheren met rechtenbeheer. U kunt de functie rechtenbeheer gebruiken om goedkeurings- en controlewerkstromen toe te voegen aan bewerkingen voor groepslidmaatschappen en ervoor te zorgen dat leden van de beheergroep niet onnodig worden toegevoegd of verwijderd.

  • Wanneer u toegang verleent tot resources, gebruik dan uitsluitend Microsoft Entra-groepen voor Azure-besturingsvlakken. Zowel entra-only gebruikers als groepen, en gebruikers die vanuit on-premises worden gesynchroniseerd met Microsoft Entra Connect, kunnen worden toegevoegd aan een entra-only-groep. Voeg on-premises groepen toe aan de Microsoft Entra-only-groep als er al een groepsbeheersysteem aanwezig is. Door alleen Entra-groepen te gebruiken, kunt u het cloudbesturingsvlak beschermen tegen onbevoegde aanpassingen van on-premises adreslijstservices. Microsoft Entra-only wordt ook wel alleen cloud genoemd.

• Maak accounts voor noodtoegang, oftewel breekglasaccounts, om te voorkomen dat uw Microsoft Entra ID-organisatie per ongeluk wordt vergrendeld. Accounts voor toegang tot noodgevallen zijn zeer bevoegd en worden alleen toegewezen aan specifieke personen. Sla de referenties voor de accounts veilig op, bewaak het gebruik ervan en test ze regelmatig om ervoor te zorgen dat u ze kunt gebruiken als er een noodgeval is.

  Zie Beveiligingstoegangsprocedures voor beheerders in Microsoft Entra ID voor meer informatie.

Aanbevelingen voor Microsoft Entra-id

• Integreer Microsoft Entra ID met Azure Monitor, zodat je je aanmeldingsactiviteit en het auditspoor met wijzigingen binnen je tenant kunt analyseren. Configureer een diagnostische instelling voor het verzenden van aanmeldingslogboeken en auditlogboeken naar de platform centrale Werkruimte voor Azure Monitor-logboeken in het beheerabonnement.

• Gebruik de functie rechtenbeheer van Microsoft Entra ID-governance om toegangspakketten te maken die groepslidmaatschap beheren via automatische goedkeuringsprocessen en regelmatige toegangsbeoordelingen voor bevoegde groepsleden.

• Gebruik Microsoft Entra ingebouwde rollen om de volgende identiteitsinstellingen op tenant-niveau te beheren:

  Rol	Beschrijving	Notitie
  Globale beheerder	Beheert alle aspecten van Microsoft Entra ID en Microsoft-services die gebruikmaken van Microsoft Entra-identiteiten.	Wijs niet meer dan vijf personen toe aan deze rol.
  Hybrid Identity-beheerder	Beheert cloudinrichting van Active Directory naar Microsoft Entra ID en beheert ook Microsoft Entra Connect, Microsoft Entra pass-through-verificatie, Microsoft Entra-wachtwoordhashsynchronisatie, naadloze eenmalige aanmelding (SSO) en federatie-instellingen.
  Beveiligingsbeheer	Leest beveiligingsgegevens en -rapporten en beheert configuraties in Microsoft Entra-id en Microsoft 365.
  Toepassingsbeheerder	Hiermee maakt en beheert u alle aspecten van app-registraties en zakelijke apps.	U kunt geen tenant-brede beheerstoestemming verlenen.

• Wijs geen rol met hogere bevoegdheden toe aan een taak die een rol met lagere bevoegdheden kan uitvoeren. Wijs bijvoorbeeld de rol Gebruikersbeheerder toe om gebruikers te beheren, niet de rol globale beheerder. Voor meer informatie, zie de ingebouwde rollenmachtigingen van Microsoft Entra.

• Gebruik beheereenheden om een set beheerders te beperken, zodat ze alleen specifieke objecten in uw tenant kunnen beheren. U kunt beheereenheden gebruiken om het beheer van een subset van de map te delegeren. U kunt bijvoorbeeld het beheer van een servicedesk delegeren aan één bedrijfseenheid binnen een bredere organisatie, zodat de servicedesk alleen gebruikers in die bedrijfseenheid kan beheren.

  Beheereenheden kunnen ook helpen bij het elimineren van de noodzaak van afzonderlijke Microsoft Entra ID-tenants als een beveiligingsgrens, waarbij afzonderlijke teams het Microsoft 365-platform en het Azure-platform in dezelfde organisatie beheren. U kunt bijvoorbeeld beheereenheden gebruiken om het beheer van Azure-toepassingsbeveiligingsprinciplen te delegeren aan het toepassingsteam zonder bevoegdheden toe te kennen aan de hele Microsoft Entra ID-tenant.

• Gebruik beperkte beheereenheden voor administratief beheer om verdere bescherming te bieden. Voorkom dat iemand anders dan een specifieke set beheerders die u aanwijst, specifieke objecten wijzigen. Uw scheiding van takenbeleid vereist bijvoorbeeld dat u deze functie gebruikt om te voorkomen dat iemand, inclusief gebruikers met de rol van Gebruikersbeheerder, een specifiek gebruikersaccount wijzigt. Deze beperking is handig voor serviceaccounts die toepassingen gebruiken en die zelfs beheerders niet mogen wijzigen. U kunt ook escalatie van bevoegdheden voorkomen, bijvoorbeeld als iemand een gebruikersaccount of groep wijzigt met bevoegdheden voor platform- of landingszonebeheer.

Aanbevelingen voor Azure RBAC

• Ter vereenvoudiging van het beheer en het verminderen van het risico op onjuiste configuratie, kunt u rollen en roltoewijzingen standaardiseren in alle landingszones van toepassingen. Als u bijvoorbeeld een rol hebt waarmee gebruikers virtuele machines kunnen beheren, gebruikt u dezelfde rol in alle landingszones van toepassingen. Deze aanpak vereenvoudigt ook het verplaatsen van resources tussen landingszones.

• Indien mogelijk, gebruik Azure RBAC om de toegang tot resources in het gegevensvlak te beheren. Voorbeelden van eindpunten voor gegevensvlakken zijn Azure Key Vault, een opslagaccount of een SQL-database. Beheerders met toegang tot het besturingsvlak voor het beheren van resources vereisen niet noodzakelijkerwijs toegang tot het gegevensvlak en het scheiden van machtigingen voor gegevens en besturingsvlakken om onbevoegde toegang tot gegevens te voorkomen.

• Zorg ervoor dat Werkruimten in Azure Monitor-logboeken zijn geconfigureerd met het juiste machtigingsmodel. Wanneer u een gecentraliseerde werkruimte voor Azure Monitor-logboeken gebruikt, gebruik resourcepermissies om ervoor te zorgen dat applicatieteams toegang hebben tot hun eigen logboeken, maar niet tot logboeken van andere teams.

Ingebouwde rollen

• Overweeg of ingebouwde rollen geschikt zijn voor uw vereisten. In veel gevallen kunt u meerdere ingebouwde rollen toewijzen aan een beveiligingsgroep om de juiste toegang voor een gebruiker te bieden. Maar soms kunt u geen ingebouwde rollen gebruiken en ook voldoen aan toegang met minimale bevoegdheden, omdat de rollen machtigingen kunnen bevatten die groter zijn dan wat uw gebruikers nodig hebben. Voor gedetailleerdere controle kunt u een aangepaste rol maken die overeenkomt met de specifieke machtigingen die nodig zijn om een taakfunctie uit te voeren. Voor meer informatie, zie Voorzien in rolgebaseerde autorisatie.

• Veel ingebouwde Azure-rollen bieden vooraf gedefinieerde roltoewijzingen op platform- en resourceniveau. Wanneer u verschillende roltoewijzingen combineert, moet u rekening houden met de algehele effecten.

• Nieuwe roldefinities worden regelmatig toegevoegd aan Entra-id. Controleer regelmatig wat er nieuw is in Microsoft Entra RBAC om te bepalen of nieuwe roldefinities u helpen de benodigde toegangsbeheer te bereiken.

• De referentiearchitectuur van de Azure-landingszone bevat verschillende aangepaste rollen voor algemene beheerfuncties. U kunt deze rollen naast ingebouwde Azure-rollen gebruiken. In de volgende tabel worden de aangepaste beheerdersrollen of gebieden voor de referentiearchitectuur van de Azure-landingszone beschreven:

  Beheerrol of -gebied	Beschrijving	Acties	Niet-acties
  Azure-platformeigenaar (zoals de ingebouwde rol Eigenaar)	Beheert de levenscyclus van beheergroepen en abonnementen	*
  Abonnementseigenaar	Gedelegeerde rol voor de eigenaar van het abonnement	*	Microsoft.Authorization/*/write, , Microsoft.Network/vpnGateways/* Microsoft.Network/expressRouteCircuits/*, Microsoft.Network/expressRouteCircuits/*, Microsoft.Network/vpnSites/*
  Toepassingseigenaar (DevOps, app-bewerkingen)	Bijdrager-rol voor het applicatie- of operationsteam op abonnementsniveau	*	Microsoft.Authorization/*/write, , Microsoft.Network/publicIPAddresses/write Microsoft.Network/virtualNetworks/write, Microsoft.KeyVault/locations/deletedVaults/purge/action
  Netwerkbeheer (NetOps)	Beheert platformbrede wereldwijde connectiviteit, zoals virtuele netwerken, UDR's, NSG's, NVA's, VPN's, Azure ExpressRoute en andere	Microsoft.Network/virtualNetworks/write, Microsoft.Network/expressRouteCircuits/*, Microsoft.Network/expressRouteCircuits/*, Microsoft.Support/*
  Beveiligingsbewerkingen (SecOps)	De rol van Beveiligingsbeheerder met een horizontaal overzicht over de hele Azure-omgeving en het Key Vault-verwijderbeleid.	Microsoft.Network/expressRouteCircuits/*, Microsoft.Network/expressRouteCircuits/*, Microsoft.Network/virtualNetworks/write, Microsoft.Network/expressRouteCircuits/*, Microsoft.Network/expressRouteCircuits/*, Microsoft.Network/expressRouteCircuits/*, Microsoft.Network/expressRouteCircuits/*, Microsoft.Network/expressRouteCircuits/*, Microsoft.Network/virtualNetworks/write, Microsoft.Network/virtualNetworks/write, Microsoft.Network/virtualNetworks/write, Microsoft.Support/*

  Deze rollen hebben mogelijk extra rechten nodig, afhankelijk van het verantwoordelijkheidsmodel. In sommige organisaties hoeft een NetOps-rol bijvoorbeeld alleen globale connectiviteit te beheren en te configureren. In organisaties die een meer gecentraliseerde benadering nodig hebben, kunt u de NetOps rol verrijken met meer toegestane acties, zoals het tot stand brengen van verbindingen tussen hubs en hun spokes.

Roltoewijzingen en -groepen

• Wanneer het platformteam een landingszone voor toepassingen in richt, moeten ze ervoor zorgen dat alle vereiste identiteits- en toegangsbeheerobjecten worden gemaakt, zoals beveiligingsgroepen, standaardroltoewijzingen en door de gebruiker toegewezen beheerde identiteiten.

• Maak roltoewijzingen voor landingszones op het niveau van het abonnement of de resourcegroep. Azure Policy-toewijzingen vinden plaats op het niveau van de beheergroep, dus u moet de roltoewijzingen voor landingszones toewijzen op een lager niveau van bereik. Gebruik deze methode om ervoor te zorgen dat beheerders van landingszones volledige autonomie hebben over hun resources, maar de Azure Policy-toewijzingen die van toepassing zijn op hun landingszone, niet kunnen wijzigen.

• Elke toepassingslandingszone moet eigen groepen en roltoewijzingen hebben. Maak geen algemene groepen en wijs ze toe aan meerdere landingszones. Deze aanpak kan leiden tot onjuiste configuratie en beveiligingsschendingen en het is moeilijk om op schaal te beheren. Als één gebruiker toegang nodig heeft tot meerdere landingszones, wijst u deze toe aan de juiste groepen in elke landingszone. Id-beheer gebruiken om hun groepslidmaatschap te beheren.

• Rollen toewijzen aan groepen, niet aan gebruikers. Deze aanpak helpt ervoor te zorgen dat gebruikers over de juiste machtigingen beschikken wanneer ze lid worden van uw organisatie of uw organisatie verlaten. Het helpt ook ervoor te zorgen dat gebruikers over de juiste machtigingen beschikken wanneer ze schakelen tussen teams. Als een gebruiker bijvoorbeeld overstapt van het netwerkteam naar het beveiligingsteam, moet u deze verwijderen uit de netwerkgroep en deze toevoegen aan de beveiligingsgroep. Als u een rol rechtstreeks aan een gebruiker toewijst, behouden ze de rol na het overstappen naar een ander team. Gebruik ID-beheer om groepslidmaatschap te beheren in plaats van groepsleden handmatig toe te voegen en te verwijderen.

• Behoud afzonderlijke beveiligingsconfiguraties voor verschillende omgevingen van dezelfde toepassing, zoals dev/test en productie. Maak afzonderlijke groepen en roltoewijzingen voor elke omgeving. Deel geen beheerde identiteiten of service-principals in omgevingen. Behandel elke omgeving als een afzonderlijke landingszone. Deze aanpak helpt bij het garanderen van isolatie tussen dev/test en productie, en standaardiseert het proces voor het verplaatsen van toepassingsimplementaties tussen omgevingen. Als voor dezelfde persoon toegang tot verschillende landingszones is vereist, moet u deze toewijzen aan de juiste groepen in elke landingszone.

• Overweeg of platformbeheerders machtigingen nodig hebben voor landingszones van toepassingen. Als dat het geval is, gebruikt u Microsoft Entra PIM om de toegang tot deze resources te beheren en wijst u de vereiste machtigingen met minimale bevoegdheden toe. Een platformbeheerder kan bijvoorbeeld toegang tot een specifieke landingszone van een toepassing vereisen om een probleem op te lossen, maar mag geen routinetoegang hebben tot de toepassingsgegevens of code. In dit geval kan de platformbeheerder toegang tot de toepassing aanvragen. Een beheerder van een bevoorrechte rol keurt de aanvraag goed en de platformbeheerder krijgt de vereiste machtigingen voor de opgegeven periode. Deze aanpak helpt bij het afdwingen van scheiding van taken en beschermt landingszones van toepassingen tegen onbedoelde of schadelijke onjuiste configuratie.

• Wanneer u beheerdersverantwoordelijkheid delegeert aan anderen, zoals toepassingsteams, kunt u overwegen of ze de volledige set bevoegdheden of alleen een subset vereisen. Volg het principe van minimale bevoegdheden (PoLP). U kunt bijvoorbeeld de rol Beheerder voor gebruikerstoegang of RBAC-beheerder toewijzen aan een gebruiker die de toegang tot Azure-resources moet beheren, maar de resources zelf niet hoeft te beheren. Als u de identiteiten, identiteitstypen en rollen wilt beperken waaraan gebruikers Azure RBAC-toewijzingen kunnen delegeren en toewijzen, gebruikt u gedelegeerde roltoewijzingen met voorwaarden. Toepassingsteams kunnen voorwaarden gebruiken om hun eigen beveiligingsprinciplen te beheren binnen de beperkingen die het platformteam instelt. Meer bevoorrechte roltoewijzingen vereisen escalatie naar het platformteam. Houd rekening met de volgende factoren wanneer u voorwaarden gebruikt om RBAC-rollen te delegeren:

  • Bekijk de huidige roltoewijzingen voor ingebouwde en aangepaste bevoorrechte rollen en evalueer of u de juiste voorwaarden aan deze bestaande toewijzingen moet toevoegen. U kunt bijvoorbeeld voorwaarden toevoegen aan de aangepaste rollen Abonnementseigenaar en Toepassingseigenaar die de referentiearchitectuur voor de Azure-landingszone biedt. Deze voorwaarden kunnen de hoofdtypen beperken waaraan ze rollen kunnen toewijzen of specifieke rollen beperken die ze kunnen toewijzen.

  • Volg de PoLP wanneer u voorwaarden toevoegt aan roltoewijzingen. Beperk bijvoorbeeld gedelegeerden om alleen rollen toe te wijzen aan groepen of gemachtigden in staat te stellen alle rollen toe te wijzen, behalve bevoorrechte beheerdersrollen, zoals Eigenaar, Beheerder van gebruikerstoegang en RBAC-beheerder.

  • Bouw uw eigen voorwaarden als de beschikbare voorwaardesjablonen niet voldoen aan uw vereisten of beleid.

    

  • Bekijk de bekende beperkingen van het delegeren van Azure-toegangsbeheer aan anderen.

• In de volgende tabel ziet u een voorbeeld van een roltoewijzingsstructuur voor een Azure-landingszoneomgeving. Het biedt een evenwicht tussen beveiliging en beheergemak. U kunt de structuur aanpassen aan de vereisten van uw organisatie. U kunt dezelfde persoon toewijzen aan meerdere groepen, afhankelijk van hun rol binnen de organisatie. Maar u moet de RBAC-toewijzingen toepassen op een specifieke groep binnen een specifieke landingszone.

  Bron	Gebruiker	Roltoewijzing	Toewijzingsdoel	Toewijzingsbereik
  Toepassing X Production-landingszone	Eigenaren van applicatie X	Toepassingseigenaar (aangepast, opgenomen in referentiearchitectuur voor Azure-landingszones)	Application X Prod Admins beveiligingsgroep	Application X-productieabonnementen
  Landingszone van Application X Dev/Test	Eigenaren van applicatie X	Toepassingseigenaar (aangepast, opgenomen in referentiearchitectuur voor Azure-landingszones)	Application X DevTest Admins beveiligingsgroep	Application X dev/test-abonnementen
  Toepassing X Production-landingszone	Application X-beveiligingsbeheerders	Toepassingstoegangsbeheerder (aangepast, met roltoewijzingsvoorwaarden om de toegang tot hun eigen toepassing te beheren)	Application X Prod Security Admins beveiligingsgroep	Application X-productieabonnementen
  Landingszone van Application X Dev/Test	Application X-beveiligingsbeheerders	Toepassingstoegangsbeheerder (aangepast, met roltoewijzingsvoorwaarden om de toegang tot hun eigen toepassing te beheren)	Application X DevTest Security Admins beveiligingsgroep	Application X dev/test-abonnementen
  Toepassing X Production-landingszone	Application X-productiegegevensbeheerder	Gegevensbeheerder (aangepast, met machtigingen voor vereiste gegevensbronnen)	Application X Prod Data Team beveiligingsgroep	Application X-productieabonnementen
  Landingszone van Application X Dev/Test	Application X dev/test-gegevensbeheerder	Gegevensbeheerder (aangepast, met machtigingen voor vereiste gegevensbronnen)	Application X DevTest Data Team beveiligingsgroep	Application X dev/test-abonnementen
  Landingszone voor toepassing Y-productie	Eigenaren van toepassing Y	Toepassingseigenaar (aangepast, opgenomen in referentiearchitectuur voor Azure-landingszones)	Application Y Prod Admins beveiligingsgroep	Y-productieabonnementen voor toepassingen
  Landingszone van toepassing Y Dev/Test	Eigenaren van toepassing Y	Toepassingseigenaar (aangepast, opgenomen in referentiearchitectuur voor Azure-landingszones)	Application Y DevTest Admins beveiligingsgroep	Toepassing Y dev/test-abonnementen
  Landingszone van toepassing Y Dev/Test	Testteam voor de applicatie Y	Testbijdrager (aangepast, met machtigingen vereist voor het testen van applicaties)	Application Y Test Team beveiligingsgroep	Abonnement Y dev/test voor toepassing
  Zandbak	Ontwikkelteam van Application Z	Eigenaar (ingebouwd)	Application Z developers beveiligingsgroep	Toepassing Z-resourcegroepen in sandbox-abonnement
  Platformbronnen	Platformbeheerteam	Bijdrager (ingebouwde functie)	Platform Admins PIM-groep	Platform beheergroep
  Platform landingszones	Platformbeheerteam	Lezer (ingebouwd)	Platform Team beveiligingsgroep	Beheergroep op het hoogste niveau van de organisatie
  Tenantbrede	Beveiligingsteam	Beveiligingsbewerkingen (aangepast, opgenomen in azure-referentiearchitectuur voor landingszones)	Security Ops beveiligingsgroep	Beheergroep op het hoogste niveau van de organisatie
  Tenantbrede	Beveiligingsteam	Beheerder voor voorwaardelijke toegang (ingebouwd, met beveiligde acties ingeschakeld)	Security administrators beveiligingsgroep	Microsoft Entra ID-tenant
  Tenantbrede	Netwerkteam	Netwerkbewerkingen (aangepast, opgenomen in azure-referentiearchitectuur voor landingszones)	Network Ops beveiligingsgroep	Alle abonnementen
  Tenantbrede	FinOps-team	Factureringslezer (ingebouwd)	FinOps Team beveiligingsgroep	Beheergroep op het hoogste niveau van de organisatie

• Azure Policy-toewijzingen die het DeployIfNotExists effect hebben, vereisen een beheerde identiteit om niet-compatibele resources te herstellen. Als u een door het systeem toegewezen beheerde identiteit gebruikt als onderdeel van het toewijzingsproces van Azure Policy, verleent Azure automatisch de vereiste machtigingen. Als u een door de gebruiker toegewezen beheerde identiteit gebruikt, moeten de machtigingen handmatig worden verleend. De roltoewijzingen van de beheerde identiteit moeten de PoLP volgen en alleen de vereiste machtigingen inschakelen voor het uitvoeren van het beleidsherstel op het doelbereik. Beheerde identiteiten voor beleidsherstel bieden geen ondersteuning voor aangepaste roldefinities. Pas roltoewijzingen rechtstreeks toe op beheerde identiteiten en niet op groepen.

Aanbevelingen voor Microsoft Entra PIM

• Gebruik Microsoft Entra PIM om te voldoen aan het Zero Trust-model en toegang met minimale bevoegdheden. Correleren van de rollen van uw organisatie aan de minimale toegangsniveaus die nodig zijn. In Microsoft Entra PIM kunt u systeemeigen Azure-hulpprogramma's gebruiken, bestaande hulpprogramma's en processen uitbreiden of zo nodig bestaande en systeemeigen hulpprogramma's gebruiken.

• Gebruik Microsoft Entra PIM-toegangsbeoordelingen om regelmatig resourcerechten te valideren. Toegangsbeoordelingen maken deel uit van veel nalevingsframeworks, dus veel organisaties hebben al een proces voor toegangsbeoordeling.

• Gebruik bevoorrechte identiteiten voor geautomatiseerde runbooks waarvoor verhoogde toegangsrechten vereist zijn, of voor pijplijnen voor bevoegde implementatie. U kunt dezelfde hulpprogramma's en beleidsregels gebruiken om geautomatiseerde werkstromen te beheren die toegang hebben tot kritieke beveiligingsgrenzen die u gebruikt om gebruikers van gelijkwaardige bevoegdheden te beheren. Automatiserings- en implementatiepijplijnen voor toepassingsteams moeten roltoewijzingen hebben die voorkomen dat de eigenaar van een toepassing hun eigen bevoegdheden escaleert.

• Beheer zeer bevoorrechte Azure RBAC-rollen, zoals eigenaars- of gebruikerstoegangsbeheerders die zijn toegewezen aan leden van het platform- of toepassingslandingszoneteam in een abonnement of beheergroep. Gebruik Microsoft Entra PIM voor groepen om Azure RBAC-rollen te configureren, zodat ze hetzelfde verheffingsproces vereisen als Microsoft Entra ID-rollen.

  Een gebruiker kan bijvoorbeeld regelmatig beperkte beheerderstoegang tot resources in een landingszone van een toepassing vereisen. Af en toe kunnen ze de rol van Eigenaar vereisen. U kunt twee beveiligingsgroepen maken: toepassingsbeheerders en toepassingseigenaren. Wijs de rollen met minimale bevoegdheden toe aan de groep Toepassingsbeheerders en wijs de rol van eigenaar toe aan de rol Toepassingseigenaren. Gebruik PIM-groepen zodat de gebruiker de rol Eigenaar kan aanvragen wanneer dat nodig is. Op alle andere momenten heeft de gebruiker alleen de machtigingen die nodig zijn om hun typische activiteiten uit te voeren.

• Gebruik beveiligde acties met Microsoft Entra PIM om extra beveiligingslagen toe te voegen. In Microsoft Entra ID zijn machtigingen voor beveiligde acties die zijn toegewezen aan beleid voor voorwaardelijke toegang. Wanneer een gebruiker een beveiligde actie probeert uit te voeren, moet deze eerst voldoen aan het beleid voor voorwaardelijke toegang dat is toegewezen aan de vereiste machtigingen. Als u bijvoorbeeld beheerders wilt toestaan om de instellingen voor toegang tussen tenants bij te werken, kunt u vereisen dat zij eerst voldoen aan het phishingbestendige MFA-beleid.

Identiteits- en toegangsbeheer in de referentiearchitectuur van de Azure-landingszone

Identiteits- en toegangsbeheer zijn kernfuncties van de referentiearchitectuur voor azure-landingszones. De implementatie omvat een abonnement dat is toegewezen aan identiteit, waar organisaties AD DS-domeincontrollers of andere identiteitsservices, zoals Microsoft Entra Connect-servers, kunnen implementeren die vereist zijn voor hun omgeving. Niet alle organisaties hebben services in het abonnement nodig. Sommige organisaties kunnen bijvoorbeeld toepassingen hebben die al volledig zijn geïntegreerd met Microsoft Entra ID.

Het identiteitsabonnement heeft een virtueel netwerk dat is gekoppeld aan het virtuele hubnetwerk in het platformabonnement. Met deze configuratie kan het platformteam het identiteitsabonnement beheren en hebben eigenaren van toepassingen indien nodig toegang tot identiteitsservices. U moet het identiteitsabonnement en het virtuele netwerk beveiligen om identiteitsservices te beschermen tegen onbevoegde toegang.

Implementatie van referentiearchitectuur voor Azure-landingszones bevat ook opties voor:

• Wijs aanbevolen beleidsregels toe om identiteiten en domeincontrollers te beheren.
• Maak een virtueel netwerk en maak verbinding met de hub via peering van virtuele netwerken.

Volgende stappen

Identiteits- en toegangsbeheer voor toepassingen