こんにちは(￣^￣)ゞ
最近、スプラトゥーン3とPhasmophobiaにハマっている大久保です。
次回のスプラトゥーンフェスは「くさ」で行こうかと思っていますー

タイトルの通り、AuroraのMySQLとPostgreSQLで利用できる「データベースアクティビティストリーミング」を有効化し、Athenaで良い感じに検索できる設定方法について書きたいと思います。

ただ1つの記事にするにはボリュームがありすぎるため、

• ~パート1~データベースアクティビティストリーミングとは
• ~パート2~データベースアクティビティストリーミングの設定方法
• ~パート3~Athenaの設定方法

の3つにわけたいと思います。

今回は「~パート1~データベースアクティビティストリーミングとは」になります。

DASとは？

Database Activity Streamsの略

DASはAuroraとRDS for Oracleで利用できる監査ログの出力機能になります。
ほぼリアルタイムで監査ログをストリーミングすることが出来、他ツールと連携を行い監査・監視を行うことが出来ます。
仕組みとしては、以下の画像のように複数のAWSサービスを利用することで監査ログのストリーミングを行っています。

画像引用元：データベースアクティビティストリーミングの機能

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/DBActivityStreams.Overview.html

Kinesis Data Streamsは、Auroraの設定からKMSのカスタマー管理キーを指定しDASを有効化することで、自動的に作成されます。
ログの保存を行いたい場合は、別途Kinesis Data FirehoseとS3バケットを手動で作成、連携させることで実現することが出来ます。

特徴

私が思うDASの特徴は以下になります。

1. MySQL、PostgreSQLのどちらでもほぼ同様の設定で監査ログの取得ができる。
2. 他ツールと連携することで、監査ログの分析をほぼリアルタイムで行うことができる。
3. 非同期、同期モードがある。
4. KMSを用いてログが暗号化されるため、どこかのタイミングで復号化処理を実装する必要がある。

4の特徴について、復号化処理は自前で作成する必要があります。
復号化のタイミングはKinesisFirehoseに連携後、Labmdaで行ったり、ファイルに保存した後で行うことも可能なようです。
公式のブログに復号化のサンプルコードがあるため、複雑な要件でなければサンプルコードを少し編集するだけで実装出来そうです。

Lambda function
The Lambda function is invoked by Kinesis Data Firehose. We configure the Lambda event source after we create the function. Aurora activity data is Base64 encoded and encrypted using an AWS Key Management Service (AWS KMS) key. For this post, we decrypt the data and store it in an appropriate folder in the S3 bucket based on activity type. However, we recommend encrypting the activity data before storing it in the folder, or enabling encryption at the bucket level. We also discard heartbeat events and store other events in specific folders like CONNECT, DISCONNECT, ERROR, and AUTH FAILURE. Pay attention to comments within the Lambda code because they highlight activities like decryption, filtering, and putting data in a specific folder. For instructions on creating a Lambda function, see the AWS Lambda Developer Guide.

The following is the sample Lambda function code in Python 3.8 using Boto3. This code depends on the aws_encryption_sdk library, which needs to be packaged as part of the Lambda code. aws_encryption_sdk depends on the cryptography library, which is OS dependent. For Lambda, Linux cryptography libraries should be included in the Lambda package.

When choosing an existing or new Lambda execution role, make sure role has access to the S3 bucket, Kinesis Data Firehose, and AWS KMS. It’s always a best practice to follow the principle of least privileges.

The following Lambda code can be found at AWS Samples on GitHub:

https://aws.amazon.com/jp/blogs/database/filter-amazon-aurora-database-activity-stream-data-for-segregation-and-monitoring/

DASの要件

Auroraの場合

DASを利用するには、いくつかの要件があります。
下記にAuroraでDASを利用する場合の要件を記載しました。　※2022/10/17日時点

• KMSのカスタマー管理キーを事前に作成している。
• 対象のAuroraクラスターがKMSにアクセス出来る必要がある。
• 利用しているAuroraのエンジンバージョンが、以下のいずれかに該当している。
  • PostgreSQL
    • 14、13 および 12 のすべてのバージョン
    • バージョン 11.6、バージョン 11 以降
    • バージョン 10.11、バージョン 10 以降
  • MySQL
    • 2.08 以上。
• 利用しているインスタンスタイプが以下のうちのいずれかに該当している。
  • PostgreSQL
    • db.r6g
    • db.r5
    • db.r4
    • db.x2g
  • MySQL
    • db.r6g
    • db.r5
    • db.r4
    • db.r3
    • db.x2g

うっかりポイントは、インスタンスタイプです。
検証環境はコストがかからないようにT系のインスタンスをつかっていることが多いと思います。
T系を使っていることを忘れ、DASが有効化出来ない…どうしてだろう…と私はなったので、みなさんも気をつけてください。
より詳細な要件は下記のドキュメントを参照してください。

データベースアクティビティストリームの要件

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/DBActivityStreams.Overview.html#DBActivityStreams.Overview.requirements

ハマるポイントは、KMSのアクセスについてです。
ログを暗号化する際にKMSを使うのですが、KMSを使うためにはAuroraがKMSにアクセス出来る必要があります。
KMSへアクセスが出来ないと、ログの暗号化が行えずエラーになり、ストリーミングが失敗します。
基本的にDBはプライベートサブネットに配置すると思いますが、この場合、KMSへアクセスさせるため以下のどちらかの設定が必要になります。

• Auroraクラスターが配置されているサブネットのルーティングテーブルに、NATゲートウェイのルートを追加する。
• Auroraクラスターが配置されているサブネットに、KMSのVPCエンドポイントを作成する。

詳しい情報については下記のドキュメントを参照してください。

プライベートアベイラビリティの前提条件

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/DBActivityStreams.Prereqs.html

DASのログ

DASのログはJSON形式で出力されます。
MySQLとPostgreSQLで一部項目が異なりますが、ほぼ同様なログが出力されます。
また公式のドキュメントにも記載がありますが、将来的に新しいフィールドの追加、既存のフィールドの削除等の変更の可能性を考慮しておく必要があります。

MySQLの場合

MySQLの場合は以下のようなログになります。

{
    "logTime": "2022-10-26 08:46:59.892621+00",
    "type": "record",
    "clientApplication": null,
    "pid": 8468,
    "dbUserName": "test",
    "databaseName": "test",
    "remoteHost": "172.16.1.193",
    "remotePort": "0",
    "command": "QUERY",
    "commandText": "SELECT * FROM `settings`",
    "paramList": null,
    "objectType": "TABLE",
    "objectName": "",
    "statementId": 159717094,
    "substatementId": 1,
    "exitCode": "0",
    "sessionId": "2365080",
    "rowCount": 1,
    "serverHost": "test-db",
    "serverType": "MySQL",
    "serviceName": "Amazon Aurora MySQL",
    "serverVersion": "8.0.mysql_aurora.3.02.0",
    "startTime": "2022-10-26 08:46:59.892378+00",
    "endTime": "2022-10-26 08:46:59.892576+00",
    "transactionId": "0",
    "dbProtocol": "MySQL",
    "netProtocol": "TCP",
    "errorMessage": "",
    "class": "MAIN"
}

各項目については、公式ドキュメントから引用した情報を記載します。

Aurora MySQL の databaseActivityEventList フィールド

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/DBActivityStreams.Monitoring.html#DBActivityStreams.AuditLog

個人的なポイントは、タイムスタンプ系項目がUTC固定のところです。
これはクラスターパラメーターグループのタイムゾーンを変更しても固定になるため、必要に応じて分析する際に変換しないといけないです。

PostgreSQLの場合

PostgreSQLの場合は以下のようなログになります。

{
    "logTime": "2022-10-27 14:00:53.674229+09",
    "statementId": 35306,
    "substatementId": 6,
    "objectType": "TABLE",
    "command": "SELECT",
    "objectName": "public.queries",
    "databaseName": "test",
    "dbUserName": "test",
    "remoteHost": "172.16.49.165",
    "remotePort": "35914",
    "sessionId": "6359cba0.54df",
    "rowCount": 1,
    "commandText": "SELECT $1,$2,$3,$4 FROM list",
    "paramList": [
        "1_id",
        "2_name",
        "3_age",
        "4_address"
    ],
    "pid": 21727,
    "clientApplication": "Passenger RubyApp: test",
    "exitCode": null,
    "class": "READ",
    "serverVersion": "12.8.2",
    "serverType": "PostgreSQL",
    "serviceName": "Amazon Aurora PostgreSQL-Compatible edition",
    "serverHost": "172.16.252.130",
    "netProtocol": "TCP",
    "dbProtocol": "Postgres 3.0",
    "type": "record",
    "startTime": "2022-10-27 14:00:53.674127+09",
    "errorMessage": null
}

各項目については、公式ドキュメントから引用した情報を記載します。

Aurora PostgreSQL の databaseActivityEventList フィールド

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/DBActivityStreams.Monitoring.html#DBActivityStreams.AuditLog

個人的には以下の2点がMySQLと違っていると思います。

• パラメーターの詳細が出力される。
• タイムスタンプ系がUTC固定ではない。

タイムスタンプ系について、正しいかは不明ですがクラスターパラメーターグループで指定したタイムゾーンに準拠する形になると思います。

DASのコスト【東京リージョンの場合】

DASを利用することで以下のサービスのコストがかかると想定されます。
気にするべきところは赤文字になっている部分です。

• Kinesis
  • Data Firehose
    • Tier 1 $0.036 per GB of data read from Kinesis Data Streams
    • Tier 1 $0.036 per GB of data ingested
  • Data Streams ※オンデマンドの場合
    • $0.052 per Stream Hour Used
    • $0.104 per GB of data written
    • $0.052 per GB of data read using GetRecords Consumer

• Lambda
• KMS
  • $1 per customer managed KMS key version in Asia Pacific (Tokyo)
  • $0.03 per 10000 KMS requests in Asia Pacific (Tokyo)
• S3
• VPC
  • KMSエンドポイント　※作成していれば
    • $0.014 per VPC Endpoint Hour
• GuardDuty　※有効にしていれば
  • $0.00000472 per CloudTrail event analyzed in Asia Pacific (Tokyo) region
• Detective　※有効にしていれば
  • USD 2.70 per GB for the first 1,000GB / month of data analyzed Asia Pacific (Tokyo) region

Kinesis Data Streamsについては、シャードの起動時間に対して課金が発生します。
大体月に$40ほど固定で掛かるイメージです。
データの取り込み、転送の料金についてはお安めの金額なため、ログの量が多くなっても爆発的な課金の増加はないと思います。

Amazon Kinesis Data Streams の料金

https://aws.amazon.com/jp/kinesis/data-streams/pricing/

KMSについては、リクエスト数に対する課金がネックになりそうな気がしています。
DASでは、暗号化と復号化のどちらでもリクエストを行い、またリクエストは一つのログごとに行っていると見受けられます。
そのためKMSのリクエストがかなり増加しやすく、課金が高額になりやすいです。

AWS Key Management Service の料金

https://aws.amazon.com/jp/kms/pricing/

GuardDutyとDetectiveについて、設定によってはかなり高額な課金が発生する場合があります。
先ほど話した記載したKMSのリクエストの増加に伴い、CloudTrail上でKMSへのリクエストログが膨大になります。
GuardDutyやDetectiveはCloudTrailのログを参照するため、CloudTrail上のログの増加に伴い爆発的にコストが増加する可能性があります。
対策としては、Detectiveの無効化するなどが必要になってくると思います。

Amazon GuardDuty の料金

https://aws.amazon.com/jp/guardduty/pricing/

Amazon Detective の料金

https://aws.amazon.com/jp/detective/pricing/

Kinesis Data Streamだけを見るとCloudWatchLogsを使うより安く済みそうに見えますが、KMSなどの周辺のサービスを含めると高額になる可能性があるため注意が必要です。

まとめ

今回はDASの概要について、ざっくりと説明してみました。
AWS上で簡単に設定でき、復号化処理も提供されているサンプルコードを利用することで、比較的に簡単に検証が出来ると思います。

次回は実際にログをS3へ保存するまでの手順について説明したいと思います。

参考にした記事

• https://dev.classmethod.jp/articles/aurora-postgresql-audit-with-data-activity-stream/
• https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/DBActivityStreams.html
• https://aws.amazon.com/jp/blogs/database/filter-amazon-aurora-database-activity-stream-data-for-segregation-and-monitoring/