보안을 단순화: 통합된 정책 간소화 SASE

보안 위험과 관리 복잡성을 줄이려면 구성과 제어의 균형이 중요합니다.

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

정책 구성의 역할

정책 구성이 중요한 역할을 합니다.isp내에서 보안을 강화하는 역할을 활성화합니다. SASE 뼈대. 잘못 구성된 정책의 영향은 리소스 위협 및 데이터 유출부터 의도하지 않은 과도한 액세스 허용에 이르기까지 다양합니다. 오늘날의 업계 환경에서 조직은 보안 정책 관리에 대한 두 가지 주요 접근 방식을 고심하고 있습니다.

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

정책 관리의 균형 유지

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

그러나 과도한 구획화로 인해 여러 문제가 발생할 수 있으므로 주의를 기울이는 것이 중요합니다. 관리자는 문제를 식별하고 해결하기 위해 여러 정책 테이블을 탐색하며 잠재적으로 해결이 지연될 수 있습니다.

주요 요구 사항 이해

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

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

보안 액세스 서비스 에지(SASE) 구성 요소는 직원, 파트너 및 게스트를 포함하여 다양한 조직의 광범위한 리소스에 대한 위협 보호 및 액세스 제어를 포괄하는 포괄적인 보안을 제공합니다. 이 보안 프레임워크 내에서 조직에는 보안의 다양한 측면을 담당하는 별도의 관리자 범주가 있는 경우가 많습니다.

예를 들어, 조직에는 위협 방지 관리를 전담하는 관리자 그룹이 있고 액세스 제어에 중점을 두는 그룹이 있을 수 있습니다. 이러한 광범위한 범주 내에서 조직은 특정 유형의 위협 방지 및 액세스 제어에 맞춰 다양한 관리 역할을 설정하는 것이 일반적입니다. 몇 가지 실제 사례를 살펴보겠습니다.

위협 방지 역할:

• 침입 감지 및 방화벽 구성: “위협-보호-ngfw-role”에는 침입 탐지 및 방화벽 설정을 구성할 수 있는 액세스 권한이 부여됩니다. SASE 환경을 제공합니다.
• 평판 통제: 위협 방지 평판 역할을 맡은 관리자는 IP 평판 제어와 관련된 설정을 관리할 수 있으며, URL기반 평판 제어, 도메인 기반 평판 제어, 파일 평판 제어 등 cloud-서비스 및 cloud-조직의 평판을 통제합니다.
• 맬웨어 방지: "위협-보호-맬웨어-보호-역할"을 가진 관리자는 특히 맬웨어 방지 제어와 관련된 설정을 구성할 권한이 있습니다.

액세스 제어 역할:

• SWG 구성: "access-control-Internet-role"로 지정된 관리자는 SWG(Secure Web Gateway) 구성을 관리할 책임이 있습니다.
• SaaS 애플리케이션별 액세스 제어: "액세스 제어-saas1app-role' 및 'access-control-saasNapp-role”은 특정 애플리케이션에 대한 액세스 제어 정책 구성에 중점을 둡니다(SaaS 서비스 1 및 SaaS 서비스 N), 세밀한 제어를 보장합니다.
• 엔트erp상승 애플리케이션 관리: "access-control-hostedapp1-role" 및 "access-control-hostedappM-role"과 같은 역할은 기업에 대한 액세스 제어 구성을 처리하는 데 전담됩니다.erp상승 수준 애플리케이션, app1 및 appM.

조직에서 다중 테넌트 애플리케이션을 사용하는 경우 보안 구성을 효과적으로 관리하기 위해 추가 역할이 도입될 수 있습니다. 예를 들어 조직의 인력, 테넌트별 인력, 게스트에 대한 정책을 구성하기 위해 역할을 설정할 수 있습니다. 다양한 관리자 그룹이 관리하는 보안 구성을 갖춘 애플리케이션 "X"를 생각해 보세요.

• 소유자 인력 보안: "access-control-hostedappX-role" 및 "access-control-owner-workforce-role"이 있는 관리자는 협력하여 소유자 직원을 위한 애플리케이션 "X"에 대한 액세스 제어 구성을 관리합니다.
• 테넌트를 위한 애플리케이션 테넌트별 인력: "access-control-hostedAppX-role" 및 "access-control-owner-tenantA-workforce-role"과 같은 역할을 통해 관리자는 테넌트 A의 직원에 대한 액세스 제어 설정을 구성할 수 있습니다.
• 테넌트 B의 애플리케이션 테넌트 특정 인력: 다중 테넌트 애플리케이션 "X"의 경우 "access-control-hostedAppX-role" 및 "access-control-owner-tenantB-workforce-role"과 같은 다양한 역할을 통해 테넌트 B의 인력에 대한 액세스 제어 구성 관리를 용이하게 합니다. .

또한, 멀티 테넌트가 아닌 기업이라도erp상승 애플리케이션에는 다양한 인력 부문에 대해 별도의 관리자가 필요할 수 있습니다. 예를 들어:

• 엔지니어링 부서: "access-control-hostedappY-role" 및 "access-control-eng-role"이 있는 관리자는 엔지니어링 부서 내의 애플리케이션 "Y"에 대한 액세스 제어 구성을 관리하는 데 중점을 둡니다.
• 영업 및 마케팅 : "access-control-hostedappY-role" 및 "access-control-sales-role"과 같은 역할은 영업 및 마케팅 팀의 액세스 제어 설정을 구성하기 위해 지정됩니다.
• IT 부서: "access-control-hostedappY-role" 및 "access-control-it-role"이 있는 관리자는 IT 부서와 관련된 액세스 제어 구성에 대한 책임이 있습니다.

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

• 발생하기 쉬운 오류: 여러 관리자가 동일한 정책 테이블과 중복되는 권한을 사용하여 작업하면 정책을 추가, 삭제 또는 수정할 때 실수로 오류가 발생할 수 있습니다.
• 문제 해결 복잡성: 모놀리식 정책 테이블 내에서 문제를 해결하는 것은 시간이 많이 걸리고 어려울 수 있습니다.
• 정책 과부하: 다양한 애플리케이션과 위협 방지 시나리오를 다루는 모든 정책을 단일 테이블로 통합하면 번거롭고 다루기 힘든 정책 관리 환경은 물론 정책 평가 중에 잠재적인 성능 문제가 발생할 수 있습니다.

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

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

조직에서는 다음을 포함한 모든 구성에 대해 변경 제어 관리를 점점 더 많이 수용하고 있습니다. SASE 구성 오류를 구현하기 전에 사전에 감지하고 수정합니다. 이 관행은 보호 장치 역할을 할 뿐만 아니라 XNUMX차 조사 계층을 도입하여 구성이 적용되기 전에 두 번째 감시자가 구성을 검토하고 승인할 수 있도록 합니다.

보안 정책 구성은 트래픽 흐름 내에서 직접 적용되므로 정책 오류로 인해 잠재적으로 서비스가 중단되고 직접적인 재정적 결과가 초래될 수 있습니다.

보안 정책 구성의 본질적인 복잡성에 대처하기 위해 변경 사항을 직렬화하는 것이 일반적인 관행입니다. 즉, 한 가지 구성 유형을 수정하면 이전 구성 유형이 적용되거나 취소될 때까지 동일한 유형의 다른 구성 세션이 시작되지 않습니다. 그러나 모든 위협 및 액세스 제어 기능을 포함하는 단일 정책 테이블을 사용하는 경우 변경 내용을 직렬화하면 다른 관리자가 수행하는 구성 조정이 지연될 수 있습니다.

이와 대조적으로 다중 테이블 접근 방식은 이 시나리오를 효과적으로 처리할 수 있으므로 여러 관리자가 서로 다른 테이블에서 동시에 작업할 수 있으므로 구성 변경 프로세스가 간소화됩니다.

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

SASE 일반적으로 서비스로 제공되며, SASE 공급자는 여러 조직에 고객으로 서비스를 제공할 수 있습니다. 이러한 조직은 규모, 규제 요구 사항 및 구조 내 역할의 다양성 측면에서 크게 다를 수 있습니다. 일부 조직에서는 온프레미스 또는 cloud다른 사람들은 독점적으로 서비스에 의존할 수 있습니다. SaaS 제공업체가 있으며 일부는 두 가지를 모두 통합할 수도 있습니다.

또한 특정 조직에는 다양한 관리 역할이나 여러 관리 사용자가 필요하지 않을 수도 있습니다. 조직의 응용 프로그램 수가 제한되어 있고 여러 관리 역할의 복잡성이 부족한 시나리오에서는 더 적은 수의 정책 테이블을 사용하는 것이 가치가 있을 수 있습니다.

SASE 여러 관련 보안 기능 및 애플리케이션에 통합 정책 테이블을 사용하는 옵션을 포함하여 이러한 다양한 요구 사항을 수용하는 데 필요한 유연성을 제공하도록 설계될 것으로 예상됩니다.

혼란스러운 구성 방지:

어떤 SASE 솔루션은 앞서 설명한 단순화를 추구하면서 다양한 일치 속성에 대한 값으로 정책을 구성할 수 있는 모든 것을 포괄하는 단일 정책 테이블을 선택합니다. 트래픽 처리 중에 정책 선택은 들어오는 트래픽의 값과 기타 상황 정보를 정책에 지정된 속성 값과 일치시키는 것을 기반으로 합니다.

그러나 트래픽을 처리하는 동안 트래픽의 모든 속성을 쉽게 알 수는 없다는 점을 인식하는 것이 중요합니다. 예를 들어 상태 저장 검사 방화벽의 경우 5튜플 정보(소스 IP, 대상 IP, 소스 포트, 대상 포트 및 IP 프로토콜)와 같은 제한된 트래픽 값 집합만 추출할 수 있습니다. 한편, SWG, ZTNA 및 같은 프록시 기반 보안 구성 요소의 경우 CASB, 속성 값 추출은 다양할 수 있으며 별도의 단계, 특히 사전 TLS 검사 및 사후 TLS 검사 단계가 포함될 수 있습니다.

TLS 검사/암호 해독 전에는 많은 HTTP 속성이 알려지지 않은 상태로 남아 있습니다. 액세스 URI 경로, HTTP 메서드 및 요청 헤더와 같은 추가 속성을 평가에 사용할 수 있게 되는 것은 TLS 암호 해독 이후에만 가능합니다.

보안 정책 구성을 담당하는 관리자로서 관리자가 정책을 정의하는 동안 패킷 처리의 다양한 단계에서 어떤 속성이 유효한지 추적하기를 기대하는 것은 비현실적입니다. 일부 보안 솔루션은 정책 평가에서 관련 없는 속성을 고려하지 않는다고 주장하지만, 복잡한 정책을 검사할 때 어떤 속성이 적절하고 어떤 속성이 그렇지 않은지 결정하는 것은 어려울 수 있습니다.

우리는 여러 단계의 정책 테이블을 단일 테이블로 통합하면 관리자에게 복잡성과 혼란을 야기한다고 굳게 믿습니다. 이러한 접근 방식은 이해하기 어려울 수 있으며 잠재적으로 다음과 같은 결과를 초래할 수 있습니다.erp렉싱 구성. 명확성을 보장하려면 일관되고 간단한 평가를 위해 관련 속성만 포함하는 정책을 특정 테이블 내에 생성하는 것이 좋습니다.

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

일부 보안 솔루션은 별도의 "거부" 및 "허용" 정책 테이블을 유지하는 구조를 채택합니다. 이 설정 내에서 "거부" 목록에 정의된 정책이 우선적으로 적용되며 먼저 평가됩니다. "거부" 테이블에 일치하는 정책이 없으면 "허용" 정책 테이블로 평가가 진행됩니다. 그러나 이렇게 정책을 두 개의 개별 테이블로 나누면 관리자에게 문제가 될 수 있습니다.

우리는 특정 정책 테이블이 순서가 지정된 정책 목록으로 표시되는 보다 효율적인 접근 방식을 굳게 옹호합니다. 이 배열에서 각 정책은 해당 작업("거부", "허용" 또는 기타 원하는 작업)을 명시적으로 지정합니다. 트래픽 처리 중에 정책 평가는 일치 항목이 발견될 때까지 우선 순위가 가장 높은 정책에서 우선 순위가 가장 낮은 정책으로 논리적 진행을 따릅니다. 일치하는 정책이 식별되면 해당 작업이 트래픽에 적용됩니다. 일치하는 정책이 없는 경우 조직의 보안 정책에 정의된 대로 "Fail Open" 또는 "Fail Close"와 같은 기본 작업이 트리거됩니다.

이 접근 방식은 정책 작업 값에 관계없이 단일하고 정렬된 목록 내에서 정책을 통합하여 복잡성을 최소화하고 정책 평가 프로세스를 간소화함으로써 정책 관리를 단순화하고 관리자의 명확성을 향상시킵니다. 작업 값을 기준으로 정책 테이블을 분리하지 않는 것도 활성화됩니다. SASE 솔루션 제공업체는 미래에 비교적 쉽게 새로운 행동 가치를 도입할 것입니다.

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

수집한 내용에 따라 관리자는 일치하는 속성에 대한 값 집합을 정의하여 정책을 만듭니다. 전통적으로 트래픽 평가 중에 정책 일치가 작동하는 방식에 대한 일반적인 이해가 있었습니다. 즉, 정책에 지정된 모든 속성 값이 들어오는 트래픽 세션의 값과 완벽하게 일치하는 경우에만 정책이 일치하는 것으로 간주됩니다. 이러한 값은 트래픽에서 직접 추출되거나 인증된 사용자 컨텍스트 및 트래픽 시작을 담당하는 장치 컨텍스트와 같은 컨텍스트 정보에서 추론될 수 있습니다. 기본적으로 이 일치 프로세스에는 정책의 모든 속성에 대한 'AND' 작업이 포함됩니다.

그러나 보안 기술이 발전함에 따라 많은 보안 장치가 보다 유연한 접근 방식을 도입하여 관리자에게 속성에 여러 값을 할당할 수 있는 기능을 부여했습니다. 이 진화된 패러다임에서는 런타임 컨텍스트 정보가 정책 속성에 지정된 값과 일치하면 일치가 설정됩니다. 본질적으로 일치 프로세스는 이제 속성 전체에 대한 'AND' 연산과 해당 속성과 연관된 값에 대한 'OR' 연산을 결합합니다.

조직은 포괄적인 정책을 수립할 때 이러한 유연성을 통해 상당한 이점을 얻을 수 있습니다. 가독성을 유지하면서 필요한 전체 정책 수를 줄입니다. 그러나 이러한 다중 값 속성은 올바른 방향으로 나아가는 한 단계일 뿐이며 조직의 고유한 요구 사항을 충족하려면 추가 개선이 필요한 경우가 많습니다.

"NOT" 장식 지원: 관리자는 "NOT" 장식으로 정책 속성 값을 정의할 수 있는 기능이 필요합니다. 예를 들어 '소스 IP' 속성 값을 'NOT 10.1.5.0/24'로 지정할 수 있어야 합니다. 이는 트래픽 세션의 소스 IP가 10.1.5.0/24 서브넷에 속하지 않을 때 정책이 성공적으로 일치함을 나타냅니다. .

속성의 다중 인스턴스 지원: 많은 기존 보안 장치는 정책 내에서 특정 속성의 인스턴스를 하나만 지원합니다. 포괄적인 정책을 생성하려면 단일 정책 내에 동일한 속성의 여러 인스턴스를 포함하는 기능이 필수적입니다. 예를 들어 관리자는 다음을 수행할 수 있습니다. wan10.0.0.0/8 서브넷에 있는 모든 IP 주소의 세션을 허용하는 동시에 10.1.5.0/24 서브넷의 트래픽 세션을 거부합니다. 이는 단일 정책 내에서 달성할 수 있습니다. '소스 IP' 값을 두 번 지정하면 됩니다("소스 IP == 10.0.0.0/8" 및 "소스 IP == NOT 10.1.5.0/24"). 이렇게 하면 두 개의 별도 정책을 만들 필요가 없고 보다 직관적인 정책 관리가 가능해집니다.

문자열 유형 값에 대한 장식 지원: URI 경로, 도메인 이름 및 많은 HTTP 요청 헤더와 같이 문자열 값을 허용하는 속성은 'exact', 'starts_with' 및 'ends_with'와 같은 장식의 이점을 얻습니다. 이러한 장식은 표현적인 정책의 생성을 향상시킵니다.

정규식 패턴 지원: 어떤 경우에는 정책에 트래픽 값 내에서 패턴 일치가 필요합니다. 예를 들어 정책에서는 '사용자 에이전트' 요청 헤더 값에 특정 패턴이 있는 경우에만 트래픽 세션이 허용되도록 지정할 수 있습니다. 이러한 시나리오에서는 정규식 패턴에 대한 지원이 필수적입니다.

동적 속성 지원: 정책의 기존 속성은 고정되어 있고 사전 정의되어 있지만 SASE 환경에는 때때로 동적 속성이 필요합니다. 표준이 수많은 사용자 정의 헤더 및 클레임과 공존하는 요청 및 응답 헤더 또는 JWT 클레임을 고려하세요. SASE 관리자가 사용자 지정 헤더와 클레임을 수용하는 정책을 만들 수 있는 권한을 부여해야 합니다. 예를 들어, SASE 요청 헤더 'X-custom-header'를 속성으로 사용하고 값은 'matchme'로 정책 생성을 허용해야 합니다. 트래픽 시 요청 헤더 중 하나로 'X-custom-header'가 있고 값이 'matchme'인 모든 HTTP 세션은 정책과 일치해야 합니다.

객체 지원: 이 기능을 사용하면 즉각적인 값을 지정하는 대신 정책에서 속성 값으로 사용할 수 있는 값을 가진 다양한 유형의 개체를 생성할 수 있습니다. 객체는 여러 정책에서 참조될 수 있으며 향후 값 변경은 객체 수준에서 이루어질 수 있으므로 정책 수정이 단순화되고 일관성이 보장됩니다.

이러한 향상된 기능은 유연하고 표현력이 풍부하며 효율적인 보안 정책을 생성하는 데 기여하여 조직이 고유한 보안 요구 사항 및 시나리오에 맞게 정책을 효과적으로 조정할 수 있도록 지원합니다.

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

특정 보안 기능에는 트래픽 수정이 필요하며, 가장 일반적인 사용 사례에는 HTTP 요청/응답 헤더와 해당 값, 쿼리 매개변수와 해당 값, 심지어 요청/응답 본문의 추가, 삭제 또는 수정이 포함됩니다. 이러한 수정 사항은 관리자의 구성에 따라 크게 달라질 수 있습니다. 종종 특정 수정 사항은 대상 애플리케이션/사이트 서비스와 같은 트래픽 값과 트래픽 런타임 중에 사용할 수 있는 상황별 정보에 따라 달라집니다.

트래픽 수정을 위해 별도의 정책 테이블을 유지하는 것보다 이러한 수정 개체를 액세스 정책 자체에 포함시키는 것이 더 효율적인 경우가 많습니다. 이 접근 방식은 정책 관리를 간소화하고 수정 사항이 트래픽 동작을 관리하는 정책과 직접적으로 일치하도록 보장합니다.

교통 수정이 필수적인 대표적인 시나리오 중 하나는 다음과 같습니다. Cloud 액세스 보안 브로커(CASB) 솔루션, 특히 조직에서 다중 테넌트 제한이 필요한 경우. 이러한 제한 사항에는 공동 작업 관련 정책을 시행하기 위해 특정 요청 헤더 및 값을 추가하는 경우가 많습니다. 또한 엔드투엔드 문제 해결 및 성능 분석을 위한 사용자 지정 헤더 추가와 같이 트래픽 수정이 중요한 역할을 하는 다른 경우도 있습니다.

결과적으로 조직은 기대합니다. SASE 원활한 정책 지원을 위한 솔루션ssly 수정 개체와 통합합니다. 트래픽 처리 중에 일치하는 정책이 적절한 수정 개체와 연결되면 트래픽 수정이 실행되어 트래픽 관리 및 정책 시행에 대한 통합되고 효율적인 접근 방식을 제공합니다.

관찰 가능성 향상:

관찰 가능성을 위해 세션이 끝날 때 모든 트래픽 세션을 기록하는 것이 일반적인 관행입니다. 상당한 세션 또는 "코끼리" 세션과 관련된 경우 정기적으로 액세스 정보를 기록하는 것도 관례입니다. 이러한 세션 로그에는 일반적으로 트래픽 메타데이터, 세션 중에 수행된 작업, 클라이언트와 서버 간에 전송된 패킷 및 바이트에 관한 세부 정보를 포함한 중요한 데이터가 포함됩니다.

한 가지 중요한 발전은 다음과 같습니다. SASE 보안 기능을 통합하고 단일 패스, 런타임 완료 아키텍처를 채택하여 통합 세션 로그를 생성합니다. 이는 비-SASE 각 개별 보안 구성 요소가 자체 세션 로그를 생성하는 보안 배포에는 일치된 정책에 대한 정보와 일치 프로세스에 사용된 중요한 속성 값이 포함되는 경우가 많습니다. 중요한 것은 그 동안 SASE 단일 로그를 생성하더라도 중요한 정보의 포함이 손상되어서는 안 될 것으로 기대됩니다.

다양한 보안 기능 및 정책 테이블에 대한 여러 정책 평가로 인해 트래픽 세션이 허용되는 경우 결과 로그에는 일치된 모든 정책에 대한 정보가 포함되어야 합니다. 또한 특정 트래픽 또는 컨텍스트 속성 값으로 인해 정책이 일치하는 경우 로그는 정책 일치로 이어진 속성 값에 대한 정확한 세부 정보를 제공해야 합니다.

조직이 효과적인 관찰 가능성을 위해 포괄적인 로그에 의존한다는 점을 고려하면, SASE 솔루션은 로그에 철저한 정보를 제공하여 관리자가 네트워크 트래픽을 효과적으로 모니터링하고 분석하는 데 필요한 데이터에 액세스할 수 있도록 보장합니다.

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

전부는 아니라는 사실을 인식하는 것이 중요합니다. SASE 솔루션은 동일합니다. 조직은 특정 사항이 있는지 신중하게 평가해야 합니다. SASE 솔루션은 유용성을 희생하지 않고 특정 조직의 요구 사항에 부합합니다. 조직이 처음에는 위에 나열된 모든 요구 사항을 보유하지 못할 수도 있지만 이는 단지 matt이러한 요구 사항이 점점 더 관련성이 높아지고 운영에 필수적이 되기까지는 시간이 더 걸립니다.

앞서 언급한 요구 사항을 모두 갖춘 조직은 자신의 요구 사항을 맞춤화하는 데 있어 완전한 유연성을 누릴 수 있습니다. SASE 특정 요구에 맞는 정책을 제공합니다. 반면, 현재 이러한 요구 사항을 모두 갖추고 있지 않은 조직은 요구 사항이 발전함에 따라 추가 기능 도입에 주의를 기울이면서 보다 단순한 사용자 경험을 추구하는 경우가 많습니다. 이 접근 방식을 통해 조직은 현재 요구 사항과 미래 성장 사이의 균형을 유지하여 SASE 솔루션은 변화하는 상황에 적응력과 반응성을 유지합니다.

않는 한 SASE 솔루션은 완전한 유연성을 제공하지만 사용자 정의는 어려워집니다. 그러므로 우리는 믿습니다. SASE 솔루션은 다음과 같은 핵심 기능을 제공해야 합니다.

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

보안 기능의 포괄성 SASE 광범위할 수 있으며 다음이 포함될 수 있습니다.

• NGFW (차세대 방화벽): L3/L4 접근 제어, DDoS 보호, IP 평판, 도메인 평판 및 침입 탐지 및 예방 시스템(IDPS) 제공
• SWG(보안 웹 게이트웨이): TLS 검사, pre-TLS 웹 접근 제어, post-TLS 웹 접근 제어 제공, URL 평판, 파일 평판 및 맬웨어 방지.
• ZTNA(제로 트러스트 네트워크 액세스): SWG와 유사하지만 호스팅된 애플리케이션 보안에 중점을 둡니다.
• CASB (Cloud 액세스 보안 브로커): 피복 cloud 서비스 평판과 cloud 서비스 접근 제어.
• DLP(데이터 손실 방지): 개인 식별 정보(PII), 표준 기밀 문서 및 엔터티를 기반으로 액세스 제어 구현erp상승 특정 민감한 문서.

정책 연결을 통해 여러 정책 테이블을 통해 각 기능 내에서 정책을 관리하는 기능과 함께 각 보안 기능에 대한 정책 관리의 유연성은 강력한 기능입니다. 다양한 규제 요구 사항이 있는 지리적으로 분산된 조직은 특히 이러한 유연성의 이점을 누릴 수 있습니다.

그러나 소규모 조직에서는 일종의 정책 테이블 통합을 선호할 수 있습니다. 이러한 경우 다음을 통해 구성을 사용자 정의할 수 있습니다.

• 모든 TLS 이전 보안 기능 구성을 여러 SWG/ZTNA 구성 요소에 걸쳐 단일 정책 테이블 모음으로 통합합니다.
• 모든 TLS 이후 보안 기능 구성을 여러 SWG/ZTNA 구성 요소에 걸쳐 또 다른 단일 정책 테이블 컬렉션으로 통합합니다.
• 유지 CASB, 맬웨어 및 DLP는 복잡한 정책 정의가 필요하므로 별도의 엔터티로 작동합니다.
• 정책 테이블 컬렉션 내에서 단일 정책 테이블을 선택하여 정책 연결을 방지합니다.

그러므로 조직은 다음을 추구해야 한다. SASE 완전한 유연성을 제공하는 동시에 관련 보안 기능에 대한 구성을 통합하기 위한 맞춤형 제어 기능도 제공하는 서비스입니다. 이 접근 방식은 다음을 보장합니다. SASE 정책은 요구 사항이 발전함에 따라 관리 용이성과 확장성을 유지하면서 조직의 특정 요구 사항에 맞게 조정됩니다.

미래에 대비한 유연성과 사용자 경험의 균형

보안 정책 관리는 역사적으로 복잡한 작업이었습니다. 많은 제품이 특정 보안 어플라이언스에 대한 정책 관리를 전문으로 하므로 환경이 단편화됩니다. SASE 여러 보안 어플라이언스를 하나의 통합 솔루션으로 통합하여 이러한 복잡성을 해결합니다. 이러한 통합은 장점을 제공하지만 그 자체로 복잡성을 야기하기도 합니다.

단일 정책 테이블과 같은 기존 정책 관리 접근 방식은 처음에는 매력적으로 보일 수 있습니다. 그러나 이는 수많은 과제를 안고 있으며 이 문서에 설명된 요구 사항을 충족하지 못하는 경우가 많습니다. 반대로, 정책 엔진의 수가 너무 많으면 복잡성이 발생할 수도 있습니다. 유연성과 단순성 사이의 적절한 균형을 맞추는 것이 무엇보다 중요합니다.

업계의 중요한 과제 중 하나는 정책의 확산입니다. 정책 수가 너무 많으면 사용자 및 문제 해결 환경이 저하될 뿐만 아니라 성능에도 영향을 미칩니다. 앞서 설명한 다중 테이블 접근 방식과 정책 표현력은 정책 테이블 내 정책의 양을 줄이기 위한 필수 전략입니다.

SASE 솔루션은 정책 관리에 더욱 정교함을 제공함으로써 이러한 복잡성을 점점 더 해결하고 있습니다. 우리의 믿음은 SASE 솔루션은 가까운 시일 내에 이 문서에 자세히 설명된 많은 요구 사항을 구현하면서 계속 발전할 것입니다. 이러한 발전을 통해 조직은 사용자 경험, 유연성 및 성능 간의 최적의 균형을 유지하여 급변하는 위협 환경에서 보안 정책을 효과적이고 적응력 있게 유지할 수 있습니다.

• CTO 인사이트 블로그

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