Filtragem de e-mail sobre uma VPN: onde as regras de conteúdo realmente são executadas

Este pedido soa como um problema de rede: impedir que um certo tipo de anexo saia do edifício, e a VPN já está lá, então use-a. Esse enquadramento quebra na primeira pergunta que o filtro precisa responder. As regras de conteúdo precisam ver a mensagem, e a mensagem torna-se visível numa camada diferente da do túnel. Percorro o caminho do correio para fora a partir do pacote e paro no primeiro ponto onde os dados necessários realmente existem.

Três camadas são independentes: o transporte VPN, a conexão SMTP TLS e a cifragem própria da mensagem. Cada uma termina num lugar diferente.

Comece pela camada que consegue ver a mensagem

A desencapsulação da VPN dá-lhe o tráfego de rede interno. Se o cliente de correio abriu uma conexão TLS para um servidor de envio, o tráfego interno ainda contém esse fluxo TLS, não correio legível.

Portanto, uma captura de pacotes na borda do túnel responde a uma pergunta diferente de «esta mensagem contém um anexo proibido».

A terminação de SMTP TLS termina no envelope

Terminar SMTP TLS no servidor de correio expõe a mensagem tal como foi submetida a esse ponto. O servidor vê cabeçalhos, o envelope e a estrutura MIME. Isso basta para muitas regras de conteúdo. O envelope diz-lhe o remetente e os destinatários tal como o servidor os entendeu.

Não basta para uma mensagem protegida com S/MIME. O servidor recebe uma entidade protegida e, sem as chaves relevantes, não consegue ler o conteúdo lá dentro. O mesmo limite aplica-se a um anexo cifrado que chega intacto.

Não enfraqueça a segurança do transporte para tornar legível uma captura passiva. Isso muda a arquitetura em vez de colocar a regra onde os dados estão.

O S/MIME termina onde estão as chaves

O S/MIME protege os dados da mensagem MIME, pelo que a sua fronteira é o material de chaves e o acordo de decifragem autorizado. Um filtro sem essas chaves ainda pode agir sobre metadados visíveis ou sobre a presença de um objeto protegido, mas é um resultado diferente.

Se a organização opera uma passagem de cifragem autorizada ou um controlo gerido de pontos finais, documente onde existe texto simples, que identidade o pode inspecionar e como são protegidas as chaves e os registos. Não existe nenhuma chave mestra criada por encaminhar tráfego através de uma VPN.

Escreva isso antes de alguém prometer classificação de texto simples. A promessa é a parte difícil de retirar.

Coloque a regra na plataforma de correio

Se o servidor de correio aprovado recebe a mensagem legível, a sua integração de filtragem de conteúdo suportada é o ponto de aplicação. Isso é diferente de permitir uma conexão SMTP através de uma firewall. Essa distinção decide se a regra pode rejeitar, colocar em quarentena ou apenas anotar.

O Postfix, por exemplo, documenta a filtragem de conteúdo depois da fila: o correio é colocado na fila, passado a um filtro e devolvido ao caminho de entrega. A sua disposição depois da fila é diferente das opções de proxy antes da fila e Milter a que o mesmo guia se refere. Escolha a integração suportada e o comportamento em caso de falha para o serviço de correio que realmente opera.

Uma regra de anexos não é um programa completo contra a perda de dados. Os envios pelo navegador, o armazenamento partilhado e as ações nos pontos finais precisam dos seus próprios controlos.

Escreva o teste de aceitação com mensagens sintéticas

Teste com exemplos sintéticos aprovados: uma mensagem permitida, uma ação de conteúdo proibida e o tratamento declarado da cifragem ao nível da mensagem. Inclua o que o serviço de correio faz quando o seu filtro não está disponível.

O resultado útil nomeia a ação, o ponto de aplicação e os dados visíveis ali. «A VPN decifrou-a» responde a uma camada e não pode substituir o modelo de conteúdo e autorização da aplicação de correio.