자연어를 활용하여 마이크로세분화 정책 정의 및 간소화하기

데이터센터나 클라우드의 세 가지 기본 리소스인 컴퓨팅, 스토리지, 네트워크 중 네트워크는 리소스 가상화 및 추상화라는 현대의 세계로 진화하는 속도가 가장 느렸습니다. 이는 대부분 의도된 것입니다. 네트워크 패브릭은 모든 데이터센터 또는 클라우드 아키텍처에서 가장 중요한 리소스라고 할 수 있습니다. 네트워크가 없으면 컴퓨팅과 스토리지는 도달할 수 없는 섬과도 같습니다. 네트워크는 모든 컴퓨팅 및 스토리지 리소스 간, 리소스 자체 간, 리소스의 최종 사용자와의 통신을 가능하게 하고 액세스를 허용합니다. 아키텍처의 기반이 되는 네트워크가 없다면 모든 클라우드 대화는 무의미합니다. 베어메탈에서 서버리스에 이르기까지 컴퓨팅 리소스에 대한 클라우드 대화를 아무리 추상화해도 그림의 어느 곳에든 IP 패킷이 있다면 네트워크는 중요합니다.

이제 네트워크 보안은 네트워킹 언어가 아닌 자연어를 사용하여 정의됩니다.

이는 상식이며, 네트워킹에는 특정 네트워킹 문제를 해결하기 위한 자체적인 형태의 리소스 가상화가 있습니다. 하지만 여기서는 데이터 센터 또는 클라우드 배포의 보안이 전통적으로 네트워크에서 구현되어 왔다는 단순한 사실에 대해 언급합니다. 클라우드 리소스 간에 전송되는 네트워크 트래픽을 차단하거나 활성화하기 위해 네트워크 패브릭의 어딘가에 방화벽이 배포됩니다. 엔드포인트 소프트웨어는 일반적으로 알려진 멀웨어나 나쁜 동작을 찾는 서명 기반 도구인 컴퓨팅 리소스에 배포될 수 있지만, 일반적으로 트래픽을 차단하거나 허용하는 것이 아니라 트래픽을 검사하는 역할을 합니다. 대부분의 워크로드에는 Linux의 iptables와 같은 일종의 기본 제공 방화벽 기능이 있지만 이러한 도구를 대규모로 오케스트레이션하는 것은 관리하기 어렵기 때문에 사용하지 않는 경우가 많습니다. 따라서 네트워크 보안 및 트래픽 시행은 전통적으로 네트워크 방화벽을 통해 이루어집니다.

보안은 종종 다른 언어로 정의됩니다.

방화벽은 일반적으로 네트워킹 팀에서 관리하기 때문에 보안 정책은 네트워킹 팀에 익숙한 용어를 사용하여 정의되는 경우가 대부분입니다. 방화벽은 수십 년 동안 존재해 왔으며 구성 방식은 수년 동안 거의 변하지 않았습니다. 정책 규칙은 일반적으로 IP 주소, TCP/UDP 포트, VLAN 및 영역을 사용하여 작성합니다. 방화벽은 일반적으로 네트워크 트래픽 병목 현상을 피하기 위해 패킷의 데이터 페이로드를 자세히 들여다보고 어떤 콘텐츠나 앱이 포함되어 있는지 검사하도록 설계되지 않습니다.

유선 속도에서 패킷을 훨씬 더 깊이 검사할 수 있고 네트워크 헤더뿐만 아니라 패킷의 데이터 페이로드에 실제로 포함된 내용에 대한 정책을 정의할 수 있는 차세대 방화벽(NGFW) 이 있습니다. 하지만 오래된 습관은 쉽게 고쳐지지 않기 때문에 이러한 방화벽은 차세대 옵션을 사용하지 않은 채 기존 방식으로 구성되는 경우가 많은 것이 현실입니다. 그 결과 데이터 센터나 클라우드에서 호스팅되는 리소스의 사용자가 인식하는 방식이 아닌 네트워킹 용어를 사용하여 네트워크 보안을 정의하는 장치가 탄생했습니다. 사용자는 리소스가 어떤 네트워크 세그먼트에서 호스팅되는지 모르거나 신경 쓰지 않는 경우가 많습니다. 그들은 리소스 자체에 관심이 있습니다.

네트워크 정책은 사용자가 보호 대상 리소스를 인식하는 방식을 반영해야 합니다.

사용자나 개발자가 데이터 센터나 클라우드에서 호스팅되는 리소스에 연결할 수 없는 등의 문제를 보고할 때는 일반적으로 연결할 수 없는 특정 워크로드나 애플리케이션을 언급합니다. 일반적으로 특정 포트를 통해 특정 IP 주소에 연결할 수 없다는 보고는 하지 않습니다. 단, 네트워킹 또는 보안 운영팀에서 이 정보를 요청할 수 있습니다. 여기서 문제가 발생합니다: 보고되는 문제가 네트워크 정책을 적용하는 디바이스와 다른 언어로 되어 있다는 것입니다. 애플리케이션 언어가 일반적으로 네트워크 언어와 같지 않습니다.

클라우드 아키텍처에서 가능한 한 많은 리소스를 자동화하는 데 있어 중요한 세부 사항 중 하나는 사용자가 보호 대상 리소스라고 인식하는 것과 동일한 용어를 사용하여 네트워크 정책을 정의할 수 있는 기능입니다. 방화벽이 애플리케이션 X, Y, Z 간에 정책을 적용하는 경우, 해당 애플리케이션이 호스팅되는 네트워크 리소스가 아닌 해당 애플리케이션에 특정한 정책을 정의할 수 있어야 합니다.

이는 IP 주소가 임시적인 마이크로서비스와 같은 최신 퍼블릭 클라우드 호스팅 인프라에서 특히 중요합니다. 워크로드와 애플리케이션은 여러 네트워크 세그먼트에 걸쳐 동적으로 마이그레이션되는 경우가 많으므로 IP 주소는 더 이상 해당 리소스의 수명 주기 동안 특정 워크로드를 식별할 수 있는 신뢰할 수 있는 방법이 아닙니다. IP 주소가 변경될 때마다 방화벽을 수정해야 하는 경우 확장성이 떨어집니다.

그 결과 방화벽이 최신 클라우드 아키텍처에 배포되지 않는 경우가 많습니다. 대신, 클라우드 패브릭의 경계에 앉아 대부분의 동서 트래픽을 차단한 채 남북 트래픽만 처리하는 역할로 강등됩니다.

IP가 아닌 메타데이터를 사용하여 보안 정의하기

대부분의 최신 SDN 컨트롤러는 각 워크로드에 적용되는 워크로드 IP 및 메타데이터의 로컬 데이터베이스를 생성할 수 있습니다. 예를 들어, 5개의 프로덕션 워크로드가 SQL 서버이고 다른 5개의 워크로드가 개발 SQL 서버인 경우 컨트롤러는 처음 5개의 워크로드 IP가 "SQL-Prod" 메타데이터 태그에 할당되고 두 번째 5개의 워크로드 IP가 "SQL-Dev" 메타데이터 태그에 할당되어 해당 서버를 두 가지 카테고리로 나열하는 로컬 레코드를 구축합니다. 컨트롤러는 이러한 워크로드를 모니터링하고, 어떤 이유로든 워크로드의 IP가 변경되거나 스핀다운되는 경우 메타데이터-IP 매핑의 로컬 레코드를 업데이트합니다.

이렇게 하면 컨트롤러는 할당된 IP 주소에 관계없이 할당된 메타데이터를 기반으로 워크로드의 전체 라이프사이클을 추적할 수 있습니다. 워크로드와의 패킷 포워딩은 현재 할당된 IP 주소를 사용하여 IP 조회를 통해 계속 수행됩니다. 그러나 해당 워크로드의 신원은 할당된 메타데이터에 의해 유지되며, 어느 네트워크 세그먼트에 할당되었는지에 관계없이 유지됩니다.

메타데이터를 사용하여 워크로드를 식별하면 해당 워크로드의 신원을 네트워킹 세부 정보로부터 완전히 추상화할 수 있으며, 이것이 바로 최신 보안이 정의되어야 하는 방식입니다. "개발 중인 SQL 서버는 프로덕션 중인 SQL 서버와 연결을 시작할 수 없음"과 같은 정책을 정의하는 것이 "192.168.10.0/24"와 같은 정책을 정의하는 것보다 사용자가 이러한 리소스를 인식하는 방식에 훨씬 더 가깝습니다. TCP 1024-2000 10.10.0.0/16 허가." 메타데이터 용어는 네트워킹 용어보다 사람이 훨씬 더 쉽게 읽을 수 있습니다.

메타데이터를 사용하여 리소스를 식별하는 것을 일반적으로 "태그" 또는 "레이블"이라고 합니다. 그리고 이 개념은 SDN 이외의 컨트롤러에서도 사용됩니다. Illumio ASP를 사용하면 각 워크로드에 라벨을 할당할 수 있으며, 각 라벨에는 네 가지 '차원'이 있습니다: 역할, 애플리케이션, 환경, 위치입니다. 각 워크로드에는 이러한 차원 중 하나 또는 전체에 대해 식별하는 레이블을 할당할 수 있으며, 이러한 레이블을 사용하여 정책을 정의할 수 있습니다. 따라서 Illumio 규칙 집합은 포트나 IP가 아니라 레이블을 의미합니다.

일루미오 라벨의 가치

레이블의 개념은 사소한 세부 사항처럼 보일 수 있지만 강조할 필요가 있습니다. 레이블을 사용하면 사용자가 보호 대상 리소스를 인식하는 방식과 동일한 용어를 사용하여 정책을 정의할 수 있습니다. 이는 기존의 네트워크 보안 정의 방식과는 크게 달라진 모습입니다. 수십 년 동안 네트워크 보안은 네트워킹 구성을 중심으로 정의되어 왔습니다: IP, VLAN, 포트가 바로 그것입니다. 방화벽은 이러한 네트워킹 구성의 렌즈를 통해 보안을 바라보며, 이러한 구성 중 하나라도 변경되면 방화벽 구성을 수정해야 합니다.

그러나 레이블을 사용하여 정책을 정의하고 이러한 레이블로 인해 워크로드의 기본 제공 방화벽 기능이 백그라운드에서 이 정의를 적용하도록 구성되면 이제 정책이 리소스가 실제로 사용되는 방식과 일치하게 됩니다. 이제 네트워크 보안은 네트워킹 언어가 아닌 자연어를 사용하여 정의됩니다. 그리고 이 자연어 정책은 한 번 정의되면 네트워크 패브릭 간에 워크로드가 마이그레이션되거나, 규모가 축소 또는 증가하거나, 대규모 배포로 확장되는 경우에도 그대로 유지됩니다.

보안이 워크로드 확장성 요구사항의 걸림돌이 되어서는 안 됩니다. 자연어를 사용하여 레이블을 사용하여 정책을 정의하면 보안을 유지하면서 DevOps 프로세스의 속도를 늦추지 않고 워크로드를 발전시킬 수 있습니다.

그래서 저는 레이블을 사용하고 있습니다: 이제 어떻게 할까요?

네트워킹 팀이 자연어 레이블을 사용하여 정책을 정의하는 데 익숙해지더라도 사람이 더 읽기 쉬운 언어를 만들기 위해 정책 정의의 사고방식은 여전히 네트워크 중심적인 경우가 많습니다. 레이블은 워크로드와 애플리케이션을 의미하지만, 네트워킹 팀은 여전히 신뢰 경계를 네트워크 경계로 생각합니다. 그러나 점점 더 많은 기업이 제로 트러스트 사고방식을 채택함에 따라 조직은 신뢰 경계를 네트워크에서 벗어나 레이블이 참조하는 리소스로 직접 확장해야 합니다. 5개의 SQL 워크로드가 있는 경우, 이러한 워크로드 각각은 자체적인 트러스트 경계가 됩니다. 신뢰 경계는 이들이 모두 공유할 수 있는 공통 네트워크 세그먼트가 아닙니다.

Illumio는 모니터링되는 모든 워크로드에 VEN이라는에이전트를 배포하고, 이 에이전트는 레이블 기반 정책을 각 워크로드의 기본 제공 방화벽에 있는 규칙으로 변환합니다. 따라서 패킷이 탄생하는 첫 번째 단계는 정책입니다. 제로 트러스트에 대해 생각하는 또 다른 방법은 "패킷이 검사되기 전에는 어떤 패킷도 네트워크 전달 영역에 도달해서는 안 된다"는 것입니다. 일루미오를 사용하면 패킷이 네트워크 포워딩 플레인에 도달할 때 이미 보안이 적용된 상태입니다.

이는 악의적인 공격자나 멀웨어가 탐지되지 않고 네트워크를 통과할 수 있는 측면 이동 문제를 해결하려고 할 때 특히 중요합니다. 예를 들어 원격 사용자와 보안 가이드라인에 대해 논의할 때 보안의 필요성은 인정하지만 "나는 숨길 것이 없다"는 답변이 일반적인데, 이는 워크로드 보안에 신경 쓰지 않는 정당화 근거로 사용되기도 합니다. 해당 사용자에게는 숨길 것이 없을지 몰라도 다른 사용자에게는 숨길 것이 있을 수 있습니다. 멀웨어는 종종 해당 워크로드에서 다른 워크로드로 이동하기 위한 특정 목적으로 워크로드를 침해하며, 그 대상은 더 가치 있는 리소스입니다. 이는 한 워크로드를 다른 워크로드를 위한 런치 패드로 사용하는 측면 이동입니다.

신뢰 경계가 네트워크 세그먼트이고 멀웨어가 해당 네트워크 세그먼트의 여러 워크로드 중 하나를 침해하는 경우, 네트워크 방화벽이 알아채지 못한 채 세그먼트를 공유하는 워크로드 간에 횡방향으로 이동할 수 있습니다. 네트워크 패브릭이 아닌 모든 워크로드에서 측면 이동을 방지해야 합니다.

레이블은 정책을 더 쉽게 이해하고 궁극적인 목표인 보안 솔루션을 보호하려는 대상에 집중할 수 있도록 하는 데 유용합니다. 클라우드 아키텍처의 한 계층에 의존하여 다른 계층을 보호하지 마세요. 신뢰의 경계는 워크로드가 어디에 있든 상관없습니다. 제로 트러스트는 모든 워크로드가 세그먼트이며, 모든 워크로드를 보호하면 측면 이동의 위험을 크게 줄일 수 있다는 의미입니다.

Illumio ASP에 대해 자세히 알아보고 라벨 제작에 대해 어떻게 생각하는지 알아보려면 여기를 확인하세요:

• 라벨의 힘에대한 새로운 동영상
• 일루미오 ASP 디자인 가이드