GuardDuty RDS Protectionがデータ流出・破壊の検知に対応

AWSで不審な動きを見張るAmazon GuardDutyが、データの読み取りや削除の異常にも監視を広げました。2026年10月8日の発表から、ログイン後の操作と、アプリ側で決める権限の確認点を整理します。

AWSの発表によると、RDS Protection（AWSのデータベースサービスRDSなどを監視する機能）はログインの異常に加え、データの流出や破壊を狙う操作を検知するようになりました。新しいデータ操作の保護は、AWS上で動くデータベース（DB）のAurora PostgreSQLとRDS for PostgreSQLが対象です。

正しいログイン情報でも、操作は確認する

AWSが背景として挙げているのは、正しいログイン情報を使ったアクセスです。ログインを通過できても、その後の読み取りや削除まで適切とは限りません。今回の追加機能は、データの取得・変更を指示するクエリの傾向から異常を探します。

認証情報が合っていることと、普段どおりの操作であることを分けて見る。その考え方は、自分のアプリを見直すときにも使います。ログインの成否だけを見ていると、入った後に起きていることが抜けてしまいます。

公式のRDS Protection解説も、ログインの監視とデータ操作の監視を分けています。対応するDBの範囲も異なります。導入を考えるときは「RDSだから使える」で済ませず、使うエンジン、バージョン、有効化の条件まで確認します。

日記なら「誰の日記を編集できるか」まで見る

小さな日記アプリを考えると、ログイン済みかどうかの確認に加えて、その日記を編集できる人かどうかの判定が要ります。他の人の日記のIDを指定したとき、読み取りや更新をどこで止めるか。画面にボタンを出すかだけでなく、処理を受ける側の条件を見ます。

読み取りと削除でも、必要な権限は違います。一覧を表示するための取得と、データをまとめて消す処理を同じ感覚で扱うと、許す範囲が広くなります。機能ごとに、誰がどのデータへ何をできるかを書き出すと、確認する場所が具体的になります。

監視サービスを追加しても、この権限判定はアプリ側で決める必要があります。私なら、まず日記を一件読む操作と一件消す操作を選び、それぞれの条件を追います。その上で、許可された操作の中から異常をどう探すかを考えます。

通知が来た後、どの操作を確認するか

検知の機能を知ると、通知を受けた後の動きも気になります。どのDBで、どんな操作があったのか。普段の処理と見分けるには、何を見ればよいのか。通知を見る人が、アプリのどの機能に結び付けて確認するかまで考えておきます。

たとえば、大量の読み取りがあっても、予定していたデータ出力かどうかで確認の仕方が変わります。削除も、利用者の操作なのか、管理用の処理なのかで追う場所が違います。通知だけを眺めるより、通常の処理を説明できる状態にしておく方が、調べ始めやすそうです。

使うDBに合わせて監視を考える

日記の作例はSQLiteというDBなので、この機能の対象外です。対象はAurora PostgreSQLとRDS for PostgreSQL。入力したイベントを日報につなぐアプリProject-ORBITの作例には、ローカルでPostgreSQLを使う構成があります。PostgreSQLという名前が共通でも、AWS上の対応サービスを使う構成とは分けて考えます。

アプリの構成は、個人開発アプリの紹介ページにまとめています。

まだ試していないので、次に触るときは通知の内容と、操作を追うために必要な情報を確かめたいです。