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

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

그렇다면 이러한 애플리케이션과 워크로드를 보호할 때 여전히 네트워크와 관련된 접근 방식을 고려하는 이유는 무엇일까요?이제 네트워크가 더 이상 애자일 워크로드 딜리버리, 자동화, 보안에 걸림돌이 되지 않도록 접근 방식을 발전시킬 수 있는 방법을 살펴보겠습니다.

최신 워크로드의 내부 작동

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

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

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

네트워크 패브릭의 중요한 특성 때문에 네트워크 변경은 일반적으로 느리게 진행됩니다. 대부분의 데이터 센터 네트워크는 대체로 평평하며, 많은 퍼블릭 클라우드 네트워크 패브릭에는 대략적인 수준의 세분화만 포함되어 있습니다. 어떤 환경에서든 네트워크를 분할할 때는 일반적으로 DMZ, WAN 세그먼트, 캠퍼스 세그먼트 또는 기존 웹/애플리케이션/개발 세그먼트와 같은 광범위한 리소스 범주에 걸쳐 격리를 설정하는 등 네트워크별 우선 순위에 따라 수행됩니다.네트워크를 분할하는 다른 이유는 네트워크 성능을 최적화하고, 처리량을 늘리고, 경로 이중화를 구현하거나, 경로 요약, 스패닝 트리, ECMP와 같은 작업의 효율성을 높이기 위해서입니다.

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

방화벽은 일반적으로 모든 세그먼트를 관련 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는 이러한 레이블 기반 정책 규칙을 Linux iptables 및 ipsets, Windows 필터링 플랫폼 (WFP) 또는 Solaris 및 AIX 워크로드에 대한 IPFilter 상태 테이블 등 현재 해당 워크로드를 실행하고 있는 모든 OS의 네트워크 필터링 기능에 특정한 구성으로 변환합니다.

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

요약하면

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

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

이것 좀 봐 비디오 세분화의 진화를 분석하고 솔루션에 대해 자세히 알아보는 간단한 여정을 위해 이리.