Fundamentação Teórica: Interpret access assignments

1. Intuição Inicial

Imagine que você é o novo responsável de segurança de uma empresa e precisa responder a uma pergunta simples: "O que exatamente a Ana pode fazer neste servidor?". A resposta não é óbvia. A Ana pode ter recebido um papel diretamente, pode ter herdado permissões porque é membro de um grupo, e esse grupo pode ter recebido um papel em um escopo acima do servidor. Além disso, ela pode ter dois papéis que se combinam.

Interpretar atribuições de acesso é a habilidade de, dado um usuário e um recurso, responder com precisão: quais permissões efetivas esse usuário possui, de onde elas vêm e por quê. Não basta saber que existe uma atribuição; é preciso saber ler o quadro completo.

Nos módulos anteriores aprendemos a criar usuários, grupos, papéis e atribuições. Este módulo é sobre ler e interpretar o que foi criado, entendendo como as peças se combinam para produzir o acesso efetivo.

2. Contexto

A capacidade de interpretar atribuições de acesso é central para três atividades críticas do dia a dia de um administrador Azure:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

O AZ-104 avalia especificamente essa habilidade porque ela integra todos os conceitos anteriores: entender a hierarquia de escopos, como papéis são definidos, como grupos propagam permissões e como múltiplas atribuições se combinam.

3. Construção dos Conceitos

3.1 As Cinco Fontes de Acesso

Quando você olha para as permissões de um usuário em um recurso, o acesso pode vir de cinco fontes distintas. Entender cada uma é o primeiro passo para interpretar corretamente:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

A permissão efetiva é a união de F1 + F2 + F3 + F4, menos qualquer Deny Assignment (F5).

3.2 Os Três Tipos de Atribuição no Portal

Ao visualizar atribuições de papel em qualquer recurso no portal, você verá atribuições classificadas em três tipos:

Tipo	O que significa	Como identificar
Direct	Atribuição feita diretamente neste escopo para este usuário/grupo	Ícone de usuário, escopo = o recurso atual
Inherited	Atribuição feita em um escopo pai (assinatura, MG, etc.) que se propaga até aqui	Ícone de seta para baixo, escopo = escopo pai
Group	O usuário é membro de um grupo que tem uma atribuição neste ou em um escopo pai	Ícone de grupo

Na prática, uma atribuição pode ser ao mesmo tempo "Inherited" e "Group": o usuário herda uma permissão porque é membro de um grupo que recebeu um papel em um escopo pai.

3.3 A Regra da Aditividade

Como visto anteriormente, permissões no Azure são aditivas: quando um usuário tem múltiplas role assignments (diretamente ou via grupos, em qualquer escopo), todas as permissões se somam.

Exemplo concreto:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

O usuário tem Reader + Contributor. Como Contributor inclui tudo que Reader inclui e mais, o resultado efetivo é Contributor. A aditividade significa que a permissão mais ampla prevalece, mas apenas porque as permissões se somam, não porque uma "sobrescreve" a outra.

3.4 Deny Assignments: A Exceção Absoluta

Deny Assignments têm precedência sobre qualquer permissão, independentemente de como foi concedida. Mesmo que um usuário seja Owner de uma assinatura, um Deny Assignment pode bloquear uma ação específica.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Deny Assignments são criados por Azure Blueprints (ao aplicar locks em recursos gerenciados), Azure Managed Applications e Azure Lighthouse. O administrador comum não pode criar Deny Assignments diretamente, mas precisa saber interpretá-los quando aparecem.

3.5 A Diferença entre Actions e DataActions na Interpretação

Uma fonte de confusão frequente: ter permissão para gerenciar um recurso não significa ter permissão para acessar os dados dentro do recurso.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Ao interpretar o acesso de um usuário a um Storage Account, você precisa verificar separadamente:

O que ele pode fazer no plano de controle (gerenciar o recurso, ver configurações)
O que ele pode fazer no plano de dados (ler, escrever ou deletar os dados armazenados)

Papéis que começam com nomes como Storage Blob Data Reader, Key Vault Secrets User, Queue Data Contributor são papéis de plano de dados (DataActions). Papéis genéricos como Contributor ou Storage Account Contributor são predominantemente de plano de controle.

4. Visão Estrutural

O Processo Completo de Interpretação

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Cenário Completo de Interpretação

Vamos construir um cenário real e interpretar o acesso passo a passo.

Configuração do ambiente:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Membros dos grupos:

Grupo-Auditoria: Pedro, Carlos
Grupo-DevOps: Ana, Bruno
Grupo-Ops: Carlos
Grupo-Analytics: Pedro

Pergunta: O que Ana pode fazer na VM alpha-web-01 e no Storage alphalogs?

Interpretação para Ana na VM alpha-web-01:

Fonte da permissão	Escopo	Papel	Tipo
Grupo-DevOps	Subscription	Contributor	Herdada via grupo
Direto para Ana	RG App-Alpha	Reader	Herdada de escopo pai da VM
Direto para Ana	VM alpha-web-01	Virtual Machine Admin Login	Direta

Permissão efetiva na VM alpha-web-01:

Contributor (via Grupo-DevOps da Sub): pode criar, modificar, excluir qualquer recurso no RG, incluindo a VM
Reader (direto no RG): subconjunto do Contributor, redundante
Virtual Machine Admin Login (direto na VM): pode fazer login na VM com privilégios de administrador via Azure AD

Resultado: Ana tem permissões de Contributor sobre a VM (gerenciamento) E pode fazer login como administrador nela.

Interpretação para Ana no Storage alphalogs:

Fonte da permissão	Escopo	Papel	Tipo
Grupo-DevOps	Subscription	Contributor	Herdada via grupo
Direto para Ana	RG App-Alpha	Reader	Herdada do RG

Permissão efetiva no Storage alphalogs:

Contributor (via Grupo-DevOps): pode gerenciar o Storage Account (criar containers, ver chaves de acesso, modificar configurações), mas NÃO pode ler dados dos blobs (Contributor não inclui DataActions de blob)
Reader (do RG): subconjunto, redundante
Storage Blob Data Reader: esse papel está atribuído ao Grupo-Analytics, não a Ana. Ana não é membro do Grupo-Analytics.

Resultado: Ana pode gerenciar o Storage Account, mas não pode ler os dados dos blobs diretamente via Azure RBAC. Se ela quiser ler os blobs, precisaria usar as chaves de acesso do storage (que ela pode ver como Contributor) ou ter o papel de Storage Blob Data Reader atribuído a ela ou a um grupo do qual faça parte.

5. Funcionamento na Prática

Ferramenta "Check Access" no Portal

A forma mais direta de interpretar o acesso de um usuário específico é a ferramenta Check Access disponível na aba IAM de qualquer recurso:

Caminho: [Recurso] > Access control (IAM) > Check access > [buscar usuário ou grupo]

O resultado mostra:

Todos os papéis atribuídos que afetam aquele usuário naquele escopo
O tipo de cada atribuição (direta, herdada, via grupo)
O escopo de origem de cada atribuição

Comportamento importante: a ferramenta Check Access mostra a combinação de todas as fontes, mas não expande automaticamente os grupos para mostrar por qual grupo o usuário herda uma permissão. Para isso, é necessário investigar a associação ao grupo separadamente.

Visualização da Aba "Role Assignments"

Na aba Role assignments de um recurso, você pode filtrar e interpretar:

Filtro disponível	Para que serve
Type: Direct	Ver apenas o que foi atribuído explicitamente neste escopo
Type: Inherited	Ver apenas o que vem de escopos superiores
Scope: This resource	Atribuições diretas neste recurso específico
Scope: Inherited	Atribuições vindas de sub, MG, etc.

Um erro comum de leitura: ver apenas as atribuições diretas e concluir que "não há acesso" quando o acesso real vem de herança.

6. Formas de Implementação

6.1 Portal do Azure: Check Access

Quando usar: diagnóstico rápido do acesso de um usuário específico a um recurso específico.

[Recurso] > Access control (IAM) > Check access

Vantagens: visual e imediato, mostra tipo e escopo de origem de cada atribuição.

Limitações: mostra o usuário em relação a um recurso por vez. Para uma visão de todos os acessos de um usuário no tenant, é necessário PowerShell ou Graph API.

6.2 Azure CLI

Verificar acesso de um usuário a um recurso específico, incluindo herança e grupos:

az role assignment list \
  --assignee joao.silva@contoso.com \
  --scope "/subscriptions/<sub-id>/resourceGroups/rg-producao/providers/Microsoft.Compute/virtualMachines/vm-prod-01" \
  --include-inherited \
  --include-groups \
  --output table

Verificar acesso a um Resource Group inteiro:

az role assignment list \
  --assignee joao.silva@contoso.com \
  --resource-group rg-producao \
  --include-inherited \
  --include-groups \
  --output table

Verificar Deny Assignments:

az role assignment list \
  --assignee joao.silva@contoso.com \
  --scope "/subscriptions/<sub-id>/resourceGroups/rg-producao" \
  --include-inherited \
  --include-groups \
  --include-deny-assignments \
  --output table

Ponto crítico: --include-groups é essencial para uma interpretação completa. Sem ele, atribuições que chegam via associação a grupos não aparecem, e a leitura ficará incompleta.

6.3 PowerShell

Visão completa do acesso de um usuário a um escopo:

$user = "ana@contoso.com"
$scope = "/subscriptions/<sub-id>/resourceGroups/rg-producao"

Get-AzRoleAssignment `
  -SignInName $user `
  -Scope $scope `
  -ExpandPrincipalGroups |
  Select-Object DisplayName, RoleDefinitionName, Scope, ObjectType |
  Format-Table -AutoSize

O parâmetro -ExpandPrincipalGroups é o equivalente do --include-groups da CLI: ele expande os grupos do usuário para mostrar atribuições via grupo.

Verificar permissões efetivas em um conjunto de recursos de um RG:

$user = "ana@contoso.com"
$rg = "rg-producao"

# Todos os recursos do RG
$resources = Get-AzResource -ResourceGroupName $rg

foreach ($resource in $resources) {
    $assignments = Get-AzRoleAssignment `
      -SignInName $user `
      -Scope $resource.ResourceId `
      -ExpandPrincipalGroups

    if ($assignments) {
        Write-Output "`n--- $($resource.Name) ($($resource.ResourceType)) ---"
        $assignments | Select-Object RoleDefinitionName, Scope, ObjectType |
          Format-Table -AutoSize
    }
}

Este script permite fazer um mapeamento completo do que um usuário pode fazer em cada recurso de um Resource Group.

6.4 Microsoft Graph API

Para interpretação programática de acesso via API:

GET https://management.azure.com/subscriptions/{subId}/resourceGroups/{rgName}/providers/Microsoft.Compute/virtualMachines/{vmName}/providers/Microsoft.Authorization/roleAssignments?api-version=2022-04-01&$filter=atScope()

O parâmetro $filter=atScope() retorna apenas atribuições exatamente neste escopo. Para incluir herdadas, use $filter=principalId eq '{objectId}' em cada escopo pai e combine os resultados.

Para verificar permissões efetivas via Graph (requer permissão Microsoft.Authorization/permissions/action):

POST https://management.azure.com/subscriptions/{subId}/resourceGroups/{rgName}/providers/Microsoft.Authorization/permissions?api-version=2015-07-01

7. Controle e Segurança

Interpretação para Fins de Auditoria de Segurança

A interpretação de atribuições é uma atividade central de auditoria. As perguntas críticas a responder regularmente são:

Quem tem Owner ou Contributor em escopos amplos (Sub ou MG)?

# Listar todos com Owner ou Contributor na subscription
Get-AzRoleAssignment -Scope "/subscriptions/<sub-id>" |
  Where-Object { $_.RoleDefinitionName -in @("Owner", "Contributor") } |
  Select-Object DisplayName, SignInName, RoleDefinitionName, ObjectType, Scope |
  Sort-Object RoleDefinitionName

Existem atribuições diretas a usuários individuais (em vez de grupos)?

Get-AzRoleAssignment -Scope "/subscriptions/<sub-id>" -IncludeClassicAdministrators |
  Where-Object { $_.ObjectType -eq "User" } |
  Select-Object DisplayName, SignInName, RoleDefinitionName, Scope

Atribuições diretas a usuários (em vez de via grupos) são um sinal de possível contorno de processos, dificultam a gestão e comprometem a auditabilidade.

Existem atribuições órfãs (para security principals excluídos)?

Get-AzRoleAssignment -Scope "/subscriptions/<sub-id>" |
  Where-Object { $_.DisplayName -eq $null -and $_.SignInName -eq $null } |
  Select-Object ObjectId, RoleDefinitionName, Scope

Atribuições sem DisplayName ou SignInName indicam que o security principal foi excluído do Entra ID mas a role assignment não foi removida. Elas consomem slots dos 4.000 disponíveis e devem ser limpas.

Interpretação de Deny Assignments

Para ver todos os Deny Assignments em uma assinatura:

# Via Az module
Get-AzDenyAssignment -Scope "/subscriptions/<sub-id>"

# Via CLI
az role assignment list \
  --include-deny-assignments \
  --scope "/subscriptions/<sub-id>" \
  --output table

Um Deny Assignment tem as seguintes propriedades relevantes:

Propriedade	Significado
DenyAssignmentName	Nome descritivo do deny
Actions	Operações que estão sendo negadas
NotActions	Exceções ao deny (operações que não são negadas mesmo estando em Actions)
Principals	A quem o deny se aplica
ExcludePrincipals	Quem está excluído do deny (tipicamente o managed application publisher)
DoNotApplyToChildScopes	Se falso, o deny herda para escopos filhos

8. Tomada de Decisão

Qual ferramenta usar para interpretar acesso?

Situação	Ferramenta	Motivo
Diagnóstico pontual de um usuário em um recurso	Portal (Check Access)	Visual, imediato, sem configuração
Auditoria de quem tem acesso a um RG específico	Azure CLI com `--include-inherited --include-groups`	Completo, exportável
Mapeamento de todo o acesso de um usuário na Sub	PowerShell com `-ExpandPrincipalGroups`	Mais flexível para análise e relatórios
Detecção de atribuições órfãs em larga escala	PowerShell com filtro por DisplayName null	Permite automação e limpeza programática
Integração com sistema de ITSM ou SIEM	Graph API / ARM API	Integração com sistemas externos
Revisão periódica para conformidade	Entra ID Access Reviews (P2)	Automatiza a revisão com workflow de aprovação

Como interpretar "acesso negado" em diagnóstico?

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

9. Boas Práticas

Use "Check Access" antes de conceder mais permissões: antes de responder a um chamado de "preciso de acesso ao recurso X" adicionando uma nova role assignment, sempre verifique primeiro se o usuário já tem acesso via herança ou grupo. Muitos chamados de "acesso negado" se resolvem com o usuário não conhecendo o URL correto, não com falta de permissão.

Documente a interpretação em auditorias: ao fazer uma auditoria de acesso, não apenas liste as atribuições: documente a interpretação. "O Grupo-DevOps tem Contributor na Sub, o que significa que todos os seus membros podem criar e modificar qualquer recurso nas assinaturas de produção" é mais útil do que simplesmente "Grupo-DevOps: Contributor, escopo: /subscriptions/xxx".

Separe a interpretação de controle da interpretação de dados: ao documentar ou reportar acesso, deixe explícito se a permissão é de plano de controle (gerenciar o recurso), de plano de dados (acessar os dados dentro do recurso), ou ambas. Isso evita confusões onde alguém conclui que "tem Contributor, então pode ler os dados do Key Vault", quando na verdade não pode sem um papel de data plane.

Inclua sempre grupos na interpretação: qualquer análise de acesso que não considere as associações de grupo do usuário está incompleta. A maioria dos acessos em ambientes bem gerenciados chega via grupos, não via atribuições diretas.

10. Erros Comuns

Interpretar apenas atribuições diretas e concluir incorretamente

O erro mais frequente: um administrador abre o IAM de um recurso, filtra por "Direct" ou vê apenas as atribuições visíveis na primeira tela, não vê o usuário listado e conclui "ele não tem acesso". Na realidade, o usuário tem acesso herdado via grupo de um escopo pai. A conclusão errada leva a conceder permissão duplicada ou a diagnosticar incorretamente um problema de acesso.

Confundir papel com permissão efetiva

Ver "Reader" atribuído e concluir que o usuário "só pode ler" sem verificar se há outras atribuições. Se o mesmo usuário também tem Contributor via um grupo, ele pode criar e modificar recursos. O papel Reader se soma ao Contributor, e a permissão efetiva é Contributor.

Assumir que Actions cobrem DataActions

"O usuário tem Contributor no Key Vault, portanto pode ler os segredos." Errado. Contributor não inclui Microsoft.KeyVault/vaults/secrets/read como DataAction. Para acessar segredos, o usuário precisa de Key Vault Secrets User (ou Key Vault Administrator). Essa confusão é muito comum com Key Vault e Storage Account.

Não verificar Deny Assignments ao diagnosticar acesso negado

Um usuário tem Owner em uma assinatura mas não consegue excluir recursos em um Resource Group específico. A investigação mostra que todas as role assignments estão corretas. O diagnóstico para aqui e o caso fica sem solução. A causa real é um Deny Assignment criado por um Blueprint que protege aquele RG. Deny Assignments não aparecem na listagem padrão de role assignments; precisam ser buscados explicitamente com --include-deny-assignments.

Ignorar a diferença entre atribuição ao grupo vs. atribuição ao usuário via grupo

Um administrador vê que o Grupo-DevOps tem Contributor na assinatura e conclui "todos da empresa têm Contributor" sem verificar quem está no grupo. A interpretação correta exige saber a composição dos grupos relevantes. Grupos dinâmicos são especialmente traiçoeiros: um usuário pode entrar ou sair do grupo automaticamente com base em atributos, alterando seu acesso sem nenhuma ação administrativa explícita.

11. Operação e Manutenção

Relatório Periódico de Acesso Privilegiado

Uma prática recomendada é gerar mensalmente um relatório de todos os usuários com papéis de alto privilégio (Owner, Contributor, User Access Administrator) em escopos amplos:

$privilegedRoles = @("Owner", "Contributor", "User Access Administrator")
$subscriptionId = "<sub-id>"

$report = Get-AzRoleAssignment `
  -Scope "/subscriptions/$subscriptionId" |
  Where-Object { $_.RoleDefinitionName -in $privilegedRoles } |
  Select-Object @{Name="Principal";Expression={$_.DisplayName}},
                @{Name="Email";Expression={$_.SignInName}},
                @{Name="Tipo";Expression={$_.ObjectType}},
                @{Name="Papel";Expression={$_.RoleDefinitionName}},
                @{Name="Escopo";Expression={$_.Scope}} |
  Sort-Object Papel, Principal

$report | Export-Csv -Path "privileged-access-$(Get-Date -Format 'yyyy-MM').csv" -NoTypeInformation
$report | Format-Table -AutoSize

Monitoramento de Mudanças em Role Assignments

Para detectar quando role assignments são criadas ou removidas, configure alertas no Activity Log:

Via portal: Monitor > Alerts > New alert rule > Signal: Create role assignment ou Delete role assignment.

# Criar alerta via CLI para criação de role assignments
az monitor activity-log alert create \
  --name "alert-new-role-assignment" \
  --resource-group rg-monitoring \
  --scopes "/subscriptions/<sub-id>" \
  --condition category=Administrative and operationName=Microsoft.Authorization/roleAssignments/write \
  --action-group "/subscriptions/<sub-id>/resourceGroups/rg-monitoring/providers/microsoft.insights/actionGroups/ag-security"

Esse alerta notifica a equipe de segurança sempre que uma nova role assignment é criada na assinatura, permitindo revisão imediata de concessões de acesso.

Limites e Considerações de Performance

Item	Detalhe
Propagação de mudanças	Até 30 minutos após criar/remover
Retenção de logs no Activity Log	90 dias (padrão)
Role assignments por subscription	4.000 (limite rígido)
Latência do Check Access no portal	Pode variar em tenants muito grandes

12. Integração e Automação

Exportação para Microsoft Sentinel ou SIEM

Os logs de role assignments do Activity Log podem ser exportados para o Microsoft Sentinel ou para qualquer SIEM via Diagnostic Settings:

az monitor diagnostic-settings create \
  --name "export-activity-to-sentinel" \
  --resource "/subscriptions/<sub-id>" \
  --workspace "/subscriptions/<sub-id>/resourceGroups/rg-monitoring/providers/Microsoft.OperationalInsights/workspaces/law-security" \
  --logs '[{"category": "Administrative", "enabled": true}]'

Com isso, queries KQL no Sentinel podem detectar padrões suspeitos, como:

Um usuário recebendo Owner em uma assinatura fora do horário comercial
Muitas role assignments criadas em sequência rápida
Role assignments em recursos de produção feitas por usuários de desenvolvimento

Query KQL para Análise de Role Assignments no Log Analytics

AzureActivity
| where OperationNameValue == "MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/WRITE"
| where ActivityStatusValue == "Success"
| extend RoleDefinition = tostring(parse_json(Properties).requestbody)
| project TimeGenerated, Caller, ResourceGroup, SubscriptionId, RoleDefinition
| sort by TimeGenerated desc

Integração com Access Reviews Automatizados

Com Entra ID P2, os Access Reviews podem ser configurados para revisar automaticamente role assignments do Azure RBAC:

Caminho: Microsoft Entra ID > Identity Governance > Access reviews > New access review

Configure revisões para:

Frequency: Mensal ou trimestral
Scope: Papéis privilegiados (Owner, Contributor) em assinaturas específicas
Reviewers: Gerentes dos usuários ou gestores de recurso
Upon completion: Remover acesso automaticamente se sem resposta (ou aguardar remoção manual)

Isso transforma a interpretação e limpeza de atribuições de uma tarefa manual periódica em um processo automatizado e auditável.

13. Resumo Final

Pontos essenciais:

A permissão efetiva de um usuário é a união de todas as role assignments que o afetam, diretas e herdadas, diretamente e via grupos, em todos os escopos aplicáveis.
Deny Assignments têm prioridade absoluta e podem bloquear ações mesmo para Owners. Não aparecem na listagem padrão; precisam ser buscados com --include-deny-assignments.
Actions (plano de controle) e DataActions (plano de dados) são avaliados separadamente. Contributor não implica acesso aos dados de blobs ou segredos do Key Vault.
Atribuições herdadas de escopos pai são tão válidas quanto atribuições diretas. Uma análise sem --include-inherited é incompleta.

Diferenças críticas:

Direct vs. Inherited: distingue onde a permissão foi concedida, não o que ela permite. Ambas têm o mesmo efeito prático.
Actions vs. DataActions: crítico para Storage, Key Vault e outros serviços com plano de dados. Contributor não inclui DataActions de blob.
--include-groups vs. sem ele: sem --include-groups, atribuições via grupos ficam invisíveis, tornando a análise incompleta.
NotActions vs. Deny Assignment: NotActions subtrai do papel atual; Deny Assignment nega explicitamente e tem prioridade sobre qualquer role assignment.

O que precisa ser lembrado:

Sempre use --include-inherited, --include-groups e --include-deny-assignments juntos para uma interpretação completa via CLI/PowerShell.
A ferramenta Check Access no portal IAM é o ponto de partida mais rápido para diagnóstico pontual.
Atribuições sem DisplayName ou SignInName são órfãs (security principal excluído). Devem ser removidas.
Atribuições diretas a usuários individuais (em vez de grupos) são um sinal de alerta para auditoria.
Em diagnóstico de "acesso negado", siga o fluxo: sem atribuição > ação não coberta pelo papel > ação em NotActions > Deny Assignment > escopo errado > DataActions vs. Actions > propagação pendente.
O acesso via grupos dinâmicos pode mudar automaticamente quando atributos do usuário mudam, sem nenhuma ação administrativa explícita sobre o acesso.

1. Intuição Inicial​

2. Contexto​

3. Construção dos Conceitos​

3.1 As Cinco Fontes de Acesso​

3.2 Os Três Tipos de Atribuição no Portal​

3.3 A Regra da Aditividade​

3.4 Deny Assignments: A Exceção Absoluta​

3.5 A Diferença entre Actions e DataActions na Interpretação​

4. Visão Estrutural​

O Processo Completo de Interpretação​

Cenário Completo de Interpretação​

5. Funcionamento na Prática​

Ferramenta "Check Access" no Portal​

Visualização da Aba "Role Assignments"​

6. Formas de Implementação​

6.1 Portal do Azure: Check Access​

6.2 Azure CLI​

6.3 PowerShell​

6.4 Microsoft Graph API​

7. Controle e Segurança​

Interpretação para Fins de Auditoria de Segurança​

Interpretação de Deny Assignments​

8. Tomada de Decisão​

Qual ferramenta usar para interpretar acesso?​

Como interpretar "acesso negado" em diagnóstico?​

9. Boas Práticas​

10. Erros Comuns​

11. Operação e Manutenção​

Relatório Periódico de Acesso Privilegiado​

Monitoramento de Mudanças em Role Assignments​

Limites e Considerações de Performance​

12. Integração e Automação​

Exportação para Microsoft Sentinel ou SIEM​

Query KQL para Análise de Role Assignments no Log Analytics​

Integração com Access Reviews Automatizados​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

3. Construção dos Conceitos

3.1 As Cinco Fontes de Acesso

3.2 Os Três Tipos de Atribuição no Portal

3.3 A Regra da Aditividade

3.4 Deny Assignments: A Exceção Absoluta

3.5 A Diferença entre Actions e DataActions na Interpretação

4. Visão Estrutural

O Processo Completo de Interpretação

Cenário Completo de Interpretação

5. Funcionamento na Prática

Ferramenta "Check Access" no Portal

Visualização da Aba "Role Assignments"

6. Formas de Implementação

6.1 Portal do Azure: Check Access

6.2 Azure CLI

6.3 PowerShell

6.4 Microsoft Graph API

7. Controle e Segurança

Interpretação para Fins de Auditoria de Segurança

Interpretação de Deny Assignments

8. Tomada de Decisão

Qual ferramenta usar para interpretar acesso?

Como interpretar "acesso negado" em diagnóstico?

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

Relatório Periódico de Acesso Privilegiado

Monitoramento de Mudanças em Role Assignments

Limites e Considerações de Performance

12. Integração e Automação

Exportação para Microsoft Sentinel ou SIEM

Query KQL para Análise de Role Assignments no Log Analytics

Integração com Access Reviews Automatizados

13. Resumo Final