마이크로세분화 환경에서 NGFW 기능 사용 살펴보기

거의 20년 동안 차세대 방화벽(NGFW)은 필수 보안 도구로 사용되어 왔습니다. 그러나 오늘날의 네트워크가 점점 더 복잡해짐에 따라 NGFW가 제공하는 경계 보호는 점점 더 관련성이 낮아지고 있는 문제를 해결합니다.

Illumio는 복잡한 네트워크에 필요한 보안을 제공하기 위해 두 기술을 결합하여 마이크로세그멘테이션 환경에서 NGFW 기능을 구현할 수 있는 가능성을 연구하고 있습니다.

1부에서는 차세대 방화벽(NGFW)의 역사, 가치, 과제에 대해 간략히 살펴보았습니다.

이 두 번째 글에서는 마이크로세그멘테이션 솔루션에 NGFW 기능의 하위 집합을 임베드하는 "만약에?" 시나리오에 대해 이야기해 보겠습니다. 다양한 사용 사례와 각 사례에 적합한 NGFW 기능에 대해 설명하겠습니다.

NGFW는 남북 트래픽에는 효과적이지만 동서 트래픽에는 어려움을 겪습니다.

NGFW는 네트워크의 경계를 보호한다는 개념을 중심으로 설계되었으며, 주로 유입되는 트래픽의 위협으로부터 보호하는 데 중점을 두고 있습니다. 네트워크 세계에서는 이러한 유형의 트래픽을 흔히 "북-남"이라고 합니다. 이 용어는 데이터 센터로 유입되는 트래픽이 위에서 아래로 또는 북쪽에서 남쪽으로 이동하는 인터넷 '버블'이 상단에 있는 네트워크를 그리는 광범위한 관행에서 유래했습니다. 데이터 센터 내부의 트래픽은 일반적으로 왼쪽에서 오른쪽 또는 오른쪽에서 왼쪽으로 측면으로 이동하는 것으로 그려지며, 따라서 흔히 "동-서"라고 합니다.

이 용어를 사용하면 1부에서 이야기한 것처럼 남북한 역할에 사용되는 NGFW의 강력한 사용 사례가 있다고 할 수 있습니다. 하지만 동서 방향의 사용 사례는 조금 덜 확실합니다. 이 두 번째 문장은 아마도 여러분의 목덜미에 털이 자랐을 테니 좀 더 구체적으로 설명해드리겠습니다.

방화벽에는 하드웨어, 유지보수/지원, 구성/모니터링의 세 가지 비용이 듭니다. 세 가지 범주 모두에서 높은 비용이 들지만, 남북 사용 사례의 경우 NGFW의 ROI는 매우 명확합니다. 이스트-웨스트의 경우 전체 NGFW 기능의 일부만 관련되어 있지만 공급업체는 전체 기능 세트를 사용하지 않는다고 해서 할인을 제공하지 않습니다. 전체 NGFW 어플라이언스를 구매하고 절반의 기능만 사용하는 것은 정당화하기 어려운 경우가 많으며, 법이나 규정에서 NGFW 기능 세트가 의무화되어 있지 않은 경우에는 더욱 그렇습니다.

남-북 트래픽을 위한 NGFW

이것이 NGFW의 좋은 사용 사례 중 두 가지이지만, 실제로 사람들이 거의 고려하지 않는 세 번째 사용 사례, 즉 네트워크 내부에서 아웃바운드 트래픽을 제어하는 남-북 사용 사례는 지나치는 경우를 제외하고는 거의 고려하지 않습니다. NGFW 공급업체는 이에 대해 이야기하지만, 조금만 이야기합니다. 그리고 대부분의 조직은 제한 없는 아웃바운드 연결의 위협을 인식하고 있지만 실제로 이를 해결하기 위한 노력은 매우 미미합니다. 수년 동안 많은 고객과 함께 일하면서 대부분의 조직에는 내부 애플리케이션 소유자가 네트워크 경계에서 아웃바운드 제어를 요청할 수 있는 프로세스조차 마련되어 있지 않다는 사실을 알게 되었습니다.

제 업무는 기본적으로 R&D이며, 'R' 부분에 중점을 두고 있습니다. 그런 맥락에서 사고 실험을 해보겠습니다. 잠시 남북 문제가 해결되었다고 가정해 보세요. 완벽한 솔루션(% )이 없다는 의미에서 문제가 해결된 것은 아니지만, 대부분의 조직이 더 이상 이러한 경로를 네트워크에 대한 주요 공격 경로로 간주하지 않는다는 의미에서 문제가 해결된 것입니다. 대신, 장비를 더 구입하거나 아웃바운드 NGFW 기능을 활용하지 못하게 하는 내부 조직 프로세스와 싸울 필요 없이 일부 NGFW 기능을 마이크로세그멘테이션 솔루션에 구현하고 동서 및 남북 NGFW 제어를 모두 개선할 수 있다면 네트워크의 보안이 어떻게 강화될 수 있을지 생각해 보시기 바랍니다.

남북 사용 사례와 동서 사용 사례는 서로 다르지만 상당 부분 겹치는 부분이 있습니다. 또한, 남북으로 나뉘어 있는 많은 기능들은 이 중 어느 쪽과도 관련이 없습니다. 동서 방향 사용 사례부터 시작하겠습니다.

앞서 말씀드렸듯이 제한된 범위의 이스트-웨스트 NGFW 제어에 대한 사용 사례는 분명 존재합니다. 비용을 고려할 때 본격적인 어플라이언스(또는 가상 어플라이언스)의 ROI는 의문일 수 있지만, 그럼에도 불구하고 그 필요성은 분명합니다. 네트워크에 PII, HIPPA 또는 PCI 데이터가 포함되어 있는 경우 해당 데이터 보호에 관한 법률 및 규정이 적용될 가능성이 거의 확실합니다. 대부분의 경우 여기에는 DLP(데이터 손실 방지) 및 IDS/IPS(침입 탐지/방지 서비스)와 같은 기존 NGFW 서비스를 구현해야 한다는 명시적인 요구 사항이 포함됩니다. 의무가 없더라도 모범 사례로 남아 있습니다. 애플리케이션 ID, 즉 포트와 프로토콜이 아닌 실제 트래픽 유형에 따라 트래픽을 차단하거나 허용하는 기능도 공격과 데이터 유출을 방지하는 강력하고 바람직한 도구입니다.

남쪽에서 북쪽으로 이동하는 사용 사례의 경우 몇 가지 추가 기능이 도움이 될 수 있습니다. DLP는 여전히 필요하고 애플리케이션 ID도 이 사용 사례에 똑같이 유용하지만, 여기에 URL 필터링과 대상 IP 평판 및 지역을 기반으로 트래픽을 제어하는 기능을 추가하고 싶습니다. 물론 보더 NGFW가 이미 이 작업을 수행할 수 있지만 앞서 지적했듯이 애플리케이션 소유자가 보더 디바이스를 제어하지 않는 경우 이러한 기능을 활용할 방법이 없는 경우가 많습니다. 그리고 대규모 데이터 센터 환경에서는 거의 사용하지 않습니다.

다른 대부분의 NGFW 서비스는 동서 또는 남북으로 제한되어 있습니다. DDoS와 QoS는 네트워크 내부에서는 거의 의미가 없습니다. 마찬가지로, OS 내에서 실행되는 최신 AV 소프트웨어는 네트워크 기반 솔루션보다 효율적일 수 있으므로 네트워크 기반 안티바이러스는 의제에 포함되지 않을 수 있습니다.

엔드포인트 디바이스에서 NGFW 기능의 성능

이제 엔드포인트에서 실행되는 NGFW 기능의 성능에 미치는 영향에 대해 이야기할 차례입니다. 기억하시겠지만, 1부에서 NGFW 어플라이언스는 상당한 성능을 얻기 위해 많은 특수 하드웨어를 갖춘 거의 슈퍼컴퓨터급 시스템이라고 언급했습니다. 동일한 기능을 구현할 때 개별 서버에 상당한 성능 페널티가 부과되는 것은 당연한 결과입니다. 다행히도 지금은 직관이 통하지 않는 시기 중 하나인 것 같습니다. 그 이유에 대해 이야기해 보겠습니다.

IDS/IPS는 시작하기에 좋은 제품입니다. 모든 NGFW 서비스 중에서 IDS/IPS는 "가장 무거운 서비스 중 하나로 간주되며(" ), 이는 불균형적인 수의 리소스를 소비하고 NGFW 어플라이언스에 많은 양의 맞춤형 실리콘을 사용하는 이유 중 하나입니다. 1,000개의 워크로드가 있는 중간 규모의 데이터 센터를 IDS/IPS 솔루션으로 보호하는 경우, 최소 12개의 서로 다른 운영 체제(Windows 2008, 2012, 2016, 2019, CentOS, RedHat, Ubuntu(의료 또는 은행업의 경우 Solaris 또는 AIX)의 최소 6가지 변형 및 버전)에 대한 IDS/IPS 서명을 지원해야 할 것입니다. 이 1,000개의 서버는 각각 적어도 하나의 서비스를 실행하며, 많게는 서너 개의 서로 다른 서비스를 실행하며, 모두 잠재적인 취약점을 가지고 있습니다. 그리고 운영 체제가 수십 개라면 서너 가지 서비스의 각기 다른 버전이 수십 개씩 실행될 수 있으며, 각기 다른 취약점이 있을 수 있습니다.

간단히 말해, 저는 그 수천 대의 머신에 대해 10,000~100,000개의 취약점 서명이 있는지 살펴보고 있습니다. 그리고 NGFW 네트워크 장치를 통해 흐르는 모든 패킷에서, 즉 작동할 수 있는 모든 포트에서 이러한 징후를 찾고 있습니다. 이는 데이터센터의 모든 서버에 부과하고 싶지 않은 부하가 분명합니다.

실제로는 그럴 필요가 없습니다. Linux 호스트에서 Windows 취약점을 찾을 이유가 없습니다. NGINX를 실행하는 머신에서 아파치2 취약점을 찾을 필요가 없습니다. Application X 버전 1.0, 1.1, 1.2, 1.3, 2.0, 2.1을 실행하는 시스템에서는 Application X 버전 2.2의 취약점을 찾을 필요가 없습니다.

모든 패킷에서 10,000~100,000개의 취약점을 찾는 대신, 4개 정도의 취약점을 찾습니다. 4,000명이 아닙니다. 4. 그리고 네 번째는 해결할 수 있는 문제입니다.

어떻게? 모든 서버에 에이전트를 배치함으로써 OS, 적용된 패치와 적용되지 않은 패치, 설치 및 실행 중인 소프트웨어(및 해당 소프트웨어의 버전), 특히 어떤 포트에서 통신하는지 파악할 수 있기 때문입니다. 탐지된 OS 및 소프트웨어 버전, 특히 관련 프로세스가 연결된 포트에서 특정 취약점을 찾습니다. 검색 공간을 4배 정도 줄였습니다. 그리고 컴퓨터 과학에서 4배수는 엄청나게 큰 숫자입니다. 이것이 어렵고 쉬운 것의 차이입니다.

DLP 및 URL 필터링과 같은 서비스에도 유사한 전략을 적용할 수 있습니다. 모든 서버의 모든 패킷을 필터링하여 제한된 DLP 콘텐츠를 확인하거나 모든 서버의 공개 주소에 대한 방대한 URL 또는 IP 정보 데이터베이스를 보유할 필요는 없습니다. DLP의 경우, 세분화 정책이 적용되는 것과 동일한 방식으로 워크로드 레이블을 기반으로 매우 특정한 서버 집합의 특정 콘텐츠만 검색합니다. URL 필터링의 경우, IP 특성에 대한 대규모 데이터베이스를 중앙 정책 관리 시스템에 보관하고 필요할 때 지연 시간이 짧은 LAN 연결을 통해 가져온 다음 후속 조회를 위해 로컬에 캐시할 수 있습니다. 대부분의 서버는 비교적 소규모의 동일한 서버 집합과 반복해서 통신합니다.

마이크로세분화 솔루션을 위한 NGFW 기능

마이크로세그멘테이션 솔루션에 NGFW 기능을 추가할 때 얻을 수 있는 가장 큰 이점 중 하나는 방화벽 정책과 마찬가지로 전체 VLAN 또는 서브넷이 아닌 필요한 곳에 정확하게 적용된다는 점입니다. 레이블 기반 정책을 사용하면 애플리케이션 소유자는 데이터센터에 넓은 붓으로 그림을 그리는 대신 필요한 곳에 매우 구체적인 서비스를 정확하게 적용할 수 있습니다. 특정 NGFW 기능은 필요한 서버에 대해서만 켜고 필요한 검사만 정확하게 수행할 수 있습니다. 이렇게 하면 특정 보안 요구 사항을 충족하는 데 필요한 오버헤드를 최소한으로 유지하여 보안, 성능 및 비용의 균형을 맞출 수 있습니다.

여기서 목표는 국경 NGFW 장치를 교체하는 것이 아니라는 점을 기억하세요. 오히려 서버 자체에서 실행되는 강력한 NGFW 기능의 하위 집합을 통해 기존 NGFW 솔루션이 아키텍처 또는 재정적으로 적합하지 않은 부분을 선택적으로 메우는 것입니다. 이러한 접근 방식을 통해 애플리케이션 소유자는 기존 솔루션으로는 불가능했던 아웃바운드 보안을 '소유'할 수 있을 뿐만 아니라 기존 솔루션으로는 비용이 많이 드는 상황에서도 이러한 기능을 제공할 수 있습니다.

미래 전망

이를 마무리하기 위해 미래를 더 자세히 살펴봅시다.

TLS 1.3은 2018년에 비준되었으며 암호화된 웹 및 기타 서비스를 위한 차세대 표준으로 서서히 자리 잡아가고 있습니다. 이에 대한 초기 반응은 "내 문제가 아니야" 또는 "그래서 뭐?"일 수 있습니다. 하지만 저는 이것이 매우 중요한 문제라고 주장하고 싶습니다. NGFW는 심층 패킷 검사(DPI) 없이는 대부분의 가용 서비스를 제공할 수 없습니다. 그리고 DPI가 어떤 식으로든 의미가 있으려면 데이터가 암호화되지 않은 일반 텍스트여야 합니다.

NGFW가 처음 시장에 출시되었을 때 웹 트래픽의 극히 일부만 암호화되었습니다. 시간이 지남에 따라 점점 더 많은 트래픽이 HTTPS 또는 암호화된 트래픽으로 이동했습니다. 오늘날 모든 웹 트래픽의 약 100% 은 암호화되어 있으므로 멀웨어, 바이러스, 데이터 유출 또는 기타 NGFW 서버에 대한 분석이 불가능합니다. 이를 위해 개발된 솔루션이 바로 TLS MiTM(중간자 개입)입니다.

TLS MiTM 설정은 개념은 간단하지만 다소 지루한 작업입니다. 솔루션에는 여러 가지 움직이는 부분이 있습니다. 먼저 조직에서 내부 TLS 인증서를 만듭니다. 공개 키는 조직 내의 모든 시스템(노트북, 데스크톱, 서버 등)에 푸시되며, 각 운영 체제는 해당 인증서를 신뢰하고 대상에 관계없이 모든 아웃바운드 통신을 암호화하는 데 사용하도록 구성됩니다. 그런 다음 개인 키는 투명한 웹 프록시로 구성된 경계 NGFW 장치에 배포됩니다.  

사용자(또는 서버 또는 기타 장치)가 외부 웹 사이트(이 예의 경우 gmail.com)에 아웃바운드 연결을 할 때 Google TLS 인증서를 사용하는 대신 조직의 내부 인증서로 트래픽을 암호화합니다. 경계 NGFW가 발신 트래픽을 확인하면 개인 키의 사본을 가지고 있기 때문에 트래픽을 해독하고 트래픽의 내용을 완전히 분석할 수 있습니다. NGFW는 내부 연결을 종료하고 Google 인증서를 사용하여 gmail.com에 대한 새 TLS 연결을 시작하고 두 연결(조직 내부의 내부 연결과 gmail의 외부 연결)의 콘텐츠를 프록시하므로 암호화되어 있더라도 모든 트래픽을 보고 분석할 수 있습니다.

이 방법은 번거롭고 CPU를 많이 사용하지만, SSL, TLS 1.0, 1.1, 1.2를 사용하는 약 10년 동안 대부분의 서비스에서 합리적으로 잘 작동했습니다.

지금까지는 괜찮습니다. 하지만 TLS 1.3은 판도를 바꿉니다. 첫째, TLS 1.3은 연결별 DH 키 교환의 형태로 완전 순방향 비밀성을 의무화합니다. 이 때문에 패시브 디바이스는 사용 중인 개인 키에 액세스할 수 있어도 페이로드를 해독할 방법이 없습니다. TLS 1.3에서는 스트림에 디바이스를 삽입하고 트래픽을 프록시하는 것이 필수입니다. 둘째, TLS 1.3은 보안 수준이 낮은 암호를 더 이상 사용하지 않으므로 프록시 장치가 프록시 연결을 TLS 1.2로 강등할 수 있는 기능이 제거되며, 이는 NGFW의 컴퓨팅 리소스를 절약하기 위해 자주 사용되는 일반적인 전략입니다(보안 수준이 낮은 암호는 일반적으로 계산이 덜 필요하기 때문).

% 암호화의 역사가 우리에게 가르쳐준 것이 있다면, 오래되고 신뢰할 수 있는 표준은 시간이 지나면서 거의 100% 확실하게 취약한 것으로 밝혀지는 경향이 있다는 것입니다. 리소스를 절약하기 위해 수동 복호화 및/또는 강등을 허용하기 위해 TLS 1.3을 TLS 1.2로 강등하는 현재 관행은 타이머가 설정되어 있으며 TLS 1.2가 더 이상 사용되지 않을 때까지 기다리는 중입니다. 그 날이 오면 수많은 수동 검사 장치는 값비싼 문진으로 전락할 것이고, 많은 인라인 솔루션은 계산 비용이 더 많이 드는 암호화를 사용해야 하기 때문에 빠르게 압도당하게 될 것입니다.

NGFW 세계의 더러운 비밀은 적어도 이 글을 쓰는 시점에서는 웹소켓 트래픽이 어떤 종류의 위협도 검사되지 않을 가능성이 높다는 것입니다. 왜 그럴까요? 일반적인 NGFW는 트래픽을 실시간으로 해독할 수 없기 때문입니다. 페이로드를 검사하려면 브라우저 내에서 (개발자 도구를 사용하여) 웹소켓 트래픽을 보거나 (비공개 키가 있다는 가정 하에) Wireshark와 같은 도구를 사용하여 사후에 캡처하고 해독해야 합니다. 웹소켓은 자바스크립트 애플리케이션이 브라우저와 웹 서버 간에 데이터를 주고받을 수 있는 훌륭한 솔루션을 제공하기 때문에 웹 애플리케이션에서 점점 더 보편화되고 있습니다. 말 그대로 웹소켓 연결을 통해 무엇이든 이동할 수 있으며, NGFW에는 완전히 불투명합니다.

마지막으로, 웹 트래픽에 QUIC을 사용하는 등 널리 퍼져 있는 다른 새로운 기술도 잊지 마세요. QUIC은 브라우저로 트래픽을 더 빠르고 효율적으로 전송할 수 있는 강력한 새 도구이지만 표준 TLS 암호화를 사용하지 않습니다. 즉, 인라인 NGFW는 모든 QUIC 트래픽을 차단하거나(TLS로 강제 다운그레이드) 트래픽이 검사되지 않고 통과할 수 있도록 허용해야 합니다. 첫 번째 솔루션은 사용자 경험의 품질을 떨어뜨리고, 두 번째 솔루션은 조직을 위험에 노출시킵니다. 어느 쪽도 이상적이지 않습니다.

워크로드 수준에서 일부 NGFW 작업을 처리하면 기존 NGFW 어플라이언스에 대한 투자 수명을 연장하는 데 도움이 됩니다. 워크로드 단위로 처리하여 계산 비용이 많이 드는 프로세스의 일정 부분을 오프로드할 수 있습니다. 이를 통해 고객은 네트워크 장치에서 검사 페이로드의 일부를 오프로드할 수 있으므로 필요한 방화벽 업그레이드가 지연되는 동시에 기술적 또는 재정적으로 합리적이지 않을 수 있는 네트워크 부분에 제로 트러스트의 이점을 제공할 수 있습니다.