마이크로세그멘테이션 환경에서의 NGFW 기능 사용 살펴보기

거의 20년 동안 차세대 방화벽 (NGFW) 필수 보안 도구였습니다.그러나 오늘날 네트워크가 점점 더 복잡해짐에 따라 NGFW가 제공하는 경계 보호 기능은 점점 더 중요해지고 있는 문제를 해결합니다.

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

에서 첫 번째 부분, 차세대 방화벽 (NGFW) 의 역사, 가치 및 과제에 대해 개괄적으로 살펴보았습니다.

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

NGFW는 남북 교통에 적합하지만 동서 지역에서는 어려움을 겪습니다.

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

이 용어를 사용하면 1부에서 이야기한 것처럼 남북 역할에서 사용되는 NGFW의 강력한 사용 사례가 있다고 할 수 있습니다.하지만 동서 지역의 활용 사례는 좀 덜 확실합니다.이 두 번째 문장 때문에 아마도 목 뒤쪽에 털이 좀 올라왔을 수도 있습니다. 그래서 좀 더 구체적으로 설명하겠습니다.

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

남북 트래픽을 위한 NGFW

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

제 업무는 기본적으로 R&D이며, 주로 “R” 부분에 중점을 두고 있습니다.그런 맥락에서 사고 실험을 해봅시다.잠깐, 해결된 남북 문제를 생각해 봅시다.100% 완벽한 해결책이 없다는 점에서 해결된 것은 아니지만, 대부분의 조직이 더 이상 이 경로를 네트워크에 대한 주요 공격 수단으로 여기지 않는다는 의미입니다.대신, 장비를 추가로 구매하거나 아웃바운드 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 어플라이언스에 맞춤형 실리콘이 많이 사용되는 이유 중 하나입니다.IDS/IPS 솔루션으로 1,000개의 워크로드로 구성된 중간 규모의 데이터 센터를 보호하려면 최소한 12개의 서로 다른 운영 체제 (Windows 2008, 2012, 2016, 2019, CentOS, RedHat 및 Ubuntu의 변형 및 버전 6개 이상 (의료 또는 은행 분야의 경우 솔라리스 또는 AIX 포함) 에 대한 IDS/IPS 시그니처를 지원해야 할 것입니다.1,000대의 서버 각각은 필자가 주시하고 싶은 서비스를 하나 이상 실행하고 있습니다. 각각 많게는 3~4개의 서로 다른 서비스를 실행하는데, 모두 잠재적인 취약점을 가지고 있습니다.운영 체제가 십여 개라면 3~4개 서비스 각각에 대해 각각 다른 취약점을 지닌 12가지 버전을 실행하고 있을 수도 있습니다.

간단히 말해서, 저는 그 천 대의 시스템에 대해 10,000~100,000개의 취약점 시그니처를 주시하고 있습니다.그리고 저는 NGFW 네트워크 디바이스를 통과하는 모든 패킷, 즉 작동할 수 있는 모든 가능한 포트에서 이러한 징후를 찾고 있습니다.데이터 센터의 모든 서버에 이러한 부하를 부과하려는 것은 분명 아닙니다.

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

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

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

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

마이크로세그멘테이션 솔루션을 위한 NGFW 기능

에 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에 대한 프록시 연결을 강등할 수 없게 합니다. 이는 보안이 낮은 암호일수록 일반적으로 계산이 덜 필요하기 때문입니다.

암호학의 역사가 우리에게 가르쳐 준 것이 있다면 오래되고 신뢰할 수 있는 표준은 시간이 지남에 따라 거의 100% 확실하게 취약한 것으로 밝혀지는 경향이 있다는 것입니다.리소스 절약을 위해 수동적 암호 해독 및/또는 강등을 허용하기 위해 TLS 1.3을 TLS 1.2로 강등하는 현재의 관행은 아직 시간이 지나지 않아 TLS 1.2의 지원이 중단되기만을 기다리고 있습니다.그 날이 오면 대다수의 수동 검사 장치는 값비싼 문진으로 전락할 것이며, 많은 인라인 솔루션은 계산 비용이 더 많이 드는 암호화를 사용해야 한다는 이유로 순식간에 어려움을 겪게 될 것입니다.

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

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

워크로드 수준에서 일부 NGFW 작업을 처리하면 기존 NGFW 어플라이언스에 대한 투자 수명을 연장하는 데 도움이 됩니다.이를 통해 컴퓨팅 비용이 많이 드는 프로세스를 워크로드별로 처리함으로써 일정 비율의 부담을 덜 수 있습니다.이를 통해 고객은 네트워크 장치에서 검사 페이로드의 일부를 오프로드하여 필요한 방화벽 업그레이드를 지연시키는 동시에 기술적으로나 재정적으로 의미가 없을 수 있는 네트워크 부분에 제로 트러스트의 이점을 제공할 수 있습니다.