VPN 연결과 업무 시스템 접근은 별개다
집에서 회사 VPN에 접속한 뒤 사내 시스템을 이용하는 상황을 생각해보자. 화면에 ‘연결됨’이 표시됐다고 해서 모든 업무 시스템의 사용 권한을 얻은 것은 아니다. VPN 연결은 통신 경로를 마련하는 단계이고, 어떤 서버와 기능을 사용할 수 있는지는 별도의 접근 정책과 애플리케이션 권한이 결정한다.
VPN(Virtual Private Network)은 기존 네트워크 위에 논리적인 사설 통신 환경을 만드는 기술이다. 이 글에서는 인터넷을 통해 회사에 접속하는 암호화된 원격접속 VPN을 중심으로 설명한다. 핵심은 ‘암호화했는가’에 더해 ‘누가, 어떤 단말로, 어디까지 접속하는가’를 함께 설계하는 데 있다.
원격접속 VPN이 통신을 전달하는 과정
일반적인 클라이언트 기반 구성에서는 업무용 노트북의 VPN 프로그램이 회사 VPN 게이트웨이와 통신한다. 사용자는 정상 서버인지 인증서를 확인하고, 게이트웨이는 사용자 인증과 필요한 단말 검증을 수행한다. 실제 인증·키 협상 순서와 방식은 사용하는 프로토콜과 제품에 따라 다르다.
정책이 허용되면 보호할 트래픽의 경로와 암호화에 필요한 정보가 설정된다. 클라이언트는 해당 트래픽을 터널로 보내고, 게이트웨이는 이를 처리한 뒤 허용된 내부 목적지로 전달한다. 응답 트래픽도 구성된 경로를 따라 돌아온다. 가상 IP 할당과 경로 배포 방식 역시 제품과 구성에 따라 달라진다.
IPsec 터널 모드를 예로 들면 원래 IP 패킷을 안쪽에 담고, 터널 양 끝을 목적지로 하는 바깥 IP 헤더를 붙인다. 암호화를 사용하는 ESP 구성은 안쪽 패킷을 보호하지만, 바깥쪽 전달에 필요한 정보까지 모두 숨기는 것은 아니다. VPN을 사용해도 통신 상대인 게이트웨이 주소나 트래픽의 존재 자체가 반드시 감춰지지는 않는다.
IPsec VPN과 TLS 기반 VPN을 구분하는 기준
IPsec은 IP 계층에서 통신을 보호하는 표준 체계이며, IKE는 인증과 키 협상 등에 사용된다. IPsec은 지사 간 연결뿐 아니라 사용자 단말의 원격접속에도 활용할 수 있다. ‘IPsec은 장비끼리만 연결한다’는 구분은 정확하지 않다.
TLS 기반 VPN은 TLS를 활용해 원격접속 통신을 보호한다. 제품에 따라 특정 웹 애플리케이션을 제공하는 포털형과 클라이언트로 여러 업무 트래픽을 전달하는 터널형 등이 있다. ‘SSL VPN’이라는 제품 분류명이 남아 있어도 실제 사용 프로토콜과 버전은 별도로 확인해야 하며, 오래된 SSL 사용을 뜻하는 것으로 받아들이면 안 된다.
선정할 때는 명칭보다 업무 프로토콜 지원, 단말 관리 방식, 인증 연동, 접속 범위와 장애 대응을 확인하는 편이 낫다. 동일한 계열의 VPN이라도 지원 기능과 보안 설정은 제품별로 다르다.
암호화 터널이 끝나는 지점을 확인한다
원격접속 VPN 터널은 보통 단말과 VPN 게이트웨이 사이를 보호한다. 게이트웨이에서 내부 업무 서버까지의 구간이 같은 터널로 자동 보호되는 것은 아니다. 내부 통신에도 기밀성이 필요하다면 HTTPS 등 해당 구간의 보호 수단을 별도로 적용해야 한다.
단말에 저장된 파일이나 감염된 단말에서 실행되는 악성코드도 VPN 암호화만으로 해결되지 않는다. 접속 전 단말 점검, 보안 업데이트, 저장 데이터 보호와 접속 후 권한 통제가 함께 작동해야 한다.
전체 터널과 분할 터널의 선택
전체 터널은 원칙적으로 단말의 인터넷 트래픽까지 회사 VPN을 거치게 하고, 분할 터널은 지정한 업무 트래픽만 터널로 보낸다. 다만 실제 우회 경로와 예외는 IPv4·IPv6, 로컬 네트워크 허용, 클라이언트 정책에 따라 달라지므로 설정 이름만 보고 판단해서는 안 된다.
| 판단 항목 | 전체 터널 | 분할 터널 |
|---|---|---|
| 트래픽 경로 | 원칙적으로 인터넷 트래픽도 회사 경유 | 지정 업무 트래픽만 회사 경유 |
| 운영상 이점 | 회사 측 검사 정책을 적용하기 쉬움 | 회사 게이트웨이 부하와 우회 지연을 줄일 수 있음 |
| 확인할 부담 | 게이트웨이 용량·지연·장애 영향 | 터널 밖 트래픽에 대한 별도 보안 통제 |
| 검증 대상 | 우회·예외 경로와 실제 검사 여부 | 업무 대역·DNS·IPv6 경로의 누락 여부 |
위 표는 설계를 위한 비교다. 전체 터널도 검사 장비와 정책이 없으면 그 자체로 보안 검사를 수행하지 않는다. 분할 터널은 터널 밖 통신을 회사 VPN에서 관찰하기 어렵기 때문에 단말 보안과 별도의 웹 접근 통제 등 보완 수단을 함께 검토해야 한다.
외부 유지보수 접속은 대상과 시간을 먼저 정한다
가상 예시로, 외부 유지보수 담당자가 특정 업무 서버 한 대를 점검한다고 가정해보자. VPN 계정에 내부 전체 대역을 허용하기보다 대상 서버, 필요한 포트, 작업 기간과 승인자를 먼저 정한다. 가능하다면 중계 서버를 통해 접속하게 하고, 서버의 관리자 권한도 작업에 필요한 수준으로 제한한다.
이 구성은 모든 조직에 동일하게 적용되는 정답이 아니라 최소권한 원칙을 구체화한 설계 예시다. 접근 정책은 다음처럼 검증 가능한 항목으로 남길 수 있다.
- 신원: 개인별 계정을 발급하고 MFA를 적용한다. 가능한 경우 피싱 저항성 인증 수단을 우선 검토한다.
- 단말: 허용 단말의 패치·보안 프로그램 상태를 확인하고, 점검할 수 없는 단말의 접근 범위를 제한한다.
- 범위: 허용한 서버·포트만 접근되는지 확인하고, 다른 내부 대역으로의 접속이 차단되는지도 시험한다.
- 기간: 계정 만료 시점과 세션 종료 조건을 정한다. 권한 회수 시 기존 세션까지 종료되는지 확인한다.
- 기록: 계정·원격지 주소·접속 시각·할당 IP를 업무 시스템 기록과 연결할 수 있게 남긴다. 작업 내용이 필요하면 서버 감사 로그나 중계 시스템 기록을 별도로 확보한다.
VPN 접속 로그만으로 파일 열람이나 서버 명령 실행 내용을 모두 알 수는 없다. 따라서 ‘누가 VPN에 들어왔는가’와 ‘들어온 뒤 무엇을 했는가’를 서로 다른 기록에서 확인할 수 있도록 설계하는 편이 실효성이 높다.
운영에서 놓치기 쉬운 것은 게이트웨이와 접속 후 권한이다
VPN 게이트웨이는 외부에서 접근하는 보안 경계 장비다. 사용자에게 MFA를 적용했어도 장비 취약점이나 세션 탈취 위험까지 없어지지는 않는다. CISA 등의 공동 지침도 전통적인 VPN의 취약점과 넓은 네트워크 접근 범위가 만드는 위험을 설명한다.
실무에서는 게이트웨이의 지원 종료 여부, 보안 패치, 관리자 화면 노출 범위와 이상 접속 탐지를 점검해야 한다. 패치 적용만큼 계정 중지와 세션 강제 종료가 실제로 작동하는지도 확인할 대상이다. 장애에 대비한 예비 접속 수단을 마련할 때도 평상시 접근 통제를 우회하는 상시 통로가 되지 않도록 설계한다.
특정 웹 서비스만 필요한 사용자에게는 애플리케이션별 접근 방식이나 ZTNA를 검토할 수 있다. 다만 새 제품으로 바꾸는 것만으로 최소권한이 완성되지는 않는다. 기존 업무 프로토콜과 운영 여건을 확인한 뒤 VPN의 범위를 줄일지, 다른 방식을 병행할지 결정해야 한다.
설계의 출발점은 접속할 업무의 범위다
원격접속을 설계할 때는 ‘VPN을 제공한다’에서 멈추지 말고 사용자별 접속 대상과 회수 조건을 먼저 정해보자. 그다음 보호할 통신 구간, 단말 조건, 터널 경로와 로그를 맞추면 실제로 검증할 수 있는 보안 구조가 된다. 도입 검수에서도 연결 성공 화면보다 허용된 업무의 정상 동작과 허용하지 않은 경로의 차단 결과를 함께 확인하는 편이 낫다.