AIエージェントを本番投入する前に確認したい、AWS AIセキュリティ設計チェックリスト

クラウド

生成AIやAIエージェントの導入では、モデルの精度や応答速度に注目が集まりがちです。しかし本番環境で問題になるのは、プロンプトインジェクション、過剰な権限、機密データの漏えい、ツールの誤操作、監査不能といった「AIならではの攻撃面」です。

AWSが示すAI Security Frameworkは、これらの対策を「インフラストラクチャ」「アイデンティティとデータ」「AIアプリケーション」の3レイヤーに分け、さらにFoundational、Enhanced、Advancedの3フェーズで段階的に強化する考え方です。すべての対策を最初から実装するのではなく、システムの成熟度とリスクに応じて適切なコントロールを選ぶ点が、実務上の重要なポイントです。

3つの防御レイヤーで責任範囲を整理する

1. インフラストラクチャレイヤー

最下層では、AIワークロードを動かすAWSアカウント、ネットワーク、コンピュート、ストレージ、ログ基盤を保護します。生成AIアプリケーションであっても、基本的なクラウドセキュリティが不要になるわけではありません。

代表的な確認項目は次のとおりです。

  • 本番・検証・開発アカウントを分離しているか
  • IAMやAWS Organizations、SCPで利用可能な操作を制限しているか
  • Amazon VPC、セキュリティグループ、AWS PrivateLinkなどで通信経路を最小化しているか
  • AWS CloudTrail、Amazon GuardDuty、AWS Security Hubなどで操作と脅威を検知できるか
  • S3バケット、ログ、モデル関連ファイルが公開状態になっていないか
  • 脆弱性管理やコンテナイメージのスキャンを継続しているか

Amazon Bedrockのようなマネージドサービスを利用する場合でも、利用者側のIAM設定、データ保管先、ネットワーク、ログの設計は残ります。マネージドであることを「セキュリティ設計が不要」と解釈しないことが重要です。

2. アイデンティティとデータレイヤー

AIシステムでは、誰がモデルを呼び出せるかだけでなく、モデルやエージェントが「どのデータを読み、どの操作を実行できるか」を制御する必要があります。

特にAIエージェントでは、アプリケーションのIAMロールに広い権限を与えると、プロンプトや取得データに誘導されて意図しない操作を実行する可能性があります。実装時には、次のような最小権限設計が有効です。

  • ユーザー、アプリケーション、エージェント、ツールごとに権限を分離する
  • IAMロールは目的別に作成し、不要なAWS APIを許可しない
  • ツール呼び出しごとに入力値、対象リソース、実行者を検証する
  • 機密データにはタグ、テナントID、属性ベースのアクセス制御を適用する
  • KMSによる暗号化と、Secrets Managerなどを用いた秘密情報管理を行う
  • 入力、検索結果、出力、ツール実行履歴を監査可能な形で記録する

RAGを採用する場合は、ベクトル検索に投入する文書のアクセス権を無視しないことが重要です。検索インデックスを全利用者で共有すると、本来見せてはいけない文書の断片が回答に混入する可能性があります。文書の取り込み時と検索時の両方で認可を適用し、テナントやユーザー属性を検索条件に反映させる必要があります。

3. AIアプリケーションレイヤー

最上位では、モデル、プロンプト、RAG、エージェント、外部ツールを組み合わせたアプリケーション固有のリスクを扱います。従来のWebアプリケーション対策に加え、AIの入力と出力が持つ不確実性を前提に設計します。

主なチェック項目は次のとおりです。

  • プロンプトインジェクションや間接プロンプトインジェクションを想定しているか
  • システムプロンプトに秘密情報や過剰な業務ルールを埋め込んでいないか
  • 入力・出力に対する有害性、個人情報、機密情報の検査を行っているか
  • モデルが生成したSQL、コマンド、メール、APIリクエストをそのまま実行していないか
  • 高リスク操作に人間の承認や二重確認を要求しているか
  • 利用モデル、プロンプト、ナレッジ、ツール定義をバージョン管理しているか
  • 失敗時に安全側へ倒れるフォールバックを用意しているか

Amazon Bedrockのガードレールは、モデル入出力のフィルタリングや機密情報対策の一部に活用できます。ただし、ガードレールだけでアプリケーション全体を保護できるわけではありません。認可、業務ロジック、ツール実行の制御、監査ログはアプリケーション側でも実装する必要があります。

3段階の成熟度モデルで対策を現実的に進める

Foundational：プロトタイプでも省略しない最低限の対策

Foundationalは、検証段階から本番の初期導入までに必要な基礎対策です。プロトタイプだからといって、実データや本番権限をそのまま使うのは避けるべきです。

最低限、以下を実施します。

  • 開発用アカウントと本番環境を分離する
  • 本番データではなく、マスキング済みまたは合成データを使う
  • IAMの最小権限とMFAを適用する
  • Secrets ManagerやParameter Storeで秘密情報を管理する
  • CloudTrailなどで主要な操作を記録する
  • モデルへの入力と出力に個人情報・機密情報を含めないルールを定める
  • エージェントのツール権限を読み取り中心に限定する

この段階の目的は、完璧なAIセキュリティを実現することではありません。検証コードがそのまま本番へ持ち込まれ、後から修正しにくい状態になることを防ぐことです。

Enhanced：本番運用に耐える管理と検証

利用者やデータ量が増え、業務プロセスに組み込む段階では、個別設定だけでなく継続的な検証が必要になります。

たとえば、Amazon MacieによるS3上の機密データ検出、AWS Configによる設定評価、Security Hubによる検出結果の集約、CloudWatchやOpenTelemetryを利用した可観測性の整備が考えられます。モデルやプロンプトの変更はCI/CDパイプラインに組み込み、セキュリティテストや回帰テストを通過したものだけをデプロイします。

AI固有のテストとしては、次のようなシナリオが有効です。

  • 指示の無視を促す悪意ある入力
  • RAG文書に埋め込まれた不正な指示
  • 権限のないデータを要求する質問
  • ツールに不正な引数を渡す要求
  • 個人情報や秘密情報を出力させる要求
  • モデル障害や外部API障害が発生した場合の挙動

Advanced：大規模・高リスク環境での継続的な防御

複数のエージェント、複数アカウント、複数リージョンに展開する段階では、統制を中央集約し、異常を継続的に分析する必要があります。エージェントの行動履歴、データアクセス、モデル変更、ツール利用を相関分析し、通常と異なる振る舞いを検出します。

高リスクな業務では、完全自動化を目指すよりも、操作の分類が重要です。情報検索は自動実行、社内システムの更新は承認必須、送金や外部への通知は人間による明示承認、といったように、影響度に応じて実行権限を分けます。

AWSサービスをどう組み合わせるか

サービス選定は、単一の製品でAIセキュリティを完成させるのではなく、役割ごとに組み合わせるのが基本です。

  • 認証・認可：IAM、IAM Identity Center、Organizations、SCP
  • データ保護：KMS、Secrets Manager、Macie、S3のアクセス制御
  • ネットワーク：VPC、PrivateLink、セキュリティグループ、Network Firewall
  • 脅威検知・監査：CloudTrail、GuardDuty、Security Hub、AWS Config
  • AI制御：Amazon Bedrockのガードレール、モデルアクセス管理、プロンプトと出力の検査
  • 運用監視：CloudWatch、AWS X-Ray、ログ分析基盤

ただし、サービスを導入した数がセキュリティ成熟度を示すわけではありません。誰が、どのデータに、どの操作を行い、その結果をどの期間監査できるのかという制御目的を先に定義し、その後でサービスを割り当てるべきです。

他のAIセキュリティフレームワークとの違い

AWS AI Security Frameworkは、AWS上でAIを設計・運用する際に、クラウドの責任共有モデルとAWSサービスへ落とし込みやすい点が特徴です。一方、NIST AI Risk Management FrameworkはAIリスクの識別・測定・管理といった組織横断のリスクマネジメントに適しており、OWASPのLLM関連ガイドラインはプロンプトインジェクションや不適切な出力処理など、アプリケーションの脆弱性を把握するのに向いています。

実務では、これらを競合するものとして選ぶのではなく、組み合わせて使うのが現実的です。AWSの3レイヤーと成熟度モデルで実装計画を作り、NISTでガバナンスやリスク受容を整理し、OWASPでLLMアプリケーションのテスト項目を補完する、といった使い分けができます。

本番投入前の最終チェックリスト

最後に、AIエージェントや生成AIサービスを本番へ移行する前に、次の質問へ答えられるかを確認します。

  1. 利用するデータの分類と、データごとのアクセス権を説明できるか
  2. モデル、エージェント、ツールが持つ権限を個別に確認できるか
  3. プロンプトインジェクション時に、機密情報や危険な操作を防げるか
  4. モデル出力を業務処理へ渡す前に検証しているか
  5. 高リスク操作に人間の承認を要求しているか
  6. 入力、出力、検索、ツール実行、設定変更を監査できるか
  7. モデルやプロンプト変更をテストして安全にロールバックできるか
  8. 障害や異常検知時に、停止・隔離・通知する手順があるか

AIセキュリティの本質は、モデルを信用することでも、すべての操作を禁止することでもありません。インフラ、アイデンティティとデータ、AIアプリケーションの各層で責任範囲を分け、システムの成熟度に応じてコントロールを積み上げることです。AWS AI Security Frameworkを設計レビューのチェックリストとして使えば、プロトタイプの速度を保ちながら、本番運用に必要な安全性を段階的に高められます。

出典： AWS公式ブログ

タイトルとURLをコピーしました