Kiro と Amazon Q でセキュリティポスチャを強化する 5 つの方法

月曜日の朝、不正アクセスの試み、セキュリティグループの設定ミス、AWS Identity and Access Management (IAM) ポリシー違反を知らせるセキュリティアラートが届きました。チームはすばやく答えを見つける必要があります。

セキュリティチームは、Kiro と Amazon Q Developer を使用して、リソースのスキャン、ポリシーの作成、CVE (Common Vulnerabilities and Exposures) の調査といった反復的なタスクを処理しています。これにより、エンジニアは人間の判断が必要なリスクに関する意思決定や複雑なシナリオに集中できるため、脅威への対応が迅速になり、セキュリティカバレッジの一貫性も高まります。

この記事では、AWS Well-Architected フレームワークのセキュリティの柱に基づき、Kiro と Amazon Q Developer を使用して AWS のセキュリティポスチャを強化する 5 つの方法を紹介します。いずれの手法も、ツールの概要に続いて説明する共通の基盤を前提としています。

Amazon Web Services (AWS) は、AI を活用した開発とセキュリティの自動化について、お客様に複数の選択肢を提供しています。Kiro のエージェント型統合開発環境 (IDE) のエクスペリエンスを好む場合も、既存の AWS 環境と緊密に統合された Amazon Q Developer を好む場合も、どちらのツールでもこの記事で説明するセキュリティプラクティスを実装できます。最適な選択はチームのワークフローによって異なりますが、多くの場合、両者は互いに補完し合うため、組み合わせて使用できます。

Kiro は、AWS が仕様駆動開発向けに設計した、AI を活用したエージェント型 IDE です。自然言語によるプロンプトと、構造化され、明確な意図に基づくコーディングを組み合わせて、アプリケーションの生成、テスト、デプロイを行います。

Amazon Q Developer は、AWS の開発環境とクラウド環境に統合された生成 AI アシスタントです。質問への回答、コードの生成、問題のトラブルシューティング、AWS サービス全体での運用タスクの自動化を行うように設計されています。

訳注: 2026 年 5 月 15 日に、Amazon Q Developer の新規登録は停止しました。また、Amazon Q Developer IDE プラグインと有料サブスクリプションは、2027 年 4 月 30 日にサポートが終了する予定です。AWS マネジメントコンソールなどで提供される Amazon Q Developer は、引き続き利用できます。AWS は移行先として Kiro を案内しています。詳細は「Amazon Q Developer のサポート終了に関するお知らせ」を参照してください。

セットアップ手順と詳細については、Kiro のドキュメントと Amazon Q Developer のドキュメントを参照してください。

AI アシスタントに適切なコンテキストを与えると、より一貫性があり、目的に合った結果が得られるようになります。この記事で紹介する 5 つの手法はいずれも、AI アシスタントが組織のセキュリティ標準をあらかじめ理解していると、効果が大幅に高まります。最初に永続的なコンテキストを設定しておけば、以降のすべてのやり取りがその基盤の上に成り立ちます。その結果、トリアージ、修復、レビュー、ポリシー作成で得られる結果は、一般的なベストプラクティスではなく、自社固有の環境をより適切に反映したものになります。

永続的なコンテキストがない場合、"enable encryption, use least privilege IAM settings, and enable logging," (暗号化を有効にする、最小権限の IAM 設定を使用する、ログ記録を有効にする) のような同じセキュリティ要件をプロンプトのたびに繰り返し指定する必要があり、結果にばらつきが出たり、コントロールが漏れたりする原因になります。Amazon Q Developer IDE プラグインのルールと Kiro のステアリングファイル (CLI と IDE) は、まさにこの問題を解決します。これらを使用して組織のセキュリティ標準を明文化しておけば、プロンプトのたびに要件を繰り返さなくても、AI が安全なインフラストラクチャを一貫して自動的に構築します。どちらのツールもこの機能を個別にサポートしているため、ワークフローに合う方を設定することも、両方を組み合わせて開発環境全体をカバーすることもできます。次の手順で、それぞれの始め方を説明します。

Amazon Q Developer の場合

1. プロジェクトのルートにディレクトリ .amazonq/rules/ を作成します。
2. ファイル .amazonq/rules/security-standards.md を作成します。
3. 組織のセキュリティ標準を自然言語で記述して貼り付けます (後述の「セキュリティ標準のコンテキストファイルの例」を参照)。

Kiro の場合 (ステアリングファイル)

Kiro では、永続的なコンテキストのドキュメントをステアリングファイルと呼びます。ステアリングファイルを使用すると、エージェントはすべてのやり取りとセッションにわたって、アーキテクチャ上の決定事項、コーディング標準、セキュリティ要件を常に把握できます。

1. プロジェクトのルートにファイル security-standards.md を作成します。
2. プロンプトでこのファイルを参照します。例: Using security-standards.md as context, create... (security-standards.md をコンテキストとして使用して、…を作成する)

ヒント: ステアリングファイルの作成自体を Kiro に手伝ってもらうこともできます。セキュリティ要件を自然言語で説明し、構造化されたステアリングファイルを生成するよう Kiro に依頼したら、保存して有効化する前に内容をレビューします。AI アシスタントが後で使用するコンテキストを AI アシスタント自身に作成してもらえるため、セットアップをより迅速かつ漏れなく進められます。

セキュリティ標準のコンテキストファイルの例

# AWS Security Standards

## Identity and Access Management
- All IAM roles must use least privilege principles
- Require MFA for console access
- Enable IAM Access Analyzer for all accounts
- Rotate access keys every 90 days
- Use IAM roles for EC2 instances, never embed access keys

## Data Protection
- Enable encryption at rest for all storage services (S3, EBS, RDS)
- Use AWS KMS customer-managed keys for sensitive data
- Enable encryption in transit with TLS 1.2 minimum
- Implement S3 bucket policies denying unencrypted uploads
- Enable versioning and MFA delete for critical S3 buckets

## Infrastructure Protection
- Security groups must follow least privilege (no 0.0.0.0/0 on sensitive ports)
- Deploy resources in private subnets when possible
- Enable VPC Flow Logs for network monitoring
- Use AWS WAF for public-facing applications
- Implement Network ACLs as additional defense layer

## Detective Controls
- Enable CloudTrail in all regions with log file validation
- Configure CloudWatch alarms for security events
- Enable GuardDuty for threat detection
- Set up AWS Config rules for compliance monitoring
- Implement centralized logging with retention policies

## Incident Response
- Create SNS topics for security alerts
- Configure automated responses with AWS Lambda
- Maintain runbooks for common security incidents
- Enable AWS Systems Manager for secure instance access
- Implement automated backup and recovery procedure

これによって実現できること

永続的なコンテキストがない場合、Create a Lambda function to process customer data (顧客データを処理する Lambda 関数を作成する) のようなプロンプトでは、暗号化、ログ記録、IAM 設定のない基本的な関数が生成される可能性があります。AI の出力は非決定的であるため、ガイダンスがなければ、これらのコントロールが含まれるかどうかは保証されません。ステアリングファイルとルールドキュメントは、すべてのプロンプトと推論の入力に、より強力なガイダンスを組み込むことで、こうした変動を最小限に抑えます。

一方、上記の例のようにセキュリティ標準を組み込んでおくと、同じプロンプトから、AWS KMS で暗号化された環境変数、保持期間 90 日の CloudWatch ロググループ、最小権限の IAM、VPC 内のプライベートサブネットへの配置、デッドレターキュー、AWS X-Ray によるトレーシングを備えた関数が、すべて自動的に生成されます。

適用範囲

この永続的なコンテキストのアプローチは、両方のツールと、インフラストラクチャを生成するすべてのワークフローに適用できます。

• Amazon Q Developer IDE プラグイン: .amazonq/rules/ 内のルールは、コードの生成とレビューのすべてのやり取りに自動的に適用されます。
• Kiro: ステアリングファイルにより、エージェントはセッションやプロジェクトをまたいで、アーキテクチャとセキュリティの要件を常に把握できます。

シフトレフトの効果

このアプローチは、既存の継続的インテグレーションと継続的デリバリー (CI/CD) のセキュリティ自動化に代わるものではなく、それを強力に補完するものです。この違いは重要です。セキュリティ標準を開発ワークフローに直接組み込むことで、パイプラインのチェックよりもさらに左側 (上流) にセキュリティ検証をシフトできます。セキュリティの専門家だけでなく、組織全体の開発者が、最初の 1 行のコードからセキュリティ標準を満たすインフラストラクチャを生成できるようになります。これにより、セキュリティの専門知識がセキュリティ以外の職務にも行き渡り、開発チームはコンプライアンス要件にセルフサービスで対応できるようになります。また、自動化されたパイプラインのチェックで検出される件数そのものも減少します。

その結果、セキュリティは開発を遅らせる関門ではなく、開発の迅速化を後押しする存在になります。セキュリティエンジニアも、回避できたはずの設定ミスの修復ではなく、ポリシーの設計やリスクに関する複雑な意思決定に時間を使えるようになります。

測定可能な効果

永続的なコンテキストの価値を定量化するには、次の指標を追跡します。

• コードレビュー時のセキュリティ検出結果: コンテキストファイルを有効にする前に 30～60 日間のベースラインを取得し、有効化後と比較します
• 開発からデプロイまでの時間: 導入前後の平均サイクルタイムを追跡します
• 修復コスト: 開発段階で修正した欠陥は、本番環境で修正した欠陥よりもコストが大幅に低いことが、研究で一貫して示されています。自社での比率を 60 日間追跡します
• 標準の一貫性: インフラストラクチャのプルリクエストを無作為に抽出し、上位 10 件のポリシーへの準拠状況を監査します

実装に関する推奨事項: まず、最も頻繁に違反されるセキュリティポリシーの上位 10 件を明文化し、コンテキストとして設定します。30～60 日間でこれらの検出結果がどれだけ減少したかを測定し、チームへの効果を定量化します。

AWS Security Hub は、Amazon GuardDuty、AWS Config、Amazon Inspector などのサービスやサードパーティのセキュリティツールからの検出結果を 1 つのダッシュボードに集約します。これにより、AWS 環境全体のセキュリティ検出結果を一元的に可視化し、組み込みのトリアージ機能を利用できます。AWS Security Hub Extended では、さらに多くの機能が加わる予定です。お客様は制御できる範囲が広がり、この記事で説明する AI を活用したワークフローを、より大規模に、かつセキュリティツールチェーン全体とより緊密に統合して活用できるようになります。

Kiro は、アカウントをまたいだ検出結果の相関付け、CVE の背景の把握、修復アプローチの策定を支援することで、Security Hub を補完できます。具体的には、次のようなことができます。

• 複数の AWS アカウントと AWS リージョンにわたる検出結果を、自然言語でクエリする
• 特定の CVE と、それがインフラストラクチャに与える潜在的な影響を理解する
• AWS CloudTrail と Amazon Virtual Private Cloud (Amazon VPC) フローログ向けの調査クエリを生成する
• 異なる期間やサービスにまたがるセキュリティイベントを相関付ける
• 最新の AWS セキュリティドキュメントとベストプラクティスにアクセスする

仕組み – Model Context Protocol

これらの機能を実現するために、Kiro は Model Context Protocol (MCP) を使用します。MCP は、AI アシスタントが外部のツール、サービス、データソースと安全に接続するための標準化された方法です。MCP により、AI アシスタントは組み込み機能の範囲を超えて、アクションの実行、リアルタイム情報の取得、API とのやり取りを行えるようになります。

AWS 向けのオープンソース MCP サーバーは、Kiro が AWS のセキュリティサービスとやり取りできるようにする専用の MCP サーバー群で、セキュリティポスチャをリアルタイムで可視化します。使用を開始するには、Kiro の設定ファイルでセキュリティに特化した MCP サーバーを設定します (次の例を参照)。Kiro で MCP サーバーを設定する詳しい手順については、Kiro MCP のドキュメントを参照してください。

認証に関する注意: Security Hub をクエリする前に、対象アカウントの有効な AWS 認証情報が設定されていることを確認してください。AWS_PROFILE の値を、~/.aws/credentials ファイル内にある適切な許可を持つ名前付きプロファイルに設定するか、AWS コマンドラインインターフェイス (AWS CLI) (aws configure) を使用して認証情報を設定します。対象アカウントの有効な認証情報がないと、Kiro は検出結果を取得できません。

{
    "mcpServers": {
        "awslabs.aws-api-mcp-server": {
            "command": "uvx",
            "args": ["awslabs.aws-api-mcp-server@latest"],
            "env": {
                "FASTMCP_LOG_LEVEL": "ERROR",
                "AWS_PROFILE": "<PROFILE>",
                "AWS_REGION": "us-east-1"
            },
            "timeout": 120000,
            "disabled": false
        },
        "awslabs.cloudtrail-mcp-server": {
            "command": "uvx",
            "args": ["awslabs.cloudtrail-mcp-server@latest"],
            "env": {
                "FASTMCP_LOG_LEVEL": "ERROR",
                "AWS_PROFILE": "<PROFILE>"
            },
            "disabled": false
        },
        "awslabs.iam-mcp-server": {
            "command": "uvx",
            "args": ["awslabs.iam-mcp-server@latest"],
            "env": {
                "FASTMCP_LOG_LEVEL": "ERROR",
                "AWS_PROFILE": "<PROFILE>"
            },
            "disabled": false
        }
    }
}

まずは、次のセキュリティに特化した MCP サーバーを設定します。

• AWS API MCP Server: AWS CLI コマンドを通じて、Security Hub、GuardDuty、IAM Access Analyzer、AWS Config とやり取りします
• CloudTrail MCP Server: 監査証跡の分析とコンプライアンスモニタリングを行います
• AWS IAM MCP Server: IAM ユーザー、IAM ロール、IAM ポリシー、許可を管理します
• AWS Knowledge MCP Server: 最新の AWS セキュリティドキュメントとベストプラクティスにアクセスします

利用可能な MCP サーバーの一覧については、awslabs/mcp GitHub リポジトリを参照してください。

例: Kiro で Security Hub をクエリする

1. ターミナルまたは Kiro IDE を開きます。
2. 次のコマンドを入力します。

"Show me all critical security findings from Security Hub in my production account ID <ACCOUNT ID>"

出力例

> Found 4 critical security findings in account 123456789012:

## Configuration Issues (2)

1. SSM.7 - SSM documents block public sharing disabled
- Status: FAILED (since July 17, 2025)
- Impact: Systems Manager documents can be publicly shared
- Remediation: Enable block public sharing setting for SSM documents
- [Documentation](https://docs.aws.amazon.com/console/securityhub/SSM.7/remediation)

2. Config.1 - AWS Config not properly configured
- Status: FAILED (since March 4, 2025)
- Issue: Config isn't recording required IAM resource types (User, Role, Group, Policy)
- Standards affected: CIS, NIST 800-53, PCI DSS, AWS Foundational Security
- Remediation: Enable recording for IAM resources in AWS Config
- [Documentation](https://docs.aws.amazon.com/console/securityhub/Config.1/remediation)

## Vulnerabilities (2)

3. CVE-2020-36242 in Lambda function: MyLambdaOne
- Package: cryptography version 3.2.1
- CVSS Score: 9.1 (Critical)
- Issue: Integer/buffer overflow in Fernet encryption class
- Fix: Upgrade to cryptography 3.3.2
- Function: SPC-1233HH5R-MyLambdaOne-lUh3ESH0MdXF

4. CVE-2020-36242 in Lambda function: AutoUpdateMyLambdaOne
- Package: cryptography version 3.2.1
- CVSS Score: 9.1 (Critical)
- Same vulnerability as above
- Function: SPC-1233HH5R-AutoUpdateMyLambdaOne-d9HIBfxThbFW

実際の効果
これまでは複数のコンソールを行き来し、ログを手動で突き合わせ、CVE データベースを調べる必要があったセキュリティ検出結果のトリアージを、大幅に迅速化できます。AI を活用したトリアージを Security Hub のワークフローに組み込んだチームからは、重大な検出結果のトリアージにかかる平均時間が数時間から数分に短縮され、より迅速な封じ込めと、複数のアカウントにわたる一貫したカバレッジを実現できたという報告が寄せられています。

AI アシスタントは、インフラストラクチャコードをスキャンし、セキュリティ上の問題を具体的な修正案とともに指摘できます。ただし、これらの変更を実装する際は、本番環境に反映する前に、慎重なレビュー、テスト、検証が必要です。

重要: AI が生成した修復案は、実装前に、十分な知識を持つセキュリティエンジニアがレビューする必要があります。AI が生成した変更を人間による検証なしで自動的に適用すると、意図しない設定ミスやサービスの中断を招く可能性があります。AI の出力は完成品ではなく、出発点として扱ってください。

ワークフロー
このワークフローは、既存の開発環境に合わせて Kiro と Amazon Q Developer のどちらでも実行できます。

1. Kiro または Amazon Q Developer に、インフラストラクチャファイルをスキャンしてセキュリティ上のギャップを特定するよう依頼します。
2. AI が生成した修復案をセキュリティチームとレビューします。
3. 非本番環境で変更をテストします。
4. IAM Access Analyzer、AWS Config、Security Hub などの AWS セキュリティサービスを使用して検証します。
5. モニタリングとロールバックの手順を整えたうえで、本番環境にデプロイします。

プロンプトの例

"Scan my infrastructure at /path/to/templates, identify all S3 buckets without encryption, enable AES-256 encryption, add bucket policies to deny unencrypted uploads, and provide the deployment command"

処理の流れ

AI アシスタントは、AWS CloudFormation、Terraform、AWS Cloud Development Kit (AWS CDK) のいずれで記述されたインフラストラクチャファイルでも分析し、セキュリティのベストプラクティスに違反しているリソースを特定します。そのうえで、AWS Key Management Service (AWS KMS) または Amazon Simple Storage Service (Amazon S3) マネージドキーによる保管時の暗号化などのコントロールを実装し、転送時の暗号化を強制するバケットポリシーを追加して、パブリックアクセスブロックを設定します。さらに、変更内容をプレビューできる正確なデプロイコマンドを生成するため、実際に適用する前に何が変更されるかをレビューできます。

前述のセキュリティ標準のコンテキストファイルの例に基づく場合、生成されるすべてのインフラストラクチャに、保管時と転送時の暗号化、最小権限の IAM ポリシー、セキュリティグループの最適化、VPC の設定、ログ記録の有効化、バックアップとリカバリの設定といったコントロールが適用されます。

検証が必要
AI が生成した設定も、他のインフラストラクチャコードと同様に慎重にレビューする必要があります。一見正しく見えるポリシーでも、組織の最小権限の基準に合わせた調整が必要な場合や、特定のコンプライアンス要件を満たすために暗号化設定の調整が必要な場合があります。コードを人が書いたか AI が生成したかにかかわらず、変更を非本番環境で実行し、本番環境に反映する前に人間が結果を確認することは、インフラストラクチャ運用における基本的なプラクティスです。

実際の効果

複数のアカウントにわたって非準拠のリソースを手動で特定するには何時間もかかることがあり、リソースごとに修復テンプレートを作成すれば、さらに多くの時間がかかります。AI を活用したインフラストラクチャスキャンを導入したセキュリティチームからは、手動での特定やテンプレート作成にかかる時間が減ったという報告があり、AI の支援によって同じ特定と作成の作業をはるかに短時間で完了できます。お客様からは、以前はチームが 1 日の大半を費やしていた修復サイクル全体を、スキャンとテンプレート生成を AI に任せることで 1 時間未満で完了できるようになったという声も寄せられています。なお、規模が大きくなると、手動での修復にかかる時間は大幅に増加します。数十の非準拠リソースの修復は、件数に比例して時間が増える単純な作業ではないためです。一方、非本番環境での検証にかかる時間は、修復内容をどのように生成したかにかかわらず欠かせないものであり、常に計画に組み込んでおく必要があります。

Amazon Q Developer と Kiro は、インフラストラクチャコードを分析し、AWS Well-Architected フレームワークのセキュリティの柱に沿った複数のカテゴリにわたって、潜在的なセキュリティ上の問題を特定できます。

Amazon Q Developer を使用する場合

1. IDE でインフラストラクチャファイルを開きます。
2. レビューするコードを選択します。
3. コンテキストメニューを開いて [Send to Amazon Q] を選択し、続けて [Optimize] を選択します。
4. [Focus on security best practices] を選択します。

Kiro を使用する場合

1. Kiro でインフラストラクチャファイルを開きます。
2. 次のような自然言語のプロンプトを入力します。Perform a comprehensive security review of this CloudFormation template and identify all deviations from our standards. (この CloudFormation テンプレートの包括的なセキュリティレビューを実施し、自社の標準からの逸脱をすべて特定する)
3. Kiro は応答を生成する際に、ステアリングファイルを追加のコンテキストとして自動的に適用します。
4. 検出結果を確認し、フォローアップのプロンプトで改善を繰り返します。

評価されるセキュリティカテゴリ: セキュリティカテゴリとコントロールの網羅的かつ最新の一覧については、AWS Well-Architected フレームワークのセキュリティの柱のドキュメントを参照してください。現在のカテゴリには、次のようなものがあります。

• アイデンティティとアクセス管理: 過剰な許可を付与する IAM ポリシー、多要素認証 (MFA) 要件の欠如、未使用の認証情報とアクセスキー、クロスアカウントアクセスのリスク
• 検出コントロール: CloudTrail のログ記録設定、Amazon CloudWatch アラームのカバレッジ、GuardDuty の有効化状況、AWS Config ルールの実装
• インフラストラクチャ保護: セキュリティグループの設定ミス、パブリックサブネットでの露出、AWS WAF ルールの欠如、暗号化されていないネットワークトラフィック
• データ保護: ストレージの暗号化状況、KMS キーのローテーションポリシー、バックアップ設定、S3 バケットのアクセスコントロール
• インシデント対応: Amazon Simple Notification Service (Amazon SNS) のアラート設定、ログ保持ポリシー、自動対応の仕組み

出力例

Security Recommendations:
- Enable S3 bucket encryption with KMS: Critical
- Implement least privilege IAM policies: High
- Enable GuardDuty threat detection: High
- Configure VPC Flow Logs: Medium
- Add WAF rules for API Gateway: Medium
- Enable CloudTrail in all regions: Critical
- Implement automated backup policies: High

Total security improvements: 23 findings across 5 Well-Architected pillars

設定ファイルを最新の状態に保つ

ステアリングファイルとルールドキュメントの内容を十分かつ最新の状態に保つには、セキュリティアーキテクトによるレビューが引き続き重要です。目指すべきは、やり取りのたびに修正が必要な AI アシスタントではなく、環境をあらかじめ理解している AI アシスタントです。設定ファイルは随時更新するドキュメントとして扱い、セキュリティ標準が変わったとき、新しいサービスを導入したとき、インシデント後のレビューでギャップが判明したときに更新してください。この記事で述べたように、プロジェクトのルールはアーキテクチャのドリフトを抑え、AI エージェントがより自律的に動作するようになっても一貫性を維持するのに役立ちます。

実際の効果

これまでセキュリティエンジニアがインフラストラクチャテンプレートを 1 行ずつ手動で確認していたセキュリティレビューを、AI の支援によって大幅に短時間で完了できます。コードが CI/CD パイプラインのチェックに到達する前のプリコミットゲートとして、AI を活用したセキュリティレビューを使用しているチームからは、セキュリティ検出結果のかなりの部分を開発サイクルの早い段階で捕捉でき、より迅速かつ低コストで対処できるようになったという報告があります。このレビューステップをプルリクエストのワークフローに組み込めば、セキュリティ検証はデプロイのゲートだけでなく、継続的に行われるようになります。

AWS Organizations のサービスコントロールポリシー (SCP) を使用すると、組織内のすべてのアカウントに予防コントロールを一貫して適用でき、個々のアカウント管理者に頼らずにセキュリティベースラインを強制できます。Kiro は、自然言語で記述したセキュリティ要件から SCP の初期ドラフトを生成できるため、ドラフトの作成と改善を繰り返すプロセスを大幅に迅速化できます。ただし、SCP は管理者でも回避できない予防コントロールであるため、設定ミスがあると組織全体でサービスの中断が発生する可能性があります。そのため、SCP を本番環境に適用する前に、専門家による検証と段階的なテストが欠かせません。

ステップ 1: SCP のドラフトを生成する

セキュリティ要件を自然言語で記述します。

"Create an SCP with these security controls:
- Deny creation of S3 buckets without encryption
- Require MFA for IAM user console access
- Prevent public RDS snapshots
- Deny security group rules allowing 0.0.0.0/0 on sensitive ports
- Enforce encryption for all EBS volumes
- Require VPC Flow Logs on all VPCs
- Deny IAM policy creation without approval tags
- Restrict resource creation to approved regions only"

Kiro は、適切な拒否ステートメント、MFA と暗号化を強制する条件キー、リソースレベルの制限、リージョンに関するコンプライアンス要件を含む、完全な SCP の JSON を生成します。

ステップ 2: SCP を検証してリントする

検証の最初のレイヤーとして、Kiro または Amazon Q Developer を使用して、ポリシーのリントと初期テストを行います。Kiro Power として提供されている IAM Policy Autopilot は、Kiro IDE からワンクリックで直接インストールでき、アプリケーションの使用状況を分析して、検出した SDK 呼び出しに基づいて必要な許可を生成します。また、IAM Policy Autopilot は MCP サーバーとして Kiro、Amazon Q Developer、その他の MCP 互換コーディングアシスタントと統合できるため、別のツールとしてではなく、既存のワークフローの一部として自然に利用できます。

"Review this SCP JSON for syntax errors, overly broad deny statements, and missing condition keys. Flag any statements that could unintentionally block legitimate operations."

次に、IAM ポリシーシミュレーターを使用して、AI を活用したリントに加えてもう 1 つの検証レイヤーを追加します。これにより、ポリシーの動作をテストし、条件キーが正しく適用されていること、正当な操作が意図せずブロックされていないことを確認できます。IAM Policy Autopilot は、実際に機能するポリシーを出発点として提供することで、IAM Access Analyzer などの既存の IAM ツールを補完します。生成されたポリシーは、IAM Access Analyzer のポリシー検証で検証したり、未使用のアクセスの分析を使って時間をかけて改善したりできます。これらのツールを組み合わせることで、各ツールが前のステップの出力を強化する多層的な検証アプローチを構築できます。

ステップ 3: サンドボックス環境でテストする

非本番アカウントを含むテスト用の組織単位 (OU) を作成し、そのテスト OU に SCP を適用します。ブロックされるべき操作を試し、正当な操作が意図せずブロックされていないことを確認します。サンドボックスでのテストの前に、Kiro を使用して、提案した SCP に照らしてインフラストラクチャコードを事前に検証しておきます。

"Analyze my current infrastructure against this proposed SCP and identify resources that would be non-compliant"

このスキャンの対象は、インフラストラクチャのコードファイルです。組織全体の稼働中のアカウントをスキャンするには、次の AWS サービスを使用します。

• アグリゲーターとコンフォーマンスパックを備えた AWS Config: 組織全体の継続的なコンプライアンスモニタリング
• IAM Access Analyzer: 外部アクセス、内部アクセス、未使用の許可を対象とした、自動推論に基づく分析
• Account Assessment for AWS Organizations: すべてのアカウントを対象とした、アイデンティティベースのポリシー、リソースベースのポリシー、サービスコントロールポリシーの一括スキャン
• Security Hub: 組織全体のコンプライアンス検出結果とセキュリティスコアの一元的な集約

ステップ 4: セキュリティアーキテクトによるレビュー

セキュリティアーキテクトに依頼して潜在的なリスクを洗い出し、ポリシーが自社のセキュリティフレームワークに沿っていることを確認します。AWS Organizations コンソールで親 OU とルートにアタッチされているすべての SCP を確認し、既存の SCP と競合していないかをチェックします。本番環境へのロールアウトの前に、IAM ポリシーシミュレーターを使用してポリシー間の相互作用をテストし、緊急アクセスの手順 (「SEC03-BP03 緊急アクセスプロセスを確立する – セキュリティの柱」と「SEC10-BP05 アクセスを事前にプロビジョニングする – セキュリティの柱」) が引き続き機能することを確認します。

ステップ 5: 段階的なロールアウト

まず開発アカウントにデプロイし、ポリシー違反や運用上の問題が発生していないかをモニタリングします。その後、対象環境を段階的に拡大し、プロセス全体を通じて文書化されたロールバック手順を維持します。

重要: 専門家による徹底的なレビューと段階的なテストを経ずに、AI が生成した SCP を本番環境に直接デプロイしないことを強くお勧めします。SCP の設定ミスは、組織内のすべてのアカウントに影響が及ぶ、組織全体のサービスの中断を引き起こす可能性があります。

実際の効果

これまで SCP の作成では、セキュリティアーキテクトが複雑な JSON ポリシードキュメントを手動で記述して何度も修正する必要があり、数日間にわたって複数回のレビューを重ねることも珍しくありませんでした。初期のドラフト作成とリントを AI に任せることで、この期間を短縮できます。アーキテクトは、JSON の構文や構造ではなく、ポリシーの設計、エッジケースの分析、組織への影響評価に時間を集中できるようになります。

AI を活用したセキュリティワークフローは、各段階に明確な検証ゲートを設けながら段階的に導入すると、最も効果を発揮します。次の 2 フェーズのアプローチに沿って進めることで、本番環境に拡大する前に、チームが自信を高め、結果を測定し、必要な社内プラクティスを確立する時間を確保できます。

• フェーズ 1: 開発とテスト (1～4 週目): まず、分離された開発アカウントで、AI が生成したセキュリティコントロールをテストします。機能を検証してエッジケースを洗い出したうえで、専用のテスト環境にデプロイし、徹底的なセキュリティ検証を行います。IAM Access Analyzer、AWS Config、Security Hub を使用して、生成されたコントロールが想定どおりに動作することを確認します。このフェーズは、セキュリティチームと開発チームの双方で社内の専門知識を蓄積するのにも適した時期です。何がうまく機能し、何に人間のレビューが必要かという知見を、最初から幅広く共有できます。
• フェーズ 2: ステージングと本番 (5 週目以降): 検証済みのコントロールを、本番環境と同等のステージング環境に適用します。必要に応じてペネトレーションテストを実施し、さらに範囲を広げる前に、モニタリングとアラートが正しく機能することを検証します。継続的なモニタリングを整えたうえで、本番アカウントに段階的にロールアウトします。全体を通じてロールバック手順を維持するとともに、フィードバックループを確立し、本番環境で得られた教訓をステアリングファイル、ルールドキュメント、検証プロセスに継続的に反映させます。

この記事のアプローチが、AI コーディングアシスタントに関する一般的なガイダンスと異なるのは、セキュリティとの統合を具体的に示している点です。AI アシスタントによる開発の加速について解説したコンテンツは数多くあります。一方、この記事では、Kiro と Amazon Q Developer をセキュリティに特化したタスクに活用するための設定方法に焦点を当てました。具体的には、Security Hub の検出結果のトリアージ、組織で定義した標準に基づくインフラストラクチャコードの脆弱性の修復、Well-Architected に基づくセキュリティレビューの実施、SCP の作成と検証、そして一般的なデフォルト設定ではなく自社の環境を反映した永続的なコンテキストによる、デフォルトで安全なインフラストラクチャの生成です。

Kiro は、仕様駆動開発によってプロトタイプから本番環境への移行を支援するエージェント型 IDE です。ステアリングファイルを使用すると、エージェントはすべてのセッションにわたってセキュリティ標準を常に把握できます。Amazon Q Developer は、既存の AWS 環境や IDE のワークフローと緊密に統合することで、Kiro を補完します。これらのツールを組み合わせることで、セキュリティチームの関与を開発ライフサイクルのあらゆる段階に広げ、セキュリティの専門知識を開発チームにも展開し、脆弱性が混入してから検出されるまでの時間を短縮できます。AWS Well-Architected フレームワークのセキュリティの柱で示されているように、開発プロセス全体を通じて早い段階から一貫してセキュリティを組み込むことは、強固なセキュリティポスチャの基盤となります。

これら 5 つの手法は、既存のセキュリティコントロールを置き換えるものではありません。チームのメンバーがセキュリティの専門家かアプリケーション開発者かにかかわらず、セキュリティを AWS での構築作業の自然な一部にするためのものです。この記事で紹介した 5 つの手法に加えて、次の AWS の機能もこのアプローチを補完するものです。より包括的に理解するために、ぜひ確認してみてください。

• Amazon Inspector は、AWS ワークロードのソフトウェアの脆弱性、コードの脆弱性、意図しないネットワークの露出を継続的にスキャンする脆弱性管理サービスです。Amazon EC2 インスタンス、Amazon ECR 内のコンテナイメージ、AWS Lambda 関数、ファーストパーティのコードリポジトリを自動的に検出してスキャンします。Amazon Inspector は、Jenkins、TeamCity、GitHub Actions、Amazon CodeCatalyst 向けのプラグインを通じて CI/CD パイプラインに直接統合できるため、デプロイ前に脆弱性を検出できます。コードセキュリティ機能には、静的アプリケーションセキュリティテスト (SAST)、ソフトウェアコンポジション解析 (SCA)、IaC スキャンが含まれ、GitHub や GitLab とネイティブに統合されています。すべての検出結果は Security Hub に直接表示されるため、組織全体で一元的に可視化して対応できます。
• Amazon Q Developer のセキュリティスキャンは、IDE 上でセキュリティ上の問題をリアルタイムに検出します。セキュリティ上の脆弱性を対象とした SAST スキャン、シークレットの検出、IaC のセキュリティ評価、サードパーティの依存関係に対する SCA などに対応しています。これらの機能は、JetBrains、Visual Studio Code、Visual Studio で利用できます。
• Kiro Powers は、Kiro パートナーが検証した MCP サーバー、ステアリングファイル、フックを厳選してパッケージ化したもので、特定の開発やデプロイのユースケースを加速します。セキュリティ関連の Kiro Powers には、ベースラインとなる IAM ポリシーを生成する IAM Policy Autopilot Kiro Power や、Kiro 向けのリアルタイムなコーディングセキュリティ検証を行う MCP サーバーパターンなどがあります。
• AWS Security Agent は、開発ライフサイクル全体を通じてアプリケーションをプロアクティブに保護する、フロンティア AI エージェントです。セキュリティチームは、承認済みの暗号化ライブラリ、認証フレームワーク、ログ記録標準など、組織のセキュリティ要件を AWS Security Agent コンソールで一度定義するだけで済みます。その後は、AWS Security Agent が定義済みの標準に照らしてアーキテクチャドキュメントとコードを評価し、開発全体を通じてこれらの要件を自動的に検証します。主な機能は 3 つあります。アーキテクチャドキュメントを対象とした設計セキュリティレビュー、接続されたリポジトリのプルリクエストを定義済みの標準に照らして自動的に分析するコードセキュリティレビュー、そして各アプリケーションに合わせてカスタマイズされた高度な多段階の攻撃シナリオを通じて脆弱性を発見、検証、報告するオンデマンドのペネトレーションテストです。脆弱性が見つかると、AWS Security Agent は、すぐに適用できる修正を含むプルリクエストをコードリポジトリに直接作成します。お客様からは、AWS Security Agent によってペネトレーションテストの期間が数週間から数時間に短縮されたという報告があります。ペネトレーションテストが定期的に発生するボトルネックからオンデマンドで実行できる機能へと変わることで、リスクへの露出を減らし、開発のスピードに合わせてセキュリティレビューをスケールできるようになります。
• AWS Security Hub の自動対応と修復は、AWS Systems Manager Automation を使用して一般的な検出結果に対応する構築済みのプレイブックを提供します。これにより、チームは検出結果に対してより迅速かつ一貫して対処できます。

AI を活用したセキュリティワークフローを初めて導入する場合は、次の週ごとのアプローチに沿って進めると、基盤が整う前に手を広げすぎることなく、着実に前進できます。

• 1 週目と 2 週目: 前述の基本セットアップのセクションで説明したとおり、上位 10 件のセキュリティポリシーを使用して永続的なコンテキストファイルを設定します。Security Hub と CloudTrail にアクセスするための MCP サーバーを Kiro で設定し、対象アカウントの認証情報が正しく設定されていることを確認します。
• 3 週目と 4 週目: 非本番のインフラストラクチャテンプレートを対象に、AI を活用した最初のセキュリティレビューを実行します。検出結果を直近の手動レビューの結果と比較し、長期的な効果を測定するためのベースラインを確立します。
• 5 週目と 6 週目: 新しい予防コントロール 1 つを対象に、AI を活用した SCP の作成を試験的に導入します。本番環境に適用する前に、AI を活用したリント、IAM Policy Autopilot、IAM ポリシーシミュレーターを含む検証ワークフローをすべて実行します。
• それ以降: 基本セットアップのセクションで説明した指標を測定し、標準の変化に合わせてステアリングファイルとルールドキュメントを更新します。また、得られた知見をセキュリティチーム、開発チーム、プラットフォームエンジニアリングチームの間で共有します。何がうまく機能し、何に人間の判断が必要かという知見は、組織内でインフラストラクチャに携わるすべての人にとって価値があります。

Kiro と Amazon Q Developer は、既知の設定ミスのスキャン、ポリシー JSON の作成、CVE の調査、安全なインフラストラクチャの生成といった、時間がかかるわりに戦略的な価値が低いタスクを担うことで、セキュリティチームが脅威への対応を迅速化し、一貫したセキュリティカバレッジを維持するための実用的なツールとなります。これらの AI アシスタントは、セキュリティエンジニアと組み合わせることで最も効果を発揮します。AI アシスタントが評価とコード生成を加速する一方で、人間によるレビュー、ポリシー設計、リスク判断はあらゆる段階で引き続き不可欠です。

この記事で紹介した 5 つの手法、つまり、まず永続的なコンテキストによってセキュリティのベストプラクティスを組み込み、その基盤を Security Hub の検出結果のトリアージ、インフラストラクチャコードの修復、Well-Architected に基づく詳細なセキュリティレビュー、SCP の作成に活用することで、組織が求める標準を維持しながら AWS のセキュリティポスチャを強化できます。

Security Hub、IAM Access Analyzer、AWS Config、CloudTrail などの AWS サービスは、これらの AI を活用したワークフローの基盤となり、環境全体のセキュリティコントロールを一元的に可視化し、自動的に検証できるようにします。SCP などの予防コントロールをデプロイする前に、AWS Well-Architected のセキュリティの柱にあるブレークグラス (緊急アクセス) のガイダンスと、ブレークグラスアクセスに関する AWS 規範ガイダンスに従って、緊急アクセスの手順を確立し、検証しておいてください。

まずは非本番環境で小さく始め、明確な検証プロセスを確立して結果を測定しながら、チームの専門知識と自信の高まりに合わせて AI アシスタントの活用範囲を徐々に広げてください。その結果、脅威への対応が迅速化し、セキュリティカバレッジの一貫性が高まり、セキュリティエンジニアは反復的なタスクではなく複雑な意思決定に集中できるようになります。

• AWS Well-Architected フレームワークのセキュリティの柱 – Well-Architected フレームワークの 5 つの柱にわたる、セキュリティの基本的なベストプラクティス
• AWS Security Hub のベストプラクティス – 脆弱性管理に関するガイダンス
• AWS Security Incident Response の ITSM 統合 – Jira と ServiceNow 向けの AWS Security Incident Response のオープンソース統合と、Kiro と Amazon Q Developer を使用して迅速にカスタマイズするためのガイダンス
• AWS Security Blog – AWS セキュリティチームによる最新のセキュリティガイダンス、お客様事例、お知らせ