Microsoft AZ-204: Autenticação, Autorização e Segurança do Azure — Guia de estudos

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

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

Visão Geral

A autenticação e a autorização no Azure dependem da Microsoft Identity Platform, que emite tokens para identidades (usuários, aplicações, workloads) e impõe o acesso a APIs e recursos. As aplicações se integram por meio do OAuth 2.0 e do OpenID Connect, adquirem tokens usando a MSAL e solicitam permissões declaradas nos registros de aplicação (app registrations) do Azure AD. Workloads em execução no Azure podem eliminar completamente as credenciais usando identidades gerenciadas (managed identities) e utilizar o Azure RBAC para acessar serviços como o Key Vault, Storage e Microsoft Graph. O gerenciamento de segredos se concentra no Azure Key Vault, com uma separação clara entre o acesso ao plano de dados (data-plane) do cofre e o controle do plano de gerenciamento (management-plane), e com fortes garantias de recuperação por meio da exclusão reversível (soft delete) e da proteção contra exclusão definitiva (purge protection). Para o armazenamento, as Shared Access Signatures (SAS) fornecem delegação com escopo definido e tempo limitado para clientes sem expor as chaves da conta.

Microsoft Identity Platform, OAuth 2.0, MSAL e App Registrations

A Microsoft Identity Platform suporta múltiplos fluxos OAuth 2.0 otimizados para diferentes tipos de aplicação:

• Fluxo de código de autorização: O padrão para aplicações web, SPAs e aplicações nativas. Clientes públicos devem usar PKCE para proteger o código de autorização. As aplicações redirecionam os usuários para o endpoint de autorização, recebem um código de autorização no URI de redirecionamento e, em seguida, o trocam no endpoint de token por um access token (e, opcionalmente, um refresh token). Para SPAs, o fluxo de código de autorização + PKCE substitui o fluxo implícito legado e mitiga o vazamento de tokens.
• Fluxo de credenciais de cliente: Usado por daemons e serviços server-to-server sem um usuário. A aplicação solicita tokens usando uma asserção de cliente (certificado) ou um client secret. Apenas permissões de aplicação (app roles) estão disponíveis aqui, e a maioria delas exige consentimento do administrador. Este fluxo usa o escopo /.default para solicitar o conjunto de permissões de aplicação configuradas estaticamente.
• Fluxo de código de dispositivo: Projetado para dispositivos ou ambientes sem um navegador embutido. A aplicação obtém um código de usuário e uma URL de verificação da plataforma de identidade, o usuário se autentica em um dispositivo separado e a aplicação sonda o endpoint de token. Permissões delegadas se aplicam porque um usuário faz login.
• Fluxo de concessão implícita: Historicamente usado por SPAs para receber tokens diretamente do endpoint de autorização. Agora é desaconselhado em favor do fluxo de código de autorização com PKCE. Se usado, um URI de redirecionamento ainda é necessário durante o registro da aplicação.

A MSAL (Microsoft Authentication Library) fornece aquisição de tokens consistente entre linguagens e plataformas. Aplicações de cliente público (desktop, mobile, SPA) usam AcquireTokenInteractive e AcquireTokenSilent para obter e armazenar tokens em cache; aplicações nativas também usarão AcquireTokenByDeviceCode para o fluxo de código de dispositivo e AcquireTokenByAuthorizationCode para o resgate do código de autorização em contextos de cliente confidencial. Clientes confidenciais (aplicações web/APIs/daemons) adquirem tokens com AcquireTokenForClient ao usar credenciais de cliente e AcquireTokenOnBehalfOf para cenários OBO (On-Behalf-Of), onde uma API chama outras APIs (downstream) com o contexto delegado de um usuário.

O cache de tokens é parte integrante da MSAL: ele armazena access tokens e refresh tokens indexados por conta, cliente e escopo, permitindo que o AcquireTokenSilent evite prompts interativos desnecessários. Aplicações web e APIs executando em múltiplas instâncias devem persistir e proteger o cache de tokens usando um armazenamento compartilhado e criptografado (por exemplo, um cache distribuído com criptografia adequada em repouso e em trânsito). Hooks de serialização de cache na MSAL permitem a persistência segura. Escopos (Scopes) identificam as permissões que uma aplicação está solicitando. Para permissões delegadas, solicite os escopos mínimos e específicos do recurso (ex: https://graph.microsoft.com/User.Read). Para credenciais de cliente, solicite o /.default baseado no recurso, que mapeia para as permissões de aplicação concedidas estaticamente à aplicação (ex: scope = https://graph.microsoft.com/.default). Use o consentimento incremental para solicitar escopos progressivamente e reduzir o atrito.

Os registros de aplicação (app registrations) no Azure AD definem a identidade da aplicação, credenciais, URIs de redirecionamento e permissões. Permissões delegadas exigem um usuário autenticado e muitas vezes podem ser consentidas pelos próprios usuários para seus dados; permissões de aplicação são concedidas à própria aplicação e quase sempre exigem que um administrador consinta, porque se aplicam a todo o tenant ou de forma ampla. Aplicações que expõem APIs declaram escopos (para permissões delegadas) e app roles (para permissões de aplicação) em “Expor uma API”. Configure o acesso como single-tenant ou multi-tenant dependendo dos limites de confiança (trust boundaries) e use certificados em vez de client secrets para credenciais mais fortes e rotação mais fácil.

O Microsoft Graph usa a mesma emissão de tokens. Autentique-se com a MSAL visando o recurso do Graph e solicite escopos de menor privilégio. Endpoints comuns incluem:

• GET https://graph.microsoft.com/v1.0/me para o perfil do usuário com tokens delegados (ex: User.Read)
• GET https://graph.microsoft.com/v1.0/users e /groups para objetos do diretório (requer permissões delegadas ou de aplicação apropriadas, como User.Read.All ou Group.Read.All)
• GET https://graph.microsoft.com/v1.0/sites ou /drives para operações do SharePoint/OneDrive Ao usar credenciais de cliente, solicite o escopo /.default e garanta que o consentimento do administrador exista para as permissões de aplicação necessárias. Escolha a autoridade (authority) correta (específica do tenant versus comum/organizações) para controlar onde os usuários podem se autenticar e onde os tokens podem ser gerados (minted).

Identidades Gerenciadas e Acesso Seguro a Recursos do Azure, além de Referências do Key Vault

Identidades gerenciadas para recursos do Azure eliminam segredos ao permitir que o Azure gerencie as credenciais de entidades de serviço (service principal). Identidades gerenciadas atribuídas pelo sistema são vinculadas 1:1 a um recurso (App Service, Function App, VM, VMSS, Logic App, etc.) e compartilham seu ciclo de vida; quando o recurso é excluído, a identidade também é excluída. Identidades gerenciadas atribuídas pelo usuário são criadas como recursos autônomos do Azure que podem ser anexados a múltiplos recursos de computação e existem independentemente do ciclo de vida de qualquer carga de trabalho individual. Este modelo suporta o reuso de identidades e a separação de responsabilidades.

Para acessar recursos do Azure com uma identidade gerenciada, conceda a ela a função do Azure RBAC apropriada no escopo correto:

• Para o plano de dados (data plane) do Azure Storage com o Azure AD, atribua funções como Storage Blob Data Reader/Contributor no escopo de uma conta de armazenamento, contêiner ou RG/assinatura.
• Para o Key Vault (modelo de plano de dados RBAC), atribua funções como Key Vault Secrets User ou Key Vault Crypto Officer.
• Para o Microsoft Graph via permissões de aplicativo, as identidades gerenciadas podem chamar APIs downstream somente após o registro de um aplicativo ser associado. Use a federação de identidade de carga de trabalho (workload identity federation) ou configure as permissões do aplicativo empresarial e o consentimento do administrador conforme necessário.

Em tempo de execução, use o Serviço de Metadados de Instância (IMDS) em VMs ou o endpoint gerenciado do App Service para obter tokens; SDKs como o DefaultAzureCredential do Azure Identity usarão automaticamente o endpoint da identidade gerenciada quando disponível. Isso remove a necessidade de armazenar segredos e suporta a rotação pela plataforma.

Referências do Key Vault no App Service e no Azure Functions permitem a recuperação segura de segredos para as configurações do aplicativo sem alterações no código. No valor de uma configuração de aplicativo, use a sintaxe de referência @Microsoft.KeyVault(SecretUri=https://{vault-name}.vault.azure.net/secrets/{name}/{version}). A plataforma resolve a referência usando a identidade gerenciada do aplicativo na inicialização e a atualiza periodicamente. Garanta que a identidade gerenciada tenha a permissão Get para segredos por meio das políticas de acesso do Key Vault ou da função Key Vault Secrets User ao usar o modelo de plano de dados RBAC. As referências do Key Vault são ideais para valores de configuração que nunca devem ser armazenados em texto simples no repositório de configuração do aplicativo e removem a lógica de manipulação de segredos do código da aplicação.

Azure Key Vault: Segredos, Chaves, Certificados e Controle de Acesso

O Azure Key Vault armazena três tipos de objetos:

• Segredos (Secrets): Strings opacas como senhas, strings de conexão ou chaves de API. São versionados; os clientes normalmente realizam operações Get e Set.
• Chaves (Keys): Chaves criptográficas (RSA, EC) usadas para operações de assinar/verificar, criptografar/descriptografar e encapsular/desencapsular (wrap/unwrap). O material da chave é protegido pelo serviço com suporte de HSM; os clientes chamam operações de criptografia através do serviço em vez de exportar o material da chave privada.
• Certificados (Certificates): Objetos X.509 com gerenciamento de ciclo de vida, opcionalmente integrados com CAs parceiras. Os certificados são materializados como um certificado mais um segredo correspondente (PFX) e, opcionalmente, uma chave gerenciada.

A exclusão reversível (soft delete) está ativada por padrão, preservando objetos excluídos por uma janela de retenção. Habilite a proteção contra limpeza (purge protection) para impedir a exclusão irreversível dentro do período de retenção e para impor garantias de recuperação (frequentemente um requisito de retenção de 90 dias). Combine a exclusão reversível e a proteção contra limpeza para atender a políticas de recuperação rigorosas. Além disso, proteja o acesso de rede ao cofre com endpoints privados e desabilite o acesso à rede pública sempre que possível.

O controle de acesso pode usar as políticas de acesso legadas do cofre ou o Azure RBAC para o plano de dados (data plane). As políticas de acesso são configuradas por cofre e concedem permissões explícitas (Get, List, Set, Sign, Wrap) a entidades de segurança (principals); elas não são herdadas e podem se tornar operacionalmente pesadas em escala. O modelo de plano de dados RBAC usa funções do Azure (ex: Key Vault Administrator, Key Vault Secrets Officer, Key Vault Secrets User, Key Vault Crypto Officer) e suporta escopo no nível de assinatura, grupo de recursos ou cofre, com auditoria integrada ao Azure RBAC. Escolha um modelo; se o RBAC estiver habilitado para o plano de dados, as políticas de acesso são ignoradas. As operações do plano de gerenciamento (management plane) (criação/atualização do cofre) sempre usam o Azure RBAC.

Integre o Key Vault com aplicações usando os SDKs do Azure (ex: SecretClient, KeyClient, CertificateClient) e o DefaultAzureCredential. Prefira identidades gerenciadas para autenticação, evite incorporar credenciais e implemente políticas de repetição (retry) e limitação (throttling) ao chamar as APIs do Vault.

SAS do Azure Storage e Políticas de Acesso Armazenadas

As Shared Access Signatures (SAS) delegam acesso refinado e por tempo limitado ao Azure Storage sem revelar as chaves da conta:

• SAS de Delegação de Usuário (somente Blob): Suportada pelo Azure AD. A aplicação obtém uma chave de delegação de usuário do serviço Blob usando credenciais do Azure AD e, em seguida, cria tokens SAS para os clientes. Esta é a abordagem mais segura para cenários centrados no usuário, pois evita o uso de chaves da conta e se alinha com a autorização baseada em função (role-based).
• SAS de Serviço: Com escopo para um recurso específico (blob, contêiner, mensagem de fila, entidade de tabela, arquivo). Assinada com uma chave da conta. Suporta permissões como leitura, escrita, adição, criação, exclusão, listagem, definição de imutabilidade e tags, dependendo do serviço.
• SAS de Conta: Escopo mais amplo sobre múltiplos serviços (Blob, Queue, Table, File) e tipos de recursos. Use com moderação devido ao amplo raio de impacto.

Os tokens SAS incluem restrições como tempo de expiração (se), tempo de início (st), permissões (sp), intervalos de IP (sip), protocolos permitidos (spr), recurso assinado (sr) e, quando vinculados a uma política de acesso armazenada, um identificador assinado (si). Siga o princípio do menor privilégio, concedendo apenas as permissões necessárias, mantendo as expirações curtas e aplicando HTTPS (spr=https). Prefira a SAS de delegação de usuário sempre que possível; caso contrário, use uma SAS de serviço com uma política de acesso armazenada para permitir a revogação.

As políticas de acesso armazenadas residem em contêineres, compartilhamentos de arquivos, filas ou tabelas e definem um conjunto reutilizável de restrições (permissões, início, expiração). Ao criar uma SAS, referencie a política por seu identificador. Isso permite a revogação centralizada ou o ajuste do escopo sem a necessidade de reemitir todos os tokens SAS; atualizar ou excluir a política afeta imediatamente todos os tokens SAS vinculados a ela. Rotacione as chaves da conta regularmente se SAS de serviço ou de conta forem usadas e monitore o uso por meio das configurações de diagnóstico e dos logs do Azure Monitor.

Cenário de Problema Prático

A Adobe está implementando um portal de processamento de mídia multi-tenant no Azure. Os clientes fazem login com seus próprios tenants do Microsoft Entra ID, fazem upload de arquivos de mídia grandes diretamente para o Blob storage e acompanham o status do processamento. A solução deve evitar o armazenamento de segredos, centralizar permissões e garantir a recuperabilidade de segredos por pelo menos 90 dias.

1. Registrar aplicações no Microsoft Entra ID:

   • Crie uma SPA para a UI do portal e um cliente confidencial para a API de backend. Exponha escopos de API para acesso delegado e defina funções de aplicativo (app roles) para trabalhos em segundo plano. Configure a SPA para usar o fluxo de código de autorização + PKCE com URIs de redirecionamento exatos. Isso alinha cada cliente com o fluxo OAuth correto e impõe limites de consentimento de menor privilégio.

2. Implementar a MSAL na SPA e no backend:

   • A SPA adquire tokens para a API de backend usando

undefined

/

undefined

com consentimento incremental. O backend usa

undefined

para chamar o Microsoft Graph e ler o perfil básico do usuário conectado. Isso preserva o contexto do usuário de ponta a ponta e minimiza as solicitações de login por meio do cache de tokens.

3. Habilitar identidades gerenciadas atribuídas pelo sistema no App Service (API) e no Azure Functions (processadores de mídia):

   • Atribua as funções Storage Blob Data Contributor no contêiner de mídia e Key Vault Secrets User no cofre. As identidades gerenciadas eliminam a proliferação de segredos e permitem que a plataforma rotacione as credenciais automaticamente, ao mesmo tempo que habilitam o acesso seguro ao Storage e ao Key Vault via Azure RBAC.

4. Configurar o Azure Key Vault com plano de dados RBAC, soft delete (exclusão reversível) e proteção contra exclusão definitiva (purge protection):

   • Armazene certificados de assinatura para asserção do backend, chaves de API de terceiros e quaisquer segredos de conexão que não possam ser substituídos pelo AAD. Aplique a proteção contra exclusão definitiva junto com a exclusão reversível para garantir a recuperação por 90 dias. O RBAC simplifica a auditoria e escala entre ambientes em comparação com as políticas de acesso por cofre.

5. Usar referências do Key Vault para configuração:

   • Referencie segredos nas configurações do App Service e do Functions usando

undefined

. A plataforma resolve e atualiza os valores com a identidade gerenciada, eliminando alterações no código e impedindo que segredos sejam armazenados em texto plano na configuração.

6. Delegar uploads diretos do navegador com SAS:

   • O backend emite tokens SAS de delegação de usuário para acesso de curta duração e somente escrita a um caminho de blob específico, com escopo por IP e HTTPS. Para ferramentas de lote operacionais, crie uma SAS de serviço vinculada a uma política de acesso armazenada no contêiner para que os tokens possam ser revogados centralmente, atualizando ou excluindo a política. Isso permite uploads de alta taxa de transferência pelo cliente sem expor as chaves da conta e suporta a revogação de emergência.

7. Integrar o Microsoft Graph minimamente:

   • Solicite https://graph.microsoft.com/User.Read na SPA para exibição do perfil e use https://graph.microsoft.com/.default no backend se alguma permissão de aplicativo for necessária (com consentimento prévio do administrador). Usar /.default garante que o backend respeite as permissões de aplicativo concedidas centralmente e evita a solicitação excessiva de escopos em tempo de execução.

Este design usa o fluxo de código de autorização + PKCE para proteger a SPA, o fluxo OBO (On-Behalf-Of) para preservar o contexto do usuário nos serviços subsequentes, identidades gerenciadas e RBAC para eliminar segredos, o Key Vault com fortes garantias de recuperação, referências do Key Vault para higiene da configuração, o Graph com escopos de menor privilégio e SAS com políticas de acesso armazenadas para uploads seguros e revogáveis pelo cliente.

← Soluções de Contêineres do Azure · Todos os domínios · Azure API Management →

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

Navegar Microsoft →