Microsoft AZ-500: Gerenciamento de Identidade e Acesso — Guia de estudos

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Faz parte do Microsoft Azure Security Engineer Associate AZ-500 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

O Gerenciamento de Identidade e Acesso (IAM) no Microsoft Azure é centrado no Microsoft Entra ID (anteriormente Azure AD). Ele rege quem pode acessar quais recursos, sob quais condições e com quais privilégios. Uma arquitetura de IAM eficaz minimiza o privilégio permanente, impõe acesso condicional e baseado em risco, e adota autenticação moderna tanto para humanos quanto para workloads, ao mesmo tempo que suporta cenários de colaboração híbrida e externa.

Construções de Identidade e Escopos do Microsoft Entra

• Tenants, usuários e grupos
  • Um tenant representa a fronteira de identidade e a malha de confiança da sua organização. Os usuários podem ser contas de membro ou convidado (B2B). Use grupos de segurança para autorização e grupos do Microsoft 365 para recursos de colaboração; prefira grupos dinâmicos para reduzir o gerenciamento manual de membros.
• Unidades Administrativas (AUs)
  • As AUs permitem que você delegue funções de diretório sobre um subconjunto de usuários/dispositivos (por exemplo, o helpdesk regional só pode gerenciar usuários da Europa). Isso suporta o princípio do menor privilégio para tarefas de diretório.
• Funções de diretório e escopos de atribuição de função
  • As funções de diretório (por exemplo, Global Administrator, User Administrator) se aplicam aos recursos do Microsoft Entra. Defina o escopo das funções de diretório em uma AU sempre que possível para restringir o raio de impacto. A função de Global Administrator é necessária para configurar o Privileged Identity Management (PIM) inicialmente.
• Escopos do controle de acesso baseado em função do Azure (Azure RBAC)
  • O Azure RBAC rege o acesso aos recursos do Azure. Atribua funções no escopo do grupo de gerenciamento, assinatura, grupo de recursos ou recurso. A herança flui para baixo; sempre escolha o escopo mais restrito possível para reduzir o excesso de privilégios.
• Raciocínio operacional
  • Separe as funções de diretório (Entra) do Azure RBAC (autorização de recursos). Use AUs e escopos de RBAC restritos para confinar o alcance administrativo, reduzir oportunidades de movimento lateral e simplificar as revisões de acesso.

Controle de Acesso com Azure RBAC e Menor Privilégio

• Funções internas e menor privilégio
  • Prefira a função interna mais específica que se ajuste à tarefa. Exemplo: conceda acesso somente para pull de imagens de contêiner com AcrPull e acesso para upload/push com AcrPush, em vez da função ampla de Contributor. Para o Key Vault, conceda controle administrativo via RBAC apenas aos administradores do cofre, enquanto usa políticas de acesso granulares para operações específicas de objetos, como o gerenciamento de certificados.
• Herança de atribuição de função
  • Atribua no menor escopo possível. Atribuições em grupos de gerenciamento ou assinaturas são propagadas em cascata; evite direitos amplos e herdados, a menos que seja intencional. Quando precisar de RBAC consistente entre assinaturas, aplique atribuições de função consistentes através do Azure Blueprints (ou alternativas modernas de IaC) em vez de atribuição manual no PIM.
• Atribuições de negação (Deny)
  • As atribuições de negação bloqueiam explicitamente ações, independentemente das atribuições de permissão (allow), e são normalmente criadas por serviços do Azure, como o Azure Policy ou Blueprints. Use-as para impor barreiras de proteção (guardrails) não negociáveis (por exemplo, impedir regras de rede pública em recursos sensíveis).
• Funções personalizadas
  • Quando as funções internas forem muito amplas, defina funções personalizadas com apenas as ações necessárias. Valide através de testes de menor privilégio e revisões de acesso.

{
  "Name": "Storage Blob Reader (TagsBlocked)",
  "IsCustom": true,
  "Description": "Read blobs; no tag write",
  "Actions": [
    "Microsoft.Storage/storageAccounts/blobServices/containers/read",
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
  ],
  "NotActions": [
    "Microsoft.Resources/tags/write"
  ],
  "AssignableScopes": ["/subscriptions/00000000-0000-0000-0000-000000000000"]
}

• Raciocínio operacional
  • O escopo do RBAC e as funções personalizadas reduzem direitos excessivos e a superfície de auditoria. As atribuições de negação codificam restrições de conformidade “rígidas” que não podem ser contornadas por concessões de permissão (allow) equivocadamente amplas, melhorando a resiliência da postura de segurança.

Acesso Privilegiado, Acesso Condicional e Proteção de Identidade

• Privileged Identity Management (PIM)

  • Elegível vs. ativo: atribuições elegíveis não concedem permissões permanentes; os usuários devem ativar Just-In-Time (JIT) para se tornarem ativos. Exija aprovação, justificativa e MFA na ativação; defina durações limitadas e exija referências de ticket para rastreabilidade. Comece descobrindo as funções privilegiadas para entender a exposição atual. Use revisões de acesso periódicas, idealmente com proprietários de recursos ou grupos como revisores, para validar a necessidade contínua.

• Acesso Condicional (CA)

  • As atribuições visam usuários/grupos, identidades de workload, aplicativos em nuvem e ações. As condições incluem risco de login, plataforma/estado do dispositivo, localizações, aplicativos cliente e filtros para dispositivos e aplicativos. Os controles de concessão podem exigir MFA, dispositivos em conformidade ou ingressados no Azure AD híbrido, políticas de proteção de aplicativos ou termos de uso. Os controles de sessão restringem a frequência de login, sessões persistentes e restrições impostas por aplicativos (por exemplo, acesso somente via web para o SharePoint). Use o modo somente relatório (report-only) para validar com segurança o impacto da política antes de aplicá-la. Mantenha exclusões para contas de emergência (break-glass) e implementações em fases para evitar bloqueios de acesso (lockouts).

• Identity Protection

  • O risco do usuário reflete a probabilidade de uma conta estar comprometida; o risco de login reflete a probabilidade de uma sessão específica ser arriscada. Configure políticas para exigir remediação segura:
    • Usuários com credenciais vazadas: trate como risco de usuário Alto; force a redefinição de senha e bloqueie até que seja remediado.
    • Logins de IPs com atividade suspeita: trate no mínimo como risco de login Médio; desafie com MFA ou bloqueie para aplicativos sensíveis.
  • Integre com o CA para adaptar a confiança em tempo real. Monitore o histórico de riscos e a remediação para medir a eficácia.

• Raciocínio operacional

  • O PIM elimina o privilégio permanente e impõe uma ativação forte e auditável. O CA e o Identity Protection aplicam o princípio de confiança zero (zero trust) — verificando cada tentativa de acesso com base no usuário, dispositivo, sessão e risco — reduzindo o sucesso de roubo de credenciais e a repetição de tokens (token replay).

Identidades Híbridas e de Carga de Trabalho

• Opções de identidade híbrida
  • Sincronização de hash de senha (PHS): sincroniza hashes de senha com o Entra ID. Simples e resiliente; não impõe políticas de login on-premises no momento da autenticação.
  • Autenticação de passagem (PTA): valida senhas em DCs on-prem por meio de conectores leves; impõe políticas de senha e restrições de conta on-prem em tempo real, sem o AD FS.
  • Federação (ex: AD FS): transfere a autenticação para um STS on-prem. Use apenas quando necessário para claims complexas ou cenários legados; introduz mais servidores e sobrecarga operacional.
  • Logon único contínuo (Seamless SSO): faz o login de usuários em dispositivos ingressados no domínio dentro da rede corporativa com o mínimo de prompts.
  • Escolha operacional: para impor políticas de senha e restrições de conta on-prem enquanto minimiza servidores, implante PTA e Seamless SSO e também habilite o PHS para resiliência/failover de cenários que não dependem do PTA. A federação por si só aumenta a complexidade e não atende ao objetivo de “minimizar servidores”.
• Autenticação de aplicativos no Azure SQL a partir de dispositivos Windows com ingresso híbrido
  • Use a autenticação integrada do Active Directory para minimizar prompts e aproveitar o Kerberos/SSO quando aplicável.
• Identidades gerenciadas e service principals
  • Identidades gerenciadas (atribuídas pelo sistema ou pelo usuário) são a primeira escolha para cargas de trabalho hospedadas no Azure porque eliminam segredos e rotacionam credenciais automaticamente. Atribua o RBAC de privilégio mínimo à identidade no escopo do recurso.
  • Service principals dão suporte a registros de aplicativos; use credenciais de certificado em vez de segredos de cliente e defina o tempo de vida mais curto possível.
• Federação de identidade de carga de trabalho
  • Use a federação OIDC para permitir que identidades de carga de trabalho externas (ex: GitHub Actions, Kubernetes) obtenham tokens para aplicativos do Entra sem armazenar segredos. Defina as claims de emissor (issuer), sujeito (subject) e público (audience) com precisão para restringir quem pode trocar tokens.

az ad app federated-credential create \
  --id <app-object-id> \
  --parameters '{
    "name":"gh-actions-main",
    "issuer":"https://token.actions.githubusercontent.com",
    "subject":"repo:contoso/api:environment:prod",
    "audiences":["api://AzureADTokenExchange"]
  }'

• Acesso do AKS ao ACR
  • Conceda à identidade gerenciada do cluster AKS a permissão AcrPull no registro de destino usando o fluxo attach-acr, que automatiza o escopo correto e evita atribuições incorretas.

az aks update -n aks-prod -g rg-aks --attach-acr myRegistry

• Raciocínio operacional
  • A combinação PTA+PHS+Seamless SSO impõe controles on-prem em tempo real, mantendo a resiliência da nuvem. Identidades gerenciadas e federação removem segredos estáticos de pipelines e do tempo de execução, fechando caminhos de roubo de credenciais de alta frequência.

Colaboração Externa, Métodos de Autenticação e Acesso a Aplicativos

• Identidades externas e colaboração B2B
  • Use contas de convidado B2B com configurações de acesso entre locatários (cross-tenant), termos de uso e CA direcionado a convidados. Restrinja quem pode convidar e prefira o acesso just-in-time por meio do gerenciamento de direitos.
• Gerenciamento de direitos e pacotes de acesso
  • Agrupe grupos, aplicativos e sites do SharePoint em pacotes de acesso com políticas que definem quem pode solicitar (incluindo usuários externos), fluxos de aprovação, durações de atribuição e revisões de acesso. Para a seleção de revisores, use Proprietários de Grupo (Group Owners) para manter a responsabilidade de negócio com os responsáveis pelos recursos.
• Métodos de autenticação e sem senha (passwordless)
  • Padronize métodos fortes: chaves de segurança FIDO2, Windows Hello for Business e login por telefone com o Microsoft Authenticator. Use o registro combinado de informações de segurança (SSPR + MFA) e imponha a política de registro de MFA para todos os usuários. Habilite o SSPR com writeback para o ambiente local (on-prem), se necessário; exija métodos seguros e limite a fatores gerenciados pela empresa sempre que possível. Desabilite protocolos de autenticação legados/básicos e bloqueie o MFA fraco apenas por SMS onde o risco justificar.
• Microsoft Entra application proxy
  • Publique aplicativos web locais (on-premises) sem aberturas de firewall de entrada. Use grupos de conectores para alta disponibilidade (HA), pré-autenticação com o Entra ID e adicione camadas de CA, conformidade de dispositivo e Identity Protection para confiança zero (zero trust) em aplicativos legados.
• Segurança no registro de aplicativos
  • Exija fluxos de trabalho de consentimento de administrador; limite quem pode criar aplicativos; classifique permissões; prefira permissões de aplicativo somente quando nenhum contexto de usuário for necessário e limite o escopo das APIs ao mínimo. Desabilite a concessão implícita (implicit grant) sempre que possível, exija atribuição para aplicativos empresariais e prefira certificados em vez de segredos (secrets) com rotação automatizada.

az ad app update --id <app-id> --required-resource-access @permissions.json
az ad sp update --id <sp-id> --set appRoleAssignmentRequired=true

• Raciocínio operacional
  • Pacotes de acesso e o app proxy fornecem acesso externo governado e auditável. Métodos fortes e sem senha aumentam a resistência a phishing. Controles rígidos no registro de aplicativos evitam consentimento excessivamente amplo e reduzem a chance de personificação de aplicativo.

Cenário de Problema Prático

A Adobe Inc. precisa conceder a um fornecedor terceirizado acesso administrativo temporário a um subconjunto de recursos do Azure e publicar um aplicativo web legado interno para o fornecedor, aplicando autenticação forte e privilégio permanente zero (zero standing privilege).

1. Definir escopo e modelar o acesso

• Crie um grupo de recursos rg-vendor-ops e mova apenas os recursos necessários para ele. Atribua as funções mínimas do Azure RBAC (por exemplo, Contributor em rg-vendor-ops; Reader em um grupo de recursos de diagnóstico).
• Justificativa: O escopo restrito previne o movimento lateral. A herança de função fica confinada a rg-vendor-ops, contendo o raio de impacto (blast radius).

2. Governar identidade e ativação com o PIM

• Torne os administradores do fornecedor elegíveis, não permanentes, para as funções necessárias; exija aprovação, ID do ticket, MFA na ativação e limite a ativação a 4 horas. Comece executando a função “Descobrir funções privilegiadas” (Discover privileged roles) do PIM para fazer um levantamento (baseline) das atribuições existentes.
• Justificativa: Atribuições elegíveis removem o privilégio permanente. A aprovação e o MFA impõem o acesso JIT alinhado às janelas de suporte e fornecem um controle auditável.

3. Aplicar Acesso Condicional e políticas de risco

• Crie uma política de CA direcionada ao grupo do fornecedor e ao portal do Azure e APIs do ARM, exigindo MFA, dispositivo em conformidade/híbrido ingressado e bloqueando o acesso de locais de risco. Habilite primeiro no modo somente relatório (report-only); depois, aplique. Configure o Identity Protection: bloqueie o Risco de usuário Alto (credenciais vazadas) até a redefinição de senha; exija MFA para Risco de login Médio (IP suspeito).
• Justificativa: O CA vincula o acesso à confiança do dispositivo e ao risco em tempo real. O modo somente relatório evita interrupções durante a implementação. As políticas de risco remediam automaticamente sessões e contas comprometidas.

4. Publicar o aplicativo legado com o Microsoft Entra application proxy

• Implante dois conectores em sub-redes separadas expostas ao fornecedor para alta disponibilidade (HA). Configure a pré-autenticação com o Entra ID, exija atribuição ao aplicativo empresarial e aplique a mesma política de CA. Use pacotes de acesso para conceder aos usuários do fornecedor acesso com prazo definido tanto ao aplicativo empresarial quanto às funções do RG; defina os Proprietários de Grupo (Group Owners) como revisores.
• Justificativa: O app proxy elimina a exposição de entrada e centraliza a autenticação. O gerenciamento de direitos padroniza o onboarding/offboarding e garante revisões periódicas pelos proprietários dos recursos.

5. Proteger credenciais de workload e de aplicativos

• Substitua quaisquer segredos de cliente (client secrets) por credenciais de certificado para entidades de serviço (service principals); para CI/CD, use a federação de identidade de workload em vez de armazenar segredos. Para workloads do AKS que precisam de imagens, anexe o ACR ao cluster para conceder a permissão AcrPull à identidade gerenciada.
• Justificativa: A remoção de segredos estáticos fecha um vetor de violação comum; a federação e as identidades gerenciadas fornecem acesso de privilégio mínimo e com rotação automática.

6. Proteger contas de emergência (break-glass) e monitorar

• Exclua duas contas de emergência (break-glass) do CA, mas proteja-as com senhas longas e aleatórias armazenadas offline. Habilite revisões de acesso trimestralmente e exporte os logs do PIM e do CA para um workspace do Log Analytics com alertas sobre ativações anômalas.
• Justificativa: As contas de emergência evitam o bloqueio do locatário (tenant) enquanto são operacionalmente seguras. O monitoramento contínuo detecta o uso indevido rapidamente, mantendo a conformidade e a prontidão para resposta a incidentes.

Todos os domínios · Arquitetura de Segurança de Rede →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Microsoft →