GuardDutyがRDSのログイン後の操作まで監視するようになった

Aurora PostgreSQLやRDS for PostgreSQLに、AWSのセキュリティ監視サービスGuardDutyの「RDS Protection」を入れているとする。見ているのはログインの異常だけだ。では、フィッシングや設定ミスで漏れた正規のユーザー名とパスワードをそのまま使われたらどうなるか。

答えは、2026年10月8日までは「気づけない」だった。ログインの瞬間しか見ていなかったからだ。この日AWSが追加した「データアクティビティ監視」で、ログインした後に何をしたかまで見られるようになった(AWS公式発表)。エージェントの追加もログの設定変更も要らず、対象のデータベースなら今日から有効にできる。

ログイン監視だけでは何が見逃されるのか

ログイン監視は、具体的に何を見ていて、何を見ていなかったのか。

GuardDuty RDS Protectionは2023年5月、Auroraのログイン監視として始まった(AWS Security Blog)。見ているのは「誰が」「どこから」ログインしたかだ。見慣れないユーザーの初回ログイン、ブルートフォースらしい失敗の連続、既知の悪意あるIPやTor経由のアクセスを、機械学習でベースラインから外れた挙動として検知する。

ここに死角がある。盗まれた認証情報は、ログインの瞬間だけを見れば「いつもの正規ユーザーがいつもどおりログインした」ようにしか映らない。パスワードが本物である以上、ログイン監視の土俵には最初から上がってこない。では、ログインした後の行動まで見れば、この死角は塞げるのか。

クエリの量と種類から異常を見分ける

発表文を最初に読んだときは、ログイン監視の延長線上にある機能だと思っていた。だが仕組みを読み込むと、見ている対象がまったく違うと気づいた。データアクティビティ監視が見るのは、ログインした後に実行されたSELECT・DROP・DELETE文だ。機械学習モデルがユーザーごと・データベースごとに正常なクエリパターンの基準をつくり、そこから外れた活動を検知する(公式ドキュメント)。

具体的な検知対象は3種類ある。

• データの不正流出(Exfiltration:RDS/AnomalousBehavior): 通常より大幅に多い行数を返すSELECT文
• テーブル等の削除(Impact:RDS/AnomalousBehavior.Drop): 通常と異なるパターンのDROP文
• 行の削除(Impact:RDS/AnomalousBehavior.Delete): 通常より大幅に多い行数を削除するDELETE文

見慣れたアカウントが、深夜に普段の数百倍の行数を読み出した場面を想像してほしい(仮の例)。ログイン自体は正規の手続きどおりでも、この読み出し量の異常がデータアクティビティ監視には引っかかる。では、そのすべてが同じ重さで扱われるのかというと、そうではない。

重大度はどう決まるか

3種類の検知結果(finding)はいずれも、重大度がLow・Medium・Highの3段階に分かれる。条件は次のとおりだ(公式ドキュメント)。

同じ「大量に読む」「大量に消す」という行為でも、社内ネットワークからの一時的な集計作業と、見たことのない公開ネットワークからの操作では、割り当てられる重大度が変わる。量だけでなく、どこから・誰の権限で行われたかの組み合わせで判定される設計だ。自分には、社内からの大量アクセスを正規のバッチ処理に近いものとして低く見積り、見たことのない公開ネットワークからの大量アクセスほど盗まれた認証情報による不正操作に近いと判断する設計に見える。

Highのfindingが出た場合、AWSは該当ユーザーのパスワード変更とアクセス権の見直し、監査ログでの操作範囲の確認を推奨している(公式ドキュメント)。DROP・DELETEのfindingでは、バックアップからの復旧も選択肢に挙がる。

使うにはどうすればいいか

有効化はGuardDutyコンソールでワンクリック、またはAPI・SDK・CLI・AWS CloudFormationからも可能だ。ただし単独では有効にできない。データアクティビティ監視を使うには、先にログイン監視を有効にしておく必要がある(GuardDuty公式料金ページ)。

料金はvCPU単位の月額課金で、ログイン監視が1vCPUあたり1.00ドル/月、データアクティビティ監視は1vCPUあたり3.00ドル/月と3倍になる(公式料金ページ)。公式料金ページの計算例では、4vCPUのインスタンス3台にログイン監視だけを適用すると月額12ドル、そこにデータアクティビティ監視を足すと月額48ドルになる。

同じ3台構成で、データアクティビティ監視を足すだけで月額コストが4倍になる。初回は30日間の無料トライアルがあり、有効化後は最大2週間の学習期間を経て通常のクエリパターンが基準化される(公式ドキュメント)。この期間は異常検知のfindingが出ないことがある。ここまでの金額と設定の話は、どのデータベースエンジンでも同じように当てはまるのか。

今すぐ使えるデータベース

対応エンジンには差がある。ログイン監視は主要なエンジンに幅広く対応しているが、データアクティビティ監視が対応するのはAurora PostgreSQLとRDS for PostgreSQLの2つに限られる(公式ドキュメント)。対応状況をまとめると次のとおりだ。

今回の機能拡張が対象にしているのはPostgreSQL系のデータベースで、MySQL系やMariaDBでAuroraやRDSを運用している場合は、対応エンジンが広がるのを待つことになる。

まとめ

ログイン監視だけでは、盗まれた認証情報による正規のログインを見逃す死角があった。2026年10月8日に追加されたデータアクティビティ監視は、ログインした後のSELECT・DROP・DELETEの量と組み合わせを見ることで、この死角を塞ぐ。重大度は「どこから・どれだけ・誰の権限で」の組み合わせで決まり、社内からの一時的な大量操作と、見たことのない公開ネットワークからの操作とでは扱いが変わる。

現時点で対象はAurora PostgreSQLとRDS for PostgreSQLのみで、月額コストはログイン監視の3倍の単価がかかる。すでにログイン監視を使っていてPostgreSQL系のデータベースを運用しているなら、追加の設定なしでそのまま有効化できる。