Por que uma regra de VPN não pode impedir o envio de um arquivo
Alcançar um serviço e controlar quais arquivos saem dele são dois requisitos. Coloque a regra onde o arquivo é visível: e-mail, aplicação ou agente de endpoint.
Uma equipe pequena pede acesso remoto aos seus sistemas de trabalho e, no mesmo fôlego, pede que certos anexos parem de sair da empresa. Os dois pedidos soam como uma única mudança de VPN. São dois requisitos com pontos de aplicação diferentes, e uma regra que satisfaz o primeiro não faz nada pelo segundo. Comece nomeando a ação e os dados, e então escolha o componente que realmente consegue vê-los.
Um pedido, dois requisitos
O primeiro requisito trata da alcançabilidade: quais usuários e dispositivos podem abrir uma conexão para qual serviço. O segundo trata do comportamento depois que essa conexão existe: quais documentos podem ser anexados, colados ou enviados. Um túnel age sobre o primeiro e é cego ao segundo por concepção.
Um controle no nível de IP encaminha pacotes. Ele não analisa um envio multipart, não inspeciona um PDF e não decide se uma planilha contém números de conta. Esperar isso dele não é um erro de configuração; é um erro de categoria.
Diga o requisito em voz alta nessa forma antes de procurar um produto. «Os usuários podem alcançar o portal de arquivos» e «os usuários não podem enviar listas de clientes ao portal de arquivos» são frases diferentes, e só a segunda descreve uma política de conteúdo.
Escolha o componente que consegue ver o arquivo
A aplicação tem de acontecer onde o arquivo é legível. Para e-mail, costuma ser a plataforma ou o gateway de correio, que já trata anexos e pode avaliá-los antes da entrega. Para envios pelo navegador a um serviço autorizado, a própria aplicação pode ser a única parte que vê o conteúdo. Para um notebook gerenciado que copia arquivos para mídia removível, um agente de endpoint vê a operação.
| Where the file moves | Component that can see it |
|---|---|
| Email attachment | Mail gateway or mail platform policy |
| Upload to a web application | The application, or an inspection proxy that terminates TLS |
| Copy to USB or local folder | Endpoint agent on the device |
| Anything inside the tunnel | Nothing, unless one of the above is present |
Alguns pacotes comerciais de acesso remoto reúnem um agente de endpoint, um controle web e um módulo de prevenção de perda de dados. Esses componentes podem aplicar política de conteúdo, mas a capacidade pertence ao módulo e não ao tunelamento. Leia o que o pacote realmente inclui antes de prometer o resultado.
A visão geral de prevenção de perda de dados do Purview da Microsoft é um modelo útil de comparação: descreve políticas em termos de tipos de informação sensível, locais e atividades. Esse vocabulário trata de conteúdo e ações, não de prefixos IP.
O TLS sobrevive ao túnel, então planeje isso
A criptografia da aplicação é negociada entre o cliente e o serviço, e um túnel VPN transporta esses bytes sem abri-los. Um gateway no caminho não ganha, portanto, a capacidade de classificar um anexo automaticamente, por maior que seja a parte da rota que possua.
Para inspecionar conteúdo em trânsito é preciso um componente que termine o TLS com um certificado confiável, e essa é uma decisão arquitetônica significativa com consequências próprias de privacidade e operação. Não é uma caixa de seleção no perfil de VPN. Os clientes têm de confiar no certificado de inspeção, aplicações que fixam certificados vão quebrar, e o operador ganha a capacidade de ler tráfego que antes não podia. São essas as razões pelas quais a decisão pertence a um responsável de segurança, e não a quem opera o túnel.
Por isso a resposta honesta a «a VPN pode bloquear este envio» costuma ser não, seguida de uma alternativa concreta. A alternativa pode ser restrições no nível da aplicação, uma regra de correio ou uma política de endpoint, e cada uma tem um responsável que pode alterá-la.
Escreva o teste de aceitação antes da regra
Uma regra de conteúdo precisa de dois exemplos, não de um: uma ação permitida que deve continuar funcionando e uma ação proibida que deve ser barrada. Teste as duas a partir das aplicações e dispositivos do escopo, porque uma política que só funciona em um navegador não é a política que alguém pediu.
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/upload
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/uploadO primeiro pedido deve ser recusado pelo componente que possui a regra, e o segundo deve ter sucesso. Se ambos tiverem sucesso, o controle não está no caminho. Se ambos falharem, você quebrou o serviço em vez de protegê-lo, que é o resultado mais comum de uma regra escrita sem um exemplo permitido.
Decida de antemão o que o usuário vê, quem pode conceder uma exceção e onde um administrador confirma a decisão depois. Um envio bloqueado sem mensagem gera um chamado de suporte, e uma regra que ninguém consegue auditar gera uma discussão. As duas coisas se evitam com uma frase de documentação escrita antes de a política entrar em vigor.
Por fim, mantenha os dois requisitos em chamados separados com responsáveis separados. Agrupá-los sob «VPN» garante que a equipe de rede será solicitada a resolver um problema de conteúdo e que o problema de conteúdo será declarado resolvido quando o túnel subir.