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

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

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

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

모든 클라우드 아키텍처에는 네트워크 인프라가 매우 중요하기 때문에 모든 아키텍처의 네트워크 계층에만 적용되는 과제와 우선 순위가 있습니다.네트워크에는 네트워크에 의존하는 워크로드 및 애플리케이션에 전혀 영향을 받지 않는 문제가 있습니다.이러한 네트워크 문제의 몇 가지 예는 다음과 같습니다.

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

애플리케이션과 워크로드가 네트워크를 사용하기 위해 이러한 세부 정보를 인식할 필요는 없습니다.

그렇다면 네트워크 보안과 워크로드 보안에 어떤 의미가 있을까요?여러 가지 고려 사항을 살펴보도록 하겠습니다. 특히 두 가지 고려 사항 간의 차이점에 대해 살펴보겠습니다. 네트워크 보안 네트워크 기반 솔루션, 워크로드 보안 및 마이크로세그멘테이션과 같은 솔루션을 제공합니다.

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

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

시간을 수십 년 전으로 돌려 보면 IP 네트워크의 보안은 원래 라우터와 스위치의 액세스 제어 목록 (“ACL”) 의 형태를 취했습니다.네트워크 디바이스는 일반적으로 패킷 단위로 트래픽을 처리하므로 패킷이 라우터나 스위치에 도착하면 이러한 ACL을 검사하여 패킷 전달을 허용할지 차단할지를 결정합니다.

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

그러나 일반적으로 패킷 기반 방화벽을 속이는 것은 쉽습니다.IP 패킷의 주소와 TCP/UDP 포트 번호를 “스푸핑”하는 것은 그리 어렵지 않습니다. 이렇게 하면 데이터 페이로드에 포함된 내용을 쉽게 마스킹할 수 있는 패킷이 생성됩니다.따라서 세션 기반 방화벽은 특정 흐름의 모든 패킷을 고유한 세션에 매핑하는 데 초점을 맞추고 해당 세션이 연관되어 있다고 “생각하는” 애플리케이션을 기반으로 해당 세션의 동작을 모니터링하도록 발전했습니다.이러한 방화벽은 각 패킷을 완벽하게 파악할 수는 없었지만 패킷과 세션의 작동 방식을 애플리케이션 기준 동작과 비교하여 이상 징후를 찾아냈습니다.

나중에 소위 “차세대” 방화벽이 등장했습니다. 이 방화벽은 패킷에 포함된 내용, 패킷과 관련된 애플리케이션, 연결된 사용자 및 보안 침해를 나타내는 기타 세부 정보를 식별하는 데 훨씬 더 많은 인텔리전스를 적용합니다.그러나 이러한 모든 세부 사항은 소스 또는 대상 워크로드 자체가 아니라 네트워크에서 인라인으로 발생합니다.방화벽은 이러한 패킷을 보내고 받는 워크로드에서 어떤 일이 벌어지고 있는지 전혀 알 수 없습니다. 워크로드와 애플리케이션을 모니터링한 다음 선택된 트래픽을 방화벽으로 전송하는 중앙 도구와 어떻게든 통신하지 않는 한 말입니다.하지만 이는 배포가 복잡할 수 있기 때문에 방화벽은 네트워크에 머물면서 패킷이 도착하기를 기다리는 경우가 많습니다.

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

전달할 수 있는 패킷과 전달할 수 없는 패킷을 결정하는 방화벽과 동시에 라우터와 스위치에도 고유한 보안 문제가 있습니다. 이는 동일한 기본 문제의 결과입니다. 네트워킹 프로토콜이 처음 설계될 당시에는 보안이 주요 관심사가 아니었습니다.

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

다시 말씀드리지만, 다음은 클라우드 아키텍처의 네트워크 계층에 존재하는 보안 문제의 몇 가지 예일 뿐입니다.

• 트래픽 엔지니어링
• 서비스 거부 (DoS)
• ARP 스푸핑
• BGP 인증
• 트래픽 리디렉션
• 맨 인 더 미들 공격
• 가짜 경로 전파
• 퍼스트 홉 라우터 하이재킹
• 세션 쿠키 하이재킹

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

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

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

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

워크로드는 레이어 3 경계를 넘어 또는 클라우드 간에 실시간 마이그레이션되는 경우가 많으며, 워크로드는 마이그레이션을 적용하기 위해 어떻게든 이러한 마이그레이션을 추적하는 네트워크 계층 도구에 의존해서는 안 됩니다. 워크로드 보안 및 마이크로세그멘테이션.애플리케이션은 워크로드 전반의 종속성에 의존하며 이러한 종속성은 네트워크 계층 도구에서 확인할 수 없는 경우가 많습니다. 따라서 전체 애플리케이션 종속성에 대한 네트워크의 가시성 부족으로 인해 애플리케이션 주변의 링펜스를 정의하는 것이 제한되어서는 안 됩니다.

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

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

네트워킹 팀은 워크로드 또는 애플리케이션 보안 업무를 맡아서는 안 됩니다.

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

이것이 의미하는 바는 워크로드에 대한 보안 및 마이크로세그멘테이션 솔루션을 설계할 때 해당 솔루션을 워크로드에 배포해야 한다는 것입니다.네트워크 도구에는 워크로드 또는 애플리케이션 관련 문제와는 다른 우선 순위가 있습니다.전체 네트워크 패브릭 내부 및 외부의 남북 트래픽을 강화하는 데 중점을 둔 네트워크 보안 도구는 항상 존재할 것입니다.이러한 네트워킹 도구는 네트워킹 디바이스에 배포됩니다.워크로드 보안은 워크로드 자체에 배포해야 하며, 워크로드 간 및 애플리케이션 간 동서 트래픽을 적용하는 데 중점을 둘 것입니다.

전체 아키텍처의 각 계층이 해당 계층에 특정한 우선 순위에 초점을 맞추면 각 계층이 다른 계층에 구애받지 않고 다른 계층의 운영 또는 확장 방식에 제한을 두지 않을 수 있습니다.그 결과 완전히 실현된 제로 트러스트 아키텍처가 탄생했습니다.

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

이것이 Illumio가 전체 보안 아키텍처에 적합한 이유입니다.Illumio를 사용하면 네트워크 세분화에 대한 기존 접근 방식과 달리 보안 및 마이크로세그멘테이션을 보호하고 세분화하려는 대상, 즉 워크로드 자체에 직접 적용할 수 있습니다.이렇게 하면 워크로드, 애플리케이션 보안, 마이크로세그멘테이션이 네트워크 상의 어디에 있든 상관 없이 확장 및 발전할 수 있습니다.이를 통해 워크로드를 온프레미스 데이터 센터 또는 클라우드 제공업체 전반의 어느 곳으로든 상주하거나 마이그레이션할 수 있습니다.

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

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

• 에서 이 간략한 개요 비디오를 시청하십시오. 세그멘테이션의 진화
• 이 온디맨드 웨비나를 확인해 보세요. 네트워크로부터 보안 확보: 단순해진 세그멘테이션