はじめに

NTT西日本エンタープライズビジネス営業部の吉田泰隆です。
本記事ではAWSが提供する生成AIアシスタント「Amazon Q」の性能を３つの観点で検証・評価してみました。
１観点１記事、合計３つの連載となりますので、最後までお読みいただけると嬉しいです。
気になる記事からの閲覧も大歓迎です。

本記事は2025年10月時点の情報に基づきます。

対象読者

本記事が想定する対象読者は以下の通りです。

Amazon Q を利用している人
生成 AI の実践的な活用方法に関心がある人
クラウドエンジニアとして生成AI に代替されないスキルを知りたい人
AWS 主要サービスを日常的に扱っている人
システム検証や検証レポートを業務に活かしたい人
生成AI の限界やリスクも含めて理解したい人

背景　

近年、生成 AI が急速に普及し、クラウドエンジニアリングの分野でも活用可能性が広がっています。
私自身も生成AIに強い関心を持ち、実際にどこまで現場で役立つのかを確かめたいと考えました。
また検証を通じて、生成AI に任せられる領域と人間のエンジニアが担うべき領域を明確化し、今後の業務に活用していくことを最終目的としています。

検証概要

AWS 環境での構築や保守・運用といった具体的なシナリオに適用できるかを以下３観点から評価します。

リソースコントロール
セキュリティ （本記事）
トラブルシューティング

本記事ではセキュリティに焦点をあてます。
１つの観点につき難易度の異なる２つシナリオで検証します。

検証条件・補足

Amazon Q Developer Pro （バージョンq 1.13.2）を利用します。
（Amazon Linux 2023にインストーラを利用して Q Developer CLIをインストール）
Amazon Qの回答をすべて記述するとかなり長いため、要所要所で「～略～」を使って省略をしています。
リソースID等の情報保護のため、「※※※」を使ってマスキングをしています。

シナリオ①「セキュリティグループの評価」

内容

EC2インスタンスに付与しているセキュリティグループがセキュリティの観点から問題がないかを評価します。評価してもらうセキュリティグループはこちらです。

インバウンドルール

タイプ	プロトコル	ポート範囲	送信元
SSH	TCP	22	0.0.0.0/0
HTTP	TCP	80	0.0.0.0/0
HTTPS	TCP	443	0.0.0.0/0
RDP	TCP	3389	0.0.0.0/0

アウトバウンドルール

タイプ	プロトコル	ポート範囲	送信先
すべてのトラフィック	すべて	すべて	0.0.0.0/0

プロンプト

Webサーバー用のEC2インスタンスのセキュリティグループ（sg-※※※）を確認して、  
セキュリティ上の問題点を指摘し、推奨される改善案をすべて提示してください。

回答結果

Amazon Qの結果がこちらです。

> 指定されたセキュリティグループの設定を確認します。

🛠️  Using tool: use_aws (trusted)
 ⋮ 
 ● Running aws cli command:
～略～
 ⋮ 
 ● Completed in 1.82s
～略～
> # Webサーバー用セキュリティグループ（sg-※※※）のセキュリティ分析

## 🚨 発見されたリスク

### 1. SSH（ポート22）全世界開放 - 重大リスク
• 現状：0.0.0.0/0からのSSHアクセス許可
• リスク：ブルートフォース攻撃、不正アクセス

### 2. RDP（ポート3389）全世界開放 - 重大リスク
• 現状：0.0.0.0/0からのRDPアクセス許可
• リスク：Linux Webサーバーには不要、攻撃対象拡大

### 3. HTTP/HTTPS直接開放 - 中リスク
• 現状：0.0.0.0/0からの直接Webアクセス許可
• リスク：ALBをバイパスした直接攻撃

### 4. 全アウトバウンド許可 - 中リスク
• 現状：すべての外向き通信を許可
• リスク：データ流出、マルウェア通信

## 📋 改善案

### 1. SSH制限（最優先）
bash
# 危険なルール削除
aws ec2 revoke-security-group-ingress --group-id sg-※※※ --protocol tcp --port 22 --cidr 0.0.0.0/0

# 管理者IPのみ許可
aws ec2 authorize-security-group-ingress --group-id sg-※※※ --protocol tcp --port 22 --cidr <管理者IP>/32

### 2. RDP削除
bash
aws ec2 revoke-security-group-ingress --group-id sg-※※※ --protocol tcp --port 3389 --cidr 0.0.0.0/0

### 3. HTTP/HTTPS制限
bash
# 直接アクセス削除
aws ec2 revoke-security-group-ingress --group-id sg-※※※ --protocol tcp --port 80 --cidr 0.0.0.0/0
aws ec2 revoke-security-group-ingress --group-id sg-※※※ --protocol tcp --port 443 --cidr 0.0.0.0/0

# ALBからのみ許可
aws ec2 authorize-security-group-ingress --group-id sg-※※※ --protocol tcp --port 80 --source-group <ALB-SG-ID>

### 4. アウトバウンド制限
bash
# 全許可削除
aws ec2 revoke-security-group-egress --group-id sg-※※※ --protocol -1 --cidr 0.0.0.0/0

# 必要最小限のみ許可
aws ec2 authorize-security-group-egress --group-id sg-※※※ --protocol tcp --port 80 --cidr 0.0.0.0/0   # HTTP
aws ec2 authorize-security-group-egress --group-id sg-※※※ --protocol tcp --port 443 --cidr 0.0.0.0/0  # HTTPS
aws ec2 authorize-security-group-egress --group-id sg-※※※ --protocol udp --port 53 --cidr 0.0.0.0/0   # DNS
aws ec2 authorize-security-group-egress --group-id sg-※※※ --protocol udp --port 123 --cidr 0.0.0.0/0  # NTP

### 5. セキュリティグループ管理改善
• 名前を用途明確に変更（例：web-server-sg）
• 適切なタグ付け（Environment、Owner、Purpose）

### 6. 監査・監視強化
• AWS Config Rulesでセキュリティグループ設定監視
• CloudTrailで変更履歴追跡

### 7. 代替アクセス方法導入
• AWS Systems Manager Session Manager使用
• 踏み台サーバー（Bastion Host）経由アクセス

## 優先順位
1. 即座実施：SSH・RDP制限（リスク1,2）
2. 早期実施：HTTP/HTTPS制限（リスク3）
3. 計画的実施：アウトバウンド制限、監視強化（リスク4以降）

考察

あらためて整理してみると、Amazon Qが指摘したのか下記７点です。

SSH（ポート22）すべてのIPからの通信
RDP（ポート3389）すべてのIPからの通信
HTTP/HTTPS通信のアクセス許可
全アウトバウンド許可
セキュリティグループ管理改善
監査・監視強化
代替アクセス方法導入

私が事前に想定していたAmazon Qの回答は前半４つのみでした。後半３つはセキュリティ上の問題点ではありませんでしたが、「確かに、このような制御方法もあるな」と勉強にもなりました。
インバウンド・アウトバウントがともにベストプラクティス通り設計されており、
最小権限の原則にしっかりと基づいていることがわかります。

（余談）
セキュリティグループの名前を適当に「test」としていたのですが、
そこを指摘されたときは、正直勘弁してほしいなと思いました...

シナリオ②「IAMユーザー権限チェック」

内容

IAMユーザー(developer)にフルアクセス＋S3全操作という過剰権限を付与し、正しい権限設定の提案をしてもらいます。 IAMユーザーに付与したIAMポリシーはこちらです。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::※※※/*"
        }
    ]
}

プロンプト

開発者ユーザー『developer』に付与されているIAMポリシーを分析し、  
セキュリティリスクを評価してください。  
このユーザーは主にS3バケット『※※※』への読み書きとCloudWatch Logsの確認作業を行います。  
適切な権限設定を提案してください。

回答結果

Amazon Qの結果がこちらです。

> 「developer」ユーザーのIAMポリシーを分析します。まず現在の権限を確認しましょう。

🛠️  Using tool: use_aws (trusted)
～略～
 ● Completed in 2.130s

🛠️  Using tool: use_aws (trusted)
～略～
 ⋮ 
 ● Completed in 0.846s

🛠️  Using tool: use_aws (trusted)
～略～
 ● Completed in 0.844s

🛠️  Using tool: use_aws (trusted)
～略～
 ● Completed in 0.840s


> ## セキュリティリスク分析

重大なセキュリティリスク発見:

現在のポリシーには "Action": "*" と "Resource": "*" が設定されており、  
これは**全てのAWSサービスへの完全なアクセス権限**を付与しています。  
これは非常に危険です。

### 主なリスク:
• IAMユーザー・ロールの作成・削除
• 他のS3バケットへの無制限アクセス
• EC2インスタンスの起動・停止
• データベースの削除
• 課金情報へのアクセス

## 推奨される最小権限ポリシー

業務要件（S3バケット「※※※」とCloudWatch Logs）に基づく適切なポリシーを作成します：


🛠️  Using tool: fs_write
 ⋮ 
 ● Path: /home/ubuntu/developer-secure-policy.json

+     1: {
+     2:   "Version": "2012-10-17",
+     3:   "Statement": [
+     4:     {
+     5:       "Sid": "S3BackupBucketAccess",
+     6:       "Effect": "Allow",
+     7:       "Action": [
+     8:         "s3:GetObject",
+     9:         "s3:PutObject",
+    10:         "s3:DeleteObject",
+    11:         "s3:ListBucket"
+    12:       ],
+    13:       "Resource": [
+    14:         "arn:aws:s3:::※※※",
+    15:         "arn:aws:s3:::※※※/*"
+    16:       ]
+    17:     },
+    18:     {
+    19:       "Sid": "CloudWatchLogsReadAccess",
+    20:       "Effect": "Allow",
+    21:       "Action": [
+    22:         "logs:DescribeLogGroups",
+    23:         "logs:DescribeLogStreams",
+    24:         "logs:GetLogEvents",
+    25:         "logs:FilterLogEvents"
+    26:       ],
+    27:       "Resource": "*"
+    28:     }
+    29:   ]
+    30: }

 ⋮ 
 ↳ Purpose: developerユーザー用の最小権限ポリシーを作成

Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

> n

> 承知いたしました。現在のポリシー分析は完了しましたが、次のアクションについて確認させてください：

## 現在の状況
「developer」ユーザーには非常に危険な "Action": "*", "Resource": "*" の権限が付与されており、  
全AWSサービスへの完全アクセスが可能な状態です。

## 次のアクションについて
以下のどちらをご希望でしょうか？

1. 新しいセキュアなポリシーを作成して既存ポリシーと置き換える
   • 既存の「Developer-IAMrole」ポリシーを更新
   • S3バケット「※※※」とCloudWatch Logsのみの最小権限に変更

2. 推奨ポリシーの内容のみを提示する
   • JSONファイルは作成せず、適切な権限設定を文章で説明
   • 実際の変更は手動で実施していただく

どちらの方法をお望みでしょうか？また、他にご希望があれば教えてください。

IAMポリシーの提案まで無事完了しました。
早速、ポリシーの中身を考察していきましょう。

考察

ポリシーを比較して、違いをまとめると下記のようになります。

既存IAMポリシーの特徴

Statement 1で全サービス・全リソースへのアクセスを許可(管理者レベル)
Statement 2でS3バケット配下のオブジェクトへの全操作を許可
Sidによる説明がない

Amazon Qが提案したポリシーの特徴

S3の操作を必要最小限(Get, Put, Delete, List)に限定
バケット自体とオブジェクトの両方にアクセス可能
CloudWatch Logsの読み取り専用アクセスを追加
Sidで各Statementの目的を明確化

S3への読み取り、書き込み、削除と、CloudWatch Logsからの読み取りに焦点を絞っており、
それ以外のAWSサービスやS3バケットへのアクセスを許可していません。
これにより、必要な機能のみを提供し、最小権限の法則から逸脱していないことがわかります。

セキュリティ編まとめ

Amazon Qは、セキュリティリスクの検出と改善提案において非常に高い能力を発揮しました。
ベストプラクティスに基づいた指摘はもちろん、具体的なAWS CLIコマンドや実装可能なJSONポリシーを提示してくれます。

一方で、Amazon Qが提案する内容はあくまで一般的なセキュリティ原則に基づいたものです。
実際の適用にあたっては、組織固有のセキュリティポリシーやコンプライアンス要件、
業務要件との整合性を人間のエンジニアが最終判断する必要があります。

次回予告

次は最後、トラブルシューティング編です。簡単に生成AIに解かれないよういろんなバグを仕込みました。果たして適切に対処できるのか...！？
ぜひ、次回をお楽しみに！

免責事項

本記事は検証・評価を目的とした技術記事です。
本記事を使用して本番環境でのAmazon Qを利用したリソース変更作業を推奨するものではありません。
本記事の内容を参考にした結果生じるいかなる損害についても、筆者および所属組織は一切の責任を負いかねます。
読者の責任において、適切なリスク管理の下でご活用ください。

執筆者

吉田泰隆（NTT西日本エンタープライズビジネス営業部所属）
好きなAWSサービス：Route53
所有資格：AWS Certified Solutions Architect – Professional

参考資料・出典

本記事を執筆するにあたり、以下のサイトを参考にしました。

business.ntt-east.co.jp

dev.classmethod.jp

商標

「AWS」は、Amazon Web Services, Inc.またはその関連会社の商標もしくは登録商標です。

NTT WEST Engineers' Blog

Amazon Qでどこまでできるのか？～２.セキュリティ編～

はじめに

対象読者

背景

検証概要

検証条件・補足

シナリオ①「セキュリティグループの評価」

内容

プロンプト

回答結果

考察

シナリオ②「IAMユーザー権限チェック」

内容

プロンプト

回答結果

考察

既存IAMポリシーの特徴

Amazon Qが提案したポリシーの特徴

セキュリティ編まとめ

次回予告

免責事項

執筆者

参考資料・出典

商標