RDS DB インスタンスにおけるCloudWatch Logsへのログ発行について

2025.06.18

このブログシリーズ 「クラウドセキュリティ 実践集」 では、一般的なセキュリティ課題を取り上げ、「なぜ危険なのか？」 というリスクの解説から、「どうやって直すのか？」 という具体的な修復手順（コンソール、AWS CLI、Terraformなど）まで、分かりやすく解説します。

この記事では、Aurora MySQL DBクラスターのCloudWatch Logsへの監査ログ発行が有効化されていない状態について、リスクと対策を解説します。

ポリシーの説明

Amazon RDS の Security Hub コントロール – AWS Security Hub

このコントロールは、Amazon RDS DB インスタンスが以下のログを Amazon CloudWatch Logs に発行するように設定されているかどうかをチェックします。インスタンスが以下のログを CloudWatch Logs に発行するように設定されていない場合、コントロールは失敗します。

リスク

Amazon Aurora MySQL DBクラスターは、高いパフォーマンスと可用性を提供するリレーショナルデータベースサービスです。しかし、監査ログのCloudWatch Logsへの発行が有効化されていない場合、データベース内の重要なアクティビティが記録されず、以下のようなセキュリティとコンプライアンスに関する重大なリスクが発生します。

  • セキュリティインシデントの検知遅延: データベースへの不正なログイン試行、特権昇格、データ変更や削除などの悪意ある操作があった場合でも、監査ログがなければそれらのイベントを検知できません。これにより、セキュリティ侵害が undetected のまま進行し、被害が拡大する可能性があります。
  • フォレンジック分析の困難化: インシデント発生時、監査ログは原因究明、攻撃経路の特定、影響範囲の分析に不可欠な情報源となります。ログがない場合、フォレンジック調査が不可能または極めて困難になり、復旧に時間がかかります。
  • コンプライアンス違反: PCI DSS、HIPAA、GDPRなどの多くの規制やコンプライアンスフレームワークでは、データベースアクティビティの監査証跡の保持が義務付けられています。監査ログが有効化されていない場合、これらのコンプライアンス要件を満たせない可能性があります。
  • 内部不正の検出困難: 内部の悪意のあるユーザーや誤操作によるデータ変更も、監査ログがなければ追跡できません。これにより、内部不正の検出や防止が困難になります。
  • 責任の不明確化: 誰が、いつ、どのような操作をデータベースに対して行ったかという記録がないため、問題発生時の責任の所在が不明確になります。

対策

Aurora MySQL DBクラスターの監査ログをCloudWatch Logsに発行するように設定することは、データベースのセキュリティを強化し、コンプライアンス要件を満たすために不可欠です。

  • 監査ログの有効化: Aurora MySQL DBクラスターの設定において、server_audit_logsなどの監査関連のログを有効化し、CloudWatch Logsに発行されるように設定します。
  • ログの保持期間の設定: CloudWatch Logsで、監査ログのロググループに対して、コンプライアンス要件や監査ポリシーに合わせた適切な保持期間を設定します。
  • 監査ログの監視とアラート: CloudWatch Logsの監査ログデータに対して、特定の不正アクセスパターン、異常なSQLクエリ、特権操作などを検知するメトリクスフィルターを設定します。その後、これらのメトリクスに基づいてCloudWatchアラームを設定し、異常が検知された場合にセキュリティチームに通知されるようにします。
  • ログの分析と可視化: CloudWatch LogsのログデータをAmazon AthenaやAmazon QuickSightなどのサービスと連携させて分析し、データベースアクティビティの傾向把握やセキュリティイベントの可視化を行います。これにより、潜在的な脅威をより早く特定できます。
  • 定期的な監査レビュー: 監査ログを定期的にレビューし、異常なアクティビティがないか確認します。自動化された監視だけでなく、人間による定期的なチェックも重要です。

修復方法

AWSコンソールでの修復手順

AWSコンソールを使用して、Aurora MySQL DBクラスターの監査ログをCloudWatch Logsに発行するように設定します。

  1. RDSサービスへ移動:
    • AWSコンソールにログインし、RDSサービスを開きます。
  2. DBクラスターの選択:
    • 左側のナビゲーションペインで「データベース」を選択します。
    • 監査ログを有効にしたいAurora MySQL DBクラスターを選択します。
  3. クラスターの変更:
    • 選択したDBクラスターの上部にある「変更」をクリックします。
  4. ログエクスポートの設定:
    • 「ログエクスポート」セクションまでスクロールします。「監査ログ」にチェックを入れます。これにより、監査ログがCloudWatch Logsに発行されるようになります。必要に応じて、他のログタイプ（エラーログ、一般ログ、スロークエリログ）も有効にすることを検討してください。
  5. DBクラスターパラメータグループの確認と変更:
    • Aurora MySQLの監査ログを有効にするには、関連するDBクラスターパラメータグループでserver_audit_logsパラメータが1に設定されている必要があります。
    • RDSコンソールの左側ナビゲーションペインで「パラメータグループ」を選択します。
    • 対象のDBクラスターに関連付けられているクラスターパラメータグループを検索して選択します。
    • 「パラメータを編集」をクリックし、server_audit_logs を検索して、その値を 1 に設定します。
    • 他の関連する監査パラメータ（例: server_audit_events で監査するイベントの種類を指定）も必要に応じて設定します。
    • 変更を保存します。
  6. 変更の適用:
    • DBクラスターの変更画面に戻り、「変更の適用」セクションで、変更をいつ適用するかを選択します。「すぐに適用」を選択すると、すぐに変更が適用されます（DBインスタンスの再起動が必要な場合あり）。
    • 「変更を適用」をクリックして設定を完了します。

Terraformでの修復手順

TerraformでAurora MySQL DBクラスターの監査ログをCloudWatch Logsに発行するように設定するには、aws_rds_cluster リソースの enabled_cloudwatch_logs_exports パラメータと、aws_rds_cluster_parameter_group の関連パラメータを設定します。

# Aurora MySQL DBクラスターパラメータグループの定義
resource "aws_rds_cluster_parameter_group" "aurora_mysql_audit" {
  name        = "aurora-mysql-audit-pg"
  family      = "aurora-mysql8.0" # またはお使いのAurora MySQLのバージョンに合わせて変更
  description = "Custom parameter group for Aurora MySQL with audit logging"

  # 監査ログを有効化する
  parameter {
    name  = "server_audit_logs"
    value = "1"
  }

  # 監査するイベントの種類を指定 (例: CONNECT, QUERY, TABLE など)
  # 必要に応じてカスタマイズしてください
  parameter {
    name  = "server_audit_events"
    value = "CONNECT,QUERY,TABLE"
  }

  # 監査ログの出力先を設定 (通常はデフォルトの FILE ですが、CloudWatch Logsと連携されるため明示的に指定は不要)
  # parameter {
  #   name  = "server_audit_output_type"
  #   value = "FILE" # FILE以外に設定するとCloudWatch Logsに発行されない場合があります
  # }
}

# Aurora MySQL DBクラスターの定義
resource "aws_rds_cluster" "aurora_cluster" {
  cluster_identifier      = "my-aurora-cluster"
  engine                  = "aurora-mysql"
  engine_version          = "8.0.mysql_aurora.3.02.2" # お使いのバージョンに合わせて変更
  availability_zones      = ["ap-northeast-1a", "ap-northeast-1c"] # リージョンに合わせて変更
  database_name           = "mydb"
  master_username         = "admin"
  master_password         = "yourpassword" # 適切なシークレット管理ツールを使用してください
  db_cluster_parameter_group_name = aws_rds_cluster_parameter_group.aurora_mysql_audit.name
  skip_final_snapshot     = true

  # CloudWatch Logsにエクスポートするログタイプを指定
  enabled_cloudwatch_logs_exports = ["audit"] 
  
  # その他のクラスター設定...
  # backup_retention_period = 7
  # preferred_backup_window = "07:00-09:00"
}

上記の例では、まずaws_rds_cluster_parameter_groupリソースを使用して、server_audit_logsパラメータを1に設定したカスタムパラメータグループを作成しています。次に、aws_rds_clusterリソースでAurora MySQLクラスターを定義し、そのdb_cluster_parameter_group_nameに作成したパラメータグループを関連付け、enabled_cloudwatch_logs_exportsに["audit"]を指定することで、監査ログをCloudWatch Logsに発行するように設定しています。

yourpasswordやその他のプレースホルダーは、実際の環境に合わせて修正してください。特にパスワードはHashiCorp VaultやAWS Secrets Managerなどの安全な方法で管理してください。

最後に

この記事では、Aurora MySQL DBクラスターのCloudWatch Logsへの監査ログ発行が有効化されていない状態について、リスクと対策を解説しました。データベースの監査ログを適切に設定し、CloudWatch Logsに発行することは、セキュリティ監視、インシデント対応、およびコンプライアンス遵守のために極めて重要です。これにより、データベースアクティビティの透明性を高め、潜在的な脅威からシステムを保護することができます。

この問題の検出は弊社が提供するSecurifyのCSPM機能で簡単に検出及び管理する事が可能です。

運用が非常に楽に出来る製品になっていますので、ぜひ興味がある方はお問い合わせお待ちしております。

最後までお読みいただきありがとうございました。この記事が皆さんの役に立てば幸いです。

この記事をシェアする

クラウドセキュリティ対策実践集一覧へ戻る

貴社の利用状況に合わせた見積もりを作成します。

見積もりを希望する
資料ダウンロード

料金プランを詳しく見る