RDS や Aurora の本番データベースを預かっていると、「正しいパスワードで入られたら、そのあと何をされても気づけるのか」と聞かれて答えに詰まることがあります。GuardDuty の RDS Protection は不審なログインを見てくれますが、見慣れた場所から正しい資格情報で入られると、入ったあとの大量の読み出しや削除は別の仕組みで見るしかありませんでした。2026年10月8日の発表で、この「入ったあと」の部分を GuardDuty が見られるようになりました。この記事では、何が加わったか、ログインの監視とどう違うか、有効にする前に何を決めておくかを整理します。
この記事の結論
- GuardDuty の RDS Protection に、データベースに対するデータの操作を監視する機能（RDS Protection for data activity）が加わりました。
- 見るのは、大量の読み出しによる持ち出しと、削除や DROP による破壊の兆候です。機械学習の異常検知と脅威の情報を使います。
- 発表の時点の対象は Aurora PostgreSQL と RDS for PostgreSQL で、ログインの監視を有効にしたうえで足す機能です。
- 料金はログインの監視とは別にかかります。金額は公式の料金ページで確かめてから見積もります。
- GuardDuty は検出して知らせるだけで、クエリは止めません。届け先と対応の手順は自分で決めておきます。
何が起きたか
2026年10月8日、AWS は Amazon GuardDuty の RDS Protection の拡張を発表しました。これまで RDS Protection が見ていたのは、データベースへのログインの動き（成功と失敗）でした。今回加わった「データの操作の監視」は、ログインしたあとに実行されたクエリのパターンを継続的に見て、データの持ち出しと破壊の兆候を検出します。
発表と公式の案内から読み取れる要点は次のとおりです。
- 対象のエンジン: データの操作の監視は、発表の時点で Amazon Aurora PostgreSQL と Amazon RDS for PostgreSQL が対象です。ログインの監視は、これまでどおり Aurora（MySQL・PostgreSQL）、RDS for PostgreSQL・MySQL・MariaDB が対象です
- 見方: 機械学習による異常検知と、GuardDuty が持つ脅威の情報を組み合わせて判定します。エージェントの導入、追加の基盤、データベースの設定変更は要らないと案内されています
- 使い始め方: ログインの監視に足す形の機能で、ログインの監視を有効にしていないと使えません。コンソールから組織全体に有効化できるほか、API・SDK・CLI・CloudFormation でも設定できます
- 提供範囲: すべての商用リージョンと AWS GovCloud (US) で使えます
- 料金: ログインの監視とは別に課金されます。単価と無料トライアルの扱いは公式の料金ページで確認してください
公式の発表はこちらです。
仕組みとして何が変わったか
これまでの RDS Protection は、言ってみれば「誰が、どこから、どう入ってきたか」を見る門番でした。見慣れない場所からのログインや、総当たりのような失敗の繰り返しは拾えます。けれども、アプリの資格情報が漏れて、普段どおりの経路から正しいパスワードで入られた場合、門番の目には「いつもの人」に見えます。そのあとに顧客の表を丸ごと読み出されても、ログインの監視だけでは気づく材料がありませんでした。
BEFORE / AFTERGuardDuty RDS Protection
「誰が入ったか」に加えて、入ったあと何をしたかを見る
これまで
ログインの監視だけ
- ログインの成功・失敗の異常を検出見慣れない場所・総当たりのような試行
- 入ったあとのクエリは見ていない正しい資格情報で入られると、持ち出しは別の仕組み頼み
これから
データの操作も監視（追加の機能）
- データの操作（DML・DDL）の異常を検出大量の読み出し・普段と違う削除や DROP
- ログインの監視を有効にしたうえで足す対象は Aurora PostgreSQL と RDS for PostgreSQL
今回加わったのは、入ったあとのデータの操作（DML・DDL）を見る目です。SELECT でふだんより桁違いに多くの行を読む、見慣れないロールが DELETE や DROP を流す、といった動きを、普段の振る舞いと比べて異常かどうかで判定します。
検出結果はどう出るか
検出結果の種類は、持ち出しなら Exfiltration:RDS/...、破壊なら Impact:RDS/... で始まる名前で出ます（例: 大量の読み出しは Exfiltration:RDS/AnomalousBehavior）。重要度は一律ではなく、送信元が公開されたネットワークか、権限の強いロールか、読み出した量がどれだけ普段と違うか、といった条件で変わります。正確な種類の一覧と重要度の決まり方は、公式の検出結果の種類のページで確かめてください。
| 比べる点 | ログインの監視（これまで） | データの操作の監視（今回） |
|---|---|---|
| 見るもの | ログインの成功・失敗 | 入ったあとのクエリ（読み出し・削除・DROP など） |
| 拾える例 | 見慣れない場所からのログイン、総当たり | 正しい資格情報での大量の持ち出し、表の削除 |
| 対象のエンジン | Aurora（MySQL・PostgreSQL）、RDS for PostgreSQL・MySQL・MariaDB | Aurora PostgreSQL、RDS for PostgreSQL（発表の時点） |
| 使い方 | 単独で有効にできる | ログインの監視に足して有効にする |
誰の責任が動いたか
これまで「入ったあと」を見たければ、データベースの監査ログを集め、どの操作を怪しいとみなすかのルールを自分で書いて、普段の量との比較も自分で組む必要がありました。今回の変更で、その検知の部分を GuardDuty に任せられるようになります。
一方で、動いていない責任もあります。誰にどの表への権限を渡すか、検出結果を誰が受けて何をするか、怪しい操作を止めるかどうかは、これまでどおり利用者の側に残ります。GuardDuty は知らせるサービスで、クエリを止めることはしません。
CHECK 1ここまでの確認
今回の追加で、GuardDuty の RDS Protection が新しく見るようになったものはどれ?
答えと解説
答え: 2. データベースに対するデータの操作（大量の読み出し・削除・DROP など）の異常
ログインの成功と失敗は、これまでの RDS Protection が見ていたものです。今回加わったのは、入ったあとのデータの操作（DML・DDL）の監視です。CPU や容量は CloudWatch で見るもので、GuardDuty の役割ではありません。「仕組みとして何が変わったか」の節を読み直してください。
どんなものに活用できそうか
FROM QUERY TO RESPONSE検出から対応までの流れ
検出は入口。届いたあと誰が何をするかまで決めておく
-
クエリが走る
普段と違う量・時間・送信元
-
判定する
GuardDuty が普段の振る舞い・脅威の情報と比べる
-
検出結果が出る
持ち出しは Exfiltration、破壊は Impact
-
届ける
EventBridge で担当へ通知
-
人が対応する
資格情報の変更・監査ログの確認
例1: 顧客情報を持つ PostgreSQL の本番データベース
会員情報や注文履歴を Aurora PostgreSQL に置いているサービスで、アプリ用のユーザーが深夜に普段の何倍もの行を読み出した、という動きを持ち出しの候補として拾えます。アプリの資格情報が漏れたときに「入ったあと」で気づける層が1枚増える、という使い方です。検出結果は EventBridge に届くので、セキュリティの担当の通知先とチケットの起票につないでおきます。
例2: 権限の強いロールの誤操作と、内部からの不正
運用者のロールで見慣れない DROP や大量の DELETE が流れた、という動きは、外からの攻撃でなくても事故の入口です。検出されたら、資格情報の変更と監査ログの確認に加えて、スナップショットやポイントインタイムリカバリからどの時点に戻すかの判断に進みます。公式にも、侵害された可能性のあるデータベースへの対応手順のページがあります。
例3: 複数のアカウントにまとめて広げる
アカウントを分けて運用している組織では、GuardDuty の委任管理者のアカウントから、新しく加わるアカウントも含めて自動で有効にできます。ただし料金は保護するインスタンスの vCPU の数で決まるので、全部に一律で入れるか、顧客データを持つアカウントから入れるかを、費用の見積もりと合わせて決めます。
使わない方がよい場面
MySQL 系や MariaDB のデータベースは、発表の時点ではデータの操作の監視の対象外です。有効にしてもこの機能の検出は出ないので、ログインの監視までで止め、対象が広がるのを待ちます。また、異常検知は普段の振る舞いを学んでから判定する仕組みなので、数時間で作って消す検証用のデータベースでは効果が見えにくいと考えられます。
CHECK 2ここまでの確認
データの操作の監視を使い始める前の確認として、正しいものはどれ?
答えと解説
答え: 2. ログインの監視が有効になっているかと、対象のエンジンが PostgreSQL 系かを確かめる
データの操作の監視はログインの監視に足す機能で、発表の時点の対象は Aurora PostgreSQL と RDS for PostgreSQL です。エージェントは要りません。GuardDuty は検出して知らせるだけで、クエリは止めないので、届け先と対応の手順は自分で決めます。「どんなものに活用できそうか」の節を読み直してください。
立場ごとに何が変わるか
- 未経験: いまは関係ありません。本番のデータベースを預かる段階になってから効いてくる話です。「入口だけでなく、入ったあとの動きも見る」という考え方だけ覚えておけば十分です
- 学習中: AWS Certified Security - Specialty（SCS-C03）の「検知」の分野に関係します。GuardDuty の保護プランは、S3 Protection が S3 のデータの操作を見るのと同じ形で、データベースにも広がったと並べて覚えると整理しやすくなります。試験の範囲に入るかどうかは、受ける版の試験ガイドで確かめてください
- 実務: PostgreSQL 系の本番データベースがあるなら、ログインの監視が有効か、保護するインスタンスの vCPU の合計でいくらかかるか、検出結果を EventBridge から誰に届けるかの3点を先に決めます
- プロ: 自前で組んできた監査ログの検知と、GuardDuty の検出の重なりを整理します。組織全体に一律で入れるか、データの重要度でアカウントごとに絞るか、誤検知が続いたときの抑制ルールをどう置くかが設計の論点です
まとめ
- GuardDuty の RDS Protection は、ログインの監視に加えて、入ったあとのデータの操作も見られるようになりました
- 発表の時点の対象は Aurora PostgreSQL と RDS for PostgreSQL で、ログインの監視を有効にしたうえで足す機能です
- 料金はログインの監視とは別にかかるので、vCPU の合計で見積もってから範囲を決めます
- GuardDuty は知らせるだけで、止める仕組みと対応の手順は自分で用意します
参照ソース
- Amazon GuardDuty RDS Protection now detects data exfiltration and destruction in Aurora and RDS databases（2026年10月時点）— 発表の内容（対象のエンジン・提供範囲・有効化の方法）
- GuardDuty RDS Protection（2026年10月時点）— RDS Protection の全体と、ログインの監視の対象エンジン
- GuardDuty RDS Protection finding types（2026年10月時点）— 検出結果の種類と重要度の決まり方
- Amazon GuardDuty の料金（2026年10月時点）— 課金の単位（vCPU・ACU）と、ログインの監視との別課金
- Remediating a potentially compromised database（2026年10月時点）— 検出後の対応の手順
- Enabling RDS Protection in multiple-account environments（2026年10月時点）— 委任管理者からの自動有効化
