GuardDuty の RDS データアクティビティ監視を有効にするAurora・RDS for PostgreSQL のデータ持ち出しと削除を検出

2. 追加された検出タイプ

データアクティビティ監視で追加された検出タイプは 7 つです。重要度は AWS のドキュメントに記載されている既定値です。

AnomalousBehavior の 3 つは、接続元と実行したユーザーによって重要度が変わります。

• LOW:プライベートネットワークの IP から実行された(Drop を除く)
• MEDIUM:パブリック IP から実行された(Drop は異常な DROP があった時点で MEDIUM)
• HIGH:量が普段より大幅に多く、かつ見たことのないパブリックネットワークから、または高い権限のロールや管理用クライアントから実行された

VPC 内のアプリケーションサーバーの認証情報が使われた場合、接続元はプライベート IP になるため、Exfiltration と Delete は LOW で出ることがあります。7 章の通知ルールで扱いを決めておきます。

3. 対応する DB とバージョン

RDS for PostgreSQL のリードレプリカは、プライマリが対応バージョンで、正常にレプリケーションされていることが条件です。MySQL 系の DB しかないアカウントでは、データアクティビティ監視の検出は出ません。

4. コンソールで有効にする

Organizations を使っている場合、設定を変更できるのは GuardDuty の委任管理者アカウントだけです(メンバーアカウントからは変更できません)。当社ではセキュリティ専用アカウントを委任管理者にしているので、そこから操作しました。

1. 委任管理者アカウントで GuardDuty コンソールを開く
2. 左メニューの「Protection Plans」→「Configure all enablements」
3. 「RDS Protection」の下に「RDS Login Activity Monitoring」と「RDS Data Activity Monitoring」が並んでいる
4. 「RDS Data Activity Monitoring」の「This account」を Enabled、「Auto enable for organization accounts」を「Enable for all accounts」にする
5. 「Save all」→「Confirm and save」

画面には「RDS Protection for login activity is required for RDS Protection for data activity to function.」と表示されます。ログイン監視が無効なアカウントでは、先にログイン監視を有効にします。

「Enable for all accounts」は、既存のメンバーアカウントと、今後組織に追加されるアカウントの両方が対象です。新しいアカウントだけを対象にする場合は「Configure accounts manually」→「Automatically enable for new member accounts」を選びます。

5. AWS CLI で有効にする

データアクティビティ監視は、RDS_LOGIN_EVENTS の AdditionalConfiguration に RDS_DATA_RISK として指定します。以下はすべて委任管理者アカウント(プロファイル example-security)で実行します。

委任管理者アカウント自身

DET=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text \
        --profile example-security)

aws guardduty update-detector \
  --detector-id $DET \
  --features '[{
    "Name": "RDS_LOGIN_EVENTS",
    "Status": "ENABLED",
    "AdditionalConfiguration": [
      { "Name": "RDS_DATA_RISK", "Status": "ENABLED" }
    ]
  }]' \
  --profile example-security

組織の全アカウント(既存 + 新規)

aws guardduty update-organization-configuration \
  --detector-id $DET \
  --auto-enable-organization-members ALL \
  --features '[{
    "Name": "RDS_LOGIN_EVENTS",
    "AutoEnable": "ALL",
    "AdditionalConfiguration": [
      { "Name": "RDS_DATA_RISK", "AutoEnable": "ALL" }
    ]
  }]' \
  --profile example-security

AutoEnable を NEW にすると新規アカウントだけ、NONE にすると自動有効化をやめます。

特定のメンバーアカウントだけ

aws guardduty update-member-detectors \
  --detector-id $DET \
  --account-ids <ACCOUNT_ID_1> <ACCOUNT_ID_2> \
  --features '[{
    "Name": "RDS_LOGIN_EVENTS",
    "Status": "ENABLED",
    "AdditionalConfiguration": [
      { "Name": "RDS_DATA_RISK", "Status": "ENABLED" }
    ]
  }]' \
  --profile example-security

成功すると UnprocessedAccounts が空の配列で返ります。ログイン監視は有効のまま、データアクティビティ監視だけを止める場合は、RDS_DATA_RISK の Status を DISABLED にします。

全リージョンにまとめて適用する

for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text \
             --profile example-security); do
  DET=$(aws guardduty list-detectors --region $r \
          --query 'DetectorIds[0]' --output text --profile example-security)
  aws guardduty update-organization-configuration --region $r \
    --detector-id $DET \
    --auto-enable-organization-members ALL \
    --features '[{"Name":"RDS_LOGIN_EVENTS","AutoEnable":"ALL",
      "AdditionalConfiguration":[{"Name":"RDS_DATA_RISK","AutoEnable":"ALL"}]}]' \
    --profile example-security
done

6. 有効化の確認

有効にした直後のコンソールでは、委任管理者アカウント自身は Enabled(Free trial: 30 days)になりましたが、「Active organization member accounts」は 0/3 のままでした。AWS のドキュメントにある通り、メンバーアカウントへの反映には最大 24 時間かかります。

# 委任管理者アカウント自身の状態
aws guardduty get-detector --detector-id $DET --profile example-security \
  --query 'Features[?Name==`RDS_LOGIN_EVENTS`]'

# メンバーアカウントごとの状態
aws guardduty get-member-detectors --detector-id $DET \
  --account-ids <ACCOUNT_ID_1> <ACCOUNT_ID_2> --profile example-security \
  --query 'MemberDataSourceConfigurations[].[AccountId, Features[?Name==`RDS_LOGIN_EVENTS`].AdditionalConfiguration[]]'

RDS_DATA_RISK の Status が ENABLED になっていれば完了です。コンソールでは、左メニューの「Accounts」に「RDS data activity」列があり、アカウントごとの状態を一覧で確認できます。

7. 通知ルールの見直し

前回の記事で作った通知ルール(Security Hub に集約された GuardDuty の検出のうち、重要度 MEDIUM 以上・未対応のもの)は、検出タイプで絞っていないため、追加の設定なしで今回の検出も通知されます。

ただし 2 章の通り、VPC 内からの読み出しや削除は LOW で出ることがあり、このルールでは通知されません。LOW の検出は Security Hub の画面で定期的に確認するか、DB の重要度が高い環境では、RDS の検出に限って LOW も通知するルールを別に作ることを検討します。

通知の動作確認には、GuardDuty のサンプル検出を使えます。重要度 HIGH の検出タイプを指定すると、MEDIUM 以上のルールで通知されるかを確認できます。

aws guardduty create-sample-findings \
  --detector-id $DET --finding-types "Impact:RDS/MaliciousIPCaller" \
  --profile example-security

確認後は、サンプルの検出をアーカイブしておきます。

8. 費用と注意点

• 30 日間の無料トライアルがある。すでにログイン監視を使っているアカウントでも、データアクティビティ監視を初めて有効にしたときにアカウント・リージョンごとに 30 日の無料トライアルが付きます。トライアルが終わっても自動では無効にならないため、期間中に GuardDuty コンソールの「Usage」で月額の見込みを確認します。
• 料金は DB の規模に比例する。ログイン監視とは別に、DB インスタンスの vCPU(Aurora Serverless v2 は ACU)の量に応じて課金されます。単価はリージョンで異なるため、GuardDuty の料金ページで確認してください。
• クエリのログは見られない。GuardDuty はデータアクティビティのログを利用者に公開しません。検出が出たときに「どのテーブルの何行が読まれたか」を調べるには、pgAudit などで DB 側の監査ログを取っておく必要があります。
• 検出は入口であって、対策ではない。AWS が示している対応も、DB ユーザーのパスワード変更、監査ログでの影響範囲の確認、必要に応じたバックアップからの復旧、DB をプライベートサブネットに置きセキュリティグループで接続元を絞ること、です。検出が出る前に、DB がインターネットに公開されていないか、アプリケーション用のユーザーに DROP の権限が付いていないかを確認しておきます。