1. O ponto cego: a área de transferência móvel

Pense no caminho que um dado sensível percorre dentro do Microsoft 365. No Exchange Online, o DLP inspeciona o e-mail. No SharePoint e no OneDrive, inspeciona o arquivo em repouso. No Teams, a mensagem. No Windows, o Endpoint DLP observa cópias para USB, impressão, upload e — sim — a área de transferência. Agora pegue o mesmo CPF e abra-o no Outlook do celular. Selecionar, copiar, colar: três toques e o dado saiu do app sem que nenhuma política de conteúdo tivesse opinião sobre isso.

Não é que o Intune não controle o clipboard. Ele controla, e bem. O problema é como controla: pela identidade do aplicativo de destino, não pelo que está sendo copiado. É exatamente essa lacuna que o Roadmap 567311 promete fechar.

2. O que a Microsoft anunciou (e só isso)

O item 567311 do Microsoft 365 Roadmap, intitulado Microsoft Purview: Data Loss Prevention – Collection and DLP Policies for Intune-Policy Managed Apps, foi publicado em 8 de julho de 2026 e atualizado no dia seguinte. Em tradução fiel, o texto oficial afirma três coisas:

1. Uma nova capacidade integrada do Purview DLP para apps móveis protegidos por Intune MAM, permitindo aplicar políticas de proteção sensíveis ao conteúdo (content-aware) a dados em dispositivos móveis.
2. As ações de área de transferência (clipboard actions) nos apps móveis gerenciados passam a ser avaliadas contra as políticas de DLP do Purview antes que o compartilhamento seja permitido.
3. As políticas de coleta do Purview (Collection policies) poderão ser usadas para governar como dados sensíveis são tratados nos apps móveis.

E aqui vai a parte que separa análise de repetição de press release: o anúncio não detalha plataformas (iOS/Android), versões mínimas de SDK, licenciamento, nome da localização no assistente de política, ações disponíveis (bloquear, auditar, permitir com justificativa) nem o comportamento para apps de linha de negócio (LOB). Até a data deste artigo, as páginas do Microsoft Learn sobre Collection policies também não listam uma fonte de dados específica para apps móveis. Tudo o que vai além dos três pontos acima é inferência — inclusive algumas coisas que você vai ler na seção de mitos.

3. Como o Intune controla o clipboard hoje

Para entender o ganho, precisamos ser precisos sobre o ponto de partida. Na documentação de configurações de App Protection Policy para Android (e equivalente para iOS/iPadOS), a seção Data Transfer traz a configuração Restringir recortar, copiar e colar entre outros apps (Restrict cut, copy and paste between other apps), com quatro valores:

Existe ainda o Limite de caracteres para recortar e copiar para qualquer app (Cut and copy character limit for any app), padrão 0, que abre uma “janela” de N caracteres para qualquer destino, inclusive não gerenciados. É a válvula de escape que muitas organizações usam para permitir colar um número de protocolo no WhatsApp sem liberar tudo.

Repare na lógica: todas essas opções respondem à pergunta “para onde?”. Nenhuma responde “o quê?”. Um limite de 20 caracteres deixa passar um CPF inteiro (14 caracteres formatados). O valor managedApps impede o WhatsApp, mas não diferencia um endereço de reunião de uma planilha de salários colada no Teams.

A própria documentação registra um risco residual importante: alguns teclados de terceiros têm clipboard próprio e inserem texto diretamente no app; nesse caso o texto chega como digitação comum e as restrições de colagem não se aplicam. É por isso que a configuração Teclados aprovados (Approved keyboards) não é detalhe estético — ela fecha um desvio real.

4. De binário para consciente de conteúdo

O que o 567311 introduz é uma segunda pergunta no caminho do clipboard. O Intune continua decidindo a fronteira entre apps; o Purview passa a olhar o conteúdo com os mesmos classificadores que você já usa em e-mail e endpoint: tipos de informações confidenciais (Sensitive Information Types, SITs), como CPF, cartão de crédito e dados bancários, e potencialmente outros classificadores.

Na prática, isso muda a conversa de negócio. Hoje, quem precisa proteger dados regulados costuma escolher managedApps e ouvir reclamações diárias, ou escolher allApps e aceitar o risco. Com avaliação de conteúdo, abre-se a possibilidade de uma política de fronteira mais tolerante combinada a uma política de conteúdo mais rigorosa — desde que o comportamento no preview confirme essa combinação.

5. DLP policy x Collection policy: não confunda

O anúncio cita dois tipos de política, e eles têm naturezas diferentes. A descrição de serviço do Microsoft Purview é explícita: Collection policies foram projetadas para facilitar a descoberta de informações relevantes, e não para aplicar imposição (enforcement) sobre elas.

Essa distinção é ouro para o planejamento: uma Collection policy é o instrumento natural para uma fase de observação, porque mostra o volume real de dados sensíveis circulando no clipboard móvel antes de você ligar qualquer bloqueio.

6. Onde isso se encaixa na arquitetura

A integração não substitui nenhuma camada existente; ela preenche um andar que estava vazio. A visão geral de App Protection Policies lembra que as APPs funcionam com ou sem registro de dispositivo (MDM) e recomenda combiná-las com Acesso Condicional (Conditional Access) para garantir que a política seja de fato aplicada.

Vale um paralelo com o que já existe no desktop. No DLP para apps de nuvem no Edge for Business, o Purview cria automaticamente, ao salvar a primeira política, as configurações do Edge, as políticas do Intune e os grupos de segurança necessários para ativação (processo documentado em Activate your DLP policy in Microsoft Edge). É razoável esperar uma orquestração parecida entre Purview e Intune no cenário móvel, mas isso é uma expectativa, não um fato documentado — confirme no preview.

7. Análise de uso real: quatro cenários

Os cenários abaixo mostram onde a capacidade tende a gerar mais valor. Todos devem ser validados no preview, porque dependem de detalhes ainda não publicados.

Vantagens objetivas

8. Mitos que já estão circulando

O anúncio tem três frases, e a internet já produziu dezenas de parágrafos de “detalhes”. Alguns deles não têm respaldo no texto oficial.

Mito: “A análise acontece quando o usuário cola de um app gerenciado em outro app gerenciado.”

Fato: O roadmap diz apenas que ações de clipboard em apps móveis gerenciados são avaliadas antes do compartilhamento. Não especifica o tipo de destino. Pode ser gerenciado, não gerenciado ou ambos — só o preview e a documentação vão dizer.

Mito: “Exige Microsoft 365 E5 mais Intune Plano 1.”

Fato: Não há licenciamento publicado para este recurso. O que a descrição de serviço do Purview afirma hoje é que Collection policies não têm licença própria e exigem a licença da carga de trabalho coberta. Planeje orçamento, mas não com base em suposição.

Mito: “GA só no primeiro semestre de 2027.”

Fato: O roadmap indica preview em setembro e GA em novembro de 2026. Datas podem mudar, mas a projeção oficial vigente é essa.

Mito: “Collection policies também bloqueiam o compartilhamento.”

Fato: Collection policies são para descoberta, não para imposição. Quem bloqueia é a DLP policy.

Mito: “Basta ir ao Compliance Center e escolher a localização ‘Intune-protected apps’.”

Fato: A configuração de DLP hoje é feita no portal do Microsoft Purview, e o nome da localização ou fonte de dados para este cenário ainda não foi documentado. Não escreva runbooks com nomes de menu que ainda não existem.

9. Preparação antes do preview (com PowerShell)

Não é preciso esperar a documentação final para começar. A ordem abaixo segue a lógica “inventariar, medir, pilotar”:

• Inventariar as App Protection Policies e o valor de clipboard de cada uma (script abaixo).
• Identificar políticas com allApps — são as que mais ganham com avaliação de conteúdo e as que hoje mais expõem dados.
• Revisar os SITs relevantes para o seu negócio (CPF, CNPJ, cartão, dados bancários) e validar a precisão deles nas políticas de DLP existentes.
• Exigir teclados aprovados onde houver dado regulado, fechando o desvio documentado dos teclados de terceiros.
• Reservar um grupo piloto com Acesso Condicional exigindo app protegido por política.
• No preview, começar por Collection policy e/ou DLP em modo de simulação antes de qualquer bloqueio.

Inventário do nível de clipboard nas App Protection Policies (Microsoft Graph)

A propriedade allowedOutboundClipboardSharingLevel está documentada nos recursos androidManagedAppProtection e iosManagedAppProtection, com os valores allApps, managedAppsWithPasteIn, managedApps e blocked.

# Requer: módulo Microsoft.Graph.Authentication
# Permissão: DeviceManagementApps.Read.All
Connect-MgGraph -Scopes "DeviceManagementApps.Read.All" -NoWelcome

$endpoints = @{
    "Android" = "https://graph.microsoft.com/v1.0/deviceAppManagement/androidManagedAppProtections"
    "iOS"     = "https://graph.microsoft.com/v1.0/deviceAppManagement/iosManagedAppProtections"
}

$relatorio = foreach ($plataforma in $endpoints.Keys) {
    $uri = $endpoints[$plataforma]
    do {
        $resp = Invoke-MgGraphRequest -Method GET -Uri $uri
        foreach ($p in $resp.value) {
            [PSCustomObject]@{
                Plataforma      = $plataforma
                Politica        = $p.displayName
                Clipboard       = $p.allowedOutboundClipboardSharingLevel
                EnviarDadosPara = $p.allowedOutboundDataTransferDestinations
                ReceberDadosDe  = $p.allowedInboundDataTransferSources
                Risco           = if ($p.allowedOutboundClipboardSharingLevel -eq "allApps") { "ALTO - sem restrição de clipboard" } else { "-" }
            }
        }
        $uri = $resp.'@odata.nextLink'
    } while ($uri)
}

$relatorio | Sort-Object Risco -Descending | Format-Table -AutoSize
$relatorio | Export-Csv ".\APP-Clipboard-Inventario.csv" -NoTypeInformation -Encoding UTF8

Valide qualquer script contra as políticas da sua organização antes de usar em produção. Este script é somente leitura, mas a permissão concedida ao aplicativo do Graph deve seguir o princípio do menor privilégio.

Conferindo os SITs brasileiros disponíveis (Security & Compliance PowerShell)

# Requer: módulo ExchangeOnlineManagement
Connect-IPPSSession

Get-DlpSensitiveInformationType |
    Where-Object { $_.Name -match "Brazil" } |
    Select-Object Name, Publisher |
    Sort-Object Name

Valide contra as políticas da sua organização antes do uso em produção. Use os nomes retornados pelo seu tenant nas condições das políticas, e não nomes copiados de artigos.

Opinião do Arquiteto

Passei anos explicando para comitês de segurança por que “bloquear copiar e colar” não é uma estratégia de DLP — é uma estratégia de frustração. O usuário que não consegue colar um endereço tira um print, digita de novo ou manda por outro canal. O dado vaza do mesmo jeito, só que sem log.

O 567311 importa porque desloca a decisão do aplicativo para o dado, que é onde ela sempre deveria ter estado. Mas eu seguraria o entusiasmo em dois pontos. Primeiro: o valor real depende de o recurso avaliar também destinos gerenciados; se ele só atuar na saída para apps não gerenciados, será um refinamento — bom, mas não revolucionário. Segundo: DLP com SIT mal calibrado no celular vira gerador de falso positivo na palma da mão do usuário, e isso destrói a adoção mais rápido do que qualquer vazamento.

Minha recomendação: use setembro e outubro para inventariar APPs, medir com Collection policies e afinar SITs. Quando a GA chegar, você terá dados para decidir — e não apenas um anúncio de roadmap.

Referências oficiais

• Microsoft 365 Roadmap — ID 567311
• Microsoft Learn — App protection policies overview
• Microsoft Learn — Android app protection policy settings
• Microsoft Learn — Collection policy reference
• Microsoft Learn — Microsoft Purview service description
• Microsoft Learn — DLP for cloud apps in Edge for Business
• Microsoft Learn — Activate your DLP policy in Microsoft Edge
• Microsoft Graph — androidManagedAppProtection e iosManagedAppProtection

Todo o conteúdo do chesley.com.br é gratuito e sempre será. Se este artigo ajudou, compartilhe com quem administra Intune e Purview no seu time.