O recurso silencioso que reduz a superfície de exposição de dados
Todo administrador de Microsoft 365 já viveu a mesma cena: alguém precisa receber documentos de fornecedores, candidatos ou parceiros externos e a solução improvisada acaba sendo um link de compartilhamento “Qualquer pessoa” (Anyone link) com permissão de edição sobre uma pasta inteira. Funciona — e abre uma porta lateral perigosa. Quem tem o link pode ver, baixar, alterar e até apagar tudo o que já está dentro daquela pasta.
O recurso de Solicitação de Arquivos (em inglês, Request Files ou File Request) resolve exatamente esse problema. Ele é nativo do OneDrive for Business e do SharePoint Online, é gratuito, e poucas equipes o utilizam de forma consciente. Neste artigo eu vou além do “como clicar”: vou tratar do modelo de permissões por trás do recurso, da governança via PowerShell, dos riscos residuais e de um checklist de segurança para implantá-lo sem criar dívida técnica.
1. O problema real: coleta de arquivos sem oversharing
A coleta de arquivos de terceiros é um dos vetores mais comuns de exposição desnecessária de dados (oversharing) dentro de uma organização. O padrão problemático costuma ser este:
- Um colaborador cria uma pasta no OneDrive ou em uma biblioteca do SharePoint.
- Gera um link “Qualquer pessoa com o link” para facilitar a vida do remetente externo.
- Concede permissão de edição, porque “senão a pessoa não consegue subir o arquivo”.
O resultado é um link anônimo, com permissão de escrita, sobre um contêiner que frequentemente contém outros documentos — às vezes sensíveis. Qualquer pessoa que receba (ou intercepte, ou reencaminhe) esse link herda acesso de leitura e escrita a todo o conteúdo.
O recurso de Solicitação de Arquivos quebra esse antipadrão porque inverte a lógica do compartilhamento: em vez de dar acesso a um contêiner, ele cria um canal de entrada unidirecional.
2. Como o recurso funciona por baixo do capô
Quando você cria uma Solicitação de Arquivos sobre uma pasta, o Microsoft 365 gera um tipo especial de link anônimo cuja permissão efetiva é somente upload (View and upload restrito ao envio). Tecnicamente, o que acontece é o seguinte:
- O link é um Anyone link (não exige autenticação do remetente), porém com a capacidade de listagem e leitura suprimida.
- Quem recebe o link só consegue enviar arquivos. Não consegue ver o conteúdo existente da pasta, não consegue editar, não consegue excluir e não consegue saber quem mais enviou algo.
- Cada arquivo recebido ganha um prefixo identificador com o nome informado pelo remetente, o que ajuda na rastreabilidade. Se dois arquivos chegarem com o mesmo nome, o sistema acrescenta automaticamente um número para evitar sobrescrita.
- O remetente não precisa ter conta Microsoft. Isso é o que torna o recurso útil para coleta junto a candidatos, fornecedores e público externo.
Do ponto de vista de segurança, a diferença essencial em relação ao Anyone link tradicional é que o File Request elimina os verbos de leitura e exclusão da equação. É a materialização prática da recomendação da própria Microsoft sobre unauthenticated sharing: definir a permissão de pasta como “Exibir e carregar” (View and upload) em vez de edição, restringindo o Anyone link a apenas visualizar enquanto habilita o envio.
3. Passo a passo de uso (perspectiva do usuário)
O fluxo para quem cria a solicitação é direto:
- No OneDrive for Business ou na biblioteca do SharePoint, crie (ou escolha) uma pasta dedicada exclusivamente ao recebimento. Nunca aponte uma solicitação para uma pasta que já contém outros documentos.
- Clique com o botão direito sobre a pasta e selecione Solicitar arquivos.
- Informe uma descrição do que está sendo solicitado (ex.: “Envie aqui o seu currículo em PDF”).
- Copie o link gerado ou informe os e-mails dos destinatários. Você pode incluir uma mensagem que seguirá no e-mail enviado pelo OneDrive.
- A cada upload, você recebe uma notificação por e-mail.
Para o remetente externo, a experiência é minimalista: ele abre o link, vê a descrição, faz o upload e — se não estiver autenticado — é solicitado a informar nome e sobrenome para que você consiga identificar a origem de cada arquivo. Ele nunca enxerga o conteúdo da pasta.
4. Pré-requisitos e governança: o que o administrador precisa controlar
Aqui está a parte que a maioria dos artigos ignora. O recurso depende de configurações de tenant e de site, e essas configurações têm implicações diretas de segurança. Se você gerencia o ambiente, precisa conhecê-las.
4.1. Dependência do compartilhamento externo
O File Request é, na sua essência, um link anônimo. Portanto, ele só funciona quando o compartilhamento externo / anônimo está habilitado no escopo correto. O controle de capacidade de compartilhamento (SharingCapability) admite quatro valores:
Disabled— compartilhamento externo desligado;ExistingExternalUserSharingOnly— apenas convidados já existentes no diretório;ExternalUserSharingOnly— compartilhamento por e-mail habilitado, mas links anônimos desativados;ExternalUserAndGuestSharing— compartilhamento por e-mail e links anônimos habilitados.
Como o File Request usa link anônimo, ele exige um cenário em que links Anyone estejam permitidos no nível pertinente. Esse é o trade-off de governança: para liberar o canal de upload anônimo, você precisa permitir links anônimos — daí a importância de aplicar as travas das próximas seções.
4.2. Habilitando o recurso via PowerShell
O recurso é controlado em dois níveis: tenant e site (coleção de sites).
No nível do tenant, a flag relevante para o SharePoint é CoreRequestFilesLinkEnabled:
powershell
# Conecta-se ao SharePoint Online Management Shell
Connect-SPOService -Url https://<seutenant>-admin.sharepoint.com
# Verifica a configuração atual do tenant
Get-SPOTenant | Select-Object CoreRequestFilesLinkEnabled, CoreRequestFilesLinkExpirationInDays

# Habilita o recurso para todos os sites do SharePoint (não inclui OneDrive)
Set-SPOTenant -CoreRequestFilesLinkEnabled $True

# (Opcional) Define expiração padrão dos links de solicitação, em dias
Set-SPOTenant -CoreRequestFilesLinkExpirationInDays 30
Nota técnica: se
CoreRequestFilesLinkEnablednão estiver definido, a opção “Solicitar arquivos” só aparecerá no OneDrive (e ainda assim dependendo de os Anyone links estarem habilitados). Para o OneDrive, as flags equivalentes sãoOneDriveRequestFilesLinkEnabledeOneDriveRequestFilesLinkExpirationInDays.
# Habilita o recurso para todos os sites do OneDrive

Set-SPOTenant –OneDriveRequestFilesLinkEnabled $True

No nível do site, você inspeciona e ajusta com Get-SPOSite / Set-SPOSite:
powershell
# Verifica o estado do recurso em um site específicoGet-SPOSite -Identity https://<seutenant>.sharepoint.com/sites/RH -Detailed | Select-Object RequestFilesLinkEnabled, RequestFilesLinkExpirationInDays# Habilita explicitamente no siteSet-SPOSite -Identity https://<seutenant>.sharepoint.com/sites/RH -RequestFilesLinkEnabled $True# Define um período de expiração mais restritivo para o siteSet-SPOSite -Identity https://<seutenant>.sharepoint.com/sites/RH -RequestFilesLinkExpirationInDays 7
4.3. A regra de ouro da expiração
Há um detalhe de governança que vale destacar porque é fonte recorrente de erro: o site pode ser mais restritivo que o tenant, mas nunca menos. Se o tenant define expiração máxima de 30 dias, um site pode reduzir para 7, mas não pode estender para 60. O intervalo válido vai de 0 a 730 dias (dois anos), e a regra prática de segurança é simples: quanto mais sensível o site, menor o período de expiração.
Lembre-se também de que mudanças em configurações do SharePoint Online podem levar até 24 horas para se propagar. Não conclua que “não funcionou” minutos após aplicar o comando.
5. Análise de risco: o que o File Request resolve e o que ele NÃO resolve
Como especialista em segurança da informação, meu papel não é vender o recurso, e sim dimensionar o risco residual. O File Request é uma mitigação de oversharing, não uma solução de segurança completa.
O que ele resolve bem:
- Elimina o acesso de leitura/escrita ao contêiner. O remetente só envia; não enxerga nada.
- Reduz o raio de exposição. Mesmo que o link vaze ou seja reencaminhado, o pior cenário é o recebimento de arquivos não solicitados — não a fuga de documentos existentes.
- Melhora a rastreabilidade com prefixos por remetente e notificações de upload.
O que ele NÃO resolve (riscos residuais):
- O link continua anônimo. Qualquer pessoa com o link pode enviar arquivos. Sem expiração e sem monitoramento, isso vira um canal de ingestão aberto — incluindo upload de malware. Trate a pasta de destino como zona não confiável e considere varredura antimalware e DLP sobre o que chega.
- Não autentica o remetente. O nome/sobrenome informado é autodeclarado e não verificado. Para fluxos que exigem identidade confiável, prefira convites a convidados (guest access) com autenticação.
- Depende de links anônimos habilitados no tenant. Isso amplia a superfície de configuração que precisa ser governada — e exige as travas complementares abaixo.
- Não substitui classificação e DLP. O conteúdo que chega ainda precisa de rótulos de sensibilidade, retenção e políticas de prevenção contra perda de dados.

6. Controles complementares recomendados
Para implantar o File Request com higiene de segurança, combine-o com os seguintes controles de tenant/site. Um exemplo de hardening de um site dedicado a recebimentos externos:
powershell
Set-SPOSite -Identity https://<seutenant>.sharepoint.com/sites/Recebimentos ` -RequestFilesLinkEnabled $True ` -RequestFilesLinkExpirationInDays 7 ` -DisableSharingForNonOwners ` -DefaultSharingLinkType None ` -DefaultLinkPermission None ` -OverrideTenantAnonymousLinkExpirationPolicy $True ` -AnonymousLinkExpirationInDays 7
O racional de cada parâmetro:
DisableSharingForNonOwners— impede que membros e visitantes criem novos compartilhamentos, concentrando o controle nos donos do site.DefaultSharingLinkType NoneeDefaultLinkPermission None— tornam o compartilhamento padrão deliberadamente “seguro por padrão”, forçando uma escolha consciente a cada compartilhamento.AnonymousLinkExpirationInDays— garante que mesmo links anônimos legítimos morram em prazo curto.
Adicionalmente, no nível organizacional:
- Restrinja domínios com
SharingDomainRestrictionMode(AllowList/BlockList) quando o público externo for previsível. - Audite o acesso anônimo periodicamente. Sites com links Anyone ativos devem entrar em um relatório recorrente de governança.
- Aplique rótulos de sensibilidade e DLP sobre o site/biblioteca de destino.
- Use uma pasta descartável e dedicada por campanha de coleta, e arquive/feche a solicitação assim que o objetivo for cumprido.
7. Casos de uso legítimos
Para fechar com aplicação prática, alguns cenários em que o recurso brilha:
- Recrutamento: coleta de currículos de candidatos externos sem expor a pasta do processo seletivo.
- Compras e licitações: recebimento de propostas de múltiplos fornecedores, cada um sem ver a proposta do concorrente.
- Eventos: coleta de apresentações e materiais de palestrantes.
- Marketing/parcerias: recebimento de logotipos e ativos de marca atualizados de parceiros.
- Financeiro/Contábil: recepção de notas e comprovantes de prestadores externos.
Em todos eles, o ganho é o mesmo: um canal de entrada unidirecional, sem dar a chave do cofre a quem só precisa colocar algo dentro dele.
Conclusão
A Solicitação de Arquivos é um daqueles recursos que parecem pequenos, mas resolvem um problema estrutural de governança: a tentação de usar links anônimos com permissão de edição para tarefas que exigem apenas recebimento. Bem configurado — com expiração curta, pasta dedicada, travas de compartilhamento e monitoramento — ele reduz materialmente a superfície de exposição de dados da sua organização.
Como sempre em segurança da informação, a ferramenta não substitui o processo. O File Request é a peça técnica; a governança via PowerShell, a classificação de dados e a auditoria contínua são o que transformam um recurso conveniente em uma prática realmente segura.
Tem dúvidas sobre como aplicar esses controles no seu tenant? Deixe um comentário ou entre em contato.

