Solicitação de Arquivos (File Request) no Microsoft 365

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:

  1. Um colaborador cria uma pasta no OneDrive ou em uma biblioteca do SharePoint.
  2. Gera um link “Qualquer pessoa com o link” para facilitar a vida do remetente externo.
  3. 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:

  1. 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.
  2. Clique com o botão direito sobre a pasta e selecione Solicitar arquivos.
  3. Informe uma descrição do que está sendo solicitado (ex.: “Envie aqui o seu currículo em PDF”).
  4. 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.
  5. 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 CoreRequestFilesLinkEnabled nã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ão OneDriveRequestFilesLinkEnabled e OneDriveRequestFilesLinkExpirationInDays.

# 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ífico
Get-SPOSite -Identity https://<seutenant>.sharepoint.com/sites/RH -Detailed |
Select-Object RequestFilesLinkEnabled, RequestFilesLinkExpirationInDays
# Habilita explicitamente no site
Set-SPOSite -Identity https://<seutenant>.sharepoint.com/sites/RH -RequestFilesLinkEnabled $True
# Define um período de expiração mais restritivo para o site
Set-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 None e DefaultLinkPermission 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.


Deixe uma resposta