翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon OpenSearch Service での監査ログのモニタリング
Amazon OpenSearch Service ドメインできめ細かなアクセスコントロールを使用する場合、データの監査ログを有効にすることができます。監査ログは高度にカスタマイズ可能で、認証の成功と失敗、OpenSearch へのリクエスト、インデックスの変更、受信検索クエリなど、OpenSearch クラスターでのユーザーアクティビティを追跡できます。デフォルトの設定では、一般的な一連のユーザーアクションが追跡されますが、正確なニーズに合わせて設定を調整することをお勧めします。
OpenSearch アプリケーションログおよびスローログのように、OpenSearch Service は CloudWatch Logs に監査ログを発行します。有効にすると、標準の CloudWatch 料金
注記
監査ログを有効にするには、ユーザーロールが security_manager
ロールにマッピングされる必要があり、これにより、OpenSearch plugins/_security
REST APIへのアクセス権が提供されます。詳細については、「マスターユーザーの変更」を参照してください。
トピック
制限
監査ログには以下の制限事項があります。
-
監査ログには、送信先のドメインアクセスポリシーによって拒否されたクロスクラスター検索リクエストは含まれません。
-
各監査ログメッセージの最大サイズは 10,000 文字です。この制限を超えると、監査ログメッセージが切り捨てられます。
監査ログ記録の有効化
監査ログの有効化は、2 段階のプロセスです。まず、CloudWatch Logs に CloudWatch Logs に監査ログを発行するようにドメインを設定します。次に、OpenSearch Dashboards で監査ログを有効にして、ニーズを満たすように監査ログを設定します。
重要
これらの手順の実行中にエラーが発生した場合、トラブルシューティング情報については、監査ログを有効にできない を参照してください。
ステップ 1: 監査ログを有効にし、アクセスポリシーを設定する
次の手順では、コンソールを使用して監査ログを有効にする方法について説明します。または OpenSearch Service API を使用して有効に AWS CLIすることもできます。
OpenSearch Service ドメインの監査ログを有効にするには (コンソール)
-
ドメインを選択して設定を開き、[ログ] タブに移動します。
-
[監査ログ] を選択してから、[有効化] を選択します。
-
CloudWatch ロググループを作成するか、既存のロググループを選択します。
-
適切なアクセス権限を含むアクセスポリシーを選択するか、コンソールに用意された JSON を使用してポリシーを作成します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "es.amazonaws.com" }, "Action": [ "logs:PutLogEvents", "logs:CreateLogStream" ], "Resource": "
cw_log_group_arn
" } ] }Confused Deputy Problem (混乱した代理の問題) から自分を守るために、
aws:SourceAccount
およびaws:SourceArn
の条件キーをポリシーに追加することをお勧めします。ソースアカウントはドメインの所有者であり、ソース ARN はドメインの ARN です。これらの条件キーを追加するには、ドメインがサービスソフトウェア R20211203 以降にある必要があります。例えば、次の条件ブロックをポリシーに追加できます。
"Condition": { "StringEquals": { "aws:SourceAccount": "
account-id
" }, "ArnLike": { "aws:SourceArn": "arn:aws:es:region
:account-id
:domain/domain-name
" } } -
[有効化] を選択します。
ステップ 2: OpenSearch Dashboards で、監査ログを有効にする
OpenSearch Service コンソールで監査ログを有効にした後、OpenSearch Dashboards でも有効にして、ニーズを満たすように設定する必要があります。
-
OpenSearch Dashboards を開き、左側のサイドメニューから [セキュリティ] を選択します。
-
[監査ログ] を選択します。
-
[監査ログ作成を有効にする] を選択します。
Dashboards UI には、[全般設定] および [コンプライアンス設定] の下で、監査ログの設定の完全なコントロールが用意されています。すべての設定オプションの説明については、「監査ログの設定」を参照してください。
を使用して監査ログ記録を有効にする AWS CLI
次の AWS CLI コマンドは、既存のドメインの監査ログを有効にします。
aws opensearch update-domain-config --domain-name
my-domain
--log-publishing-options "AUDIT_LOGS={CloudWatchLogsLogGroupArn=arn:aws:logs:us-east-1:123456789012:log-group:my-log-group
,Enabled=true}"
ドメインを作成するときに、監査ログを有効にすることもできます。詳細については、「AWS CLI コマンドのリファレンス」を参照してください。
設定 API を使用して監査ログを有効にする
次の設定 API へのリクエストにより、既存のドメインで監査ログが有効になります。
POST https://es.us-east-1.amazonaws.com/2021-01-01/opensearch/domain/
my-domain
/config { "LogPublishingOptions": { "AUDIT_LOGS": { "CloudWatchLogsLogGroupArn":"arn:aws:logs:us-east-1
:123456789012
:log-group1:sample-domain", "Enabled":true } } }
詳細については、「Amazon OpenSearch Service API reference」(Amazon OpenSearch Service API リファレンス) を参照してください。
監査ログのレイヤーとカテゴリ
クラスターコミュニケーションは、2 つの別々のレイヤーを介して行われます: RESTレイヤーとトランスポートレイヤー。
-
REST レイヤーは、curl、Logstash、OpenSearch Dashboards、Java 高レベル REST クライアント、Python Requests
ライブラリなどの HTTP クライアントとの通信 (クラスターに到達する HTTP リクエスト) を対象としています。 -
トランスポートレイヤーは、ノード間のコミュニケーションを対象としています。例えば、検索リクエストが(REST レイヤーを介して)クラスターに到着した後、リクエストを処理する調整ノードは、クエリを他のノードに送信し、そのレスポンスを受け取り、必要なドキュメントを収集し、それらを最終的なレスポンスと照合します。シャード割り当てや再分散などのオペレーションは、トランスポートレイヤーでも実行されます。
レイヤー全体の監査ログと、レイヤーの個々の監査カテゴリを有効または無効にできます。次の表に、監査カテゴリの概要と、監査カテゴリが使用可能なレイヤーを示します。
カテゴリ | 説明 | REST で利用可能 | トランスポートで利用可能 |
---|---|---|---|
FAILED_LOGIN |
リクエストに無効な資格情報が含まれ、認証に失敗しました。 | あり | あり |
MISSING_PRIVILEGES |
ユーザーには、リクエストを行う権限がありませんでした。 | あり | あり |
GRANTED_PRIVILEGES |
ユーザーには、リクエストを行う権限がありました。 | あり | あり |
OPENSEARCH_SECURITY_INDEX_ATTEMPT |
リクエストが .opendistro_security インデックスを修正しようとしました。 |
いいえ | はい |
AUTHENTICATED |
リクエストに有効な認証情報が含まれ、認証に成功しました。 | あり | あり |
INDEX_EVENT |
リクエストは、インデックスの作成、エイリアスの設定、強制マージの実行など、インデックスの管理オペレーションを実行しました。このカテゴリに含まれる indices:admin/ アクションの完全なリストは、OpenSearch ドキュメント |
いいえ | はい |
これらの標準カテゴリに加えて、きめ細かなアクセスコントロールには、データコンプライアンス要件を満たすように設計されたいくつかの追加カテゴリが用意されています。
カテゴリ | 説明 |
---|---|
COMPLIANCE_DOC_READ |
リクエストは、インデックス内のドキュメントに対して読み取りイベントを実行しました。 |
COMPLIANCE_DOC_WRITE |
リクエストは、インデックス内のドキュメントに対して書き込みイベントを実行しました。 |
COMPLIANCE_INTERNAL_CONFIG_READ |
リクエストは、 |
COMPLIANCE_INTERNAL_CONFIG_WRITE |
リクエストは、 |
カテゴリおよびメッセージ属性の任意の組み合わせを指定できます。例えば、REST リクエストを送信してドキュメントのインデックスを作成すると、監査ログに次の行が表示されることがあります。
-
REST レイヤーで AUTHENTICATED (認証)
-
トランスポートレイヤーで GRANTED_PREVIEWE (認可)
-
COMPLIANCE_DOC_WRITE (インデックスに書き込まれたドキュメント)
監査ログの設定
監査ログには、多数の設定オプションがあります。
全般設定
全般設定では、個々のカテゴリまたはレイヤー全体を有効または無効にできます。除外カテゴリとして GRANTED_Privileges および Authenticated を残すことを強くお勧めします。それ以外の場合、これらのカテゴリは、クラスターへの有効なリクエストごとにログされます。
名前 | バックエンドの設定 | 説明 |
---|---|---|
REST レイヤー |
enable_rest |
REST レイヤーで発生するイベントを有効または無効にします。 |
REST 無効なカテゴリ |
disabled_rest_categories |
REST レイヤーで無視する監査カテゴリを指定します。これらのカテゴリを変更すると、監査ログのサイズが大幅に増加する可能性があります。 |
トランスポートレイヤー |
enable_transport |
トランスポートレイヤーで発生するイベントを有効または無効にします。 |
トランスポート無効なカテゴリ |
disabled_transport_categories |
トランスポートレイヤーで無視する必要がある監査カテゴリを指定します。これらのカテゴリを変更すると、監査ログのサイズが大幅に増加する可能性があります。 |
属性設定では、各ログ行の詳細量をカスタマイズできます。
名前 | バックエンドの設定 | 説明 |
---|---|---|
一括リクエスト |
resolve_bulk_requests |
この設定を有効にすると、一括要求でドキュメントごとにログが生成されます。これにより、監査ログのサイズが大幅に増加する可能性があります。 |
リクエスト本文 |
log_request_body |
リクエストのリクエストボディを含めます。 |
インデックスの解決 |
resolve_indices |
インデックスに対してエイリアスを解決します。 |
無視設定を使用して、一連のユーザーまたは API パスを除外します。
名前 | バックエンドの設定 | 説明 |
---|---|---|
無視されたユーザー |
ignore_users |
除外するユーザーを指定します。 |
無視されたリクエスト |
ignore_requests |
除外するリクエストパターンを指定します。 |
コンプライアンス設定
コンプライアンス設定では、インデックス、ドキュメント、またはフィールドレベルのアクセスを調整できます。
名前 | バックエンドの設定 | 説明 |
---|---|---|
コンプライアンスのロギング |
enable_compliance |
コンプライアンスのロギングを有効または無効にします。 |
読み取りおよび書き込みイベントのロギングには以下の設定を指定できます。
名前 | バックエンドの設定 | 説明 |
---|---|---|
内部設定のロギング |
internal_config |
|
読み取りイベントには以下の設定を指定できます。
名前 | バックエンドの設定 | 説明 |
---|---|---|
メタデータの読み取り |
read_metadata_only |
読み取りイベントのメタデータのみを含めます。ドキュメントフィールドを含めないでください。 |
無視されたユーザー |
read_ignore_users |
読み取りイベントには特定のユーザーを含めないでください。 |
監視するフィールド |
read_watched_fields |
読み取りイベントを監視するインデックスとフィールドを指定します。監視するフィールドを追加すると、ドキュメントアクセスごとに 1 つのログが生成されます。これにより、監査ログのサイズが大幅に増加する可能性があります。監視するフィールドは、インデックスパターンとフィールドパターンをサポートします。
|
書き込みイベントには以下の設定を指定できます。
名前 | バックエンドの設定 | 説明 |
---|---|---|
メタデータの書き込み |
write_metadata_only |
書き込みイベントのメタデータのみを含めます。ドキュメントフィールドを含めないでください。 |
差分のログ |
write_log_diffs |
write_metadata_only が false の場合は、書き込みイベント間の違いのみを含めます。 |
無視されたユーザー |
write_ignore_users |
書き込みイベントには特定のユーザーを含めないでください。 |
インデックスの監視 |
write_watched_indices |
書き込みイベントを監視するインデックスまたはインデックスパターンを指定します。監視するフィールドを追加すると、ドキュメントアクセスごとに 1 つのログが生成されます。これにより、監査ログのサイズが大幅に増加する可能性があります。 |
監査ログの例
このセクションには、設定例、検索リクエスト、およびインデックスのすべての読み取りおよび書き込みイベントの結果となる監査ログが含まれます。
ステップ 1: 監査ログを設定する
CloudWatch Logs グループへの監査ログの公開を有効にした後、OpenSearch Dashboards の監査ロギングページに移動し、[監査ロギングを有効にする] を選択します。
-
[全般設定] で、[設定] を選択し、[REST レイヤー] が有効であることを確認します。
-
[コンプライアンス設定] で、[設定] を選択します。
-
[書き込み] の下で、[監視フィールド] に、追加このインデックスへのすべての書き込みイベントのために
accounts
を追加します。 -
[読み取り] の下で、[監視フィールド] に、
accounts
インデックスのssn
およびid-
フィールドを追加します。{ "accounts-": [ "ssn", "id-" ] }
ステップ 2: 読み取りイベントと書き込みイベントを実行する
-
OpenSearch Dashboards に移動し、[デベロッパーツール] を選択し、サンプルドキュメントのインデックスを作成します。
PUT accounts/_doc/0 { "ssn": "123", "id-": "456" }
-
読み取りイベントをテストするには、次のリクエストを送信します。
GET accounts/_search { "query": { "match_all": {} } }
ステップ 3: ログを確認する
-
CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/
) を開きます。 -
ナビゲーションペインで、[Log groups] (ロググループ) を選択します。
-
監査ログを有効にするときに指定したロググループを選択します。ロググループ内で、OpenSearch Service はドメイン内の各ノードのログストリームを作成します。
-
[ログストリーム] で、[すべて検索] を選択します。
-
読み取りおよび書き込みイベントについては、対応するログを参照してください。ログが表示される前に、5 秒の遅延が予想されます。
監査ログの書き込みの例
{ "audit_compliance_operation": "CREATE", "audit_cluster_name": "824471164578:audit-test", "audit_node_name": "be217225a0b77c2bd76147d3ed3ff83c", "audit_category": "COMPLIANCE_DOC_WRITE", "audit_request_origin": "REST", "audit_compliance_doc_version": 1, "audit_node_id": "3xNJhm4XS_yTzEgDWcGRjA", "@timestamp": "2020-08-23T05:28:02.285+00:00", "audit_format_version": 4, "audit_request_remote_address": "3.236.145.227", "audit_trace_doc_id": "lxnJGXQBqZSlDB91r_uZ", "audit_request_effective_user": "admin", "audit_trace_shard_id": 8, "audit_trace_indices": [ "accounts" ], "audit_trace_resolved_indices": [ "accounts" ] }
監査ログの読み取りの例
{ "audit_cluster_name": "824471164578:audit-docs", "audit_node_name": "806f6050cb45437e2401b07534a1452f", "audit_category": "COMPLIANCE_DOC_READ", "audit_request_origin": "REST", "audit_node_id": "saSevm9ASte0-pjAtYi2UA", "@timestamp": "2020-08-31T17:57:05.015+00:00", "audit_format_version": 4, "audit_request_remote_address": "54.240.197.228", "audit_trace_doc_id": "config:7.7.0", "audit_request_effective_user": "admin", "audit_trace_shard_id": 0, "audit_trace_indices": [ "accounts" ], "audit_trace_resolved_indices": [ "accounts" ] }
リクエストボディを含めるには、OpenSearch Dashboards の [コンプライアンス設定] に戻り、[メタデータの書き込み] を無効にします。特定のユーザーによるイベントを除外するには、そのユーザーを [無視されたユーザー] に追加します。
各監査ログフィールドの説明については、「監査ログフィールドのリファレンス
REST API を使用した監査ログの設定
OpenSearch Dashboards を使用して監査ログを設定することをお勧めしますが、きめ細かなアクセスコントロールの REST API を使用することもできます。このセクションには、リクエストの例が含まれています。REST API に関する完全なドキュメントは、OpenSearch ドキュメント
PUT _opendistro/_security/api/audit/config { "enabled": true, "audit": { "enable_rest": true, "disabled_rest_categories": [ "GRANTED_PRIVILEGES", "AUTHENTICATED" ], "enable_transport": true, "disabled_transport_categories": [ "GRANTED_PRIVILEGES", "AUTHENTICATED" ], "resolve_bulk_requests": true, "log_request_body": true, "resolve_indices": true, "exclude_sensitive_headers": true, "ignore_users": [ "kibanaserver" ], "ignore_requests": [ "SearchRequest", "indices:data/read/*", "/_cluster/health" ] }, "compliance": { "enabled": true, "internal_config": true, "external_config": false, "read_metadata_only": true, "read_watched_fields": { "read-index-1": [ "field-1", "field-2" ], "read-index-2": [ "field-3" ] }, "read_ignore_users": [ "read-ignore-1" ], "write_metadata_only": true, "write_log_diffs": false, "write_watched_indices": [ "write-index-1", "write-index-2", "log-*", "*" ], "write_ignore_users": [ "write-ignore-1" ] } }