‘Zscaler가 도대체 무엇인가요?’라고 많은 분들이 질문하십니다. 필자는 우선, ‘클라우드에 존재하는 인터넷 프록시’라고 대답합니다. Zscaler의 실체를 잘 아시는 분들이라면 전적으로 동의하기보다는 인터넷 프록시 외에도 수많은 기능이 있지 않냐고 반문하실 겁니다. 그러나 Zscaler를 처음 접하시는 분들에게, 좀 더 쉽게 그 개념을 한 번에 파악하는 데 도움되는 설명이라는 점에서는 큰 이견이 없으실 겁니다. 왜냐하면, Zscaler ZIA(Zscaler Internet Access)는 DLP(Data Loss Prevention), Malware Protection, Sandbox 등 여러 보안 기능을 포함하고 있지만, 그중 인터넷 프록시는 가장 중심이 되는 보안 기능이기 때문입니다.
웹 세션을 암호화하면 인터넷을 통해 전송되는 데이터가 보이지 않도록 보호할 수 있습니다. 인터넷 전반에 걸쳐 SSL 암호화 사용이 증가하고 있습니다. Salesforce나 Google Apps와 같은 기업 애플리케이션의 절반 이상이 이미 SSL을 사용하고 있으며, Facebook 및 Gmail과 같은 많은 Social Networking Application도 마찬가지입니다. 반면, 악성코드 유포지, Malware, Compliance와 관련한 위험에 대한 사각지대가 만들어지는 셈입니다. 어떤 내용인지 파악할 수 없기 때문입니다. 그래서 인터넷 프록시 보안 장비는 SSL 트래픽을 ‘열어보고’, 검토한 후, 다시 암호화하여 인터넷으로 보내는 기능을 가지고 있습니다. 바로 SSL Inspection입니다.
Zscaler 또한 SSL Inspection 기능을 제공합니다. 이번 아티클에서는 그 기능과 메커니즘 그리고 한계점에 대해 알아보고자 합니다.
SSL Inspection이란
우선, SSL Protocol이 무엇인지 알아볼 필요가 있습니다. SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security)는 두 지점 간의 데이터 암호화 및 전송을 제어하는 암호화 프로토콜입니다. 그러면, 이 두 프로토콜은 무엇이 다를까요? 과거 웹 태동기에 인터넷 브라우저로 유명했던 Netscape는 1990년대 중반에 SSL을 개발했고, 1996년에 SSL 3.0을 출시했습니다. SSL 3.0 버전을 기반으로 하는 TLS 1.0은 1999년에 출시되었습니다. 2018년 IETF(Internet Engineering Task Force)가 발표한 TLS 1.3이 현재 시점에서 가장 최신 버전입니다. 이제, SSL은 더 이상 개발되거나 지원되지 않습니다. 2015년까지 IETF는 취약성과 중요 보안 기능 부족을 사유로, SSL이 더 이상 사용되지 않는다고 했습니다. 그러나 많은 사람들이 이러한 엄격한 기술적 정의와 상관없이 여전히 ‘SSL’이라는 단어를 사용하고 있습니다. SSL, TLS, SSL/TLS, HTTPS 등을 볼 때 대부분의 경우 모두 동일한 의미를 갖는다고 생각하셔도 큰 무리가 없습니다.
SSL Inspection이란 말 그대로, SSL 트래픽을 검사하는 것입니다. 암호를 풀어서 판독 가능한 평문으로 만들고 나서 검사하는 것입니다. 그렇다면 어느 수준까지 SSL Inspection을 수행해야 하는 것일까요? On-premise 기반의 SSL Inspection을 수행하는 보안 장비를 -보통 어플라이언스(Appliance)라고 부릅니다- 보유하고 있는 회사는 여전히 일부 트래픽에 대해서만 SSL Inspection을 수행하고 ‘신뢰할 수 있는 사이트’를 대상으로 한 트래픽은 검사하지 않는 경우가 꽤 있습니다. 안타깝게도 이것만으로는 부족합니다. 인터넷은 시시각각 빠르게 변경될 수 있기 때문입니다. 또한, 악성 프로그램을 만드는 사람들은 자신들의 행위를 숨기기 위해 암호화를 점점 더 많이 악용하고 있습니다. 더욱이 전 세계에 수많은 SSL 인증기관이 있어서 유효한 서명된 인증서를 쉽고 저렴하게 얻는 것은 그리 어려운 일이 아닙니다. 그렇기 때문에 가능한 범위에서 모든 사이트를 대상으로 SSL 트래픽을 Inspection하는 것이 가장 안전하다고 할 수 있습니다. (그럼에도 불구하고, SSL Inspection을 부분적으로 수행하고, 일부는 우회시키는 까닭은 보유 중인 장비의 용량을 고려한 고육책인 경우가 대부분입니다. 고가의 보안 장비를 즉시 투자하기란 어려운 일입니다. 만일 부족한 용량의 장비를 가지고 SSL 트래픽의 복호화, 검사 및 재암호화를 수행한다면 네트워크 성능에 큰 영향을 미칠 수 있습니다.)
이제 SSL Inspection은 대부분의 웹 트래픽이 암호화되어 있는 현재 상황에서 필수적인 네트워크 보안으로 자리 잡았습니다. 많은 보안 분석가들이 악성 프로그램의 대부분은 암호화된 채널에 숨어 있을 수 있다고 주장합니다. SSL Inspection을 하는 이유는 궁극적으로 최종사용자와 그 데이터를 안전하게 보호하기 위함입니다. 암호화된 트래픽을 열어 확인해 봄으로써, 숨겨진 악성 프로그램이나 악성코드 유포지를 찾아내어 해커의 악의적 의도를 사전에 차단할 수 있고, 의도적이든 아니든 임직원이 외부로 정보 유출을 시도하고 있는지 그 내용을 확인할 수 있습니다. 그리고 Compliance 요구사항 충족 여부를 판단하여 그 위반으로 인해 개인 또는 회사가 위험에 빠지지 않도록 해 줄 수 있습니다.
Zscaler의 SSL Inspection 수행 방법
Zscaler의 SSL Inspection 수행 방법은 일반적으로 MITM(Man In To Middle) 공격 방법을 응용한 것입니다. MITM은 흔히 정상적인 연결 경로에 공격자가 개입하는 악의적인 공격으로 많이 알려져 있습니다. Zscaler를 비롯한 보안 솔루션 벤더들은 이 악의적인 공격 방법을 유익한 방향으로 승화했다고 할 수 있습니다.
- User(Client)
- Original Certificate →
- Hacker
- FAKE Certificate →
- Destination(Sever)
실제로 Zscaler가 SSL Inspection을 수행하는 프로세스는 다음과 같습니다. MITM과 차이점은 가운데 위치한 객체가 해커가 아닌 신뢰할 수 있는 Zscaler라는 점입니다.
[그림 2] Zscaler SSL Inspection 프로세스
① 사용자가 브라우저를 열고 HTTPS를 요청합니다.
② Zscaler 서비스가 HTTPS 요청을 가로챕니다. Zscaler 서비스는 별도의 SSL 터널을 통해 목적지 서버에 자체 HTTPS 요청을 보내고 SSL Negotiation을 수행합니다.
③ 목적지 서버는 자신의 인증서를 공용 키와 함께 Zscaler 서비스에 전송합니다.
④ Zscaler 서비스와 목적지 서버가 SSL Handshake를 완료합니다. Application 데이터와 이후 메시지는 SSL 터널을 통해 전송합니다.
⑤ Zscaler 서비스는 사용자의 브라우저와 SSL Negotiation을 수행합니다. Zscaler는 사용자 브라우저에 Zscaler 중간 인증서(혹은 사용자가 속한 조직이 이용하는 사용자 고유의 인증서)와 Zscaler 중간 CA(Certificate Authority, 인증기관)가 서명한 서버 인증서를 브라우저에 보냅니다. 브라우저는 브라우저의 인증서 저장소에서 인증서 체인의 유효성을 검사합니다.
⑥ Zscaler 서비스와 브라우저가 SSL Handshake를 완료합니다. Application 데이터와 이후 메시지는 SSL 터널을 통해 전송합니다.
Zscaler가 제공하는 SSL Inspection을 사용하면, 변화하는 트래픽 수요를 충족하도록 인프라를 탄력적으로 확장하는 서비스를 통해 사용자의 SSL 트래픽을 검사할 수 있습니다. 클라우드 서비스의 Auto Scale-up을 연상하시면 됩니다. Zscaler Cloud에 Upload된 인증서는 전 세계에 위치한 Zscaler 데이터센터에서 즉시 사용할 수 있습니다. 세분된 정책 제어가 가능합니다. 개인정보 등 민감 데이터가 포함된 의료 또는 은행과 같은 중요한 웹사이트 범주에 대해서는 암호화된 사용자 트래픽을 대상으로 SSL Inspection을 제외할 수 있습니다. 또한 고객이 원한다면 고객이 속한 조직이 이용하는 자체 인증서를 사용할 수 있고 API를 사용하여 인증서를 필요할 때마다 쉽게 교체할 수도 있습니다.
SSL Inspection 한계 및 완화 방안
모든 SSL 트래픽을 Inspection할 수는 없습니다. Certificate Pinning 이슈가 있기 때문입니다. Certificate Pinning이란 SSL 인증서와 애플리케이션 사이에 다른 인증서를 집어넣는 행위를 차단하기 위해 Client와 Server 사이에 SSL 통신을 할 때 사용하는 인증서를 Destination Server에 Pinning(고정)시킨다는 의미입니다. 즉, 지정된 CA 외의 나머지 인증서들을 거부하도록 합니다. 실제로 SSL Inspection이 적용된 상황에서 Certificate Pinning이 적용된 사이트에 접속하면 SSL Handshake를 하는 과정에서 수신된 CA를 찾을 수 없다는 에러를 띄워 줍니다. 이런 경우는 부득이하게도 SSL Inspection을 할 수가 없습니다. 그래서 Zscaler에는 이러한 애플리케이션을 대상으로 SSL Inspection을 예외 처리할 수 있는 기능이 있습니다. 단, 예외 처리는 인터넷 보안 프로세스에 근거하여 진행할 것을 권장합니다. 예를 들어, SSL Inspection 예외 처리가 필요한 경우, 보안 부서와 부서장의 승인을 거쳐, 업무 목적에 필요한 사용자들 대상으로만 허용하는 것이 바람직하겠습니다.
- User(Client) →
- Zscaler →
- Destination(Sever) - 지정된 인증서 ! (non-negotiable)
어플라이언스 형태의 프록시 제품 또한 SSL Inspection 기능을 가지고 있습니다. 이미 서두에서 어플라이언스 프록시를 통해 SSL Inspection을 하는 경우, 증가하는 인터넷 트래픽의 용량에 동적으로 대응하기 어렵기 때문에 ‘신뢰할 수 있는 사이트’는 예외 처리를 하는 경우가 많다고 언급한 바 있습니다. 그럼에도 불구하고 어플라이언스 형태의 프록시 제품에는 장점이 하나 있는데, 그것은 복호화된 트래픽 Stream을 다른 로깅 시스템으로 전달하는 기능입니다. 트래픽의 분석 및 보관, Forensic 목적을 충족시키기 위해서입니다. Zscaler와 같은 Cloud Type의 보안 솔루션은 SSL Inspection을 통해 보안과 관련한 목적을 달성하는 반면, 그 복호화된 트래픽을 Steaming해 주는 기능은 아직 없습니다. Zscaler가 클라우드 서비스라서 복호화된 트래픽을 클라우드상의 데이터 저장 공간으로 전달해 줄 수 있다면 매우 유용할 것 같습니다. 많은 사용자들이 그 기능을 지속적으로 요구하고 있어 가까운 미래에 해당 기능이 보강될 것을 기대해 봅니다.
인터넷 보안을 강화하기 위한 방편으로, 이제 SSL Inspection은 사실상 필수 기능으로 자리매김했다고 할 수 있습니다. 클라우드 시대인 만큼 보안 장비 또한 On-premise형과 Cloud 형의 장단점과 각 기업의 보안 정책, 그리고 예산 등을 종합적으로 고려하여 선택하여야 할 것입니다.
삼성SDS는 지난 20년 가까이 삼성 관계사와 기업 고객들을 대상으로 업무 환경을 분석하여 최적의 보안 시스템을 구축하는 서비스를 제공하고 있습니다. 인터넷 트래픽 모니터링 및 악성코드 분석을 통해 인터넷 보안 위협에 신속하고 정확하게 대응할 수 있도록 노력하고 있습니다.
언제든지 문의해 주세요. 삼성SDS가 도움 드리겠습니다.
References
[1] Zscaler Help Portal: https://help.zscaler.com/
[2] Proxy E TAP(Symantec Encrypted Tap): https://docs.broadcom.com/doc/encrypted-tap-en
▶ 해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶ 해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.
삼성SDS 클라우드보안서비스그룹
Secure Web Gateway 솔루션인 Zscaler 구축 및 운영 업무를 담당하고 있습니다. Zscaler는 전자를 비롯한 여러 관계사가 사용 중입니다.