보안을 간소화하세요: 통합 SASE에서 보안 정책 간소화하기 보안 액세스 서비스 에지(SASE) 서비스는 관련 아키텍처와 함께 여러 보안 구성 요소의 강력한 통합으로 구성되어 있습니다. 여기에는 상태 저장 검사 방화벽, 침입 탐지 및 방지 시스템(IDPS), DNS 보안, DoS/DDoS 보호, 보안 웹 게이트웨이(SWG), 제로 트러스트 네트워크 아키텍처(ZTNA), 클라우드 액세스 보안 브로커(CASB) 등이 포함됩니다. 이러한 구성 요소는 관리자가 정책을 통해 구성할 수 있는 기능을 제공하여 특정 액세스 요구 사항을 준수하면서 위협으로부터 조직의 자산을 보호하는 강력한 보호막을 제공합니다.

정책 구성의 역할

정책 구성은 SASE 프레임워크 내에서 보안을 강화하는 데 없어서는 안 될 중요한 역할을 합니다. 잘못 구성된 정책의 영향은 리소스 위협과 데이터 유출부터 의도치 않은 지나치게 허용적인 액세스까지 다양합니다. 오늘날의 업계 환경에서 조직은 보안 정책 관리에 대한 두 가지 주요 접근 방식을 두고 고민하고 있습니다:

  1. 단일 테이블 접근 방식: 모든 SASE 구성 요소에 걸쳐 위협 관리 및 다양한 액세스 제어 시나리오를 포괄하는 수많은 정책을 포함하는 통합 정책 테이블입니다.
  2. 다중 테이블 접근 방식: 위협 보호, 액세스 제어, 다양한 애플리케이션 및 사용자 그룹과 같은 특정 측면을 각각 다루는 여러 정책 테이블을 사용합니다.

정책 관리의 균형 잡기

관리하기 쉬운 보안 정책과 간소화된 문제 해결 절차를 제공해야 한다는 점에서 SASE에 대한 기대는 분명합니다. 이를 달성하려면 균형 잡힌 접근 방식이 필요합니다. 조직의 요구 사항에 따라 정책 복잡성을 완화하는 효과적인 전략 중 하나입니다. 규모가 큰 조직에서는 보안 기능, 애플리케이션 리소스 및 주체(사용자/그룹)에 따라 정책 테이블의 세분성을 정의하는 다중 테이블 접근 방식을 사용하여 구획화해야 할 수 있습니다. 소규모 조직은 여러 유형의 액세스 제어를 결합하거나 위협 방지와 액세스 제어를 결합하는 정책 테이블의 수를 줄여서 구획화하는 것을 선호할 수 있습니다. 이 유연한 접근 방식은 동시 관리가 필요한 정책의 수를 최소화하여 관리의 편의성을 높입니다. 그러나 지나친 구획화는 자체적인 문제를 야기할 수 있으므로 주의를 기울여야 합니다. 관리자는 문제를 식별하고 해결하기 위해 여러 정책 테이블을 탐색해야 하므로 해결이 지연될 수 있습니다.

주요 요구 사항 이해

복잡한 정책 관리에 대해 자세히 알아보기 전에 조직이 SASE 프레임워크 내에서 해결해야 하는 특정 요구 사항을 이해하는 것이 중요합니다. 주요 영역은 다음과 같습니다:

SASE 환경에서 역할 기반 보안 구성 관리의 필요성

보안 액세스 서비스 에지(SASE) 구성 요소는 직원, 파트너, 게스트 등 다양한 조직의 광범위한 리소스에 대한 위협 보호 및 액세스 제어를 포괄하는 포괄적인 보안을 제공합니다. 이러한 보안 프레임워크 내에서 조직은 종종 보안의 여러 측면을 담당하는 관리자의 범주를 구분합니다. 예를 들어, 조직에서 한 관리자 그룹은 위협 보호 관리를 전담하고 다른 그룹은 액세스 제어에 집중할 수 있습니다. 이러한 광범위한 범주 내에서 조직은 특정 유형의 위협 보호 및 액세스 제어에 맞는 다양한 관리 역할을 설정하는 것이 일반적입니다. 몇 가지 실제 사례를 살펴보겠습니다:

위협 보호 역할:

  • 침입 탐지 및 방화벽 구성: ‘위협 보호 및 방화벽 역할’을 가진 관리자에게는 SASE 환경 내에서 침입 탐지 및 방화벽 설정을 구성할 수 있는 액세스 권한이 부여됩니다.
  • 평판 제어: ‘위협-보호-평판-역할’을 맡은 관리자는 IP 평판 제어, URL 기반 평판 제어, 도메인 기반 평판 제어, 파일 평판 제어는 물론 클라우드 서비스 및 클라우드 조직 평판 제어와 관련된 설정을 관리할 수 있습니다.
  • 맬웨어 보호: “위협 보호-멀웨어 보호 역할”을 가진 관리자는 멀웨어 보호 제어와 관련된 설정을 구체적으로 구성할 수 있는 권한이 있습니다.

액세스 제어 역할:

  • SWG 구성: “액세스 제어-인터넷 역할”로 지정된 관리자는 보안 웹 게이트웨이(SWG) 구성을 관리할 책임이 있습니다.
  • SaaS 애플리케이션별 액세스 제어: “access-control-saas1app-role” 및 “access-control-saasNapp-role”과 같은 역할은 특정 애플리케이션(SaaS 서비스 1 및 SaaS 서비스 N)에 대한 액세스 제어 정책을 구성하여 세분화된 제어를 보장하는 데 중점을 둡니다.
  • 엔터프라이즈 애플리케이션 관리: ‘액세스 제어 호스팅 앱1 역할’ 및 ‘액세스 제어 호스팅 앱M 역할’과 같은 역할은 엔터프라이즈 수준 애플리케이션인 앱1 및 앱M에 대한 액세스 제어 구성을 처리하는 전용 역할입니다.

조직에서 멀티테넌트 애플리케이션을 사용하는 경우 보안 구성을 효과적으로 관리하기 위해 추가 역할이 도입될 수 있습니다. 예를 들어 역할을 설정하여 조직의 인력, 테넌트별 인력, 심지어 게스트에 대한 정책을 구성할 수 있습니다. 서로 다른 관리자 집합이 관리하는 보안 구성이 있는 애플리케이션 ‘X’를 생각해 보세요:

  • 소유자 인력 보안: ‘액세스 제어 호스팅 앱X 역할’과 ‘액세스 제어 소유자 인력 역할’을 가진 관리자가 협업하여 소유자의 인력에 대한 애플리케이션 ‘X’의 액세스 제어 구성을 관리합니다.
  • 테넌트를 위한 애플리케이션 테넌트별 인력: 관리자는 ‘액세스 제어 호스팅된AppX 역할’ 및 ‘액세스 제어 소유자 테넌트A 인력 역할’과 같은 역할을 통해 테넌트 A의 인력에 대한 액세스 제어 설정을 구성할 수 있습니다.
  • 테넌트 B에 대한 애플리케이션 테넌트별 인력: 멀티테넌트 애플리케이션 ‘X’의 경우 ‘액세스 제어 호스팅된AppX-역할’ 및 ‘액세스 제어 소유자-테넌트B-인력-역할’과 같은 다양한 역할을 통해 테넌트 B의 인력에 대한 액세스 제어 구성을 쉽게 관리할 수 있습니다.

또한 멀티 테넌트가 아닌 엔터프라이즈 애플리케이션의 경우에도 여러 인력 세그먼트에 대해 별도의 관리자가 필요할 수 있습니다. 예를 들어

  • 엔지니어링 부서: ‘액세스 제어 호스팅 앱 Y 역할’ 및 ‘액세스 제어 엔진 역할’을 가진 관리자는 엔지니어링 부서 내 애플리케이션 ‘Y’에 대한 액세스 제어 구성을 관리하는 데 중점을 둡니다.
  • 영업 및 마케팅: 영업 및 마케팅 팀의 액세스 제어 설정을 구성하기 위해 ‘액세스 제어 호스팅 앱Y 역할’ 및 ‘액세스 제어 판매 역할’과 같은 역할이 지정됩니다.
  • IT 부서: ‘액세스 제어 호스팅 앱Y 역할’ 및 ‘액세스 제어 IT 역할’을 가진 관리자는 IT 부서와 관련된 액세스 제어 구성에 대한 책임이 있습니다.

역할 기반 보안 구성 관리의 가장 큰 장점은 특정 책임에 맞게 세분화된 제어를 제공할 수 있다는 점입니다. 이러한 접근 방식과 모든 것을 포괄하는 단일 정책 테이블을 사용할 때 발생할 수 있는 문제를 대조해 보세요:

  • 오류가 발생하기 쉽습니다: 여러 관리자가 동일한 정책 테이블로 작업하고 권한이 겹치면 정책을 추가, 삭제 또는 수정할 때 실수로 오류가 발생할 수 있습니다.
  • 복잡성 문제 해결: 단일화된 정책 테이블 내에서 문제를 해결하는 것은 시간이 많이 걸리고 어려울 수 있습니다.
  • 정책 과부하: 다양한 애플리케이션과 위협 보호 시나리오를 포괄하는 모든 정책을 단일 테이블로 통합하면 정책 관리가 번거롭고 다루기 어려울 뿐만 아니라 정책 평가 시 잠재적인 성능 문제가 발생할 수 있습니다.

결론적으로, SASE 환경 내에서 역할 기반 보안 구성 관리를 채택하면 조직은 단일 테이블 접근 방식과 관련된 복잡성을 피하면서 효율적으로 책임을 위임하고, 보안을 강화하며, 정책 관리를 간소화할 수 있습니다.

구성 변경 제어 관리와 함께 작업

구성 오류가 구현되기 전에 이를 사전에 감지하고 수정하기 위해 SASE 구성을 포함한 모든 구성에 대한 변경 제어 관리를 도입하는 조직이 점점 더 많아지고 있습니다. 이러한 관행은 안전장치 역할을 할 뿐만 아니라, 구성이 적용되기 전에 두 번째 감시자가 검토하고 승인할 수 있도록 하는 2차 감시 계층을 도입하는 것입니다. 보안 정책 구성은 트래픽 흐름 내에서 직접 적용되므로 정책 오류로 인해 서비스가 중단될 수 있으며 직접적인 금전적 손실이 발생할 수 있습니다. 보안 정책 구성의 고유한 복잡성에 대처하기 위해 변경 사항을 직렬화하는 것이 일반적인 관행입니다. 즉, 한 유형의 구성을 수정할 때 이전 구성이 적용되거나 취소될 때까지 동일한 유형의 다른 구성 세션이 시작되지 않습니다. 그러나 모든 위협 및 액세스 제어 기능을 포괄하는 단일 정책 테이블을 사용하는 경우 변경 사항을 직렬화하면 다른 관리자가 수행하는 구성 조정에 지연이 발생할 수 있습니다. 반면, 다중 테이블 접근 방식은 이러한 시나리오를 효과적으로 해결할 수 있어 여러 관리자가 서로 다른 테이블에서 동시에 작업할 수 있으므로 구성 변경 프로세스를 간소화할 수 있습니다.

모든 조직이 동일한 요구 사항을 공유하는 것은 아닙니다:

SASE는 일반적으로 서비스로 제공되며, SASE 제공업체는 여러 조직을 고객으로 두고 서비스를 제공할 수 있습니다. 이러한 조직은 규모, 규제 요건, 조직 내 역할의 다양성 측면에서 크게 다를 수 있습니다. 일부 조직은 온프레미스 또는 클라우드에서 여러 애플리케이션을 호스팅하는 반면, 다른 조직은 SaaS 제공업체의 서비스에만 의존하거나 두 가지를 모두 통합할 수도 있습니다. 또한 특정 조직에서는 다양한 관리 역할이나 여러 명의 관리 사용자가 필요하지 않을 수도 있습니다. 조직에 애플리케이션 수가 제한되어 있고 여러 관리 역할이 복잡하지 않은 경우에는 더 적은 수의 정책 테이블을 사용하는 것이 유용할 수 있습니다. SASE는 여러 관련 보안 기능 및 애플리케이션에 통합 정책 테이블을 사용하는 옵션을 포함하여 이러한 다양한 요구 사항을 수용하는 데 필요한 유연성을 제공하도록 설계될 예정입니다.

혼란스러운 구성 피하기:

앞서 설명한 대로 단순화를 추구하는 일부 SASE 솔루션은 다양한 일치하는 속성에 대한 값으로 정책을 구성할 수 있는 단일의 포괄적인 정책 테이블을 선택합니다. 트래픽 처리 중에 정책 선택은 들어오는 트래픽의 값과 기타 컨텍스트 정보를 정책에 지정된 속성 값과 일치시키는 것을 기반으로 합니다. 그러나 트래픽을 처리하는 동안 트래픽의 모든 속성을 쉽게 알 수 있는 것은 아니라는 점을 인식하는 것이 중요합니다. 예를 들어, 상태 저장 검사 방화벽의 경우 5-튜플 정보(소스 IP, 대상 IP, 소스 포트, 대상 포트, IP 프로토콜)와 같은 제한된 트래픽 값만 추출할 수 있습니다. 한편, SWG, ZTNA, CASB와 같은 프록시 기반 보안 구성 요소의 경우 속성 값 추출은 다양할 수 있으며, 특히 사전 TLS 검사 및 사후 TLS 검사 단계와 같은 별개의 단계를 포함할 수 있습니다. TLS 검사/복호화 이전에는 많은 HTTP 속성이 알려지지 않은 상태로 남아 있습니다. TLS 복호화 이후에만 액세스 URI 경로, HTTP 메서드 및 요청 헤더와 같은 추가 속성을 평가할 수 있습니다. 보안 정책 구성을 담당하는 관리자가 정책을 정의하는 동안 패킷 처리의 다양한 단계에서 어떤 속성이 유효한지 추적하는 것은 비현실적입니다. 일부 보안 솔루션은 정책 평가에서 관련 없는 속성은 고려하지 않는다고 주장하지만, 복잡한 정책을 검사할 때 어떤 속성이 관련 있고 어떤 속성이 관련 없는지 판단하는 것은 어려울 수 있습니다. 여러 단계에 걸친 정책 테이블을 단일 테이블로 통합하는 것은 관리자에게 복잡성과 혼란을 야기한다고 굳게 믿고 있습니다. 이러한 접근 방식은 이해하기 어렵고 잠재적으로 혼란스러운 구성으로 이어질 수 있습니다. 명확성을 확보하려면 일관되고 간단한 평가를 위해 관련 속성만 포함하는 정책을 주어진 테이블 내에 만드는 것이 좋습니다.

거부 및 허용 정책 테이블 최적화하기:

특정 보안 솔루션은 별도의 ‘거부’ 및 ‘허용’ 정책 테이블을 유지하는 구조를 채택하고 있습니다. 이 설정에서는 ‘거부’ 목록에 정의된 정책이 우선적으로 적용되며 먼저 평가됩니다. ‘거부’ 테이블에서 일치하는 정책을 찾을 수 없으면 ‘허용’ 정책 테이블로 평가가 진행됩니다. 하지만 이렇게 정책을 두 개의 서로 다른 테이블로 나누면 관리자에게는 어려움이 따를 수 있습니다. 저희는 주어진 정책 테이블이 정책의 정렬된 목록으로 표시되는 보다 간소화된 접근 방식을 강력히 지지합니다. 이 방식에서 각 정책은 ‘거부’, ‘허용’ 또는 기타 원하는 조치 등 해당 조치를 명시적으로 지정합니다. 트래픽 처리 중에 정책 평가는 일치하는 정책이 발견될 때까지 우선순위가 가장 높은 정책에서 가장 낮은 정책으로 논리적으로 진행됩니다. 일치하는 정책이 식별되면 해당 조치가 트래픽에 적용됩니다. 일치하는 정책이 없는 경우 조직의 보안 정책에 정의된 대로 ‘열기 실패’ 또는 ‘닫기 실패’와 같은 기본 작업이 트리거됩니다. 이 접근 방식은 정책 조치 값에 관계없이 정책을 하나의 정렬된 목록에 통합하여 복잡성을 최소화하고 정책 평가 프로세스를 간소화함으로써 관리자의 정책 관리를 간소화하고 명확성을 높입니다. 또한 액션 값에 따라 정책 테이블을 분리하지 않기 때문에 SASE 솔루션 제공업체는 향후 새로운 액션 값을 비교적 쉽게 도입할 수 있습니다.

유연하고 표현력이 풍부한 정책 만들기:

지금까지 살펴본 바와 같이 관리자는 일치하는 속성에 대한 값 집합을 정의하여 정책을 만듭니다. 기존에는 트래픽 평가 중 정책 매칭이 작동하는 방식에 대해 일반적으로 정책에 지정된 모든 속성 값이 들어오는 트래픽 세션의 값과 완벽하게 일치하는 경우에만 정책이 일치하는 것으로 간주했습니다. 이러한 값은 트래픽에서 직접 추출하거나 인증된 사용자 컨텍스트 및 트래픽을 시작한 디바이스 컨텍스트와 같은 컨텍스트 정보에서 유추할 수 있습니다. 기본적으로 이 매칭 프로세스에는 정책의 모든 속성에 대한 ‘AND’ 연산이 포함됩니다. 그러나 보안 기술이 발전함에 따라 많은 보안 장치에서 보다 유연한 접근 방식을 도입하여 관리자가 속성에 여러 값을 할당할 수 있는 기능을 제공합니다. 이 발전된 패러다임에서는 런타임 컨텍스트 정보가 정책 속성에 지정된 값과 일치하면 일치하는 것으로 설정됩니다. 이제 매칭 프로세스는 속성에 대한 ‘AND’ 연산과 해당 속성과 연관된 값에 대한 ‘OR’ 연산을 결합합니다. 조직은 포괄적인 정책을 만들 때 이러한 유연성을 통해 상당한 이점을 얻을 수 있습니다. 가독성을 유지하면서 필요한 전체 정책 수를 줄일 수 있습니다. 그러나 이러한 다중 값 속성은 올바른 방향으로 나아가는 한 단계일 뿐이며, 조직의 고유한 요구 사항을 충족하기 위해 추가 개선이 필요한 경우가 많습니다: “NOT” 데코레이션 지원: 관리자는 “NOT” 장식으로 정책 속성 값을 정의할 수 있는 기능이 필요합니다.
예를 들어, 트래픽 세션의 소스 IP가 10.1.5.0/24 서브넷에 속하지 않을 때 정책이 성공적으로 일치한다는 것을 나타내는 ‘소스 IP’ 속성 값을 ‘NOT 10.1.5.0/24’로 지정할 수 있어야 합니다. 속성의 여러 인스턴스 지원: 기존의 많은 보안 디바이스는 정책 내에서 특정 속성의 인스턴스 하나만 지원합니다. 포괄적인 정책을 만들려면 단일 정책 내에 동일한 속성의 여러 인스턴스를 포함할 수 있는 기능이 필수적입니다. 예를 들어 관리자는 10.0.0.0/8 서브넷의 모든 IP 주소로부터의 세션을 허용하는 동시에 10.1.5.0/24 서브넷으로부터의 트래픽 세션은 거부하고 싶을 수 있습니다. 이는 단일 정책 내에서 “source IP == 10.0.0.0/8” 및 “source IP == NOT 10.1.5.0/24” 등 ‘source IP’ 값을 두 번 지정하여 달성할 수 있어야 합니다. 이렇게 하면 별도의 정책을 두 개 만들 필요가 없으며 보다 직관적인 정책 관리가 가능해집니다. 문자열 유형 값에 대한 데코레이션 지원: URI 경로, 도메인 이름 및 많은 HTTP 요청 헤더와 같이 문자열 값을 허용하는 속성은 ‘exact’, ‘starts_with’, ‘ends_with’ 등의 데코레이션을 사용하면 이점을 얻을 수 있습니다.
이러한 데코레이션은 표현형 정책 생성을 향상시킵니다. 정규 표현식 패턴 지원: 경우에 따라 정책에 트래픽 값 내 패턴 일치가 필요한 경우가 있습니다. 예를 들어, ‘사용자 에이전트’ 요청 헤더 값에 특정 패턴이 있는 경우에만 트래픽 세션이 허용되도록 정책을 지정할 수 있습니다. 이러한 시나리오에서는 정규식 패턴 지원이 필수적입니다. 동적 속성 지원: 정책의 기존 속성은 고정적이고 미리 정의되어 있지만, SASE 환경에서는 동적 속성이 필요할 때가 있습니다. 표준이 수많은 사용자 지정 헤더 및 클레임과 공존하는 요청 및 응답 헤더 또는 JWT 클레임을 고려하세요. SASE는 관리자가 사용자 지정 헤더 및 클레임을 수용하는 정책을 만들 수 있도록 권한을 부여해야 합니다. 예를 들어, SASE는 요청 헤더 ‘X-custom-header’를 속성으로 하고 값을 ‘matchme’로 하는 정책 생성을 허용해야 합니다. 트래픽 시점에 요청 헤더 중 하나로 ‘X-custom-header’가 있고 값으로 ‘matchme’가 있는 모든 HTTP 세션은 정책과 일치해야 합니다. 객체 지원: 이 기능을 사용하면 즉각적인 값을 지정하는 대신 정책에서 속성 값으로 사용할 수 있는 값으로 다양한 유형의 개체를 만들 수 있습니다. 여러 정책에서 개체를 참조할 수 있으며, 향후 가치 변경은 개체 수준에서 이루어질 수 있으므로 정책 수정을 간소화하고 일관성을 유지할 수 있습니다. 이러한 개선 사항은 유연하고 표현력이 풍부하며 효율적인 보안 정책을 만드는 데 기여하여 조직이 고유한 보안 요구사항과 시나리오에 맞게 정책을 효과적으로 조정할 수 있도록 지원합니다.

트래픽 수정으로 정책 통합 강화

특정 보안 기능을 사용하려면 트래픽을 수정해야 하는데, 가장 일반적인 사용 사례는 HTTP 요청/응답 헤더와 그 값, 쿼리 매개변수와 그 값, 심지어 요청/응답 본문까지 추가, 삭제 또는 수정하는 것입니다. 이러한 수정 사항은 관리자의 구성에 따라 크게 달라질 수 있습니다. 특정 수정 사항은 대상 애플리케이션/사이트 서비스와 같은 트래픽 값과 트래픽 런타임 중에 사용할 수 있는 컨텍스트 정보에 따라 달라지는 경우가 많습니다. 트래픽 수정을 위한 별도의 정책 테이블을 유지하는 것보다 액세스 정책 자체에 이러한 수정 개체를 포함하는 것이 더 효율적인 경우가 많습니다. 이 접근 방식은 정책 관리를 간소화하고 수정 사항이 트래픽 행동을 관리하는 정책과 직접적으로 일치하도록 합니다. 트래픽 수정이 필수적인 대표적인 시나리오 중 하나는 클라우드 액세스 보안 브로커(CASB) 솔루션의 맥락에서, 특히 조직에서 멀티 테넌시 제한이 필요한 경우입니다. 이러한 제한에는 협업 관련 정책을 적용하기 위해 특정 요청 헤더와 값을 추가하는 경우가 많습니다. 또한 트래픽 수정이 중요한 역할을 하는 엔드투엔드 문제 해결 및 성능 분석을 위한 사용자 지정 헤더 추가와 같은 다른 사례도 있습니다. 따라서 조직은 SASE 솔루션이 수정 개체와 원활하게 통합되는 정책을 지원하기를 기대합니다. 트래픽 처리 중에 일치하는 정책이 적절한 수정 개체와 연결될 때 트래픽 수정이 실행되므로 트래픽 관리 및 정책 시행에 대한 통합적이고 효율적인 접근 방식을 제공합니다.

관찰 가능성 향상:

관찰 가능성을 위해 세션이 종료될 때 모든 트래픽 세션을 기록하는 것이 일반적인 관행입니다. 상당한 시간 또는 ‘코끼리’ 세션이 포함된 경우에는 주기적으로 액세스 정보를 기록하는 것이 관례입니다. 이러한 세션 로그에는 일반적으로 트래픽 메타데이터, 세션 중에 수행한 작업, 클라이언트와 서버 간에 전송된 패킷 및 바이트에 관한 세부 정보 등 중요한 데이터가 포함됩니다. SASE가 제공하는 중요한 발전 중 하나는 보안 기능의 통합과 단일 패스, 런타임 완료 아키텍처의 채택으로 세션 로그가 통합된다는 것입니다. 이는 각 개별 보안 구성 요소가 자체 세션 로그를 생성하는 비 SASE 보안 배포와 대조되며, 여기에는 종종 일치된 정책 및 일치 프로세스에 사용된 중요한 속성 값에 대한 정보가 포함되어 있습니다. 중요한 것은 SASE가 단일 로그를 생성하지만 중요한 정보가 포함되지 않아야 한다는 기대가 있다는 점입니다. 다양한 보안 기능 및 정책 테이블에서 여러 정책을 평가하여 트래픽 세션이 허용된 경우, 결과 로그에는 일치된 모든 정책에 대한 정보가 포함되어야 합니다. 또한 특정 트래픽 또는 컨텍스트 속성 값으로 인해 정책이 일치하는 경우 로그는 정책 일치로 이어진 속성 값에 대한 정확한 세부 정보를 제공해야 합니다. 조직이 효과적인 가시성을 위해 포괄적인 로그에 의존한다는 점을 고려할 때, SASE 솔루션은 로그에 철저한 정보를 제공하여 관리자가 네트워크 트래픽을 효과적으로 모니터링하고 분석하는 데 필요한 데이터에 액세스할 수 있도록 보장해야 합니다.

정책 관리에 대한 SASE 접근 방식:

모든 SASE 솔루션이 동일한 것은 아니라는 점을 인식하는 것이 중요합니다. 조직은 특정 SASE 솔루션이 사용성을 저하시키지 않으면서도 조직의 특정 요구사항에 부합하는지 신중하게 평가해야 합니다. 조직이 처음에 위에 나열된 모든 요건을 갖추지 못할 수도 있지만, 이러한 요건이 점점 더 관련성이 높아지고 운영에 필수적인 요건이 되는 것은 시간 문제일 뿐입니다. 앞서 언급한 모든 요구 사항을 충족하는 조직은 특정 요구 사항에 맞게 SASE 정책을 유연하게 조정할 수 있는 이점을 누릴 수 있습니다. 반면, 현재 이러한 요구 사항을 모두 갖추지 못한 조직은 요구 사항이 발전함에 따라 추가 기능을 도입하는 것을 주시하면서 더 간단한 사용자 경험을 추구하는 경우가 많습니다. 이러한 접근 방식을 통해 조직은 현재의 요구와 미래의 성장 사이에서 균형을 유지하여 변화하는 환경에 적응하고 대응할 수 있는 SASE 솔루션을 유지할 수 있습니다. SASE 솔루션이 완전한 유연성을 제공하지 않으면 사용자 지정이 어려워집니다. 따라서 SASE 솔루션은 다음과 같은 핵심 기능을 제공해야 한다고 생각합니다:

  1. 모듈식 정책 관리: SASE 솔루션에는 각각 고유한 정책 구성이 포함된 여러 보안 기능이 포함되어 있습니다. 이러한 구성에는 활성화/비활성화, 정책 일치 항목이 없는 경우 기본 동작 설정, 여러 정책 테이블 모음 관리, 각 정책 테이블 내에서 여러 정책 정의, 정책의 정렬된 목록 설정, 각 정책에 대한 동작 설정, 수정 개체, 일치하는 속성 및 값 설정 등의 옵션이 포함되어야 합니다.
  2. 정책 체인: 보다 구체적이고 세분화된 정책을 구현하려면 SASE 솔루션이 정책 연쇄를 지원해야 합니다. 즉, 컬렉션의 여러 정책 테이블에 걸쳐 정책을 배열할 수 있습니다. 예를 들어 조직은 여러 애플리케이션에 대해 별도의 정책 테이블을 가질 수 있으며, 기본 테이블 정책은 애플리케이션/도메인 이름을 일치 조건으로 사용하여 적절한 정책 테이블을 선택할 수 있습니다. 이는 일반적으로 정책 평가를 참조된 정책 테이블로 리디렉션하는 ‘점프’라는 액션이 있는 정책을 사용하여 수행합니다. 정책 체인 개념은 Linux IPTables에서 인기를 얻었으며 이후 많은 보안 솔루션에서 이 기능을 통합했습니다.

SASE 내 보안 기능의 포괄성은 광범위할 수 있으며 다음을 포함할 수 있습니다:

  • NGFW(차세대 방화벽): L3/L4 접속 제어, DDoS 방어, IP 평판, 도메인 평판, 침입 탐지 및 방지 시스템(IDPS)을 제공합니다.
  • SWG(보안 웹 게이트웨이): TLS 검사, TLS 전 웹 액세스 제어, TLS 후 웹 액세스 제어, URL 평판, 파일 평판 및 멀웨어 보호 기능을 제공합니다.
  • ZTNA(제로 트러스트 네트워크 액세스): SWG와 유사하지만 호스팅된 애플리케이션 보안에 중점을 둡니다.
  • CASB(클라우드 액세스 보안 브로커): 클라우드 서비스 평판 및 클라우드 서비스 액세스 제어를 다룹니다.
  • DLP(데이터 손실 방지): 개인 식별 정보(PII), 표준 기밀 문서 및 기업별 민감한 문서를 기반으로 액세스 제어를 구현합니다.

각 보안 기능에 대한 정책 관리의 유연성과 함께 정책 체인 기능이 있는 여러 정책 테이블을 통해 각 기능 내에서 정책을 관리할 수 있는 기능은 강력한 기능입니다. 다양한 규제 요건을 가진 지역적으로 분산된 조직은 특히 이러한 유연성의 이점을 누릴 수 있습니다. 그러나 소규모 조직에서는 정책 테이블을 통합하는 방식을 선호할 수 있습니다. 이러한 경우 다음과 같이 구성을 사용자 지정할 수 있어야 합니다:

  • 모든 TLS 이전 보안 기능 구성을 여러 SWG/ZTNA 구성 요소에 걸쳐 단일 정책 테이블 모음으로 통합합니다.
  • 모든 TLS 이후 보안 기능 구성을 여러 SWG/ZTNA 구성 요소에 걸쳐 하나의 단일 정책 테이블 모음으로 통합합니다.
  • 복잡한 정책 정의가 필요하므로 CASB, 멀웨어 및 DLP 기능을 별도의 엔티티로 유지합니다.
  • 정책 테이블 컬렉션 내에서 단일 정책 테이블을 선택하면 정책 연쇄를 피할 수 있습니다.

따라서 조직은 완전한 유연성을 제공하는 동시에 관련 보안 기능의 구성을 통합할 수 있는 사용자 지정 제어 기능을 제공하는 SASE 서비스를 찾아야 합니다. 이 접근 방식은 요구 사항의 변화에 따라 관리의 용이성과 확장성을 유지하면서 조직의 특정 요구 사항에 맞게 SASE 정책을 맞춤화할 수 있도록 합니다.

사용자 경험과 미래 지향적인 유연성 간의 균형 유지

보안 정책 관리는 그동안 복잡한 작업이었습니다. 많은 제품이 특정 보안 어플라이언스에 대한 정책 관리에 특화되어 있어 환경이 파편화되어 있습니다. SASE는 여러 보안 어플라이언스를 통합 솔루션으로 통합하여 이러한 복잡성을 해결합니다. 이러한 통합은 이점을 제공하지만, 그 자체로 복잡성을 야기하기도 합니다. 단일 정책 테이블과 같은 전통적인 정책 관리 방식은 처음에는 매력적으로 보일 수 있습니다. 그러나 많은 어려움이 있으며 이 문서에 설명된 요구 사항을 충족하지 못하는 경우가 많습니다. 반대로 정책 엔진의 수가 지나치게 많으면 복잡해질 수도 있습니다. 유연성과 단순성 사이의 적절한 균형을 맞추는 것이 가장 중요합니다. 업계에서 중요한 과제 중 하나는 정책의 확산입니다. 지나치게 많은 정책은 사용자 및 문제 해결 환경을 저하시킬 뿐만 아니라 성능에도 영향을 미칩니다. 앞서 설명한 다중 테이블 접근 방식과 정책 표현 방식은 정책 테이블 내에서 정책의 양을 줄이기 위한 필수 전략입니다. SASE 솔루션은 점점 더 정교한 정책 관리를 제공함으로써 이러한 복잡성을 해결하고 있습니다. SASE 솔루션은 가까운 시일 내에 이 문서에 설명된 많은 요구 사항을 구현하면서 계속 발전할 것으로 믿습니다. 이러한 진화를 통해 조직은 사용자 경험, 유연성, 성능 간에 최적의 균형을 유지하여 급변하는 위협 환경에서 보안 정책을 효과적이고 적응력 있게 유지할 수 있습니다.

  • CTO 인사이트 블로그

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