진화 SASE 아키텍처

일반적으로 네트워크 보안의 맥락에서 여러 아키텍처 원칙에 대해 들어 보셨을 것입니다. SASE 특히. 업계에서 사용하는 일부 소프트웨어 아키텍처 원칙 SASE 컨텍스트는 다음과 같습니다.

• 단일 패스 아키텍처
• 단일 프록시 아키텍처
• Run-to-complete 아키텍처
• 스케일 아웃 아키텍처
• 단일 패스 병렬 처리 아키텍처
• 자체 보안 기능 가져오기 아키텍처
• Cloud-네이티브 아키텍처
• 격리 아키텍처
• API 우선 아키텍처
• 슬라이싱(E2E 분할) 아키텍처

위의 많은 아키텍처 원칙은 새로운 것이 아닙니다. Single-pass, One-proxy, Single-pass-parallel-processing 및 Run-to-completion 아키텍처 원칙은 2000년대 초 UTM(Unified Threat Management) 시절부터 인기를 끌었지만 이전에는 다른 이름으로 알려졌습니다.

이러한 아키텍처 원칙의 주요 목적은 다음을 달성하는 것입니다.

• 리소스를 효율적으로 사용하여 처리량을 높입니다.
• 엔드투엔드 대기 시간 단축
• 낮은 지터
• 보안 서비스에 대한 DDoS 공격에도 높은 탄력성(Scale-out) 및 복원력 제공
• 새로운 보안 기능의 빠른 도입(Agility)
• 비효율성을 도입하지 않고 여러 공급업체 보안 기능 통합(최고 기술 통합)
• 적응성(어디서나 실행)
• 단일 창

진화

네트워크 보안 산업의 장점 중 하나는 역동적이라는 것입니다. 모든 차세대 제품에서 최신 소프트웨어 및 배포 아키텍처 원칙을 채택합니다. 또한 공격자의 정교함에 대한 보호를 유지합니다.

즉, 네트워크 보안 시장은 전통적으로 세분화되어 있습니다. 서로 다른 보안 기능을 제공하는 여러 보안 공급업체가 있습니다. 혁신의 관점에서 보면 좋은 일이며 장려하고 계속해야 합니다. 한 공급업체가 모든 보안 기능을 잘 수행하지 못할 수도 있다는 점에 유의해야 합니다.

더 자세히 살펴보겠지만, 각 공급업체가 보안 기능을 위한 완전한 스택을 제공한다면 엄청난 비효율이 발생하고 그에 따라 막대한 비용 영향이 있을 것입니다. 또한 더 많은 대기 시간이 발생할 수 있으며 이는 일부 애플리케이션에 문제가 될 수 있습니다. 따라서 최신 아키텍처 원칙과 모범 사례를 적용할 수 있습니다. 소프트웨어 아키텍처는 비효율성을 처리하지만 최고의 사이버 보안을 위해 여러 벤더 기술을 통합할 수 있는 방식이어야 합니다.

컨버전스 이전

그림 1과 그림 2는 이전 네트워크 보안의 두 가지 대표적인 예입니다. SASE. 그림 1은 보안 인터넷 액세스를 보여주고 그림 2는 보안 개인 액세스의 예를 보여줍니다. 이 그림에서 보안 기능의 순서는 임의적이며 실행 순서는 일반적으로 배포에 따라 다릅니다.

보안 인터넷 액세스는 전통적으로 그림 1에 나열된 여러 보안 솔루션을 사용하여 달성됩니다.erp이러한 보안 기능을 구매하여 서비스 체인에 넣는 상승. 많은 보안 기능이 프록시 연결을 필요로 하므로 이 연결을 업계에서는 프록시 연결이라고도 합니다.

각각의 개별 보안 솔루션은 자급자족할 수 있고 여러 공급업체에서 제공되기 때문에 이러한 솔루션에서 공통 기능이 반복됩니다. 일반적인 기능에는 수신 시 트래픽 정책, 송신 시 트래픽 셰이핑, 관련 트래픽만 프록시로 이동하도록 보장하는 트래픽 필터링, TCP 클라이언트 연결 종료, 신규 TCP 목적지로의 연결, SSLTLS 암호 해독 및 TLS 암호화, 프록시 인증(Kerberos, NTLM, OIDC), HTTP 1.1/2.0 디코딩을 포함하는 /TLS 가로채기(목적지 인증서를 에뮬레이트하는 온디맨드 인증서 생성이 필요함). 각 상자/가상 어플라이언스의 이 공통 기능은 대략적으로 전체 보안 솔루션 CPU 리소스의 50%를 차지합니다.

보안 애플리케이션 액세스는 그림 2와 같이 개별 보안 솔루션을 연결하여 유사한 방식으로 달성됩니다. 여기에서도 공통 기능은 여러 보안 솔루션에서 동일합니다. Secure Internet Access에 사용되는 보안 솔루션의 공통 기능과 거의 같습니다. 몇 가지 차이점은 다음과 같습니다. SSL가로채기 대신 /TLS 종료 및 프록시 인증 대신 기존 방법을 통한 사용자 인증.

보안 솔루션의 공통 기능에 대한 평균 오버헤드는 전체 솔루션의 50% 정도일 수 있습니다. 이 아키텍처로 인한 대기 시간은 기능 체인으로 인해 몇 밀리초까지 올라갈 수 있습니다.

Ent가 직면한 또 다른 큰 도전erp물리적 및 가상 어플라이언스가 확장됨에 따라 증가합니다. 원래 확장은 더 큰 어플라이언스를 사용하거나 VM 기반 보안 솔루션에 더 많은 CPU 및 메모리 리소스를 할당하여 처리되었습니다. 이를 스케일업이라고 합니다. 트래픽이 일정하다면 Ent에 적합합니다.erp더 큰 물리적/가상 기기에 돈을 쓰게 됩니다. 하지만 트래픽이 폭주하면 Enterp상승은 돈이 낭비되는 것을보고 싶지 않습니다. XNUMX년에 단 며칠만 트래픽이 높은 경우를 생각해 보십시오. 엔트가 왜erp일년 내내 이러한 충돌에 돈을 쓰고 싶습니까? 이는 보안 공급업체가 다음을 통해 확장 아키텍처를 지원하기 시작한 다음 진화로 이어졌습니다. cloud-배달 서비스. 이는 다음과 같은 추론이다. IaaS FBI 증오 범죄 보고서 Cloud 애플리케이션 세계. 확장형 아키텍처에서는 더 높은 트래픽을 감지하거나 DDoS 공격으로 인해 더 많은 보안 솔루션 인스턴스가 자동으로 표시되고 수요가 감소하면 해당 인스턴스를 종료합니다. 그림 3은 확장형 아키텍처를 보여줍니다.

확장 기능이 필요하다는 것은 의심의 여지가 없습니다. 단, 각 보안 솔루션에 로드밸런서가 필요합니다. 이 로드 밸런서는 보안 솔루션의 여러 인스턴스에서 세션의 로드 밸런싱을 위해 필요합니다. 다중 로드 밸런서 순회에는 더 많은 리소스가 필요하고 트래픽 세션의 종단간 대기 시간이 늘어납니다.

네트워크 보안 아키텍처의 차세대 진화는 다음과 같은 문제를 해결합니다.

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

와

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

단일 패스 및 단일 프록시 아키텍처(컨버지드 아키텍처)

아래의 그림 4에서 볼 수 있듯이 모든 보안 기능은 한 번만 등장하는 프록시 및 기타 공통 기능과 함께 번들로 제공됩니다. 모든 보안 기능은 실행 완료 방식으로 한 번에 하나씩 호출됩니다. 결과적으로 이 아키텍처는 컴퓨팅 리소스를 효율적으로 사용합니다. 모든 함수가 동일한 사용자 공간 컨텍스트에서 호출되기 때문에 메모리 복사가 방지됩니다. 또한 하나의 사용자 공간 프로세스 아키텍처는 운영 체제 컨텍스트 스위치를 크게 줄입니다. 단일 프록시 인스턴스는 멀티스레딩을 통해 한 번에 여러 세션을 처리할 수 있으며 각 스레드는 세션의 하위 집합을 처리하므로 멀티코어 CPU를 효과적으로 활용할 수 있습니다. 다중 스레딩 기능을 사용하면 특정 트래픽 세션에 대해 일부 보안 기능을 직렬 대신 병렬로 실행할 수 있으므로 대기 시간이 개선됩니다. 이 아키텍처를 '단일 패스 병렬 처리'라고 합니다.

예기치 않은 로드를 처리하고 DDoS 시나리오를 해결하기 위해 세션 로드 밸런싱 방식으로 들어오는 하나의 로드 밸런서 인스턴스와 함께 자동 확장 아키텍처가 채택됩니다.

이 아키텍처에서 프록시는 인터페이스 API를 노출합니다. 모든 보안 기능은 이 API에 연결됩니다. 프록시는 트래픽 세션 처리 중에 관련된 후킹된 보안 기능을 호출합니다. 모든 보안 기능은 다음에 의해 구현되지 않을 수 있습니다. SASE 솔루션 개발자. SASE 솔루션 개발자는 기술 공급업체 엔진과 피드를 프록시와 통합하여 기술 공급업체와 협력합니다. 그렇게 함으로써 고객들의 SASE 공급자는 두 가지 장점을 모두 얻습니다 – 고성능 SASE 최고의 보안 구현.

즉, 일부 기술 공급업체에서는 프록시의 일부로 보안 기능을 개발하기 위해 SDK 형식으로 엔진을 제공하지 않을 수도 있습니다. 어쩌면 그들은 그것을 가지고 있을 수도 있습니다. cloud 서비스. DLP는 많은 기술 제공업체가 이를 cloud 서비스. 또한 어떤 경우에는 SASE 솔루션 제공업체는 want 메모리 제약과 같은 이유로 프록시의 동일한 사용자 공간 프로세스 컨텍스트에서 일부 보안 기능을 통합하고, 라이선스 비호환성을 방지하고, 사용자 공간을 취약하게 만들지 않도록 합니다.

통합 아키텍처 및 BYOL(Bring Your Own Security) 기능

다음 진화는 SASE 아키텍처는 아래에 나와 있습니다. 아래 그림 6에 표시된 세 가지 두드러진 점이 있습니다.

ICAP(Internet Content Adaptation Protocol)를 통한 보안 서비스 지원: 엔트erp상승은 다른 보안 공급업체의 보안 서비스를 사용하는 데 사용되거나 사용하는 것을 좋아할 수 있습니다. ICAP IETF의 사양은 프록시가 보안 서비스를 포함하여 외부 콘텐츠 적응 서비스와 통신할 수 있는 방법을 지정합니다. 외부 보안 서비스를 허용함으로써, SASE 솔루션 공급자는 Ent를 활성화합니다.erp보안 서비스를 선택해야 합니다.

자체 보안 기능 사용: "데이터 위반 비용 보고서 2022"에 대한 IBM 보안 보고서에 따르면 조직은 데이터 위반을 감지하고 억제하는 데 평균 277일이 소요됩니다. 그렇지만 SASE 매우 좋은 정책 구성을 제공하지만 일부 데이터 위반 억제에는 프로그래밍 방식의 규칙이 필요할 수 있습니다. 데이터 유출을 분석하는 조직은 이러한 프로그램을 개발하기에 좋은 위치에 있습니다. 에 따라 SASE 제공업체나 보안 서비스와 같이 공급업체는 제품 릴리스가 전체 소프트웨어 개발 수명 주기를 거쳐야 하므로 시간이 걸릴 수 있습니다. 이러한 지연을 방지하기 위해 새로운 SASE 아키텍처는 Ent를 위한 방법을 제공합니다.erprises의 보안 팀은 프로그래밍 방식의 규칙을 자체적으로 개발하고 배포합니다. 이것들은 프록시에 불안정성을 야기하지 않기 때문에, SASE 아키텍처는 프로그래밍 방식의 규칙을 WASM 모듈로 생성할 수 있도록 WASM 런타임을 제공합니다. WASM 런타임은 샌드박스 역할을 하므로 WASM 모듈의 문제로 인해 호스팅 사용자 공간 및 기타 보안 기능 플러그인이 충돌/죽지 않습니다.

통합 프록시: 보안 인터넷 액세스 및 보안 애플리케이션 액세스 모두를 위한 하나의 통합 프록시는 메모리 요구 사항을 줄일 수 있습니다. Anti-Malware 및 DLP와 같은 일부 보안 기능의 엔진 및 피드는 메모리 호거입니다. 각 Ent에 대해 두 개의 서로 다른 프록시 인스턴스 가져오기erp따라서 상승 사이트는 비용이 많이 들 수 있습니다. 또한 세 가지 모드(정방향, 역방향 및 투명)를 모두 지원하는 하나의 프록시를 갖는 것은 개발자 생산성 관점에서도 좋은 개발 관행입니다.

새로운 세대의 아키텍처 원칙을 따르는 추가 아키텍처 원칙 SASE 건축은

Cloud 원주민: 유니버설에서 논의한 바와 같이 SASE 이 블로그 게시물, SASE 온프레미스에는 서비스가 필요합니다. Clouds 및 Edge. 그러므로 신세대 SASE 아키텍처는 'Cloud 네이티브' 원칙을 만드는 것 SASE 어디서나 일하세요. 그렇지만 Cloud 네이티브와 Kubernetes는 동의어가 아닌 경우가 많습니다. cloud 네이티브는 Kubernetes 기반입니다. Kubernetes에서 솔루션이 작동하도록 선택한 이유는 cloud/edge 제공업체는 Kubernetes-as-a-service를 제공하며, 더 중요한 것은 API 인터페이스가 그대로 유지된다는 것입니다. cloud/가장자리 공급자. Kubernetes의 일관된 API 인터페이스 덕분에 cloud/edge 제공자, K8s 기반 SASE 솔루션은 완벽하게 작동합니다ssly 건너편에 cloud/가장자리 공급자.

격리 아키텍처: Current SASE 아키텍처는 효율성상의 이유로 여러 테넌트 세션이 공유 사용자 공간 프로세스를 통해 진행될 수 있도록 합니다. 영리한 방법을 사용하여 테넌트 간에 겹치는 IP 주소가 있더라도 일정 수준의 격리가 유지되도록 합니다. 여러 테넌트에 대한 공유 사용자 공간 프로세스는 성능 및 보안 격리 관점에서 좋은 것이 아닙니다. 공유 리소스를 사용하면 테넌트에 대한 DDOS 공격과 같은 오작동으로 인해 다른 테넌트의 트래픽에서 성능 문제가 발생할 수 있습니다. 또한 공유 사용자 공간 프로세스에 대한 익스플로잇은 모든 테넌트의 모든 비밀/암호/키를 노출할 수 있습니다. 위의 사항을 염두에 두고 신세대 SASE 아키텍처는 점점 더 전용 사용자 공간 프로세스 또는 전용 컨테이너를 통해 전용 프록시 인스턴스를 사용하고 있습니다.

API 우선 아키텍처: Current SASE 솔루션은 구성 및 관찰을 위한 CLI 및 Portal을 제공합니다. 일부 SASE 솔루션은 CLI/포털과 백엔드 관리 시스템 사이에서 API를 사용하며 광고되지 않습니다. 경우에 따라 API가 깨끗하지 않았을 수 있습니다. 새로운 SASE 솔루션은 API가 CLI 및 포털 구현뿐만 아니라 제XNUMX자가 외부 프로그래밍 엔티티를 개발하기 위해 정의되는 API 우선 아키텍처를 채택하고 있습니다. API는 간단한 스크립트 개발에서 복잡한 워크플로 개발에 이르기까지 Terraform 및 기타를 통해 SecOps-as-code를 가능하게 합니다.

RESTful API, OpenAPI 기반 문서가 포함된 JSON 페이로드를 사용하는 것이 일반적이지만 일부는 보안 및 네트워킹 개체 및 정책을 구성하기 위해 Kubernetes 사용자 지정 리소스를 노출하기도 합니다.

API First 아키텍처는 또한 RBAC(Role Based Access Control) 구현에서 실제 백엔드 로직을 분리할 것으로 예상됩니다. 업계 경험에 따르면 RBAC와 비즈니스 로직이 결합될 때 많은 수의 취약점이 있습니다. 결과적으로 업계는 RBAC 기능을 외부 엔터티로 분리하고 애플리케이션이 비즈니스 논리에 집중하도록 하는 방향으로 이동하고 있습니다. 동일한 논리가 적용됩니다. SASE 관리 시스템, 여기서 SASE 관리 시스템은 SAE 정책/객체 및 관찰 가능성에 초점을 맞추고 RBAC 기능은 인그레스 프록시 및 API 게이트웨이와 같은 외부 엔터티에 맡깁니다. Ingress 프록시는 모든 인증 및 권한 부여와 API 라우팅을 처리합니다. 좋은 점은 하나의 인그레스 프록시가 여러 애플리케이션을 프런트엔드할 수 있다는 것입니다. 이로 인해 관리 사용자는 여러 애플리케이션에서 하나의 RBAC 엔터티에만 익숙해지면 됩니다. RBAC에서 비즈니스 로직을 분리하기 위해 API 우선 아키텍처 솔루션은 몇 가지 지침을 따를 것으로 예상됩니다. 예를 들어 많은 수신 프록시 및 API 게이트웨이는 URI가 RBAC에 대한 리소스를 가리키는 데 사용된다고 예상합니다. 워크플로 기반 자동화의 경우 관리 시스템이 구성에 태그를 지정하고 이전 태그로 복원하여 saga 패턴을 활성화할 수 있다는 기대가 있습니다. 모든 API 우선 아키텍처는 업계 모범 사례를 따를 것으로 예상됩니다.

요약

네트워크 보안 아키텍처는 물리적/모놀리식 개체에서 가상 어플라이언스 및 컨테이너로 진화하고 있습니다. 많은 cloud- 응용 프로그램 세계에서 인기를 얻은 기본 원칙이 다음에서 채택되고 있습니다. SASE 얻을 수 있는 솔루션 cloud- 확장/축소, 민첩성, 다중화 등의 이점을 제공합니다.cloud / 에지 준비 및 여러 테넌트에서 리소스를 효율적으로 사용합니다. 새로운 아키텍처 원칙과 방법을 알아보려면 이 공간을 주목하세요. Aryaka 활용하고 있다 cloud-같은 기술.

• CTO 인사이트 블로그

  XNUMXD덴탈의 Aryaka CTO Insights 블로그 시리즈는 네트워크, 보안 및 보안에 대한 사고 리더십을 제공합니다. SASE 주제. 을 위한 Aryaka 제품 사양 참조 Aryaka 데이터시트.