5
1

More than 1 year has passed since last update.

Amazon GuardDuty RDS Protectionについて調べてみた

Last updated at Posted at 2023-01-03

はじめに

re:Invent 2022のリリースの中でGuardDutyの新機能としてRDS Protectionが発表されました(プレビュー)。GuardDutyはEC2やS3、VPCフローログ、DNSログ、CloudTrail管理ログなどを継続的にモニタリングする事で悪意あるアクティビティを調査してくれる脅威検知サービスです。

今回のリリースではそのモニタリング対象としてRDSが追加されたという内容になります。まだプレビューでGAはされていませんが、具体的に何をしてくれるものなのかを再確認する意味も含めて調べてみようと思い、その記録として書いていきます。

RDS Protectionがしてくれること

  • AuroraDBインスタンスへのログインアクティビティの監視
  • 疑わしいアクティビティの検出(不正アクセスなど)
  • 侵害された可能性のあるDBインスタンスに関するレポートの生成

対象

サポートされているRDSは、現時点では以下のAuroraDBバージョンに限定されます。

DBエンジン バージョン
Aurora MySQL 2.10.2 および 3.2.1 以降
Aurora PostgreSQL 10.17、11.12、12.7、13.3、および 14.3 以降

検出結果タイプ

GuardDuty RDS Protectionは2種類の検出結果タイプをサポートしています。

検出結果タイプ 重大度 概要 想定する原因 対応
CredentialAccess:RDS/
AnomalousBehavior.SuccessfulLogin
ユーザーが異常な方法でRDSデータベースに正常にログインしました RDSのなどロール侵害、資格情報の漏洩 パスワード変更、侵害されたユーザによって実行されたアクティビティの調査
CredentialAccess:RDS/
AnomalousBehavior.FailedLogin
RDSデータベースで異常なログイン試行の失敗が1回以上観察されました 悪意ある者からのブルートフォースなどのによる攻撃 アクセスポリシーやNW構成、SGなどの見直し

有効化

新規アカウントであればGuardDutyそのものを有効化した時点でRDS Protectionも自動的に有効化されますが、既存アカウントの場合はコンソール上で有効化する必要があります。※2022/12時点

スクリーンショット_2023-01-03_22_26_52.png

初めてRDS Protectionを有効にする場合や、新しく作成されたデータベースインスタンスがある場合は、通常の動作のベースラインを設定するために最大2週間の学習期間が必要です。その間、異常なログイン結果が関連付けられていない可能性があります。

RDS Protectionによる調査結果

具体的にどういったレポートが出力されるのかパッと全容が分かるものが見つけられなかったので参考にre:Inventにて発表された内容として以下が挙げられます。

スクリーンショット 2023-01-03 23.07.52.png

  • 異常な動作がログイン成功か失敗か
  • ユーザやDB、アプリケーション名、DBにアクセスしたASN
  • 不正アクセスされたDBと不正アクセスに関与したユーザの詳細
  • DBに不正アクセスしたIPアドレス、国、ASN

侵害されたデータベースの修復

AWSはGuardDuty RDS Protectionにて脅威検知したDBに対して、それぞれ以下の方法で修復を推奨としておりました。

成功したログインイベントで侵害された可能性のあるデータベースに対して

  1. 影響を受けるデータベースとユーザーの特定
    1. レポートにより、影響を受けるDBの名前と対応するユーザーの詳細を確認
  2. 動作が予期されたものか予期しないものかを確認
  3. データベースインスタンスへのアクセスを制限
    1. 疑わしいアカウントやユーザのDBアクセスを制限
  4. アクセスされた情報を特定
    1. 監査ログを確認
    2. アクセスされた可能性のある情報を特定
    3. 機密情報などがアクセスまたは変更されたかどうかを確認

失敗したログインイベントでデータベースが侵害された可能性がある場合

  1. 影響を受けるデータベースとユーザーを特定
    1. レポートにより、影響を受けるDBの名前と対応するユーザーの詳細を確認
  2. 失敗したログイン試行の原因を特定
    1. レポートにより、IPアドレスとASN組織を特定
  3. この動作が予期しないものであることを確認
    1. プリケーションの構成が間違っていないか
    2. 接続を繰り返し試行しているかどうか
    3. DBがパブリックに公開されているか
    4. インフラ構成が誤っているかどうか
  4. DBへのアクセスを制限
  5. このアクティビティの原因を分析して可能性のある手順を特定

侵害された可能性のある資格情報に対して

  1. レポートのresource.rdsDbUserDetailsより、ユーザ詳細(ユーザー名、使用したアプリケーション、アクセスしたデータベース、SSL バージョン、認証方法)を確認
  2. 資格情報の保護パターン
    1. 特定ユーザーのアクセスを取り消すか、パスワードをローテーション
    2. Secrets Managerを使用して、データベースのシークレットを安全に保存し、自動的にローテーション
    3. IAMデータベース認証を使用して、パスワードを必要とせずにDBユーザーのアクセスを管理

ネットワークアクセスを制限する場合

  1. レポートのresource.rdsDbInstanceDetails.dbSecurityGroupsにより、セキュリティグループの精査
  2. NACLの再構成

まとめ

GuardDutyのRDS Protection機能について調査してみました。ベースライン確立までに最大2週間かかるということで、実際の不正ログインレポートを確認するところまでやりたかったですが持ち越しとなりました。まだプレビューではありますがDBへの不正ログインを脅威検知できる素晴らしい機能ですので、GAされたら是非とも必須導入としていきたいですね。

5
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
1