Compartilhar via

Implantar uma política que pode ser corrigida em uma assinatura delegada

  • Artigo

O Azure Lighthouse permite que os provedores de serviços criem e editem definições de política em uma assinatura delegada. Para implantar políticas que usam uma tarefa de correção (ou seja, políticas com o deployIfNotExists ou o efeito modificar), você precisará criar uma identidade gerenciada no locatário do cliente. Essa identidade gerenciada pode ser usada pelo Azure Policy para implantar o modelo na política. Este artigo descreve as etapas necessárias para habilitar esse cenário, não apenas quando você integra o cliente ao gerenciamento do Azure Lighthouse, mas também quando implanta a política propriamente dita.

Dica

Embora estejamos nos referindo a provedores de serviços e clientes neste tópico, as empresas que gerenciam vários locatários podem usar os mesmos processos.

Criar um usuário que pode atribuir funções a uma identidade gerenciada no locatário do cliente

Ao integrar um cliente ao Azure Lighthouse, você define autorizações que permitem acesso a recursos delegados no locatário do cliente. Cada autorização especifica uma principalId que corresponde a um usuário, grupo ou entidade de serviço do Microsoft Entra no locatário de gerenciamento e um roleDefinitionId que corresponde à função interna do Azure que será concedida.

Para permitir que um principalId atribua funções a uma identidade gerenciada no locatário do cliente, você deve definir a respectiva roleDefinitionId para Administrador de Acesso do Usuário. Embora essa função geralmente não ofereça suporte para o Azure Lighthouse, ela pode ser usada nesse cenário específico. Conceder essa função a essa principalId permite que ela atribua funções internas específicas a identidades gerenciadas. Essas funções são definidas na propriedade delegatedRoleDefinitionIds e podem incluir qualquer função interna do Azure com suporte, exceto o Proprietário e o Administrador de Acesso do Usuário.

Depois que o cliente for integrado, o principalId criado nessa autorização poderá atribuir essas funções internas a identidades gerenciadas no locatário do cliente. Ele não terá outras permissões normalmente associadas à função de administrador de acesso do usuário.

Observação

Atualmente, as atribuições de função entre locatários devem ser feitas por meio de APIs, não no portal do Azure.

Esse exemplo mostra um principalId com a função de administrador de acesso do usuário. Esse usuário poderá atribuir duas funções internas a identidades gerenciadas no locatário do cliente: Colaborador e Colaborador do Log Analytics.

{
    "principalId": "00000000-0000-0000-0000-000000000000",
    "principalIdDisplayName": "Policy Automation Account",
    "roleDefinitionId": "18d7d88d-d35e-4fb5-a5c3-7773c20a72d9",
    "delegatedRoleDefinitionIds": [
         "b24988ac-6180-42a0-ab88-20f7382dd24c",
         "92aaf0da-9dab-42b6-94a3-d43ce8d16293"
    ]
}

Implantar políticas que possam ser corrigidas

Depois de você criar o usuário com as permissões necessárias, esse usuário poderá implantar políticas que usam tarefas de correção nas assinaturas delegadas do cliente.

Por exemplo, digamos que você queira habilitar o diagnóstico em recursos do Azure Key Vault no locatário do cliente, conforme ilustrado neste exemplo. Um usuário no locatário de gerenciamento com as permissões apropriadas (conforme descrito acima) implantaria um modelo do Azure Resource Manager para habilitar esse cenário.

A criação da atribuição de política a ser usada com uma assinatura delegada deve ser feita atualmente por meio de APIs, não no portal do Azure. Ao fazer isso, a apiVersion deve ser definida como 2019-04-01-preview ou posterior, que inclui a nova propriedade delegatedManagedIdentityResourceId. Essa propriedade permite incluir uma identidade gerenciada que reside no locatário do cliente (em uma assinatura ou grupo de recursos que foi integrado ao Azure Lighthouse).

O exemplo a seguir mostra uma atribuição de função com um 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)]"
            }

Dica

Um exemplo similar está disponível para demonstrar como implantar uma política que adiciona ou remove uma tag (usando o efeito modificar) para uma assinatura delegada.

Próximas etapas