No exame AZ-305 de Solution Architect, o domínio de Identidade e Gerenciamento de Acesso representa aproximadamente 20–25% de todas as questões. Além de memorizar papéis do RBAC, é necessário projetar quem pode acessar o quê, com qual identidade e em qual escopo. Este guia cobre os conceitos fundamentais do Entra ID, herança de RBAC, Conditional Access, Managed Identity e Privileged Identity Management — os tópicos mais frequentes no exame — com cenários práticos. Seja você iniciante no AZ-305 ou um engenheiro de nuvem experiente, aqui encontrará critérios de decisão aplicáveis imediatamente.
---
Conceitos fundamentais do Entra ID
Microsoft Entra ID (anteriormente Azure Active Directory) é a espinha dorsal do gerenciamento de acesso no Azure. Assim como um crachá determina quais áreas de um prédio você pode acessar, o Entra ID decide quais recursos em nuvem cada identidade pode usar.
Permissão Delegada vs Permissão de Aplicação
A Permissão Delegada (Delegated Permission) significa que um aplicativo age em nome do usuário autenticado. Ele acessa recursos apenas dentro dos escopos que o usuário consentiu explicitamente, usando o Authorization Code Flow. Por exemplo, quando um aplicativo web precisa ler o calendário do usuário conectado, usa Calendars.Read (Delegated).
A Permissão de Aplicação (Application Permission) significa que o aplicativo opera com sua própria identidade, sem nenhum usuário presente. Usa o Client Credentials Flow e o Admin Consent é obrigatório. Quando uma API backend define App Roles e esses papéis são atribuídos como permissões de aplicação a um app cliente, eles aparecem no claim do token de acesso.
Guia de palavras-chave: se aparecer "em nome do usuário" ou "consentimento do usuário," escolha Permissão Delegada. Se aparecer "autenticação entre serviços sem interação do usuário," escolha Permissão de Aplicação.
Administrative Units e administração delegada
Para que os administradores de TI de cada departamento gerenciem apenas os usuários do próprio departamento, atribua o papel User Administrator com escopo na Administrative Unit (AU) correspondente. O papel Helpdesk Administrator não pode criar novos usuários, portanto, se a criação de contas for necessária, selecione User Administrator.
Identidade Híbrida: PHS vs PTA vs AD FS
Password Hash Synchronization (PHS) sincroniza os hashes de senha com o Entra ID, mantendo a autenticação na nuvem mesmo que o AD local fique indisponível. Pass-through Authentication (PTA) encaminha as solicitações de autenticação para um agente local; se a conexão local cair, a autenticação falha.
Dica para o exame: se o requisito for "manter a autenticação na nuvem mesmo durante uma interrupção local," escolha PHS. Se "as senhas não devem ser armazenadas na nuvem," escolha PTA ou AD FS. O Microsoft Entra Connect pode sincronizar múltiplas florestas de AD local em um único tenant do Entra; domínios filhos dentro de uma única floresta são gerenciados por um único agente.
!Identidade híbrida: PHS, PTA e AD FS
Design de RBAC e delegação de permissões
RBAC (Role-Based Access Control) é como dar chaves diferentes para cargos diferentes. As atribuições de papéis do Azure RBAC são herdadas automaticamente de escopos superiores para escopos inferiores.
Atribuir um papel no nível do Management Group se aplica automaticamente a todas as assinaturas e recursos filhos — sem configuração adicional. Grupos aninhados também são suportados, de modo que um papel em um grupo pai se propaga para os membros de grupos filhos.
Limitação importante: as atribuições de papel do RBAC não cruzam os limites do tenant. Para conceder acesso de Reader a cinco assinaturas distribuídas em dois tenants do Entra independentes, atribua no nível do Management Group uma vez por tenant — duas atribuições no total.
Limitação do Contributor: Contributor pode criar, modificar e excluir recursos, mas não possui . Para atribuir papéis a outros usuários, é necessário Owner ou User Access Administrator.
ABAC permite refinar o acesso com base em atributos do recurso (tags, nomes de contêiner) sem alterar os papéis existentes. Atualmente suportado apenas em operações do plano de dados do Azure Blob Storage — Files, Queue e Table Storage não são suportados.
---
Conditional Access e estratégia de MFA
Conditional Access é o motor de políticas Zero Trust que avalia sinais compostos — usuário, dispositivo, localização, aplicativo e nível de risco — e responde com Permitir, Bloquear ou uma solicitação de autenticação adicional.
Forçar o registro de MFA e forçar o login com MFA são coisas diferentes. Forçar o registro de MFA usa a política de registro de MFA do Conditional Access para que os usuários cadastrem um método de MFA. Forçar o login com MFA configura a opção "Exigir MFA" no controle de concessão (Grant), de modo que o acesso só é permitido após a conclusão da autenticação MFA.
Para bloquear BYOD e permitir acesso somente de dispositivos gerenciados, configure a condição "Dispositivo em Conformidade (Compliant Device)." Azure Firewall e NSG não reconhecem o estado de gerenciamento do dispositivo, portanto, sempre use Conditional Access para controle de acesso baseado em dispositivos.
Exigir MFA para administradores que acessam o Azure Portal pode ser resolvido com uma única política que combina grupo de usuários, aplicativo em nuvem (Microsoft Azure Management) e controle de concessão (Exigir MFA).
Segurança de acesso a VM: use Azure Bastion quando precisar de acesso RDP/SSH sem expor um IP público. JIT VM Access abre temporariamente uma porta pública, portanto, se o requisito for "remover a exposição de IP público," escolha Bastion + Conditional Access.
---
Managed Identity e autenticação de serviços
Use Managed Identity quando precisar de autenticação entre serviços do Azure sem armazenar credenciais no código ou arquivos de configuração. A plataforma Azure emite e renova tokens automaticamente, eliminando o gerenciamento de expiração e rotação.
System-assigned Managed Identity tem um ciclo de vida vinculado ao recurso específico do Azure. Quando o recurso é excluído, a identidade é removida automaticamente. User-assigned Managed Identity pode ser compartilhado entre múltiplos recursos.
Dica para o exame: se cada recurso precisar de uma credencial separada, escolha System-assigned. Se múltiplos recursos compartilharem a mesma identidade, escolha User-assigned.
Padrão de integração com Key Vault: atribua o papel "Key Vault Secrets User" à Managed Identity para acessar segredos sem nenhuma alteração no código. Se a autenticação for bem-sucedida, mas as leituras falharem, a etapa de autorização está faltando. A autenticação bem-sucedida da Managed Identity apenas confirma a identidade; ler um segredo requer permissões de Get/List separadamente.
Para obter um token de Managed Identity de dentro de uma VM usando apenas chamadas REST (sem SDK), use o Azure Instance Metadata Service (IMDS).
---
Tabela comparativa de serviços
| Serviço | Uso principal | Licença | Característica principal | |---------|---------------|---------|--------------------------| | Entra ID PIM | Gerenciamento de papéis privilegiados JIT | P2 | Atribuição Eligible, fluxo de aprovação, log de auditoria | | Access Reviews | Revisão periódica de direitos de acesso | P2 | Agendamento recorrente, autorrevisão, remoção automática sem resposta | | Entitlement Management | Acesso temporário para usuários externos | P2 | Pacotes de acesso, expiração automática, solicitação self-service | | Conditional Access | Motor de políticas de acesso condicional | P1 | Avaliação de sinais compostos: usuário/dispositivo/localização/app | | Application Proxy | Publicar apps locais sem VPN | P1 | Proxy reverso, suporte KCD, sem mudanças no código | | Entra Domain Services | Domínio LDAP/Kerberos totalmente gerenciado | SKU separado | Sem conectividade local, compatível com apps legados |
---
Critérios de seleção frequentemente confundidos no exame
Critérios de decisão baseados em padrões reais de cenários do exame.
PIM vs Access Reviews — PIM controla quando um papel é ativado; Access Reviews determina periodicamente quem deve continuar possuindo um papel. Quando ambos os requisitos aparecem juntos, escolha PIM + Access Reviews.
Application Proxy vs Azure Bastion — Application Proxy publica aplicativos web baseados em HTTP/HTTPS na internet sem VPN. Azure Bastion é exclusivamente para acesso RDP/SSH a VMs. Para acesso SSO a um app IWA local sem VPN, escolha Application Proxy.
Entra B2B vs B2C — Se funcionários de parceiros já possuem contas do Entra ID, use o convite de convidado B2B. Se o público-alvo são consumidores ou usuários com contas sociais, escolha B2C.
Entra Domain Services vs Entra Connect — Se um app legado usa autenticação LDAP e não deve haver conectividade local, escolha Entra Domain Services. Se o objetivo é sincronizar usuários de AD local no Entra ID, use Entra Connect.
Seleção de fluxo OAuth 2.0 — Quando um aplicativo web chama uma API backend em nome de um usuário conectado, use o On-Behalf-Of (OBO) Flow. Para chamadas entre serviços sem usuário, use Client Credentials Flow. Para um usuário fazendo login diretamente em um app, use Authorization Code Flow.
---
Dicas práticas para aplicação no mundo real
Converta atribuições de papéis permanentes para atribuições Eligible (PIM) sempre que possível. Exigir ativação sob demanda reduz o risco de abuso de privilégios. Minimize o número de atribuições usando grupos, levando em conta o limite de 4.000 atribuições de papel por assinatura.
Aproveite ao máximo a hierarquia de Management Groups. À medida que o número de assinaturas cresce, atribuir papéis individualmente a cada uma se torna ineficiente. Atribuir um papel uma única vez no nível do Management Group se propaga automaticamente para todas as assinaturas filhas.
Automatize o gerenciamento do ciclo de vida de usuários externos com pacotes de aces