자연어 활용을 통한 마이크로세그멘테이션 정책 정의 및 간소화

데이터 센터 또는 클라우드의 세 가지 기본 리소스 (컴퓨팅, 스토리지, 네트워크) 중에서 네트워크는 최신 리소스 가상화 및 추상화 세계로 발전하는 데 가장 느립니다.이는 대체로 설계에 의한 것입니다.네트워크 패브릭은 모든 데이터 센터 또는 클라우드 아키텍처에서 가장 중요한 리소스라고 주장할 수 있습니다.네트워크가 없으면 컴퓨팅과 스토리지는 도달할 수 없는 고립입니다.네트워크를 통해 모든 컴퓨팅 및 스토리지 리소스 간의 액세스와 통신, 그리고 해당 리소스의 최종 사용자와의 통신이 가능합니다.아키텍처의 기반이 되는 네트워크가 없으면 모든 클라우드 대화는 의미가 없습니다.베어메탈에서 서버리스에 이르기까지 컴퓨팅 리소스에 대한 클라우드 대화를 아무리 추상화하더라도 그림 어느 곳에나 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 조회를 사용하여 수행됩니다.하지만 워크로드의 ID는 할당된 네트워크 세그먼트에 관계없이 할당된 메타데이터에 의해 유지됩니다.

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

메타데이터를 사용하여 리소스를 식별하는 것을 일반적으로 “태그” 또는 “레이블”이라고 합니다.그리고 이 개념은 SDN 이외의 컨트롤러에서도 사용됩니다.와 함께 일루미오 ASP, 각 워크로드에 레이블을 할당할 수 있으며, 각 레이블에는 역할, 애플리케이션, 환경 및 위치라는 네 가지 “차원”이 있습니다.각 워크로드에 이러한 차원 중 하나 또는 전체를 기준으로 워크로드를 식별하는 레이블을 할당할 수 있으며, 그런 다음 해당 레이블을 사용하여 정책을 정의할 수 있습니다.따라서 Illumio 규칙 세트는 포트나 IP를 참조하지 않고 레이블을 참조합니다.

일루미오 라벨의 가치

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

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

보안이 워크로드 확장성 요구 사항을 가로막는 장애물이 되어서는 안 됩니다.레이블을 사용하여 자연어를 사용하여 정책을 정의하면 보안으로 인해 DevOps 프로세스가 느려지지 않으면서 워크로드를 발전시킬 수 있습니다.

그래서 라벨을 사용하고 있습니다. 이제 어떻게 될까요?

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

Illumio는 다음과 같은 에이전트를 배포합니다. 벤s, 모니터링되는 모든 워크로드에서 이러한 에이전트는 레이블 기반 정책을 각 워크로드의 내장 방화벽에 있는 규칙으로 변환합니다.따라서 패킷 생성 시 첫 번째 단계는 정책입니다.제로 트러스트에 대한 또 다른 생각은 “검사를 거치기 전까지는 어떤 패킷도 네트워크 포워딩 플레인에 도달해서는 안 된다”는 것입니다.Illumio를 사용하면 패킷이 네트워크 포워딩 플레인에 도달하면 이미 보안이 적용된 것입니다.

이는 다음과 같은 문제를 해결하려고 할 때 특히 중요합니다. 측면 이동이를 통해 악의적인 행위자 또는 맬웨어가 탐지되지 않은 상태로 네트워크를 통과할 수 있습니다.예를 들어 원격 사용자와 보안 지침을 논의할 때는 일반적으로 보안의 필요성이 인식되지만 일반적으로 “숨길 것이 없습니다”라는 반응이 나오는데, 이는 워크로드 보안에 신경 쓰지 않는다는 근거로 사용됩니다.그 사용자는 숨길 것이 없을 수도 있지만 다른 사람은 숨길 수 있습니다.멀웨어는 해당 워크로드에서 다른 워크로드로 이동하기 위한 특정 목적을 위해 워크로드를 침해하는 경우가 많으며, 목적지가 더 중요한 리소스가 됩니다.이는 한 워크로드를 다른 워크로드의 출발대로 사용하는 횡방향 이동입니다.

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

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

Illumio ASP와 라벨링에 대한 우리의 생각에 대해 자세히 알아보려면 다음을 확인하세요.

• 의 새 비디오 라벨의 힘
• 더 일루미오 ASP 디자인 가이드