Een beleid implementeren dat kan worden hersteld binnen een gedelegeerd abonnement

Met Azure Lighthouse kunnen serviceproviders beleidsdefinities binnen een gedelegeerd abonnement maken en bewerken. Als u beleidsregels wilt implementeren die gebruikmaken van een hersteltaak (dat wil weten beleidsregels met het effect deployIfNotExists of het effect wijzigen ), moet u een beheerde identiteit maken in de tenant van de klant. Deze beheerde identiteit kan worden gebruikt door Azure Policy om de sjabloon in het beleid te implementeren. In dit artikel worden de stappen beschreven die nodig zijn om dit scenario in te schakelen, zowel wanneer u de klant onboardt voor Azure Lighthouse als wanneer u het beleid zelf implementeert.

Fooi

Hoewel we in dit onderwerp verwijzen naar serviceproviders en klanten, kunnen ondernemingen die meerdere tenants beheren dezelfde processen gebruiken.

Een gebruiker maken die rollen kan toewijzen aan een beheerde identiteit in de tenant van de klant

Wanneer u een klant onboardt naar Azure Lighthouse, definieert u autorisaties die toegang verlenen tot gedelegeerde resources in de tenant van de klant. Elke autorisatie geeft een principalId op die overeenkomt met een Microsoft Entra-gebruiker, -groep of -service-principal in de beheertenant en een roleDefinitionId die overeenkomt met de ingebouwde Azure-rol die wordt verleend.

Als u wilt toestaan dat een principalId rollen toewijst aan een beheerde identiteit in de tenant van de klant, moet u de roleDefinitionId instellen op Gebruikerstoegang Beheer istrator. Hoewel deze rol doorgaans niet wordt ondersteund voor Azure Lighthouse, kan deze worden gebruikt in dit specifieke scenario. Als u deze rol aan deze principalId toewijst, kan deze specifieke ingebouwde rollen toewijzen aan beheerde identiteiten. Deze rollen worden gedefinieerd in de eigenschap delegatedRoleDefinitionIds en kunnen elke ondersteunde ingebouwde Azure-rol bevatten, met uitzondering van gebruikerstoegang Beheer istrator of eigenaar.

Nadat de klant is toegevoegd, kan de principalId die in deze autorisatie is gemaakt, deze ingebouwde rollen toewijzen aan beheerde identiteiten in de tenant van de klant. Deze heeft geen andere machtigingen die normaal gesproken zijn gekoppeld aan de rol Gebruikerstoegang Beheer istrator.

Notitie

Roltoewijzingen tussen tenants moeten momenteel worden uitgevoerd via API's, niet in Azure Portal.

In het onderstaande voorbeeld ziet u een principalId met de rol Gebruikerstoegang Beheer istrator. Deze gebruiker kan twee ingebouwde rollen toewijzen aan beheerde identiteiten in de tenant van de klant: Inzender en Log Analytics-inzender.

{
    "principalId": "3kl47fff-5655-4779-b726-2cf02b05c7c4",
    "principalIdDisplayName": "Policy Automation Account",
    "roleDefinitionId": "18d7d88d-d35e-4fb5-a5c3-7773c20a72d9",
    "delegatedRoleDefinitionIds": [
         "b24988ac-6180-42a0-ab88-20f7382dd24c",
         "92aaf0da-9dab-42b6-94a3-d43ce8d16293"
    ]
}

Beleid implementeren dat kan worden hersteld

Zodra u de gebruiker met de benodigde machtigingen hebt gemaakt, zoals hierboven beschreven, kan die gebruiker beleidsregels implementeren die hersteltaken gebruiken binnen gedelegeerde klantabonnementen.

Stel dat u diagnostische gegevens wilt inschakelen voor Azure Key Vault-resources in de tenant van de klant, zoals in dit voorbeeld wordt geïllustreerd. Een gebruiker in de beherende tenant met de juiste machtigingen (zoals hierboven beschreven) zou een Azure Resource Manager-sjabloon implementeren om dit scenario in te schakelen.

Het maken van de beleidstoewijzing voor gebruik met een gedelegeerd abonnement moet momenteel worden uitgevoerd via API's, niet in Azure Portal. Als u dit doet, moet de apiVersion worden ingesteld op 2019-04-01-preview of hoger om de nieuwe eigenschap delegatedManagedIdentityResourceId op te nemen. Met deze eigenschap kunt u een beheerde identiteit opnemen die zich in de tenant van de klant bevindt (in een abonnement of resourcegroep die is toegevoegd aan Azure Lighthouse).

In het volgende voorbeeld ziet u een roltoewijzing met een delegatedManagedIdentityResourceId.

"type": "Microsoft.Authorization/roleAssignments",
            "apiVersion": "2019-04-01-preview",
            "name": "[parameters('rbacGuid')]",
            "dependsOn": [
                "[variables('policyAssignment')]"
            ],
            "properties": {
                "roleDefinitionId": "[concat(subscription().id, '/providers/Microsoft.Authorization/roleDefinitions/', variables('rbacContributor'))]",
                "principalType": "ServicePrincipal",
                "delegatedManagedIdentityResourceId": "[concat(subscription().id, '/providers/Microsoft.Authorization/policyAssignments/', variables('policyAssignment'))]",
                "principalId": "[toLower(reference(concat('/providers/Microsoft.Authorization/policyAssignments/', variables('policyAssignment')), '2018-05-01', 'Full' ).identity.principalId)]"
            }

Fooi

Er is een vergelijkbaar voorbeeld beschikbaar om te laten zien hoe u een beleid implementeert waarmee een tag (met het wijzigingseffect) wordt toegevoegd aan of verwijderd uit een gedelegeerd abonnement.

Volgende stappen