Well-Architected Framework:セキュリティの柱

根拠

入力は AI システムの最初の接点です。従来のパラメータ検証とは異なり、AI の入力は自然言語です。「悪意」は形式エラーとして現れるのではなく、意味レベルの意図として現れます。それでも、基本的な形式検証は依然として必要な最初のフィルタです。低コストで、単純だが頻出する攻撃の試行を一定数ブロックできます。

実装

長さ制限：ユーザー入力に対して妥当な上限トークン数を設定します。過度に長い入力は推論コストを増やすだけでなく、インジェクションの典型的な手段でもあります。攻撃者はパディングを用いてシステムプロンプトを有効範囲の外へ「押し出す」ためです。ビジネスシナリオに基づき、たとえば会話シナリオでは 2,048 トークン、ドキュメント分析シナリオでは 8,192 トークンなど、妥当な閾値を設定してください。制限を超える入力は拒否し、通知を返します。

エンコーディングの正規化：すべての入力を標準の UTF-8 エンコーディングに正規化します。ゼロ幅文字、不可視の Unicode 制御文字、ホモグリフを除去します。攻撃者はこれらの特殊文字を用いてキーワード検知を回避することがよくあります。たとえば、単語の途中にゼロ幅文字を挿入すると、ルールエンジンでは見逃されても、モデルは理解できる場合があります。後続の処理に進む前に、必ず正規化を完了してください。

攻撃パターン検知：既知の攻撃パターンのシグネチャライブラリを維持し、正規表現マッチングと意味分類の両方で検知します。正規表現は、構造化されたパターン (たとえば "ignore previous instructions" や "system prompt:" といった一般的なインジェクションの接頭辞) に使用します。意味分類モデルはさまざまな言い回しに対応します。セキュリティコミュニティが公開する新たな攻撃手法や、社内で検知した攻撃の試行を取り込み、シグネチャライブラリを継続的に更新します。

アンチパターン：入力フィルタリングをキーワードのブロックリストのみに依存すること。類義語、言語混在、比喩などの自然言語の変化により、単純なキーワード一致は容易に回避されます。もう 1 つの一般的なアンチパターンは、入力を一切検証せずにモデルへ直接送信し、攻撃からの防御をモデル自身の安全性アラインメントに全面的に依存することです。

Alibaba Cloud での実装：Model Studio の [Application Configuration] は、入力長制限とコンテンツセキュリティポリシーをサポートします。AI Security Guardrail のマネージドルールとカスタムルールを使用することで、AI サービスに到達する前に明らかに悪意のあるリクエストをブロックできます。

根拠

単一の防御レイヤーでは、どれほど強固であっても回避される可能性があります。多層防御はセキュリティエンジニアリングの基本原則です。AI の文脈では、モデルの前後に独立したセキュリティ検知レイヤーを配置し、攻撃者が成功するには複数の防御線を突破しなければならない状態にすることを意味します。

実装

モデル前フィルタリング：メインモデルとは独立した軽量セキュリティ分類器を配置し、ユーザー入力のリスクを評価します。分類軸には、インジェクション攻撃の確率、有害コンテンツカテゴリ、センシティブトピック識別などを含めます。セキュリティ分類器とメインモデルはパラメータを共有しないようにして、攻撃者が 1 つの手法で両方を回避できないようにします。アクションは "Block"、"Alert"、"Allow" の 3 つを使用します。ブロックされた入力には標準の拒否応答を返します。アラート対象の入力は、追加のセキュリティ制約 (たとえばシステムプロンプトに強化した安全指示を付加) を加えてから通過させます。許可された入力は通常どおり処理します。

モデル後モデレーション：モデル出力に対して、モデル前フィルタとは異なるモデレーションモデルまたはルールセットでセキュリティチェックを実行します。モデル後チェックは、有害コンテンツに加え、次のようなより広い軸をカバーします：個人情報漏えい (出力中の電話番号や ID 番号などのパターン検知)、著作権コンテンツの複製 (保護対象テキストと類似する大きな出力セグメントの検知)、事実性リスクのフラグ付け (法令、医療助言、金融データなどの高リスク領域に関連する出力のマーキング)。

2 つのレイヤーの独立性は、モデルアーキテクチャ、学習データ、更新サイクルを分けて維持します。これにより、単一の手法で両レイヤーを同時に回避できるようなシステム的バイアスを回避できます。

アンチパターン：モデル前またはモデル後のどちらか一方にのみ、単一レイヤーのセキュリティ検知を配置すること。モデル前フィルタリングだけでは、複雑なマルチターン会話で、各入力は無害に見えても、モデルが段階的に有害出力へ誘導される可能性があります。モデル後モデレーションだけでは、悪意ある入力がすでにモデルへ到達しており、会話履歴の汚染など、内部状態へ影響している可能性があります。

Alibaba Cloud での実装：AI Security Guardrail は入力および出力のモデレーション段階の両方をサポートし、異なるポリシー強度を設定できます。より細かな制御が必要なシナリオでは、Content Moderation API を個別に呼び出し、アプリケーションコードでモデル前・モデル後の明示的な検知ロジックをオーケストレーションしてください。Web Application Firewall (WAF) は、HTTP リクエストレベルで明らかな攻撃トラフィックをブロックする予備レイヤーとして利用できます。

根拠

生成 AI の中核リスクの 1 つはハルシネーションであり、モデルが完全に捏造した情報を自信満々に出力することがあります。RAG シナリオでは、出力は検証可能である必要があります。つまり、生成内容をナレッジベース内の特定ソースへトレースできる必要があります。出力のトレーサビリティ検証の目的は、モデルが取得した参照情報に忠実であり、情報を捏造していないことを確認する点にあります。

実装ガイドライン

引用検証：事実に関する記述には、ナレッジベースのドキュメント ID や段落位置などのソースの引用を必須にします。生成後に引用を検証します。引用されたドキュメントが存在するか、段落内容がモデルの記述を裏付けるかを確認します。引用が無効、または結論を支持しない場合は、出力を低信頼としてマークし、補足文を追加します。

事実性スコアリング：データ、規制、技術仕様などの客観的事実を含む出力に対して、別の検証モデルまたはルールエンジンでスコアリングします。スコアが設定した閾値を下回る場合は、"This information is for reference only. Check the official source for accuracy." のような免責文を追加します。あるいは、手動レビューをトリガーします。

検索のトレースバック：RAG シナリオでは、各出力の生成に対する検索結果を記録します。これにより、出力 → 検索結果 → ソースドキュメントという完全なチェーンが作られます。ユーザーが出力の正確性に疑義を呈した場合、このチェーンにより迅速に原典へ遡って検証できます。

アンチパターン：モデル出力に対して事実検証を一切行わない、または末尾に汎用的な免責文を付けるだけ、というのはアンチパターンです。法的助言、医療上の推奨、金融上の意思決定などの高リスクシナリオでは、ソース検証の欠如が深刻なコンプライアンスリスクと信頼リスクにつながります。

Alibaba Cloud での実装：Model Studio の RAG アプリケーションは引用ソースの表示をサポートし、生成結果にナレッジベースのソース引用を含めます。Log Service (SLS) を使用して、検索結果を含む各推論の完全なコンテキストを記録します。これにより、事後のトレースバック分析が可能になります。

根拠

AI システムは、機密度の異なる多様なソースからデータを処理します。異なる分類のデータを同一ストレージに混在させ、単一の権限モデルでアクセス可能にすることは、データ漏えいの主な原因です。データ分類は一度きりのラベリング作業ではなく、データライフサイクル全体にわたる動的な管理プロセスである必要があります。

実装

AI データ分類標準を少なくとも 4 段階で定義します：Public Data (学習と検索に自由に使用可能)、Internal Data (社内ナレッジベースなど、組織内での利用に限定)、Sensitive Data (PII または業務上の機密を含み、利用が制限される)、Highly Confidential Data (中核的な営業秘密、または規制により特別に保護されるデータで、一般に AI システムでの利用は避けるべき)。

分類ごとにベクトルデータベースを分離します。異なるセキュリティレベルのデータは、別々のベクトルデータベースインスタンス、または別々のコレクションに格納し、独立したアクセス制御ポリシーを設定します。同一のベクトルデータベースに異なる機密度のデータを混在させないでください。セマンティック検索がセキュリティ境界をまたいで、Highly Confidential なコンテンツを返す可能性があるためです。

データ分類に基づき、推論サービスに対するアクセス制御を強制します。ユーザーの権限レベルにより、検索可能なデータ範囲を決定します。たとえば、一般社員のクエリでは Public と Internal のナレッジベースのみを検索し、管理職は Sensitive レベルまで検索できるようにします。この判断は、生成段階でモデルに委ねるのではなく、検索段階で強制する必要があります (モデルは信頼できるセキュリティ境界ではありません)。

アンチパターン：すべてのデータを 1 つの巨大なベクトルデータベースに取り込み、"Do not answer questions about confidential content." のようなプロンプト指示に依存すること。モデル指示はセキュリティ境界ではありません。どのようなプロンプトインジェクションでも、この「防御」を回避できます。

Alibaba Cloud での実装：DataWorks は自動データ分類とラベリング機能を提供し、データ取り込みプロセスに統合できます。Model Studio のナレッジベースは複数ナレッジベースの分離をサポートし、異なるアプリケーションを異なるナレッジベースにバインドすることでデータ境界を強制できます。Resource Access Management (RAM) ポリシーを使用して、どのロールがどのナレッジベースへアクセスできるかを制御します。

根拠

企業の社内 AI プラットフォームは、複数の事業部門やテナントにサービスを提供することがよくあります。効果的なテナント分離がない場合、モデルのコンテキストウィンドウや共有キャッシュを介して、あるテナントのデータが別のテナントに漏えいする可能性があります。SaaS モデルでは、テナント分離は基本的なセキュリティ要件です。

実装

セッションレベルの分離：各セッションまたは各リクエストのコンテキストが完全に独立していることを保証します。会話履歴、システムプロンプト、検索結果を共有しないでください。長期メモリ機能を使用する場合は、メモリストレージをテナントまたはユーザー単位で分離し、ユーザー間のメモリアクセスを防止します。

推論リソース分離：高いセキュリティ要件を持つテナントには、専用の推論インスタンス (非共有 GPU) を提供し、同一物理デバイス上の別テナントの推論情報がサイドチャネル攻撃によって推測されるのを防ぎます。PAI-EAS は専用インスタンスのデプロイモードをサポートします。

ナレッジベース分離：異なるテナントのナレッジベースデータを物理的または論理的に分離します。論理分離はメタデータフィルタリング (たとえば、検索時に tenant_id のフィルター条件を強制) により実現します。物理分離は別々のベクトルデータベースインスタンスにより実現します。高セキュリティシナリオでは物理分離を推奨します。

アンチパターン：複数テナントで 1 つの巨大なベクトルデータベースを共有し、アプリケーション層のコードだけでテナントフィルター条件を付与すること。アプリケーション層に欠陥がある場合 (テナントフィルターが欠落した API エンドポイントなど)、テナント間のデータアクセスが発生してしまいます。

Alibaba Cloud での実装：Model Studio はアプリケーションレベルでナレッジベースと会話コンテキストの分離をサポートします。PAI-EAS は専用リソースグループへのデプロイをサポートし、コンピュートレイヤーでのリソース分離を提供します。RAM の条件ポリシーと組み合わせることで、テナント単位のきめ細かな権限制御を実現できます。

根拠

ベクトルデータベースは、企業のナレッジベースのセマンティックインデックスを格納します。内容はベクトル形式ですが、デコードや最近傍探索により元の意味情報を復元できる可能性があります。ベクトルデータベースの保護レベルは、元データそのものの保護レベルを下回ってはなりません。

実装

保管時の暗号化：ベクトルデータベースの保管データを AES-256 で暗号化します。Key Management Service (KMS) を使用してキーを管理します。KMS はキーローテーションをサポートします。暗号化の粒度は少なくともコレクションレベルに設定し、セキュリティレベルの異なるコレクションに対して異なる暗号鍵を使用できるようにします。

転送中の暗号化：クライアントとベクトルデータベース間の通信に TLS 1.2+ 暗号化を強制します。VPC 内にデプロイする場合は、プライベートエンドポイント経由でアクセスし、ベクトルデータベースをパブリックインターネットへ公開しないでください。

アクセス制御：最小権限の原則に基づき、ベクトルデータベースへのアクセス資格情報を割り当てます。推論サービスには読み取り専用 (ベクトル検索のみ) の資格情報、データパイプラインには書き込み (データ更新) の資格情報、管理操作には別の管理者資格情報を分離して使用します。資格情報は定期的にローテーションし、操作監査ログを有効化します。

クエリ結果のフィルタリング：ベクトル検索で結果が返った後、モデルへ渡す前に、権限に基づいて結果をフィルタリングします。現在のユーザーにアクセス権限のないドキュメント断片は除外します。権限判断はモデルの振る舞いではなく、事前に維持するドキュメントのアクセス制御リスト (ACL) に基づいて行います。

アンチパターン：ベクトルデータベースをデフォルト設定のままデプロイすること (暗号化なし、独立したアクセス制御なし、すべてのサービスで単一のフル権限資格情報を共有)。

Alibaba Cloud での実装：Alibaba Cloud Vector Search は VPC 内でのプライベートデプロイとデータ暗号化をサポートします。RAM を使用して、きめ細かなアクセス制御ポリシーを設定します。ActionTrail はセキュリティ監査のために操作イベントを記録します。

根拠

モデルは AI システムの中核アーティファクトであり、その来歴はシステムのセキュリティベースラインを直接左右します。ソフトウェアがソフトウェア部品表 (SBOM) によりコンポーネントの出自を追跡するのと同様に、モデルも「モデル部品表」により構成を記録する必要があります。これには、ベースモデルの出所、学習データソース、ファインチューニング手法、依存ライブラリやフレームワークのバージョンなどが含まれます。

実装

各モデルに対して構造化されたモデル SBOM を作成します。最低限、次を含めます：ベースモデル識別子 (名称、バージョン、ハッシュ、入手チャネル)、学習/ファインチューニング用データセット識別子 (名称、バージョン、ソース)、学習フレームワークとそのバージョン、主要ハイパーパラメータ、学習環境の説明、出力モデルファイルのハッシュ値。

モデル SBOM はモデルアーティファクトとともにアーティファクトリポジトリへ保存します。署名によってモデルアーティファクトと SBOM を紐付け、改ざんや分離ができないようにします。

本番デプロイ前に、自動プロセスで SBOM に記載されたベースモデルの出所が信頼できるチャネル (Alibaba Cloud Model Hub や監査済みの社内モデルライブラリなど) であることを検証し、既知のセキュリティアドバイザリがないか確認します。これはソフトウェア依存関係の脆弱性スキャンに似ていますが、モデルの「依存関係」に対して適用します。

アンチパターン：インターネットからモデル重みファイルをダウンロードし、来歴の検証、系譜の記録、改ざんチェックを行わずにそのまま本番環境へデプロイすること。

Alibaba Cloud での実装：PAI Model Registry はモデルメタデータの構造化保存とバージョン管理をサポートします。Container Registry (ACR) を使用してモデルイメージに署名し、脆弱性スキャンを実施します。モデルの出自は Model Hub または ModelScope コミュニティの元レコードまで追跡できます。

根拠

モデル学習から本番デプロイまで、アーティファクトは学習、エクスポート、圧縮、コンテナ化、デプロイなど、複数の段階を経由します。どの段階でもアーティファクトが改ざんされると、セキュリティリスクにつながります。アーティファクト署名により、本番にデプロイされるアーティファクトがセキュリティレビューを通過したものと同一であり、中間で改ざんされていないことを保証できます。

実装

学習完了直後に、モデルアーティファクトのハッシュダイジェストを算出して署名します。署名には非対称暗号を使用します。セキュリティチームは秘密鍵を独立して管理し、KMS に格納します。

CI/CD パイプラインの重要な受け渡し点 (学習出力からアーティファクトリポジトリ、リポジトリからデプロイ環境など) ごとに署名検証を実施します。検証に失敗した場合はプロセスをブロックし、セキュリティアラートを発報します。

モデルをコンテナイメージとして配布するコンテナ化デプロイシナリオでは、コンテナイメージ署名 (たとえば cosign) を有効化します。Kubernetes ノードがイメージをプルする際に署名を検証し、未署名または無効な署名のイメージのデプロイを拒否します。

以前のバージョンへロールバックする場合も、対象バージョンが署名により検証済みであることを確認します。これにより、攻撃者が「旧バージョン」を偽装して悪意あるアーティファクトをデプロイすることを防ぎます。

アンチパターン：整合性チェックなしで、共有ストレージやファイル転送でチーム間のアーティファクトを受け渡すこと。デプロイスクリプトが学習ノードから直接モデルファイルを取得し、中間の署名検証ステップがないこと。

Alibaba Cloud での実装：ACR Enterprise Edition は、コンテナイメージ署名とデリバリーチェーンポリシーをサポートし、デプロイ時の署名検証を強制できます。Key Management Service (KMS) を使用して署名鍵を管理し、ActionTrail によりすべてのアーティファクト操作の監査ログを記録します。

根拠

モデルは企業の中核資産であるため、アクセス権限を精密に制御する必要があります。データサイエンティスト、エンジニア、運用担当者、ビジネス関係者など、役割によってモデルに対する操作ニーズは異なります。最小権限の原則に従う必要があります。

実装

モデル操作の権限軸を明確に定義します：モデルの作成/登録、モデルメタデータの閲覧、モデル重みのダウンロード、推論サービスへのモデルデプロイ、推論 API の呼び出し、モデル設定の変更、モデルの削除。各ロールには、業務に必要な最小権限のみを付与します。

モデル重みのダウンロードとエクスポートは極めて機微な操作です。これらはごく少数のロールに限定し、承認プロセスを必須にして、内部関係者による無断コピーを防ぎます。

推論 API 呼び出し権限はアプリケーション単位で分離します。各アプリケーションは、必要な特定のモデルエンドポイントのみにアクセスを許可された個別のサービスアカウントを使用します。すべてのアプリケーションで単一のフル権限資格情報を共有しないでください。

権限付与は定期的に監査し、長期間未使用の権限を削除します。また、勤務時間外のモデルダウンロードなど、異常な権限利用パターンを検知します。

アンチパターン：モデル関連の操作すべてに単一の管理者アカウントを使用すること、またはすべての開発者にモデル重みへのフル read-write 権限を付与すること。

Alibaba Cloud での実装：RAM は PAI リソースに対するきめ細かな権限制御をサポートします。送信元 IP や操作時間を制限する RAM の条件ポリシーと組み合わせることで、アクセス境界をさらに強化できます。Log Service (SLS) と ActionTrail は、すべてのモデルアクセス操作を記録し、異常行動分析を支援します。

根拠

エージェントはツール呼び出しを通じて外部システムと連携します。ツール権限が広すぎると、プロンプトインジェクションの成功により、その過剰権限が悪用されて深刻な被害につながります。エージェントにおいても、最小権限の原則が重要です。各ツールには、意図した機能に必要な最小権限のみを付与する必要があります。

実装

各ツールの権限境界ドキュメントを明確に定義し、許可される操作範囲とアクセス可能なデータを規定します。たとえばメール送信ツールは、社内メールシステム経由の送信のみに許可し、宛先は社内アドレス (外部アドレスではない) に限定し、1 通あたりの宛先数は 5 件を超えないようにします。

ツールごとに別々のサービスアカウント資格情報を使用し、ツール設計上の機能に正確に一致する権限を付与します。ツールにエンドユーザーの資格情報を使わせて操作を実行させることは、決して許可しないでください。これはユーザーの全権限を AI システムに露出させることと同義です。

実行時の権限チェックを実装します。ツール実行前に、現在の呼び出しパラメータが許容範囲内であることを検証します。たとえばファイル操作ツールは、書き込み前に対象パスが許可ディレクトリ内であることを確認し、データベース照会ツールは SQL 文が許可されたテーブルのみを対象としていることを検証します。

アンチパターン：管理者権限を持つ万能な資格情報をエージェントに付与し、すべてのツールでそれを共有すること。または、プロンプトでモデルに「特定の操作をするな」と伝えるだけで、実際の権限制限を強制しないこと。

Alibaba Cloud での実装：RAM を使用して、ツールまたは機能ごとに個別のサービスロールを作成し、アクセス可能なリソース範囲と操作タイプを正確に定義できます。Model Studio のエージェント設定は、ツールレベルの権限宣言をサポートします。

根拠

データ削除、金融取引の開始、アクセス権限の変更、外部通知の送信など、一度実行すると取り消せない、または影響が大きい操作があります。AI システムはこれらの操作を自律的に実行してはなりません。この種の操作には、手動承認または二次確認の仕組みを導入する必要があります。

実装

高影響操作の分類標準を定義します。例：一定額を超える金融取引、データ削除操作、権限変更操作、外部者への情報送信を伴う操作、システム設定変更操作。分類標準はセキュリティチームとビジネスチームが共同で策定します。

エージェントが高影響操作を実行しようとする場合は、実行フローを一時停止し、操作の詳細 (タイプ、パラメータ、コンテキスト) を承認キューへ送ります。指定された承認者は、所定の期限内に承認を完了する必要があります。承認されれば実行を継続し、拒否されれば操作を中止し、拒否理由を明確にしてエージェントへ返します。

承認タイムアウトポリシー：タイムアウト期間内に承認されない操作は、デフォルトで拒否してください (セキュリティ優先)。デフォルトで承認しないでください。タイムアウト後は、関係者へエスカレーション通知を送信します。

承認記録 (承認者、承認時刻、判断、操作コンテキスト) をすべて監査ログに記録し、トレーサビリティを確保します。

アンチパターン：手動チェックポイントなしで、エージェントにすべての操作を自律実行させること。または、承認プロセスが複雑すぎて業務効率を著しく損ない、ユーザーが仕組みを回避するよう促してしまう設計。

Alibaba Cloud での実装：DingTalk の承認フローまたはカスタムワークフローエンジンを使用して承認ゲートを実装できます。Model Studio のエージェントのツール呼び出しログは SLS に記録されるため、高影響操作を監視するリアルタイムアラートルールを設定できます。

根拠

エージェントの行動チェーンは、マルチターン会話、複数のツール呼び出し、複数の外部システムとの相互作用を含み、長く複雑になり得ます。セキュリティインシデント発生時には、根本原因を特定するために、エージェントの意思決定プロセスと実行経路を完全に再構築できる必要があります。そのため、完全な監査ログと行動リプレイ機能を提供する必要があります。

実装

エージェントの完全な行動チェーンをログに記録します：各ラウンドのユーザー入力、システムプロンプト、モデル出力、ツール呼び出しリクエスト (パラメータを含む)、ツール呼び出し結果、そしてシステムがユーザーへ返す最終コンテンツ。すべての記録にタイムスタンプを付与し、セッション ID とユーザー ID などの関連情報を含めます。

任意のトークンレベルログ：極めて高いセキュリティ要件のシナリオでは、モデルのストリーミング出力トークン列を記録し、生成プロセスの完全なリプレイを可能にします。

改ざん耐性ログ：監査ログは、一度書き込んだら (少なくとも保持期間中は) 変更または削除しないでください。書き込みアクセス制御とログ整合性検証の仕組みでこれを強制します。監査ログは、ビジネスシステムから分離された別のログストアへ書き込むことを推奨します。

行動リプレイ機能：完全なログに基づき、任意時点の会話コンテキストと意思決定根拠を復元できる必要があります。セキュリティインシデント調査では、アナリストがエージェントの行動プロセスを「リプレイ」し、インジェクション、操作、またはシステム不備があったかを判定できます。

ログ保持期間：中国のサイバーセキュリティ法の要件に従い、ログは少なくとも 6 か月保持する必要があります。金融など特定業界では、保持期間は業界規制に準拠する必要があります。

アンチパターン：最終出力のみをログに記録し、中間の推論プロセスやツール呼び出し詳細を記録しないこと。または、監査ログをビジネスシステムと同一ストレージに保存し、侵害後に他データとともにログも削除されるリスクを生じさせること。

Alibaba Cloud での実装：SLS は、大量ログの収集、保存、分析機能を提供し、イミュータブルログポリシーの設定をサポートします。ActionTrail は、すべてのクラウドリソース操作の監査イベントを記録します。Model Studio プラットフォームの呼び出しログは SLS に直接統合でき、完全な行動チェーンの記録と検索を実現します。CloudMonitor を使用して異常行動のリアルタイムアラートを設定します。