Pacotes de acesso Entra Entitlement Management: piloto governado

O que são os pacotes de acesso Entra Entitlement Management?

Os pacotes de acesso Entra Entitlement Management transformam uma tarefa de negócio definida num pedido de acesso sujeito a governação. Um primeiro pacote útil responde a perguntas práticas: de que recursos precisa esta tarefa, quem é responsável pela decisão, quem pode pedir acesso e quando deve terminar a atribuição? Comece com um projeto cujos responsáveis pelos recursos consigam explicar essas respostas e ajudar a testá-las.

A Microsoft descreve um pacote como um conjunto de acessos a recursos regido por políticas e mantido num catálogo. Os recursos suportados incluem grupos, aplicações empresariais e sites do SharePoint Online. As políticas definem a elegibilidade, a aprovação e a duração da atribuição. Os catálogos estabelecem um âmbito para a delegação. Os pacotes podem servir colaboradores ou utilizadores externos. Estes conceitos provêm da visão geral do entitlement management no Microsoft Learn.

A ausência de um pacote é uma observação de configuração a investigar. Não demonstra que a sua organização não tem governação de acesso. Pode já existir um serviço de pedidos documentado, aprovação pelos responsáveis dos recursos e procedimentos fiáveis de remoção de acesso. Avalie esse processo face à necessidade de negócio antes de decidir se o entitlement management o melhoraria.

Como funciona: delimitar o piloto sujeito a governação

Considere uma equipa de projeto que precisa de uma função específica numa aplicação e de acesso a documentos do projeto. Este é um cenário ilustrativo de planeamento, não uma constatação medida num tenant. Registe os utilizadores previstos, os recursos, os níveis de permissão, o aprovador e a condição de término antes de abrir o assistente. Peça a cada responsável pelos recursos que confirme que o acesso proposto é suficiente para a tarefa e não ultrapassa o necessário.

Mantenha o piloto suficientemente delimitado para conseguir explicar cada permissão incluída. Evite agregar acessos sem relação entre si apenas porque os recursos pertencem ao mesmo departamento. Registe a pessoa responsável pela manutenção do pacote e a pessoa responsável por cada recurso. Estas responsabilidades podem caber a pessoas diferentes; a passagem de responsabilidade importa quando um recurso muda ou um projeto termina.

A visão geral coloca explicitamente os pacotes ao lado de outros mecanismos de atribuição. Adequam-se a tarefas com duração limitada, acesso dependente de aprovação e cenários de colaboração; não substituem todos os métodos de atribuição existentes. Compare o piloto com a associação normal a grupos e com o processo existente de pedidos de serviço. Escolha o mecanismo que permite ao responsável aprovar o acesso certo e demonstrar a sua remoção. Microsoft Learn: quando utilizar pacotes de acesso.

A associação dinâmica e o acesso sujeito a governação também respondem a perguntas operacionais diferentes. A seleção baseada em atributos pode identificar uma população, enquanto uma política de pacote define como essa população recebe um direito de acesso específico. O nosso artigo sobre a retirada do operador memberOf aborda a associação dinâmica e as dependências de atribuição automática do entitlement management. Utilize-o para rever a lógica de atribuição existente antes de conceber um piloto baseado em pedidos, sem presumir que uma migração de regras de grupo fornece provas de aprovação ou expiração.

Verificar o licenciamento e os pré-requisitos administrativos

Os requisitos de licença da visão geral do Learn mencionam Microsoft Entra ID Governance ou Microsoft Entra Suite para utilizadores da organização e indicam que algumas funcionalidades podem operar com Microsoft Entra ID P2. Trate isto como uma verificação de licenciamento por funcionalidade, e não como uma instrução universal para adquirir uma subscrição específica.

A tabela dos fundamentos de licenciamento de Governance inclui pedidos de autosserviço dos utilizadores, grupos, aplicações, sites do SharePoint, gestores ou aprovadores específicos e expiração de atribuições em P2, bem como em Governance e Suite. Nessa tabela, as políticas de atribuição automática e os patrocinadores provenientes dos perfis de utilizador como aprovadores exigem Governance ou Suite. Os produtos Governance também têm subscrições como pré-requisito; a governação de convidados tem considerações de faturação separadas. Verifique as funcionalidades previstas e a população elegível na documentação atual do Learn antes de ativar o piloto. Não deduza o direito de utilização da simples presença de uma licença algures no tenant.

Concentre o primeiro teste em utilizadores humanos e em recursos habituais de projeto. Se mais tarde adicionar funcionalidades avançadas, reveja o licenciamento e as permissões delegadas, em vez de manter as premissas do piloto. Registe a decisão de licenciamento junto do desenho do pacote para que o próximo responsável compreenda quais as escolhas deliberadas.

Deteção: estabelecer se os pacotes estão ausentes

No Microsoft Entra admin center, inspecione ID Governance > Entitlement management > Access package, o caminho documentado no guia de criação. Confirme o diretório e a sua visibilidade antes de interpretar uma vista vazia. Guarde a data da observação, o observador e o âmbito juntamente com o inventário.

Para um inventário por API, a Microsoft documenta o seguinte pedido em List accessPackages:

GET https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/accessPackages

A API devolve os pacotes que o chamador pode ler nos vários catálogos. A tabela de permissões apresenta EntitlementManagement.Read.All como a permissão OAuth menos privilegiada para acesso delegado e de aplicação; os chamadores delegados também precisam de uma função suportada. Para chamadores que utilizam apenas a aplicação, a Microsoft também permite atribuir uma função apropriada em vez dessa permissão de aplicação; Catalog reader é uma opção menos privilegiada. O acesso específico a um catálogo pode limitar o que o chamador vê. Assim, uma resposta vazia bem-sucedida só sustenta uma conclusão de ausência em todo o tenant quando o âmbito da recolha cobre os catálogos do tenant. Conclua a enumeração, incluindo qualquer ligação de continuação devolvida, antes de registar um inventário como completo.

A documentação Graph do recurso accessPackage descreve o catálogo do pacote, as políticas de atribuição e as relações com funções de recursos. Listar objetos de pacote verifica a sua existência; é necessário inspecionar separadamente essas relações para avaliar se um pacote representa o acesso pretendido.

O pedido acima é um método de inspeção documentado, não uma consulta executada num tenant de cliente para este artigo. Conserve o estado real, o âmbito da recolha e a resposta da sua auditoria autorizada. Um erro de autenticação, um erro de autorização, uma execução interrompida ou um âmbito não verificado deve constar das provas como limitação da recolha. Nenhum desses casos sustenta escrever «nenhum pacote configurado».

Remediação: criar o pacote e comprovar o seu ciclo de vida (Remediation)

1. Selecionar o catálogo e as funções dos recursos

Siga o fluxo de criação do Learn: selecione New access package, introduza o nome e a descrição em Basics e escolha o catálogo. Identity Governance Administrator, catalog owner ou access package manager podem criar pacotes dentro do seu âmbito autorizado. Access package managers utilizam recursos já presentes no catálogo; não podem adicionar-lhe recursos. Em Resource roles, selecione os recursos e as funções pretendidos.

Escolha o catálogo de forma deliberada e identifique o seu responsável no registo do piloto. Utilize uma descrição que permita ao requerente reconhecer a tarefa de negócio. Peça aos responsáveis pelos recursos que revejam as funções selecionadas antes de continuar. Uma função de proprietário de grupo é materialmente diferente da associação ao grupo, e uma função de administrador de aplicação pode ser desnecessária para o trabalho normal de projeto. Reveja a permissão real, não apenas o nome de apresentação do recurso.

2. Definir requerentes e aprovadores

Em Requests, configure os utilizadores elegíveis e as definições de aprovação da política inicial. Exija aprovação para o piloto, escolha o aprovador designado e exija uma justificação do pedido. Se utilizar a opção de gestor, configure uma alternativa para a ausência de informação sobre o gestor. Em Who can request access, selecione Self para este piloto solicitado pelos próprios utilizadores. Estes controlos estão documentados nas definições de aprovação do guia de criação.

Prefira uma população de piloto claramente definida a um âmbito amplo de pedidos. Pergunte ao aprovador de que informação precisa para decidir e se consegue reconhecer um pedido inadequado. Teste com um utilizador elegível e com um utilizador fora do âmbito. Registe as decisões esperadas antes do teste para distinguir um defeito da política de um requisito mal compreendido.

Para colaboração externa, reveja também Conditional Access para convidados e definições de colaboração externa. Esse artigo aborda a proteção do início de sessão de convidados, os convites, a visibilidade e os controlos do ciclo de vida. Utilize-o para enquadrar os controlos que rodeiam a população externa; a aprovação de um pacote, por si só, não documenta essa revisão mais ampla.

3. Configurar a expiração antes de criar o pacote

Em Lifecycle, selecione uma expiração de atribuição por data ou duração e decida se as extensões são permitidas e exigem aprovação. Reveja a configuração em Review + create e selecione Create para criar o pacote e a política inicial. Estes são os passos de criação documentados.

Escolha a condição de término a partir do calendário de negócio da tarefa. Para o piloto, utilize uma atribuição de teste que possa atingir a expiração prevista durante a sua janela de verificação. Acorde esse momento com o responsável pelo recurso. Documente como serão tratadas as extensões legítimas e quem as decidirá. Evite deixar uma atribuição permanente apenas porque testar a expiração exige mais coordenação.

4. Verificar o acesso entregue e depois o acesso expirado

O guia de gestão de atribuições da Microsoft documenta Assignments, os detalhes de atribuições individuais e os filtros de estado Delivering e Expired. Os erros de entrega podem ser investigados através da entrada correspondente em Requests. Utilize essas vistas para recolher provas do estado real da atribuição de teste.

Submeta o pedido do piloto através do percurso de aprovação configurado. Registe o requerente, a política selecionada, a decisão, o identificador da atribuição e a hora de término prevista. Verifique que o utilizador de teste recebe a função de recurso pretendida e consegue executar a tarefa permitida. Teste também uma operação relevante que o utilizador não deve poder executar. Um início de sessão bem-sucedido, por si só, diz pouco sobre a adequação da função atribuída.

Após a expiração prevista, registe a atribuição expirada e volte a verificar o acesso ao recurso. Compare a associação a grupos, a atribuição da aplicação e a capacidade do utilizador para executar a tarefa com as provas anteriores. Se o acesso persistir, investigue outras concessões antes de afirmar que o pacote falhou ou que a expiração removeu todo o acesso efetivo. O mesmo utilizador pode ter um direito de acesso separado que o piloto nunca se destinou a remover.

Guarde ambas as observações no registo do piloto. «Pacote criado» é um marco de configuração; «acesso aprovado entregue, seguido da expiração da atribuição e da retirada do acesso ao recurso pretendido» é o resultado de verificação que procura estabelecer. Este artigo não afirma que um teste deste tipo já tenha passado em qualquer tenant.

Como a EtcSec deteta esta situação

O detetor AZ_ENTITLEMENT_MANAGEMENT do etc-collector da EtcSec avalia a existência de pacotes recolhidos através de AzureAccessPackagesProbed e AzureAccessPackagesCount. O Detect() inspecionado tem os seguintes ramos:

O Count: 1 da constatação é a contagem de constatações ao nível do tenant, não uma contagem de utilizadores afetados ou de políticas em falta. Um resultado nil não valida a seleção de recursos, os aprovadores, o âmbito dos pedidos, o licenciamento, a expiração ou a remoção de acesso. O detetor verifica a existência, não a qualidade das políticas. Uma constatação de ausência também não prova que faltam todos os processos alternativos de governação.

Utilize o resultado para abrir a investigação apropriada: cobertura da recolha para Info, avaliação de negócio e de licenciamento para Medium e revisão separada do ciclo de vida quando já existem pacotes. Conserve as provas de entrega e expiração do piloto junto da auditoria para que a próxima revisão possa distinguir uma constatação de existência resolvida de uma governação de acesso demonstrada.