Em 27 de julho de 2026, organizações que usam o Restricted SharePoint Search para limitar o que aparece no Microsoft 365 Copilot têm uma decisão próxima. A documentação oficial da Microsoft informa que o recurso está sendo retirado e que, a partir de 31 de julho de 2026, novas ativações serão bloqueadas.
Isso não significa que todos os ambientes existentes serão desligados nessa data. Significa que o controle tratado desde o início como solução de curto prazo chegou ao ponto em que não deve mais ser a base de uma estratégia de governança para Copilot e agentes.
A migração também não é uma simples troca de botão. Restricted SharePoint Search, Restricted Content Discovery, Restricted Access Control e Data Access Governance atuam em camadas diferentes. Confundi-las pode produzir uma sensação de segurança sem alterar quem realmente consegue abrir um arquivo.
O que muda em 31 de julho — e o que não muda
Restricted SharePoint Search mantém uma allowlist de sites do SharePoint que podem alimentar experiências de busca, Copilot Chat e agentes. A própria Microsoft o descreve como uma medida temporária para que administradores revisem permissões e governança enquanto limitam a descoberta organizacional.
A partir de 31 de julho, o bloqueio de novas ativações torna inadequado planejar novos projetos em torno desse mecanismo. Mas a documentação não afirma que todos os tenants que já o utilizam perderão o recurso imediatamente em 31 de julho. Qualquer plano que trate essa data como desligamento universal está indo além do que a fonte informa.
O que não muda é ainda mais importante: o Copilot continua respeitando as permissões existentes do usuário. Se alguém já consegue acessar um site, uma biblioteca ou um arquivo, ocultar esse conteúdo de uma experiência de descoberta não corrige a permissão que permitiu o acesso.
É a mesma diferença explorada no artigo sobre arquivos abertos para “Todos”: não aparecer facilmente e não estar acessível são estados de segurança diferentes.
O erro de arquitetura: tratar um controle de descoberta como se fosse least privilege. Ele pode reduzir a chance de um conteúdo aparecer numa resposta, mas não muda necessariamente a autorização que permite abrir esse conteúdo diretamente.
Quatro controles, quatro funções diferentes
| Controle | Função principal | O que ele faz | O que ele não faz |
|---|---|---|---|
| Restricted SharePoint Search | Allowlist temporária | Limita o conjunto de sites usado por experiências organizacionais de busca e Copilot | Não corrige permissões e está em processo de retirada |
| Restricted Content Discovery (RCD) | Conter descoberta | Reduz a descoberta de sites selecionados em busca organizacional e Copilot durante uma revisão | Não altera permissões nem impede acesso direto de quem já tem autorização |
| Restricted Access Control (RAC) | Restringir acesso | Limita o acesso ao site aos grupos de controle configurados e é respeitado em busca e Copilot | Não concede a permissão original nem corrige grupos mal administrados |
| Data Access Governance | Medir e coordenar | Produz relatórios de permissões, links, grupos amplos e exposição; permite acionar owners | Não é controle preventivo nem remedia permissões sozinho |
Restricted Content Discovery: contenção, não remediação
O Restricted Content Discovery foi desenhado para sites que precisam de revisão antes de se tornarem amplamente descobertos. Quando habilitado, reduz a presença do conteúdo em busca organizacional e cenários de descoberta do Copilot.
Há quatro limitações que precisam aparecer no plano:
- As permissões existentes não mudam; quem já tem acesso pode continuar abrindo o conteúdo diretamente.
- Conteúdo que o usuário possui ou com o qual interagiu recentemente ainda pode ser descoberto.
- O controle vale para sites SharePoint, não para OneDrive.
- A propagação não é instantânea. Para sites com mais de 500 mil itens, a Microsoft informa que o processamento pode levar mais de uma semana.
A própria documentação recomenda uso seletivo: aplicar RCD em excesso pode reduzir a completude e a relevância de busca e respostas de IA. Portanto, ele funciona como uma contenção durante a revisão, não como estado permanente para todo o tenant.
Restricted Access Control: uma fronteira de acesso
O Restricted Access Control atua em outra camada. Ele permite limitar o acesso a um site a grupos específicos do Microsoft 365 ou Microsoft Entra. Usuários fora desses grupos não conseguem acessar o site ou seu conteúdo, mesmo que tivessem uma permissão anterior ou um link compartilhado. A política também é respeitada por busca organizacional e Microsoft 365 Copilot.
Isso é mais próximo de uma fronteira efetiva, mas não é automático. Os grupos de controle precisam representar as pessoas certas; sites de canais privados e compartilhados exigem tratamento próprio; e mudanças podem levar tempo para aparecer no índice e no Copilot.
RAC também não substitui a revisão de permissões. Ele pode conter o acesso ao site, mas a organização ainda precisa entender por que pessoas, grupos e links chegaram àquele estado — e evitar que o problema reapareça em outros repositórios.
Data Access Governance: a camada de evidência
Os relatórios de Data Access Governance ajudam a encontrar sites potencialmente superexpostos e organizar a investigação. O relatório de permissões por organização mostra, entre outros sinais:
- total de usuários com acesso em nível de site ou item;
- grupos do Microsoft Entra presentes nas permissões;
- itens com herança interrompida;
- acesso por “Everyone” e “Everyone except external users”;
- convidados, participantes externos e links de compartilhamento.
Esses relatórios são snapshots, não telemetria em tempo real. O primeiro relatório organizacional pode levar até cinco dias, execuções posteriores até 24 horas e os dados podem refletir um estado de até 48 horas antes da geração. Essa defasagem precisa entrar no cronograma de migração e na interpretação do resultado.
Um plano de migração em cinco etapas
1. Meça antes de escolher o controle
Comece pelo baseline de permissões da organização. O objetivo não é apenas listar sites: é descobrir quais combinam maior número de usuários, conteúdo sensível, grupos amplos, convidados, links e permissões únicas.
Se o foco for o blast radius de identidades específicas — administradores, executivos, contas privilegiadas ou primeiros usuários do Copilot — use também o relatório de permissões por usuário. Ele diferencia acesso ao site inteiro de itens compartilhados direta ou indiretamente.
Não espere o dia 31 para iniciar essa coleta. A data bloqueia novas ativações do recurso antigo; ela não reduz o tempo necessário para gerar, revisar e validar evidências.
2. Priorize por risco de dados, não por quantidade de sites
O site com mais usuários não é automaticamente o mais crítico. A prioridade aparece na combinação:
sensibilidade × alcance × facilidade de descoberta × ausência de owner
Um site de comunicação aberto para toda a empresa pode estar funcionando conforme o esperado. Uma biblioteca de RH, jurídico ou finanças com o mesmo alcance exige outra resposta. Use rótulos de sensibilidade, finalidade, owner, compartilhamento externo e volume de permissões para separar colaboração legítima de exposição.
Essa é a ligação com blast radius: número de usuários é um indicador de alcance, não uma medida completa de risco.
3. Use RCD para ganhar tempo e RAC para impor fronteira
Quando um site de alto risco precisa continuar acessível diretamente durante a revisão, mas não deveria surgir em descoberta organizacional, RCD pode funcionar como contenção temporária.
Quando existe um conjunto estável de pessoas autorizadas e a necessidade é impedir acesso fora desse grupo, RAC é o controle mais alinhado ao objetivo. Antes de aplicá-lo, valide grupos, owners, canais de Teams relacionados, links externos e impacto operacional.
Em ambos os casos, registre a justificativa, o responsável, a data e a condição de saída. Um controle temporário sem prazo de revisão tende a virar dívida permanente.
4. Leve a decisão ao proprietário do site
TI consegue identificar amplitude, grupos e links, mas nem sempre consegue decidir quem deveria manter acesso a cada contrato, relatório ou projeto. A revisão de acesso por site permite delegar a análise ao owner e acompanhar o resultado.
O processo suporta relatórios de links, “Everyone except external users” e baseline de oversharing. Site owners podem revisar grupos, itens e detalhes de compartilhamento e então remover ou ajustar acessos. Essa etapa transforma um relatório técnico em uma decisão de negócio atribuível.
5. Valide acesso, descoberta e Copilot separadamente
Depois da mudança, teste pelo menos quatro cenários:
- Um usuário autorizado consegue abrir o site diretamente?
- Um usuário não autorizado recebe bloqueio real de acesso?
- O conteúdo aparece em busca organizacional para cada perfil?
- O Copilot ou um agente consegue recuperar o conteúdo para cada perfil?
Um único teste não prova os quatro comportamentos. Registre horário, identidade, site, política aplicada e resultado; considere a latência de propagação antes de classificar uma configuração como falha.
O que não fazer nessa migração
Não aplicar RCD em massa e declarar least privilege. O acesso direto continua existindo e a Microsoft alerta que uso excessivo degrada busca e respostas de IA.
Não tratar o relatório como estado ao vivo. Dados com até 48 horas de defasagem podem não refletir a última mudança. Use o snapshot para priorizar e confirme o estado atual antes de revogar.
Não usar RAC sem um owner capaz de validar os grupos. Um grupo de controle errado pode manter pessoas indevidas ou interromper um processo legítimo.
Não medir sucesso pelo número de sites ocultados. A métrica correta é a redução de acesso injustificado a dados relevantes, acompanhada de impacto operacional aceitável.
Não esquecer OneDrive. RCD e site access review têm escopos específicos de SharePoint. O programa precisa tratar OneDrive com os relatórios e controles aplicáveis, sem presumir cobertura automática.
Checklist para CISO e administrador Microsoft 365
- Sabemos se o Restricted SharePoint Search está ativo no tenant?
- Geramos um baseline de permissões de SharePoint e OneDrive?
- Identificamos sites com grupos “Everyone” ou “Everyone except external users”?
- Cruzamos amplitude de acesso com sensibilidade e owner?
- Definimos critérios objetivos para RCD temporário e RAC permanente?
- Cada contenção possui responsável, justificativa e data de revisão?
- Site owners participam da decisão de remoção de acesso?
- Testamos acesso direto, busca, Copilot e agentes com perfis diferentes?
- Guardamos evidência da configuração e do resultado?
- Monitoramos novos links e permissões depois da limpeza?
Se várias respostas forem “não”, a retirada do recurso antigo não é o problema principal. Ela apenas tornou visível uma lacuna de Access Governance que já existia.
Conclusão
A retirada do Restricted SharePoint Search encerra a ideia de que uma allowlist temporária pode sustentar indefinidamente a governança do Copilot. O caminho mais seguro não é substituir um nome por outro: é separar claramente as funções de cada controle.
Data Access Governance mede. Restricted Content Discovery contém a descoberta enquanto a equipe revisa. Restricted Access Control impõe uma fronteira de acesso. Site access review leva a decisão ao owner. Nenhuma dessas camadas, isoladamente, mantém permissões justificáveis ao longo do tempo.
O objetivo final não é esconder mais sites do Copilot. É conseguir demonstrar quem acessa quais dados, por qual motivo e sob qual controle — antes que uma pergunta em linguagem natural, um agente ou uma vulnerabilidade como EchoLeak e SearchLeak exponha a diferença entre permissão concedida e permissão realmente necessária.
O assessment gratuito do DSPM Brasil mede o domínio de Access Governance e ajuda a identificar se sua organização está apenas contendo descoberta ou se já consegue governar permissões com evidência.
Fontes
Fontes consultadas em 27/07/2026:
- Restricted SharePoint Search, Microsoft Learn.
- Restrict discovery of SharePoint sites and content, Microsoft Learn.
- Restrict SharePoint site access with Microsoft 365 and Microsoft Entra groups, Microsoft Learn.
- Data access governance reports for SharePoint and OneDrive sites, Microsoft Learn.
- Get your organization’s site permissions baseline, Microsoft Learn.
- Discover sites accessible by a given user, Microsoft Learn.
- Everyone except external users activity report, Microsoft Learn.
- Initiate site access reviews for data access governance reports, Microsoft Learn.
Disponibilidade, pré-requisitos e licenciamento desses recursos podem mudar e devem ser confirmados na documentação e no tenant antes da implementação.
