Cato SPACE 아키텍처를 통한 패킷 흐름 이해

이 문서는 Cato의 단일 패스 클라우드 엔진 아키텍처(SPACE)를 기반으로 PoP에서 보안 엔진의 패킷 흐름에 대해 설명합니다.

개요

Cato의 SPACE 아키텍처는 단일 서비스로 트래픽 흐름을 검토하고 처리합니다. 이 서비스에는 여러 네트워킹 및 보안 엔진이 포함되며, 이들은 동시에 트래픽 흐름을 분석하고 처리합니다. 이 아키텍처는 서비스 체인과 함께 여러 포인트 솔루션을 결합하는 데 따르는 제한을 방지합니다. 흐름의 단일 패스는 지연을 최소화하고 전체 네트워크 성능을 향상시킵니다. 각 PoP는 Cato의 모든 SPACE 서비스와 엔진을 사용하여 이러한 네트워킹 및 보안 결정을 수행할 수 있습니다.

보안 및 네트워킹 엔진은 트래픽 흐름을 위한 데이터에 완전한 접근 권한을 가지며, 동시적으로 데이터를 평가하고, 공유된 컨텍스트로 서로 데이터를 공유합니다. 엔진은 병렬로 운영되며, 특정 엔진이 다른 엔진보다 우선하여 트래픽 평가를 하지 않습니다. 엔진은 각 PoP에 위치하며, 다른 물리적 위치에 있는 엔진으로부터 정보를 기다리지 않고 데이터를 공유할 수 있습니다.

예를 들어, 방화벽 규칙이 macOS 장치를 차단하지만, 방화벽 엔진은 첫 번째 패킷에서 이 데이터를 가져올 수 없으므로 더 많은 데이터를 기다립니다. 다른 엔진이 장치를 macOS로 식별하면 방화벽은 규칙 작업에 따라 흐름을 차단합니다.

SPACE 네트워크 및 보안 서비스 요약

이 섹션은 패킷 흐름의 다양한 단계에 적용되는 PoP의 네트워크 및 보안 서비스와 엔진을 나열합니다.

Cato 정책 및 엔진
- 방화벽 - 인터넷 및 WAN 방화벽을 위한 방화벽 정책
- 네트워크 - 라우팅 및 QoS 우선 순위를 위한 네트워크 규칙 정책
- IPS/SAM - IPS 보호 및 의심스러운 활동 모니터링 (SAM)
- 앱 제어 - 애플리케이션 제어 정책을 위한 앱 식별
  - 앱 제어 gen2 - 접근 기반 앱 규칙: 허용 또는 차단
  - 앱 제어 gen3 - 세분화된 동작 기반 앱 규칙: 업로드, 다운로드 등
- TLSi - HTTPS 및 암호화된 트래픽을 위한 TLS 검사
- DLP - 데이터 유출 방지 (DLP) 정책을 위한 콘텐츠 검사
- AM/NGAM - 첨부된 파일을 악성코드에 대해 검사하는 안티-멀웨어 및 차세대 안티-멀웨어
트래픽 흐름 데이터 및 프로토콜
- 앱 식별 - 보안 또는 네트워킹 정책을 위한 특정 애플리케이션을 식별하는 다양한 기준
- OS - 장치의 운영 체제 (예: 장치 상태 또는 클라이언트 연결 정책)
- 클라이언트 클래스 - 이 네트워크 흐름을 생성한 운영 체제에서 실행되는 클라이언트 애플리케이션 유형(예: Chrome)
- URLF - 웹사이트 URL을 기반으로 Cato 카테고리를 필터링하는 URL 필터링
- 파일 유형 - CASB와 DLP를 위해 업로드 또는 다운로드 방향의 파일 첨부

SPACE와 함께하는 TCP 패킷 흐름

다음 항목이 있는 일반적인 HTTP 흐름의 예입니다:

타임라인 - 트래픽 흐름의 다른 단계
사용 가능한 필드 - 특정 타임라인 단계에 사용 가능한 데이터
Cato 엔진 - 흐름을 분석하고 적절한 조치를 취할 수 있는 SPACE 엔진 (차단 또는 허용)
트래픽 흐름 데이터 - 각 단계에서 트래픽 흐름을 평가하는 데 사용되는 데이터

다음의 세부사항 목록을 Sample TCP Flow의 세부 사항에서 확인할 수 있습니다.

트래픽 흐름에서의 샘플 앱 식별

이것은 Slack 애플리케이션을 포함하는 규칙에 대한 트래픽 흐름의 예시이며, 각 단계에서 사용 가능한 정보를 보여줍니다.

첫 번째 패킷 - TCP
```
출처 - 10.10.2.107
출처 포트 - 55477
목적 IP - 3.68.124.168
목적 포트 - 443
프로토콜 - TCP
DNS 응답 - 3.68.124.168 - slack.com (선택적 응답)
```
이 샘플 첫 번째 패킷 기반의 트래픽 흐름 정보는 다음과 같습니다:
- 5-tuple - 트래픽이 Slack 애플리케이션과 연결되어 있는지 식별할 수 없습니다.
- DNS 응답 - 이전 흐름에 따르면, 엔진은 이미 이 목적지 IP에 대한 도메인 이름이 slack.com이라는 것을 알고 있습니다.
- ASN - 목적지 IP를 기반으로 보안 엔진이 ASN을 식별할 수 있습니다.
- 앱 식별에는 다음이 포함됩니다: tcp
엔진은 Slack 앱의 식별을 완료하기 전에 TLS 핸드셰이크로부터 추가 정보를 기다립니다.
tls_handshake
```
"TLS Header"
"sni_host": "slack.com"
"predefined inspection bypass reason": "none"
"ja3_formatted_str": "771,4865-4866-4867-49195-49199-49196-4920…"
```
이 샘플 tls_handshake 기반의 트래픽 흐름 정보는 다음과 같습니다:
- TLS 헤더 및 서버 포트 443 - TLS 프로토콜과 일치합니다.
- SNI는 slack.com - Cato Slack 앱 식별과 일치합니다.
  
  SNI는 또한 URLF에 전송되며, 비즈니스 정보, 컴퓨터 및 기술, 소셜 카테고리와 일치합니다.
- 클라이언트 클래스는 JA3 - TLS 지문을 기반으로 클라이언트를 브라우저로 분류합니다.
- TLS 검사 또는 우회 작업 - 클라이언트 클래스 및 앱 식별을 기반으로 합니다.
- 앱 식별에는 다음이 포함됩니다: tcp, tls, slack
HTTP
```
"url" : "upload.slack.com:
"host_name" : "slack.com"
"Content-Type" : "application/pdf"
"Content-Disposition" : form-data; name="file"; filename="sample-data.pdf"
"Content-Length" : "52765"
```
이 샘플 흐름의 HTTP 데이터 기반의 사용 가능한 정보는 다음과 같습니다:
- 앱 식별에는 다음이 포함됩니다: tcp, tls, http, slack
- TLS 검사는 흐름을 해독하고 Slack 서버 호스트 이름이 slack.com임을 식별합니다.
- HTTP 헤더 - HTTP 프로토콜과 일치합니다.
  
  이것은 일반적인 예제이며, HTTP_host가 SNI와 일치하며, 앱 식별에는 변화가 없습니다.
- URL - 업로드 접두사가 있어 더 세분화된 정보를 제공하고, 애플리케이션 제어 정책에서 업로드 작업과 일치할 수 있습니다.
- Content-Type, Content-Disposition, Content-Length - 파일의 이름, 크기 및 유형에 대한 정보를 제공합니다.
- 애플리케이션 제어 정책 동작:
  - 기업 Slack 테넌트만 사용하는 정책을 강제합니다.
  - 파일 유형을 기반으로 파일 제어
    
    안티멀웨어 및 NG 안티멀웨어는 다운로드 방향의 파일만 검사합니다.
HTTP 바디
```
"HTTP 본문 페이로드" : "파일 자체"
```
예를 들어, DLP 정책은 Slack 메시지에서 신용카드 데이터를 사용할 수 없도록 강제합니다.
- Slack 애플리케이션에 대한 앱 식별이 완료되었습니다. 소셜 카테고리에 속하는 트래픽으로 식별됩니다.
- 파일 내용이 준비되면, 이 엔진들은 파일 내용을 분석합니다.
  - DLP 엔진은 데이터 제어 정책을 기반으로 콘텐츠를 스캔합니다.
  - 안티멀웨어 및 NG 안티멀웨어는 다운로드 방향의 파일을 검사합니다.

Cato 정책 및 엔진

이 섹션은 트래픽 흐름을 분석하고 조치를 취하는 Cato 보안 정책 및 엔진을 설명합니다.

방화벽 및 네트워크 정책

WAN 방화벽, 인터넷 방화벽, 네트워크 규칙 정책은 종종 첫 번째 패킷에서 트래픽 흐름을 평가할 수 있습니다. 예를 들어, 5-tuple의 데이터를 기반으로 한 규칙입니다. 하지만, Azure나 Slack과 같은 특정 애플리케이션과 일치하는 규칙의 경우에는 엔진이 흐름을 평가하기 위해 트래픽 흐름에서 추가 데이터가 필요합니다. 이는 엔진이 흐름을 평가하는 단계가 특정 규칙에 대한 설정에 따라 다르다는 것을 의미합니다.

방화벽 규칙의 유형에 대한 더 많은 정보는 인터넷 및 WAN 방화벽 정책 – 모범 사례를 참조하십시오.

간단한 네트워크 규칙 및 복잡한 방화벽 규칙에 대한 첫 번째 패킷 예시

이 예제는 IP 주소와 포트를 사용하는 간단한 네트워크 규칙과 Azure 앱을 위한 복잡한 방화벽 규칙에 대해 PoP 엔진이 트래픽 흐름을 어떻게 다르게 평가하는지를 보여줍니다. 네트워크 엔진은 첫 번째 패킷을 기반으로 흐름을 평가할 수 있지만, PoP는 방화벽 엔진의 분석을 완료하기 위해 추가 데이터를 기다립니다.

샘플 네트워크 규칙

다음 네트워크 규칙은 IP 범위로서의 출처에 대한 트래픽이고, 포트 범위는 8000 - 8010까지이며, 트래픽은 런던 PoP 위치를 통해 나갑니다.

네트워킹 엔진은 5-tuple에 기반하여 트래픽 흐름에 대한 라우팅 결정을 평가할 수 있습니다.

샘플 WAN 방화벽 규칙

다음 WAN 방화벽 규칙은 위의 네트워크 규칙에 대한 IP 범위와 동일한 출처에 대해 트래픽을 허용하며, RnD 사용자 그룹의 구성원인 사용자에 대해 적용됩니다. 또한, 이 규칙은 HTTP(S), TLS, FTP 및 TFTP 서비스를 위한 Azure 애플리케이션에 대해 적용됩니다.

방화벽 엔진은 사용자 식별, Azure 애플리케이션 및 흐름에 대한 서비스를 확인해야 하기 때문에 첫 번째 패킷에서 트래픽을 평가할 수 없습니다. 엔진이 평가를 완료하고 흐름이 모든 기준을 충족하면 엔진은 흐름을 허용합니다. PoP도 첫 번째 패킷에 기반한 라우팅 결정을 적용합니다.

URL 필터링 및 Cato 카테고리

URL 필터링 서비스는 웹사이트의 URL을 분석하고, 알려진 또는 의심스러운 악성 혹은 부적절한 웹사이트에 대한 데이터베이스와 비교하여 작동합니다. 이 서비스는 또한 성인 콘텐츠, 도박, 소셜 네트워킹 또는 스트리밍 미디어와 같은 카테고리를 결정하기 위해 웹사이트 자체의 콘텐츠를 분석할 수도 있습니다.

카테고리에 대한 자세한 내용은 카테고리와 함께 작업을 참조하십시오.

TLS 검사

TLS 검사 엔진은 패킷 흐름의 tls_handshake 단계 동안 참여합니다. 흐름을 검사할 것인지 여부에 대한 결정은 돌이킬 수 없으며 두 단계로 이루어집니다:

1단계 - client_hello 패킷의 첫 번째 페이로드는 TLS 검사 엔진이 해당 트래픽 흐름을 검사할 것인지 초기 표시를 제공합니다.
2단계 - client_hello가 완전히 구문 분석되고 TLS 검사 정책 작업이 적용됩니다 (흐름을 검사 또는 우회).

HTTPS 흐름의 경우, 1단계에서 패킷을 차단하기로 결정할 수 있습니다. 그러나 엔진은 계속해서 통신하고 올바른 방화벽 또는 IPS 차단 페이지를 엔드 유저에게 표시하기 위해 TLS 연결을 설정합니다.

IPS

IPS 엔진은 트래픽 흐름의 수명 동안 계속 동작합니다. 특정 항목을 각기 다른 단계에서 검사하고 IPS(침입 방지 시스템) 보호와 긍정적으로 일치하는 콘텐츠를 처리합니다. IPS는 돋보기처럼 동작하여 트래픽의 업데이트를 지속적으로 기다리며 흐름에서 확인된 엔진에 정보를 지속적으로 제공합니다.

다음 예는 흐름의 다양한 단계에서 사용할 수 있는 다양한 정보를 보여줍니다.

흐름의 프로토콜은 HTTP입니다.
페이로드에 따라 TLS가 있습니다.
TLS 1.3 암호 스위트 TLS_AES_256_GCM_SHA384를 사용하는 client_hello가 있습니다.

다른 IPS 보호는 위의 항목과 일치할 수 있으며 해당 단계에서 트래픽 흐름에 대해 작업을 수행할 수 있습니다.

DNS 보호

DNS 보호는 IPS 엔진의 일부이며 DNS 요청 및 응답에 대해 실행되며, 예를 들어 TCP나 UDP와 같은 전송과는 전혀 연결되지 않습니다.

DNS 요청 중 도메인 이름은 도메인 평판 및 정적 피드에 대해 분석 및 평가됩니다. 그런 다음 DNS 응답 동안 해결된 IP와 콘텐츠는 잠재적으로 악성 콘텐츠에 대해 분석됩니다. DNS 보호 정책은 일치하는 모든 콘텐츠에 적용됩니다(트래픽 흐름 차단 또는 허용).

앱 제어

앱 제어 엔진은 트래픽을 검사하고 애플리케이션 제어 정책에 대한 작업을 적용하며, 각 새로운 HTTP 트랜잭션(요청 및 응답)에 대해 평가됩니다.

gen2 앱의 경우, TLS 및 HTTP 프록시가 앱 식별을 완료하는 데 필요합니다.

보안 및 규정 준수 요건을 포함하는 규칙의 경우:

다른 네트워킹 및 보안 엔진의 컨텍스트 데이터를 기반으로, 앱 제어 엔진은 tls_inspection 단계 중에 이러한 요구 사항을 평가할 수 있습니다.
엔진은 SNI에서 이 정보를 얻을 수도 있으며, 앱을 평가하기 위해 TLS나 전체 앱 식별(레이어 7 DPI)을 필요로 하지 않을 수 있습니다.

DLP

DLP 엔진은 트래픽 흐름의 콘텐츠를 검사하며, 앱 제어 엔진의 확장입니다. 정책이 파일 유형 또는 파일 크기를 지정하면 엔진은 이러한 파일 특성에 대해 앱 메타데이터와 페이로드를 검사해야 합니다.

엔진은 파일 유형을 평가하고 컨텐츠 검사를 위해 지원되는 파일 목록과 일치하는지 확인합니다.
그런 다음 gen3 앱 식별이 완료되어 콘텐츠와 데이터를 저장하는 필드에 대한 특정 콘텐츠 서명이 확인됩니다.
콘텐츠가 검사되고 정의된 콘텐츠 프로파일과 일치하는지 확인됩니다.

안티멀웨어 및 NG 안티멀웨어

안티멀웨어 및 SentinelOne NG 안티멀웨어 엔진은 들어오는 트래픽(파일 다운로드)의 파일 첨부파일을 알려진 및 미지의 맬웨어에 대해 스캔합니다. 파일 유형은 HTTP 응답 또는 FTP 트래픽 요청을 기반으로 합니다.

HTTP, HTTPS 및 FTP 애플리케이션 및 서비스만 스캔됩니다.

엔진은 애플리케이션이 안티멀웨어 정책의 규칙과 일치하는지 확인합니다.
파일은 다음 파일 목록과 비교됩니다.
1. Cato 관리 애플리케이션에 구성된 허용 목록 - 이러한 파일은 다운로드가 허용됩니다.
2. Cato 보안 팀에 의해 관리되는 차단 목록 - 이러한 파일은 차단됩니다.
파일은 안티멀웨어 및 NG 안티멀웨어 엔진에 의해 스캔되며, 평결이 반환됩니다: 악성, 의심스러운, 또는 양호한.
안티멀웨어 정책에 대한 적절한 조치가 파일에 적용됩니다.

Cato 정책 및 엔진에 대한 FAQ

URL 필터링이 WAN 트래픽에 적용됩니까?

아니오, URL 필터링은 인터넷 트래픽에만 해당되며 WAN을 통한 계정 트래픽에는 적용되지 않습니다.

방화벽 대 IPS 정책에 대한 지리적 제한 설정의 차이점은 무엇입니까?

디바이스 설정은 WAN 및 인터넷 방화벽에서는 세부 규칙에 대한 원산지를 정의할 수 있습니다. 하지만 목적지 국가에 대한 제어는 없습니다.

지리적 제한 탭은 IPS 정책에서 원산지나 목적지에 대한 제한된 트래픽을 정의합니다. 하지만, IPS는 전체 계정에 대한 글로벌 정책이므로 특정 사이트나 객체에 대한 지리적 제한 설정을 적용할 수 없습니다.

샘플 TCP 흐름의 세부사항

타임라인 - 첫 번째 패킷
1. 사용 가능한 필드 - 5-튜플, 호스트 이름(도메인 이름)
2. 카토 엔진 - 방화벽, 네트워크, IPS/SAM
3. 트래픽 흐름 데이터 - 앱 식별, 클라이언트 클래스, OS
타임라인 - tls_핸드셰이크
1. 사용 가능한 필드 - 암호 스위트, 호스트 이름(SNI)
2. 카토 엔진 - IPS/SAM, 앱 제어 gen2, TLSi, 방화벽, 네트워크
3. 트래픽 흐름 데이터 - 앱 식별, 클라이언트 클래스, URLF
타임라인 - HTTP_헤더
1. 사용 가능한 필드 - 헤더, URL, 호스트 이름(호스트 헤더)
2. 카토 엔진 - 앱 제어 gen3, IPS/SAM
3. 트래픽 흐름 데이터 - 파일 유형(업로드), OS
타임라인 - HTTP_본문
1. 사용 가능한 필드 - HTTP_요청, HTTP_본문
2. 카토 엔진 - 앱 제어 gen3, DLP, IPS/SAM
3. 트래픽 흐름 데이터 - 파일 유형(업로드), 앱 식별
타임라인 - HTTP_응답
1. 사용 가능한 필드 - HTTP_응답_헤더, HTTP_응답_본문
2. 카토 엔진 - AM/NGAM, 앱 제어 gen3, DLP, IPS/SAM
3. 트래픽 흐름 데이터 - 파일 유형(다운로드), 앱 식별