O dilema móvel da PME: os dados corporativos estão no Outlook e no Teams do telemóvel pessoal do colaborador, e as opções parecem reduzir-se a duas — inscrever o telemóvel no MDM, com controlo total do dispositivo, ou deixar a conta desprotegida. As App Protection Policies (APP) do Intune são a terceira via: políticas ao nível da aplicação que protegem os dados corporativos sem inscrição do dispositivo.

O que uma APP faz

A política aplica-se à app (Outlook, Teams, Edge,…) e define como ela trata os dados da organização:

  • PIN de acesso à app (com biometria), e bloqueio de execução em telemóveis com root/jailbreak.
  • Encriptação dos dados da organização dentro da app.
  • Cortar/copiar/colar restrito: sem colar conteúdo corporativo em apps pessoais (com limite ajustável de caracteres).
  • “Save As” bloqueado para armazenamento local — o guardar fica confinado a serviços (OneDrive/SharePoint) ou apps autorizadas.
  • Screenshot bloqueado na app (Android: também bloqueia Circle to Search e Google Assistant a aceder aos dados, e desfoca a pré-visualização no app switcher).
  • Wipe selectivo: remover só os dados corporativos da app — o telemóvel e as fotos pessoais ficam intactos.

O modelo assenta no Intune SDK: apps com o SDK embutido “sabem” aplicar políticas. A Microsoft mantém a lista — Office, Outlook, Teams, Edge, OneDrive… — e há apps de terceiros igualmente integradas. Nas apps Microsoft, a política aplica-se só ao contexto de conta de trabalho (multi-identity): a versão pessoal da app não é tocada.

Requisito Android: para as apps Microsoft 365, o MAM exige registo do dispositivo no Microsoft Entra ID (não inscrição MDM — registo de conta). É diferente de MDM, mas não é opcional.

A framework de configuração: níveis 1, 2 e 3

Configurar uma APP de raiz, setting a setting, é trabalho para especialistas. A Microsoft publica uma framework com três níveis cumulativos — cada um inclui o anterior:

  • Nível 1 — Enterprise basic data protection: PIN + encriptação + wipe selectivo, e validação de device attestation em Android. É a entrada, equivalente na prática às políticas de caixa de correio do Exchange Online.
  • Nível 2 — Enterprise enhanced data protection: junta mecanismos de prevenção de fuga de dados (DLP: save-as restrito, copy/paste) e requisitos mínimos de SO. Adequado à maioria dos utilizadores móveis.
  • Nível 3 — Enterprise high data protection: PIN avançado e integração com Mobile Threat Defense. Para quem acede a dados de risco elevado.

Para PME: a Microsoft posiciona o nível 2 como adequado à maioria dos utilizadores móveis — na prática, parte no nível 2 para todos e reserva o nível 3 para quem acede a dados de risco elevado, onde o MTD justifica.

BYOD vs dispositivos corporativos (MAM-WE)

  • BYOD sem inscrição: a meta por omissão. O colaborador descarrega as apps da loja, entra com a conta Microsoft e as políticas aplicam-se à conta. Limitações documentadas desta via: as apps não são distribuídas pelo Intune (vêm da loja), não há cert profiles nem acesso Wi-Fi/VPN central, e a conformidade do dispositivo não entra na balança — o controlo é o da app.
  • MAM-WE (without enrollment): o dispositivo fica sem qualquer inscrição — que é, na prática, o próprio BYOD. A Microsoft descreve três cenários de protecção por app: inscritos no Intune (tipicamente corporativos), inscritos num MDM de terceiros (tipicamente corporativos) e não inscritos (tipicamente pessoais). O MAM-WE é o terceiro — e cobre também máquinas geridas por outro EMM em que só as apps ficam sob gestão do Intune. Um dispositivo corporativo Android Enterprise está, por definição, inscrito num EMM: não é o caso sem inscrição.

Conditional Access: as APP com dente

Uma APP sozinha é política sem enforcement: o utilizador pode ignorar. Com Conditional Access a obrigar à app protegida — o grant Require app protection policy — o acesso ao Exchange Online e ao SharePoint só passa a apps com política activa: quem não tiver, é bloqueado no login, com remediação guiada. O antigo grant Require approved client apps foi entretanto reformado pela Microsoft (a 30 de Junho de 2026 as políticas que o usam ficaram read-only no Entra) — em políticas novas, usa só o de app protection policy. Este par (APP + CA) converte o PIN de recomendação em imposição.

Criar a primeira política

No Intune admin center: Apps → App protection policies → Create policy → Android/iOS, selecionar as apps (Outlook, Teams, Edge, OneDrive para começar), configurar o nível escolhido da framework, atribuir a um grupo (não a “All users” à primeira — começa num grupo piloto), e activar. No Android há um pré-requisito extra mesmo sem inscrição: o Intune Company Portal tem de estar instalado — é o broker que entrega as políticas à app, exigência documentada para receber APP em Android mesmo sem inscrição. A sequência do utilizador resume-se a: instalar as apps da loja, instalar o Company Portal, entrar com a conta de trabalho e aceitar o PIN. Numa próxima sessão, o utilizador recebe o pedido de PIN e o registo no Entra ID.

O que a APP não resolve

  • Não controla o dispositivo: WiFi, certificados, actualizações do SO, Firewall — isso é MDM.
  • Não protege contra screenshot fora da app protegida, nem contra o utilizador fotografar o ecrã com outro telemóvel.
  • Apps sem Intune SDK ficam fora — o “bloquear apps não geridas” funciona por oposição: o conteúdo não sai para apps sem gerir, mas essas apps continuam livres.

Fontes oficiais

Artigos Relacionados