Panther 시스템 아키텍처
Panther 시스템 아키텍처의 다이어그램 및 설명
Panther 시스템 개요
위 다이어그램은 대략 왼쪽에서 오른쪽으로 흐르며 다음 단계로 읽을 수 있습니다:
활성화된 경우, 클라우드 보안 스캔 은 온보딩된 클라우드 인프라를 스캔한 후 발견한 리소스를 탐지 하위 시스템에서 파싱, 필터링 및 정규화됩니다.
로 전달합니다. 탐지 하위 시스템은 다음 입력에 탐지를 적용합니다:
에서 로그 처리: 로그 이벤트
에서 예약 검색: 로그 이벤트
에서 클라우드 보안 스캔: 인프라 리소스
탐지가 경고를 생성하면 해당 경고는 경고 발송 하위 시스템으로 전송되어 적절한 경고 대상지로 발송됩니다 (예: Slack, Jira, 웹후크 등). 단일 경고는 여러 대상지로 라우팅될 수 있습니다.
다이어그램 하단의 제어 평면(Control Plane)은 위의 하위 시스템(데이터 플레인)을 구성하고 제어하는 횡단 인프라를 나타냅니다. 이는 아래의 각 하위 시스템 설명에서 확장됩니다. 오른쪽 상단에 참조된 API 서버 는 제어 평면으로의 외부 진입점입니다.
일반 고려 사항
AWS
각 Panther 고객은 전용 AWS 계정에 Panther 인스턴스를 배포합니다.
고객은 AWS 계정을 직접 소유하거나 Panther가 계정을 관리하도록 선택할 수 있습니다.
고객 간에 데이터가 공유되거나 접근 가능한 형태는 없습니다.
AWS 계정은 애플리케이션의 권한 경계를 형성합니다.
네트워킹을 필요로 하는 서비스에는 단일 VPC가 사용됩니다.
처리는 AWS Lambda와 Fargate 인스턴스를 통해 수행됩니다.
독점적인 제어 평면이 비용을 최소화하기 위해 최적의 컴퓨트를 동적으로 선택합니다(아래 참조).
컴퓨트 리소스는 서로 직접 통신하지 않으며, 대신 AWS 서비스를 통해 통신합니다. 다시 말해 "동서(east/west)" 네트워크 트래픽은 없고 "남북(north/south)" 트래픽만 존재합니다.
로 전달합니다. 최소 권한 원칙 은 각 인프라 구성요소에 대해 최소 범위의 IAM 역할을 사용하여 준수됩니다.
데이터레이크
각 Panther 고객은 다음 중 하나를 보유합니다: Snowflake 또는 Databricks 인스턴스.
Snowflake
Panther Snowflake 인스턴스는 전용 Snowflake 계정에 배포됩니다.
고객은 Snowflake 계정을 직접 소유하거나 Panther가 계정을 관리하도록 선택할 수 있습니다.
고객 간에 데이터가 공유되거나 접근 가능한 형태는 없습니다.
Snowflake 비밀은 RSA 키를 사용하여 AWS Secrets Manager에서 관리되며 매일 교체됩니다.
Databricks
고객은 자체 Databricks 인스턴스를 보유해야 합니다.
고객 간에 데이터가 공유되거나 접근 가능한 형태는 없습니다.
기타
모든 데이터는 전송 중 및 저장 시 암호화됩니다.
모든 외부 상호작용은 API:
를 사용하여 수행됩니다. Panther 콘솔은 API 서버와 인터페이스하는 React 애플리케이션입니다.
엔드포인트를 노출합니다. 모든 API 작업은Panther 감사 로그
로 기록되며, 이는 Panther에서 로그 소스로 수집될 수 있습니다. 외부 통합과 관련된 비밀은 Amazon DynamoDB
의 KMS 암호화 필드를 사용하여 관리됩니다.
시스템은 로드에 따라 확장 및 축소됩니다. Panther 인프라는.
Pulumi
로 관리됩니다. 모든 인프라는(예: 리소스 이름, 하위 시스템) 태그가 지정되어 효과적인 청구 분석을 가능하게 합니다. AWS 계정을 소유한 고객은
자체 태그를 추가 하여 조직의 청구 보고에 통합할 수 있습니다., 모니터링은 다음의 조합을 사용하여 수행됩니다:CloudWatch Sentry.
, 및
로 전달합니다. Datadog API 하위 시스템 GraphQLCloudWatch 및 Panther API
는 Panther와의 모든 외부 상호작용에 대한 진입점입니다. 콘솔, 클라이언트는 AWS ALB를 통해 연결합니다. 고객은 선택적으로 IP CIDR을 사용하여 ALB 접근을 위한 허용 목록을 구성할 수 있습니다.API 인증은 AWS Cognito를 사용하여 수행됩니다. GraphQL 및 REST 클라이언트는 토큰 을 사용하고, Panther 콘솔은 JWT 를 사용하여 AWS Cognito에서 관리됩니다. 콘솔은
싱글 사인온(SSO)
을 AWS Cognito를 통해 지원합니다.
내부 API 서버가 요청을 해결합니다. 일부 요청은 API 서버 내에서 완전히 처리되며, 다른 요청은 AWS Lambda 함수로 구현된 하나 이상의 내부 서비스에 대한 호출을 필요로 합니다. 로그 처리 하위 시스템, 이 하위 시스템으로 입력되는 모든 데이터는 AWS S3 및 S3 알림을 통해 전달됩니다. S3 기반이 아닌 상류 소스(예: SaaS 풀러,HTTP 소스 Google Cloud Storage 소스 )는 이벤트를 S3 객체로 집계하기 위해 Amazon Data Firehose 를 사용합니다. 이러한 알림은 마스터
Amazon SNS
트래픽이 증가하면 추가 컴퓨트가 필요합니다. Panther의 제어 평면은 트래픽에 맞춰 확장하여 데이터 집계를 극대화하고 비용을 최소화하기 위해 사용하는 컴퓨트 인스턴스 수를 최소화합니다.
Lambda는 지연 시간이 낮아 트래픽 변동을 빠르게 따를 수 있기 때문에 Panther의 핵심 컴퓨트로 사용됩니다. 이는 버스트성 및 가벼운 트래픽 부하에 비용 효율적입니다. 그러나 Lambda의 단위 시간당 비용은 다른 컴퓨트 옵션보다 높습니다. 지속적이고 예측 가능한 트래픽의 경우 Lambda는 다른 컴퓨트 옵션만큼 비용 효율적이지 않습니다. 따라서 제어 평면이 안정적이고 높은 볼륨의 트래픽을 감지하면 비용을 최소화하기 위해 Lambda 대신 Fargate(Fargate Spot이 가능한 경우)를 사용합니다.
수신된 각 알림에 대해 다음 단계가 수행됩니다:
S3 객체와 연결된 통합 소스가 DynamoDB에서 조회되고 읽기를 위해 관련 역할을 맡습니다. 데이터가 S3에서 읽혀집니다. 각 이벤트는 해당 데이터 유형에 대한 관련
스키마 에 따라 파싱됩니다. 분류 또는 파싱 오류가 발생하면,
시스템 오류가 생성되고 관련된 "잘못된" 데이터는
처리된 이벤트는 S3 객체로 기록되고 알림이 내부 SNS 주제로 전송되며, 해당 주제를 구독하는 하위 시스템 이 있습니다.
S3 알림은 이벤트 샘플링 하위 시스템으로도 라우팅되며, 이는
확장 로그 스키마 필드 발견 탐지 에 사용됩니다. 데이터에서 새로운 속성이 발견되면 자동으로 분석되어 스키마(및 관련 데이터 레이크 테이블)에 추가됩니다.
IPinfo확장 하위 시스템 Panther의 확장은 조회 테이블(LUT)을 통해 구현됩니다. LUT는 고유한 기본 키와 연결된 데이터를 포함하는 테이블입니다. LUT는 또한 스키마에서 기본 키로의 매핑을 가지며, 이를 통해 하위 시스템에서 자동 확장이 가능합니다. 탐지는 또한 함수 호출 인터페이스를 사용하여 데이터를 조회할 수 있습니다.
예를 들어,
는 지리 위치 데이터를 포함하는 Panther 관리 확장 제공자입니다. 로그 이벤트의 IP 주소는 자동으로 위치, ASN 및 개인정보 관련 정보로 확장됩니다. 고객은 또한 비즈니스 및 보안 관련 컨텍스트를 제공하기 위해 자체 탐지 맞춤 LUT 데이터 레이크을 생성할 수 있습니다. 예약 검색 LUT는 Panther 콘솔을 통해 또는 CLI 워크플로우( YAML 사양 파일 사용)에서 생성됩니다. LUT 데이터는 콘솔에 업로드하거나 CLI 구성 파일에 파일로 포함하거나 S3 객체로 저장하는 등 몇 가지 방법으로 Panther가 접근할 수 있도록 할 수 있습니다. 일반적으로 LUT 데이터를 관리하는 가장 유용한 방법은 S3 객체 참조로 관리하는 것입니다—고객은 자체 계정에 S3 객체를 생성할 수 있으며 Panther는 변경 사항을 폴링합니다.
LUT와 연관된 메타데이터는 DynamoDB에 저장됩니다. 새 데이터가 있을 때 Lookup Table Processor는 메타데이터에 지정된 역할을 맡아 S3 데이터를 처리합니다. 이는 두 가지 출력을 생성합니다:
하위 시스템에서 사용하는 EFS의 실시간 데이터베이스와, 로그 처리 및 예약 검색데이터 레이크의 테이블. 클라우드 보안 스캔데이터 레이크의 테이블은
가 조인을 사용하여 이벤트를 확장하는 데 사용할 수 있습니다.
로그타입
)를 대상으로 합니다.
예약 탐지(예약 규칙): 하나 이상의출력을 대상으로 합니다.
정책 탐지: 리소스를 대상으로 합니다.이들 소스에서 데이터를 처리하는 단계는 다음과 같습니다:
활성화된 모든 Lookup Table에 대해 일치 항목이p_enrichment필드에 적용되어 해당 정보가 탐지에서 사용 가능하도록 합니다.주어진 경고 발송 LogType , 클라우드 리소스 또는 예약 검색과 연관된 모든 탐지가 찾아집니다..각 탐지의
로 전달합니다. 데이터 레이크 rule() 함수가 이벤트/리소스에서 실행됩니다. 함수가 True
를 반환하면 다른 선택적 함수들이 실행되고 경고가 하위 시스템으로 전송됩니다. 규칙 및 예약 규칙의 경우, 탐지의 중복 제거 창
내에서 첫 번째 탐지에 대해서만 경고가 전송됩니다. 탐지와 연관된 이벤트는 S3 객체로 기록되고 내부 SNS 주제로 S3 알림이 전송됩니다.
하위 시스템은 규칙 매치 및
신호 Snowflake 또는 Databricks 테이블로의 데이터 수집을 위해 SNS 주제를 구독합니다.
Snowflake
예약 검색 이 실행을 완료하면 스트리밍 탐지 프로세서 Lambda가 쿼리 결과에 대한 참조와 함께 호출됩니다. 결과가 읽혀지고 각 이벤트가 위의 단계에 따라 처리됩니다. 데이터 재생 은 과거 데이터에서 탐지를 테스트할 수 있게 합니다. 이는 라이브 인프라와 독립적인 "미러" 인프라 세트를 통해 구현됩니다. 데이터 레이크 하위 시스템
Panther 고객은 보안 데이터 레이크로 중 하나를 사용할 수 있습니다. Panther는 데이터를 Snowflake로 수집하기 위해
Snowflake Snowpipe 서비스 를 사용합니다. 이 서비스는 AWS IAM 권한을 사용하므로 쿼리 및 관리를 위해 구성된 Snowflake 사용자에 의존하지 않습니다. Panther에 새 데이터 소스를 온보딩하면 Admin 데이터베이스 API Lambda를 사용하여 관련 테이블 및 Snowpipe 인프라가 생성됩니다. 이 Lambda는 Panther 데이터베이스 및 스키마에 대한. 읽기/쓰기.
Databricks
권한이 있는 연관 사용자를 가집니다. 이 Lambda를 호출하기 위한 직접적인 외부 연결은 없으며, 대신 이 Lambda는 내부 제어 평면에 의해 구동됩니다. 테이블은 p_event_time
Panther 고객은 보안 데이터 레이크로 을 클러스터 키로 사용합니다. Snowflake 비밀은 중 하나를 사용할 수 있습니다. AWS Secrets Manager
에 저장됩니다. RSA 비밀이 사용되며 매일 교체됩니다. 를 사용합니다. 이 서비스는 AWS IAM 권한을 사용하므로 쿼리 및 관리를 위해 구성된 Snowflake 사용자에 의존하지 않습니다. Panther에 새 데이터 소스를 온보딩하면 Admin 데이터베이스 API Lambda를 사용하여 관련 테이블 및 Snowpipe 인프라가 생성됩니다. 이 Lambda는 Panther 데이터베이스 및 스키마에 대한 Panther에는 로더 프로세스가 있어 S3에 로드할 파일에 대한 S3 알림을 위해 내부 SNS 주제를 수신합니다. 로더 프로세스는 모든 테이블을 관리하고
COPY INTO
명령을 사용하여 S3 파일을 배치 로드합니다. 컬럼에 대한 유동적 클러스터링 컬럼에 대한 이 적용됩니다.
Databricks OAuth 자격 증명은 고객의 Databricks AWS 계정의에 저장됩니다. 자격 증명은 고객의 Databricks AWS 계정의 쿼리
쿼리는 읽기 전용 데이터베이스 API Lambda를 사용하여 실행됩니다. 이 Lambda는
예약 검색 권한을 가진 연관 사용자를 가집니다. 탐지 쿼리는 비동기식입니다. 쿼리를 실행하라는 API 요청이 있으면 관련 SQL이 데이터 레이크에서 실행되고
queryId 를 반환합니다. 그런 다음 API 호출은 를 사용하여 상태를 확인하고 관련 결과를 읽습니다. 쿼리 실행 상태는 DynamoDB에 추적됩니다.
쿼리 결과는 30일 동안 EFS에 저장됩니다(이 기간은 구성 가능합니다). 고객은 Panther의
로 전달합니다. 탐지 검색 기록 을 사용하여 과거 검색 결과를 볼 수 있습니다. 에 의해 사용되는
는 AWS Step Function을 통해 실행됩니다. 쿼리 실행이 완료되면 스트리밍 탐지 프로세서는 추가 처리를 위해 쿼리 결과에 대한 참조와 함께 호출됩니다.
로 전달합니다. 현재 로그타입별 RBAC (현재는 Snowflake만 지원)는 활성화되면 역할별로 고유한 관리 읽기 전용 사용자가 존재합니다. 경고 발송 하위 시스템
하위 시스템은 경고를 DynamoDB 테이블에 삽입하며, 경고 발송 Lambda는 스트림에서 이를 수신합니다. 이 Lambda는 구성된 통합).
을 사용하여 목적지로 경고를 전송합니다.
로 전달합니다. Panther 콘솔에 경고를 표시하려면 핵심 경고 데이터는 DynamoDB에서 검색되고 해당 경고와 관련된 이벤트는 데이터 레이크에서 검색됩니다. 경고 제한 기능
은 잘못 구성된 탐지로 인해 발생하는 것으로 보이는 "경고 폭주"가 대상지를 과부하시키는 것을 방지하도록 설계되었습니다. 동일한 탐지로부터 한 시간에 1000개 이상의 경고가 생성되면 경고가 억제됩니다. (이 한도는 구성 가능합니다.) 한도가 충족되면 탐지는 계속 실행되어 데이터 레이크에 이벤트를 저장하므로 데이터 손실은 발생하지 않지만 경고는 생성되지 않습니다. 이 경우 고객에게 알리기 위해
시스템 오류
가 생성되며, 고객은 콘솔에서 수동으로 경고 억제를 해제할 수 있습니다(예: 탐지를 조정한 후).
경고 상태를 동기화하기 위해 Jira 및 Slack에 대해 Panther로 "콜백"할 수 있는 특수 인증된 엔드포인트가 있어(예: 경고 상태를 해결됨 으로 업데이트)
AI 하위 시스템 Panther AI 하위 시스템은 구조적으로 복잡하지 않습니다. 다음으로 구성됩니다:
서버: 요청을 수신하고 응답 및 영속성을 오케스트레이션합니다 외부 통합과 관련된 비밀은
해결됨진입점 및 컨텍스트에 따라 동적으로 시스템 프롬프트를 생성합니다
외부 통합과 관련된 비밀은쿼터 및 권한을 적용합니다
인터페이스: Amazon Bedrock
API와 인터페이스합니다
Panther 콘솔에 경고를 표시하려면 핵심 경고 데이터는 DynamoDB에서 검색되고 해당 경고와 관련된 이벤트는 데이터 레이크에서 검색됩니다. 도구 사용을 오케스트레이션합니다(이는 내부 Panther API 호출로 구성됨)AI 응답을 다음에 영속화하는 것을 관리합니다: 서버는 모든 AI 추론을 위해 Bedrock과 통신합니다 AI 응답의 영속화에 사용됩니다
응답은 명시적으로
Last updated
Was this helpful?