일반적으로 네트워크 보안, 특히 SASE와 관련하여 여러 가지 아키텍처 원칙에 대해 들어보셨을 것입니다. 업계에서 SASE 맥락에서 사용하는 몇 가지 소프트웨어 아키텍처 원칙은 다음과 같습니다:

  • 싱글 패스 아키텍처
  • 원 프록시 아키텍처
  • 실행에서 완료까지 아키텍처
  • 스케일아웃 아키텍처
  • 단일 패스 병렬 처리 아키텍처
  • 나만의 보안 기능 가져오기 아키텍처
  • 클라우드 네이티브 아키텍처
  • 격리 아키텍처
  • API 우선 아키텍처
  • 슬라이싱(E2E 세분화) 아키텍처

위의 아키텍처 원칙 중 많은 부분이 새로운 것은 아닙니다. 싱글 패스, 원 프록시, 싱글 패스-병렬 처리, 실행-완료 아키텍처 원칙은 2000년대 초 UTM(통합 위협 관리) 시절부터 널리 사용되었지만 이전에는 다른 이름으로 알려져 있었습니다. 이러한 아키텍처 원칙의 주요 목적은 다음을 달성하는 것입니다.

  • 효율적인 리소스 사용으로 처리량 증가.
  • 엔드투엔드 지연 시간 단축
  • 지터 감소
  • 보안 서비스에 대한 DDoS 공격 시에도 높은 탄력성(스케일아웃) 및 복원력 제공
  • 새로운 보안 기능의 신속한 도입(민첩성)
  • 여러 공급업체의 보안 기능을 비효율성 없이 통합(최고의 기술 통합)
  • 채택 가능성(어디서나 실행 가능)
  • 단일 창 유리

진화

네트워크 보안 산업의 한 가지 장점은 역동적이라는 점입니다. 모든 새로운 세대의 제품에서 최신 소프트웨어 및 배포 아키텍처 원칙을 채택합니다. 또한 공격자의 정교한 공격에 대한 보호 기능을 유지합니다. 즉, 네트워크 보안 시장은 전통적으로 세분화되어 있습니다. 다양한 보안 기능을 제공하는 여러 보안 공급업체가 있습니다. 혁신의 관점에서 볼 때 이는 좋은 일이며 장려되어야 하고 계속되어야 합니다. 한 공급업체가 모든 보안 기능에 능숙하지 않을 수 있다는 점에 유의해야 합니다. 각 공급업체가 보안 기능을 위한 완전한 스택을 제공한다면 엄청난 비효율성과 그에 따른 막대한 비용이 발생하게 됩니다. 또한 지연 시간이 늘어날 수 있어 일부 애플리케이션에서는 문제가 될 수 있습니다. 따라서 최신 아키텍처 원칙과 모범 사례를 적용할 수 있습니다. 소프트웨어 아키텍처는 비효율성을 처리하면서도 최고의 사이버 보안을 위해 여러 공급업체의 기술을 통합할 수 있는 방식이어야 합니다.

컨버전스 이전

그림 1과 그림 2는 SASE 이전 네트워크 보안의 대표적인 두 가지 예입니다. 그림 1은 보안 인터넷 액세스를, 그림 2는 보안 비공개 액세스의 예를 보여줍니다. 이 그림에서 보안 기능의 순서는 임의적이며 일반적으로 배포에 따라 실행 순서가 달라질 수 있습니다. 안전한 인터넷 접속은 일반적으로 그림 1과 같이 여러 보안 솔루션을 사용하여 이루어집니다.
1. 이러한 보안 기능을 구매하여 서비스 체인에 배치하는 것은 기업입니다. 많은 보안 기능이 연결을 프록시해야 하기 때문에 업계에서는 이 체인화를 프록시 체이닝이라고도 합니다. 각각의 개별 보안 솔루션은 독립적이고 여러 공급업체에서 제공하므로 공통 기능은 이러한 솔루션에서 반복됩니다. 일반적인 기능으로는 수신 시 트래픽 폴리싱, 송신 시 트래픽 쉐이핑, 관련 트래픽만 프록시로 이동하도록 하는 트래픽 필터링, 클라이언트 연결의 TCP 종료, 목적지를 향한 새로운 TCP 연결, TLS 복호화 및 TLS 암호화를 포함하는 SSL/TLS 차단(대상 인증서를 에뮬레이션하는 주문형 인증서 생성 필요), 프록시 인증(Kerberos, NTLM, OIDC), HTTP 1.1/2.0 디코딩이 있습니다. 각 박스/가상 어플라이언스의 이러한 공통 기능은 전체 보안 솔루션의 CPU 리소스 중 50%를 차지하는 것으로 추정됩니다. 보안 애플리케이션 접속은 그림과 같이 개별 보안 솔루션을 연결하여 비슷한 방식으로도 달성할 수 있습니다.
2. 여기에서도 공통 기능은 여러 보안 솔루션에서 동일합니다. 이는 보안 인터넷 액세스에 사용되는 보안 솔루션의 일반적인 기능과 거의 비슷합니다. 몇 가지 차이점으로는 가로채기 대신 SSL/TLS 종료, 프록시 인증 대신 기존 방법을 통한 사용자 인증 등이 있습니다. 보안 솔루션에서 일반적인 기능의 평균 오버헤드는 전체 솔루션의 50%에 달할 수 있습니다. 이 아키텍처로 인한 지연 시간은 기능의 연쇄로 인해 몇 밀리초까지 늘어날 수 있습니다. 물리적 및 가상 어플라이언스를 사용하는 기업이 직면한 또 다른 큰 과제는 확장에 관한 것입니다. 원래는 더 큰 어플라이언스를 사용하거나 VM 기반 보안 솔루션에 더 많은 CPU 및 메모리 리소스를 할당하는 방식으로 확장을 처리했습니다. 이를 스케일업이라고 합니다. 트래픽이 일정하다면 기업에서는 더 큰 물리적/가상 어플라이언스에 비용을 지출하는 것이 합리적입니다. 하지만 트래픽이 폭주하는 경우 기업들은 돈이 낭비되는 것을 원치 않습니다. 1년에 단 며칠만 트래픽이 더 많은 경우를 생각해 보세요. 기업은 왜 1년 내내 이러한 범프에 돈을 쓰고 싶어할까요? 이를 계기로 보안 공급업체는 클라우드 제공 서비스를 통해 스케일아웃 아키텍처를 지원하기 시작했고, 이는 다음 단계로 발전했습니다. 이는 클라우드 애플리케이션 세계에서 IaaS를 사용하는 이유와 같습니다. 스케일아웃 아키텍처에서는 트래픽이 증가하거나 DDoS 공격이 감지되면 자동으로 보안 솔루션의 인스턴스가 더 많이 가동되고, 수요가 감소하면 더 많은 인스턴스가 다운됩니다. 그림 3은 이러한 스케일아웃 아키텍처를 보여줍니다. 스케일아웃 기능이 필요하다는 것은 의심의 여지가 없습니다. 하지만 각 보안 솔루션에 로드 밸런서가 필요합니다. 이 로드 밸런서는 여러 보안 솔루션 인스턴스에서 세션의 부하를 분산하는 데 필요합니다. 로드 밸런서를 여러 번 통과하면 더 많은 리소스가 필요하고 트래픽 세션의 엔드투엔드 지연 시간이 늘어납니다. 네트워크 보안 아키텍처의 차세대 진화는 다음과 같은 문제를 해결합니다.

  • 더 많은 수의 컴퓨팅 리소스 필요
  • 더 높은 지연 시간

함께

  • 하나의 프록시 아키텍처
  • 단일 패스 아키텍처

싱글 패스 및 원 프록시 아키텍처(컨버지드 아키텍처)

아래 그림 4와 같이 모든 보안 기능이 프록시 및 기타 공통 기능과 함께 번들로 제공되며, 프록시는 한 번만 사용하게 됩니다. 모든 보안 함수는 실행 후 완료 방식으로 한 번에 하나씩 호출됩니다. 결과적으로 이 아키텍처는 컴퓨팅 리소스를 효율적으로 소비합니다. 모든 함수가 동일한 사용자 공간 컨텍스트에서 호출되므로 메모리 복사가 방지됩니다. 또한 하나의 사용자 공간 프로세스 아키텍처로 운영 체제 컨텍스트 전환을 획기적으로 줄일 수 있습니다. 단일 프록시 인스턴스는 멀티스레딩을 통해 한 번에 여러 세션을 처리할 수 있으며, 각 스레드는 세션의 하위 집합을 처리하므로 멀티코어 CPU를 효과적으로 활용할 수 있습니다. 또한 멀티스레딩 기능을 사용하면 특정 트래픽 세션에 대해 일부 보안 기능을 직렬이 아닌 병렬로 실행할 수 있으므로 지연 시간이 개선됩니다. 이 아키텍처를 ‘단일 패스 병렬 처리’라고 합니다. 예기치 않은 부하를 처리하고 DDoS 시나리오를 해결하기 위해 자동 스케일아웃 아키텍처가 채택되어 하나의 로드 밸런서 인스턴스가 세션 부하 분산 방식으로 제공됩니다. 이 아키텍처에서 프록시는 인터페이스 API를 노출합니다. 모든 보안 기능은 이 API에 연결됩니다. 프록시는 트래픽 세션 처리 중에 관련 후킹된 보안 함수를 호출합니다. 모든 보안 기능은 SASE 솔루션 개발자가 구현하지 못할 수도 있습니다. SASE 솔루션 개발자는 기술 공급업체 엔진 및 피드를 프록시와 통합하여 기술 공급업체와 협력합니다. 이렇게 하면 SASE 제공업체의 고객은 최고의 보안 구현을 갖춘 고성능 SASE라는 두 가지 장점을 모두 누릴 수 있습니다. 하지만 일부 기술 공급업체는 프록시의 일부로 보안 기능을 개발하기 위해 SDK 형태로 엔진을 제공하지 않을 수도 있습니다. 클라우드 서비스로 제공되고 있을 수도 있습니다. 많은 기술 제공업체가 클라우드 서비스로서 DLP를 제공하는 한 가지 예입니다. 또한 경우에 따라 SASE 솔루션 제공업체가 메모리 제약, 라이선스 비호환성 방지, 사용자 공간 취약성 방지 등의 이유로 프록시의 동일한 사용자 공간 프로세스 컨텍스트에 일부 보안 기능을 통합하지 않으려는 경우도 있을 수 있습니다.

통합 아키텍처 및 자체 보안 기능 가져오기

SASE 아키텍처의 다음 진화는 아래와 같습니다. 아래 그림 6에 표시된 세 가지 중요한 사항이 있습니다. ICAP(인터넷 콘텐츠 적응 프로토콜)를 통한 보안 서비스 지원: 기업은 다른 보안 공급업체의 보안 서비스에 익숙하거나 사용하고 싶을 수 있습니다. IETF의 ICAP 사양은 프록시가 보안 서비스를 포함한 외부 콘텐츠 적응 서비스와 통신할 수 있는 방법을 명시합니다.
외부 보안 서비스를 허용함으로써 SASE 솔루션 제공업체는 기업이 원하는 보안 서비스를 선택할 수 있도록 지원합니다. 자체 보안 기능 도입: IBM 보안 보고서 ‘2022 데이터 유출 비용 보고서’에 따르면, 조직은 데이터 유출을 탐지하고 억제하는 데 평균 277일이 소요되고 있습니다. SASE는 매우 우수한 정책 구성을 제공하지만, 일부 데이터 유출을 차단하려면 프로그래밍 방식의 규칙이 필요할 수 있습니다. 데이터 유출을 분석하는 조직은 이러한 프로그램을 개발할 수 있는 좋은 위치에 있습니다. SASE 제공업체 또는 보안 서비스에 따라 공급업체는 제품 릴리스가 전체 소프트웨어 개발 수명 주기를 거쳐야 하므로 시간이 걸릴 수 있습니다. 이러한 지연을 방지하기 위해 새로운 SASE 아키텍처는 기업의 보안팀이 직접 프로그래밍 규칙을 개발하여 배포할 수 있는 방법을 제공합니다. 프록시에서 불안정성을 유발해서는 안 되므로, SASE 아키텍처는 프로그래밍 규칙을 WASM 모듈로 생성할 수 있도록 WASM 런타임을 제공합니다. WASM 런타임은 샌드박스 역할을 하므로 WASM 모듈에 문제가 발생해도 호스팅 사용자 공간 및 기타 보안 기능 플러그인이 충돌하거나 죽지 않습니다. 통합 프록시: 보안 인터넷 액세스 및 보안 애플리케이션 액세스를 위한 하나의 통합 프록시를 사용하면 메모리 요구 사항을 줄일 수 있습니다. 안티 멀웨어, DLP와 같은 일부 보안 기능의 엔진과 피드는 메모리를 많이 사용합니다. 따라서 각 엔터프라이즈 사이트에 대해 서로 다른 두 개의 프록시 인스턴스를 가져오는 것은 비용이 많이 들 수 있습니다. 또한 하나의 프록시가 세 가지 모드(정방향, 역방향, 투명)를 모두 지원하는 것은 개발자 생산성 관점에서도 좋은 개발 관행입니다.

최신 세대의 SASE 아키텍처에서 따르는 추가 아키텍처 원칙은 다음과 같습니다.

클라우드 네이티브: 이 블로그 게시물의 범용 SASE에서 설명한 대로, 온-프레미스, 클라우드 및 에지에서는 SASE 서비스가 필요합니다. 따라서 차세대 SASE 아키텍처는 ‘클라우드 네이티브’ 원칙에 따라 어디서나 SASE가 작동하도록 하고 있습니다. 클라우드 네이티브와 Kubernetes는 동의어는 아니지만, 클라우드 네이티브라고 하는 솔루션은 Kubernetes 기반인 경우가 많습니다. 솔루션이 Kubernetes에서 작동하도록 선택한 이유는 모든 클라우드/엣지 제공자가 서비스형 Kubernetes를 제공하며, 더 중요한 것은 클라우드/엣지 제공자가 API 인터페이스를 그대로 유지한다는 점입니다. 클라우드/엣지 제공자 전반에서 일관된 Kubernetes의 API 인터페이스로 인해, K8 기반 SASE 솔루션은 클라우드/엣지 제공자 전반에서 원활하게 작동합니다. 격리 아키텍처: 현재의 SASE 아키텍처는 효율성을 위해 공유 사용자 공간 프로세스를 통해 여러 테넌트 세션을 통과할 수 있도록 합니다. 테넌트 간에 IP 주소가 겹치더라도 일정 수준의 격리가 유지되도록 하기 위해 영리한 방법이 사용됩니다. 여러 테넌트의 사용자 공간 프로세스를 공유하는 것은 성능 및 보안 격리 관점에서 좋은 일이 아닙니다. 공유 리소스를 사용하면 테넌트에 대한 DDOS 공격과 같은 잘못된 동작으로 인해 다른 테넌트의 트래픽에 성능 문제가 발생할 수 있습니다. 또한 공유 사용자 공간 프로세스를 익스플로잇하면 모든 테넌트의 모든 비밀/비밀번호/키가 노출될 수 있습니다. 위의 내용을 염두에 두고, 차세대 SASE 아키텍처에서는 전용 사용자 공간 프로세스 또는 전용 컨테이너를 통해 전용 프록시 인스턴스를 사용하는 경우가 점점 더 많아지고 있습니다. API 우선 아키텍처: 현재 SASE 솔루션은 구성 및 관찰을 위한 CLI와 포털을 제공합니다. 일부 SASE 솔루션은 CLI/포털과 백엔드 관리 시스템 간의 API를 사용하며, 광고되지 않습니다. 어떤 경우에는 API가 깨끗하지 않았을 수도 있습니다. 새로운 SASE 솔루션은 CLI 및 포털 구현뿐만 아니라 서드파티가 외부 프로그래밍 엔티티를 개발할 수 있도록 API를 정의하는 API 우선 아키텍처를 채택하고 있습니다. API를 사용하면 간단한 스크립트 개발부터 복잡한 워크플로 개발까지, Terraform 등을 통해 코드형 SecOps를 구현할 수 있습니다. OpenAPI 기반 문서와 함께 RESTful API, JSON 페이로드를 사용하는 것이 일반적인 관행이지만, 일부는 보안 및 네트워킹 오브젝트 및 정책을 구성하기 위해 Kubernetes 사용자 정의 리소스를 노출하기도 합니다. API 우선 아키텍처는 또한 실제 백엔드 로직과 RBAC(역할 기반 액세스 제어) 구현을 분리할 것으로 예상됩니다. 업계 경험에 따르면 RBAC와 비즈니스 로직이 결합된 경우 취약점이 많이 발생한다고 합니다. 그 결과, 업계에서는 RBAC 기능을 외부 기관에 분리하고 애플리케이션은 비즈니스 로직에 집중하는 방향으로 나아가고 있습니다. SASE 관리 시스템에도 동일한 논리가 적용되고 있는데, SASE 관리 시스템은 SAE 정책/객체 및 통합 가시성에 초점을 맞추고 RBAC 기능은 수신 프록시 및 API 게이트웨이와 같은 외부 엔터티에 맡깁니다. 인그레스 프록시는 모든 인증 및 권한 부여와 API 라우팅을 처리합니다. 좋은 점은 하나의 인그레스 프록시가 여러 애플리케이션을 프런트엔드할 수 있다는 것입니다. 따라서 관리 사용자는 여러 애플리케이션에 걸쳐 하나의 RBAC 엔티티에만 익숙해지면 됩니다. 이러한 비즈니스 로직과 RBAC의 분리를 위해 API 우선 아키텍처 솔루션은 몇 가지 가이드라인을 따라야 합니다. 예를 들어, 많은 인그레스 프록시 및 API 게이트웨이는 URI가 RBAC용 리소스를 가리키는 데 사용되기를 기대합니다. 워크플로 기반 자동화의 경우 관리 시스템에서 구성에 태그를 지정하고 이전 태그로 복원하여 사가 패턴을 사용할 수 있을 것으로 기대합니다. 모든 API 우선 아키텍처는 업계 모범 사례를 따라야 합니다.

요약

네트워크 보안 아키텍처는 물리적/모놀리식 엔터티에서 가상 어플라이언스 및 컨테이너로 진화하고 있습니다. 애플리케이션 세계에서 인기를 끌고 있는 많은 클라우드 네이티브 원칙이 SASE 솔루션에 도입되어 스케일아웃/인, 민첩성, 멀티 클라우드/엣지 지원, 여러 테넌트에서 리소스를 효율적으로 사용하는 등 클라우드와 같은 이점을 얻고 있습니다. 이 공간에서 새로운 아키텍처 원칙과 아리아카가 클라우드와 유사한 기술을 어떻게 활용하고 있는지 살펴보세요.

  • CTO 인사이트 블로그

    아리아카 CTO 인사이트 블로그 시리즈는 네트워크, 보안 및 SASE 주제에 대한 사고 리더십을 제공합니다.
    아리아카 제품 사양은 아리아카 데이터시트를 참조하세요.