SSL 솔루션 배포 시 주요 고려 사항

사회적 동물인 인간은 비밀을 지키는 데 어려움을 겪습니다. 우리는 정보 공유를 통해 생존하고 발전합니다. 그러나 일부 정보는 비밀로 유지되어야 하며, 스파르타 군대가 그리스와의 전쟁 중에 군사 정보를 보호하기 위해 전치 암호를 사용한 이래로 암호화가 어떤 형태로든 존재해 온 이유입니다.

개인 데이터를 비밀로 유지하는 과학이 한때 정부 정보 기관의 관할이었지만, 인터넷이 보편화되면서 개인 정보 보호는 모든 사람의 관심사가 되었습니다. 꾸준히 발생하는 데이터 침해에 직면하여 전 세계 기업은 온라인에서 개인 및 회사 데이터를 어떻게 보호할 것인가라는 문제를 가장 중요하게 여기게 되었습니다.  

불과 10년 전만 해도 대형 금융 기관과 정부 기관이 역사적으로 SSL(Secure Sockets Layer)로 알려졌고, 현재는 TLS(Transport Layer Security)라고 불리는 암호화 프로토콜을 주로 채택한 조직이었습니다. 오늘날 SSL은 어디에나 있습니다. 분석가들은 암호화된 트래픽이 2015년 29%에 불과했던 북미 온라인 트래픽 중 2016년에는 약 64%로 급증할 것으로 예측하고 있습니다.¹ 기업들은 이메일, 소셜 미디어, 스트리밍 비디오 등 모든 것을 포함한 대부분의 트래픽을 암호화하기 위해 노력하고 있습니다. 이러한 발전으로 웹 트래픽의 보안이 강화되지만, 그에 따른 대가도 치러야 합니다. SSL 트래픽의 증가로 인해 조직에서는 강력한 보안에 필요한 작업 부하 증가에 네트워크 인프라가 대응할 수 있도록 효율적인 SSL 솔루션을 구현해야 하는 부담을 안게 되었습니다.

많은 기업은 SSL이 제공하는 보안 수준에 매력을 느끼지만, 이를 언제 어디서나 사용할 수 있는 보안 프로토콜로 배포하는 데는 과제가 따릅니다. 동시에 공격자가 암호화된 트래픽을 볼 수 없는 보안 장치로부터 맬웨어를 숨기는 수단으로 SSL을 사용하기 시작하면서 SSL은 취약점 벡터가 되었습니다. 분산 서비스 거부(DDoS) 공격은 SSL 서버 트래픽을 호스팅하는 데 드는 비교적 큰 컴퓨팅 비용을 이용하기 때문에 특히 문제가 됩니다. 게다가 Heartbleed 사건과 같은 구현 문제로 인해 보안 침해가 발생할 수도 있습니다.

SSL을 올바르게 배포하는 것은 숙련된 관리자에게도 어려운 일입니다. 하지만 사이트 전체에 SSL을 배포하는 데 있어 가장 최신의 옵션과 추세에 대해 알아보면, 반응적 전략이 아닌 사전 예방적 전략을 선택하여 변화에 앞서 나갈 수 있습니다.

SSL에는 완벽한 전방 비밀성(PFS) 보호라는 수동적 감시 대책이 있는데, 이는 SSL 연결의 두 측면 간의 키 설정 프로토콜에 추가적인 교환을 추가합니다. PFS는 사용자가 시작하는 각 세션에 대해 고유한 세션 키를 생성함으로써 공격자가 단순히 단 하나의 키를 복구하여 이전에 녹음된 수백만 개의 대화를 해독할 수 없도록 보장합니다.

PFS를 도입하는 것은 간단해 보입니다. ADC(Application Delivery Controller)와 같은 SSL 종료 장치에서 PFS를 활성화하기만 하면 됩니다. 그러나 침입 방지 시스템(IPS)이나 침입 탐지 시스템(IDS)과 같은 수동 보안 장치를 사용하는 조직은 문제에 직면하게 될 수 있습니다. 이러한 장치는 종종 PFS가 사용하지 않는 영구 개인 키로 구성되어야 하기 때문입니다. 따라서 조직은 IPS/IDS를 끄거나 PFS를 끄는 것 중 하나를 선택해야 합니다. 두 가지 선택 모두 전반적인 보안 태세를 손상시킵니다.

또 다른 방법이 있습니다. IDS/IPS가 모든 SSL 트래픽을 웹 애플리케이션 방화벽이나 ADC와 같은 역방향 프록시로 오프로드하여 본래의 작업을 수행하도록 허용합니다. 그러면 역방향 프록시가 암호를 처리한 다음 복호화된 트래픽을 검사 및 살균을 위해 IDS/IPS로 전달할 수 있습니다.

당신이 할 수 있는 일: PFS를 활성화하여 데이터 무결성을 보호합니다. 또한 SSL 트래픽을 오프로드하고 네트워크 보안 장치의 작업을 최적화하기 위해 역방향 프록시를 배포하는 것을 고려하세요. 

HTTP Strict Transport Security(HSTS)를 활성화하는 것은 애플리케이션의 보안 태세를 개선하는 가장 쉽고 강력한 방법 중 하나입니다. HSTS는 HTTPS 트래픽에 헤더를 삽입하여 쿠키 하이재킹, 중간자 공격, 다운그레이드 공격을 포함한 여러 일반적인 공격 벡터로부터 보호 계층을 제공합니다. 현재 모든 주요 브라우저는 HSTS를 지원하므로, 이를 사용하면 모든 트래픽이 암호화된 상태를 유지할 수 있습니다.

당신이 할 수 있는 일: 하위 도메인에 대해 HSTS를 활성화하여 모든 도메인의 모든 페이지에 HSTS 헤더가 있는지 확인하세요. 해당 하위 도메인이 SSL 사용을 지원할 수 있는지 확인하세요. SSL 솔루션이 시스템 전체 HSTS 매개변수를 빠르고 쉽게 구성할 수 있는지 다시 한번 확인하세요. HSTS 헤더의 기간이 6개월 이상인지 확인하세요. 

애플리케이션을 관리하고 보안을 보장하려면 트래픽에 대한 가시성이 필요합니다. 즉, 웹 애플리케이션 방화벽(WAF), IPS/IDS, 차세대 방화벽(NGFW)과 같은 보안 장치에 해당 가시성을 제공할 수 있어야 합니다. 이를 통해 알려진 위협을 차단할 수 있습니다. 그러나 정의에 따르면 SSL은 보안 솔루션을 통해서도 통신 중인 데이터를 숨기지만, 여러 접근 방식은 악성 트래픽을 효과적으로 드러내는 동시에 보안을 유지합니다.

SSL 트래픽을 암호화하고 해독하는 데는 추가적인 컴퓨팅 능력이 소모됩니다. SSL이 성장함에 따라 네트워크 및 사용자 경험이 지연 및 성능 저하로 인해 영향을 받을 수 있습니다. 또한, 일부 계산 집약적 프로토콜은 현재 사용 중인 일부 보안 장치에서는 지원되지 않습니다. ADC는 TCP, HTTP, SSL에 대한 전체 프록시 역할을 하여 컴퓨팅 부담을 덜어줄 수 있습니다. 즉, ADC는 클라이언트(브라우저)에 하나의 연결을 만들고, 서버에는 별도의 연결을 만듭니다. SSL 프록시의 변형적 특성으로 인해 사이트는 애플리케이션 서버의 기능에서 분리된 SSL 기능을 제공할 수 있습니다.

당신이 할 수 있는 일: 확장 가능한 솔루션을 배포하세요. SSL 종료 작업을 ADC로 오프로드하면 성능, 키 보호 또는 가시성을 손상시키지 않고 일관된 SSL 정책을 시행하는 것이 간소화됩니다. 이를 통해 ADC가 백엔드 전송 옵션에 관계없이 웹 서버에 대한 인터페이스를 ADC가 지원하는 모든 프로토콜로 변환할 수 있으므로 유연성이 향상됩니다. 이를 통해 백엔드의 비즈니스에 중요한 레거시 장치와 애플리케이션은 변경 없이 계속 작동할 수 있으며, 동시에 강력한 대중 보안 태세를 유지할 수 있습니다.

또한 중앙 제어 지점이 있으면 새로운 취약점으로부터 보호하기 위해 사이트를 업데이트하는 프로세스가 간소화됩니다. 마지막으로, 하이브리드 아키텍처를 통해 인프라의 컴퓨팅 수요를 줄이고 가상 배포의 효과를 극대화하기 위해 가상 머신(VM)에서 하드웨어 장치로 SSL 처리를 오프로드할 수 있는 솔루션을 찾으세요.

보안 분석가들은 2017년까지 모든 신규 맬웨어가 SSL을 사용하여 이를 식별하고 무력화하도록 설계된 보안 장치의 추적을 피할 것으로 추정합니다. 기업에서는 스피어 피싱이나 맬웨어 활동과 같은 지능형 지속 위협(APT)을 완화하기 위해 아웃바운드 웹 트래픽을 모니터링하고 살균해야 합니다.

관리자가 이러한 위협을 감지하는 데 도움을 주기 위해 새로운 보안 장치가 끊임없이 개발되고 있습니다. 심층 방어 전략을 구현하면서 많은 관리자는 보안 장치를 체인 방식으로 배치하여 서로를 지원합니다. 그러나 SSL 작업은 이러한 장치의 효율성, 보안 및 성능을 저해합니다. 이러한 새로운 기술 중 다수는 암호화된 트래픽을 감지하지 못하거나 암호화된 트래픽을 검사할 때 성능이 크게 저하됩니다. 예를 들어 차세대 방화벽은 SSL을 활성화하면 최대 80%의 성능 손실을 경험할 수 있습니다. 맬웨어 및 스피어 피싱 작성자는 이 사실을 알고 있으며 맬웨어와 외부 세계 간의 모든 통신을 암호화하는 데 발 빠르게 움직이고 있습니다.

당신이 할 수 있는 일: 이러한 암호화된 위협에 맞서는 한 가지 방법은 SSL 에어갭 솔루션을 구축하는 것입니다. 이는 가시성 체인의 양쪽에 ADC를 배치하는 것으로 구성됩니다. 사용자에게 가장 가까운 ADC는 아웃바운드 트래픽을 해독하고, 해독된 통신을 보안 장치를 통해 전송합니다. 이제 콘텐츠를 보고 정책과 제어를 적용하여 맬웨어를 탐지하고 무력화할 수 있는 이러한 장치가 있습니다. 체인의 반대쪽 끝에서는 또 다른 ADC가 데이터 센터를 떠나는 트래픽을 다시 암호화합니다. 이 솔루션을 구축하면 보안 장치의 성능을 유연하게 유지하는 동시에 보안 장치가 본래의 기능을 수행할 수 있습니다.

한 가지 더 알려드릴 점은 다음과 같습니다. FireEye나 Cisco Sourcefire와 같은 가시성 스캐너를 사용하여 네트워크를 제로데이 익스플로잇 및 기타 악성 공격으로부터 보호하는 경우 SSL 솔루션이 이러한 보안 제품과 긴밀하게 작동하여 효율성을 극대화하는지 확인하세요.

SSL을 배포하는 데 따르는 복잡성과 많은 네트워크 장치가 암호화된 트래픽에 대한 가시성을 확보하는 데 겪는 어려움을 합치면 SSL은 DDoS 공격의 완벽한 대상이 됩니다. 공격자도 이 사실을 너무나 잘 알고 있습니다. 합법적인 SSL 트래픽의 전체 볼륨이 급격히 증가함에 따라 보안 장치에서 악성 DDoS 트래픽을 식별하는 것이 점점 더 어려워지고 있습니다.

당신이 할 수 있는 일: 포괄적인 SSL 솔루션을 통해 SSL 재협상 공격 및 SSL 플러드 등의 DDoS 공격을 완화하여 의심스러운 DDoS 트래픽을 효율적으로 식별하고 이로 인해 웹사이트 가용성에 영향이 미치지 않도록 방지합니다. SSL 기반 DDoS 공격의 영향을 완화하는 데 도움이 되는 클라우드 기반 DDoS 서비스를 조사해 보세요.

그러면 SSL 보안 태세가 적절한지 어떻게 알 수 있을까요? Qualys SSL Labs는 공격을 받기 전에 사이트의 인증서와 구성을 테스트할 수 있는 귀중한 도구를 제공합니다. 또한 브라우저의 SSL 구현을 평가하고 다른 사이트와 경쟁사가 빠르게 진화하는 SSL 과제에 직면하여 어떻게 대처하고 있는지 확인할 수도 있습니다.

하드웨어 보안 모듈(HSM)은 암호화 키를 보호하고 관리하기 위해 엄격한 FIPS 140-2 암호화 설계 지침을 따르는 별도의 소프트웨어 및 하드웨어 보안 장치입니다. 키가 HSM 외부로 전송되지 않으므로 Heartbleed 버그와 같은 SSL 취약점에 대해 걱정할 필요가 없습니다.

당신이 할 수 있는 일: SSL 키를 보호하는 가장 안전한 방법은 HSM을 사용하는 것입니다. ADC에 포함된 것과 같은 내부 HSM을 구매하는 등 여러 가지 가능성이 있습니다. 일부 조직에서는 HSM 장치를 중앙 키 저장소(예: 데이터 센터당 한 쌍)로 사용하여 키 관리를 통합합니다. 이러한 네트워크 HSM은 키 복호화가 필요한 서비스를 위해 내부 네트워크를 통해 접근할 수 있으므로 여러 SSL 종료 지점이 동일한 네트워크 HSM을 사용할 수 있습니다. 한 가지 주의 사항: SSL 솔루션이 네트워크 HSM에 원활하게 연결될 수 있는지 확인하세요.

조직에서는 SSL 키의 보안을 보장하기 위해 엔터프라이즈 키 및 인증서 관리(EKCM) 모범 사례를 구현합니다. 네트워크 파일 시스템에 암호문을 암호화된 형태로 저장할 수 있는 하드웨어 보안 암호화 키 저장 시스템을 사용하는 것을 고려하세요.

효과적인 EKCM 모범 사례의 기초는 모든 기업 인증서, 해당 위치 및 이를 관리하는 담당자에 대한 포괄적인 인벤토리를 만드는 것입니다. SSL이 활성화된 각 웹사이트에는 자체 인증서가 있으며, 각 인증서에는 자체 만료 날짜가 있습니다. 일주일 중에 하나 이상의 인증서가 만료될 수 있으며, 만료되면 관련 웹사이트나 애플리케이션을 사용할 수 없게 됩니다. 이 모든 인증서를 관리하는 것은 힘든 일이 될 수 있지만, 중요한 사이트의 높은 가용성을 보장하는 데 필수적입니다. 또한, SSL 인증서는 키 길이(2048비트 이상), 디지털 서명(SHA2 이상), 내부 PKI 또는 공개 루트 CA에서 생성되지 않은 사기 인증서에 대해서도 감사를 받아야 합니다. 마지막으로, PCI DSS를 준수하려면 문서화된 인증서와 키 관리 프로세스가 필요합니다.

당신이 할 수 있는 일: 중대형 조직의 관리자 대부분은 조직이 여러 곳에 키와 인증서를 보관하기 때문에 외부 인증서 관리 시스템을 선호합니다. 특히, 많은 사람들이 두 가지 외부 솔루션을 통해 성공을 거두었습니다. 베나피와 시만텍. 어떤 솔루션을 선택하든 관리를 자동화하고 운영 부하를 줄일 수 있는 개방형 API를 갖추는 것이 중요합니다.

규정 준수는 종종 SSL 도입의 원동력 이 됩니다. PCI DSS 사양을 준수하는 애플리케이션은 PCI 3.0을 준수하려면 향후 2년 동안 SSLv3 및 TLSv1 사용을 중단해야 합니다. 새로운 PCI DSS 배포에서는 이미 SSL 3.0 및 TLS 1.0을 비활성화해야 합니다.

당신이 할 수 있는 일: 먼저, 네트워크 방화벽이 ICSA Labs 인증을 받았는지 확인하세요. 또한 SSL 변환 서비스는 개별 서버에 정책을 시행할 필요 없이 인터넷 기반 SSL 정책을 준수할 수 있는 기능을 제공합니다. SSL 솔루션이 곧 출시될 TLS 1.3에 대비되었는지 확인하세요. 또한 각 개별 애플리케이션에서 문제를 해결하려고 하기보다는 ADC에 오프로드된 네트워크 서비스를 통해 규정 준수를 중앙화하면 실제 운영 효율성을 높일 수 있습니다.

¹ 샌드바인, 글로벌 인터넷 현상 스포트라이트: 인터넷 트래픽 암호화(https://www.sandvine.com/downloads/general/global-internet-phenomena/2015/encrypted-internet-traffic.pdf), 2015.