VPN 규칙이 파일 하나의 업로드를 막을 수 없는 이유
서비스에 도달하는 것과 그 서비스에서 어떤 파일이 나가는지를 통제하는 것은 두 가지 요구 사항입니다. 규칙은 파일이 보이는 곳에 두십시오. 메일, 애플리케이션 또는 엔드포인트 에이전트입니다.
작은 팀이 업무 시스템에 대한 원격 접속을 요청하면서 동시에 특정 첨부 파일이 회사를 떠나지 않게 해 달라고 요청한다. 두 요청은 하나의 VPN 변경처럼 들린다. 그러나 서로 다른 적용 지점을 가진 두 가지 요구 사항이며, 첫 번째를 충족하는 규칙은 두 번째에 아무것도 하지 않는다. 먼저 행위와 데이터에 이름을 붙이고, 그것을 실제로 볼 수 있는 구성 요소를 고르라.
하나의 요청, 두 가지 요구 사항
첫 번째 요구 사항은 도달성에 관한 것이다. 어떤 사용자와 기기가 어느 서비스로 연결을 열 수 있는가. 두 번째는 그 연결이 존재한 뒤의 동작, 즉 어떤 문서를 첨부하고 붙여넣고 업로드할 수 있는지에 관한 것이다. 터널은 첫 번째에 작용하며 설계상 두 번째에는 눈이 멀다.
IP 수준의 제어는 패킷을 전달한다. 그것은 멀티파트 업로드를 파싱하지 않고, PDF를 검사하지 않으며, 스프레드시트에 계좌 번호가 있는지 판단하지 않는다. 그것을 기대하는 것은 구성 실수가 아니라 범주 오류다.
제품을 찾기 전에 요구 사항을 그 형태로 소리 내어 말하라. «사용자는 파일 포털에 도달할 수 있다»와 «사용자는 고객 목록을 파일 포털에 업로드할 수 없다»는 서로 다른 문장이며, 내용 정책을 설명하는 것은 두 번째뿐이다.
파일을 볼 수 있는 구성 요소를 고르라
적용은 파일을 읽을 수 있는 곳에서 일어나야 한다. 이메일이라면 보통 메일 플랫폼이나 게이트웨이이며, 이미 첨부 파일을 처리하고 전달 전에 평가할 수 있다. 승인된 서비스로의 브라우저 업로드에서는 애플리케이션 자체가 내용을 보는 유일한 당사자일 수 있다. 관리되는 노트북이 파일을 이동식 미디어로 복사할 때는 엔드포인트 에이전트가 그 작업을 본다.
| 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 |
일부 상용 원격 접속 제품군은 엔드포인트 에이전트, 웹 제어, 데이터 손실 방지 모듈을 함께 묶는다. 그 구성 요소들은 내용 정책을 적용할 수 있지만, 그 능력은 터널링이 아니라 모듈에 속한다. 결과를 약속하기 전에 제품군에 실제로 무엇이 포함되어 있는지 읽어 보라.
비교에 유용한 모델은 Microsoft의 Purview 데이터 손실 방지 개요 이다. 그것은 정책을 민감한 정보 유형, 위치, 활동이라는 용어로 설명한다. 그 어휘는 내용과 행위에 관한 것이지 IP 접두사에 관한 것이 아니다.
TLS는 터널을 통과해 살아남으므로 그것을 계획하라
애플리케이션 암호화는 클라이언트와 서비스 사이에서 협상되고, VPN 터널은 그 바이트를 열지 않은 채 운반한다. 따라서 경로상의 게이트웨이는 경로의 얼마를 소유하든 첨부 파일을 분류하는 능력을 자동으로 얻지 않는다.
전송 중인 내용을 검사하려면 신뢰할 수 있는 인증서로 TLS를 종료하는 구성 요소가 필요하며, 이는 자체적인 프라이버시와 운영 결과를 동반하는 중대한 아키텍처 결정이다. VPN 프로필의 체크박스가 아니다. 클라이언트는 검사 인증서를 신뢰해야 하고, 인증서를 고정하는 애플리케이션은 깨질 것이며, 운영자는 이전에는 읽을 수 없던 트래픽을 읽을 수 있게 된다. 바로 이런 이유로 이 결정은 터널을 운영하는 사람이 아니라 보안 책임자에게 속한다.
그래서 «VPN이 이 업로드를 막을 수 있는가»에 대한 정직한 답은 보통 아니오이며, 그 뒤에 구체적인 대안이 따른다. 대안은 애플리케이션 수준의 제한, 메일 규칙 또는 엔드포인트 정책일 수 있고, 각각에는 그것을 바꿀 수 있는 책임자가 있다.
규칙보다 먼저 인수 테스트를 작성하라
내용 규칙에는 하나가 아니라 두 가지 예, 즉 계속 동작해야 하는 허용된 행위와 멈춰야 하는 금지된 행위가 필요하다. 범위 안의 애플리케이션과 기기에서 둘 다 시험하라. 브라우저 하나에서만 동작하는 정책은 누군가 요청한 정책이 아니다.
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/upload첫 번째 요청은 규칙을 소유한 구성 요소가 거부해야 하고, 두 번째는 성공해야 한다. 둘 다 성공하면 통제가 경로에 없다. 둘 다 실패하면 서비스를 보호한 것이 아니라 망가뜨린 것이며, 이는 허용된 예 없이 작성된 규칙의 더 흔한 결과다.
사용자가 무엇을 보는지, 누가 예외를 줄 수 있는지, 관리자가 나중에 어디에서 결정을 확인하는지를 미리 정하라. 메시지 없는 차단된 업로드는 지원 티켓을 만들고, 아무도 감사할 수 없는 규칙은 논쟁을 만든다. 둘 다 정책이 시행되기 전에 작성된 한 문장의 문서로 피할 수 있다.
마지막으로, 두 요구 사항을 서로 다른 담당자와 서로 다른 티켓에 두라. «VPN» 아래에 묶으면 네트워크 팀이 내용 문제를 해결하도록 요청받고, 터널이 올라오면 내용 문제가 해결되었다고 선언된다는 것이 보장된다.