翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon DocumentDB イベントの監査
Amazon DocumentDB (MongoDB の互換性あり) を使用すると、クラスター内で実行されたイベントを監査できます。ログに記録されるイベントの例としては、認証の成功と失敗、データベース内のコレクションの削除、インデックスの作成などがあります。Amazon DocumentDB ではデフォルトで監査が無効になっているため、この機能を選択して使用する必要があります。
監査が有効な場合、Amazon DocumentDB はデータ定義言語 (DDL)、データ操作言語 (DML)、認証、認可、およびユーザー管理イベントを Amazon CloudWatch Logs に記録します。監査が有効な場合、Amazon DocumentDB はクラスターの監査レコード (JSON ドキュメント) を Amazon CloudWatch Logs にエクスポートします。Amazon CloudWatch Logs を使用すると、Amazon DocumentDB 監査イベントを分析、モニタリング、およびアーカイブすることができます。
Amazon DocumentDB では監査を有効にしても追加料金は発生しませんが、CloudWatch Logs の使用には標準料金がかかります。CloudWatch Logs の料金の詳細については、[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/) をご覧ください。
Amazon DocumentDB 監査機能は、モニタリング対象のサービスリソースの使用状況とは明確に異なります AWS CloudTrail。CloudTrail は、 AWS Command Line Interface (AWS CLI) またはクラスター、インスタンス、パラメータグループ、スナップショットなどのリソース AWS マネジメントコンソール で実行されるオペレーションを記録します。CloudTrailを使用した リソースの監査はデフォルトで有効化され、無効にすることはできません。Amazon DocumentDB 監査機能は、オプトイン機能です。これによって、オブジェクト (データベース、コレクション、インデックスやユーザーなど) のクラスター内で発生したオペレーションが記録されます。
**Topics**
+ [サポートされるイベント](#auditing-events)
+ [監査の有効化](#event-auditing-enabling-auditing)
+ [監査の無効化](#event-auditing-disabling-auditing)
+ [監査イベントへのアクセス](#event-auditing-accessing)
+ [DML 監査イベントのフィルタリング](#filtering-dml-events)
## サポートされるイベント
Amazon DocumentDB 監査は、以下のカテゴリのイベントをサポートしています。
+ **データ定義言語 (DDL)**- データベースの管理操作、接続、ユーザー管理、認可が含まれます。
+ **データ操作言語読み取りイベント (DML 読み取り)** - `find()`、 およびさまざまな集計演算子、算術演算子、ブール演算子、およびその他の読み取りクエリ演算子が対象になります。
+ **データ操作言語書き込みイベント (DML 書き込み)** - `insert(), update(), delete(),` および `bulkWrite()` 演算子が対象になります。
イベントタイプは次のとおりです。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/documentdb/latest/developerguide/event-auditing.html)
**注記**
DML イベントドキュメントパラメータフィールドの値には 1 KB のサイズ制限があります。サイズが 1 KB を超えると、Amazon DocumentDB 値は切り捨てられます。
**注記**
現時点では、TTL 削除イベントは監査されません。
## 監査の有効化
クラスターでの監査の有効化は、2 ステップのプロセスです。両方のステップが完了していることを確認してください。完了していない場合、監査ログは CloudWatch Logs に送信されません。
### ステップ 1. audit\$1logs クラスターパラメータを有効にする
監査を有効にするには、パラメータグループの `audit_logs` パラメータを変更する必要があります。`audit_logs` は記録するイベントのカンマ区切りのリストです。イベントはすべて小文字で指定する必要があります。リスト要素間に空白があってはいけません。
パラメータには以下の値を指定できます。
| 値 | 説明 |
| --- | --- |
| ddl | 設定すると、createDatabase、dropDatabase、createCollection、dropCollection、createIndex、dropIndex、authCheck、authenticate、createUser、dropUser、grantRolesToUser、revokeRolesFromUser、updateUser、dropAllUsersFromDatabase などの DDL イベントの監査が有効になります |
| dml\$1read | 設定すると、find、sort count、distinct、group、projecta、unwind、geoNear、geoIntersects、geoWithin、その他の MongoDB 読み取りクエリ演算子などの DML 読み取りイベントの監査が有効になります。 |
| dml\$1write | 設定すると、insert()、update()、delete()、bulkWrite() などの DML 書き込みイベントの監査が有効になります。 |
| all | 設定すると、読み取りクエリ、書き込みクエリ、データベースアクション、管理者アクションなどのデータベースイベントの監査が有効になります。 |
| none | 設定すると、監査が無効になります |
| enabled (レガシー) | これは「ddl」と同等のレガシーパラメータ設定です。設定すると、createDatabase、dropDatabase、createCollection、dropCollection、createIndex、dropIndex、authCheck、authenticate、createUser、dropUser、grantRolesToUser、revokeRolesFromUser、updateUser、dropAllUsersFromDatabase などの DDL イベントの監査が有効になります。レガシー設定であるため、この設定の使用はお勧めしません。 |
| disabled (レガシー) | これは「なし」と同等のレガシーパラメータ設定です。レガシー設定であるため、この設定の使用はお勧めしません。 |
**注記**
audit\$1logs クラスターパラメーターのデフォルト値は `none` (レガシー「`disabled`」) です。
上記の値を組み合わせて使用することもできます。
| 値 | 説明 |
| --- | --- |
| ddl, dml\$1read | 設定すると、DDL イベントと DML 読み取りイベントの監査が有効になります。 |
| ddl, dml\$1write | 設定すると、DDL イベントと DML 書き込みイベントの監査が有効になります。 |
| dml\$1read, dml\$1write | 設定すると、すべての DML イベントの監査が有効になります。 |
**注記**
デフォルトのパラメータグループを変更することはできません。
詳細については次を参照してください:
+ [Amazon DocumentDB クラスターパラメータグループを作成する](cluster_parameter_groups-create.md)
カスタムパラメータグループを作成したら、`audit_logs` パラメータ値を `all` に変更します。
+ [Amazon DocumentDB クラスターパラメータグループを変更する](cluster_parameter_groups-modify.md)
### ステップ 2. Amazon CloudWatch Logs のエクスポートを有効にする
`audit_logs` クラスターパラメータの値が `enabled` か `ddl`、`dml_read`、`dml_write` のいずれかの場合、Amazon DocumentDB がログを Amazon CloudWatch にエクスポートできるようにする必要があります。上述の手順のいずれかを省略すると、監査ログは CloudWatch に送信されません。
クラスターを作成するときにポイントインタイムリストアまたはスナップショットの復元を実行する場合、以下のステップで CloudWatch Logs を有効にすることができます。
------
#### [ Using the AWS マネジメントコンソール ]
コンソールを使用して Amazon DocumentDB へのログを CloudWatch にエクスポートすることを有効にするには、次のトピックを参照してください。
+ **クラスターを作成する場合** - [を使用したクラスターとプライマリインスタンスの作成 AWS マネジメントコンソール](db-cluster-create.md#db-cluster-create-con) の「**クラスターを作成する: 追加の設定** (ステップ 5、[**ログのエクスポート**])」を参照してください。
+ **既存のクラスターを変更する場合** - [Amazon DocumentDB クラスターの変更](db-cluster-modify.md)
+ **クラスタースナップショットリストアを実行する場合** - [クラスタースナップショットからの復元](backup_restore-restore_from_snapshot.md)
+ **ポイントインタイムリストアを実行する場合** - [特定時点への復元](backup_restore-point_in_time_recovery.md)
------
#### [ Using the AWS CLI ]
**新しいクラスターの作成時に監査ログを有効にするには**
次のコードでは、クラスター `sample-cluster` を作成し、CloudWatch 監査ログを有効にします。
**Example**
Linux、macOS、Unix の場合:
```
aws docdb create-db-cluster \
--db-cluster-identifier sample-cluster \
--port 27017 \
--engine docdb \
--master-username master-username \
--master-user-password password \
--db-subnet-group-name default \
--enable-cloudwatch-logs-exports audit
```
Windows の場合:
```
aws docdb create-db-cluster ^
--db-cluster-identifier sample-cluster ^
--port 27017 ^
--engine docdb ^
--master-username master-username ^
--master-user-password password ^
--db-subnet-group-name default ^
--enable-cloudwatch-logs-exports audit
```
**既存のクラスターを変更するときに監査ログを有効にするには**
次のコードでは、クラスター `sample-cluster` を変更し、CloudWatch 監査ログを有効にします。
**Example**
Linux、macOS、Unix の場合:
```
aws docdb modify-db-cluster \
--db-cluster-identifier sample-cluster \
--cloudwatch-logs-export-configuration '{"EnableLogTypes":["audit"]}'
```
Windows の場合:
```
aws docdb modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--cloudwatch-logs-export-configuration '{"EnableLogTypes":["audit"]}'
```
これらのオペレーションによる出力は、次のようになります (JSON 形式)。
```
{
"DBCluster": {
"HostedZoneId": "ZNKXH85TT8WVW",
"StorageEncrypted": false,
"DBClusterParameterGroup": "default.docdb4.0",
"MasterUsername": "",
"BackupRetentionPeriod": 1,
"Port": 27017,
"VpcSecurityGroups": [
{
"Status": "active",
"VpcSecurityGroupId": "sg-77186e0d"
}
],
"DBClusterArn": "arn:aws:rds:us-east-1:900083794985:cluster:sample-cluster",
"Status": "creating",
"Engine": "docdb",
"EngineVersion": "4.0.0",
"MultiAZ": false,
"AvailabilityZones": [
"us-east-1a",
"us-east-1c",
"us-east-1f"
],
"DBSubnetGroup": "default",
"DBClusterMembers": [],
"ReaderEndpoint": "sample-cluster.cluster-ro-corcjozrlsfc.us-east-1.docdb.amazonaws.com",
"EnabledCloudwatchLogsExports": [
"audit"
],
"PreferredMaintenanceWindow": "wed:03:08-wed:03:38",
"AssociatedRoles": [],
"ClusterCreateTime": "2019-02-13T16:35:04.756Z",
"DbClusterResourceId": "cluster-YOS52CUXGDTNKDQ7DH72I4LED4",
"Endpoint": "sample-cluster.cluster-corcjozrlsfc.us-east-1.docdb.amazonaws.com",
"PreferredBackupWindow": "07:16-07:46",
"DBClusterIdentifier": "sample-cluster"
}
}
```
------
## 監査の無効化
CloudWatch Logs のエクスポートを無効にし、`audit_logs` パラメータを無効にすることで、監査を無効にすることができます。
### CloudWatch Logs のエクスポートの無効化
監査ログのエクスポートは、 AWS マネジメントコンソール または を使用して無効にできます AWS CLI。
------
#### [ Using the AWS マネジメントコンソール ]
次の手順では、 を使用して AWS マネジメントコンソール Amazon DocumentDB の CloudWatch へのログのエクスポートを無効にします。
**監査ログを無効にするには**
1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/docdb](https://console.aws.amazon.com/docdb) で Amazon DocumentDB コンソールを開きます。
1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。ログのエクスポートを無効にするクラスターの名前の左側にあるボタンを選択します。
1. [**アクション**] を選択してから、[**変更**] を選択します。
1. [**ログのエクスポート**] セクションまで下にスクロールし、[**無効**] を選択します。
1. [**続行**] をクリックしてください。
1. 変更を確認してから、この変更をクラスターにいつ適用するかを選択します。
+ **Apply during the next scheduled maintenance window (次に予定されているメンテナンス期間中に適用)**
+ **すぐに適用**
1. **[クラスターを変更]** を選択します。
------
#### [ Using the AWS CLI ]
次のコードでは、クラスター `sample-cluster` を変更し、CloudWatch 監査ログを無効にします。
**Example**
Linux、macOS、Unix の場合:
```
aws docdb modify-db-cluster \
--db-cluster-identifier sample-cluster \
--cloudwatch-logs-export-configuration '{"DisableLogTypes":["audit"]}'
```
Windows の場合:
```
aws docdb modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--cloudwatch-logs-export-configuration '{"DisableLogTypes":["audit"]}'
```
このオペレーションによる出力は、次のようになります (JSON 形式)。
```
{
"DBCluster": {
"DBClusterParameterGroup": "default.docdb4.0",
"HostedZoneId": "ZNKXH85TT8WVW",
"MasterUsername": "",
"Status": "available",
"Engine": "docdb",
"Port": 27017,
"AvailabilityZones": [
"us-east-1a",
"us-east-1c",
"us-east-1f"
],
"EarliestRestorableTime": "2019-02-13T16:35:50.387Z",
"DBSubnetGroup": "default",
"LatestRestorableTime": "2019-02-13T16:35:50.387Z",
"DBClusterArn": "arn:aws:rds:us-east-1:900083794985:cluster:sample-cluster2",
"Endpoint": "sample-cluster2.cluster-corcjozrlsfc.us-east-1.docdb.amazonaws.com",
"ReaderEndpoint": "sample-cluster2.cluster-ro-corcjozrlsfc.us-east-1.docdb.amazonaws.com",
"BackupRetentionPeriod": 1,
"EngineVersion": "4.0.0",
"MultiAZ": false,
"ClusterCreateTime": "2019-02-13T16:35:04.756Z",
"DBClusterIdentifier": "sample-cluster2",
"AssociatedRoles": [],
"PreferredBackupWindow": "07:16-07:46",
"DbClusterResourceId": "cluster-YOS52CUXGDTNKDQ7DH72I4LED4",
"StorageEncrypted": false,
"PreferredMaintenanceWindow": "wed:03:08-wed:03:38",
"DBClusterMembers": [],
"VpcSecurityGroups": [
{
"Status": "active",
"VpcSecurityGroupId": "sg-77186e0d"
}
]
}
}
```
------
### audit\$1logs パラメータを無効にする
クラスターの `audit_logs` パラメータを無効にするには、`audit_logs` パラメータ値が `disabled` であるパラメータグループを使用するようにクラスターを変更します。または、クラスターの `audit_logs` パラメータグループのパラメータ値を `disabled` に変更することもできます。
詳細については、以下の各トピックを参照してください。
+ [Amazon DocumentDB クラスターの変更](db-cluster-modify.md)
+ [Amazon DocumentDB クラスターパラメータグループを変更する](cluster_parameter_groups-modify.md)
## 監査イベントへのアクセス
Amazon CloudWatch の監査イベントにアクセスするには、以下のステップを実行してください。
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. Amazon DocumentDB クラスターと同じリージョンであることを確認します。
1. ナビゲーションペインで [**ログ**] を選択します。
1. クラスターの監査ログを確認するため、リストから **/aws/docdb/*yourClusterName*/audit** を見つけ出して選択します。
各インスタンスの監査イベントは、各インスタンス名の下に表示されます。
## DML 監査イベントのフィルタリング
### DML 監査フィルタリングの開始方法
DML 監査イベントは、Amazon CloudWatch への書き込み前にフィルタリングできます。この機能を使用するには、監査ログと DML ログ記録を有効にする必要があります。Amazon DocumentDB は、`atype`、`command`、`user`、`namespace`、`auditAuthorizationSuccess` でのフィルタリングをサポートしています。
**注記**
DDL イベントはフィルタリングされません。
`db.adminCommand( { command } )` オペレーションの `setAuditConfig`、`filter`、`auditAuthorizationSuccess` パラメータを使用して監査フィルターを指定することで、いつでも監査フィルタリングを有効にできます。
```
db.admin.runCommand(
{
setAuditConfig: 1,
filter:
{
//filter conditions
},
auditAuthorizationSuccess: true | false
}
)
```
次のコマンドを実行して、監査フィルター設定を取得することもできます。
```
db.admin.runCommand( { getAuditConfig: 1})
```
**セキュリティ要件**
DML 監査フィルターを設定または一覧表示する際に `admindb` に対して上記のコマンドを実行できるのは、特権アクション `auditConfigure` を持つデータベースユーザー/ロールのみです。[`clusterAdmin`、`hostManager`、`root`] の組み込みロールのいずれかを使用するか、あるいは `auditConfigure` 権限を持つカスタムロールを作成できます。以下は、`auditConfigure` 権限で既存のロールを使用する例と、カスタムロールを使用する例です。
ロールが組み込まれているユーザー:
```
use admin
db.createUser(
{
user: "myClusterAdmin",
pwd: "password123",
roles: [ { role: "clusterAdmin", db: "admin" } ]
}
)
```
カスタムロールを持つユーザー:
```
use admin
db.createRole(
{
role: "myRole",
privileges: [
{ resource: { cluster: true }, actions: [ "auditConfigure" ] }
],
roles: []
}
)
db.createUser(
{
user: "myUser",
pwd: "myPassword",
roles: [ { role: "myRole", db: "admin" } ]
}
)
```
#### ユースケースのフィルタリング
**例: コマンドによるイベントのフィルタリング**
```
db.admin.runCommand(
{
setAuditConfig: 1,
filter: {
"$and": [
{
"param.command":
{
$in: [ "find","count", "insert", "delete", "update", "findandmodify" ]
}
}
]
},
auditAuthorizationSuccess: true
}
)
```
**例: ユーザー名によるイベントのフィルタリング**
この例では、ユーザー「myUser」のみがログに記録されます。
```
db.admin.runCommand(
{
setAuditConfig: 1,
filter: {
"$and": [
{
"param.user":
{
$in: [ "myUser" ]
}
}
]},
auditAuthorizationSuccess: true})
```
**例: `atype` によるフィルタリング**
```
db.admin.runCommand(
{
setAuditConfig: 1,
filter: {atype: "authCheck"},
auditAuthorizationSuccess: true
})
```
**注記**
すべての DML ログは、`atype` として `authCheck` を持っています。DDL のみが別の `atype` を持っています。`filter` に `authCheck` 以外の値を指定した場合、CloudWatch での DML ログの生成は行われません。
**例: 演算子によって結合された複数のフィルターを使用したフィルタリング**
```
db.admin.runCommand(
{
setAuditConfig: 1,
filter: {
"$and": [
{
"param.command":
{
$in: [ "find","count", "insert", "delete", "update", "findandmodify" ]
}
}
],
"$nor": [
{
"param.command":
{
$in: ["count", "insert", "delete", "update", "findandmodify" ]
}
}]
},
auditAuthorizationSuccess: true})
```
**注記**
最上位レベルでは、`$and`、`$or`、`$nor` のみがサポートされています。他の演算子はサポートされていないため、エラーが発生します。
**例: `auditAuthorizationSuccess` によるイベント別のフィルタリング **
このフィルターでは、認証に合格したすべてのコマンドはログに記録されません。
```
db.admin.runCommand(
{
setAuditConfig: 1,
filter: {},
auditAuthorizationSuccess: false
}
)
```
**例: `$in` および `$nin` 条件によるフィルタリング**
`$in` と `$nin` の両方で使用する場合、条件間に暗黙的な「and」があるため、コマンドはログに記録されません。この例では、正規表現で `find` コマンドがブロックされるため、ログには何も記録されません。
```
db.admin.runCommand(
{
setAuditConfig: 1,
filter: {
"$and": [
{
atype: "authCheck",
"param.command":
{
$in: [ "find", "insert", "delete", "update", "findandmodify" ],
$nin: ["count", "insert", "delete", "update", "findandmodify" ],
$not: /^^find.*/
}
},
],
"$or": [
{
"param.command":
{
$nin: ["count", "insert", "delete", "update", "findandmodify" ]
}
}]
},
auditAuthorizationSuccess: true})
```
**例: `namespace` によるフィルタリング**
```
db.admin.runCommand(
{
setAuditConfig: 1,
filter: {
"$and": [
{
"param.ns":
{
$in: [ "test.foo" ]
}
}
]},
auditAuthorizationSuccess: true})
```
**例: デフォルトフィルターへのリセット**
デフォルト値にリセットすると、すべての DML 監査イベントがログに記録されます。フィルターをデフォルト値にリセットするには、次のコマンドを実行します。
```
db.admin.runCommand(
{
setAuditConfig: 1,
filter: {},
auditAuthorizationSuccess: true
}
)
```