TLS VPN 대 IPsec: 검토할 가치가 있는 다섯 항목

TLS VPN 을 IPsec VPN 과 프로토콜 패밀리로 순위 매기는 것은 아무도 묻지 않은 질문에 답하면서, 대개 두 패밀리가 몇 년 전에 버린 구성을 인용합니다. 검토자가 실제로 평가할 수 있는 것은 협상된 보호, 피어 신원, 클라이언트 모델, 노출된 서비스입니다. 이 네 가지는 배포에서 보이며 어느 것도 제품 라벨에서 나오지 않습니다. 다섯 항목을 요구하면 대화는 구체적으로 바뀝니다.

다섯 항목, 라벨은 그중 하나가 아닙니다

첫 항목은 지원되는 소프트웨어 릴리스입니다. 버전 없는 프로토콜 설명은 안내 책자에 불과합니다. 둘째는 협상된 프로토콜 버전으로 어떤 구성이 가능한지 결정합니다. 셋째는 보호 스위트, 넷째는 피어와 사용자 모두의 인증 방식, 다섯째는 제품이 승인 후 부여하는 접근 범위입니다.

SSL VPN 이라는 라벨은 적어도 세 가지 다른 제품을 포괄합니다. 전체 네트워크 클라이언트, 애플리케이션 프록시, 브라우저 기반의 구형 포털입니다. 노출하는 서비스도 실패 방식도 다르므로 라벨은 범위 항목을 대신할 수 없습니다.

인증된 암호화가 실제로 바꾸는 것

TLS 1.3 은 인증된 암호화를 요구하며, 이는 오래된 MAC-then-encrypt 구성을 선택 사항으로 두지 않고 프로토콜에서 제거합니다. IPsec ESP 도 같은 기간 인증된 암호화 스위트를 갖고 있으며 AES-GCM 은 자체 RFC 에 정의되어 있습니다. 두 패밀리 모두 보증은 패밀리 이름이 아니라 협상된 스위트에서 오며, 그래서 항목 목록이 버전으로 시작합니다. 스위트를 지목하지 못하는 검토자에게는 평가할 것이 없습니다.

그래서 역사적 비교는 오해를 낳습니다. CBC 스위트와 함께 오래된 TLS 버전에 고정된 배포와 AEAD 스위트로 TLS 1.3 을 실행하는 배포는 둘 다 TLS VPN 이지만 같은 보안 태세가 아닙니다. 같은 분열이 IPsec 쪽에도 현대 ESP 스위트와 구형 조합 사이에 있습니다.

의도한 구성이 아니라 협상된 값을 읽으십시오. 아래 명령은 동작 중인 엔드포인트와 동작 중인 터널이 실제로 합의한 것을 보여 줍니다.

openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sas

엔드포인트가 TLS 1.3 협상을 원하지 않는다면 그것은 선호가 아니라 발견 사항입니다. 터널이 예상하지 못한 스위트를 나열한다면 중요한 구성은 피어가 선택한 것이지 템플릿의 것이 아닙니다.

피어 신원은 별개의 질문입니다

검증된 피어 없이 암호화하면 트래픽은 관찰자로부터 보호되지만 연결에 응답한 상대에게 그대로 넘어갑니다. 피어 인증은 어떤 신원을 기대하는지, 어떤 신뢰 자료가 그것을 검증하는지, 답이 맞지 않을 때 클라이언트가 어떻게 행동하는지를 묻습니다. 인증서 체인, 고정된 키, 사전 공유 비밀은 각기 다른 운영 비용을 가진 세 가지 답입니다.

그다음 사용자나 장치에 대해 같은 질문을 하십시오. 기계를 인증하고 아무 사용자나 받아들이는 게이트웨이, 혹은 그 반대는 가정하지 말고 기록해야 할 특정한 태세를 갖습니다. 승인 후 적용되는 리소스 권한은 같은 항목의 일부입니다. 인증은 인가가 아니기 때문입니다.

호스트 이름과 인증서 검사를 유지하는 것이 로그인 창의 익숙함보다 중요합니다. 검증을 무시하도록 구성된 클라이언트는 귀하의 게이트웨이를 설득력 있는 모조품과 구별해 주는 유일한 단계를 없앤 것입니다.

제품이 노출하는 경계

클라이언트 없는 포털은 선택된 애플리케이션 작업을 게이트웨이를 통해 대리하므로 사용자는 네트워크가 아니라 인터페이스에 도달합니다. 전체 터널 클라이언트는 경로와 필터링 정책이 선택한 모든 것을 나르며 훨씬 큰 표면입니다. 둘을 프로토콜 강도로 비교하면 공격자가 그것을 통해 무엇에 닿을 수 있는지라는 차이를 놓칩니다. 하나는 애플리케이션 인터페이스를, 다른 하나는 라우팅된 네트워크를 노출하며 둘은 서로 다른 검토를 필요로 합니다.

어떤 서비스가 노출되었는지, 어떤 작업이 승인되었는지, 게이트웨이 자체가 무엇을 듣는지 물으십시오. 사용자 포털과 같은 주소에서 도달할 수 있는 관리 인터페이스는 배포상의 발견 사항이며 어떤 프로토콜 선택도 그것을 보상하지 못합니다.

애플리케이션별 범위는 표면을 더 좁히고 터널이 끊길 때의 실패 동작도 바꿉니다. 전체 터널 도달을 전제하는 설계는 앱별 설계가 모르는 방식으로 깨지며 지원 부담이 뒤따릅니다.

실패 결과와 수명 주기를 결정하십시오

인증이나 보호를 사용할 수 없을 때 무엇이 일어나는지는 검토에 속하는 정책 결정입니다. 차단된 결과와 공지 없는 직접 폴백은 결과가 다르며 그 차이는 기능 목록에서 보이지 않습니다. 의도한 동작을 그것이 보호하는 리소스 옆에 적으십시오.

게이트웨이의 패치와 지원 수명 주기, 활성화된 외부 기능, 클라이언트의 업데이트 경로를 포함하십시오. 올바른 프로토콜 선택이 잘못 배포된 서비스를 안전하게 만들지는 않으며 대부분의 사고는 스위트가 아니라 그 틈에 있습니다.

다섯 항목, 실패 정책, 수명 주기 책임자를 한 페이지에 쓰십시오. 그 페이지가 검토이며 프로토콜 패밀리 비교는 의견입니다.