Wat zijn Azure-beheergroepen?

Als uw organisatie veel Azure-abonnementen heeft, hebt u mogelijk een manier nodig om de toegang, beleidsregels en naleving voor deze abonnementen efficiënt te beheren. Beheergroepen bieden een governancebereik boven abonnementen. U organiseert abonnementen in beheergroepen de governancevoorwaarden die u trapsgewijs toepast op alle gekoppelde abonnementen.

Beheergroepen bieden u op schaal beheer op ondernemingsniveau, ongeacht welk type abonnementen u mogelijk hebt. Alle abonnementen binnen één beheergroep moeten echter dezelfde Azure Active Directory-tenant (Azure AD) vertrouwen.

U kunt bijvoorbeeld beleid toepassen op een beheergroep, dat het aantal regio's beperkt dat beschikbaar is voor het maken van virtuele machines (VM’s). Dit beleid wordt toegepast op alle geneste beheergroepen, abonnementen en resources, en toestaan dat VM's alleen worden gemaakt in geautoriseerde regio's.

Hiërarchie van managementgroepen en abonnementen

U kunt een flexibele structuur van managementgroepen en abonnementen bouwen om uw resources in een hiërarchie te ordenen voor uniform beleid en toegangsbeheer. Het volgende diagram laat een voorbeeld zien van hoe een hiërarchie voor governance kan worden gemaakt met behulp van beheergroepen.

Diagram van een voorbeeld van een hiërarchie voor beheergroepen.

Diagram van een hoofdbeheergroep met zowel beheergroepen als abonnementen. Sommige onderliggende beheergroepen bevatten beheergroepen, sommige abonnementen en sommige beide. Een van de voorbeelden in de voorbeeldhiërarchie is vier niveaus van beheergroepen waarbij het onderliggende niveau alle abonnementen is.

U kunt een hiërarchie maken die bijvoorbeeld een beleid toepast, waarmee VM-locaties worden beperkt tot de regio VS - west in de beheergroep met de naam 'Productie'. Dit beleid is van toepassing op alle Enterprise Agreement-abonnementen die afgeleid zijn van die beheergroep en worden toegepast op alle VM's onder die abonnementen. Dit beveiligingsbeleid kan niet worden gewijzigd door de eigenaar van de resource of het abonnement, wat zorgt voor betere governance.

Notitie

Beheergroepen worden momenteel niet ondersteund in Cost Management-functies voor Microsoft-klantovereenkomst (MCA)-abonnementen.

Een ander scenario waarbij u beheergroepen kunt gebruiken, is om gebruikers toegang te geven tot meerdere abonnementen. Als u meerdere abonnementen naar de desbetreffende beheergroep verplaatst, kunt u één Azure-roltoewijzing in de beheergroep maken, die de toegang doorgeeft aan alle abonnementen. Eén toewijzing in de beheergroep kan gebruikers toegang geven tot alles wat ze nodig hebben. Er hoeven dan geen scripts te worden geschreven voor Azure RBAC-toewijzingen in meerdere abonnementen.

Belangrijke feiten over beheergroepen

  • In één map kunnen 10.000 beheergroepen worden ondersteund.
  • Een beheergroepstructuur ondersteunt tot wel zes niveaus.
    • Deze limiet is exclusief het hoofdniveau of het abonnementsniveau.
  • Een beheergroep of abonnement biedt ondersteuning voor slechts één bovenliggend item.
  • Elke beheergroep kan een groot aantal onderliggende items hebben.
  • Alle abonnementen en beheergroepen bevinden zich in één hiërarchie in elke map. Zie Belangrijke feiten over de hoofdbeheergroep.

Hoofdbeheergroep voor elke map

Elke map krijgt één beheergroep op het hoogste niveau, de hoofdbeheergroep . De hoofdbeheergroep is ingebouwd in de hiërarchie, zodat alle beheergroepen en abonnementen erin kunnen worden gevouwen. Met deze hoofdbeheergroep kunt u algemene beleidsregels en Azure-roltoewijzingen toepassen op mapniveau. De globale beheerder van Azure AD moet eerst de rol Beheerder gebruikerstoegang van deze hoofdgroep aan zichzelf toewijzen. Nadat hij dit heeft gedaan, kan de beheerder een Azure-rol toewijzen aan andere directory-gebruikers of -groepen om de hiërarchie te beheren. Als beheerder kunt u uw eigen account toewijzen als eigenaar van de hoofdbeheergroep.

Belangrijke feiten over de hoofdbeheergroep

  • De weergavenaam van de hoofdbeheergroep is standaard tenanthoofdgroep en werkt zelf als beheergroep. De id is dezelfde waarde als de tenant-id van Azure Active Directory (Azure AD).
  • Als u de weergavenaam wilt wijzigen, moet aan uw account de rol Eigenaar of Inzender in de hoofdbeheergroep worden toegewezen. Zie Change the name of a management group (De naam van een beheergroep wijzigen) om de naam van een beheergroep bij te werken.
  • In tegenstelling tot andere beheergroepen kan de hoofdbeheergroep niet worden verplaatst of verwijderd.
  • Alle abonnementen en beheergroepen kunnen worden samengevouwen in deze ene hoofdbeheergroep binnen de map.
    • Alle resources in de map kunnen worden samengevouwen in de hoofdbeheergroep voor algemeen beheer.
    • Wanneer er een nieuw abonnement wordt gemaakt, wordt dit standaard automatisch in de hoofdbeheergroep geplaatst.
  • Alle Azure-klanten kunnen de hoofdbeheergroep zien, maar niet alle klanten hebben de mogelijkheid om die hoofdbeheergroep te beheren.
    • Iedereen die toegang heeft tot een abonnement, kan de context zien van waar dat abonnement zich in de hiërarchie bevindt.
    • Niemand krijgt standaard toegang tot de hoofdbeheergroep. Globale beheerders van Azure AD zijn de enige gebruikers die zichzelf toegang kunnen verschaffen. Zodra ze toegang hebben tot de hoofdbeheergroep, kunnen de globale beheerders elke Azure-rol toewijzen aan andere gebruikers om deze te beheren.

Belangrijk

Elke toewijzing van gebruikerstoegang of beleid in de hoofdbeheergroep is van toepassing op alle resources in de map. Daarom moeten alle klanten goed nadenken over de noodzaak om items op dit niveau toe te wijzen. Op dit niveau mogen alleen toewijzingen voor gebruikerstoegang of beleid de aanduiding ‘Must have’ (Strikt noodzakelijk) hebben.

Eerste installatie van beheergroepen

Wanneer een gebruiker start met het gebruik van beheergroepen, vindt er een proces plaats voor de eerste installatie. Eerst wordt er een hoofdbeheergroep gemaakt in de map. Zodra deze groep klaar is, worden alle bestaande abonnementen die in de map zijn opgenomen gemaakt tot onderliggende items van de hoofdbeheergroep. De reden dat dit proces zo werkt, is om er zeker van te zijn dat er binnen een map slechts één beheergroephiërarchie is. Die ene hiërarchie in de map zorgt ervoor dat klanten met een beheerdersrol globale toegang en beleidsregels kunnen toepassen waar andere klanten in de map niet omheen kunnen. Alle toegewezen items in de hoofdmap zijn van toepassing op de hele hiërarchie, waaronder alle beheergroepen, abonnementen, resourcegroepen en resources binnen die Azure AD tenant.

Problemen met de weergave van alle abonnementen

Een paar mappen die vroeg in de preview-versie van beheergroepen begonnen te gebruiken vóór 25 juni 2018, konden een probleem zien waarbij niet alle abonnementen zich in de hiërarchie bevonden. Het proces voor het onderbrengen van alle abonnementen in de hiërarchie werden geïmplementeerd nadat er een rol- of beleidstoewijzing was uitgevoerd in de hoofdbeheergroep in de map.

Het probleem oplossen

U kunt dit probleem op twee manieren verhelpen.

  • Alle rol- en beleidstoewijzingen verwijderen uit de hoofdbeheergroep
    • Door alle beleids- en roltoewijzingen van de hoofdbeheergroep te verwijderen, zal de service alle abonnementen in de hiërarchie aanvullen tijdens de volgende nachtelijke cyclus. Dankzij dit proces wordt er niet onbedoeld toegang verleend of beleid toegewezen aan alle abonnementen van de tenant.
    • De beste manier om dit proces uit te voeren zonder dat dit van invloed is op uw services, is door de rol- of beleidstoewijzingen één niveau onder de hoofdbeheergroep toe te passen. Vervolgens kunt u alle toewijzingen van het hoofdbereik verwijderen.
  • De API rechtstreeks aanroepen om het backfill-proces te starten
    • Elke klant in de map kan de API's TenantBackfillStatusRequest en StartTenantBackfillRequest aanroepen. Wanneer de API StartTenantBackfillRequest wordt aangeroepen, wordt hiermee het initiële instellingsproces gestart voor het verplaatsen van alle abonnementen naar de hiërarchie. Met dit proces wordt ook afgedwongen dat alle nieuwe abonnementen een onderliggend element van de hoofdbeheergroep worden gemaakt. Dit proces kan worden uitgevoerd zonder de toewijzingen op het hoofdniveau te wijzigen. Door de API aan te roepen, geeft u aan dat een beleids- of toegangstoewijzing in de hoofdmap mag worden toegepast op alle abonnementen.

Als u vragen hebt over dit backfill-proces, neemt u contact op met: managementgroups@microsoft.com

Toegang tot beheergroepen

Azure-beheergroepen ondersteunen op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) voor alle soorten toegang tot resources en roldefinities. Deze machtigingen worden overgenomen door onderliggende resources die in de hiërarchie zijn opgenomen. Elke Azure-rol kan worden toegewezen aan een beheergroep die door alle onderliggende items in de hiërarchie voor de resources worden overgenomen. Zo kan de Azure-rol VM-inzender aan een beheergroep worden toegewezen. Deze rol heeft geen actie in de beheergroep, maar wordt overgenomen door alle VM's in die beheergroep.

In de volgende tabel staat een lijst met rollen en de acties die worden ondersteund in beheergroepen.

Naam van Azure-rol Maken Naam wijzigen Verplaatsen** Verwijderen Toegang toewijzen Beleid toewijzen Lezen
Eigenaar X X X X X X X
Inzender X X X X X
Beheergroep-inzender* X X X X X
Lezer X
Beheergroep-lezer* X
Inzender voor resourcebeleid X
Beheerder van gebruikerstoegang X X

*: Met de rollen Inzender en Lezer van beheergroepen kunnen gebruikers deze acties alleen uitvoeren op het bereik van de beheergroep.

**: Roltoewijzingen in de hoofdbeheergroep zijn niet vereist om een abonnement of beheergroep naar en van de groep te verplaatsen.

Zie Uw resources beheren met beheergroepen voor meer informatie over het verplaatsen van items binnen de hiërarchie.

Aangepaste roldefinitie en -toewijzing van Azure

Ondersteuning voor aangepaste rollen van Azure voor beheergroepen is momenteel in de preview-versie beschikbaar met enkele beperkingen. U kunt het bereik van de beheergroep definiëren in het toewijsbare bereik van de roldefinitie. Die aangepaste rol van Azure is dan beschikbaar voor toewijzing in die beheergroep en alle beheergroepen, abonnementen, resourcegroepen en resources daaronder. Deze aangepaste rol neemt machtigingen over in de hiërarchie op dezelfde manier als een ingebouwde rol.

Voorbeelddefinitie

Het definiëren en maken van een aangepaste rol verandert niet met het opnemen van beheergroepen. Gebruik het volledige pad om de beheergroep /providers/Microsoft.Management/managementgroups/{groupId} te definiëren.

Gebruik de id van de beheergroep en niet de weergavenaam van de beheergroep. Deze fout wordt vaak gemaakt omdat beide aangepaste velden zijn bij het maken van een beheergroep.

...
{
  "Name": "MG Test Custom Role",
  "Id": "id",
  "IsCustom": true,
  "Description": "This role provides members understand custom roles.",
  "Actions": [
    "Microsoft.Management/managementgroups/delete",
    "Microsoft.Management/managementgroups/read",
    "Microsoft.Management/managementgroup/write",
    "Microsoft.Management/managementgroup/subscriptions/delete",
    "Microsoft.Management/managementgroup/subscriptions/write",
    "Microsoft.resources/subscriptions/read",
    "Microsoft.Authorization/policyAssignments/*",
    "Microsoft.Authorization/policyDefinitions/*",
    "Microsoft.Authorization/policySetDefinitions/*",
    "Microsoft.PolicyInsights/*",
    "Microsoft.Authorization/roleAssignments/*",
    "Microsoft.Authorization/roledefinitions/*"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
        "/providers/microsoft.management/managementGroups/ContosoCorporate"
  ]
}
...

Problemen met het verbreken van de roldefinitie en het toewijzingshiërarchiepad

Roldefinities kunnen overal binnen de hiërarchie van de beheergroep worden toegewezen. Een roldefinitie kan worden gedefinieerd in een bovenliggende beheergroep terwijl de daadwerkelijke roltoewijzing bestaat op het onderliggende abonnement. Omdat er een relatie bestaat tussen de twee items, ontvangt u een foutmelding wanneer u probeert de toewijzing van de definitie te scheiden.

Laten we bijvoorbeeld eens kijken naar een kleine sectie van een hiërarchie voor een besturingselement.

Diagram van een subset van het voorbeeld van een hiërarchie voor beheergroepen.

Het diagram is gericht op de hoofdbeheergroep met onderliggende IT- en Marketingbeheergroepen. De IT-beheergroep heeft één onderliggende beheergroep met de naam Productie terwijl de Marketingbeheergroep twee onderliggende abonnementen van de gratis proefversie heeft.

Stel dat er een aangepaste rol is gedefinieerd in de Marketing-beheergroep. Deze aangepaste rol wordt vervolgens toegewezen aan de twee gratis proefabonnementen.

Als we een van deze subabonnementen proberen te verplaatsen naar een onderliggend niveau van de Production-beheergroep, wordt het pad van de abonnementsroltoewijzing naar de roldefinitie van de Marketing-beheergroep verbroken. In dit scenario wordt een foutbericht weergegeven waarin staat dat de verplaatsing niet is toegestaan omdat de relatie dan wordt verbroken.

Er zijn verschillende opties om dit scenario op te lossen:

  • Verwijder de roltoewijzing uit het abonnement voordat u het abonnement naar een nieuwe bovenliggende beheergroep verplaatst.
  • Voeg het abonnement toe aan het toewijsbare bereik van de roldefinitie.
  • Wijzig het toewijsbare bereik in de roldefinitie. In het bovenstaande voorbeeld kunt u de toewijsbare bereiken van Marketing bijwerken naar de hoofdbeheergroep, zodat de definitie kan worden bereikt door beide vertakkingen van de hiërarchie.
  • Maak een andere aangepaste rol die is gedefinieerd in de andere vertakking. Voor deze nieuwe rol moet de roltoewijzing ook worden gewijzigd in het abonnement.

Beperkingen

Er bestaan beperkingen wanneer u aangepaste rollen gebruikt voor beheergroepen.

  • U kunt slechts één beheergroep definiëren in het toewijsbare bereik van een nieuwe rol. Deze beperking bestaat om het aantal situaties te verminderen waarin de koppeling tussen roldefinities en roltoewijzingen wordt verbroken. Deze situatie treedt op wanneer een abonnement of beheergroep met een roltoewijzing wordt verplaatst naar een andere bovenliggende site die niet over de roldefinitie beschikt.
  • Resourceprovider-gegevensvlakacties kunnen niet worden gedefinieerd in de aangepaste rollen van een beheergroep. Deze beperking bestaat omdat er een latentieprobleem is met het bijwerken van de gegevensvlak-resourceproviders. Er wordt aan dit latentieprobleem gewerkt en deze acties worden uitgeschakeld in de roldefinitie om risico's te beperken.
  • De Azure Resource Manager valideert niet het bestaan van de beheergroep in het toewijsbare bereik van de roldefinitie. Als er een typefout of een onjuiste beheergroep-id wordt vermeld, wordt de roldefinitie nog steeds gemaakt.
  • Roltoewijzing van een rol met dataActions wordt niet ondersteund. Maak in plaats daarvan de roltoewijzing in het abonnementsbereik.

Belangrijk

Het toevoegen van een beheergroep aan AssignableScopes is momenteel in de preview-fase. Deze preview-versie wordt aangeboden zonder Service Level Agreement en wordt niet aanbevolen voor productieworkloads. Misschien worden bepaalde functies niet ondersteund of zijn de mogelijkheden ervan beperkt. Zie Supplemental Terms of Use for Microsoft Azure Previews (Aanvullende gebruiksvoorwaarden voor Microsoft Azure-previews) voor meer informatie.

Beheergroepen en abonnementen verplaatsen

Als u een beheergroep of een abonnement wilt verplaatsen om het/deze een onderliggend item van een andere beheergroep te maken, moeten drie regels worden geëvalueerd als waar.

Als u de verplaatsing wilt uitvoeren, hebt u het volgende nodig:

  • Schrijfmachtigingen voor schrijf- en roltoewijzingen van beheergroepen voor het onderliggende abonnement of de onderliggende beheergroep.
    • Voorbeeld van ingebouwde rol: Eigenaar
  • Schrijftoegang voor de beheergroep op de beoogde bovenliggende beheergroep.
    • Voorbeeld van een ingebouwde rol: Eigenaar, Inzender, Inzender beheergroep
  • Schrijftoegang voor de beheergroep op de bestaande bovenliggende beheergroep.
    • Voorbeeld van een ingebouwde rol: Eigenaar, Inzender, Inzender beheergroep

Uitzondering: Als het doel of de bestaande bovenliggende beheergroep de hoofdbeheergroep is, zijn de machtigingsvereisten niet van toepassing. Omdat de hoofdbeheergroep de standaardlandingslocatie is voor alle nieuwe beheergroepen en abonnementen, hebt u er geen machtigingen voor nodig om een item te verplaatsen.

Als de rol Eigenaar van het abonnement wordt overgenomen van de huidige beheergroep, zijn uw verplaatsingsdoelen beperkt. U kunt het abonnement alleen verplaatsen naar een andere beheergroep met de rol Eigenaar . U kunt deze niet verplaatsen naar een beheergroep waarin u inzender bent, omdat u het eigendom van het abonnement verliest. Als u rechtstreeks bent toegewezen aan de rol Eigenaar voor het abonnement (niet overgenomen van de beheergroep), kunt u deze verplaatsen naar elke beheergroep waaraan u de rol Inzender hebt toegewezen.

Belangrijk

Azure Resource Manager slaat de hiërarchiegegevens van beheergroepen maximaal 30 minuten in de cache op. Als gevolg hiervan wordt het verplaatsen van een beheergroep mogelijk niet onmiddellijk doorgevoerd in de Azure Portal.

Beheergroepen controleren met behulp van activiteitenlogboeken

Beheergroepen worden ondersteund in het Azure-activiteitenlogboek. U kunt op dezelfde centrale locatie als andere Azure-resources zoeken naar alle gebeurtenissen die in een beheergroep plaatsvinden. U kunt bijvoorbeeld alle roltoewijzingen of beleidstoewijzingswijzigingen zien die zijn aangebracht in een bepaalde beheergroep.

Schermopname van activiteitenlogboeken en bewerkingen met betrekking tot de geselecteerde beheergroep.

Wanneer u query's wilt uitvoeren op beheergroepen buiten de Azure Portal, ziet het doelbereik voor beheergroepen eruit als '/providers/Microsoft.Management/managementGroups/{management-group-id}'.

Notitie

Met behulp van de Azure Resource Manager REST API kunt u diagnostische instellingen inschakelen voor een beheergroep om gerelateerde Vermeldingen van het Azure-activiteitenlogboek te verzenden naar een Log Analytics-werkruimte, Azure Storage of Azure Event Hub. Zie Diagnostische instellingen voor beheergroepen - Maken of bijwerken voor meer informatie.

Volgende stappen

Voor meer informatie over beheergroepen gaat u naar: