

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# イベント、ログ、監査証跡
<a name="events-logs-audit"></a>

[DB インスタンスメトリクス](db-instance-monitoring.md)と [OS メトリクス](os-monitoring.md)のモニタリング、傾向分析、メトリクスとベースライン値の比較、定義済みしきい値を超えた場合のアラート生成は、いずれも必要なオペレーションであり、Amazon RDS DB インスタンスの信頼性、可用性、パフォーマンス、セキュリティの確保と維持に役立つベストプラクティスでもあります。しかし、包括的なソリューションを実現するには、MySQL および MariaDB データベースのデータベースイベント、ログファイル、監査証跡もモニタリングしなければなりません。

**セクション**
+ [Amazon RDS イベント](rds-events.md)
+ [データベースログ](database-logs.md)
+ [監査証跡](audit-trails.md)

# Amazon RDS イベント
<a name="rds-events"></a>

*Amazon RDS* *イベント*は、Amazon RDS 環境で生じた変更を示すものです。例えば、DB インスタンスのステータスが*開始中*から*使用可能*に変わると、Amazon RDS ではイベント `RDS-EVENT-0088 The DB instance has been started` が生成されます。Amazon RDS から Amazon EventBridge へは、ほぼリアルタイムでイベントが配信されます。イベントにアクセスするには、Amazon RDS コンソール、AWS CLI コマンド [describe-events](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/describe-events.html)、または Amazon RDS API オペレーション [DescribeEvents](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeEvents.html) を使用します。次の画像は、Amazon RDS コンソールに表示されるイベントとログを示しています。

![\[Amazon RDS コンソールに表示されるアラーム、イベント、ログ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/amazon-rds-monitoring-alerting/images/alarms-events-logs-rds-console.png)


Amazon RDS では、DB インスタンスイベント、DB パラメータグループイベント、DB セキュリティグループイベント、DB スナップショットイベント、RDS Proxy イベント、ブルー/グリーンデプロイイベントといった、各種イベントが発行されます。これにより、次の情報が得られます。
+ ソース名とソースタイプ。例: `"SourceIdentifier": "database-1", "SourceType": "db-instance"`
+ イベントの日付と時刻。例: `"Date": "2022-12-01T09:20:28.595000+00:00"`
+ イベントに関連付けられたメッセージ。例: `"Message": "Finished updating DB parameter group"`
+ イベントカテゴリ。例: `"EventCategories": ["configuration change"]`

網羅的なリファレンスについては、Amazon RDS ドキュメントの「[Amazon RDS のイベントカテゴリとイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Messages.html)」を参照してください。

Amazon RDS イベントのモニタリングをお勧めします。なぜなら、これらのイベントは、DB インスタンスの可用性ステータス変更、設定変更、リードレプリカのステータス変更、バックアップおよびリカバリイベント、フェイルオーバーアクション、障害イベント、セキュリティグループの変更といった、さまざまな情報や通知を示すものだからです。例えば、データベースのパフォーマンスと耐久性の向上を目的にリードレプリカ DB インスタンスを設定している場合は、DB インスタンスに関連付けられた*リードレプリカ*イベントカテゴリの Amazon RDS イベントをモニタリングすると良いでしょう。`RDS-EVENT-0057 Replication on the read replica was terminated` などのイベントは、リードレプリカがプライマリ DB インスタンスと同期されていないことを示しているからです。そのようなイベントの発生を担当チームに通知すれば、問題のタイムリーな緩和に役立ちます。Amazon EventBridge とその他の AWS のサービス (AWS Lambda、Amazon Simple Queue Service (Amazon SQS)、Amazon Simple Notification Service (Amazon SNS) など) は、データベースの可用性の問題やリソースの変更といったシステムイベントへの応答を自動化するのに有用です。

Amazon RDS コンソールでは、過去 24 時間のイベントを取得できます。AWS CLI または Amazon RDS API を使用してイベントを表示する場合は、次のように **describe-events** コマンドを使用して、過去 14 日間のイベントを取得できます。

```
$ aws rds describe-events --source-identifier database-1 --source-type db-instance
{
    "Events": [
        {
            "SourceIdentifier": "database-1",
            "SourceType": "db-instance",
            "Message": "CloudWatch Logs Export enabled for logs [audit, error, general, slowquery]",
            "EventCategories": [],
            "Date": "2022-12-01T09:20:28.595000+00:00",
            "SourceArn": "arn:aws:rds:eu-west-3:111122223333:db:database-1"
        },
        {
            "SourceIdentifier": "database-1",
            "SourceType": "db-instance",
            "Message": "Finished updating DB parameter group",
            "EventCategories": [
                "configuration change"
            ],
            "Date": "2022-12-01T09:22:40.413000+00:00",
            "SourceArn": "arn:aws:rds:eu-west-3:111122223333:db:database-1"
        }
    ]
}
```

イベントを長期的に保存 (指定した有効期限まで、あるいは永続的に保存) する場合は、[CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) を使用して、Amazon RDS で生成されたイベントの情報をログに記録できます。このソリューションを実装するには、Amazon SNS トピックを使用して Amazon RDS イベント通知を受信し、Lambda 関数を呼び出して CloudWatch Logs にイベントをログ記録します。

1. イベントで呼び出す Lambda 関数を作成し、イベントから取得した情報を CloudWatch Logs に記録します。CloudWatch Logs は Lambda と統合されているため、`stdout` にイベント情報を書き出す **print** 関数を使用して、それらの情報を簡単にログに記録できます。

1. Lambda 関数へのサブスクリプションを使用して SNS トピックを作成し (**[プロトコル]** を Lambda に設定)、**[エンドポイント]** を、前のステップで作成した Lambda 関数の Amazon リソースネーム (ARN) に設定します。

1. Amazon RDS イベント通知を受信するように SNS トピックを設定します。詳細な手順については、Amazon SNS トピックで Amazon RDS 通知を受信する方法に関する [AWS re:Post の記事](https://repost.aws/knowledge-center/sns-topics-rds-notifications)を参照してください。

1. Amazon RDS コンソールで、イベントサブスクリプションを新規作成します。**[ターゲット]** を ARN に設定し、前に作成した SNS トピックを選択します。要件に応じて、**[ソースタイプ]** と **[含めるイベントカテゴリ]** を設定します。詳細については、Amazon RDS ドキュメントの「[Amazon RDS イベント通知にサブスクライブする](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Subscribing.html)」を参照してください。

# データベースログ
<a name="database-logs"></a>

MySQL および MariaDB データベースでは、監査やトラブルシューティングのためにアクセスできるログが生成されます。これらのログを次にしめします。
+ [監査](https://mariadb.com/kb/en/mariadb-audit-plugin-log-format/) – 監査証跡は、サーバーのアクティビティが記録されている一連のレコードです。これには、クライアントセッションごとに、サーバーに接続したユーザー (ユーザー名とホスト)、実行したクエリ、アクセスしたテーブル、変更したサーバー変数が記録されます。
+ [エラー](https://dev.mysql.com/doc/refman/8.0/en/error-log.html) – このログには、サーバー (`mysqld`) の起動およびシャットダウン時刻に加え、サーバーの起動、シャットダウン、稼働時に発生したエラー、警告、通知といった診断メッセージが記録されます。
+ [全般](https://dev.mysql.com/doc/refman/8.0/en/query-log.html) – このログには、`mysqld` のアクティビティ (各クライアントの接続および切断アクティビティ、クライアントから受信した SQL クエリなど) が記録されます。全般のクエリログは、エラーが疑われる場合や、クライアントが `mysqld` に送信した内容を正確に把握する場合に非常に有用です。
+ [スロークエリ](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html) – このログには、実行に長い時間がかかった SQL クエリが記録されます。

ベストプラクティスを実行するには、[Amazon RDS から Amazon CloudWatch Logs にデータベースログを発行](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Procedural.UploadtoCloudWatch.html)する必要があります。CloudWatch Logs を使用すると、ログデータのリアルタイム分析、耐久性に優れたストレージへのデータ保存、CloudWatch Logs エージェントによるデータ管理を行えます。[データベースログは、Amazon RDS コンソールからアクセスして監視](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Procedural.Watching.html)できます。CloudWatch Logs Insights を使用すると、CloudWatch Logs 内のログデータをインタラクティブに検索し、分析することも可能です。次の例は、監査ログのクエリを示しています。このクエリにより、ログに `CONNECT` イベントが出力されている回数、接続者、接続元クライアント (IP アドレス) を確認します。監査ログからの抜粋を次に示します。

```
20221201 14:07:05,ip-10-22-1-51,rdsadmin,localhost,821,0,CONNECT,,,0,SOCKET
20221201 14:07:05,ip-10-22-1-51,rdsadmin,localhost,821,0,DISCONNECT,,,0,SOCKET
20221201 14:12:20,ip-10-22-1-51,rdsadmin,localhost,822,0,CONNECT,,,0,SOCKET
20221201 14:12:20,ip-10-22-1-51,rdsadmin,localhost,822,0,DISCONNECT,,,0,SOCKET
20221201 14:17:35,ip-10-22-1-51,rdsadmin,localhost,823,0,CONNECT,,,0,SOCKET
20221201 14:17:35,ip-10-22-1-51,rdsadmin,localhost,823,0,DISCONNECT,,,0,SOCKET
20221201 14:22:50,ip-10-22-1-51,rdsadmin,localhost,824,0,CONNECT,,,0,SOCKET
20221201 14:22:50,ip-10-22-1-51,rdsadmin,localhost,824,0,DISCONNECT,,,0,SOCKET
```

Log Insights クエリの例は、`rdsadmin` が `localhost` から 5 分おきにデータベースに接続していることを示しており、次の図を見ると、それが合計 22 回発生していることがわかります。これらの結果によると、このアクティビティは、モニタリングシステムといった内部の Amazon RDS プロセス自体によって生じています。

![\[Log Insights によるレポート\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/amazon-rds-monitoring-alerting/images/log-insights.png)


ログイベントには、MySQL および MariaDB DB インスタンス関連オペレーションで生じる警告やエラーといった、カウント対象となる重要なメッセージが頻繁に出力されます。例えば、操作が失敗した場合、次のエラーが発生し、エラーログファイルに記録される場合があります: `ERROR 1114 (HY000): The table zip_codes is full`。エラー傾向を把握するために、これらのログのモニタリングをお勧めします。[Amazon RDS ログからカスタム CloudWatch メトリクスを作成するには、フィルターを使用して](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html) Amazon RDS データベースログの自動モニタリングを有効にします。次に、特定のログで特定のパターンをモニタリングし、想定動作に違反する挙動があった場合にアラームを生成するよう設定します。[例えば](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CountOccurrencesExample.html)、ロググループ `/aws/rds/instance/database-1/error` にメトリクスフィルターを作成し、これによって、エラーログをモニタリングし、`ERROR` のような[特定のパターン](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html)を検索します。**フィルターパターン**を `ERROR` に、**メトリクス値**を `1` に設定します。このフィルターによって、キーワード `ERROR` が含まれるログレコードをすべて検出し「ERROR」のあるログイベントごとにカウントを 1 増やします。フィルターを作成したら、MySQL または MariaDB エラーログでエラーが検出された際にその旨を通知させるアラームを設定できます。

CloudWatch ダッシュボードの作成と CloudWatch Logs Insights の使用によるスロークエリログおよびエラーログモニタリングの詳細については、ブログ記事「[Creating an Amazon CloudWatch dashboard to monitor Amazon RDS and Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/creating-an-amazon-cloudwatch-dashboard-to-monitor-amazon-rds-and-amazon-aurora-mysql/)」を参照してください。

# 監査証跡
<a name="audit-trails"></a>

監査証跡 (監査ログ) は、AWS アカウント で発生したイベントについて、セキュリティ関連の時系列レコードを得られます。Amazon RDS のイベントも対象になるため、データベースまたはクラウド環境に影響を与えた一連のアクティビティについて、ドキュメント化された証拠を収集できます。Amazon RDS for MySQL または MariaDB では、監査証跡を使用して次のオペレーションを行います。
+ DB インスタンスの監査ログをモニタリングする
+ AWS CloudTrail で Amazon RDS API コールをモニタリングする

Amazon RDS DB インスタンスが対象の場合、一般的に、次のような監査目的があります。
+ 以下について説明責任を果たすこと。
  + パラメータまたはセキュリティ設定で行われた変更
  + データベーススキーマ、テーブル、行で実行されたアクション、あるいは、特定の内容に影響が及ぶアクション
+ 侵入の検出および調査
+ 疑わしいアクティビティの検出および調査
+ 認可上の問題の検出。例: 正規ユーザーまたは特権ユーザーによるアクセス権の悪用を特定する

データベースの監査証跡は、次のようなよくある疑問の解消に有用です: *どのユーザーがデータベース内の機密データを表示または変更したか? この事象はいつ発生したか? この特定のユーザーはどこからデータにアクセスしたか? この特権ユーザーは無制限のアクセス権を悪用したか?*

MySQL と MariaDB ではともに、MariaDB 監査プラグインを使用して DB インスタンスの監査証跡機能を実装します。このプラグインにより、データベースへのユーザーログインや、データベースへのクエリ実行といった、データベースのアクティビティを記録します。データベースのアクティビティのレコードはログファイルに保存されます。監査ログにアクセスするには、DB インスタンスは `MARIADB_AUDIT_PLUGIN` オプションを指定してカスタムオプショングループを使用する必要があります。詳細については、Amazon RDS ドキュメントの「[MySQL に対する MariaDB 監査プラグインのサポート](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.Options.AuditPlugin.html)」を参照してください。監査ログのレコードは、プラグインで定義されている特定の形式で保存されます。監査ログ形式の詳細については、[MariaDB Server のドキュメント](https://mariadb.com/kb/en/mariadb-audit-plugin-log-format/)を参照してください。

AWS アカウントで AWS クラウド の監査証跡を得るには、[AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) サービスを利用します。CloudTrail は、Amazon RDS の API コールをイベントとしてキャプチャします。Amazon RDS でのアクションは、すべてログに記録されます。CloudTrail では、ユーザー、ロール、その他の AWS サービスによって Amazon RDS で実行されたアクションを記録します。例えば、AWS マネジメントコンソール、AWS CLI、AWS SDK および API で実行されたアクションなどのイベントが記録対象となります。

## 例
<a name="example"></a>

一般的な監査シナリオでは、AWS CloudTrail の証跡、データベース監査ログ、Amazon RDS イベントモニタリングの結果を総合的に確認する必要があるでしょう。例えば、Amazon RDS DB インスタンス (`database-1` など) のデータベースパラメータが変更され、その変更者、変更された対象、変更されたタイミングを特定するタスクを任されるといったシナリオが考えられます。

そのタスクを実行するには、次のステップに従います。

1. データベースインスタンス `database-1` で発生した Amazon RDS イベントを一覧表示して、`configuration change` カテゴリに属する​​イベントのうち、`Finished updating DB parameter group` というメッセージを持つイベントがあるかどうかを確認します。

   ```
   $ aws rds describe-events --source-identifier database-1 --source-type db-instance
   {
       "Events": [
           {
               "SourceIdentifier": "database-1",
               "SourceType": "db-instance",
               "Message": "Finished updating DB parameter group",
               "EventCategories": [
                   "configuration change"
               ],
               "Date": "2022-12-01T09:22:40.413000+00:00",
               "SourceArn": "arn:aws:rds:eu-west-3:111122223333:db:database-1"
           }
       ]
   }
   ```

1. DB インスタンスで使用されている DB パラメータグループを特定します。

   ```
   $ aws rds describe-db-instances --db-instance-identifier database-1 --query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups]'
   [
       [
           "database-1",
           "mariadb",
           [
               {
                   "DBParameterGroupName": "mariadb10-6-test",
                   "ParameterApplyStatus": "pending-reboot"
               }
           ]
       ]
   ]
   ```

1. [AWS CLI を使用して、CloudTrail イベントを検索します](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events-cli.html)。具体的には、`database-1` がデプロイされているリージョンで、ステップ 1 で検出した Amazon RDS イベントの発生時刻前後の期間を対象に `EventName=ModifyDBParameterGroup` のイベントを特定します。

   ```
   $ aws cloudtrail --region eu-west-3 lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=ModifyDBParameterGroup --start-time "2022-12-01, 09:00 AM" --end-time "2022-12-01, 09:30 AM"    
   
   {
       "eventVersion": "1.08",
       "userIdentity": {
           "accountId": "111122223333",
           "accessKeyId": "AKIAIOSFODNN7EXAMPLE",
           "sessionContext": {
               "sessionIssuer": {
                   "type": "Role",
                   "principalId": "AIDACKCEVSQ6C2EXAMPLE",
                   "arn": "arn:aws:iam::111122223333:role/Role1",
                   "accountId": "111122223333",
                   "userName": "User1"
               }
           }
       },
       "eventTime": "2022-12-01T09:18:19Z",
       "eventSource": "rds.amazonaws.com",
       "eventName": "ModifyDBParameterGroup",
       "awsRegion": "eu-west-3",
       "sourceIPAddress": "AWS Internal",
       "userAgent": "AWS Internal",
       "requestParameters": {
           "parameters": [
               {
                   "isModifiable": false,
                   "applyMethod": "pending-reboot",
                   "parameterName": "innodb_log_buffer_size",
                   "parameterValue": "8388612"
               },
               {
                   "isModifiable": false,
                   "applyMethod": "pending-reboot",
                   "parameterName": "innodb_write_io_threads",
                   "parameterValue": "8"
               }
           ],
           "dBParameterGroupName": "mariadb10-6-test"
       },
       "responseElements": {
           "dBParameterGroupName": "mariadb10-6-test"
       },
       "requestID": "fdf19353-de72-4d3d-bf29-751f375b6378",
       "eventID": "0bba7484-0e46-4e71-93a8-bd01ca8386fe",
       "eventType": "AwsApiCall",
       "managementEvent": true,
       "recipientAccountId": "111122223333",
       "eventCategory": "Management",
       "sessionCredentialFromConsole": "true"
   }
   ```

この CloudTrail イベントによると、AWS アカウントが 111122223333 で、ロール `Role1` を持つ `User1` が、`2022-12-01 at 09:18:19 h` に DB インスタンス `database-1` で使用されていた DB パラメータグループ `mariadb10-6-test` を変更していました。2 つのパラメータが変更され、値が以下に設定されています。
+ `innodb_log_buffer_size = 8388612`
+ `innodb_write_io_threads = 8`

## CloudTrail と CloudWatch Logs が備えるその他の機能
<a name="additional-features"></a>

過去 90 日間に発生した運用上およびセキュリティ上のインシデントにトラブルシューティングを行うには、CloudTrail コンソールで **[イベント履歴]** を表示します。その保持期間を延長して、追加のクエリ機能を利用する場合は、[AWS CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html) を使用できます。AWS CloudTrail Lake では、イベントデータを、最大 7 年間、イベントデータストアに保存できます。さらに、このサービスは、複雑な SQL クエリに対応しています。カスタマイズ可能で詳細なイベントビューを得られるという点で、**[イベント履歴]** での単純なキーと値のルックアップよりも優れています。

監査証跡をモニタリングして、アラームを設定し、特定のアクティビティが発生したときに通知を受け取るには、[CloudTrail を設定して、その証跡レコードが CloudWatch Logs に送信されるようにする](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/monitor-cloudtrail-log-files-with-cloudwatch-logs.html)必要があります。証跡レコードが CloudWatch Logs として保存されたら、メトリクスフィルターを定義して、用語、フレーズ、または値に一致するログイベントを評価し、メトリクスフィルターにメトリクスを割り当てることができます。さらに、指定したしきい値と期間に基づいてアラームを生成する CloudWatch アラームを作成することも可能です。例えば、担当チームに通知を送信するアラームを設定すると、チームでは適切なアクションを実行できます。アラームへの対応アクションが自動的に実行されるように CloudWatch を設定することもできます。