App-centric management: oficina para administrar acesso sem voltar ao modelo antigo

Se você administra Microsoft 365, já deve ter visto o aviso na página de políticas de permissão do Teams: "If you're migrated to app centric management, you can see the following message on the permission policy page" (fonte ((abre em nova aba))). A Microsoft está migrando todos os tenants para o modelo app-centric management (ACM), e a janela para escolher o momento da migração está se fechando.

A pergunta que ouço de administradores é: "como faço para gerenciar acesso sem voltar ao esquema antigo de políticas de permissão?" A resposta é que o ACM não é uma versão piorada do modelo anterior. Ele é mais simples, desde que você entenda como ele funciona.

Neste artigo, vou mostrar na prática como navegar essa transição, o que muda no seu dia a dia e como evitar as armadilhas mais comuns.

O que é app-centric management e por que existeLink para esta seção

Antes do ACM, controlar acesso a um app no Teams exigia três camadas: a configuração organizacional para apps de terceiros, o status de cada app (allow ou block) e uma política de permissão aplicada a usuários específicos (fonte ((abre em nova aba))). Na prática, isso significava criar políticas customizadas, lembrar de aplicá-las aos grupos certos e torcer para não haver conflito entre elas.

O ACM substitui essas três camadas por uma única: cada app tem sua própria definição de acesso, com uma lista de usuários e grupos que podem usá-lo (fonte ((abre em nova aba))). Você não cria mais políticas. Você configura o app.

As três opções de disponibilidade são:

• Everyone: o app fica disponível para todos os usuários da organização, incluindo novos usuários e convidados.
• Specific users or groups: somente os usuários e grupos selecionados podem usar o app. Convidados não conseguem usar o app mesmo se estiverem atribuídos a ele. Os tipos de grupo suportados são grupos de segurança, grupos do Microsoft 365, grupos de associação dinâmica de usuários, grupos aninhados e listas de distribuição (fonte ((abre em nova aba))).
• No one: o app não fica disponível para ninguém.

Como a migração aconteceLink para esta seção

A Microsoft iniciou a migração automática em abril de 2025 (fonte ((abre em nova aba))). Existem dois cenários:

• Automática: para organizações que usam apenas a política global padrão. A Microsoft executa a migração sem intervenção do administrador.
• Assistida: para organizações com uma ou mais políticas customizadas. O administrador usa um assistente no centro de administração do Teams.

Se o seu tenant ainda usa políticas de permissão e você vê o aviso na página, pode iniciar a migração manualmente pelo assistente em Teams apps > Permission policies (fonte ((abre em nova aba))). O assistente guia você por sete etapas: inventário, seleção de políticas, revisão da disponibilidade por app, resolução de conflitos, validação por app ou usuário, revisão final e confirmação.

Um detalhe importante: durante a migração, uma política customizada vira um grupo de segurança. Todos os usuários que estavam na política são adicionados ao grupo correspondente, e esse grupo é atribuído aos apps que a política permitia (fonte ((abre em nova aba))). Isso significa que o acesso dos usuários não muda, mas a forma de gerenciá-lo sim: em vez de editar uma política, você edita a atribuição do grupo ao app.

O que muda no seu dia a diaLink para esta seção

A diferença prática é que o centro de gravidade do gerenciamento sai de "políticas que listam apps" para "apps que listam usuários". No modelo antigo, você abria uma política, via quais apps estavam permitidos ou bloqueados e aplicava a política a usuários. No ACM, você abre o app, vê quem pode usá-lo e ajusta.

Isso resolve um problema clássico: políticas conflitantes. Se um usuário estava em duas políticas ao mesmo tempo, uma permitindo um app e outra bloqueando, o comportamento era imprevisível. No ACM, cada app tem uma única lista de quem pode acessá-lo. Conflito deixa de existir.

Outra mudança prática: as configuração organizacionais de apps de terceiros foram unificadas. Antes do ACM, existiam dois controles separados para apps de terceiros: um para gerenciar novos apps em massa e outro para apps existentes. Depois da migração, esses dois controles viram um só, que governa a disponibilidade em massa de apps novos e existentes ao mesmo tempo (fonte ((abre em nova aba))). Quando você ativa a chave, todos os apps de terceiros são habilitados. Quando desativa, todos são desabilitados. Isso não sobrescreve configurações que você fez manualmente app por app.

Armadilhas que eu já vi acontecerLink para esta seção

Algumas situações merecem atenção especial.

Apps bloqueados antes da migração. Depois que a migração termina, o status desses apps aparece como "unblocked", mas a coluna "Available to" mostra "No one" (fonte ((abre em nova aba))). O app continua indisponível para todos, exatamente como antes. A diferença é que agora você vê isso de forma mais clara: não é um bloqueio no nível do app, é uma decisão de disponibilidade.

Conflito entre política global e política customizada. Se um app estava permitido na política global mas bloqueado em uma política customizada, a migração automática trata isso de forma diferente para clientes EDU e não-EDU. Para organizações que não são EDU, o app fica disponível para todos os usuários do tenant. Para clientes EDU, o app fica disponível para ninguém (fonte ((abre em nova aba))). No seu tenant, confirme qual cenário se aplica antes de migrar.

Apps que precisam de configuração do administrador. Quando um desenvolvedor publica um app que exige configuração prévia, ele aparece como "Blocked by publisher" no centro de administração (fonte ((abre em nova aba))). Antes de liberar o app para os usuários, siga as instruções do publicador para configurá-lo.

Apps que não estavam nas políticas selecionadas para migração. Se você optar pela migração assistida e escolher apenas algumas políticas, os apps das políticas não selecionadas não entram na migração e não podem ser migrados depois (fonte ((abre em nova aba))). A saída é editar manualmente a disponibilidade desses apps após a migração.

Como se preparar antes de migrarLink para esta seção

A Microsoft publicou um guia de melhores práticas que recomenda três passos antes da migração (fonte ((abre em nova aba))):

1. Exporte o catálogo de apps da página Manage Apps como CSV. Anote quais apps estão com status "Allowed" e quais estão "Blocked". Esse status determina se o app fica disponível para todos ou para ninguém.

2. Revise cada política de permissão e anote quais apps estão permitidos ou bloqueados em cada uma. Se tiver muitas políticas, use o PowerShell com o comando Get-CsTeamsAppPermissionPolicy para listar todas.

3. Identifique quais usuários estão atribuídos a cada política. No centro de administração, vá em Users > Manage users, use o filtro por política e exporte a lista para CSV. No PowerShell, use Get-CsOnlineUser -Filter "TeamsAppPermissionPolicy -eq '<policy>'".

Com esse inventário em mãos, você consegue validar, depois da migração, se a disponibilidade de cada app ficou como esperava.

Depois da migração: como gerenciar no dia a diaLink para esta seção

O fluxo diário muda para algo mais direto. Para permitir que um usuário ou grupo use um app:

1. Vá em Teams apps > Manage apps no centro de administração do Teams.
2. Busque o app e clique no nome para abrir a página de detalhes.
3. Selecione a aba Users and groups.
4. Clique em Edit availability e escolha a opção desejada: Everyone, Specific users or groups, ou No one (fonte ((abre em nova aba))).

As alterações levam até 24 horas para refletir para todos os usuários. Em casos raros, podem levar até seis dias (fonte ((abre em nova aba))).

Para operações em massa, o centro de administração não permite atualizar a disponibilidade de vários apps de uma vez. Mas o PowerShell sim, com o cmdlet Update-M365TeamsApp (fonte ((abre em nova aba))). Por exemplo, para atribuir um app a um grupo específico:

Update-M365TeamsApp -Id <AppId> -AppAssignmentType UsersAndGroups -Groups "grupo@dominio.com"

E se eu não migrar?Link para esta seção

A migração é obrigatória. A Microsoft está migrando todos os tenants automaticamente. Se o seu já foi migrado, você não consegue mais acessar, editar ou usar políticas de permissão. E não há como reverter a migração (fonte ((abre em nova aba))).

Se o seu tenant ainda não foi migrado e você vê as políticas de permissão disponíveis, pode continuar usando-as ou iniciar a migração por conta própria pelo assistente (fonte ((abre em nova aba))). O importante é não ser pego de surpresa quando a migração automática chegar.

Para fecharLink para esta seção

O app-centric management não é um recurso novo que você precisa aprender do zero. É uma reorganização de algo que você já faz: controlar quem usa qual app. A diferença é que, em vez de gerenciar isso por políticas que cruzam dezenas de apps, você gerencia app por app, com uma lista clara de quem tem acesso.

O maior risco não é a mudança em si. É não se preparar para ela. Faça o inventário antes, entenda o mapeamento entre o modelo antigo e o novo, e use o assistente de migração com confiança. Depois que a poeira baixar, a administração de apps no Teams fica mais simples, não mais complicada.

No seu tenant, confirme o status atual acessando a página de políticas de permissão em admin.teams.microsoft.com/policies/app-permission. Se aparecer o aviso de migração, o ACM já está no seu caminho. Se aparecerem as políticas normalmente, você ainda tem tempo de se preparar.