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 efeito deployIfNotExists ou modificar ), você deve criar uma identidade gerenciada no locatário do cliente. Essa identidade gerenciada pode ser usada pela Política do Azure para implantar o modelo dentro da política. Este artigo descreve as etapas necessárias para habilitar esse cenário, tanto quando você integra o cliente para o Azure Lighthouse quanto quando implanta a própria política.

Gorjeta

Embora nos referimos 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 possa atribuir funções a uma identidade gerenciada no locatário do cliente

Ao integrar um cliente ao Azure Lighthouse, você define autorizações que concedem acesso a recursos delegados no locatário do cliente. Cada autorização especifica um 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 seu roleDefinitionId como Administrador de Acesso de Usuário. Embora essa função geralmente não tenha suporte para o Azure Lighthouse, ela pode ser usada neste cenário específico. Conceder essa função a esse principalId permite que ele 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 Administrador de Acesso de Usuário ou Proprietário.

Depois que o cliente for integrado, o principalId criado nesta 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 de Usuário.

Nota

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

Este exemplo mostra um principalId com a função de Administrador de Acesso de 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 podem ser corrigidas

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

Por exemplo, digamos que você queria habilitar o diagnóstico nos recursos do Cofre de Chaves do Azure 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.

Atualmente, a criação da atribuição de política a ser usada com uma assinatura delegada deve ser feita por meio de APIs, não no portal do Azure. Ao fazer isso, o apiVersion deve ser definido como 2019-04-01-preview ou posterior para incluir a nova propriedade delegatedManagedIdentityResourceId . Essa propriedade permite que você inclua 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)]"
            }

Gorjeta

Um exemplo semelhante está disponível para demonstrar como implantar uma política que adiciona ou remove uma marca (usando o efeito de modificação) a uma assinatura delegada.

Próximos passos