Audit logs

원문 보기 위키 갱신 2026.10.14

출처: 문서

본문

감사 로그

{: .text-delta } - TOC {:toc}

감사 로그를 사용하면 OpenSearch 클러스터에 대한 접근을 추적할 수 있어서, 컴플라이언스 목적이나 보안 침해 발생 후 조사에 유용해요. 기록할 카테고리, 기록되는 메시지의 상세 수준, 로그를 저장할 위치를 설정할 수 있어요.

OpenSearch는 두 가지 감사 로깅 모드를 지원해요. 다음 표에서 각 모드와 설정 방법을 설명해요.

모드	요구 사항	설정
Standard(기본값)	세분화된 접근 제어(fine-grained access control, FGAC)가 활성화된 Security 플러그인.	security 인덱스의 `audit.yml` 파일과 REST API.
Standalone	FGAC 없음. SSL 전용 모드(`plugins.security.ssl_only: true`)로 실행되거나 보안이 비활성화된 상태(`plugins.security.disabled: true`)로 실행됨.	`opensearch.yml`과 동적 클러스터 설정.

standalone 모드에 대한 자세한 내용은 Standalone audit logging을 참고하세요.

감사 로깅 활성화하기(standard 모드)

감사 로깅은 기본적으로 비활성화되어 있어요. 감사 로깅을 활성화하려면:

각 노드의 opensearch.yml에 다음 줄을 추가하세요:
```
plugins.security.audit.type: internal_opensearch
```
{% include copy.html %}

이 설정은 감사 로그를 현재 클러스터에 저장해요. 다른 저장 옵션은 Audit Log Storage Types을 참고하세요.
각 노드를 재시작하세요.

감사 로깅에는 두 가지 설정이 필요해요. opensearch.yml의 저장 타입(plugins.security.audit.type)과 audit.yml의 config.enabled: true가 그것이에요. Security 플러그인이 제공하는 audit.yml 파일은 기본적으로 config.enabled를 true로 설정하기 때문에, 새 클러스터에서는 감사 로깅이 활성화된 것처럼 보일 수 있어요. 저장 타입을 지정하기 전까지는 Security 플러그인이 감사 로그용 저장 엔드포인트를 생성할 수 없어서, 이벤트를 기록하지 않고 시작 시 기본 저장소를 사용할 수 없다는 경고를 로그에 남겨요. {: .note}

이 초기 설정 이후에는 OpenSearch Dashboards에서 감사 로그 카테고리와 기타 설정을 관리할 수 있어요. OpenSearch Dashboards에서 Security를 선택한 다음 Audit logs를 선택하세요. 또는 audit.yml과 opensearch.yml 파일에서 감사 로깅 설정을 지정할 수도 있어요(설정에 따라 어느 파일을 사용할지가 달라져요---자세한 내용은 Audit log settings을 참고하세요). Audit log APIs를 사용해서 설정을 관리하고 업데이트할 수도 있어요.

추적되는 이벤트

감사 로깅은 HTTP 요청(REST)과 트랜스포트 계층, 이 두 가지 방식으로 이벤트를 기록해요. 다음 표에서 추적되는 이벤트에 대한 설명과 해당 이벤트가 REST 또는 트랜스포트 계층에서 기록되는지 여부를 확인할 수 있어요.

이벤트	REST에서 기록	트랜스포트에서 기록	설명
`FAILED_LOGIN`	예	예	요청의 자격 증명을 검증하지 못했어요. 대부분 사용자가 존재하지 않거나 비밀번호가 틀렸기 때문이에요.
`AUTHENTICATED`	예	예	사용자가 성공적으로 인증했어요.
`MISSING_PRIVILEGES`	아니요	예	사용자에게 요청을 수행할 필요 권한이 없어요.
`GRANTED_PRIVILEGES`	아니요	예	사용자가 OpenSearch에 성공적인 요청을 보냈어요.
`SSL_EXCEPTION`	예	예	유효한 SSL/TLS 인증서 없이 OpenSearch에 접근하려는 시도가 있었어요.
`opensearch_SECURITY_INDEX_ATTEMPT`	아니요	예	필요한 권한이나 TLS 관리자 인증서 없이 Security 플러그인의 내부 사용자 및 권한 인덱스를 수정하려는 시도가 있었어요.
`BAD_HEADERS`	예	예	Security 플러그인의 내부 헤더를 사용해 OpenSearch 요청을 스푸핑하려는 시도가 있었어요.
`CLUSTER_SETTINGS_CHANGED`	아니요	예	persistent 또는 transient 클러스터 설정이 변경됐어요. 기본적으로는 비활성화되어 있어요.
`INDEX_SETTINGS_CHANGED`	아니요	예	인덱스 설정이 변경됐어요. 기본적으로는 비활성화되어 있어요.
`REQUEST_AUDIT`	예	예	REST 요청이 수신되고 처리됐어요. standalone audit logging 모드에서만 생성돼요. 이 이벤트를 억제하는 방법에 대한 자세한 내용은 Suppressing `REQUEST_AUDIT` events을 참고하세요.
`TRANSPORT_AUDIT`	아니요	예	노드에서 트랜스포트 계층 요청이 수신됐어요. standalone audit logging 모드에서만 생성돼요.
`RESOURCE_ACCESS_GRANTED`	아니요	예	공유 리소스에 대한 접근이 허용됐어요. 기본적으로는 비활성화되어 있어요.
`RESOURCE_ACCESS_DENIED`	아니요	예	공유 리소스에 대한 접근이 거부됐어요. 기본적으로는 비활성화되어 있어요.
`RESOURCE_SHARING_CHANGED`	아니요	예	리소스 공유 설정이 변경됐어요. 기본적으로는 비활성화되어 있어요.

REQUEST_AUDIT는 REST 요청(audit_request_origin: REST)에서 발생하지만, 이벤트 자체는 audit_request_layer: TRANSPORT로 기록돼요. 그래서 disabled_categories, disabled_transport_categories, disabled_rest_categories 중 무엇으로든 억제할 수 있어요---이 설정 중 하나에 REQUEST_AUDIT을 추가하기만 해도 이벤트가 억제돼요. {: .note}

감사 로그 설정

다음 기본 로그 설정은 대부분의 사용 사례에 잘 맞아요. 하지만 저장 공간을 절약하거나 정보를 필요에 딱 맞게 조정하고 싶다면 설정을 변경할 수 있어요.

audit.yml의 설정

다음 설정들은 audit.yml 파일에 저장돼요.

카테고리 제외하기

카테고리를 제외하려면 다음 설정에 나열하세요:

config:
  audit:
    disabled_rest_categories: <disabled categories>
    disabled_transport_categories: <disabled categories>

{% include copy.html %}

예를 들면 다음과 같아요:

config:
  audit:
    disabled_rest_categories:
      - AUTHENTICATED
      - GRANTED_PRIVILEGES
    disabled_transport_categories: [ GRANTED_PRIVILEGES ]

{% include copy.html %}

또는 통합 설정인 disabled_categories를 사용해 두 레이어에서 카테고리를 동시에 비활성화할 수도 있어요:

config:
  audit:
    disabled_categories:
      - AUTHENTICATED
      - GRANTED_PRIVILEGES

{% include copy.html %}

disabled_categories를 disabled_rest_categories 또는 disabled_transport_categories와 함께 구성하면, 통합 설정이나 레이어별 설정 중 어느 곳에든 카테고리가 나타날 경우 해당 레이어에서 비활성화돼요.

disabled_categories를 레이어별 설정과 함께 구성하면 disabled_categories만 사용하도록 마이그레이션을 권장하는 지원 중단 경고가 로그에 기록돼요.

예를 들어 다음 구성은 두 레이어 모두에서 AUTHENTICATED를 비활성화하고(disabled_categories 사용), REST 레이어에서만 SSL_EXCEPTION을 비활성화해요:

config:
  audit:
    disabled_categories:
      - AUTHENTICATED
    disabled_rest_categories:
      - SSL_EXCEPTION

{% include copy.html %}

기본적으로 CLUSTER_SETTINGS_CHANGED와 INDEX_SETTINGS_CHANGED 카테고리는 transport 레이어에서 비활성화되어 있어요. 이를 활성화하려면 disabled_transport_categories에서 제거하세요:

config:
  audit:
    disabled_transport_categories:
      - AUTHENTICATED
      - GRANTED_PRIVILEGES

{% include copy.html %}

모든 카테고리의 이벤트를 로그에 기록하려면 NONE을 사용하세요:

config:
  audit:
    disabled_rest_categories: NONE
    disabled_transport_categories: NONE

{% include copy.html %}

REST 또는 transport 레이어 비활성화하기

기본적으로 Security 플러그인은 REST와 transport 레이어 양쪽에서 이벤트를 기록해요. 둘 중 하나를 비활성화할 수 있어요:

config:
  audit:
    enable_rest: false
    enable_transport: false

{% include copy.html %}

요청 본문 로깅 비활성화하기

기본적으로 Security 플러그인은 REST와 transport 레이어 양쪽에서 요청 본문(있는 경우)을 포함해요. 요청 본문이 필요 없거나 원하지 않는다면 비활성화할 수 있어요:

config:
  audit:
    log_request_body: false

{% include copy.html %}

인덱스 이름 로깅하기

기본적으로 Security 플러그인은 요청의 영향을 받는 모든 인덱스를 기록해요. 인덱스 이름은 별칭(alias)일 수 있고 와일드카드/날짜 패턴을 포함할 수 있기 때문에, Security 플러그인은 사용자가 제출한 인덱스 이름 과 그 이름이 실제로 해석되는 인덱스 이름을 모두 기록해요.

예를 들어 별칭이나 와일드카드를 사용하면 감사 이벤트가 다음과 같이 보일 수 있어요:

audit_trace_indices: [
  "human*"
],
audit_trace_resolved_indices: [
  "humanresources"
]

{% include copy.html %}

다음과 같이 설정하면 이 기능을 비활성화할 수 있어요:

config:
  audit:
    resolve_indices: false

{% include copy.html %}

이 기능은 config.audit.log_request_body도 false로 설정된 경우에만 비활성화돼요. {: .note }

벌크 요청 처리 구성하기

벌크 요청에는 여러 색인 작업이 포함될 수 있어요. 기본적으로 Security 플러그인은 개별 작업이 아니라 벌크 요청 하나만 기록해요.

Security 플러그인을 구성하면 각 색인 작업을 별도의 이벤트로 기록할 수도 있어요:

config:
  audit:
    resolve_bulk_requests: true

{% include copy.html %}

이 변경은 감사 로그에 엄청나게 많은 이벤트를 만들어낼 수 있으므로, _bulk API를 자주 사용한다면 이 설정을 활성화하지 않는 것을 권장해요.

요청 제외하기

특정 요청이 로그에 기록되지 않게 하려면 transport 요청의 액션, HTTP 요청 경로(REST), 또는 둘 모두를 구성하세요:

config:
  audit:
    ignore_requests: ["indices:data/read/*", "SearchRequest"]

{% include copy.html %}

사용자 제외하기

기본적으로 Security 플러그인은 모든 사용자의 이벤트를 기록하지만 내부 OpenSearch Dashboards 서버 사용자인 kibanaserver는 제외해요. 다른 사용자를 제외할 수도 있어요:

config:
  audit:
    ignore_users:
      - kibanaserver
      - admin

{% include copy.html %}

모든 사용자의 요청을 기록하려면 NONE을 사용하세요:

config:
  audit:
    ignore_users: NONE

{% include copy.html %}

헤더 제외하기

민감한 헤더가 로그에 포함되지 않도록 제외할 수 있어요---예를 들어 Authorization: 헤더 같은 경우죠:

config:
  audit:
    exclude_sensitive_headers: true

{% include copy.html %}

opensearch.yml의 설정

다음 설정들은 opensearch.yml 파일에 저장돼요. 런타임에 어떻게 적용되는지는 감사 로깅 모드에 따라 달라져요:

스탠드얼론 모드(SSL 전용 또는 보안 비활성화)에서는 대부분의 감사 필터 및 컴플라이언스 설정을 노드 재시작 없이 Cluster Settings API를 사용해 런타임에 변경할 수 있어요. 여기에는 log_request_body, resolve_indices, disabled_categories, enable_rest, enable_transport, ignore_users, ignore_requests가 포함돼요.
FGAC가 적용된 표준 모드에서는 감사 구성이 audit.yml에 저장되며, 그에 해당하는 plugins.security.audit.config.* 및 plugins.security.audit.compliance.* 클러스터 설정으로는 이를 업데이트하지 못해요. PUT _cluster/settings 요청이 감사 구성을 변경하지 않은 채 성공할 수도 있어요. body_logging_exclusions 설정은 예외인데, FGAC 모드에서는 Cluster Settings API를 사용해 업데이트할 수 있어요.

일부 감사 설정은 정적이라 노드 재시작이 필요해요: action_groups.<NAME>, log4j.enable_mdc_routing, config.index, 스레드 풀 설정, 싱크 연결 설정이 그렇죠.

FGAC가 활성화된 경우 동적 감사 설정을 업데이트하려면 plugins.security.restapi.roles_enabled에 나열된 역할이 필요해요. 이 제한은 SSL 전용 모드나 보안 비활성화 모드에서는 적용되지 않아요. body_logging_exclusions 설정은 상승된 역할 없이도 업데이트할 수 있어요.

다음 표는 각 모드에서 호출자가 GET _cluster/settings를 사용해 읽을 수 있는 감사 설정을 설명해요.

모드	설정 응답에 표시되는 감사 설정
스탠드얼론, SSL 전용	모든 호출자가 비밀이 아닌 동적 감사 구성(`plugins.security.audit.config.` 및 `plugins.security.audit.compliance.`)을 읽을 수 있어요. 자격 증명이 포함된 싱크 설정은 계속 숨겨져 있어요.
스탠드얼론, 보안 비활성화	`plugins.security.audit.*` 설정은 아무것도 필터링되지 않으므로 싱크 자격 증명과 PEM 내용이 노출될 수 있어요.
FGAC	`plugins.security.audit.*` 하위 트리 전체가 모든 호출자에 대해 필터링돼요. 이 필터링은 역할 기반이 아니에요.

plugins.security.audit.enabled 런타임 토글은 스탠드얼론 감사 로깅에만 적용돼요. 사용 방법은 스탠드얼론 감사 로깅을 참고하세요. {: .note}

카테고리 제외하기

plugins.security.audit.config 접두사를 사용해 opensearch.yml에서 비활성화할 카테고리를 구성할 수 있어요. 이는 audit.yml 보안 인덱스를 사용할 수 없는 비-FGAC 모드(SSL 전용 또는 보안 비활성화)에서 유용해요:

plugins.security.audit.config.disabled_categories:
  - AUTHENTICATED
  - GRANTED_PRIVILEGES

{% include copy.html %}

레이어별 설정인 disabled_rest_categories와 disabled_transport_categories는 더 이상 권장되지 않아요. 대신 통합 설정인 disabled_categories를 사용하세요. {: .warning}

레이어별 설정도 사용할 수 있어요:

plugins.security.audit.config.disabled_rest_categories:
  - AUTHENTICATED
  - GRANTED_PRIVILEGES
plugins.security.audit.config.disabled_transport_categories:
  - AUTHENTICATED
  - GRANTED_PRIVILEGES

{% include copy.html %}

disabled_categories와 레이어별 설정을 모두 구성하면, 어느 설정에든 카테고리가 나타날 경우 해당 레이어에서 비활성화돼요. 또한 disabled_categories만 사용할 것을 권장하는 지원 중단 경고도 로그에 기록돼요.

disabled_categories 설정은 REST와 transport 카테고리만 억제해요. COMPLIANCE_* 카테고리에는 영향을 주지 않는데, 이는 컴플라이언스 설정(compliance.enabled, 감시 대상 인덱스와 필드, 컴플라이언스 ignore-users 설정)에 의해서만 결정돼요. {: .note}

본문 로깅 제외

body_logging_exclusions를 사용하면 다른 모든 요청의 본문은 계속 기록하면서 특정 액션이나 REST 경로에 대해서만 요청 본문을 생략할 수 있어요. log_request_body 설정은 모든 요청에 적용되기 때문에 벌크 수집 같은 대량 작업을 선택적으로 제외할 수는 없어요.

확장된 모든 액션 그룹 패턴과 원시 제외 패턴이 하나의 결합된 와일드카드 매처를 이뤄요. 각 감사 레이어에 대해 이 매처는 다음 표에 설명된 해당 식별자와 비교돼요. 일치하는 항목을 찾으면 감사 이벤트에서 요청 본문 필드가 생략돼요. 사용자, IP 주소, 인덱스, 타임스탬프 같은 다른 모든 필드는 그대로 유지돼요.

식별자	설명	일치 대상
Transport 액션	내부 액션 이름(예: `indices:data/write/bulk[s][p]`).	Transport 레이어 감사 이벤트.
REST 경로	HTTP 요청 경로(예: `/_bulk`). REST 경로는 항상 `/`로 시작해요.	REST 레이어 감사 이벤트.

두 식별자 모두 *를 사용한 와일드카드 패턴을 지원해요(예: indices:data/write/bulk*는 indices:data/write/bulk[s][p]와 일치해요).

액션 그룹 구성하기

액션 그룹은 opensearch.yml에 정적으로 정의되는, 액션 패턴이나 REST 경로 또는 둘 모두를 담은 이름 있는 컬렉션이에요. 그룹 이름은 직접 정하는 것이므로 운영에 의미 있는 어떤 이름이든 사용하세요:

plugins.security.audit.config.action_groups.BULK: "indices:data/write/bulk*,/_bulk"
plugins.security.audit.config.action_groups.SEARCH: "indices:data/read/search*,/_search"
plugins.security.audit.config.action_groups.INDEX_ADMIN: "indices:admin/*"

{% include copy.html %}

각 액션 그룹은 이름을 indices:data/write/bulk*, /_bulk, indices:data/write/* 같은 리터럴 또는 와일드카드 패턴의 쉼표로 구분된 목록에 매핑해요. 모든 패턴은 동일한 매처를 사용하며, :, /, * 같은 문자가 패턴을 특정 감사 레이어에 할당하지 않아요.

액션 그룹은 정적 설정이라 변경하려면 노드 재시작이 필요해요. 그룹 이름 자체는 대소문자를 구분해요.

본문 로깅 제외 구성하기

body_logging_exclusions 설정은 액션 그룹 이름이나 원시 패턴을 참조해요. 초기 제외 항목을 설정하려면 opensearch.yml에서 이 설정을 구성하세요:

plugins.security.audit.config.body_logging_exclusions:
  - BULK

{% include copy.html %}

이 설정은 동적이므로 클러스터를 재시작하지 않고도 런타임에 제외 항목을 업데이트할 수 있어요:

PUT _cluster/settings
{
  "persistent": {
    "plugins.security.audit.config.body_logging_exclusions": ["BULK", "SEARCH"]
  }
}

{% include copy.html %}

목록의 각 항목은 다음과 같이 처리돼요:

항목이 정의된 액션 그룹 이름과 일치하면 해당 그룹의 패턴이 확장돼요.
어떤 그룹 이름과도 일치하지 않으면 항목은 원시 패턴(리터럴 또는 와일드카드)으로 취급돼요.

정의된 그룹 이름과 일치하지 않는 항목의 경우, 항목에 :가 없고 /로 시작하지 않으며 *도 없으면 액션이나 REST 경로와 일치할 가능성이 낮기 때문에 경고가 로그에 기록돼요. 이 검사는 항목 어디에든 /가 있는지가 아니라 맨 앞의 /만 확인한다는 점에 유의하세요: _bulk/items 같은 항목은 /를 포함하지만 /로 시작하지 않으므로 여전히 경고가 기록돼요. 이 검사는 경고를 기록할지 여부만 결정할 뿐이며, 항목은 여전히 결합된 매처에 포함돼요.

벌크 요청

resolve_bulk_requests: true가 구성되면(개별 벌크 하위 항목 로깅), 제외 검사는 부모 벌크 액션 문자열을 사용해요. 그 결과 BULK 그룹을 제외하면 해당 벌크 요청 내의 모든 하위 항목(index, update, delete)의 본문이 생략돼요. 동일한 벌크 요청 안에서 index 항목의 본문은 유지하면서 delete 항목의 본문만 제외할 수는 없어요.

`log_request_body`와의 상호작용

본문 로깅 제외는 log_request_body가 true일 때만 적용돼요. log_request_body가 false이면 제외 구성과 관계없이 본문은 기록되지 않아요.

예제 구성

다음 구성은 세 개의 액션 그룹을 정의하고 벌크 요청의 요청 본문을 제외해요:

# opensearch.yml

# Define action groups (static, requires restart)
plugins.security.audit.config.action_groups.BULK: "indices:data/write/bulk*,/_bulk"
plugins.security.audit.config.action_groups.SEARCH: "indices:data/read/search*,/_search"
plugins.security.audit.config.action_groups.MONITORING: "cluster:monitor/*,indices:monitor/*"

# Initial exclusions (can be updated at runtime using _cluster/settings)
plugins.security.audit.config.body_logging_exclusions:
  - BULK

{% include copy.html %}

다음 표는 이 구성을 사용할 때 요청 유형별로 요청 본문이 기록되는지를 설명해요.

요청 유형	요청 본문 기록 여부
벌크 쓰기	아니요, `BULK` 그룹이 제외되기 때문이에요.
검색	네.
인덱스 생성	네.
모니터링	네, 제외 항목에 `MONITORING`을 추가하지 않는 한 기록돼요.

런타임에 검색 제외를 추가하려면 다음 요청을 보내세요:

PUT _cluster/settings
{
  "persistent": {
    "plugins.security.audit.config.body_logging_exclusions": ["BULK", "SEARCH"]
  }
}

{% include copy.html %}

모든 제외 항목을 지우려면(모든 본문 로깅 재개):

PUT _cluster/settings
{
  "persistent": {
    "plugins.security.audit.config.body_logging_exclusions": []
  }
}

{% include copy.html %}

Log4j MDC 라우팅

log4j 감사 싱크를 사용할 때는 Mapped Diagnostic Context(MDC) 라우팅을 활성화해서 Log4j가 이벤트 속성에 따라 감사 이벤트를 서로 다른 애펜더로 라우팅하게 하세요:

plugins.security.audit.config.log4j.enable_mdc_routing: true

{% include copy.html %}

활성화하면 각 감사 이벤트에 다음 MDC 키가 설정돼요:

audit_category --- 감사 이벤트 카테고리(예: REQUEST_AUDIT 또는 GRANTED_PRIVILEGES)
audit_action --- 액션 이름
audit_user --- 유효 사용자
audit_request_type --- 요청 유형

log4j2.properties에서 Log4j 라우팅 애펜더를 사용하면 카테고리, 사용자 또는 그 외 다른 MDC 키별로 감사 로그를 분리할 수 있어요.

이 설정은 정적이라 노드 재시작이 필요해요. {: .note}

감사 로그 인덱스 이름 구성하기

기본적으로 Security 플러그인은 security-auditlog-YYYY.MM.dd라는 이름의 일일 롤링 인덱스에 감사 이벤트를 저장해요:

plugins.security.audit.config.index: myauditlogindex

{% include copy.html %}

인덱스 이름에 날짜 패턴을 사용하면 일일, 주간, 월간 롤링 인덱스를 구성할 수 있어요:

plugins.security.audit.config.index: "'auditlog-'YYYY.MM.dd"

{% include copy.html %}

날짜 패턴 형식에 대한 참고 자료는 Joda DateTimeFormat 문서를 확인하세요.

(고급) 스레드 풀 튜닝하기

Search 플러그인은 이벤트를 비동기적으로 기록해서 클러스터에 미치는 성능 영향을 최소화해요. 플러그인은 이벤트를 기록하기 위해 고정 스레드 풀을 사용해요:

plugins.security.audit.config.threadpool.size: <integer>

{% include copy.html %}

기본 설정은 10이에요. 이 값을 0으로 설정하면 스레드 풀이 비활성화되어 플러그인이 이벤트를 동기적으로 기록해요. 스레드별 최대 큐 길이를 설정하려면:

plugins.security.audit.config.threadpool.max_queue_len: 100000

{% include copy.html %}

감사 로그 비활성화

감사 로그를 활성화한 후에 비활성화하려면 opensearch.yml에서 plugins.security.audit.type: internal_opensearch 설정을 제거하거나, OpenSearch Dashboards에서 Enable audit logging 체크박스를 끄면 돼요. Cluster Settings API로 설정하는 plugins.security.audit.enabled 런타임 토글은 독립형(standalone) 감사 로깅에만 적용돼요. 설정 방법은 독립형 감사 로깅 문서를 참고하세요.

사용자 계정 조작 감사

역할 매핑 변경이나 역할 생성·삭제 같은 보안 인덱스에 대한 변경에 감사 로깅을 활성화하려면, 다음 예시처럼 감사 로그 설정의 compliance: 부분에 아래 설정을 사용해요.

_meta:
  type: "audit"
  config_version: 2

config:
  # enable/disable audit logging
  enabled: true

  ...


  compliance:
    # enable/disable compliance
    enabled: true

    # Log updates to internal security changes
    internal_config: true

    # Log only metadata of the document for write events
    write_metadata_only: false

    # Log only diffs for document updates
    write_log_diffs: true

    # List of indices to watch for write events. Wildcard patterns are supported
    # write_watched_indices: ["twitter", "logs-*"]
    write_watched_indices: [".opendistro_security"]

{% include copy.html %}

더 알아보기 (Learn more)

원문 전체: https://docs.opensearch.org/latest/security/audit-logs/index/

Audit logs

본문

감사 로그

감사 로깅 활성화하기(standard 모드)

추적되는 이벤트

감사 로그 설정

audit.yml의 설정

카테고리 제외하기

REST 또는 transport 레이어 비활성화하기

요청 본문 로깅 비활성화하기

인덱스 이름 로깅하기

벌크 요청 처리 구성하기

요청 제외하기

사용자 제외하기

헤더 제외하기

opensearch.yml의 설정

카테고리 제외하기

본문 로깅 제외

액션 그룹 구성하기

본문 로깅 제외 구성하기

벌크 요청

log_request_body와의 상호작용

예제 구성

Log4j MDC 라우팅

감사 로그 인덱스 이름 구성하기

(고급) 스레드 풀 튜닝하기

감사 로그 비활성화

사용자 계정 조작 감사

더 알아보기 (Learn more)

함께 읽는 실무 이야기

`log_request_body`와의 상호작용