Microsoft Intune: Guia prático para entender Roles, Scope Tags e Custom Roles

Administrar o Microsoft Intune em ambiente corporativo não é só entrar no portal e sair criando política. Em algum momento, toda operação cresce, o time aumenta e aparece uma necessidade que é inevitável: delegar acesso sem entregar privilégio demais. É exatamente aí que entram as roles do Intune, as custom roles, os scope groups e as scope tags. A Microsoft define esse conjunto como a base do controle administrativo no Intune, usando RBAC para distribuir permissões e escopo entre equipes e regiões.

Na teoria, parece simples. Na prática, é comum ver ambientes em que o administrador criou uma role, colocou uma scope tag, adicionou alguns grupos e, no final, o resultado ficou estranho: admin enxergando objeto demais, sem conseguir ver determinados dispositivos ou com uma segmentação difícil de manter. O problema quase nunca está em uma única configuração. Normalmente, o erro está em não entender a função real de cada peça.

A ideia deste artigo é organizar tudo isso de um jeito mais direto: o que são as roles nativas do Intune, quando vale usar uma built-in role, quando faz mais sentido criar uma custom role, como funcionam os role assignments e como usar scope tags sem transformar o tenant em uma bagunça administrativa. Também vou mostrar um caminho prático para montar uma delegação mais segura e mais sustentável em produção. A Microsoft inclusive reforça o uso de custom roles e assignments para implementar least privilege, ou seja, o menor privilégio necessário para a tarefa.

O que são Roles no Microsoft Intune?

As roles do Intune definem o que um administrador pode fazer dentro do serviço. Esse modelo usa RBAC, ou seja, controle de acesso baseado em função. A Microsoft mantém roles nativas prontas para cenários comuns e também permite criar roles personalizadas quando a role pronta não atende bem o nível de acesso necessário. Na prática, dá para resumir assim:

• Role = Define o que o admin pode fazer.
• Role assignment = Define quem recebe a função.
• Scope groups = Define quais usuários e dispositivos entram no alcance daquele admin.
• Scope tags = Define quais objetos do Intune esse admin pode visualizar.

Atenção: Esse ponto é essencial. Muitos profissionais tentam resolver tudo apenas criando uma role, quando na verdade o comportamento final do acesso depende da combinação correta dessas quatro camadas. A própria Microsoft trata a assignment como a peça que amarra role, grupos administrativos, scope groups e scope tags.

1. Application Manager

A Application Manager é a role voltada para administração de aplicativos no Microsoft Intune. Ela permite criar, atualizar, excluir, atribuir e relacionar apps, além de oferecer leitura de informações sobre dispositivos e perfis. É uma função indicada para equipes que cuidam do ciclo de vida dos aplicativos, mas não precisam administrar políticas de conformidade, segurança ou a arquitetura completa do tenant.

Exemplo: Um analista responsável por publicar aplicativos Win32, apps da Microsoft Store e aplicativos móveis, revisar atribuições e acompanhar a distribuição dos softwares, sem precisar alterar políticas de segurança ou configurações de enrollment.

2. Endpoint Privilege Manager

A Endpoint Privilege Manager é uma role específica para cenários de Endpoint Privilege Management (EPM). Ela permite criar, atribuir e gerenciar políticas de elevação, além de acompanhar relatórios e solicitações relacionadas ao recurso. É indicada para equipes que administram elevação controlada de privilégios no endpoint.

Exemplo: Uma equipe de segurança que precisa permitir a execução de determinados aplicativos com elevação controlada, sem entregar privilégios de administrador local para o usuário final.

3. Endpoint Privilege Reader

A Endpoint Privilege Reader é a versão somente leitura do EPM. Ela permite acompanhar políticas, solicitações e relatórios de elevação, sem capacidade de alteração.

Exemplo: um time de auditoria que precisa apenas verificar como o recurso de elevação está sendo usado no ambiente, sem aprovar solicitações nem alterar políticas.

4. Endpoint Security Manager

A Endpoint Security Manager é uma role bastante relevante em ambientes corporativos, pois concentra permissões ligadas à segurança e conformidade. Ela abrange recursos como security baselines, device compliance, integrações com Microsoft Defender e outras configurações de proteção relacionadas ao endpoint.

Exemplo: Uma equipe responsável por manter o nível de segurança dos dispositivos, revisar conformidade, administrar baselines e acompanhar integrações com o Defender.

5. Help Desk Operator

A Help Desk Operator é uma das roles mais úteis para operação de suporte. Ela permite diversas ações remotas em usuários e dispositivos, além de oferecer leitura operacional de vários objetos do Intune. Dependendo da plataforma e do cenário, pode incluir ações como sincronização, reinicialização, coleta de diagnósticos, wipe, retire e outras tarefas de suporte.

Exemplo: Uma equipe de suporte que precisa ajudar o usuário no dia a dia, forçando uma sincronização, reiniciando o dispositivo remotamente, coletando diagnósticos ou executando ações básicas de troubleshooting.

6. Intune Role Administrator

A Intune Role Administrator é uma role sensível, voltada à administração do próprio modelo de RBAC do Intune. Ela permite gerenciar custom roles e assignments, ou seja, é a função usada por quem governa como os demais administradores recebem acesso no ambiente.

Exemplo: Um administrador responsável por organizar a delegação do Intune, criar novas roles, revisar assignments e ajustar o escopo de acesso das equipes.

7. Policy and Profile Manager

A Policy and Profile Manager é focada em políticas e perfis. Ela cobre o gerenciamento de configuration profiles, compliance policies, enrollment profiles e outros objetos relacionados à configuração do ambiente. É indicada para quem projeta, implementa e mantém o desenho técnico do tenant.

Exemplo: Um analista que cria e mantém perfis de configuração, políticas de conformidade e perfis de enrollment usados em produção.

8. Read Only Operator

A Read Only Operator é a role de somente leitura. Ela permite visualizar informações de usuários, dispositivos, enrollment, configurações e aplicativos, sem capacidade de alteração.

Exemplo: Um gerente, auditor ou analista de governança que precisa consultar o ambiente e acompanhar informações do Intune sem correr o risco de fazer alterações.

9. School Administrator

A School Administrator é uma role voltada a cenários educacionais e de laboratório, com foco em administração de aplicativos, configurações e ações remotas sobre grupos e dispositivos sob sua responsabilidade.

Exemplo: Uma equipe de TI de escola ou universidade que administra dispositivos compartilhados, aplicativos educacionais e configurações usadas em salas de aula ou laboratórios.

Quando usar Role nativa e quando criar Custom Role

A melhor regra prática é: use role nativa quando ela já atende exatamente o cenário. Se a role pronta entrega privilégios demais, aí sim começa a valer a pena criar uma custom role. A Microsoft reforça isso nas orientações sobre custom role e no quickstart oficial, sempre com foco em least privilege.

Na prática, eu costumo usar role nativa quando o cenário é muito claro, por exemplo:

• leitura simples do ambiente
• suporte operacional básico
• equipe focada exclusivamente em apps
• time focado em Endpoint Security

Já a custom role faz mais sentido quando você precisa de uma função mais cirúrgica, como:

• um N2 que pode executar ações remotas, deletar devices, dentre outras ações, mas não deve alterar políticas críticas
• uma equipe regional que só enxerga devices da própria unidade
• um time que pode ler compliance e inventário, mas não apagar nem reconfigurar objetos
• uma operação que precisa de um mix específico de permissões que não existe em nenhuma built-in role

O que são Scope Tags no Intune?

As scope tags são etiquetas administrativas usadas para segmentar a visibilidade dos objetos do Intune. A Microsoft descreve as scope tags como valores definidos pelo administrador para ajudar a separar o que cada equipe administrativa pode visualizar no portal.

Em termos práticos, a scope tag serve para “marcar” objetos do Intune com um determinado escopo administrativo ou região como por exemplo:

• J365-BRASIL
• J365-EUA

Você também pode usar por equipe, por função ou por nível de suporte, por exemplo:

• J365-N1
• J365-N2

Mas, na prática, o uso mais limpo costuma ser por escopo administrativo do ambiente, como país, região ou unidade lógica. Função de equipe normalmente fica melhor representada na role e no grupo administrativo.

O que a scope tag faz, na prática

A scope tag ajuda a organizar quais objetos pertencem a determinado escopo administrativo. Exemplo:

• políticas usadas no Brasil podem receber a tag J365-BRASIL
• políticas usadas nos Estados Unidos podem receber J365-EUA
• apps usados apenas no Paraguai podem receber J365-CHILE

Depois, quando um administrador recebe uma role assignment contendo a mesma scope tag, ele passa a enxergar os objetos compatíveis com aquele escopo, desde que o restante da configuração também esteja correto. A Microsoft explica que a combinação entre roles e scope tags é justamente o que limita a visibilidade dos objetos administrativos no Intune.

O que a scope tag não faz

Esse é um ponto muito importante e vale deixar bem claro. A scope tag não serve para distribuir configuração, aplicativo ou script para usuários e dispositivos. Esse papel continua sendo dos assignments do próprio objeto, como acontece com apps, compliance policies, configuration profiles e outros recursos do Intune. Ela também não substitui uma role e não entrega permissão administrativa por conta própria. Sozinha, ela não transforma ninguém em administrador e nem libera ações no portal.

Na prática, a função da scope tag é outra: ela funciona como uma etiqueta de visibilidade administrativa, usada para organizar quais objetos do Intune pertencem a cada escopo e, com isso, ajudar a limitar o que determinadas equipes conseguem visualizar no console. Em outras palavras:

• quem define o que será implantado são os assignments do objeto;
• quem define o que o admin pode fazer é a role;
• quem ajuda a definir o que o admin consegue enxergar é a scope tag.

Hands-on – Habilitar Scoped Permissions do tenant

Antes de criar a estrutura de delegação, o primeiro ponto é validar a configuração em: Tenant administration >> Roles >> Settings. Nessa tela, existe a opção Scoped permissions.

Em tenants onde existem várias equipes administrativas, várias tags e múltiplas assignments, habilitar Scoped permissions tende a deixar o modelo mais previsível, reduzindo efeitos indesejados de visibilidade entre recursos e tags. Como a mudança é irreversível, essa etapa deve ser analisada internamente antes de habilitar.

• Acesse Tenant administration.
• Entre em Roles.
• Clique em Settings.
• Localize a seção Scoped permissions.
• Clique em Enable scoped permissions.
• Confirme a ação.

Se o tenant vai trabalhar com segmentação administrativa por time, área, país ou operação, essa revisão deve vir antes da criação do restante do RBAC. Isso evita retrabalho no desenho.

Próximo Passo – Criando uma Scope Tag

No portal do Intune, o caminho é: Intune admin center >> Tenant administration >> Roles >> Scope (Tags) >> Create

1. Acesse o Intune admin center
2. Vá em Tenant administration
3. Entre em Roles
4. Clique em Scope (Tags)
5. Clique em Create

1. Informe o Nome e Descrição, ponto importante para manter um ambiente organizado e documentado:
   • Name: J365-N1
   • Description: Esta tag define o escopo de visibilidade e gerenciamento para analistas de N1. Objetos marcados com esta tag estarão visíveis e editáveis (conforme permissões de RBAC) para a equipe de suporte imediato.
2. Avance para Assignments

Para utilizar a atribuição automática (que é o ideal para escala), selecione os grupos de dispositivos que devem receber esta tag. Neste exemplo, selecionamos os grupos de Windows e Android, limitando a associação automática desta tag apenas a estas duas plataformas.

Atenção: Para fins de automação, as Scope Tags devem ser associadas apenas a grupos de dispositivos. Grupos de usuários não devem ser utilizados nesta etapa, pois a tag visa identificar o hardware que será gerenciado.

Após avançar, valide as configurações e conclua clicando em Create.

Importante: Note que, neste momento, estamos apenas definindo quais aparelhos receberão essa TAG. A restrição real de visibilidade para o Suporte N1 só será efetivada no próximo passo da configuração (na atribuição da Role), onde diremos ao Intune que aqueles analistas só podem enxergar objetos que possuam esta tag específica. Por enquanto, estamos apenas preparando o terreno e garantindo que dispositivos Linux ou macOS fiquem sem esse carimbo.

Depois de criar a Scope Tag, é fundamental aplicá-la também aos recursos do Intune que você deseja que a equipe N1 consiga visualizar, como políticas de conformidade, perfis do Settings Catalog, aplicativos, scripts e outros objetos compatíveis. Se essa associação não for feita, os analistas podem até receber a role corretamente, mas continuarão sem visibilidade sobre esses recursos no portal.

Criando uma Custom Role e definindo o escopo administrativo com Scope Groups e Scope Tags

Depois de entender a lógica das scope tags e da segmentação administrativa, o próximo passo é criar a custom role que será usada pela equipe, mas nada impede de você usar as roles disponíveis no intune. Aqui é importante separar bem as funções de cada componente: a role define o que o administrador pode fazer, enquanto a role assignment vai definir quem recebe esse acesso, em quais grupos ele pode atuar e quais objetos ele conseguirá visualizar. É justamente nessa etapa que muita gente se perde, porque criar a role sozinha não resolve a delegação. Para o acesso funcionar do jeito esperado, a role precisa ser associada corretamente aos Admin Groups, Scope Groups e Scope Tags.

No portal, acesse: Intune admin center >> Tenant administration >> Roles >> All roles >> Create >> Intune Role

Escolha um nome objetivo e fácil de entender. No nosso exemplo será criado:

• Nome: Jornada 365 – Analista N1
• Descrição: Esta função é destinada à equipe de suporte de primeiro nível (Service Desk) para as plataformas Windows e Android. Permite a visualização completa do inventário, renomeação de dispositivos, execução de scripts de remediação e monitoramento de conformidade. Inclui permissões para ações remotas de suporte, como reinicialização, sincronização e bloqueio. O acesso é estritamente controlado via Scope Tags, impedindo alterações em políticas de segurança, scripts globais ou configurações críticas de infraestrutura do locatário (tenant).
• Após preencher corretamente avance para a próxima tela.

A lógica aqui foi simples: habilitar apenas o necessário para atendimento de primeiro nível e manter bloqueado tudo o que poderia abrir alteração estrutural, risco operacional ou administração indevida do tenant.

A seguir, estão as permissões habilitadas na role, em ordem alfabética das categorias.

Admin tasks

Essa configuração permite que a equipe visualize tarefas administrativas e informações relacionadas ao ambiente, sem criar, alterar ou excluir configurações administrativas. Para um time de N1, esse comportamento faz sentido porque entrega visibilidade operacional sem abrir capacidade de administração estrutural.

Nesta categoria, foi habilitada apenas a permissão leitura e todas as demais permaneceram negadas.

• Read = Yes

Device compliance policies

Na prática, isso permite que a equipe consulte o estado de conformidade dos dispositivos e visualize relatórios relacionados, sem criar ou alterar políticas de conformidade. Esse desenho é ideal para o suporte, porque o analista consegue entender se o equipamento está ou não em conformidade e usar essa informação no troubleshooting, mas sem mexer no padrão de segurança da empresa. Nesta categoria, foram habilitadas duas permissões e todas as demais permaneceram desativadas:

• Read = Yes
• View reports = Yes

Managed apps

Essa configuração permite que o suporte visualize informações sobre aplicativos gerenciados no tenant, o que pode ajudar em atendimento e troubleshooting, mas sem publicar, alterar, excluir ou redistribuir apps. Também é importante manter Wipe desabilitado, já que essa ação seria excessiva para um papel operacional de primeiro nível. Nesta categoria, foi habilitada apenas:

• Read = Yes

Managed devices

Este bloco permite localizar dispositivos, ver relatórios de erros e renomear objetos no portal para organização, bloqueando ações críticas como a exclusão de ativos. Foca estritamente na gestão de dados do inventário para diagnóstico, não incluindo comandos de intervenção física, como reiniciar ou sincronizar, que pertencem à categoria de tarefas remotas. Nesta categoria, foram habilitadas:

• Read = Yes
• Update = Yes
• View reports = Yes

Mobile apps

Aqui a ideia é permitir somente leitura do catálogo e das informações de aplicativos móveis, sem abrir distribuição, edição ou relacionamento de apps. Para uma equipe de N1, isso é suficiente na maior parte dos cenários, já que o objetivo é consultar e validar informações, não administrar o ciclo de vida do app. Nesta categoria, foi habilitada apenas:

• Read = Yes

Organization

Essa é uma permissão importante porque entrega leitura do contexto organizacional do Intune, sem permitir alteração de configurações globais. Em uma custom role de suporte, essa leitura ajuda a navegar no ambiente e consultar dados necessários para o atendimento, sem abrir administração do tenant. Nesta categoria, foi habilitada apenas:

• Read = Yes

Remote tasks

Esse conjunto foi muito bem escolhido para um time de primeiro nível, porque cobre exatamente as ações mais comuns de suporte operacional. Nesta categoria, foram habilitadas as ações abaixo:

• Collect diagnostics = Yes
• Reboot now = Yes
• Sync devices = Yes
• Run Remediation = Yes
• Set device name = Yes

Depois das permissões, a próxima tela da criação da role é Scope tags. A Scope Tag dentro da custom role é importante principalmente para visibilidade, e não para criar nova permissão. A role continua sendo o elemento que define ação. Se preferir deixe Default e avance para a próxima etapa.

Na etapa Review + create, o portal mostra um resumo da role. Visualize e confirme as alterações e por fim clique em Create.

Este conjunto de ações remotas foi estrategicamente selecionado para o suporte de primeiro nível (N1), priorizando a agilidade na resolução de chamados comuns, como sincronização e reinicialização, sem expor o ambiente a riscos operacionais. Ao restringir funções críticas e irreversíveis, como a limpeza de dados (Wipe), desativação (Retire) ou troca de chaves de segurança, o modelo aplica o princípio do menor privilégio, garantindo autonomia técnica sem conceder permissões destrutivas.

Nota: Vale ressaltar que esta configuração serve como um modelo base de Custom Role, podendo ser customizada conforme as políticas de segurança e a maturidade de governança de cada organização no Intune.

Criando a Role Assignment

Depois de criar a custom role, o próximo passo é transformá-la em acesso real para a equipe. Isso é feito pela role assignment. No Intune, a role sozinha não entrega acesso a ninguém. O acesso só passa a existir quando a assignment é criada.

Acesse: Tenant administration > Roles > All roles > Jornada 365 – Analyst N1 > Assignments > Assign

Na primeira tela da role assignment, você define o nome e a descrição da assignment.

• Nome: J365 – N1 – Brasil
• Descrição: Atribuição de funções para analistas de Nível 1 baseados no Brasil. Esta configuração define a visibilidade operacional para dispositivos Windows e Android, permitindo suporte técnico básico, renomeação e execução de scripts de correção. O acesso é restrito por meio de Etiquetas de Escopo para garantir que a equipe gerencie apenas seus recursos regionais, preservando as políticas de segurança globais.

Após preencher o nome e a descrição avance para o Admin Groups.

Definindo o Admin Group

Nesta etapa do Admin Groups você não define escopo de objetos, e sim o grupo de administradores que vai herdar a role Jornada 365 – Analyst N1. No cenário deste artigo, o grupo utilizado foi: J365-N1.

Depois de definir o grupo avance para Scope Groups.

Agora vem a parte que mais costuma gerar dúvida. Na aba Scope Groups, defina sobre quais grupos de usuários e dispositivos a assignment poderá atuar dentro do Intune.

Nota: Adicionar um grupo de usuários em Scope Groups faz sentido quando a equipe administra objetos do Intune que são direcionados a usuários, como aplicativos e políticas atribuídas a grupos de usuários. Nesse caso, o grupo ajuda a limitar o escopo operacional da role assignment ao público correto. O que esse grupo não faz é conceder administração da conta do usuário no Microsoft Entra ID.

Na aba Scope Groups, clique em Add groups. Adicione os grupos:

• J365 – Devices Android
• J365 – Devices Windows
• J365 – Users Call Center

Confirme se todos aparecem com status Active. Clique em Next.

Na aba Scope tags, você vai associar a tag administrativa que será usada nessa assignment. A scope tag na role assignment não concede permissão. Ela trabalha principalmente com visibilidade administrativa:

• a role define o que o administrador pode fazer
• a scope tag ajuda a definir o que ele pode ver
• a scope tag aplicada na role controla a visibilidade da própria role
• a scope tag aplicada na role assignment limita a visibilidade dos objetos do Intune, como políticas, aplicativos e dispositivos, para os administradores daquela assignment que tenham tags correspondentes.

• Na aba Scope tags, clique em Select scope tags.
• No painel lateral a sua scope tag, neste exemplo é: J365-N1
• Clique em Select.
• Confirme se a tag aparece em Selected scope tags.
• Clique em Next.

Na etapa final, revise toda a configuração antes de concluir e depois clique em Create.

Depois da role assignment criada, o teste real deve ser feito com uma conta membro do grupo administrativo J365-N1.

Depois de concluir toda a configuração, como você pode ver abaixo, a conta vinculada ao grupo administrativo herda apenas as permissões definidas na role personalizada que criamos. Com isso, o usuário consegue executar somente as ações liberadas, enquanto os demais comandos continuam bloqueados.

Como vimos ao longo deste artigo, criar uma estrutura de delegação no Microsoft Intune vai muito além de simplesmente atribuir uma role. Quando você entende o papel de cada camada o processo passa a fazer muito mais sentido e a delegação fica realmente controlada, previsível e segura. E esse é justamente o grande valor do RBAC bem implementado: permitir que cada time tenha acesso somente ao que precisa para executar seu trabalho com eficiência, sem comprometer a governança do tenant.

E então, você já aplicou esse modelo no seu ambiente corporativo? Já passou por desafios ao criar Custom Roles, Scope Tags ou Role Assignments no Microsoft Intune?

Compartilhe sua experiência nos comentários. Esse tipo de troca ajuda outros profissionais que estão passando pelo mesmo cenário e fortalece ainda mais a nossa comunidade.