Google Cloud 生成AIセキュリティ対策：Model Armor
こんにちは。クラウドアーキテクトの山下です。
Next’25で発表されたセキュリティサービス群について触れていきたいと思います。今回のNextはAIエージェントに関わる登壇や発表が多く、Google Cloudのサービスにも多く組みこまれています。生成AIを安全に使う、ユーザが安心して使える、悪意のあるユーザからの攻撃を防ぐためにもリスクを把握し、是正する事が重要になります。
生成AIセキュリティといえば
まず、生成AIのセキュリティ観点としてどういったものがあるのかざっくりと触れたいと思います。生成AI/LLMセキュリティの指標としてOWASP Top10 for LLMが代表的です。
OWASPはWebアプリケーションのセキュリティリスクを調査/取りまとめして発表し注意喚起を行う非営利団体です。APIやWebアプリケーションとしてのリスクTop10を毎年リリースしています。
あくまで文字通りTop10なので、これだけをやれば全てのリスクが回避されるわけではありません。彼らが大事にしているのは優先度や重要性のカバレッジであり、網羅性ではないためです。生成AIは日々進歩しているのもあり、毎年のように内容や順位が更新されています。
2025年はRAGも外部APIへのアクションも行うのが当たり前となっており、生成AIがただの賢いチャットbotの域を超え、AIの外部に干渉しさらに推論する事で目標達成を目指すエージェントに進化しているのを受けた内容となっています。
それを踏まえてLLM08のベクトルDBに関わる項目や、LLM06のような生成AIに過剰な認証・認可を行える権限を付与しない取り組みが追加されています。
Model Armorとは
Model ArmorはGoogle CloudのSecurity Command Centerの機能です。アプリケーションから生成AIに対してプロンプトをリクエストする際の内容を検査して、内容に問題ないかをチェックし、かつ、生成AIから発せられた回答についても内容の精査を行うサービスです。
Next'25以前から提供されているものですが、AIエージェントを自分で作成する、増やす、人が作成したエージェントを利用する時代になることを踏まえて今回紹介しようと思います。
ある意味、生成AIとエンドユーザー間のプロキシとして存在し通信の内容を制御しています。その点ではL7ファイアウォール(WAF)やSASEなどのアプリケーションセキュリティ技術の延長とも言えます。これらと大きく異なるのはコンテンツ(≒内容) にフォーカスしている点です。
2025年現在Model Armorが提供している機能は大きく4点になります。これに加えてPDFなどプロンプトではないテキスト情報を含むファイルをスキャンする場合に以下の機能群を用いて攻撃をブロックできるPDFスキャンがあります。
| 機能 | OWASP指標 | 内容 |
|---|---|---|
| 責任あるAIの安全フィルタ | LLM01 | ヘイトスピーチ、誹謗中傷、猥褻な内容、違法性のある有害な情報をフィルタ |
| プロンプトインジェクションとジェイルブレイク検出 | LLM01/LLM02/LLM05 | プロンプトで生成AIを欺きフィルタを解除して、欲しいアウトプットを入手するのをブロック |
| 悪意のあるURL検出 | LLM01 | プロンプトまたはアウトプットにフィッシングやマルウェア配布が行われるURLが含まれる事を防ぐ |
| 機密データ保護(DLP) | LLM01/LLM02 | 個人情報や機密情報がプロンプトで誤送信されたりアウトプットに含まれてしまうのを防ぐ、さらにCloud DLPと組み合わせてこれらの情報の削除やマスキングを行える |
不適切な有害情報、機密情報、そしてこれらを生成AIから引き出すことと、生成AI組み込んで他者に間接的に攻撃を行う事を防ぐ事ができます。
このModel Armorはプロキシ的なサービスであるため、基盤もAIモデルもGoogle Cloudに限らず利用できるのが嬉しいところです。どことは言いませんが、他社製品では自社の生成AIサービス基盤にガードレールとしてこれらのプロンプト保護機能があるだけでマルチクラウド対応していません。生成AIモデルを使い分けたり、IaaSを特定のクラウドで固めているような方には嬉しいサービスです。
OWASPのリスクとModel Armorを当てはめる
まずは机上でOWASP Topで今回カバーできうるLLM01,02,05について対策をみていきたいと思います。
LLM01：プロンプトインジェクション
OWASPとして攻撃手法とリスクは以下のように定義されています。
| 攻撃手法 | 詳細 |
|---|---|
| 直接プロンプトインジェクション | ユーザー自身の入力がモデルの動作を直接変更する |
| 間接プロンプトインジェクション | LLMが読み込む外部ソース（ウェブサイトやファイルなど）に含まれるデータが、モデルの動作を意図せず変更する |
| マルチモーダルインジェクション | モーダリティを跨いでモデルのフィルタを突破しモデルの動作を変更する |
| 多言語インジェクション | 複数の言語や絵文字、Base64暗号化された文字列でプロンプトを送る |
| コードインジェクション | プロンプトにコードを含ませ実行する、またはコードを介してジェイルブレイクや不正な命令を出す |
| ペイロード分割 | NGワードを複数の文字列に分割してフィルタを突破し、分割された文字列を生成AIに再結合させて解釈させる |
| 敵対的文字列(サフィックス) | 意味不明な文字列をプロンプトで送り付け、生成AIの解釈を狂わす攻撃をする |
[発生しうるリスク]
- 機密情報の漏洩
- コンテンツの不正な操作による不正確または偏った出力の生成
- LLMが利用できる機能への不正なアクセス
- 接続されたシステムでの任意のコマンド実行
[対策]
前提として、、生成AIを完全にコントロールできず、曖昧な回答をしてしまったり不正確な回答をしてしまう性質が根底にあるので、OWASPはこれらの対策を以てしてもリスクを防ぎきれないとしています。
| 対策 | 詳細 |
|---|---|
| システムプロンプトでの制御 | システムプロンプトでモデルの役割や制限を明確に定義し、モデルの動作を制約する |
| アウトプット評価 | 期待される出力形式を定義し、出力の妥当性を検証し評価する機構を用意する |
| 入出力フィルタリング | 入出力のフィルタリングを実施し、非許可コンテンツを検出・処理する |
| 権限制御 | 権限制御を行い、モデルのアクセス権限を最小限に留める |
| 承認制の導入 | リスクの高い操作には人間の承認を必須とする |
| インプット分離 | 外部から取り込んだコンテンツは分離し、信頼できないものとして扱う |
| AIぺネトレーションテスト | 定期的に敵対的テストや攻撃シミュレーションを実施する |
Model Armorでできること
対策の入出力のフィルタリングがModel Armorの該当するところになります。そのため、他の対策は生成AIモデルを稼働させるSaaS/PaaS/IaaS側で別途必要になります。
では、入出力のフィルタリングでどれほどの攻撃を防げるのか当てはめてみます。ユーザからのインプットの多くを防げる反面、ペイロード分割やテキストではないコードや別のモーダル、縦読みなどの文字列操作を防ぎきれない可能性があることがわかります。
ModelArmorを入れる意義は大いにあるものの、攻撃者のいやらしいインジェクションを完全にカバーしきれない点は留意する必要があります。
| 手法 | Model Armorでカバーできるか | 備考 |
|---|---|---|
| 直接プロンプトインジェクション | ◯ | 入力に含まれる不正な単語を元にフィルタリング可能 |
| 間接プロンプトインジェクション | ◯ | 入力や外部の閲覧先に含まれる不正なURLや不適切なコンテンツをフィルタリング可能 |
| マルチモーダルインジェクション | △一部可能になる見込み | Next'25でマルチモーダル対応すると発表あり |
| 多言語インジェクション | △一部可能になる見込み | Next'25で多言語対応すると発表あり |
| コードインジェクション | × | 明記がないため恐らく不可 |
| ペイロード分割 | ？？要検証 | 分割した文字列も対応するのか不明・・・ |
| 敵対的文字列(サフィックス) | × | 明記がないため恐らく不可 |
LLM02：機密情報漏えい
情報漏えいなので攻撃ではなく起こり得るリスクになります。OWASPとして機密情報を以下のように定義しています。これらが生成AIのアウトプットを通じて出力、漏洩してしまうリスクを指しています。
[機密情報にあたるもの]
- 個人識別情報（PII）
- 財務詳細
- 健康記録
- 企業機密
- セキュリティ認証情報
- 法的文書
- モデルに関する情報（独自の学習方法やソースコードなど）
そもそも何故機密情報をインプットしているのか？というところが一番気になる点かと思います。機密情報が生成AIに含まれてしまう原因としては以下が挙げられます。
| 原因 | 詳細 |
|---|---|
| ユーザプロンプトからの学習 | ユーザから送られたプロンプトに機密情報が含まれているパターンです。意図したものか悪意のあるものかに寄らず、送られた機密情報を学んでしまうパターンです。 |
| ユーザプロンプトの保管 | 生成AIモデルの提供事業者によってはユーザから送られたプロンプトは一定期間保存されるケースがあります。その保管データにアクセスされてしまうパターンです。 |
| 学習したデータに内包 | そもそもモデルのトレーニング過程で学習データに機密情報が含まれてしまうパターンです。多くのLLMがインターネット上のデータを学習しており、学習に関係する人でないと何を学んだのかはブラックボックスです。また、自分でファインチューニングする際に紛れてしまうパターンもあります。 |
| RAGの不適切処理 | RAGに機密情報を格納して生成AIがRAGを介したアウトプットを行う際にその機密情報が漏洩してしまうパターンです。 |
[対策]
LLM02は攻撃ではなく生成AIのアウトプット”結果”なので、そのアウトプットを引き起こさないための対策が様々な観点で示されています。
| 対策 | 詳細 |
|---|---|
| データサニタイゼーションの実装 | 学習データにユーザーデータが入らないようにスクラビングやマスキングを行う |
| 堅牢な入力検証 | 有害または機密性の高いデータ入力を検出・フィルタリングする |
| 厳格なアクセス制御 | 最小権限の原則に基づき、データへのアクセスを制限する |
| データソースの制限 | LLMがアクセスできる外部ソースを制限し、安全に管理する |
| 連合学習や差分プライバシーの利用 | データを分散させたり、データ/出力にノイズを加えたりして、プライバシー保護を図る |
| ユーザー教育と透明性 | 安全なLLMの使用法についてユーザーを教育し、データ使用ポリシーを明確にする（オプトアウトの提供など） |
| 安全なシステム構成 | システムの初期設定を隠蔽したり、セキュリティ設定ミスのベストプラクティス（例: OWASP API8:2023）に従う |
| 高度な技術の適用 | ホモモルフィック暗号化や、トークン化・匿名化によって機密情報を保護・処理する |
| システムプロンプトでの制限 | モデルが返すデータタイプに制限を加える（ただし、プロンプトインジェクションなどによりバイパスされる可能性あり） |
Model Armorでできること
対策の堅牢な入力検証と高度な技術の適用がModel Armorの該当するところになります。他の対策は生成AIモデルを稼働させるSaaS/PaaS/IaaS側で別途必要になります。Model Armorではインプットのプロンプトだけではなく生成AIからのアウトプットもフィルタにかけ、サニタイズ(破棄、マスキング)する事ができます。
デフォルトで用意されているプロンプト内の機密情報をチェックするテンプレートは以下の6種になります。 日本だけかつGoogleCloudに限定しない場合はクレジットカード番号のみと有用なりますが、これら以外の機密情報パターンを定義することも可能です。
-
CREDIT_CARD_NUMBER: クレジット カード番号は 12 〜 19 桁です。世界各地での決済取引に使用されます。 -
US_SOCIAL_SECURITY_NUMBER: 米国社会保障番号（SSN）は、米国市民、永住者、一時居住者に発行される 9 桁の番号です。この検出機能は、いずれかの数字グループがすべてゼロの番号（つまり 000-##-####、###-00-####、###-##-0000）、最初の数字グループが 666 の番号、9 で始まる番号には一致しません。 -
FINANCIAL_ACCOUNT_NUMBER: 特定の金融口座を指す番号（銀行口座番号や退職金口座番号など）。 -
US_INDIVIDUAL_TAXPAYER_IDENTIFICATION_NUMBER: 米国の個人納税者番号（ITIN）は、国税庁（IRS）によって発行される納税識別番号（TIN）の一種です。ITIN は、社会保障番号（Social Security Number: SSN）を取得できない特定の非居住者および居住外国人、その配偶者と扶養家族にのみ利用可能な税処理番号です。 -
GCP_CREDENTIALS: Google Cloud サービス アカウントの認証情報Google API クライアント ライブラリとサービス アカウントでの認証のために使用できる認証情報です。 -
GCP_API_KEY: Google Cloud API キー非公開のユーザーデータにアクセスする必要のない Google Cloud API を呼び出すときに使用される、暗号化された文字列です。
機密情報のサニタイズやインプット情報やアウトプット情報に機密情報が含まれるケースをカバーできるため、LLM01の対策で防ぎきれなくともアウトプットで不正な情報を引き出すことは防げます。オプトアウトやシステムプロンプトに関わる部分まではカバーできないため、モデル提供者側に情報が届かないようCloudArmorでのフィルタカバレッジを上げることが大事になります。
LLM05：不適切なアウトプット処理
一見するとLLM02と似た内容ですが、他のコンポーネントやシステムに渡す前に、十分な検証、サニタイズ、または処理が行われていない状態を指しています。つまり生成AIのアウトプットではなくシステム間連携に重きを置いた観点になります。そのため、人間ではなくシステムで生成AIのアウトプットが扱われる際のリスクが対象になります。
[発生しうるリスク]
- LLMの出力がシステムシェル関数（exec や eval など）に直接入力され、リモートコード実行を引き起こす
- LLMがJavaScriptやMarkdownを生成し、それがユーザーのブラウザで解釈されてXSSを引き起こす
- LLMが生成したSQLクエリが適切なパラメータ化なしに実行され、SQLインジェクションにつながる
- LLMの出力がファイルパス構築に使われ、パス・トラバーサル脆弱性を引き起こす
- LLMが生成したコンテンツがメールテンプレートで適切にエスケープされずに使われ、フィッシング攻撃につながる
[対策]
LLM05は攻撃ではなく生成AIのアウトプット”結果”なので、そのアウトプットを引き起こさない、もしくはアウトプットがあったとしても制御するための対策が様々な観点で示されています。
| 対策 | 詳細 |
|---|---|
| 適切な入力検証 | モデルを他のユーザーと同様に扱い、ゼロトラストのアプローチを採用し、モデルからの応答に対してバックエンド関数への適切な入力検証を適用する |
| 出力のエンコード | LLMの出力をユーザーに戻す際にエンコードを行い、JavaScriptやMarkdownによる意図しないコード実行を軽減する |
| 文脈に応じた出力のエンコード | LLMの出力が使用されるコンテキストに基づいた文脈に応じた出力エンコーディングを実装する（例：ウェブコンテンツにはHTMLエンコーディング、データベースクエリにはSQLエスケープ） |
| データベースの操作制限 | LLMの出力を伴うすべてのデータベース操作に対して、パラメータ化クエリまたはプリペアドステートメントを使用する |
| コンテンツセキュリティポリシー | 厳格な CSP (Content Security Policies) を実施し、LLMが生成したコンテンツによるXSS攻撃のリスクを軽減する |
| ロギング | ロギングおよび監視システムを実装し、悪用試行を示す可能性のあるLLM出力の異常なパターンを検出する |
| コードレビュー | ソフトウェア開発においてコード生成AIを使用する場合は、徹底的なコードレビューと提案されたパッケージの検証が不可欠です |
Model Armorでできること
Model Armorでは適切な入力検証で不正なアウトプットにつながるプロンプトをブロックすることはできます。例えば、DDoS攻撃のコードを生成してやマルウェアのコードを生成してなどは防ぐことはできます。しかし、巧妙なプロンプトや遠回しに関連性が一見ないコードを生成して連携システムに攻撃することを防ぎ切ることはできません。
SQLインジェクションやXSSなどWAFで一般的に防げるものでもプロンプトによって間接的に実施される事で防ぐことができません。生成AIのアウトプットを取り扱うアプリケーションやロジック側でこの制御(=Handling)を行わないといけません。
Model Armorはあくまでプロンプトでこうした攻撃やリスクを発生させないようフィルタできる補助として捉えるべきです。
まとめ
マルチAIエージェント時代に備えて生成AIのリスクとなるOWASP Top10 for LLMとModel Armorでの対策とカバレッジについてまずは机上で触れてきました。機密情報の漏洩や不適切なインプットをフィルタできる点で非常に有用です。特に人間のユーザ相手での不正操作は多く防げます。
一方で、LLM05のような生成AIが生成したSQL文やコード、IDが攻撃に繋がってしまったり、プロンプトで間接的かつ巧妙に文字列操作をおこなってくる悪意を持ったユーザやシステム、マルウェアに対してはカバーできません。Model Armorを入れたから安心とは考えず、生成AIを提供しているSaaS/PaaS/IaaS事業者のプラットフォームでのセキュリティ対策とアプリケーション側でのセキュリティ対策が必要となります。
Discussion