예시: 문자열 배열 vs. 문자열 기본 키 유형
특정 사용자와 연결된 들어오는 로그 이벤트에 추가 개인 정보가 포함되도록 커스텀 enrichment 테이블에 사용자 데이터를 저장하고 싶다고 가정해 보겠습니다. 사용자의 이메일 주소로 일치시키려 하므로, 이메일 필드는 enrichment 테이블의 기본 키이자 로그 이벤트의 Selector가 됩니다.
enrichment 테이블의 기본 키 열이 문자열인지 문자열 배열인지 결정하고 있습니다.
먼저, 로그 소스에서 수신할 것으로 예상되는 아래의 두 이벤트를 검토하세요.
```json
# 들어오는 로그 이벤트 1
{
"actor_email": "janedoeemailone@mail.com",
"action": "LOGIN"
}
# 들어오는 로그 이벤트 2
{
"actor_email": "janedoeemailtwo@mail.com",
"action": "EXPORT_FILE"
}
```
두 이메일 주소(`janedoeemailone@mail.com` 및 `janedoeemailtwo@mail.com`)는 같은 사용자 `Jane Doe`.
에 속합니다. Panther가 이 이벤트들을 받으면, enrichment 테이블을 사용해 각 이벤트에 Jane의 전체 이름과 역할을 enrichment하고 싶을 것입니다. enrichment 후에는 이 이벤트들이 다음과 같이 보이게 됩니다:
# enrichment 후 로그 이벤트 1
{
"actor_email": "janedoeemailone@mail.com",
"action": "LOGIN",
"p_enrichment": {
"<lookup_table_name>": {
"actor_email": {
"full_name": "Jane Doe",
"p_match": "janedoeemailone@mail.com",
"role": "ADMIN"
}
}
}
}
# enrichment 후 로그 이벤트 2
{
"actor_email": "janedoeemailtwo@mail.com",
"action": "EXPORT_FILE",
"p_enrichment": {
"<lookup_table_name>": {
"actor_email": {
"full_name": "Jane Doe",
"p_match": "janedoeemailtwo@mail.com",
"role": "ADMIN"
}
}
}
}
다음 중 하나로 커스텀 enrichment를 정의하여 이 enrichment를 구현할 수 있습니다:
* (권장) 문자열 배열 유형의 기본 키 열
* 문자열 유형의 기본 키 열
문자열 배열 유형의 기본 키 열을 가진 enrichment 테이블을 사용하면, Jane의 여러 이메일 주소를 하나의 기본 키 항목에 포함하여 한 행의 데이터와 연결할 수 있습니다. 이는 다음과 같이 보일 수 있습니다:
또는 문자열 유형의 기본 키 열을 가진 enrichment 테이블을 정의할 수도 있습니다. 그러나 이벤트와 enrichment 테이블 간의 일치는 사용자의 이메일 주소로 이루어지며, 사용자는 여러 이메일 주소를 가질 수 있으므로(Jane의 경우처럼), 각 이메일마다 enrichment 테이블 행을 복제해야 합니다. 이는 다음과 같습니다:
두 옵션 모두 같은 결과를 내지만(즉, 로그 이벤트가 동일한 방식으로 enrichment됨), 관리가 편하고 유지보수 실수의 가능성이 낮기 때문에 문자열 배열 기본 키로 enrichment를 정의하는 것이 권장됩니다.
## 커스텀 enrichment 구성 방법
다음을 충족한 후 [전제 조건](#prerequisites-for-configuring-a-custom-enrichment)을 충족하면, 다음 방법 중 하나를 사용하여 커스텀 enrichment를 생성하고 구성할 수 있습니다. Panther 콘솔에서는 현재 각 방법이 enrichment 온보딩 페이지의 전용 타일로 제공되어 빠르고 직접적으로 접근할 수 있습니다:
* [옵션 1: Scheduled Search로 커스텀 enrichment 데이터 가져오기](#option-1-import-custom-enrichment-data-with-a-scheduled-search)
* **타일: "스케줄된 쿼리로 데이터 가져오기"**
* 반복 일정에 따라 자동 업데이트되도록 데이터 웨어하우스에서 직접 데이터를 가져오는 데 가장 적합합니다.
* 예: 현재 환경을 기반으로 자동 새로고침이 필요한 의심스러운 IP, 사용자 행동 패턴 또는 AWS 계정 매핑 추적.
* [옵션 2: ](#option-2-import-lookup-table-data-via-file-upload)[파일 업로드를 통해 커스텀 enrichment 데이터 가져오기](https://docs.panther.com/enrichment/custom#option-1-import-lookup-table-data-via-file-upload)
* **타일: "CSV 또는 JSON 파일 업로드"**
* AWS 계정 정보나 회사 서브넷처럼 비교적 정적인 데이터에 가장 적합합니다.
* 파일 업로드를 통해 채워진 커스텀 enrichment 테이블의 최대 크기는 6 MB입니다(API 요청의 payload 크기 제한 때문).
* AWS CloudTrail 로그에서 개발 계정과 프로덕션 계정을 구분하기 위해 메타데이터를 추가하는 예.
* [옵션 3: S3 버킷에서 커스텀 enrichment 데이터 동기화](#option-3-sync-custom-enrichment-data-from-an-s3-bucket)
* **타일: "AWS S3에서 데이터 동기화"**
* 간소화된 4단계 마법사를 사용합니다: 기본 정보 → S3 연결 → 스키마 → 검증.
* 데이터가 비교적 자주 업데이트되는 대량의 데이터가 있을 때 가장 적합합니다. S3 버킷의 변경 사항은 Panther와 동기화됩니다.
* S3 버킷에서 동기화된 커스텀 enrichment 테이블의 최대 크기는 10 GB입니다.
* 예: 회사의 직원과 연결된 그룹 및 권한 수준을 알고 싶다고 가정해 보겠습니다. 이 경우 회사는 그룹 및 권한 정보가 포함된 최신 Active Directory 목록 사본이 들어 있는 S3 버킷을 보유하고 있을 수 있습니다.
* [옵션 4: Google Cloud Storage(GCS) 버킷에서 커스텀 enrichment 데이터 동기화](#option-4-sync-custom-enrichment-data-from-a-google-cloud-storage-gcs-bucket)
* **타일: "Google Cloud Storage에서 데이터 동기화"**
* 데이터가 비교적 자주 업데이트되는 대량의 데이터가 있을 때 가장 적합합니다. GCS 버킷의 변경 사항은 Panther와 동기화됩니다.
* GCS 버킷에서 동기화된 커스텀 enrichment 테이블의 최대 크기는 10 GB입니다.
* Panther 인스턴스에서 Google Cloud Storage가 활성화되어 있어야 합니다.
이 방법 중 하나를 선택한 후에는 Panther 콘솔 또는 다음과 함께 작업하도록 선택할 수 있습니다 [PAT](/ko/panther/detections-repo/pat.md).
{% hint style="warning" %}
커스텀 enrichment 테이블의 행 최대 크기는 65535 bytes입니다.
{% endhint %}
### 옵션 1: Scheduled Search로 커스텀 enrichment 데이터 가져오기
{% hint style="info" %}
Scheduled Search를 사용한 커스텀 enrichment 데이터 가져오기는 Panther 버전 1.117부터 공개 베타이며, 모든 고객이 사용할 수 있습니다. 버그 보고와 기능 요청은 Panther 지원 팀에 공유해 주세요.
{% endhint %}
커스텀 enrichment 데이터는 다음 결과로 자동 채워질 수 있습니다 [예약된 검색](/ko/search/scheduled-searches.md). 이 방법은 외부 스크립트나 수동 CSV 내보내기의 필요성을 없애 주며, 정해진 일정에 따라 자동으로 업데이트되는 enrichment 데이터를 유지할 수 있게 합니다.
{% hint style="warning" %}
**Scheduled Search를 사용한 커스텀 enrichment 데이터 가져오기의 제한 사항**
* CIDR 매칭은 사용할 수 없습니다.
* Scheduled Search는 최소 15분마다 실행할 수 있습니다.
* 검색 타임아웃은 15분으로 고정되어 있으며 구성할 수 없습니다.
{% endhint %}