Auditoria de funções personalizadas Entra ID: sem atribuições

Auditoria de funções personalizadas Entra ID: o que é medido?

Uma auditoria de funcoes personalizadas entra id deve responder a três perguntas distintas: quais definições de permissões existem, quais entidades de segurança as detêm e se essas atribuições ainda atendem a uma necessidade de negócio. A Microsoft modela uma atribuição como uma ligação entre uma definição, uma entidade de segurança e um âmbito. Encontrar apenas uma definição personalizada não demonstra acesso privilegiado. Microsoft Graph: unifiedRoleAssignment.

As revisões de acesso tratam das atribuições; uma auditoria das definições examina separadamente as permissões concedidas por essas atribuições. Uma revisão pode deixar de fora atribuições além das funções, populações ou tipos de atribuição selecionados. Uma revisão devidamente direcionada pode remover o acesso quando os seus resultados são aplicados. Rever as atribuições também deixa uma questão distinta: a definição subjacente deve continuar a existir e as suas permissões são adequadas? Criar revisões de acesso a funções, concluir e aplicar revisões.

Este guia separa essas perguntas, apresenta pedidos Graph documentados e explica sete verificações do etc-collector. Não contém resultados de um tenant nem operações Graph executadas. O objetivo prático é um conjunto de evidências que permita a um administrador justificar o acesso mantido, remover atribuições desnecessárias e desativar definições personalizadas realmente redundantes, sem confundir essas ações.

Definições, funções ativadas e detentores

No Graph, isBuiltIn=false identifica uma definição de função personalizada. isEnabled descreve se a definição está disponível para atribuição; não indica se alguém a detém atualmente. rolePermissions contém a sua coleção de permissões. A Microsoft indica que resourceScopes não deve ser utilizado e está previsto para descontinuação; associe o âmbito à atribuição. Propriedades de unifiedRoleDefinition.

As funções de diretório do Microsoft Entra governam recursos Entra; o RBAC de recursos Azure governa recursos como máquinas virtuais e armazenamento. As respetivas permissões não são intercambiáveis. As funções de diretório personalizadas podem implementar uma tarefa mais restrita do que uma função incorporada, pelo que “personalizada” não constitui, por si só, um veredito de segurança. Visão geral do RBAC do Microsoft Entra.

Para esta auditoria, mantenha três categorias de constatações: complexidade das definições, atribuições que exigem justificação e incerteza na recolha. Trata-se de um método de apresentação recomendado. Evita apresentar uma lista vazia de atribuições como um comprometimento ativo e impede que um catálogo de funções aparentemente pequeno substitua a análise das permissões.

Como funciona: as permissões e o âmbito determinam a exposição

O nome de uma permissão segue um namespace, uma entidade, um conjunto de propriedades e uma ação. Por exemplo, microsoft.directory/applications/credentials/update é uma permissão de diretório, não uma permissão de aplicação Graph consentida chamada Application.ReadWrite.All. A documentação da Microsoft sobre permissões privilegiadas explica a estrutura das permissões e como estas podem tornar privilegiada uma função incorporada ou personalizada. Funções e permissões privilegiadas.

O catálogo de permissões de registo de aplicações identifica as atualizações de credenciais como alterações a certificados e segredos em aplicações de tenant único e de vários tenants. A variante applications.myOrganization restringe o subtipo de aplicação. Também distingue applications/permissions/update, que altera a configuração de permissões, da concessão efetiva de consentimento. Preserve estas diferenças ao comparar definições; nomes de ações semelhantes não são intercambiáveis. Permissões personalizadas de registo de aplicações.

Um caminho condicional de abuso de credenciais

A Microsoft alerta que um administrador capaz de adicionar credenciais de aplicação pode fazer-se passar por essa aplicação, cujas permissões podem superar as do próprio administrador. O seguinte é uma inferência operacional baseada nesse alerta e no modelo de âmbito das funções personalizadas: uma atribuição efetiva de atualização de credenciais ao nível do diretório pode expor os registos de aplicações desse diretório; uma atribuição limitada a um registo restringe o alvo em conformidade. Delegar permissões de gestão de aplicações.

A cadeia inferida exige uma atribuição efetiva ou uma ativação permitida, uma credencial aceite para a aplicação visada e permissões efetivas úteis da aplicação. Não concede automaticamente Global Administrator. Não demonstra controlo sobre todas as identidades de carga de trabalho: um registo local de aplicação, uma identidade gerida e um service principal de uma aplicação pertencente a uma organização externa são objetos diferentes. Delegação de gestão de aplicações, RBAC e identidades de carga de trabalho.

Um detetor da quantidade de definições não pode estabelecer esta cadeia. PA_CUSTOM_ROLE_EXCESSIVE testa o número de funções não incorporadas, não as suas ações nem os âmbitos das atribuições (azure/privileged-access/roles/custom-role-excessive.go:24). Uma única definição poderosa pode, portanto, merecer investigação mesmo quando essa verificação de quantidade não assinala problemas.

As funções de administrador nomeadas continuam a ser populações distintas

Application Administrator diz respeito à administração de aplicações; Exchange Administrator e SharePoint Administrator governam os respetivos serviços. Security Administrator gere a configuração de segurança, enquanto Privileged Role Administrator gere atribuições de funções e PIM. São responsabilidades distintas na referência de funções da Microsoft, não cinco nomes para o mesmo privilégio. Referência de funções incorporadas.

Recomenda-se pedir a cada responsável de serviço que explique as tarefas que exigem a sua função, o âmbito necessário e o período de acesso esperado. Mantenha visíveis os detentores não humanos: o nosso artigo relacionado sobre service principals com funções administrativas e privilégios permanentes examina a responsabilidade e o ciclo de vida dos detentores. Complementa um inventário de definições; não o substitui.

Medição: pedidos Microsoft Graph documentados

Os pedidos abaixo foram copiados dos exemplos HTTP ou da sintaxe de pedidos citados no Learn. Cada um tem o seu próprio bloco de código. São documentação, não instruções executadas contra um tenant para este artigo. Numa auditoria autorizada, registe o momento da recolha, as permissões, o estado da resposta e a paginação. Siga cada @odata.nextLink devolvido; classifique recolhas falhadas ou incompletas como desconhecidas, não como zero atribuições.

1. Listar definições e classificar funções personalizadas

O exemplo do fornecedor de diretório no Learn lista as definições de funções:

GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleDefinitions

A mesma API documenta a filtragem por igualdade em isBuiltIn. Para o pedido apresentado, classifique localmente as definições devolvidas utilizando isBuiltIn=false, preserve os respetivos IDs e estado de ativação e examine as coleções de permissões. RoleManagement.Read.Directory é uma permissão de leitura suportada; as chamadas delegadas também exigem uma função de operador adequada. Listar roleDefinitions.

Recomenda-se preservar a definição original ao lado da sua interpretação. Um nome de apresentação como “Application Support” não explica quais ações de escrita permite. Inclua as ações exatas, o responsável de negócio e a justificação no registo da auditoria, para que um futuro revisor possa comparar permissões em vez de nomes.

2. Distinguir funções incorporadas ativadas

O exemplo documentado de directoryRoles é:

GET https://graph.microsoft.com/v1.0/directoryRoles

Esta operação devolve funções ativadas, não o conjunto completo de definições incorporadas disponíveis. A ativação de funções de diretório nesta API também não é uma sessão de ativação PIM de um utilizador. Reconcilie roleTemplateId quando adequado, em vez de tratar IDs de instância e IDs de definição como intercambiáveis. Listar directoryRoles.

3. Recolher atribuições ativas

O Learn documenta a sintaxe do pedido para o fornecedor de diretório:

GET /roleManagement/directory/roleAssignments

Utilize a raiz de serviço v1.0 para esse caminho relativo. O Learn também fornece este exemplo exato de filtragem e expansão:

GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?$filter=roleDefinitionId eq '62e90394-69f5-4237-9190-012177145e10'&$expand=principal

O GUID é o exemplo da Microsoft para Global Administrator, não uma definição personalizada descoberta no seu tenant. Numa investigação por definição, substitua-o pelo ID de definição verificado. A API de listagem suporta $filter, $expand e $select, incluindo RoleManagement.Read.Directory entre as permissões de leitura. Listar unifiedRoleAssignments.

Associe as atribuições às definições utilizando roleDefinitionId e preserve principalId e directoryScopeId. As entidades de segurança suportadas incluem utilizadores, grupos aos quais se podem atribuir funções e service principals. Uma entidade de segurança de grupo expandida continua a ser um objeto de grupo; não representa o número de pessoas que recebem acesso através da pertença. Campos e relações das atribuições.

4. Recolher a elegibilidade PIM separadamente

O exemplo documentado de elegibilidade é:

GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleEligibilityScheduleInstances

A API devolve instâncias de elegibilidade e suporta seleção, filtragem e expansão. A sua permissão de leitura com menos privilégios é RoleEligibilitySchedule.Read.Directory; o acesso delegado também exige uma função de operador. Listar roleEligibilityScheduleInstances.

Recomenda-se manter os registos ativos e elegíveis separados antes de produzir uma vista combinada. Faça corresponder a entidade de segurança, a definição, o âmbito e as datas relevantes. Uma lista ativa vazia não determina se alguém continua elegível, e uma resposta de elegibilidade não estabelece a utilização histórica. Registe exatamente a pergunta a que cada conjunto de dados responde.

5. Identificar atribuições privilegiadas sem ocultar a versão da API

A página do Learn sobre funções privilegiadas apresenta este exemplo opcional:

GET https://graph.microsoft.com/beta/roleManagement/directory/roleAssignments?$expand=roleDefinition&$filter=roleDefinition/isPrivileged eq true

Este é explicitamente um pedido beta. Não o reescreva silenciosamente como v1.0 nem implique que isPrivileged é uma propriedade documentada pelo recurso de definição v1.0 utilizado acima. A página também descreve a etiqueta PRIVILEGED no centro de administração. Identificação de funções privilegiadas.

Deteção: contar atribuições, entidades distintas e valores desconhecidos

Recomenda-se produzir a seguinte folha de análise para cada função. São campos de apresentação da auditoria, não limites adicionais da Microsoft:

Para uma função ativada sem atribuições recolhidas, reconcilie primeiro os IDs e confirme que ambos os caminhos de recolha foram bem-sucedidos. Depois, pergunte ao responsável se a definição tem uma finalidade planeada. Descreva-a como “ativada sem atribuição ativa ou elegível recolhida”, não como “nunca utilizada”. O predicado UNUSED do collector verifica a presença nos dados de entrada atuais, não o histórico de atividade (azure/privileged-access/roles/unused-admin-role.go:36).

Para contar detentores, indique se o número representa registos de atribuição ou entidades de segurança distintas. O detetor TOO_MANY partilhado compara IDs de funções e conta entradas de atribuição correspondentes; não elimina duplicados de pessoas, não filtra o tipo de entidade e não restringe o âmbito (azure/privileged-access/roles/too-many-privileged-roles.go:43). Trate o resultado como um sinal de triagem que requer esta folha de análise.

Transformar um sinal numa decisão passível de revisão

Recomenda-se dar a cada constatação um encaminhamento explícito: manter com justificação, investigar evidências incompletas, remover uma atribuição, restringir uma atribuição ou desativar uma definição personalizada. Registe a pessoa responsável pela decisão e as evidências que examinou. Mantenha o resultado do detetor ao lado desse encaminhamento, para que uma exceção operacional continue a distinguir-se de um erro de medição.

Para uma constatação sobre a quantidade de definições, peça uma comparação de permissões antes de recomendar a consolidação. Para uma constatação UNUSED, peça os registos de recolha ativos e elegíveis antes de recomendar a desativação. Para uma constatação TOO_MANY, pergunte quais entidades e âmbitos produziram a contagem antes de recomendar uma população menor. Estas perguntas seguem os três predicados descritos acima; nenhuma exige inventar um resultado de exploração.

Recomenda-se documentar a regra de contagem na própria exportação. Se uma entidade aparecer em vários âmbitos, explique se o relatório conta essas atribuições separadamente. Se aparecer um grupo, identifique a sua atribuição como uma concessão ao grupo e reserve um campo separado para evidências de pertença. Se não foi possível recolher a elegibilidade, marque como provisória a conclusão de ausência. Isto torna o relatório utilizável por um revisor que não realizou a recolha.

Escolha as evidências de encerramento ao abrir a constatação. Uma tarefa de desativação de definição deve terminar com a definição aprovada ausente de um inventário atualizado. Uma tarefa de remoção de atribuição deve terminar com essa concessão específica ausente do conjunto de dados relevante. Uma exceção mantida deve terminar com uma finalidade documentada e uma data de revisão futura. Estes são critérios de aceitação recomendados para a auditoria, não alegações sobre uma funcionalidade de aplicação automática.

A Microsoft recomenda menos de cinco Global Administrators e menos de dez atribuições de funções privilegiadas em toda a organização. São recomendações de governação, não limites de atribuição impostos. A página citada não estabelece um limite de dois a quatro detentores por função Application, Exchange, Security, SharePoint ou Privileged Role Administrator. Os limiares por função do collector são valores predefinidos do produto. Boas práticas para funções do Microsoft Entra.

Correção: desativar definições redundantes e governar o acesso restante (Remediation)

1. Decidir quais funções personalizadas devem permanecer

Recomenda-se rever cada definição com o responsável do serviço: qual operação exata a exige, qual âmbito mais restrito funciona e quem é responsável por futuras alterações? Consolide definições redundantes apenas depois de comparar as suas ações e atribuições previstas. Mantenha funções personalizadas úteis quando implementam o conjunto de permissões necessário de forma mais precisa do que uma função incorporada. Seleção de funções com o menor privilégio.

Trate isto como um registo de decisão, não como uma tentativa de atingir uma dimensão arbitrária do catálogo. Para uma definição aparentemente vazia, capture os inventários ativos e elegíveis, confirme a qualidade da recolha e investigue dependências planeadas antes de aprovar a desativação. Quando o acesso continua necessário, dê prioridade à redução de ações desnecessárias de gestão de credenciais e de âmbitos amplos de aplicações. Permissões personalizadas de registo.

2. Remover atribuições desnecessárias e depois eliminar definições personalizadas aprovadas

Recomenda-se separar as duas decisões de alteração. Remover uma atribuição trata do acesso de um detentor; desativar uma definição trata do catálogo de funções. A API de eliminação da Microsoft suporta definições personalizadas, proíbe eliminar funções incorporadas e documenta esta sintaxe:

DELETE /roleManagement/directory/roleDefinitions/{id}

Esta é uma operação de escrita citada, não executada aqui. Substitua {id} apenas pelo ID da definição personalizada aprovada. O Learn especifica RoleManagement.ReadWrite.Directory como a permissão de API com menos privilégios e Privileged Role Administrator como a função de operador delegado suportada com menos privilégios. Uma eliminação bem-sucedida devolve 204 No Content. Eliminar unifiedRoleDefinition.

Para uma função incorporada reportada por UNUSED, documente por que não existem detentores e se a instância ativada continua relevante. Não aplique um procedimento de eliminação de definições personalizadas a todos os resultados UNUSED. Recomenda-se verificar os inventários de definições e atribuições após a alteração antes de a encerrar.

3. Definir populações justificadas e migrar o acesso humano adequado para PIM

Recomenda-se um orçamento de acesso por função baseado nas tarefas necessárias e na cobertura operacional, com exceções explícitas. Avalie o total de atribuições privilegiadas da organização segundo as orientações da Microsoft, em vez de tratar os limiares do collector como quotas obrigatórias da Microsoft.

O PIM suporta ativação baseada em tempo e aprovação para funções Entra incorporadas e personalizadas. O seu plano de implementação recomenda testar um piloto, configurar definições para cada função e preservar o acesso de emergência. Os service principals não podem receber atribuições elegíveis; podem receber atribuições ativas limitadas no tempo. O plano da Microsoft recomenda duas contas de emergência exclusivamente na cloud com atribuições permanentes de Global Administrator. Planear uma implementação de PIM.

Para atribuições humanas adequadas, recomenda-se testar aprovação, MFA, justificação e duração face ao modelo operacional pretendido antes da implementação alargada. O nosso artigo sobre controlos de aprovação, MFA, justificação e duração da ativação PIM cobre essa revisão de configuração separada.

Confirme o licenciamento antes de adotar o plano: a utilização de funções personalizadas exige P1 para os utilizadores atribuídos, enquanto o PIM exige P2 ou Governance. As revisões de acesso de service principals precisam de Workload ID Premium além de P2 ou Governance. Licenciamento de funções personalizadas, Licenciamento PIM e orientações sobre funções, Pré-requisitos das revisões PIM.

4. Rever o acesso e aplicar as decisões

No PIM, selecione as funções Entra e populações relevantes, escolha atribuições ativas, elegíveis ou ambas, e configure revisores responsáveis e o tratamento da ausência de resposta. Uma revisão captura um instantâneo no início; os grupos aos quais se podem atribuir funções aparecem sem expansão dos membros. Criar revisões de acesso a funções.

Recomenda-se manter o âmbito da revisão ao lado dos resultados, para que “revisão concluída” não seja confundido com “todo o acesso administrativo revisto”. Documente evidências de pertença separadas quando uma função é atribuída a um grupo. Dê aos responsáveis das cargas de trabalho uma tarefa de revisão adequada à identidade de serviço, em vez de assumir que os controlos de ativação humana a abrangem.

O acesso recusado é removido quando os resultados da revisão são aplicados, manualmente ou através da aplicação automática configurada. Registar apenas uma recusa não é o passo final de revogação. Concluir revisões de acesso a funções.

5. Verificar o resultado com as mesmas medições

Recomenda-se repetir as leituras documentadas após as alterações, comparando IDs de definições, ações de permissões, âmbitos e atribuições ativas e elegíveis. Verifique a alteração específica aprovada: um detentor removido, uma permissão restringida ou uma definição desativada. Preserve exceções e valores desconhecidos, em vez de declarar a auditoria bem-sucedida porque uma contagem diminuiu.

Como o EtcSec deteta isto

Os sete IDs seguintes existem no catálogo. As respetivas implementações foram lidas no etc-collector no commit b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c. Os caminhos abaixo são relativos a public/internal/audit/detectors/.

CUSTOM utiliza azure/privileged-access/roles/custom-role-excessive.go:24; UNUSED utiliza azure/privileged-access/roles/unused-admin-role.go:36. As cinco verificações TOO_MANY utilizam o Detect() partilhado em azure/privileged-access/roles/too-many-privileged-roles.go:43. Os seus construtores individuais too-many-*-admins.go definem os limiares na linha 17 e as severidades na linha 19. Cada implementação devolve uma constatação mesmo com Count=0; a deteção positiva exige Count>0. Acima do limiar, CUSTOM e TOO_MANY devolvem a contagem completa correspondente, não apenas o excesso.

As cinco entradas TOO_MANY são Info com peso 0 no catálogo, embora os seus construtores emitam High, ou Critical para Privileged Role Administrator. Esta discrepância é preservada explicitamente. Não aumente silenciosamente a pontuação do catálogo nem descreva as severidades em execução como valores do catálogo.

Os limites da recolha afetam a interpretação

O fornecedor revisto combina atribuições ativas com a elegibilidade recolhida utilizando entidade de segurança, função e âmbito (public/internal/providers/azure/client.go:1597, :1626, :1784). O seu inventário de funções combina instâncias incorporadas ativadas com definições personalizadas, mapeando os IDs dessas definições para RoleTemplateID e definindo o seu valor interno IsEnabled=true sem copiar o valor de ativação do Graph (client.go:1500).

As leituras de definições personalizadas são feitas na medida do possível; os caminhos de funções e elegibilidade revistos não implementam ciclos nextLink. Falhas HTTP ou de análise da elegibilidade podem devolver um mapa vazio (client.go:404). Consequentemente, uma recolha de elegibilidade ausente pode produzir um resultado UNUSED aparente ou subcontar as populações TOO_MANY. São observações estáticas do código, não falhas de tenant reproduzidas.

Encerre a auditoria com evidências separadas para a necessidade da definição, a justificação dos detentores e a revogação efetiva. Um resultado sem ultrapassagem de limiares é útil, mas a decisão pela qual se deve responder é se cada permissão e atribuição mantida ainda tem uma finalidade documentada.