Panther 시스템 아키텍처

Panther 시스템 아키텍처의 다이어그램 및 설명

Panther 시스템 개요

위 다이어그램은 대략 왼쪽에서 오른쪽으로 흐르며, 다음 단계로 읽을 수 있습니다:

1. 원시 로그 데이터는 SaaS 풀러(예: Okta) 및 데이터 전송 소스(예: AWS S3)를 포함한 다양한 로그 소스에서 Panther로 유입됩니다. 이러한 원시 로그는 로그 처리 서브시스템에서 파싱, 필터링 및 정규화됩니다.

   • 의 출력은 두 개의 서브시스템으로 흐릅니다: 로그 처리 데이터 레이크 데이터 레이크 와 함수를 포함해야 함을 의미합니다;.

2. 활성화된 경우, 클라우드 보안 스캐닝 는 온보드된 클라우드 인프라를 스캔한 후 찾아낸 리소스를 함수를 포함해야 함을 의미합니다; 서브시스템에서 파싱, 필터링 및 정규화됩니다.

3. 사용자를 사용할 것이며, 인리치먼트 서브시스템으로 전달합니다. 함수를 포함해야 함을 의미합니다; 서브시스템은 선택적으로 IPinfo, Okta 프로필).

4. 사용자를 사용할 것이며, 함수를 포함해야 함을 의미합니다; 서브시스템은 다음 입력에 대해 디텍션을 적용합니다:

   • 다음으로부터 로그 처리: 로그 이벤트

   • 다음으로부터 스케줄된 검색: 로그 이벤트

   • 다음으로부터 클라우드 보안 스캐닝: 인프라스트럭처 리소스

5. 사용자를 사용할 것이며, AI 서브시스템은 알러트 분류(triage)에 사용되며, 알러트가 생성될 때 자동으로 트리거되도록 구성할 수 있습니다. AI 서비스는 API 및 여러 콘솔 UI 진입점.

6. 디텍션이 알러트를 생성하면 해당 알러트는 알러팅 서브시스템으로 전송되어 적절한 알러트 대상으로 배포됩니다 대상지 (예: Slack, Jira, 웹후크 등). 단일 알러트는 둘 이상의 대상으로 라우팅될 수 있습니다.

다이어그램 하단의 컨트롤 플레인은 위의 서브시스템들(데이터 플레인)을 구성하고 제어하는 횡단 인프라를 나타냅니다. 이는 아래 각 서브시스템 설명에서 확장됩니다. 오른쪽 상단에 참조된 API 서버 는 컨트롤 플레인으로 들어가는 외부 진입점입니다.

일반 고려 사항

AWS

• 각 Panther 고객은 전용 AWS 계정에 배포된 Panther 인스턴스를 가집니다.

  • 고객은 AWS 계정을 직접 소유하거나 Panther가 계정을 관리하도록 선택할 수 있습니다.

  • 고객 간에 데이터가 공유되거나 접근 가능한 경우는 없습니다.

  • AWS 계정은 애플리케이션의 권한 경계를 형성합니다.

  • 네트워킹이 필요한 서비스에는 단일 VPC가 사용됩니다.

• 처리는 AWS Lambda 및 Fargate 인스턴스를 통해 수행됩니다.

  • 독점적인 컨트롤 플레인이 비용을 최소화하기 위해 최적의 컴퓨트를 동적으로 선택합니다(아래 참조).

  • 컴퓨트 리소스는 서로 직접 통신하지 않으며, 대신 AWS 서비스를 통해 통신합니다. 다시 말해, "동서(east/west)" 네트워크 트래픽은 없고 "남북(north/south)" 네트워크 트래픽만 있습니다.

• 사용자를 사용할 것이며, 최소 권한 원칙 각 인프라 구성 요소에 대해 최소 범위의 IAM 롤을 사용하여 준수됩니다.

데이터레이크

각 Panther 고객은 다음 중 하나를 보유합니다: Snowflake 이전에 생성한 Snowflake 사용자 이름, 예를 들면 Databricks 인스턴스.

Snowflake

• 전용 Snowflake 계정에 배포된 Panther Snowflake 인스턴스.

  • 고객은 Snowflake 계정을 직접 소유하거나 Panther가 계정을 관리하도록 선택할 수 있습니다.

  • 고객 간에 데이터가 공유되거나 접근 가능한 경우는 없습니다.

• Snowflake 비밀은 RSA 키를 사용하여 AWS Secrets Manager에서 관리되며 매일 교체됩니다.

Databricks

• 고객은 자체 Databricks 인스턴스를 보유해야 합니다.

  • 고객 간에 데이터가 공유되거나 접근 가능한 경우는 없습니다.

기타

• 모든 데이터는 전송 중 및 저장 시 암호화됩니다.

• 모든 외부 상호작용은 API:

  • 를 사용하여 수행됩니다.

  • Panther 콘솔은 API 서버와 인터페이스하는 React 애플리케이션입니다. GraphQL 와 REST 공개 API는

  • 엔드포인트를 노출합니다. 모든 API 액션은Panther 감사 로그

• 로 로깅되며, 이는 Panther에서 로그 소스로 수집될 수 있습니다. 외부 통합과 관련된 비밀은 Amazon DynamoDB

• 에서 KMS로 암호화된 필드를 사용하여 관리됩니다.

• 시스템은 부하에 따라 확장 및 축소됩니다. Panther 인프라는.

  • Pulumi

  • 로 관리됩니다. 모든 인프라는 태그(예: 리소스 이름, 서브시스템)가 지정되어 효과적인 비용 분석을 가능하게 합니다. 자신의 AWS 계정을 소유한 고객은

• 자체 태그를 추가할 수 있어 더 큰 조직의 비용 보고서에 통합할 수 있습니다., 모니터링은 다음의 조합으로 수행됩니다:및 CloudWatch.

Sentry

사용자를 사용할 것이며, Panther API Datadog GraphQL및 REST API 서브시스템

은 Panther와의 모든 외부 상호작용에 대한 진입점입니다. 콘솔과 클라이언트는 AWS ALB를 통해 연결합니다. 고객은 선택적으로 IP CIDR을 사용하여 ALB 접근에 대한 허용 목록을 구성할 수 있습니다.API 인증은 AWS Cognito를 사용하여 수행됩니다. GraphQL 및 REST 클라이언트는 토큰 을 사용하고, Panther 콘솔은 JWT 를 사용하며 이는 AWS Cognito가 관리합니다. 콘솔은 AWS Cognito를 통한

싱글 사인온(SSO)

을 지원합니다.

요청을 해결하는 내부 API 서버가 있습니다. 일부 요청은 API 서버 내부에서 전적으로 처리되며, 다른 요청은 AWS Lambda 함수로 구현된 하나 이상의 내부 서비스 호출이 필요합니다. HTTP 소스, 로그 처리 서브시스템이 서브시스템으로 입력되는 모든 데이터는 AWS S3 및 S3 알림을 통해 전달됩니다. S3 기반이 아닌 상류 소스(예: SaaS 풀러, Google Cloud Storage 소스 )는 Amazon Data Firehose 를 사용하여 이벤트를 S3 객체로 집계합니다. 이러한 알림은 마스터

Amazon SNS

주제로 라우팅됩니다. 로그 처리 및 이벤트 샘플링 워크플로우 각각은 이 SNS 주제를 구독합니다.

로그 처리 연산은 AWS Lambda 및 Fargate로 구현됩니다.

동적 컴퓨트 비용 최적화

Panther는 컴퓨트 선택, 집계 및 스케일링을 오케스트레이션하는 효율적인 독점 컨트롤 플레인을 사용합니다.

트래픽이 증가하면 추가 컴퓨트가 필요합니다. Panther의 컨트롤 플레인은 트래픽에 맞춰 확장하여 데이터 집계를 극대화하고 비용을 최소화하도록 컴퓨트 인스턴스 수를 최소화합니다.

1. Lambda는 저지연으로 트래픽 변동을 빠르게 따를 수 있어 버스트 및 가벼운 트래픽 부하에 비용 효율적이므로 Panther의 핵심 컴퓨트로 사용됩니다. 그러나 Lambda의 시간당 단가가 다른 컴퓨트 옵션보다 높습니다. 지속적이고 예측 가능한 트래픽의 경우 Lambda는 다른 옵션만큼 비용 효율적이지 않습니다. 따라서 컨트롤 플레인이 안정적인 대량 트래픽을 감지하면 비용을 최소화하기 위해 Lambda 대신 Fargate(가능한 경우 Fargate Spot)를 사용합니다.

2. 수신된 각 알림에 대해 다음 단계가 수행됩니다:

3. S3 객체와 연관된 통합 소스가 DynamoDB에서 조회되고, 읽기를 위해 관련 역할이 가정됩니다. 업로더는 기존 스키마가 있는지 확인한 다음 일치하는 스키마 이름이 없으면 새 스키마를 생성하거나 업데이트를 진행합니다. 데이터가 S3에서 읽혀집니다.

   • 각 이벤트는 해당 데이터 유형에 연관된 시스템 오류 에 따라 파싱됩니다. 분류 또는 파싱 오류가 발생하면 을(를) 사용하여 쿼리할 수 있습니다.

4. 가 생성되고 관련된 "불량" 데이터는 와 분류_실패 내의 데이터 레이크에 저장됩니다.

5. 수집 필터 (p_any 변환 이 적용됩니다. 지표 필드

6. 필드)가 추출되고, 데이터 레이크 와 함수를 포함해야 함을 의미합니다; 표준 필드

가 삽입됩니다. 처리된 이벤트는 S3 객체로 기록되고 내부 SNS 주제로 알림이 전송되며, 해당 주제를 서브시스템들이 구독합니다.

각 온보드된 로그 소스에 대해 트래픽이 예기치 않게 중단될 경우를 알리기 위해 선택적으로 이벤트 임계치 알람을 구성할 수 있습니다.

S3 알림은 또한 이벤트 샘플링 서브시스템으로 라우팅되며, 이는

인리치먼트 로그 스키마 필드 발견 함수를 포함해야 함을 의미합니다; 에 사용됩니다. 데이터에서 새로운 속성이 발견되면 분석되어 스키마(및 연관된 데이터 레이크 테이블)에 자동으로 추가됩니다.

IPinfo보강(Enrichment) 서브시스템 은 Panther에서 Lookup Table(LUT)을 통해 구현됩니다. LUT는 고유한 기본 키와 연결된 데이터를 포함하는 테이블입니다. LUT는 또한 스키마에서 기본 키로의 매핑을 가지며, 이는 서브시스템에서 자동 보강을 가능하게 합니다. 디텍션은 또한 데이터 조회를 위해 함수 호출 인터페이스를 사용할 수 있습니다.

예를 들어,

은 지리 위치 데이터를 포함하는 Panther가 관리하는 보강 공급자입니다. 로그 이벤트의 IP 주소는 위치, ASN 및 프라이버시 정보로 자동 보강됩니다. 고객은 또한 자체 비즈니스 및 보안 관련 컨텍스트를 제공하기 위해 함수를 포함해야 함을 의미합니다; 사용자 지정 LUT 데이터 레이크을 생성할 수 있습니다. 스케줄된 검색 LUT는 Panther 콘솔 또는 YAML 명세 파일을 사용하는 CLI 워크플로우를 통해 생성됩니다. LUT 데이터는 콘솔에 업로드하거나 CLI 구성의 파일로 포함하거나 S3 객체로 저장하는 등 몇 가지 방법으로 Panther가 접근 가능하도록 할 수 있습니다. 일반적으로 LUT 데이터를 관리하는 가장 유용한 방법은 S3 객체 참조로 관리하는 것입니다—고객은 자신의 계정에 S3 객체를 생성할 수 있으며 Panther는 변경 사항을 폴링합니다.

LUT와 연관된 메타데이터는 DynamoDB에 저장됩니다. 새로운 데이터가 있을 때, Lookup Table Processor는 메타데이터에서 지정된 역할을 가정하고 S3 데이터를 처리합니다. 이로써 두 개의 출력이 생성됩니다:

서브시스템에서 사용되는 EFS의 실시간 데이터베이스와 로그 처리 와 스케줄된 검색데이터 레이크의 테이블들. 클라우드 보안 스캐닝데이터 레이크의 테이블은 조인을 사용하여 이벤트를 보강하기 위해

에서 사용될 수 있습니다.

• 디텍션 서브시스템 스트리밍 디텍션 프로세서는 LogTypes)

• 의 로그 이벤트와 의 리소스에서 실행되는 Python 기반 디텍션을 허용합니다. 스트리밍 디텍션 프로세서는 고속 Python 실행에 최적화된 AWS Lambda 함수(또는 Fargate 인스턴스)로 실행됩니다. (다만 프로세서는 단순한 Python Lambda가 아닙니다—초기 Panther 인프라에서는 그랬습니다. 다년간의 경험을 통해 단순한 Python Lambda 구현은 효율적이지도 비용 효과적이지도 않다는 것을 배웠습니다.) 스케줄된 검색

• 스트리밍 디텍션 프로세서는 다음 유형의 디텍션을 평가합니다:스트리밍 디텍션

(룰): 하나 이상의 로그 스키마(또는

1. 라고도 함)를 대상으로 합니다. p_enrichment 스케줄된 디텍션

2. (스케줄된 룰): 하나 이상의 출력을 대상으로 합니다.정책 디텍션

3. : 리소스를 대상으로 합니다. 최소한 각 룰과 예약된 룰은 룰 논리를 정의해야 합니다. 다음 소스에서 데이터를 처리하는 단계는 다음과 같습니다: 비율이활성화된 모든 Lookup Table에 대해 일치 항목이 알러팅 필드에 적용되어 해당 정보가 디텍션에 사용 가능하도록 합니다. 주어진.

4. LogType

   • 사용자를 사용할 것이며, 데이터 레이크 , 클라우드 리소스 또는 스케줄된 검색과 연관된 모든 디텍션이 발견됩니다. 시그널 각 디텍션의

함수가 이벤트/리소스에서 실행됩니다. 해당 함수가 를 반환하면 다른 선택적 함수들이 실행되고 알러트가 서브시스템으로 전송됩니다. 룰 및 스케줄된 룰의 경우, 디텍션의

중복 제거 창 내에서 최초 디텍션에 대해서만 알러트가 전송됩니다.

디텍션과 연관된 이벤트는 S3 객체로 기록되고 내부 SNS 주제로 S3 알림이 전송됩니다.

서브시스템은 규칙 일치 및 Snowflake 이전에 생성한 Snowflake 사용자 이름, 예를 들면 Databricks 테이블로의 데이터 수집을 위해 SNS 주제를 구독합니다.

Snowflake

Panther는 스케줄된 검색 이 실행을 마치면 스트리밍 디텍션 프로세서 Lambda는 쿼리 결과에 대한 참조와 함께 호출됩니다. 결과가 읽히고 각 이벤트는 위 단계에 따라 처리됩니다. 데이터 재생 은 과거 데이터에 대해 디텍션을 테스트할 수 있게 해줍니다. 이는 라이브 인프라와 독립적인 "미러" 인프라 세트를 통해 구현됩니다.

데이터 레이크 서브시스템 p_event_time Panther 고객은 보안 데이터레이크로 다음 중 하나를 사용할 수 있습니다:

를 데이터를 Snowflake로 수집하기 위해 Snowflake Snowpipe 서비스를 사용합니다.. 이 서비스는 AWS IAM 권한을 사용하므로 쿼리 및 관리를 위해 구성된 Snowflake 사용자에 의존하지 않습니다. Panther에서 새 데이터 소스를 온보딩하면 Admin 데이터베이스 API Lambda를 사용하여 연관된 테이블과 Snowpipe 인프라 생성이 트리거됩니다. 이 Lambda에는.

Databricks

권한(읽기/쓰기)이 있는 연관 사용자가 있습니다. 이 Lambda를 호출하기 위한 직접적인 외부 연결은 없으며, 대신 이 Lambda는 내부 컨트롤 플레인에 의해 구동됩니다. 테이블은

데이터 레이크 서브시스템 를 클러스터 키로 사용합니다. Snowflake 비밀은 p_event_time 열에서 확인할 수 있습니다.

AWS Secrets Manager 에 저장됩니다. 데이터를 Snowflake로 수집하기 위해 Snowflake Snowpipe 서비스를 사용합니다. RSA 비밀이 사용되며 매일 교체됩니다.

Panther에는 로더 프로세스가 있어 S3에 로드할 파일에 대한 S3 알림을 위한 내부 SNS 주제를 수신 대기합니다. 로더 프로세스는 모든 테이블을 관리하고 S3 파일을

COPY INTO 명령을 사용하여 일괄 로드합니다. 리퀴드 클러스터링 명령을 사용하여 일괄 로드합니다. 권한.

은 에서 사용됩니다.Databricks OAuth 에서 사용됩니다. 자격 증명은 고객의 Databricks AWS 계정에

에 저장됩니다. 쿼리 쿼리는

스케줄된 검색 읽기 전용 함수를 포함해야 함을 의미합니다; 데이터베이스 API Lambda를 사용하여 실행됩니다. 이 Lambda에는 연관된 사용자가 있습니다.

다음 필드를 포함해야 합니다 쿼리는 비동기식입니다. 쿼리 실행을 위해 API 요청이 이루어지면 연관된 SQL이 데이터레이크에서 실행되고 queryId

를 반환합니다. 그런 다음 해당

사용자를 사용할 것이며, 함수를 포함해야 함을 의미합니다; 를 사용하여 상태를 확인하고 연관된 결과를 읽기 위한 API 호출이 이루어집니다. 쿼리 실행 상태는 DynamoDB에서 추적됩니다. 쿼리 결과는 30일 동안 EFS에 저장됩니다(이 기간은 구성 가능). 고객은 Panther에서 검색 기록

을 사용하여 과거 검색 결과를 볼 수 있습니다.

사용자를 사용할 것이며, 에서 사용되는 는 AWS Step Function을 통해 실행됩니다. 쿼리 실행 완료 시 스트리밍 디텍션 프로세서는 추가 처리를 위해 쿼리 결과에 대한 참조와 함께 호출됩니다. 시스템 오류 로그타입별 RBAC

(현재 Snowflake에서만 지원)은 활성화되면 역할별로 고유한 관리형 읽기 전용 사용자가 존재합니다. (알러트 상태가).

알러팅 서브시스템

사용자를 사용할 것이며, : 샘플 로그 집합 업로드: 시스템에서 파일을 팝업 모달로 드래그하거나 클릭하세요 서브시스템은 알러트를 DynamoDB 테이블에 삽입하며 알러트 디스패치 Lambda는 스트림을 통해 이를 청취합니다. 이 Lambda는 알러트를 대상에 전송하기 위해

• 구성된 통합

  • 을 사용합니다.

  • Panther 콘솔에 알러트를 표시하기 위해 핵심 알러트 데이터는 DynamoDB에서 검색되고, 알러트와 연관된 이벤트는 데이터 레이크에서 검색됩니다.

  • 알러트 제한기 기능 Amazon Bedrock AWS 콘솔에서 API Gateway 서비스로 이동하세요.

  • 은 (아마도) 잘못 구성된 디텍션으로 인해 대상이 과부하되는 "알러트 폭주"를 방지하도록 설계되었습니다. 동일한 디텍션에서 한 시간에 1000개를 초과하는 알러트가 생성되면 알러트는 억제됩니다. (이 제한은 구성 가능합니다.) 제한이 충족되면 디텍션은 계속 실행되어 데이터 레이크에 이벤트를 저장하므로(데이터 손실 없음) 알러트만 생성되지 않습니다. 이 경우 고객에게 알리기 위해 도구 이 생성되며, 고객은 콘솔에서 수동으로 알러트 억제를 해제할 수 있습니다(예: 디텍션 조정 후).

  • Jira 및 Slack에는 알러트 상태를 동기화하기 위해 Panther에 "콜백"할 수 있는 특수 인증된 엔드포인트가 있어 알러트 상태를 외부 통합과 관련된 비밀은

• Amazon Bedrock로 업데이트하는 등의 작업을 수행할 수 있습니다.

• 외부 통합과 관련된 비밀은AI 서브시스템

  • 서브시스템은 아키텍처상 복잡하지 않습니다. 구성 요소는 다음과 같습니다: AI 응답의 "저장 해제"는 저장된 응답 목록에서 이를 제거하는 것을 의미합니다. 저장 해제된 응답은(다시

서버: 요청을 수신하고 응답 및 영속성을 오케스트레이션합니다

: 샘플 로그 집합 업로드: 시스템에서 파일을 팝업 모달로 드래그하거나 클릭하세요 진입점 및 컨텍스트에 따라 시스템 프롬프트를 동적으로 생성합니다 도구할당량과 권한을 시행합니다 알러트 분류 다음과 인터페이스합니다:

자주 묻는 질문: Panther AI 아키텍처 및 보안

오케스트레이션을 수행합니다

사용(이는 내부 Panther API 호출로 구성됩니다) AI 응답을.

에 영속화하는 것을 관리합니다:

Panther AI는 서버는 모든 AI 추론을 위해 Bedrock과 통신합니다 : AI 응답의 영속성에 사용됩니다

응답은 명시적으로

되지 않는 한 30일 후 삭제됩니다. 외부 통합과 관련된 비밀은Panther AI 워크플로우 AI 응답의 "저장 해제"는 저장된 응답 목록에서 이를 제거하는 것을 의미합니다. 저장 해제된 응답은(다시.

는 인간 Panther 사용자가 이용할 수 있는 많은 서비스를 로그 유형 액세스 제한로 노출합니다. Panther AI는 필요에 따라(즉, 컨텍스트와 작업에 따라) 도구를 사용하므로 워크플로우는 종종 가변적입니다. 아래에는 전형적인

• 워크플로우가 설명되어 있습니다.

• Panther는 고객 데이터를 AI 학습에 사용합니까?

아니요. Panther는 고객 데이터를 AI 학습에 사용하지 않습니다. Panther AI는 오직

Amazon Bedrock 기반 모델

• 를 사용하여 AI 추론만 수행합니다.

• Panther AI는 어떤 기반 모델을 사용합니까?

Anthropic Claude Cloud Connected 모델을 사용합니다. AI 응답은 어떻게 저장되고 보호됩니까?.

AI 응답은 Panther 고객 계정의 에 저장됩니다. 응답은 명시적으로 되지 않는 한 30일 후 삭제됩니다.

Panther AI는 현재 사용자의 역할에 대해 설정된 경우

을 시행합니다. 이는 다음을 의미합니다: 알러트에 대한 응답은 알러트에 대한 사용자의 권한에 기반해 접근이 제한됩니다.검색 결과에 대한 응답은 데이터 레이크에 대한 사용자의 권한에 기반해 접근이 제한됩니다.

Panther AI에 가드레일이 있습니까?

Panther AI는 다음과 같은 비용 안전 제어 할당량을 가지고 있습니다(요청 시 변경될 수 있음): Cloud Connected 고객 SaaS 시간당 추론(기본값은 100) 도구 시간당 실행되는 데이터 레이크 쿼리(기본값은 100)

추가로,

고객은 다음을 구현할 수 있습니다: Amazon Bedrock 가드레일즈(Guard Rails).