네트워크 보안은 워크로드 보안이 아닙니다

침해, 해킹, 하이재킹, 데이터 손실, 유출은 대부분의 클라우드 아키텍처에 존재하는 문제인데, 그 이유는 대부분의 IT 기술이 원래 보안을 우선순위에 두고 설계되지 않았다는 아주 간단한 이유 때문입니다. 애플리케이션 개발, 워크로드 운영 체제, 네트워킹 프로토콜, 전반적인 프로세스 관리와 관련된 복잡성은 모두 기능성과 복원력이라는 서로 다른 우선순위를 염두에 두고 설계되었습니다. 이러한 작업은 모두 작동해야 하며 전체 아키텍처의 요소에서 장애가 발생해도 살아남아야 하지만 이러한 요소를 보호하는 것은 일반적으로 후순위로 밀려났습니다.

네트워크는 전체 아키텍처에서 중요한 인프라이므로 여기에 보안 및 마이크로세그멘테이션 솔루션을 적용하는 것이 합리적일 수 있습니다.

애플리케이션 개발 방식, 다양한 OS의 구축 및 배포 방식, 이 모든 것이 가상화, 추상화 및 관리되는 방식에 관계없이 이러한 요소의 대부분은 서로 통신해야 합니다. 네트워크가 없는 경우 각 애플리케이션은 하나의 섬이 됩니다. 그리고 오늘날 대부분의 애플리케이션은 사설 네트워크나 인터넷을 통해 원격 클라이언트가 액세스하도록 설계되어 있습니다. 이는 모든 종류의 클라우드 아키텍처에 필요하며, 모든 클라우드 네이티브 아키텍처는 이미 존재하는 네트워크가 없으면 통신할 수 없습니다. 따라서 전체 클라우드 아키텍처에서 가장 중요한 요소는 사실 네트워크 자체라고 할 수 있습니다.

모든 클라우드 아키텍처에서 네트워크 인프라의 중요한 특성으로 인해 모든 아키텍처의 네트워크 계층에만 해당하는 과제와 우선 순위가 있습니다. 네트워크에는 네트워크에 의존하는 워크로드 및 애플리케이션과 전혀 무관한 문제가 있습니다. 이러한 네트워크 우려 사항의 몇 가지 예는 다음과 같습니다:

• 신뢰성(네트워크가 작동해야 함)
• 복원력(하나 이상의 네트워크 장치에 장애가 발생해도 시스템 전체에 장애가 발생하지 않아야 함)
• 트래픽 엔지니어링 및 서비스 품질(IP 네트워크는 설계상 '무연결'이지만 다양한 종류의 트래픽을 엔지니어링하고 우선순위를 지정할 수 있는 방법이 있어야 함)
• 확장(네트워크는 리소스 상한선에 부딪히지 않고 진화할 수 있어야 함)

애플리케이션과 워크로드가 네트워크를 사용하기 위해 이러한 세부 사항을 인지할 필요가 없어야 합니다.

그렇다면 이는 네트워크 보안과 워크로드 보안에 어떤 의미가 있을까요? 특히 네트워크 보안과 네트워크 기반 솔루션, 워크로드 보안과 마이크로세그멘테이션과 같은 솔루션의 대조에 대해 살펴볼 것입니다.

네트워크 보안의 간략한 역사

보안은 대부분의 클라우드 아키텍처에서 항상 후발 주자이기 때문에 보안 및 네트워크 세분화는 전통적으로 네트워크 계층에서 구현되어 왔습니다. 네트워크는 전체 아키텍처에서 중요한 인프라이므로 여기에 보안 및 마이크로세그멘테이션 솔루션을 적용하는 것이 합리적일 수 있습니다.

수십 년 전으로 거슬러 올라가면, IP 네트워크의 보안은 원래 라우터와 스위치에서 액세스 제어 목록("ACL")의 형태를 취했습니다. 네트워크 장치는 일반적으로 패킷 단위로 트래픽을 처리하므로 패킷이 라우터나 스위치에 도착하면 이러한 ACL을 확인하여 패킷의 전달을 허용할지 차단할지 여부를 결정합니다.

이 접근 방식은 원래 동일한 기본 접근 방식을 사용하던 전용 네트워크 장치인 방화벽으로 아웃소싱되었습니다. 모든 IP 패킷은 헤더에 패킷의 데이터 페이로드에 어떤 유형의 데이터가 있는지를 나타내는 TCP 또는 UDP 번호 외에도 소스 및 대상을 나타내는 정보를 포함하므로 방화벽은 이 정보를 사용하여 자체 액세스 제어 목록을 기반으로 포워딩 결정을 내립니다. 네트워크가 패킷을 처리하기 때문에 애플리케이션 개발 및 시스템 팀은 다른 문제에 집중할 수 있도록 보안과 마이크로세그멘테이션도 네트워크에 맡기는 것이 합리적입니다.

그러나 일반적으로 패킷 기반 방화벽은 쉽게 속일 수 있습니다. IP 패킷의 주소와 TCP/UDP 포트 번호를 '스푸핑'하는 것은 그리 어렵지 않기 때문에 데이터 페이로드에 포함된 내용을 쉽게 가릴 수 있는 패킷을 생성할 수 있습니다. 따라서 세션 기반 방화벽은 특정 흐름의 모든 패킷을 고유 세션에 매핑하고 해당 세션이 어떤 애플리케이션과 연결되어 있다고 '생각'하는지에 따라 해당 세션의 동작을 모니터링하는 데 중점을 두도록 진화했습니다. 이러한 방화벽은 각 패킷에 대한 완전한 가시성을 확보하지는 못했지만, 해당 패킷과 세션의 동작 방식을 애플리케이션 기준 동작과 비교하여 이상 징후를 찾습니다.

이후 패킷에 포함된 내용, 패킷이 어떤 애플리케이션과 연관되어 있는지, 어떤 사용자와 연관되어 있는지, 기타 보안 침해를 나타내는 세부 정보를 식별하는 데 훨씬 더 많은 지능을 적용하는 이른바 '차세대' 방화벽이 등장했습니다. 그러나 이러한 모든 세부 사항은 소스 또는 대상 워크로드 자체가 아니라 네트워크에서 인라인으로 발생합니다. 방화벽은 워크로드 및 애플리케이션을 모니터링하는 중앙 도구와 통신하여 선택한 트래픽을 방화벽으로 조정하지 않는 한 이러한 패킷을 주고받는 워크로드에서 무슨 일이 일어나고 있는지 알 수 없습니다. 그러나 이는 배포가 복잡할 수 있으므로 방화벽은 단순히 네트워크에 앉아 패킷이 도착하기를 기다리는 경우가 많습니다.

네트워크 보안은 워크로드 보안과 다릅니다.

방화벽이 어떤 패킷을 전달할 수 있고 전달할 수 없는지 결정하는 것과 마찬가지로 라우터와 스위치도 자체적인 보안 문제를 가지고 있는데, 이는 원래 네트워킹 프로토콜이 설계될 때 보안이 주요 관심사가 아니었다는 동일한 기본 문제에서 비롯된 결과입니다.

BGP 및 OSPF와 같이 패킷을 전달하는 데 사용되는 TCP/IP 및 동적 라우팅 프로토콜은 애플리케이션 및 워크로드와 동일한 기본 목표인 기능 및 복원력을 염두에 두고 설계되었습니다. 네트워킹 초창기에는 보안이 우선순위가 아니었습니다. 보안과 마이크로세그멘테이션은 네트워크 발전의 후기 단계에서 우선순위가 되었고, 네트워크 보안 솔루션은 네트워킹에 특화된 보안 문제를 해결하는 데 사용되었습니다. 보안은 워크로드와 애플리케이션에만 국한된 문제가 아닙니다. 네트워크에는 워크로드 및 애플리케이션에 대한 가시성이 없는 보안 문제가 있습니다.

다시 말씀드리지만, 이는 모든 클라우드 아키텍처의 네트워크 계층에 존재하는 보안 문제의 몇 가지 예에 불과합니다:

• 교통 공학
• 서비스 거부(DoS)
• ARP 스푸핑
• BGP 인증
• 트래픽 리디렉션
• 중간자 공격
• 가짜 경로 전파
• 퍼스트홉 라우터 하이재킹
• 세션 쿠키 하이재킹

이 짧은 목록의 항목은 모두 워크로드나 애플리케이션이 아닌 네트워킹과 관련된 보안 문제입니다. 예를 들어 트래픽 엔지니어링 문제는 MPLS와 같은 기술과 라벨 배포 프로토콜의 신뢰성을 통해 해결됩니다. 서비스 거부는 ISP 라우팅 피어와 교환하는 BGP 커뮤니티를 통해 해결되는 중요한 문제입니다. ARP 스푸핑은 라우터가 레이어 3 주소와 레이어 2 주소 간의 매핑을 변경하여 트래픽의 목적지가 도용되는 문제입니다. BGP 인증은 인터넷을 통한 라우팅 문제를 방지하기 위해 BGP 피어 간에 교환되는 정보를 암호화하기 위해 RPKI와 같은 것을 필요로 합니다. 기타 등등. 네트워킹에는 모든 클라우드 아키텍처의 네트워크 계층에 고유한 보안 문제를 처리하기 위한 고유한 전문 어휘가 있습니다.

이러한 예는 워크로드나 애플리케이션 아키텍처가 아닌 네트워크 아키텍처의 주요 보안 문제 중 일부에 불과합니다. 애플리케이션 개발 및 시스템 팀은 일반적으로 이러한 네트워크 보안 문제에 대한 가시성을 확보할 필요가 없기 때문입니다. 예를 들어 워크로드의 OS가 패킷을 보내거나 받기 위해 iptables를 사용하는 경우, 네트워크 어딘가에 있는 ISP 간에 BGP가 하이재킹되고 있는지 알 필요가 없습니다. 워크로드 및 애플리케이션은 네트워크 보안이 아닌 워크로드 및 애플리케이션 보안과 관련이 있습니다.

네트워킹 보안 솔루션은 워크로드 보안 솔루션이 아닙니다.

즉, 네트워킹 보안 문제를 해결하기 위해 설계된 도구는 일반적으로 워크로드 또는 애플리케이션의 보안 및 마이크로세그멘테이션 문제를 해결하는 데 적합한 도구가 아니라는 뜻입니다. 워크로드 보안은 규모에 제한을 받지 않아야 하는 경우가 많습니다. 여러 클라우드에 걸쳐 수천 개의 워크로드를 배포할 때 이러한 워크로드에 애플리케이션 수준의 보안을 제공하기 위해 하나의 네트워크 계층 도구에 의존해서는 안 됩니다.

워크로드는 레이어 3 경계를 넘거나 클라우드 간에 실시간 마이그레이션하는 경우가 많으며, 워크로드 보안 및 마이크로세그멘테이션을 적용하기 위해 이러한 마이그레이션을 추적하는 네트워크 레이어 도구에 워크로드가 의존해서는 안 됩니다. 애플리케이션은 워크로드 전반의 종속성에 의존하며 이러한 종속성은 네트워크 계층 도구에 표시되지 않는 경우가 많으므로 애플리케이션에 대한 링펜스를 정의할 때 네트워크가 전체 애플리케이션 종속성에 대한 가시성이 부족하다는 이유로 제한해서는 안 됩니다.

일부 네트워킹 공급업체는 워크로드 및 애플리케이션 보안과 마이크로세그멘테이션 요구 사항에 대한 솔루션으로 자사의 SDN 솔루션을 제안합니다. 그러나 이러한 도구는 네트워크 또는 하이퍼바이저 계층에 상주하며 자동화, 가상화, 네트워크 분석, 네트워크 오버레이 및 터널링, 동적 라우팅 프로토콜 간 인증 등 해당 계층의 우선순위를 해결하도록 설계되었습니다. SDN 도구는 대규모 워크로드 및 애플리케이션에 보안 및 마이크로세그멘테이션을 제공하도록 설계되지 않았습니다.

또한 차세대 방화벽이 네트워크 트래픽에 대한 완전한 계층 7 가시성을 제공한다고 주장하면서 워크로드 및 애플리케이션 보안 요구 사항에 대한 솔루션으로 하드웨어 또는 하이퍼바이저의 가상화된 인스턴스인 방화벽을 제안할 수도 있습니다. 그러나 모든 방화벽은 패킷이 방화벽에 도달한 후에만 유용합니다. 방화벽은 소스에서 애플리케이션이나 워크로드의 동작에 영향을 줄 수 없으며, 대신 패킷이 방화벽의 포트에 도착할 때까지 기다릴 뿐입니다. 방화벽은 트래픽이 전송 중일 때 네트워크 보안과 마이크로 세분화(남북 트래픽) 를 시행합니다. 애플리케이션 또는 워크로드 보안을 소스인 이스트-웨스트 트래픽에 적용하지 않습니다. 진정한 제로 트러스트 아키텍처를 실현하려면 두 솔루션이 모두 필요하지만, 아키텍처의 한 계층이 다른 계층에 완전한 보안과 마이크로세그멘테이션을 제공할 수는 없습니다.

네트워킹 팀은 워크로드 또는 애플리케이션 보안을 담당해서는 안 됩니다.

네트워크 팀은 워크로드나 애플리케이션 작업과는 다른 네트워킹 작업에 집중합니다. 이러한 작업에는 레이어 2 및 레이어 3 변환 및 전달 메커니즘, BGP 및 OSPF와 같은 라우팅 프로토콜과 서로 피어링하는 방법, 자체 인증 메커니즘 등 해당 팀과 관련된 용어가 포함됩니다. 스패닝 트리 및 ECMP와 같은 레이어 2 네트워킹 문제에 대한 솔루션에도 고유한 보안 우선 순위가 있습니다. 하이퍼바이저에 배포된 SDN 및 가상화된 네트워크 어플라이언스와 같은 네트워킹 도구는 네트워킹 우선순위와 관련된 문제에 초점을 맞추고 있습니다. 이러한 솔루션 중 어느 것도 워크로드 내 보안 위험 자체를 우선순위에 두지 않습니다.

이 모든 것이 의미하는 바는 워크로드에 대한 보안 및 마이크로세분화 솔루션을 설계할 때 해당 솔루션을 워크로드에 배포해야 한다는 것입니다. 네트워크 도구에는 워크로드 또는 애플리케이션 문제와 다른 우선순위가 있습니다. 네트워크 보안 도구는 항상 존재하며, 전체 네트워크 패브릭 안팎의 남북 트래픽을 강화하는 데 중점을 둡니다. 이러한 네트워킹 도구는 네트워킹 장치에 배포됩니다. 워크로드 보안은 워크로드 자체에 배포되어야 하며, 워크로드 간 및 애플리케이션 간 이스트-웨스트 트래픽을 적용하는 데 중점을 두어야 합니다.

전체 아키텍처의 각 계층이 자체 계층에 특정한 우선순위에 집중하면 각 계층이 다른 계층의 운영이나 확장 방식에 제한을 두지 않고 서로 독립적으로 운영할 수 있습니다. 그 결과 완전히 실현된 제로 트러스트 아키텍처가 탄생했습니다.

많은 클라우드 네이티브 아키텍처는 보안 모범 사례를 따르며 워크로드 자체에 워크로드 보안 솔루션을 배포합니다. 그러나 오래된 습관은 쉽게 사라지지 않으며, 기존 IT 환경이 데이터센터에서 클라우드 서비스로 마이그레이션될 때 네트워킹 솔루션을 사용하여 워크로드 보안을 강화하려는 기존 접근 방식도 마이그레이션되는 경우가 많으며, 그 결과 워크로드와 애플리케이션 간의 동서 보안 요구 사항을 무시하는 네트워크 계층이 만들어지는 경우가 많습니다. 그 결과는 제로 트러스트가 아닙니다.

이것이 바로 전체 보안 아키텍처에 Illumio가 들어맞는 부분입니다. 네트워크 세분화에 대한 기존의 접근 방식과 달리 Illumio는 보안 및 마이크로세분화를 보안 및 세분화하려는 엔터티, 즉 워크로드 자체에서 직접 시행할 수 있습니다. 이렇게 하면 워크로드 및 애플리케이션 보안과 마이크로세그멘테이션이 네트워크의 위치에 의존하지 않고 확장 및 발전할 수 있습니다. 또한 온프레미스 데이터 센터 또는 클라우드 제공업체의 어느 곳에서나 워크로드를 유지하거나 마이그레이션할 수 있습니다.

멀티 클라우드 아키텍처는 모든 기본 네트워킹 토폴로지에 걸쳐 도달성을 갖춘 하나의 광범위한 네트워크 패브릭을 생성합니다. 보안과 마이크로세그멘테이션은 동일한 가이드라인을 따라야 하며, 동일한 네트워크 패브릭에서 엔드투엔드에 걸쳐 일관되고 확장 가능한 하나의 솔루션을 제공해야 합니다. 제로 트러스트란 보안 신뢰 경계가 보호가 필요한 모든 워크로드와 애플리케이션으로 확장되는 것을 의미하며, 클라우드 아키텍처의 다른 계층에서 이 목표를 실현하려고 시도함으로써 이 목표가 제한되어서는 안 됩니다.

이러한 주제에 대해 자세히 알아보고 Illumio가 워크로드 및 애플리케이션 보안을 해결하는 방법을 알아보세요:

• 세분화의 진화에대한 간단한 개요 동영상을 시청하세요.
• 이 온디맨드 웨비나를 확인하세요: 네트워크에서 보안을 강화하세요: 간편한 세분화