# Panther Analysis Tool로 보강 공급자 관리하기

## 개요

[Enrichment](/ko/enrichment.md) 소스(조회 테이블이라고도 함)를 사용하면 수신 로그에 더 많은 컨텍스트를 추가할 수 있습니다. 다음에 대한 스키마와 매핑을 관리할 수 있습니다. [사용자 지정 보강](/ko/enrichment/custom.md) 및 특정 Panther 관리형 보강을 통해 [Panther Analysis Tool (PAT)](/ko/panther/detections-repo/pat.md).

이 가이드에서는 다음 내용을 안내합니다:

* 다음을 사용하여 사용자 지정 보강 소스용 사용자 지정 스키마를 생성하고 업로드하기 [`pantherlog` 도구](/ko/panther/pantherlog.md).
* 수정하기 `셀렉터` 및 `로그 유형` 보강 소스의 YAML 구성 파일에서.
  * 로그 유형과 셀렉터는 [수동으로 설정되거나](/ko/enrichment/custom.md#option-1-manually-choose-log-types-and-selectors) 또는 [indicator 필드에 의해 자동으로 매핑될 수 있습니다](/ko/enrichment/custom.md#option-2-let-log-types-and-selectors-be-automatically-mapped-by-indicator-fields).
* PAT를 통해 보강 소스의 YAML 구성 파일 업로드하기.
* Panther Console에서 보강 테스트하기.

{% hint style="info" %}

* 팀에서 CLI 워크플로를 사용하는 경우, Console의 디택션 팩을 통해 관리하는 대신 PAT와 CI/CD를 사용하여 보강을 관리하는 것이 권장됩니다.
* Panther Console에서 활성화한 후 PAT를 통해 보강 테이블을 관리하려는 경우, 먼저 Panther Console에서 디택션 팩을 비활성화해야 합니다. 보강 소스를 관리하기 위해 Panther Console과 PAT를 동시에 사용하는 것은 지원되지 않습니다.
  {% endhint %}

{% hint style="warning" %}
이 가이드는 다음에 적용됩니다. [사용자 지정 보강](/ko/enrichment.md#custom-enrichments) 및 [이러한 Panther 관리형 보강 소스](/ko/enrichment.md#additional-enrichment-sources).

["자체 API 키 가져오기" 로그 풀러](/ko/enrichment.md#bring-your-own-api-key-log-pullers) 및 [Panther 로그 소스 풀러](/ko/enrichment.md#panther-log-source-pullers) 은 PAT를 사용하는 CLI 워크플로에서 활성화할 수 없습니다.
{% endhint %}

### 사용자 지정 보강과 Panther 관리형 보강 비교

* [사용자 지정 보강](/ko/enrichment/custom.md) 은(는) 사용자가 관리합니다. 스키마를 생성하고 업로드한 다음, 보강 테이블의 YAML 구성 파일을 업로드해야 합니다.
* Panther 관리형 보강 공급자는 Panther에서 관리합니다. 해당 스키마는 Panther에서 정의하며, 필요에 맞게 수정할 수 있는 YAML 구성 파일은 다음에서 찾을 수 있습니다. [panther-analysis 리포지토리](https://github.com/panther-labs/panther-analysis/blob/master/lookup_tables/) GitHub에서.

## PAT로 사용자 지정 및 Panther 관리형 보강을 관리하는 방법

{% tabs %}
{% tab title="사용자 지정 보강" %}
**사전 요구 사항**

* YAML 구성 파일. YAML 구성 파일은 직접 만들어야 합니다.
* 데이터 샘플(새 스키마를 생성해야 하는 경우) 또는 Panther에서 생성된 기존 YAML 스키마.

**1단계: 스키마 생성 및 업로드**

사용자 지정 보강은 사용자가 생성하여 Panther에 업로드한 스키마와 연결되어야 합니다. 사용자 지정 보강에 연결하려는 스키마를 이미 Panther에서 생성했다면, 이 단계는 건너뛸 수 있습니다.

1. 샘플 로그 데이터를 사용하여 스키마를 생성합니다.
   * 다음을 사용할 수 있습니다. `pantherlog` 샘플 데이터 세트에서 스키마를 추론합니다. 샘플 JSON 로그 파일에서 스키마를 생성하려면 다음을 사용하세요. `infer` 명령어:

     ```bash
     $ ./pantherlog infer sample_logs.jsonl > schema.yml
     ```
   * 추론된 스키마를 검토하고 Panther에 업로드하기 전에 필요한 조정을 수행하는 것을 잊지 마세요. 이 프로세스에 대한 자세한 내용은 다음을 참조하세요. [pantherlog 문서](/ko/panther/pantherlog.md).
2. 스키마 업로드하기.
   * 스키마를 생성한 후에는 다음을 따라 Panther에 업로드할 수 있습니다. [Panther Analysis Tool로 로그 스키마 업로드하기](/ko/data-onboarding/custom-log-types.md#uploading-log-schemas-with-the-panther-analysis-tool) 지침에 있는 단계를 완료했습니다.

**2단계: YAML 구성 파일 생성**

* 사용자 지정 보강의 경우 YAML 구성 파일을 처음부터 직접 만들어야 합니다. 다음을 참조하세요. [조회 테이블 사양 참조](/ko/enrichment/custom/lookup-table-specification-reference.md) 이 파일에 어떤 키가 포함되어야 하는지 확인하려면.

**3단계: PAT를 통해 사용자 지정 보강 업로드**

사용자 지정 보강 구성 파일을 생성한 후에는 PAT를 사용하여 이를 Panther에 업로드할 수 있습니다. [`upload` 명령](/ko/panther/detections-repo/pat/pat-commands.md#upload-uploading-packages-to-panther-directly):

```bash
panther_analysis_tool upload
```

다음과 함께 API 토큰과 호스트를 제공해야 합니다. `--api-token` 및 `--api-host`업로드가 이루어지도록 하기 위해 각각. 다른 옵션으로는 필터링, 최소 테스트 등이 있습니다.

{% hint style="warning" %}
YAML 구성 파일을 업로드하기 전에 해당 스키마를 먼저 업로드했는지 확인하세요.
{% endhint %}

**4단계: 사용자 지정 보강 테스트**

사용자 지정 보강이 올바르게 설정되었는지 테스트하는 방법은 여러 가지가 있습니다.

**방법 1: Panther Console 또는 CLI에서 테스트 데이터 보강**

{% tabs %}
{% tab title="Console" %}
Panther Console의 디택션 편집기에서 **테스트 데이터 보강** 를 클릭하여 사용자 지정 보강이 올바르게 작동하는지 확인하세요. 이렇게 하면 테스트 데이터를 입력하고 단위 테스트 내에서 보강 프로세스의 출력을 확인할 수 있습니다.

{% hint style="warning" %}
\~에 대해 **테스트 데이터 보강** 가 작동하려면 단위 테스트에 `p_log_type` 올바른 로그 유형을 식별하는. 이는 Panther의 보강 로직의 기반이 됩니다.
{% endhint %}
{% endtab %}

{% tab title="CLI" %}

* PAT의 `enrich-test-data` 명령을 사용하세요. [다음에 대해 자세히 알아보세요 `enrich-test-data` 여기](/ko/panther/detections-repo/pat/pat-commands.md#enrich-test-data-enriching-test-data-with-enrichment-content).
  {% endtab %}
  {% endtabs %}

**방법 2: `panther_signals` 데이터베이스 확인**

다음 `panther_signals.public.correlation_signals` 데이터베이스/테이블에서 `p_enrichment` 필드를 확인하여 변경 사항이 적용되었는지 검증할 수 있습니다. 해당 필드에 예상되는 사용자 지정 보강 세부 정보가 포함되어 있는지 확인하세요.

**방법 3: SQL 쿼리 사용**

또한 `LEFT JOIN` 을 SQL에서 이벤트 로그와 보강 테이블 사이에 수행할 수도 있습니다. 쿼리에 선택자가 정의되어 있는지 확인하세요. 이렇게 하면 로그의 데이터가 사용자 지정 보강의 데이터와 올바르게 일치하는지 검증할 수 있습니다.

예를 들어, 이 쿼리는 사용자 지정 선택자(이는 YAML 구성 파일에서 정의한 선택자와 동일해야 함)를 사용하여 이벤트 데이터를 사용자 지정 보강과 일치시키려고 시도합니다:

```sql
SELECT *
FROM panther_logs.public.<log_type> AS e
LEFT JOIN panther_lookups.public.<lookup_table_name> AS lt
ON e.<field_path> = lt.<field_path>
WHERE e.p_occurs_since('1 day')
```

{% endtab %}

{% tab title="Panther가 관리하는 보강" %}
**필수 조건**

* YAML 구성 파일. 다음을 사용할 수 있습니다. [panther-analysis의 Panther 제공 구성 파일](https://github.com/panther-labs/panther-analysis/tree/master/lookup_tables).

**1단계: 필요에 따라 YAML 구성 파일 수정**

Panther가 관리하는 보강을 활성화하는 경우, 다음이 포함된 구성 파일을 수정할 수 있습니다. [Panther는 다음을 제공합니다.](https://github.com/panther-labs/panther-analysis/tree/master/lookup_tables) 필요에 맞게

* Panther가 제공한 보강용 YAML 구성 파일을 수정할 때는, 오직 `AssociatedLogTypes` 키의 내용만 수정하여 `셀렉터`을 사용자 지정해야 합니다. 다음과 같은 다른 매개변수의 변경은 `Refresh` 간격은 문제를 일으키는 것으로 알려져 있습니다.

**예시**

{% hint style="warning" %}
이 로그 유형(`Cloudflare.Firewall`)과 선택자(`ClientIP`)를 이런 방식으로 수동 설정하지 않았더라도, `Cloudflare.Firewall` 및 `p_any_ip_addresses` 는 각각 로그 유형과 선택자로 추가됩니다. 이는 [지표 필드의 자동 매핑 때문입니다.](/ko/enrichment/custom.md#option-2-let-log-types-and-selectors-be-automatically-mapped-by-indicator-fields).

그 이유는 `ClientIP` 이 다음의 `ip` 지표 필드로 지정되어 있기 때문입니다. `Cloudflare.Firewall` schema와 Tor Lookup Table의 primary key, `ip`,는 하나의 `ip` 표시자로서 자체 데이터 schema에, `Tor.ExitNode`.
{% endhint %}

이 예시에서는, `tor_exit_nodes` enrichment가 새로운 `LogType` 및 `Selector`.

* 다음 값은 유의하세요`PrimaryKey` 은 `ip`.
* 아래 예시는 하나의 `AssociatedLogTypes` 기본적으로 포함됩니다.

```yaml
LogTypeMap:
  PrimaryKey: ip
  AssociatedLogTypes:
    - LogType: AlphaSOC.Al러트
      Selectors:
        - '$.event.srcIP'
```

다음에 목록 항목을 추가해 봅시다 `AssociatedLogTypes` 에 대한 지원을 추가하는 `ip_address` 필드를 `Cloudflare.Firewall` schema:

* 참고로 `셀렉터` 는 상위 필드이거나 중첩 필드의 JSON 경로일 수 있습니다.

```yaml
LogTypeMap:
  PrimaryKey: ip
  AssociatedLogTypes:
    - LogType: AlphaSOC.Al러트
      Selectors:
        - '$.event.srcIP'
    - LogType: Cloudflare.Firewall
      Selectors:
        - "ClientIP"
```

**2단계: PAT를 통해 enrichment 업로드**

enrichment 구성 파일을 수정한 후에는 PAT를 사용해 Panther에 업로드할 수 있습니다 [`upload` 명령](/ko/panther/detections-repo/pat/pat-commands.md#upload-uploading-packages-to-panther-directly):

```bash
panther_analysis_tool upload
```

다음과 함께 API 토큰과 호스트를 제공해야 합니다. `--api-token` 및 `--api-host`업로드가 이루어지도록 하기 위해 각각. 다른 옵션으로는 필터링, 최소 테스트 등이 있습니다.

**3단계: enrichment 테스트**

enrichment가 올바르게 설정되었는지 테스트하는 방법은 여러 가지가 있습니다.

**방법 1: Panther Console 또는 CLI에서 테스트 데이터 보강**

{% tabs %}
{% tab title="Console" %}
Panther Console의 디택션 편집기에서 **테스트 데이터 보강** enrichment가 올바르게 작동하는지 확인합니다. 이를 통해 테스트 데이터를 입력하고 단위 테스트 내에서 enrichment 프로세스의 출력을 확인할 수 있습니다.

{% hint style="warning" %}
\~에 대해 **테스트 데이터 보강** 가 작동하려면 단위 테스트에 `p_log_type` 올바른 로그 유형을 식별하는. 이는 Panther의 보강 로직의 기반이 됩니다.
{% endhint %}
{% endtab %}

{% tab title="CLI" %}

* PAT의 기능을 사용하여 enrichment가 올바르게 작동하는지 확인하세요 `enrich-test-data` 명령을 사용하세요. [다음에 대해 자세히 알아보세요 `enrich-test-data` 여기](/ko/panther/detections-repo/pat/pat-commands.md#enrich-test-data-enriching-test-data-with-enrichment-content).
  {% endtab %}
  {% endtabs %}

**방법 2: `panther_signals` 데이터베이스 확인**

다음 `panther_signals.public.correlation_signals` 데이터베이스/테이블에서 `p_enrichment` 필드. 해당 필드에 기대하는 enrichment 세부 정보가 포함되어 있는지 확인하세요.

**방법 3: SQL 쿼리 사용**

또한 `LEFT JOIN` 이벤트 로그와 SQL의 enrichment table 사이에서. selector가 쿼리에 정의되어 있는지 확인하세요. 이를 통해 로그의 데이터가 enrichment table의 데이터와 올바르게 매칭되는지 확인할 수 있습니다.

예를 들어, 이 쿼리는 사용자 정의 selector(이는 enrichment 구성에서 정의한 selector와 같아야 함)를 사용하여 이벤트 데이터를 enrichment 데이터와 매칭하려고 시도합니다:

```sql
SELECT *
FROM panther_logs.public.<log_type> AS e
LEFT JOIN panther_lookups.public.<lookup_table_name> AS lt
ON e.<field_path> = lt.<field_path>
WHERE e.p_occurs_since('1 day')
```

{% endtab %}

{% tab title="SQL custom enrichments (Beta)" %}
{% hint style="info" %}
SQL custom enrichments는 Panther 버전 1.120부터 공개 beta이며, 모든 고객에게 제공됩니다. 버그 보고와 기능 요청은 Panther 지원 팀과 공유해 주세요.
{% endhint %}

**1단계: YAML 구성 파일 생성**

다음과 같은 YAML 파일을 생성합니다 `Query` 필드. schema는 쿼리 결과에서 자동 생성되므로 수동 schema 정의가 필요하지 않습니다. 다음을 참조하세요 [Custom Enrichment Specification Reference](/ko/enrichment/custom/lookup-table-specification-reference.md) 사용 가능한 모든 필드에 대해.

**예시:**

```yaml
AnalysisType: lookup_table
LookupName: panther_audit_enrichment
Enabled: true
Description: Panther 감사 활동 컨텍스트로 알러트를 enrichment합니다.
Indicators:
  - Field: actor
    Indicators: [username]
Query: |
  SELECT
    id,
    actionname,
    actiondescription,
    actionresult,
    actor,
    sourceip,
    useragent,
    타임스탬프
  FROM panther_logs.public.panther_audit
새로고침:
  주기분: 60
LogTypeMap:
  기본 키: id
```

**2단계: PAT를 통해 업로드**

`panther_analysis_tool upload`

다른 명령과 마찬가지로, 다음을 제공해야 합니다 `--api-token` 및 `--api-host` 인증용으로 (또는 다음을 입력하세요: `.panther_settings.yml` 파일).\
\
enrichment만 업로드하려면:

`panther_analysis_tool upload --filter AnalysisType=lookup_table`

{% hint style="info" %}
스키마는 SQL 쿼리 결과로부터 자동 생성됩니다. 별도의 스키마 업로드는 필요하지 않습니다.
{% endhint %}

**3단계: 확인**

* 콘솔: Enrichments 페이지에서 enrichment가 생성/업데이트되었는지 확인하세요.
* SQL: 데이터를 확인하려면 enrichment 테이블을 직접 쿼리하세요:

`SELECT * FROM panther_lookups.public.name_of_your_enrichment LIMIT 1`
{% endtab %}
{% endtabs %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.panther.com/ko/panther/detections-repo/pat/managing-enrichment.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.