Signal to Policy · leitura estimada: 9 min

Um novo radio button muda a pergunta da política

A nova opção aparece discretamente dentro da ação Restrict access or encrypt the content in Microsoft 365 locations.

Na interface atual, o texto é:

Block access to external domains and users

Depois de selecionar a opção, o administrador adiciona propriedades para definir os domínios ou usuários externos que serão afetados.

Parece apenas mais uma variação de bloqueio. Não é.

Até aqui, uma decisão comum de Data Loss Prevention para SharePoint e OneDrive era essencialmente binária: permitir o acesso externo ou bloquear pessoas externas à organização.

A nova ação introduz uma pergunta mais específica:

Este conteúdo pode ser acessado por qualquer organização externa ou apenas por determinados parceiros, domínios e usuários?

Essa mudança não torna o DLP automaticamente mais inteligente. Ela torna o desenho da política mais próximo das relações reais de negócio.

O que mudou de fato

Na documentação, a Microsoft chama a funcionalidade de Block access for specific external domains or users.

Ela permite que regras de DLP para SharePoint Online e OneDrive for Business bloqueiem o acesso a arquivos sensíveis com base em:

• um domínio externo, como partner.com;
• um usuário externo específico, identificado pelo endereço SMTP.

Em 4 de agosto de 2026, a funcionalidade ainda está documentada como public preview e disponível somente para SharePoint e OneDrive. Não se trata de uma nova ação equivalente para Exchange, Teams Chat, Fabric ou Power BI, mesmo que todos esses workloads apareçam no texto mais amplo da ação na interface. (Microsoft Learn)

Essa diferença de escopo precisa estar clara no assessment.

A interface apresenta uma ação agregada para várias localizações do Microsoft 365, mas a subopção por domínio ou usuário externo está documentada apenas para arquivos armazenados no SharePoint e no OneDrive.

O problema que essa ação tenta resolver

Considere uma organização que trabalha com escritórios jurídicos, consultorias, fornecedores, distribuidores e parceiros tecnológicos.

Um arquivo pode conter dados sensíveis e ainda assim precisar ser compartilhado externamente. O risco não está necessariamente em qualquer colaboração externa. Pode estar em compartilhar aquela categoria de informação com uma organização específica.

Antes dessa granularidade, o requisito de negócio era difícil de representar diretamente no DLP:

Arquivos relacionados à aquisição podem ser compartilhados com o escritório jurídico responsável pela operação, mas não devem ser acessados por outros parceiros externos.

A ação Block only people outside your organization é ampla demais para esse cenário. Ela não distingue um parceiro autorizado de um destinatário externo indevido.

A nova opção permite combinar a sensibilidade do conteúdo com a identidade externa que tenta acessá-lo.

Esse é o ponto central da mudança.

O DLP deixa de responder apenas se o destinatário é interno ou externo. Ele começa a responder qual externo pode acessar qual conteúdo.

O que a documentação sustenta

A ação não funciona de forma isolada. Ela continua dependendo do restante do desenho da regra.

No cenário documentado pela Microsoft, a política inclui:

1. SharePoint, OneDrive ou ambos como localizações;
2. a condição Content is shared from Microsoft 365 — with people outside my organization;
3. uma condição de classificação, como Sensitive Information Types, sensitivity labels ou outros classificadores aplicáveis;
4. a ação Restrict access or encrypt the content in Microsoft 365 locations;
5. a subopção Block access for specific external domains or users.

Para criar uma lista de bloqueio, a documentação orienta usar:

Domain IS
User IS

Para representar entradas de permissão, a interface também oferece:

Domain IS NOT
User IS NOT

A Microsoft documenta alerting para essa ação, mas informa que user notifications e user override não são suportados. (Microsoft Learn)

Isso tem consequência operacional.

O DLP pode bloquear o acesso sem oferecer ao usuário interno a mesma experiência de policy tip, orientação ou justificativa de negócio encontrada em outros cenários.

Não é apenas uma limitação visual. É uma limitação do processo.

Uma organização que depende de override para tratar exceções legítimas não deve assumir que poderá reutilizar o mesmo modelo operacional nessa nova ação.

O bloqueio acontece no acesso

A documentação descreve três atividades negadas quando um domínio ou usuário configurado tenta consumir o arquivo:

• abrir;
• visualizar uma prévia;
• fazer download.

Os eventos podem ser investigados em DLP Alerts, Activity Explorer e Audit, e o registro inclui o endereço do usuário externo bloqueado. A documentação também indica a geração de um registro de auditoria por tentativa, respeitando as limitações da preview. (Microsoft Learn)

Essa descrição exige cuidado na linguagem.

Eu evitaria dizer que a funcionalidade “impede o compartilhamento” sem qualificação.

O comportamento documentado é o bloqueio do acesso ao arquivo. A documentação não afirma, com a mesma clareza, que a criação do link, o envio do convite ou a inclusão inicial do usuário na permissão serão necessariamente impedidos.

O usuário interno pode acreditar que compartilhou o documento normalmente, enquanto a negação ocorre quando o destinatário tenta abrir, visualizar ou baixar.

Até validar o fluxo completo em tenant, a descrição tecnicamente mais segura é:

O DLP impede que domínios ou usuários externos específicos acessem arquivos sensíveis no SharePoint e no OneDrive.

A lógica de allow e block merece um laboratório

A tela parece permitir uma configuração simples de allow list e deny list. A precedência é menos intuitiva.

A Microsoft informa que, quando o mesmo usuário ou domínio aparece em entradas de permissão e bloqueio, prevalece o resultado mais restritivo: o bloqueio vence.

Há outro comportamento que merece atenção. Quando um arquivo corresponde simultaneamente a regras de allow e block, usuários que não aparecem em nenhuma das listas podem ser bloqueados por padrão. (Microsoft Learn)

A própria redação da documentação não é completamente consistente.

Em uma página, a avaliação é descrita como ocorrendo “per rule”. Na referência de ações para SharePoint, aparece como avaliação “across all matching rules”. O resultado operacional apresentado é semelhante, mas a diferença de linguagem não ajuda quem precisa prever o comportamento de políticas complexas.

Por isso, eu não começaria a adoção misturando várias listas de permissão, bloqueio e exceções.

Uma deny list pequena e explícita é mais fácil de testar, explicar e sustentar.

Onde está a mudança arquitetural

Essa funcionalidade não substitui os controles de compartilhamento externo do SharePoint nem as configurações de colaboração do Microsoft Entra.

Ela ocupa uma camada diferente.

A fronteira de colaboração

SharePoint, OneDrive e Entra continuam definindo quem pode ser convidado, quais tipos de link são permitidos e com quais organizações a empresa pode colaborar.

Esses controles respondem:

Com quem o ambiente pode colaborar?

A classificação do conteúdo

Sensitive Information Types, sensitivity labels, Exact Data Match e trainable classifiers ajudam a determinar o que existe no arquivo e qual é sua categoria de sensibilidade.

Essa camada responde:

Que tipo de dado este arquivo contém?

A decisão contextual do DLP

A nova ação conecta as duas anteriores:

Quando esta categoria de conteúdo estiver compartilhada externamente, quais domínios ou usuários não poderão acessá-la?

É aqui que o desenho da política muda.

A organização pode permitir colaboração com um parceiro no nível do tenant ou do site e, ainda assim, impedir que esse parceiro acesse uma categoria específica de informação.

Não é necessário transformar toda restrição de dados em uma proibição estrutural de colaboração.

A funcionalidade resolve uma lacuna real.

Muitas políticas corporativas não dizem simplesmente “não compartilhar externamente”. Elas estabelecem uma relação entre classificação e destinatário:

• dados financeiros podem ser enviados ao auditor, mas não a outros fornecedores;
• documentos de uma aquisição podem ser acessados pelo escritório jurídico, mas não por consultorias não envolvidas;
• informações de engenharia podem ser compartilhadas com o fabricante contratado, mas não com todos os parceiros do projeto;
• um usuário externo específico pode precisar ser bloqueado sem que todo o seu domínio seja afetado.

O DLP agora tem uma forma mais direta de representar essas decisões em SharePoint e OneDrive.

Mas a granularidade cria uma nova dependência: a governança das listas.

Domínios mudam. Empresas são adquiridas. Contratos terminam. Parceiros operam com várias marcas e endereços. Usuários externos trocam de função ou organização.

Uma regra tecnicamente correta hoje pode se tornar obsoleta sem produzir qualquer erro de configuração.

O proprietário da política não pode ser apenas o administrador do Purview. A lista precisa ter responsável de negócio, critério de inclusão, processo de revisão e prazo de validade.

Sem isso, a nova granularidade vira dívida operacional.

O que eu faria na prática

Eu começaria com um cenário pequeno e defensável.

A primeira política teria:

• um site controlado;
• uma categoria de conteúdo bem compreendida;
• um domínio explicitamente bloqueado;
• um endereço SMTP explicitamente bloqueado;
• outro parceiro externo permitido para comparação.

A classificação precisa ser confiável.

Um SIT genérico com alto volume de falsos positivos não se torna melhor porque agora pode bloquear um domínio específico. A nova ação melhora a granularidade do destinatário, não a qualidade da detecção.

Também separaria políticas por intenção.

Por exemplo:

Deny | M&A | competitor.example

Deny | Restricted engineering | external.user@example.com

Allow | Legal confidential | approved-lawfirm.example

Eu evitaria uma única regra com dezenas de domínios, usuários, classificadores e exceções.

A economia de regras raramente compensa uma política que ninguém consegue interpretar durante um incidente.

Matriz mínima de validação

Antes do enforcement, eu testaria:

1. um domínio presente apenas na lista de bloqueio;
2. um usuário presente apenas na lista de bloqueio;
3. um domínio configurado como permitido;
4. um usuário ausente de todas as listas;
5. um domínio presente em allow e block;
6. um arquivo já compartilhado antes da ativação;
7. um novo compartilhamento após a ativação;
8. abertura, preview e download;
9. comportamento do convite e do link;
10. registros em Audit, Activity Explorer e DLP Alerts;
11. arquivos de imagem;
12. tempo entre alteração da regra e enforcement.

A preview tem duas limitações documentadas que precisam entrar no teste: arquivos de imagem não são protegidos por essa subopção e determinadas atividades podem produzir múltiplos registros de auditoria. (Microsoft Learn)

Isso já impede tratar o recurso como cobertura completa para qualquer biblioteca documental.

E o licenciamento?

A documentação de DLP afirma que Office 365 E3 e Microsoft 365 E3 incluem proteção para SharePoint, OneDrive e Exchange. (Microsoft Learn)

Isso não deveria ser transformado automaticamente na afirmação de que toda nova subopção em preview está garantida, sem restrições, para qualquer contrato E3.

A página específica da funcionalidade não apresenta uma matriz própria de entitlement. A Service Description também reforça que os usuários beneficiados por serviços do Purview precisam das licenças aplicáveis. (Microsoft Learn)

Minha recomendação é validar três pontos antes de incluir a funcionalidade no desenho definitivo:

• a assinatura efetivamente contratada;
• o Product Terms vigente;
• a disponibilidade da ação no tenant e na região relevantes.

A presença do radio button no portal não substitui uma decisão de licenciamento.

A nova ação parece apenas mais uma opção dentro de Restrict access or encrypt the content in Microsoft 365 locations.

Na prática, ela muda a unidade da decisão.

O DLP não precisa mais tratar todos os externos como uma única categoria. Para SharePoint e OneDrive, ele pode considerar domínios e usuários externos específicos quando um arquivo atende às condições de sensibilidade da política.

Isso permite controles mais próximos das relações reais de negócio.

Também aumenta a complexidade de desenho, precedência, testes e manutenção.

A funcionalidade continua em public preview, não suporta user notifications ou override, não protege arquivos de imagem e possui limitações de auditoria documentadas.

Portanto, a decisão não é simplesmente habilitar a nova opção.

A decisão é definir:

Quais categorias de dados podem ser acessadas por quais relações externas — e quem será responsável por manter essa matriz correta ao longo do tempo?

Fontes oficiais

• Help prevent sharing sensitive items via SharePoint and OneDrive with external users — Microsoft Learn, atualizado em 26 de junho de 2026
• Data Loss Prevention policy reference — Microsoft Learn, atualizado em 26 de junho de 2026
• What’s new in Microsoft Purview — Microsoft Learn
• Design a data loss prevention policy — Microsoft Learn
• Create and deploy a data loss prevention policy — Microsoft Learn
• Microsoft Purview service description — Microsoft Learn
• Data loss prevention and Microsoft Teams — seção de licenciamento para SharePoint e OneDrive, Microsoft Learn

Signal to Policy is an independent publication and is neither affiliated with, nor authorized, sponsored, or approved by Microsoft Corporation.