[レポート] Amazon Q DeveloperとSlackでセキュリティインシデント対応を自動化する #SEC351 #AWSreInforce

はじめに

こんにちは、コンサルティング部の神野です。

米国東海岸で開催されているAWS re:Inforce 2025 に現地参加しています。

今回の記事では re:Inforce 2025 のBuilder's Sessionの1つ、「SEC351: Accelerating incident response, compliance & auditing using generative AI」についてレポートします。

AWS環境のSecurity Hubなどの通知をAmazon Q DeveloperとSlack・Teamsなどのチャットアプリと連携させて、AIの力でインシデント対応を進めるやり方を体験するセッションでした。
AIの力を借りて自然言語で対応できるのは面白そうだなと思い、本セッションに参加してみました。

セッション概要

In this session, you will learn how to use AWS native generative AI capabilities to reduce time to recovery after an incident using enterprise communication tools such as Slack. We will also learn how to use detective controls to identify events that may result in an incident, and also how to use preventive controls to mitigate the risk of an incident occurring. We will use services like Amazon Q Developer, AWS Config, AWS CloudTrail Lake, Amazon CloudWatch and other observability features.

スピーカー:

• Snehal Nahar (Principal Technical Account Manager, Amazon)
• Ravindra Kori (Sr Solutions Architect, AWS)
• Rayette Toles-Abdullah (Principal Solutions Architect, AWS)
• Abhijit Barde (Principal Product Manager, AWS)

レベル: 300 - Advanced
セッション形式: Builder's Session（ハンズオン形式）

会場の雰囲気

Builders' Sessionなので、参加者全員がラップトップを持参して、
実際に手を動かしながら学ぶ形式です。

慣れない英語で緊張していましたが、講師の方が優しく対応いただけて安心しました！

セッション内容

全体的なシナリオ

AWS Config、Security Hub、AWS CloudTrailの通知をAmazon Q Developer経由でチャットアプリ（Slack、Teams）にインシデントを連携して、対応するシナリオです。

3つのユースケースに応じてAmazon Qによる通知とその対応を体験していきます。

• Use case 1：Non-compliant configuration AWS Config
• Use case 2：Security finding AWS Security Hub
• Use case 3：Unintentional Access Control

今回チャットツールはSlackとTeamsが選べたのですが、馴染みのあるSlackを採用しました。

チャンネル設定

まずはSlackやMicrosoft TeamsでAmazon Q Developerを使えるようにする設定から始まりました。
Slack AppでAmazon Q Developerを追加して連携しました。

その次に、通知したいチャネルのIDを設定画面から控えておきます。

控えたIDはこの後ワークショップ上で通知機構のCloudFormationを実行する際のパラメータとして使用します。
CloudFormationで作成が完了したらテスト通知を行なってみます。

テストメッセージを送信ボタンを押下すると下記のように通知が飛びます。

ここまでできたらAmazon QとSlackの連携は完了しているので、早速Use caseを試してみます。

Use case 1 Non-compliant configuration AWS Config

まずはAWS Configに非準拠なリソースを作成してみて、Amazon Q Developerによる通知および対応を体験してみます。
今回は、CloudTrailのログファイル検証機能が無効になっているという設定不備を検出するシナリオです。

実行コマンド

aws cloudtrail create-trail --name workshop-trail1 --s3-bucket-name $(aws s3 ls | grep module-resources-cloudtrailbucket* | awk '{print $3}')

aws configservice put-config-rule \
--config-rule '{
    "ConfigRuleName": "cloud-trail-log-file-validation-enabled",
    "Source": {
        "Owner": "AWS",
        "SourceIdentifier": "CLOUD_TRAIL_LOG_FILE_VALIDATION_ENABLED"
    },
    "Scope": {
        "ComplianceResourceTypes": [
            "AWS::CloudTrail::Trail"
        ]
    }
}'

aws configservice describe-config-rules --config-rule-names cloud-trail-log-file-validation-enabled

LogFileValidationEnabledがtrueを遵守するConfigルールを作成して、CloudTrailが違反している状態を作り出します。
少し経つと違反しているよと下記通知を受け取ります。

画像上に表示されているボタンListTrailsを押下すると下記のようにCloudTrailを調査してくれて実態を教えてくれます。

LogFileValidationEnabledはやはりfalseですね。
この状態を修復してもらいましょう。今度は左側のEnabledLogFileをクリックします。
クリックするとポップアップが表示されるため、対象のTrail名であるworkshop-trail1を入力します。

Nextを押すと実行コマンドが表示されて、実行するかどうか最終のポップアップが出るのでRunをクリックします。

クリックするとコマンドが実行されて修復されます。

これで修復完了したのですが、もはや自然言語すら不要でボタンだけで修復できてびっくりでした。
もうちょっと色々なケースでどこまで簡略化して対応できるか検証してみたいですね。

Use case 2：Security finding AWS Security Hub

次はわざと問題のあるセキュリティグループを作成して、それをAmazon Q Developerで修復するというシナリオです。

まず、CloudShellで以下のコマンドを実行して、0.0.0.0/0からのアクセスを許可する危険なセキュリティグループを作成します。

aws ec2 create-security-group \
  --group-name noncompliant-security-group \
  --description "noncompliant-security-group"

aws ec2 authorize-security-group-ingress \
  --group-name noncompliant-security-group \
  --protocol all \
  --port 0-65535 \
  --cidr 0.0.0.0/0

すると、数分後にSlackに以下のような通知が来ました。

まずは自然言語で調査してみます。

@Amazon Q Show the EC2 security groups allowing 0.0.0.0/0 to port 22 in us-east-2?

調査すると下記のように返事が返ってきます。

先ほどわざと作ったものがポートが解放されているよと教えてくれていますね。
今度はどうやってアップデートしたらいいかも聞いてみます。

@Amazon Q How do I update the security group "noncompliant-security-group" to change inbound rule from 0.0.0.0/0 to 10.0.0.0/16 in us-east-2?

今度は下記メッセージが返信されました。

ステップバイステップで対応方法を教えてくれて親切ですね。
対応案は一旦は今全開放となっているのを自VPCのIPレンジに変更するといった案を出していますね。

ここからはカスタムアクションを追加してボタン押下で修復できるようにしてみます。
Suppress findingsの右隣のボタンをクリックします。クリックするとManage actionsの案内が出るのでクリックします。

次に具体的なアクション名や表示するテキスト、またカスタムアクションの種別を選択します。
今回は事前に作成されたLambdaを使用するのでLambda actionを選択します。

次はLambda関数のアカウント、リージョン、関数名を選びpayloadも決定します。
事前に作成したLambda関数を選択して、修復したいセキュリティグループのARNsg_arnを引数に渡すようにします。

最後に表示の設定を行います。追加でSeverityがhighの時は表示するようにします。

アクションを追加したら、今度はまた全開放のインバウンドルールを付与したセキュリティグループを作成します。
作成すると下記のような通知が表示されて、今度は作成したRemediate SGボタンが表示されます。

実際にボタンを押してみると、見事にセキュリティグループが修正され、Security HubのFindingもRESOLVEDになりました。

コンソール上からみてもセキュリティグループのインバウンドで許可するIPレンジは変更されていました。

簡単に設定できて便利ではあるなと思ったのですが、エラーのたびにLambda関数でアクションを作るのも大変そうだと感じました。

Use case 3：Unintentional Access Control

次は、Amazon Q Developerを使ってIAMユーザーの権限を調査し、過剰な権限を削除する演習です。

事前に過剰な権限を付与したユーザーを作成します。下記コマンドを実行して作成しました。

aws iam create-user --user-name AdminUser

aws iam attach-user-policy --user-name AdminUser --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

すると、検知されて下記通知が表示されました。

Slackで以下のようなコマンドを実行して、Admin権限を持つユーザーを全て洗い出してもらうことにしました。

@Amazon Q List all the IAM users with administrator access in us-east-1.

先ほど作ったAdminUserというユーザーにAdministratorAccessポリシーがアタッチされていることを調べてくれましたね。
また、User IDやARNも調べておきます。

さらに、エイリアスを作成して、簡単なコマンドでポリシーを削除できるようにしておきます。
ロールはすでに作成されているため、アカウントIDを自分のアカウントIDに変更して、IAMUserIDを引数で受け取れるようにしておきます。

@Amazon Q alias create AWSConfigRemediationRemoveUserPolicies2 ssm start-automation-execution --document-name AWSConfigRemediation-RemoveUserPolicies --parameters {"AutomationAssumeRole":["arn:aws:iam::xxx:role/ProductionSupport-SRERole"],"IAMUserID":"$IAMUserId","PolicyType":["All"]} --region us-east-2

そして実行してみます。IAMUserIDは先ほどQ Developerに調べてもらった値を指定します。

@Amazon Q run AWSConfigRemediationRemoveUserPolicies2 xxx

削除は実行されていそうですね。
削除後にAdmin権限を持っているユーザーはいるか聞いてみます。

聞いてみるといないと返事が返ってきましたね！削除が成功していました！
チャットアプリだけで解決して便利ですね。

おわりに

Amazon Q Developerを使ったセキュリティインシデント対応の自動化のセッションについて紹介させていただきました！

セキュリティインシデントが発生すると、マネジメントコンソールにログインして、該当リソースを探して、手動で修正して...という作業がよくあると思いますが、Slackから自然言語による調査や対応ができるのは便利で面白く、特に印象的だったのが自然言語による調査かなと思いました。チャットアプリだけでシームレスにインシデント対応できると効率化できそうだなと思います。一方で修復アクションなどでLambda関数を作って対応が必要な場合はコストがまあまあ必要な印象なので、どこまでAmazon Q Developerで自動化できるかは試していきたいですね。

私自身も今回のセッションで使用してみて、今後積極的にAmazon Q Developerを試してみたいな思いました！
最後までご覧いただきありがとうございましたー！！