네트워크가 워크로드 세분화의 걸림돌이 되지 않도록 하세요.

보안과 네트워킹은 오랫동안 우선 순위가 상충되는 문제였습니다. 기존 데이터센터나 하이브리드 클라우드 패브릭을 설계할 때 네트워크 아키텍처의 우선 순위는 트래픽을 안정적이고 탄력적으로 전송하는 것입니다. 네트워크는 모든 데이터센터 또는 클라우드 아키텍처에서 가장 중요한 리소스일 것입니다. 결국 워크로드, 클라이언트, 데이터베이스는 그들 사이에 네트워크가 없으면 서로 통신할 수 없습니다. 그리고 모든 네트워크는 패킷의 헤더와 기타 다양한 지표를 분석하여 포워딩 결정을 내리는 방식으로 운영됩니다. 또한 라우터와 스위치는 패킷의 데이터 페이로드에 깊이 포함된 애플리케이션별 세부 정보에 크게 영향을 받지 않는 레이어 2 및 레이어 3 개념에 대한 정보를 교환합니다. 네트워크는 주로 트래픽에 어떤 애플리케이션 데이터가 포함되어 있는지가 아니라 트래픽을 안정적이고 빠르게 이동시키는 데 중점을 둡니다.

그렇다면 이러한 애플리케이션과 워크로드를 보호할 때 왜 여전히 네트워크에 연결된 접근 방식을 고려해야 할까요? 네트워크가 더 이상 민첩한 워크로드 전송, 자동화 및 보안에 걸림돌이 되지 않도록 접근 방식을 발전시키는 방법을 살펴보세요.

최신 워크로드의 내부 작동 방식

모든 네트워크를 통해 통신하는 워크로드는 애플리케이션별 우선순위에 따라 통신하도록 설계되어 있습니다. 워크로드가 수행하는 작업은 기본 네트워크 패브릭이 어떤 모습인지보다 더 중요합니다. 클라이언트는 워크로드와 통신하고, 워크로드는 일반적으로 네트워크 패킷 헤더에 포함된 세부 정보에 의존하지 않는 개념을 기반으로 데이터베이스와 통신합니다.

기존의 베어메탈 워크로드와 달리 최신 워크로드는 대부분 기본 네트워크 또는 서버 리소스 위에 추상화되어 있습니다. 모든 기본 리소스에 대한 워크로드의 존재는 일시적이며 호스트, 데이터센터, 클라우드 간에 동적으로 라이브 마이그레이션할 수 있다고 가정합니다. 이러한 마이그레이션은 일반적으로 사람의 수동 지시 없이 동적으로 이루어집니다. 이처럼 워크로드가 기본 리소스 위에 추상화되어 있기 때문에 워크로드의 IP 주소를 해당 워크로드의 수명 기간 동안 유용한 형태의 ID로 간주하는 것은 더 이상 현실적이지 않습니다. 워크로드는 수명 주기 동안 다양한 IP 주소를 가질 수 있으며, 이는 최신 네트워크에서 보안 경계를 정의하는 방식에 직접적인 영향을 미칩니다.

기존 네트워크 세분화 및 방화벽

네트워크 패브릭의 중요한 특성으로 인해 네트워크의 변경은 설계상 전통적으로 느립니다. 많은 데이터센터 네트워크는 대체로 평평하며, 많은 퍼블릭 클라우드 네트워크 패브릭에는 대략적인 수준의 세분화만 포함되어 있습니다. 어떤 환경에서든 네트워크를 세그먼트화할 때는 일반적으로 DMZ, WAN 세그먼트, 캠퍼스 세그먼트 또는 기존 웹/앱/개발 세그먼트와 같은 광범위한 범주의 리소스를 격리하는 등 네트워크별 우선순위에 따라 수행합니다. 네트워크를 세그먼트화하는 다른 이유는 네트워크 성능 최적화, 처리량 증가, 경로 중복성 구현 또는 경로 요약, 스패닝 트리 및 ECMP와 같은 작업을 보다 효율적으로 수행하기 위해서입니다.

네트워크 세그먼트는 전통적으로 레거시 '언더레이' 네트워크 또는 SDN 컨트롤러와 VXLAN과 같은 터널링을 사용하여 구현된 '오버레이' 네트워크에 걸쳐 VLAN 및 서브넷을 생성하여 구현됩니다. 토폴로지가 언더레이인지 오버레이인지에 관계없이 이러한 모든 네트워크 세그먼트는 하드웨어 또는 가상의 라우터 또는 스위치에서 종료됩니다. 그리고 이러한 세그먼트 전반에 걸쳐 보안을 구현하는 것은 일반적으로 네트워크 방화벽을 사용하여 수행됩니다.

방화벽은 일반적으로 모든 세그먼트를 관련 TCP/UDP 포트와 함께 IP 범위 그룹으로 보거나 세그먼트의 모음인 영역으로 보고 관련 IP 범위 간에 차단하거나 허용할 포트를 함께 보곤 합니다. 네트워크 방화벽은 패킷의 데이터 페이로드에 포함된 애플리케이션별 콘텐츠를 기반으로 보안을 구현하지 않습니다. 방화벽은 패킷의 목적지 또는 소스 IP 주소와 포트를 워크로드의 ID로 간주합니다. 패킷 깊숙한 곳에 포함된 애플리케이션 데이터를 기반으로 의사 결정을 내릴 수 있는 최신'차세대' 방화벽이있더라도 대부분의 방화벽 규칙은 여전히 기존의 IP 및 포트 범위를 따라 구성됩니다. 오래된 습관은 고치기 어렵습니다.

전통과의 결별

DevOps 철학은 배포 속도와 자동화에 중점을 둡니다. 또한 앞서 언급했듯이 네트워크 세그먼트 및 방화벽 변경은 일반적으로 느리고 수동으로 이루어집니다. 네트워크 및 보안에 대한 변경 사항을 자동화하면 종종 운영상의 장벽에 부딪혀 수정하기가 어려울 수 있습니다. 그 결과 보안은 단순히 프로세스 속도를 늦추기 때문에 뒷전으로 밀리는 경우가 많습니다. 일반적으로 워크로드는 빠르고 민첩하게 배포되며, 보안은 침해가 발생하고 기업이 소송에 직면한 후에야 우선 순위로 돌아옵니다. CEO에게 보안이 왜 최우선 순위가 아니었는지, 왜 지금 자신의 비즈니스가 소송을 당하고 있는지 설명하는 사람이 되고 싶어 하는 사람은 아무도 없습니다.

Amazon은 2012년에 "네트워크가 방해가 된다"는 말로 워크로드 민첩성과 네트워크 변경 간의 우선순위 충돌을 표현한 것으로 유명합니다. 네트워크와 변화하는 네트워크 세그먼트는 민첩한 워크로드 배포를 방해하는 장애물입니다. 따라서 네트워크 세분화는 종종 수행되지 않거나 네트워킹 팀에서 매우 거친 방식으로 수행됩니다.

하지만 네트워크 세분화 및 보안을 워크로드 내에서 직접 구현할 수 있다면 어떨까요? 더 이상 네트워크 운영이 기본 네트워크 패브릭에서 세분화를 구현할 때까지 기다릴 필요가 없습니다.

대신 DevOps 프로세스를 통해 워크로드를 배포하는 것과 동일한 애자일 프로세스 내에서 필요한 세그먼트를 직접 구현할 수 있다면 어떨까요?

그리고 더 중요한 것은 이러한 세그먼트 간의 보안을 오래된 IP/포트 방화벽 규칙에 의존하지 않고 자연어 정책을 사용하여 정의할 수 있다면 어떨까요? 더 이상 대상 IP 및 포트를 가리키는 소스 IP 및 포트에 대해 정의된 정책이 수명 주기 내내 워크로드에 연결되지 않으므로 더 이상 필요하지 않습니다.

대신 "뉴욕에 배포된 웹 서버만 런던의 데이터베이스 서버와 통신할 수 있습니다."와 같이 사용자가 리소스를 인식하는 방식을 반영하는 정책을 작성할 수 있다면 어떨까요?

이를 세분화된 접근 방식으로 정의하여 "동일한 위치 내에서 웹서버-1만 웹서버-2와 통신할 수 있음"과 같은 진정한 "마이크로세그먼트" 제로 트러스트 접근 방식을 달성할 수 있다면 어떨까요 ?

네트워크 아키텍처에는 이 다이어그램에 표시된 것처럼 정책을 적용할 수 있는 네 가지 계층이 있습니다:

계층이 올라갈수록 정책은 하위 계층에 구애받지 않고 보다 자연스러운 언어로 표현됩니다. 워크로드에 직접 워크로드 정책을 적용하면 하위 계층이 네트워크 우선순위에 집중할 수 있는 여유가 생깁니다.

워크로드 계층 도구가 기본 네트워크 패브릭 위에 추상화된 방식으로 워크로드 간 세분화 및 적용을 정의할 수 있도록 허용하면 네트워크 운영 팀이 애플리케이션 요구 사항이 네트워크 설계에 영향을 미치지 않도록 할 수 있습니다. 애플리케이션 세분화 및 적용을 워크로드 계층으로 '상향'하면 네트워크 운영팀은 네트워크 우선순위에 따라 네트워크 패브릭을 설계할 수 있습니다.

방화벽은 항상 그랬던 것처럼 패브릭 전체에 광범위한 세그먼트를 만드는 데 여전히 사용되지만, 애플리케이션 세분화 요구 사항을 수용하기 위해 더 이상 감당하기 어려운 수의 VLAN 또는 서브넷을 만들 필요는 없습니다. 네트워크 설계자는 대신 처리량, 중복성, 경로 요약, 스패닝 트리, ECMP 등 네트워크 세분화를 설계할 때 네트워크 우선순위에 집중할 수 있습니다. 애플리케이션 세분화는 더 이상 네트워크 설계에 골칫거리가 될 필요가 없습니다. 워크로드가 세분화 경계를 생성하고 적용하도록 하면 보안 문제를 해결할 때 원인을 찾을 때 네트워크가 최우선 순위가 되지 않아도 됩니다.

최신 워크로드를 위한 최신 세분화

일루미오의 적응형 보안 플랫폼 (ASP)은 진정한 제로 트러스트 아키텍처 구축에 필수적인 워크로드 간 마이크로세그멘테이션을 지원하고 자연어 표현을 사용하여 이러한 워크로드 간 정책을 정의합니다. 애플리케이션 종속성 맵을 통해 전체 하이브리드 클라우드 패브릭에서 어떤 워크로드가 서로 통신하고 있는지, 누가 누구와 연결을 시작하는지 정확히 파악할 수 있습니다. 워크로드에서 사용하는 IP 주소 지정을 완벽하게 파악할 수 있지만, 네트워크 주소 지정과 애플리케이션 간의 연결은 일시적이므로 IP 주소 지정에 대해 정책을 정의할 수도 없고 정의해서도 안 됩니다.

Illumio는 레이블을 사용하여 워크로드가 호스팅되는 기본 하이브리드 클라우드 네트워크 세그먼트의 어떤 세그먼트 위에 추상화된 기준에 따라 워크로드를 식별합니다:

• 이러한 레이블에는 현재 IP 주소와 관계없이 워크로드와 관련된 메타데이터가 포함됩니다.
• 레이블은 역할, 애플리케이션, 환경 및 위치("RAEL")입니다.
• 이는 워크로드 간의 세그먼트를 정의하는 데 사용되며, 이러한 레이블이 지정된 워크로드 간의 적용은 자연어 표현을 사용하여 정의됩니다(예: 웹 워크로드는 앱 워크로드와 통신할 수 있지만 앱 워크로드만 데이터베이스 워크로드와 통신할 수 있음). 정책은 IP 주소에만 적용되는 것이 아닙니다.
• 그런 다음 Illumio는 이러한 레이블 기반 정책 규칙을 현재 해당 워크로드를 실행 중인 OS의 네트워크 필터링 기능에 맞는 구성으로 변환합니다(Linux iptables 및 ipsets, Windows 필터링 플랫폼(WFP), Solaris 및 AIX 워크로드용 IPFilter 상태 테이블 등).

Illumio를 사용하면 워크로드가 호스팅되는 방법과 위치보다 완전히 추상화된 방식으로 정책을 정의할 수 있으므로 네트워킹 우선 순위와 애플리케이션 우선 순위가 더 이상 충돌하지 않습니다.

요약

최신 데이터센터 및 하이브리드 클라우드 네트워크 아키텍처에서 경계는 단순히 워크로드가 현재 호스팅되는 위치로 정의되며, 해당 워크로드는 클라우드의 모든 세그먼트에서 동적으로 이동할 수 있습니다. 데이터 센터와 인터넷 사이라는 기존의 경계 정의는 더 이상 적합하지 않으며, 애플리케이션 경계를 넘어 마이크로세그멘테이션이 가능하도록 네트워크 패브릭을 설계하는 것은 확장하기 어렵습니다. 하이퍼바이저에서 종료되는 컨트롤러와 오버레이 네트워크를 사용하는 SDN 솔루션은 네트워크와 워크로드 사이의 경계를 호스트까지 효과적으로 이동하지만, 여전히 네트워크 계층에서 워크로드 계층의 문제를 해결하기 위해 '아래로부터 위로' 세그먼트를 정의하는 데 의존합니다.

최신 클라우드 패브릭에서 훨씬 더 확장 가능한 접근 방식은 워크로드로 이동하여 마이크로 세그먼트를 생성하고 워크로드와 관련된 정책을 적용하여 네트워크 설계와 관련된 우선 순위에 따라 네트워크 세분화를 정의하는 것입니다. 네트워크는 더 이상 애플리케이션 워크로드 민첩성과 보안을 방해하는 장애물이 아닙니다. 또한 애플리케이션 보안 문제 해결 시 네트워크가 더 이상 최우선 순위가 아니므로 인시던트 대응 시 손가락질하는 일이 줄어듭니다.

이 동영상을 통해 세분화의 진화 과정을 간략하게 살펴보고 여기에서 솔루션에 대해 자세히 알아보세요.