APRENDER. PRATICAR. EVOLUIR.Definir o acesso que o trabalho exige
Num projeto fictício, uma equipa APS precisa de intervir num resource group durante uma janela de suporte. Antes de configurar PIM, identifica a pessoa, o papel, o âmbito e a operação permitida. A elegibilidade oferece um caminho para pedir ativação; não equivale a acesso ativo permanente. Define como será reconhecido o sucesso do pedido, quem aprova, quanto dura a ativação e como se testa o fim do acesso. O ticket deve descrever a operação de negócio que justifica a intervenção. Um ecrã que mostra a atribuição não demonstra que a aplicação aceita apenas as ações pretendidas.
Separar herança de permissões e políticas
Um papel Azure concedido num âmbito superior pode aplicar-se aos recursos inferiores. As políticas PIM de ativação têm outra regra: são definidas por papel e recurso, sem herança automática das definições da subscrição para o resource group. Se existem duas atribuições elegíveis distintas, o ensaio precisa de usar a atribuição e o âmbito que a pessoa realmente vai ativar. Configurar aprovação na subscrição não prova aprovação no grupo. Mantém uma tabela com âmbito, papel, identificação da política, aprovadores e resultado observado. Repete a verificação quando o projeto cria um novo caminho de acesso ou muda a organização dos recursos.
Inspecionar todos os caminhos de concessão
Azure RBAC combina permissões de atribuições aplicáveis. Acrescentar Reader num resource group não retira um Contributor ativo herdado da subscrição. Da mesma forma, terminar uma pertença PIM não remove uma atribuição direta independente. No modelo didático desta aula, Ana pode exportar através do grupo Operação e através de uma concessão direta. Remover apenas o grupo deixa a segunda via. O modelo executável representa permissões explícitas e âmbitos por prefixo, sem reproduzir denies, condições, ações de dados, tokens ou todo o motor Azure. Usa-o para aprender a procurar caminhos residuais; valida a autorização real no serviço e no âmbito concretos.
Confirmar o que os controlos de ativação provam
Exigir uma referência de ticket no PIM não valida automaticamente esse número numa ferramenta de mudanças. O processo precisa de demonstrar que o pedido existe, está aprovado e abrange a ação concreta. Também a ausência de novo prompt não prova ausência de MFA: uma sessão pode já satisfazer o requisito. Consulta a política e a evidência de autenticação antes de concluir falha. Para a passagem de turno, regista pedido, aprovação, momento de ativação e âmbito. Um colega deve conseguir relacionar esses registos com a intervenção autorizada, sem interpretar texto livre ou um ecrã de sucesso como aprovação de negócio.
Distinguir ativação e utilização posterior
Quando se exige authentication context, prepara e valida a política Conditional Access aplicável antes de o associar ao PIM. O mecanismo de recurso para política ausente não cobre uma política em Report-only, desligada ou que exclua a pessoa. Além disso, cumprir uma condição de dispositivo na ativação não garante que todas as utilizações posteriores do papel acontecem no mesmo dispositivo. O desenho precisa de políticas adequadas ao acesso que se pretende proteger. Num piloto, testa a ativação e a operação posterior como momentos diferentes, com contas de teste e recuperação preparada. Regista resultados observados sem prometer enforcement fora do âmbito configurado.
Gerir Member e Owner como funções distintas
PIM for Groups permite ativar pertença ou ownership. Cada grupo tem políticas próprias para Member e Owner; rever apenas a aprovação de Member deixa a outra função por verificar. No nosso cenário, o owner administra a continuidade do grupo enquanto a pertença suporta acesso a uma aplicação. Esses papéis não devem ser tratados como equivalentes. Mapeia também quem pode alterar o grupo por outras interfaces: PIM não torna invisíveis nem impossíveis outras vias administrativas autorizadas. Na aceitação, testa a função necessária e inspeciona o estado efetivo. Um nome de grupo semelhante não significa que as políticas ou os privilégios sejam iguais.
Planear a saída do último owner
Suponhamos que A é owner ativo e B tem ownership elegível. B ativa; depois A é removido. B torna-se o último owner ativo e a sua desativação pode não se concluir, porque Entra não permite remover o último owner. A documentação descreve tentativas durante até trinta dias, sem garantir remoção se a condição persistir. O plano de saída deve nomear um sucessor ativo autorizado e confirmar o resultado da desativação. Não basta aguardar a hora prevista. Conserva continuidade do grupo e evita eliminar um objeto com dependências apenas para encerrar rapidamente uma pendência de acesso.
Provar revogação no consumidor
A pertença pode desaparecer do diretório enquanto a aplicação conserva uma sessão ou decisão em cache. Uma concessão direta também pode continuar válida. Se o objetivo é retirar exportação, verifica o estado de identidade, os caminhos alternativos e uma tentativa funcional controlada. Não uses um TTL universal inventado: o comportamento depende da aplicação. O handover deve incluir evidência de remoção, resultado do teste e tratamento de sessões segundo o procedimento suportado. Esta aula fornece cenários e modelos locais; não executa PIM, altera tenants ou comprova revogação num serviço real. Um ensaio autorizado em ambiente isolado continua necessário para validar o desenho.
Ana tem exportação por grupo e por atribuição direta. Às 18:00 termina a pertença PIM. O teste continua a passar pela via direta; eliminar apenas a pertença não satisfaz o critério de retirar exportação.
Armadilhas comuns
Herança de permissões como herança de políticas; Reader como deny; referência de ticket como validação; fim de ativação como perda instantânea de todas as permissões; último owner sem sucessor.
Tópicos relacionados: Conditional Access · Revisões de acesso · Passagem para suporte
Verifica a política no âmbito correto, todos os caminhos de concessão e o resultado no consumidor antes de aceitar ativação ou revogação.
Referência: PIM Azure resource role settings · SC-300 objectives effective 2026-04-27; product documentation reviewed 2026-10-01; 2026-10-28 English update compared separately