Amazon Q Developer CLI を利用してGuardDutyの抑制ルールを管理する

Last updated at 2025-07-06Posted at 2025-07-06

はじめに

kyonosukeです。
前回の記事ではAmazon Q Developer CLI にGuardDutyのインシデント調査を行ってもらいました。

GuardDutyを運用するうえで、ノイズとなる無視してもよいインシデントの管理は工数がかかる部分であり、同時に必要なタスクです。今回はこのようなインシデントを抑制するルールについておさらいしたあと、Amazon Q に作成してもらいます。

本記事は、2025 Japan AWS Jr. Champions Qiitaリレー夏の3日目の記事です！

Jr. Championsによって、今後もたくさんの記事が投稿されるのでお楽しみに！

抑制ルールの基礎知識

2種類のステータス

抑制ルールの前にGuardDutyのインシデントのステータスについて再確認しましょう。
GuardDutyのインシデントには「最近」「アーカイブ済み」の2種類が存在します。

いや「最近」ってなんだよって感じですが、マネジメントコンソールにそのように記載があるので受け入れます。「ステータス」が不自然に改行されているのも気になる。

「最近」はインシデントの対応状況がアクティブな状態のことです。インシデントが発生した状態のデフォルトステータスは「最近」です。そのインシデントがまだ調査中であるならば、ステータスは変更しないでおきましょう。

「アーカイブ済み」は逆にインシデントの対応状況がクローズな状態のことです。「アーカイブ済み」のインシデントは検出結果の画面から見えなくなります。ステータスのフィルタを「アーカイブ済み」にするとアーカイブされたインシデントのみが表示されます。ユースケースとしては、インシデント調査が完了したらステータスを「アーカイブ済み」にする運用が考えられます。

抑制ルールとは

2種類のステータスについて分かっていただけたところで、抑制ルールの説明です。
抑制ルールとは、フィルタ条件に一致する新規検出のインシデントのステータスを「アーカイブ済み」に設定する機能のことです。フィルタ条件に引っかかるインシデントは発生した段階でアーカイブされます。

どんな組織にも「このインシデントよく発生するけど、業務上の通常動作を検知しているだけなんだよな～」「危険性ないから無視で良いんだよな〜」というインシデントがあるかと思います。セキュリティ運用においてこのようなインシデントはFalse Positiveと呼ばれています。直訳すると偽陽性です。要は誤って陽性と判定されるアクテビティのことです。インシデント発生の通知が来るたびに飛び起きなければならないセキュリティ担当者にとって、False Positiveは悪でしかありません。

GuardDutyでは適切なフィルタを設定することでFalse Positiveを自動でアーカイブすることができます。抑制ルールを設定することで、見なくていいインシデントを見なくてよくなるのでノイズが減り、セキュリティ担当者が対応すべきインシデントのみに集中することができます。セキュリティ担当者の睡眠時間のために、抑制ルールは必要不可欠です。

また、アーカイブに設定すると検出結果に表示されなくなるだけでなく、他のAWSサービスに連携されなくなります。 なのでアーカイブされた検出結果はSecurity Hubに統合されることはありませんし、EventBridge→S3バケット経由で長期保存される事もなくなります。

抑制ルールは一見とても便利な機能に見えますが、フィルタ条件を間違えたり過剰に設定したりしてしまうと、今度は逆に見ないといけないインシデントを見落とす危険性があります。抑制ルールの設定には十分な吟味と確実な設定が必要です。

抑制ルールの作成方法

ではまずマネジメントコンソール上で設定してみましょう。
検知タイプとして、前回も取り上げたPolicy:S3/BucketAnonymousAccessGrantedを題材にします。

「抑制ルールを作成」から、今回はフィルタ条件として「検知タイプ」「リージョン」「アカウントID」を設定して、「抑制ルールを作成」をクリックします。

抑制ルール名をつけて作成します。

設定が完了したら「保存済みのルール」から選ぶことができるようになります。いや「保存済みのルール」ってなんだよ、抑制ルールじゃないのかよと言いたくなりますが、これも受け入れます。

これで次から発生する「Policy:S3/BucketAnonymousAccessGranted」かつ「ap-northeast-1」かつ「該当のアカウントID」にマッチするインシデントについてはアーカイブされることになります。前回のようにXXXXアカウントの東京リージョンでS3バケットポリシーを制限している状態から全開放に設定変更したとしても、GuardDutyで検知されることはなくなります。

抑制ルールの設定ってめんどくさい？

ここまで手動で抑制ルールの作成を行ってみましたが、正直めんどくさいです。上記で試した例はまだ楽な方ですが、これが複数のルールを設定しないといけなかったり、もっと細かくフィルタしないといけない場合はどうでしょう。

なにより設定ミスが怖すぎます。検知タイプを打ち間違えたり、検知除外するIAMプリンシパルに望まないものを設定すると大変なことになります。本来インシデントとして検知すべきものをしなくなり、業務上クリティカルなアクティビティを見逃すおそれがあります。

ちなみに、CLIで設定する方法もありますが、それも工数的に大差はなさそうです。

参考：GuardDutyの抑制ルールをCLIで設定する(サンプルあり)

あとは抑制ルールって、どんな条件でフィルタをしているかというのを一括で確認することができないんですよね。マネジメントコンソール上にそのようなボタンが見当たりません。例えばこんな感じで2つ以上の抑制ルールを設定していた場合、どれがどんなルールだっけ、、？となります。必然的にルール詳細の管理台帳的なシートが必要になり、管理の手間が増えます。

さらに気になるのが、抑制ルールの削除・更新方法が地味に分かりにくいです。え、そこ？って場所にあります。直感的なUIではない気がしていて、運用に慣れが必要です。

ここまで踏まえて個人的には、抑制ルールは人力で設定している組織はあまり健全とはいえない、と考えています。

Amazon Q にやってもらう

ということでこういった作業はAmazon Q におまかせしちゃいましょう。

抑制ルールの作成

人力で設定した抑制ルールを、私の代わりとしてAmazon Q に作ってもらいます。

まずはGuardDutyのインシデントをAmazon Q に読ませて、フィルタ作成に必要なデータを取得します。

東京リージョンのGuardDutyのFindingID dccbe52fade6cbf534a90ef0604d3359について調査してください。

前回の記事の通り、検出結果をわかりやすく解説してくれました。

> ## GuardDuty Finding調査結果

Finding ID: dccbe52fade6cbf534a90ef0604d3359

### 🚨 セキュリティアラート概要
• **重要度**: 8.0 (HIGH)
• **タイプ**: Policy:S3/BucketAnonymousAccessGranted
• **発生日時**: 2025-07-02 09:02:16 UTC
• **ステータス**: アクティブ（アーカイブされていない）

### 📋 インシデント詳細
問題: S3バケット test-my-secret-bucket-kyonosuke-202507021744 にパブリック匿名アクセスが許可されました

実行されたアクション:
• API: PutBucketPolicy
• サービス: s3.amazonaws.com
• 実行者: AWSReservedSSO_AWSAdministratorAccess_XXXX

### 👤 実行者情報
• **ユーザー**: AWSReservedSSO_AWSAdministratorAccess_XXXX
• **ユーザータイプ**: AssumedRole
• **プリンシパルID**: AROA6D2FUA7DXAO7WIIFO:XXXX@gmail.com
• **アクセスキーID**: XXXX

### 🪣 影響を受けたS3バケット
• **バケット名**: test-my-secret-bucket-kyonosuke-202507021744
• **作成日**: 2025-07-02 17:55:59 JST
• **暗号化**: AES256（デフォルト）

パブリックアクセス設定:
• ✅ バケットポリシーによるパブリック読み取りアクセス: 許可
• ✅ バケットポリシーによるパブリック書き込みアクセス: 許可
• ❌ パブリックアクセスブロック: 無効

抽出した情報をもとに、抑制ルールを作成してもらいます。本インシデントはセキュリティリスクがないことを伝えました。

本インシデントは調査の結果、業務上の意図した操作であることができました。よってGuardDutyの抑制ルールを作成します。
この検知タイプかつアカウントIDかつ東京リージョンの検出結果については、アーカイブするようなルールを設定してください。

するとcreate-filterコマンドで抑制ルールの作成が始まりました。

> 業務上の意図した操作であることが確認されたとのことですね。GuardDutyの抑制ルール（Suppression Rule）を作成して、同様の検知を自動的にアーカイブするように設定
します。


🛠️  Using tool: use_aws
 ⋮ 
 ● Running aws cli command:

Service name: guardduty
Operation name: create-filter
Parameters: 
- description: "業務上の意図した操作のため、アカウントXXXXの東京リージョンでのS3バケット匿名アクセス許可検知を抑制"
- detector-id: "XXXX"
- finding-criteria: {"criterion":{"accountId":{"eq":["XXXX"]},"region":{"eq":["ap-northeast-1"]},"type":{"eq":["Policy:S3/BucketAnonymousAccessGranted"]}}}
- name: "S3BucketAnonymousAccess-AccountXXXX-TokyoRegion-Suppression"
- action: "ARCHIVE"
Profile name: Audit
Region: ap-northeast-1

パラメータの調整などをAmazon Q が数回の試行錯誤を繰り返した後、以下の回答を提示してきました。

> ## ✅ GuardDuty抑制ルール作成完了

ルール名: S3-BucketAnonymousAccess-Suppression

### 📋 設定内容
• **アクション**: ARCHIVE（自動アーカイブ）
• **説明**: Business approved S3 bucket anonymous access suppression for account XXXX in Tokyo region

### 🎯 適用条件
以下の条件をすべて満たすFindingが自動的にアーカイブされます：

1. 検知タイプ: Policy:S3/BucketAnonymousAccessGranted
2. アカウントID: XXXX
3. リージョン: ap-northeast-1 (東京リージョン)

### 🔄 動作確認
この抑制ルールにより、今後同じ条件で発生するS3バケット匿名アクセス許可の検知は自動的にアーカイブされ、アラートとして表示されなくなります。

### 📝 注意事項
• この抑制ルールは指定したアカウントと東京リージョンでのみ適用されます
• 他のリージョンや異なる検知タイプには影響しません
• 必要に応じて、後でルールを削除または修正することも可能です

抑制ルールが正常に作成され、今後同様のインシデントは自動的にアーカイブされるようになりました。

いい感じですね！コンソールも見てみます。

ばっちり作成されています！面倒でミスが起きがちなフィルタ作業を自然言語で作成できるのはうれしいです。

抑制ルールのリスト

次はこのアカウントで作成している抑制ルールをリストしてもらいましょう。2025年7月現在、コンソール上だと多分できないです。

このアカウントに設定してある抑制ルールをリストして、運用者にとってわかりやすいように表示してください。

抑制ルールの確認が始まりました。list-filtersというAPIらしいです。

> このアカウントに設定されているGuardDutyの抑制ルールを確認します。


🛠️  Using tool: use_aws (trusted)
 ⋮ 
 ● Running aws cli command:

Service name: guardduty
Operation name: list-filters
Parameters: 
- detector-id: "XXXX"
Profile name: Audit
Region: ap-northeast-1
Label: GuardDuty抑制ルール一覧取得
 ⋮ 
 ● Completed in 2.326s

その後、リストをしてくれました。

> ## 📋 GuardDuty抑制ルール一覧

アカウント: XXXX  
リージョン: 東京 (ap-northeast-1)  
Detector ID: XXXX

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


### 🔧 ルール #1: test-rule-2
• **アクション**: 🗄️ ARCHIVE (自動アーカイブ)
• **説明**: Suppress BlockPublicAccess
• **対象検知**: Policy:S3/BucketBlockPublicAccessDisabled
• **適用条件**: 
  • S3バケットのパブリックアクセスブロックが無効化された検知

📝 運用上の意味: S3バケットのパブリックアクセスブロック無効化アラートを自動的に抑制

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


### 🔧 ルール #2: S3-BucketAnonymousAccess-Suppression
• **アクション**: 🗄️ ARCHIVE (自動アーカイブ)
• **説明**: Business approved S3 bucket anonymous access suppression for account XXXX in Tokyo region
• **対象検知**: Policy:S3/BucketAnonymousAccessGranted
• **適用条件**:
  • アカウントID: XXXX
  • リージョン: ap-northeast-1 (東京)
  • S3バケット匿名アクセス許可の検知

📝 運用上の意味: 業務承認済みのS3バケット匿名アクセス許可アラートを自動的に抑制

めっちゃいい感じですね！抑制ルールの詳細について顧客に説明するときや運用設計書に記述する場面でとても役に立ちそうです。

面白いことに、list-filtersをCLIで実行しても抑制ルールの詳細までは表示されません。
ためしに実行してみると

$ aws guardduty list-filters \
  --detector-id XXXX \
  --profile Audit \
  --region ap-northeast-1
  
{
    "FilterNames": [
        "test-rule-2",
        "S3-BucketAnonymousAccess-Suppression"
    ]
}

たしかにルール名しか表示されません。
Amazon Q に聞いてみたら、list-filtersコマンドには詳細を表示するオプションはないとのことでした。代わりにシェルスクリプトを提案してきました。

> GuardDutyのlist-filtersコマンドでは、ルールの詳細情報を直接表示するオプションはありません。ルール名の一覧のみが返されます。

### 複数ルールの詳細を一括取得（シェルスクリプト）
bash
#!/bin/bash
DETECTOR_ID="1acbcb4327285ba99a6be56ff65eba0a"
PROFILE="Audit"
REGION="ap-northeast-1"

# ルール名一覧を取得
FILTER_NAMES=$(aws guardduty list-filters \
  --detector-id $DETECTOR_ID \
  --profile $PROFILE \
  --region $REGION \
  --query 'FilterNames[]' \
  --output text)

# 各ルールの詳細を取得
for filter_name in $FILTER_NAMES; do
  echo "=== $filter_name ==="
  aws guardduty get-filter \
    --detector-id $DETECTOR_ID \
    --filter-name "$filter_name" \
    --profile $PROFILE \
    --region $REGION
  echo ""
done

## 💡 ポイント
• list-filtersは名前のリストのみ
• 詳細情報にはget-filterが必要
• 複数ルールの詳細確認にはループ処理が効果的

抑制ルールの詳細リストについてはコンソール・CLIでは表示することができず、これはAmazon Q の有用性が示せる良い例なのではないでしょうか。

抑制ルールの削除・更新

最後に抑制ルールの削除もやってもらいましょう。コンソール上だとUIが微妙ですし、上記の確認をした後に抑制ルールを削除したくなることがあるかもしれません。

S3のブロックパブリックアクセスに関する検出結果をアーカイブしている抑制ルールを削除してください。
このルールは誤って作成してしまい、社内のポリシー的には検知が必要な項目でした

delete-filterコマンドが実行されます。

> S3のブロックパブリックアクセスに関する抑制ルール（test-rule-2）を削除します。この検知は重要なセキュリティ項目なので、適切に削除して検知を有効
化しましょう。


🛠️  Using tool: use_aws (trusted)
 ⋮ 
 ● Running aws cli command:

Service name: guardduty
Operation name: delete-filter
Parameters: 
- detector-id: "XXXX"
- filter-name: "test-rule-2"
Profile name: Audit
Region: ap-northeast-1
Label: S3ブロックパブリックアクセス抑制ルール削除
 ⋮ 
 ● Completed in 3.373s

削除したルールを表示してくれます。

> ## ✅ 抑制ルール削除完了

### 🗑️ 削除されたルール
ルール名: test-rule-2
• **対象検知**: Policy:S3/BucketBlockPublicAccessDisabled
• **説明**: Suppress BlockPublicAccess
• **アクション**: ARCHIVE

ついでにルールの更新も行ってもらいましょう。検知除外するリージョンを追加してみます。

Policy:S3/BucketAnonymousAccessGrantedをアーカイブしている抑制ルールについては、
バージニア北部リージョンでも頻発してノイズになっているのでフィルタに加えてください。

APIについては省略しますが、古いルールを削除して新しいルールを作成していました。

> ## ✅ 抑制ルール更新完了

### 🔄 変更内容
旧ルール: S3-BucketAnonymousAccess-Suppression → 削除  
新ルール: S3-BucketAnonymousAccess-MultiRegion-Suppression → 作成

### 📋 更新された抑制ルール詳細
ルール名: S3-BucketAnonymousAccess-MultiRegion-Suppression
• **アクション**: 🗄️ ARCHIVE (自動アーカイブ)
• **説明**: Business approved S3 bucket anonymous access suppression for account 970271754183 in Tokyo and Virginia regions

### 🎯 適用条件（拡張済み）
以下の条件をすべて満たすFindingが自動的にアーカイブされます：

1. 検知タイプ: Policy:S3/BucketAnonymousAccessGranted
2. アカウントID: XXXX
3. リージョン: 
   • 🇯🇵 ap-northeast-1 (東京リージョン)
   • 🇺🇸 us-east-1 (バージニア北部リージョン) ← 新規追加

### 📈 効果
• **ノイズ削減**: バージニア北部リージョンでの頻発する同検知もアーカイブ対象に
• **運用効率向上**: 両リージョンでの業務承認済み操作によるアラートを統一管理
• **一元管理**: 複数リージョンを単一ルールで管理

### 🔍 対象外リージョン
他のリージョン（例：オレゴン、フランクフルトなど）では引き続き検知が有効です。

バージニア北部リージョンでのS3匿名アクセス許可検知も自動アーカイブされるようになり、ノイズが削減されます。

コンソールでもちゃんと更新されていることを確認できました。

素晴らしいですね！抑制ルールの更新というミスったらヤバそうなタスクを自動化できるのはめちゃくちゃ助かります。

まとめ

今回はAmazon Q Developer CLI を利用してGuardDutyの抑制ルールを管理してみました。
GuardDutyを運用するうえで工数がかかる部分だと思いますが、Amazon Q のおかげで劇的に効率化できそうです。
今後もAmazon Q を活用したセキュリティ運用を考察します。

本記事がセキュリティ運用に困っているあなたの力になれば幸いです。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up