VPN을 통한 이메일 필터링: 콘텐츠 규칙이 실제로 실행되는 위치

이 요청은 네트워크 문제처럼 들립니다. 특정 유형의 첨부 파일이 건물 밖으로 나가지 않게 하고, VPN이 이미 있으니 그것을 쓰라는 것입니다. 그 틀은 필터가 답해야 할 첫 질문에서 무너집니다. 콘텐츠 규칙은 메시지를 봐야 하고, 메시지는 터널과 다른 계층에서 보이게 됩니다. 저는 패킷에서 바깥쪽으로 메일 경로를 따라가며 필요한 데이터가 실제로 존재하는 첫 지점에서 멈춥니다.

세 계층은 서로 독립적입니다. VPN 전송, SMTP TLS 연결, 그리고 메시지 자체의 암호화입니다. 각각 다른 곳에서 끝납니다.

메시지를 볼 수 있는 계층에서 시작하십시오

VPN 역캡슐화는 내부 네트워크 트래픽을 줍니다. 메일 클라이언트가 제출 서버로 TLS 연결을 열었다면, 내부 트래픽에는 여전히 그 TLS 스트림이 들어 있고 읽을 수 있는 메일은 아닙니다.

따라서 터널 가장자리에서 뜬 패킷 캡처는 «이 메시지에 금지된 첨부 파일이 있는가»와는 다른 질문에 답합니다.

SMTP TLS 종료는 봉투에서 끝납니다

메일 서버에서 SMTP TLS를 종료하면 그 끝점에 제출된 그대로의 메시지가 드러납니다. 서버는 헤더, 봉투, MIME 구조를 봅니다. 많은 콘텐츠 규칙에는 이것으로 충분합니다. 봉투는 서버가 이해한 발신자와 수신자를 알려 줍니다.

S/MIME으로 보호된 메시지에는 충분하지 않습니다. 서버는 보호된 개체를 받고, 해당 키가 없으면 그 안의 콘텐츠를 읽을 수 없습니다. 온전하게 도착하는 암호화된 첨부 파일에도 같은 한계가 적용됩니다.

수동적 캡처를 읽을 수 있게 만들려고 전송 보안을 약화하지 마십시오. 그것은 규칙을 데이터가 있는 곳에 두는 대신 구조를 바꾸는 일입니다.

S/MIME은 키가 있는 곳에서 끝납니다

S/MIME은 MIME 메시지 데이터를 보호하므로 그 경계는 키 자료와 승인된 복호화 방식입니다. 그 키가 없는 필터도 보이는 메타데이터나 보호된 객체의 존재에는 작용할 수 있지만, 그것은 다른 결과입니다.

조직이 승인된 암호화 게이트웨이나 관리형 엔드포인트 통제를 운영한다면, 평문이 어디에 있는지, 어떤 신원이 그것을 검사할 수 있는지, 키와 기록이 어떻게 보호되는지 문서화하십시오. VPN으로 트래픽을 보낸다고 해서 만들어지는 마스터 키는 없습니다.

누군가 평문 분류를 약속하기 전에 그것을 적어 두십시오. 약속은 되돌리기 어려운 부분입니다.

규칙을 메일 플랫폼에 두십시오

승인된 메일 서버가 읽을 수 있는 메시지를 받는다면, 그 서버가 지원하는 콘텐츠 필터 통합이 적용 지점입니다. 방화벽을 통해 SMTP 연결을 허용하는 것과는 다릅니다. 그 차이가 규칙이 거부할 수 있는지, 격리할 수 있는지, 아니면 주석만 달 수 있는지를 결정합니다.

예를 들어 Postfix는 큐 이후 콘텐츠 필터링을 문서화합니다. 메일은 큐에 들어가고, 필터로 전달되고, 배달 경로로 돌아옵니다. 그 큐 이후 구성은 같은 안내서가 언급하는 큐 이전 프록시와 Milter 옵션과 다릅니다. 실제로 운영하는 메일 서비스에 맞는 지원되는 통합과 실패 동작을 고르십시오.

첨부 파일 규칙 하나로는 완전한 데이터 유출 방지 프로그램이 되지 않습니다. 브라우저 업로드, 공유 저장소, 엔드포인트 작업에는 각자의 통제가 필요합니다.

합성 메시지로 수용 테스트를 작성하십시오

승인된 합성 예제로 시험하십시오. 허용된 메시지, 금지된 콘텐츠 작업, 메시지 수준 암호화에 대해 선언된 처리입니다. 필터를 사용할 수 없을 때 메일 서비스가 무엇을 하는지도 포함하십시오.

유용한 결과는 작업, 적용 지점, 그곳에서 보이는 데이터를 지목합니다. «VPN이 복호화했다»는 한 계층에 답할 뿐이며 메일 애플리케이션의 콘텐츠와 권한 모델을 대신할 수 없습니다.