SSL-VPN 대체무엇이 달라지고 무엇부터 옮기나

Zero Trust?는 «매번» 묻습니다. 들어온 뒤의 자유가 사라지는 대신 모든 요청이 기록으로 남습니다.

관리 화면으로 나란히 보려면 아래 «화면으로 비교» 일곱 절을 봅니다.

계정 하나가 넘어가면 침입자는 그 직원 권한으로 사내 자원 대부분을 씁니다. 망 안을 옮겨 다니는 평면 확산?을 막을 두 번째 문이 없습니다.

게이트웨이도 공인망에 열린 문이라, VPN 장비 취약점은 매년 실제 공격 대상이 되어 왔습니다.

ZTNA?는 최소 권한?으로 «어느 앱에» 닿는지를 정하고, 정책에 없는 자원은 보이지 않게 합니다.

따질 것은 «계정 하나를 뺏겼을 때 침입자가 얼마나 멀리 가나»입니다.

특정 상용 제품을 지목하지 않으면서, 상용 SSL-VPN과 같은 관리 작업을 화면으로 보여 주려고 골랐습니다. 기준은 네 가지입니다.

• 관리 화면이 있어 화면 대 화면으로 비교할 수 있다
• SSL-VPN과 같은 방식(OpenVPN, TLS)이다
• 라이선스 없이 실제 접속까지 확인할 수 있다
• 특정 상용 제품을 지목하지 않는다

랩 구성(2026-10-15)은 Pritunl v1.34(OpenVPN 2.4), 조직 2개(본사, 협력사), 사용자 6명, 서버 2대(1194/udp, 1195/udp)입니다. 실제 VPN 접속까지 확인한 뒤 캡처했습니다.

비교 대상은 오픈소스 기본 설정입니다. 다만 «인터넷에 열린 장비, 접속 뒤 네트워크 단위 접근»이라는 기본 구조는 상용 SSL-VPN도 대체로 같습니다.

입사, 이동, 퇴사를 VPN에 따로 반영할 일이 없어집니다.

※ 비교 대상은 오픈소스 기본 설정입니다. 상용 SSL-VPN은 AD 연동이나 단말 점검 같은 기능이 다를 수 있습니다.

계정 하나를 도용당했을 때 닿는 범위가 다릅니다. VPN은 대역 전체, Cloudflare One은 그 사람에게 허락된 앱뿐입니다.

※ 비교 대상은 오픈소스 기본 설정입니다. 상용 SSL-VPN은 AD 연동이나 단말 점검 같은 기능이 다를 수 있습니다.

퇴사 처리를 사내 IdP 한 곳에서 끝냅니다.

※ 비교 대상은 오픈소스 기본 설정입니다. 상용 SSL-VPN은 AD 연동이나 단말 점검 같은 기능이 다를 수 있습니다.

«누가 무엇에 접근했고 왜 막혔는지»를 정책 단위로 답할 수 있습니다.

※ 비교 대상은 오픈소스 기본 설정입니다. 상용 SSL-VPN은 AD 연동이나 단말 점검 같은 기능이 다를 수 있습니다.

SSL-VPN(오픈소스 Pritunl 기본 설정, 우리 랩): 로그인(인증서, 비밀번호)만 맞으면 어느 PC에서든 접속됩니다. 단말 상태를 보려면 상용 VPN의 부가 기능이나 별도 NAC 제품을 붙여야 합니다.

별도 NAC 제품 없이 PoC에서 바로 확인할 수 있습니다.

※ 비교 대상은 오픈소스 기본 설정입니다. 상용 SSL-VPN은 AD 연동이나 단말 점검 같은 기능이 다를 수 있습니다.

Pritunl에서 사내 계정 SSO 연동은 유료 구독입니다.

비밀번호가 새도 두 번째 확인에서 막힙니다. 앱마다 강도를 달리하고, 피싱에 강한 보안 키까지 쓸 수 있습니다.

1. 본사, 그룹 IT: 전체 터널(Exclude). 인터넷까지 Cloudflare로 보호합니다.
2. 협력사, 고객사: 업무 대역만(Include). 개인 인터넷은 그대로 둡니다.
3. 기본(Default): 위 규칙에 해당하지 않는 단말입니다.

서버를 늘리지 않고 한 화면에서 소속별로 나눕니다. 협력사에는 업무 대역만, 임직원에는 인터넷 보호까지 줍니다.

SSL-VPN 칸은 일반적인 구조 기준이며 제품마다 다를 수 있습니다. 2단계 인증과 소속별 설정은 위 «화면으로 비교» 6, 7을 봅니다.

• VPN: 본사 회선과 장비 용량이 곧 전체 속도이고, 한 곳이 죽으면 전원이 끊깁니다.
• Zero Trust: 사내 서버까지는 Tunnel?의 나가는 연결로 잇습니다.
• 웹앱: 클라이언트리스?라 VPN 클라이언트가 없는 협력사나 임시 인력도 브라우저로 들어옵니다.

사설 IP나 비웹 포트에는 WARP?가 필요하지만, 설치와 로그인은 한 번뿐입니다.

1. 웹앱: 서버는 그대로 두고 문 앞만 Access?로 바꿉니다.
2. 사내망 자원: 사설 IP와 비웹 포트는 WARP?와 Tunnel?로 엽니다. 이때부터 VPN 없이도 사내 시스템이 열립니다.
3. 정책과 확인: 앱마다 «누가, 어떤 단말로» 정책을 걸고 로그로 실제 접속을 봅니다.
4. 축소와 폐쇄: 새 문으로 모인 앱과 사용자를 VPN 허용 목록에서 빼고, 마지막 실접속이 사라지면 게이트웨이를 끕니다.

게이트웨이를 첫날 끄는 것은 이전이 아닙니다. 나란히 두고 앱 단위로 옮깁니다.

• 소속별 접근 통제 랩: 협력사와 고객사 계정으로 같은 주소가 열리고 막히는 것을 PC와 휴대폰에서 봅니다.
• Access 동작 원리: Access가 요청을 판단하는 방식과 오리진이 받는 것을 봅니다.
• 실습장 Zero Trust 탭: 로그인이 무엇을 두 번 묻는지 그림으로 보고 직접 해 봅니다.

이전은 하루짜리 전환이 아니라 앱 단위 병행입니다. 두 문을 나란히 열고 로그로 접속이 옮겨 가는 것을 봅니다(위 «어떤 순서로 바꾸나요?»).

앱 주소가 바뀌지 않는다고 사용자에게 먼저 알리면 문의가 줄어듭니다.

기준은 지금 VPN으로 쓰는 목록입니다. VPN 사용 로그와 서버별 접속 대역을 먼저 뽑으면 빠지는 앱이 없습니다.

Zero Trust › Access › Applications › Add an application › Self-hosted

1. Self-hosted를 고르고 앱 이름과 도메인(앱 주소)을 넣습니다.
2. 로그인 방법은 회사가 쓰는 IdP를 연결합니다.
3. 정책(누가 들어오나)을 이메일이나 그룹으로 쓰고, 필요한 앱만 MFA?를 켭니다.
4. 세션 시간은 오래 쓰는 앱은 길게, 관리 화면은 짧게 둡니다.

앱 등록은 «문이 생겼다»까지입니다. 오리진이 토큰 서명을 검증해야 그 문이 유일한 길이 됩니다.

1. 사내망 컴퓨터 한 대에 cloudflared?를 깔고 터널을 띄웁니다.
2. 사내 대역을 터널 라우트로 등록합니다.
3. 사용자 단말에 WARP?를 깔고 한 번 로그인합니다.
4. Split Tunnel? 기본 제외 목록에서 사내 대역을 빼 Cloudflare를 지나게 합니다(아래 함정 참고).
5. 사설 IP 하나에 접속해 완료를 확인합니다(공식 안내의 마지막 단계).

Zero Trust › Access › Policies › Add policy

• 웹앱(Access?): 회사 그룹이나 이메일 목록으로 신원을 정하고, 필요한 앱만 2단계 인증을 켭니다.
• 사설망(Gateway?): 터널만 연결하면 등록된 단말 전부가 사설망 전체에 닿아 VPN과 같습니다. HTTP 정책과 네트워크 정책으로 서버, 포트, 사람을 좁혀야 ZTNA가 됩니다.
• 단말 기준: 민감한 앱에만 OS 버전이나 방화벽 같은 단말 조건을 붙입니다.

배포 전에 정책 시험기(policy tester)로 «이 사람이 이 앱을 통과하나»를 봅니다.

• Access? 로그: 누가, 언제, 어느 앱에 들어왔고 허용인지 차단인지 남습니다.
• Gateway? 로그: 단말, 적용된 정책, 목적지까지 남아 사설망 접근을 여기서 봅니다.
• 주기: 주 단위로 «새 문으로만 쓰이나»를 보고, 맞으면 VPN 허용 목록에서 뺍니다.
• 보관: 장기 보관과 분석은 Logpush로 내보냅니다.

기본 제외 목록에 사설 대역이 통째로 들어 있어, 사내망 접근에는 이를 바꿔야 합니다.

• 사내 대역을 제외 목록에서 빼고, 필요하면 대역이나 호스트 단위로 좁힙니다.
• 사내 DNS 이름은 이름 풀림도 함께 봅니다. 이름이 풀려도 경로가 안 열리는 경우가 있습니다.

«연결됨(Connected)»은 단말과 Cloudflare가 붙었다는 뜻일 뿐입니다. 확인은 실제 사설 IP 접속으로 합니다.

• VPN: 재택, 출장, 해외 트래픽이 본사 회선으로 모여 게이트웨이가 단일 실패점이 됩니다. 이 비중이 클수록 체감 차이가 커집니다.
• ZTNA: 연결 종결과 정책 평가는 가까운 Cloudflare 입구에서, 사내까지는 Tunnel?의 나가는 연결로 이어집니다.

비교는 같은 앱, 같은 시간대, 같은 단말로 재야 의미가 있습니다. 본사 안쪽 사용자는 VPN도 빨라 차이가 작게 느껴집니다.

비웹 앱은 사설 IP 기준 «private app»으로 등록해 문을 열 수도 있습니다.

레거시 프로토콜과 전용 클라이언트는 공식 문서보다 우리 환경의 실측이 우선입니다. 시험 없이 일괄 이전 계획에 넣지 않습니다.

• 세션 시간: 업무 앱은 길게, 관리 화면과 민감 앱은 짧게 둡니다.
• 오리진 검증: 오리진이 토큰 서명을 검증하면 Cloudflare를 지난 요청만 받습니다.
• 사람 아닌 연동: 배포와 자동화는 서비스 토큰?으로 들어와 회사 로그인 세션과 분리됩니다.
• VPN과 비교: 세션을 VPN보다 짧게 두면 «문이 잠기는 주기»가 곧 보안 수준이 됩니다.

1. 우리 출구 IP를 허용 목록에 둔 상대를 VPN 사용 로그와 계약 문서에서 찾습니다.
2. 전용 출구 IP?를 발급받아 등록합니다.
3. 발급은 «주·예비 한 쌍»으로 옵니다. 예비가 다른 나라인지 보고 둘 다 등록해 검증합니다.
4. 지역 기반 차단을 쓰는 상대라면 예비 위치의 나라가 차단 대상인지도 봅니다.

건너뛰면 «VPN 때는 되던 것이 안 된다»는 문의가 폐쇄 뒤에 돌아옵니다.

Zero Trust › Insights › Logs

• 접속: VPN 로그에 최근 실접속이 있는 계정이나 앱이 없는지 봅니다.
• 출발지: 상대 허용 목록 점검(4번 절)이 끝났는지 확인합니다.
• 사후: 폐쇄 뒤 잠시 남기는 «비상 문»의 기간과 해제 조건을 미리 정했는지 봅니다.

폐쇄 기록(누가, 언제, 무슨 근거로)은 감사와 다음 검토에 그대로 씁니다.

상대별 점검을 끝냈어도, 우리 출구 IP를 쓰던 곳이 모두 문서에 있지는 않습니다.

• 폐쇄 뒤 한두 주는 VPN 계정과 대역을 끊기만 하고 지우지 않은 채 접속 시도 로그를 봅니다.
• 끊기는 연결이 출발지 때문이면 전용 출구 IP? 주·예비 등록 상태를 다시 봅니다.

단말 장애처럼 보이는 문의는 진단 자료를 받은 뒤 판단합니다. 바로 재설치하면 원인 기록이 사라집니다.