Go to Qiita Advent Calendar Top
LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@orangist

【検討】AIネイティブ時代のクラウドセキュリティを考えてみた（AWS, Google Cloud, Azure）

Posted at

AIネイティブ時代のクラウドセキュリティを考えてみた（AWS, Google Cloud, Azure）

対象読者

  • AIエージェントをクラウドで安全に使いたい方
  • AWS, Google Cloud, Azure の公式機能（Guardrails・Model Armor・Prompt Shields など）を横並びで把握したい人
  • RAGや外部APIを呼ぶエージェント運用のリスクと対策を整理したい人

TL;DR

  • AIネイティブは、“生成AIを前提”に対話→計画→ツール実行まで自動化する設計。安全に使うには入出力の安全フィルタ＋接地（グラウンディング）＋権限/ネットワーク/監査の多層防御が必須。
  • AWSは Guardrails を入出力に適用でき、ApplyGuardrail APIでモデル非依存に前後どこへでも挟めるのが強み（有害カテゴリ・PII・プロンプト攻撃・接地などを一括提供）。
  • Google Cloudは Safety filters＋Model Armor で プロンプトとレスポンスの双方をスクリーニングし、Google 検索によるグラウンディングで事実整合性を強化できます。
  • Azureは Content Safety と Prompt Shields で ユーザー由来/ドキュメント由来の攻撃を検出・ブロックし、**Groundedness 検出（Correction含む）**で“根拠外れ”の出力を抑制します。

0. まず用語をサクッとおさらい

  • 生成AI（LLM）：大量データから学んだ確率的モデル。質問応答・要約・コード生成などをこなします。
  • AIエージェント：LLMが外部ツールやAPI、検索・RAGを使い分けて一連のタスクを自律的に実行する形。Googleは「Agent Engine」/「Agent Builder」と呼びます。(Google Cloud)
  • プロンプトインジェクション：ユーザー入力や参照ドキュメントに指示を紛れ込ませ、本来の方針を上書きさせる攻撃（間接＝ドキュメント経由も）。MicrosoftのPrompt Shieldsは「User Prompt攻撃」と「Document攻撃」を区別して説明しています。(Microsoft Learn)
  • ジェイルブレイク：安全ポリシーを回避する書き方で禁止出力を引き出す手口。AzureはこれをPrompt Shieldsの対象に含めています。(Microsoft Learn)
  • グラウンディング（接地）：出力を根拠（検索/社内データ）に沿わせる仕組み。GoogleはGoogle 検索でのグラウンディングを提供、AzureはGroundedness検出/Correctionで根拠外れを検知・補正します。(Google Cloud Documentation)

1. セキュリティ課題：AIエージェントになって何が増えた？

AIの一般的な課題（有害出力、機微情報流出、幻覚、コスト暴走）に加えて、エージェント化で次が効いてきます。

  • ツール誤用リスク：エージェントが外部APIを自律実行するため、権限最小化と実行前承認が要。AWSはアクションごとにユーザー同意を求める設定を提供。

    “Request confirmation from end users before an action group function is called.”（抜粋） (AWS ドキュメント)

  • 間接プロンプトインジェクション：RAGのコーパス側に悪性指示が混入。前段のフィルタに加え、**コーパス衛生（DLP/検査）**が重要。(Google Cloud)

  • 来歴・真正性：生成物の透明性を示す要件が増加。GoogleはSynthID、Microsoftは**Content Credentials（C2PA）**を案内。(Google AI for Developers)

  • 評価/可観測性：安全・品質の継続評価とメトリクス監視が必須（後述）。GoogleはModel Observability、AWSはGuardrailsのCloudWatchメトリクス、AzureはEvaluationを提供。(Google Cloud Documentation)

2. 「どこで何が効く？」— エージェント実行の安全レイヤ

  • IN/OUT（入出力ゲート）

    • AWS: Guardrails（有害カテゴリ/拒否トピック/単語/PII/プロンプト攻撃/接地/推論チェック）。ApplyGuardrail APIでモデルと独立に適用可能。(AWS ドキュメント)
    • Google Cloud: Safety filters（カテゴリごとに閾値）＋ Model Armor（プロンプト/レスポンスをスクリーニング）。(Google Cloud)
    • Azure: Content Safety＋ Prompt Shields（User Prompt/Document攻撃を区別）。(Microsoft Learn)

  • GROUND（グラウンディング）

  • APPROVE（人手承認）

    • AWS: エージェントのアクショングループにユーザー確認を設定可能。(AWS ドキュメント)

  • NET（ネットワーク境界）

    • AWS: PrivateLinkでcontrol/runtime/agentsの各エンドポイントにVPC内プライベート接続。(AWS ドキュメント)
    • Google: VPC Service ControlsでVertex AIをサービス境界に閉じてデータ外部流出を抑止。(Google Cloud Documentation)
    • Azure: VNet＋Private EndpointでAzure OpenAI/Agent基盤を閉域化。(Microsoft Learn)

  • HYGIENE（コーパス衛生）

    • Sensitive Data Protection（旧Cloud DLP） / Amazon Macie / Microsoft Purview。(Google Cloud)

  • OBS/COST（監視/コスト）

3. クラウド各社の方針まとめ

3-1. AWS（Amazon Bedrock / Agents / Guardrails）

“Guardrails can be used for both prompts and responses… and can also be used directly from the ApplyGuardrail API.”（抜粋） (AWS ドキュメント)

“Request confirmation from end users before an action group function is called.”（抜粋） (AWS ドキュメント)

“Create a private connection between your VPC and Amazon Bedrock using AWS PrivateLink.”（抜粋） (AWS ドキュメント)

  • 補足：Guardrailsは有害カテゴリ/拒否トピック/単語/PII/プロンプト攻撃、さらにコンテキストグラウンディング/自動推論チェックまで含む多層の保護を提供。(AWS ドキュメント)
  • 観測：CloudWatchメトリクスでガードレール介入等を可視化。(AWS ドキュメント)

3-2. Google Cloud（Vertex AI / Gemini / Agent Builder & Engine / Model Armor）

“Vertex AI safety filters allow you to configure safety thresholds for different harm categories.”（抜粋） (Google Cloud)

“Model Armor… configure how Model Armor screens prompts and responses and define your security filter configuration.”（抜粋） (Google Cloud)

“Grounding with Google Search” is available for supported models.（節タイトル） (Google Cloud Documentation)

“Vertex AI Model Observability provides a prebuilt dashboard to view model behavior, health, and performance.”（抜粋） (Google Cloud Documentation)

“Google won’t use your data to train or fine-tune any AI/ML models without your permission.”（抜粋） (Google Cloud)

  • 補足：Agent Builder / Agent Engineは本番運用のためのランタイム・評価・セッション・メモリ等を提供。(Google Cloud)
  • 境界：VPC Service ControlsでVertex AIのデータ流出リスク低減。(Google Cloud Documentation)

3-3. Microsoft Azure（Azure AI Foundry / OpenAI / Content Safety / Prompt Shields）

“Groundedness detection helps ensure LLM responses are based on your provided source material, reducing non-factual outputs.”（抜粋） (Microsoft Learn)

“Prompt Shields… detect and block adversarial user prompts and document attacks.”（抜粋） (Microsoft Learn)

“Azure AI Foundry Agent Service connects models, tools, frameworks… enforces content safety, identity, network, and monitoring in one runtime.”（抜粋） (Microsoft Learn)

“Build a security boundary for Azure OpenAI with Virtual Network + Private Endpoint.”（抜粋） (Microsoft Learn)

“During detection, inputs are not stored and not used to train Content Safety models.”（抜粋） (Microsoft Learn)

4. どう使う？— 最小構成の「安全プリセット」

4-1. AWS（Bedrock中心）

  1. VPC内に閉じる：PrivateLinkでcontrol/runtime/agentsの各エンドポイントを作成。(AWS ドキュメント)
  2. 入出力にGuardrails：ApplyGuardrailで入力（プロンプト攻撃/PII）→出力の順に適用。(AWS ドキュメント)
  3. 高リスクは人手承認：アクショングループのユーザー確認を有効化。(AWS ドキュメント)
  4. コーパス衛生：Amazon MacieでS3の機微情報を継続検査。(AWS ドキュメント)
  5. 可観測性：CloudWatchメトリクス（Guardrails）＋CloudTrailで追跡。(AWS ドキュメント)
  6. コスト：AWS Budgetsで予算/閾値通知。(Amazon Web Services, Inc.)

4-2. Google Cloud（Vertex AI中心）

  1. サービス境界：VPC Service ControlsでVertex AIを保護。(Google Cloud Documentation)
  2. 入出力の安全化：Safety filters（カテゴリのしきい値）＋Model Armor（プロンプト/レスポンスのスクリーニング）。(Google Cloud)
  3. 接地：Google 検索グラウンディングをオン。(Google Cloud Documentation)
  4. コーパス衛生：Sensitive Data Protection（旧Cloud DLP）で検査/匿名化。(Google Cloud)
  5. 可観測性：Model Observabilityで動作/健全性をダッシュボード監視。(Google Cloud Documentation)
  6. コスト：Cloud BillingのBudget/Alert。(Google Cloud)

4-3. Azure（Azure AI Foundry中心）

  1. 閉域化：VNet + Private EndpointでAzure OpenAI/Agentの通信を制御。(Microsoft Learn)
  2. 入出力の安全化：Content Safety＋Prompt Shields（User/Document攻撃）。(Microsoft Learn)
  3. 接地：Groundedness検出＋Correction（プレビュー）。(Microsoft Learn)
  4. エージェント実行：Agent Serviceでツール呼出・安全/ID/監視を一体ランタイムで。(Microsoft Learn)
  5. コーパス衛生：Microsoft Purviewで検出/分類/保護。(Microsoft Learn)
  6. 評価/運用：Evaluation SDK/Studioで品質/安全の回帰テスト。(Microsoft Learn)
  7. コスト：Cost Managementのアラート。(Microsoft Learn)

5. 各社の“似ているところ”と“違いが見えるところ”

類似点

  • 入出力に安全フィルタ（AWS Guardrails / GC Safety filters+Model Armor / Azure Content Safety+Prompt Shields）。プロンプトインジェクション/ジェイルブレイクに3社とも公式で対応。(AWS ドキュメント)
  • 接地の仕組み（Azure Groundedness、Google Search Grounding、AWS Context Grounding）。(Microsoft Learn)
  • ネットワークの閉域化（PrivateLink / VPC-SC / VNet+PE）。(AWS ドキュメント)
  • データ利用のコントロール（各社、学習目的での無断利用はしない旨やコントロールを明記）。(Google Cloud)

相違点

  • AWS：Guardrailsがカテゴリ/拒否トピック/単語/PII/攻撃/接地/推論チェックまで一つに凝縮。さらにApplyGuardrailでモデル非依存に差し込めるのが便利。(AWS ドキュメント)
  • Google Cloud：Model Armorがプロンプトとレスポンス双方をセキュリティコマンドセンターと統合してスクリーニング。Search GroundingもGoogleらしい強み。(Google Cloud)
  • Azure：Prompt Shieldsがユーザー由来/ドキュメント由来を明示区別。Groundedness Correctionで補正まで踏み込み、Agent Serviceで安全/ID/監視を一体化。(Microsoft Learn)

6. RAGと“コーパス衛生”はなぜ重要なのか？

間接インジェクションは社内文書やWebソースに悪性指示を混ぜる攻撃。前段のフィルタだけでは漏れる可能性があるため、コーパスそのものの衛生管理が鍵です。（基本的には100%は難しいので、多段防御が基本）

  • Google Cloud：**Sensitive Data Protection（旧Cloud DLP）**で検査・匿名化・リスク分析。(Google Cloud)
  • AWS：Amazon MacieでS3の機微データを継続的に発見。(AWS ドキュメント)
  • Azure：Purview Information Protectionで検出/分類/保護を横断適用。(Microsoft Learn)

7. 監査・評価・ガバナンスの型

  • 監査/可観測性

    • AWS：Guardrails CloudWatchメトリクス。(AWS ドキュメント)
    • Google Cloud：Model Observabilityダッシュボード。(Google Cloud Documentation)
    • Azure：Evaluation SDK/Studioで安全・品質・エージェント特有メトリクス（ツール精度/タスク遵守など）を評価。(Microsoft Learn)

  • フレームワーク

    • OWASP Top 10 for LLM Applications（LLM特有のリスク一覧）。(OWASP)
    • NIST AI RMF（リスクベース運用の基礎）。(NIST)
    • ISO/IEC 42001（AIマネジメントシステムの国際規格）。(ISO)

  • コンテンツ真正性/来歴

  • コスト/濫用制御

    • AWS Budgets／Google Cloud Budgets／Azure Cost Managementアラートで暴走検知の基盤に。(Amazon Web Services, Inc.)

8. まとめ：まずはこの“安全プリセット”から

  1. 入出力の安全ゲート（Guardrails / Safety+Model Armor / Content Safety+Prompt Shields）
  2. 接地の徹底（Search Grounding / Groundedness）
  3. 高リスク操作は承認（Bedrockのユーザー確認など）
  4. ネットワークを閉じる（PrivateLink / VPC-SC / VNet+PE）
  5. コーパス衛生（SDP/Macie/Purview）
  6. 可観測性・評価（CloudWatch/Observability/Evaluation）
  7. 予算アラート（Budgets/Cost Management）

最後に：どのクラウドも“安全に使ってもらうための手当て”を急速に整備しています。
公式いわく、

  • AWS：「プロンプトとレスポンスの両方にGuardrails、ApplyGuardrailでモデル非依存」（要旨） (AWS ドキュメント)
  • Google：「プロンプト/レスポンスをModel Armorでスクリーニング、検索グラウンディングを提供」（要旨） (Google Cloud)
  • Azure：「Prompt ShieldsでUser/Document攻撃に対応、Groundedness CorrectionとAgent Serviceで実運用へ」（要旨） (Microsoft Learn)

参考リンク

  • AWS：Guardrails / ApplyGuardrail、Agentsのユーザー確認、PrivateLink、CloudWatchメトリクス、セキュリティ考慮点 (AWS ドキュメント)
  • Google Cloud：Safety filters、Model Armor、Search Grounding、Model Observability、Zero Data Retention、Agent Builder/Engine、VPC-SC (Google Cloud)
  • Azure：Content Safety、Prompt Shields、Groundedness/Correction、Agent Service、VNet+Private Endpoint、Evaluation、データ・プライバシー (Microsoft Learn)
  • データ保護/真正性/標準：Sensitive Data Protection、Macie、Purview、SynthID、Content Credentials、OWASP LLM Top10、NIST AI RMF、ISO/IEC 42001 (Google Cloud)
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?