AI特有の攻撃面
AIを組み込んだ仕組みには、従来のシステムにはなかった攻撃面が加わります。本章ではそれを扱います。従来のセキュリティ対策(認証、通信の暗号化、脆弱性管理)が不要になるわけではなく、その上に追加される領域です。
本章の構成は、脅威の説明と、それに対する設計上の対処です。第18章で概観したものを、対策の水準まで掘ります。
プロンプトインジェクション
AIへの指示を悪用する攻撃です。2つの型を明確に区別します。対処が違うためです。
直接型
利用者自身が、AIに与えられた制限を外そうとする指示を与えるものです。「これまでの指示を無視して」という形の入力が典型です。
業務システムでの影響は、利用者の範囲によって変わります。
- 社内の限定された利用者のみ ― 影響は限定的です。ただしAIが持つ権限の範囲を超えることはできないため、権限設計が防御になります。
- 社外の利用者が使う ― 対処が必要です。システムプロンプトの内容が引き出される、想定外の用途に使われる、他の利用者の情報が漏れるといった影響が考えられます。
対処:
- AIが参照できる情報を、その利用者が見てよいものに限定する(権限設計)
- 出力に含めてはいけない情報の検査を、出力側で行う
- システムプロンプトに機密情報を書かない(引き出される前提で設計する)
- 1人あたりの利用回数に上限を設ける(試行の繰り返しを制限する)
3番目が実務上重要です。システムプロンプトは秘密として扱えません。内部の指示が引き出される前提で、そこに機密情報を書かない設計にします。
間接型
AIが読み込むデータの中に指示文が仕込まれている形です。業務上のリスクとしては、こちらが本題です。
攻撃が成立する経路を挙げます。
- 問い合わせメールの本文に指示文が埋め込まれている(背景色と同じ文字色、フォントサイズ0など、人には見えない形も可能です)
- ウェブページを読み込ませる仕組みで、ページ内に指示文がある
- 共有フォルダの文書、添付ファイル、画像内の文字
- 外部から取り込んだデータ(CSVの項目、システム間連携で受け取った値)
危険性が高いのは、AIが読み込みだけでなく操作を実行できる場合です。エージェント型の仕組み(第2章)では、読み込んだ指示に従って外部への送信、ファイルの操作、システムの更新が実行される可能性があります。
間接型への対処 ― 権限が被害の上限を決める
入力の検証だけでは防ぎきれません。指示文は自然言語であり、正当な文章と機械的に区別することが難しいためです。したがって権限設計が主要な防御になります。
| 層 | 対処 | 効果 |
|---|---|---|
| 権限 | 読み取りのみで足りる処理に書き込み・送信・削除の権限を与えない | 被害の上限を決める。最も重要 |
| 承認 | 送信・削除・公開・更新の前に人が承認する | 取り返しのつかない操作を止める |
| 分離 | 外部データを扱う処理と、社内データにアクセスする処理を分ける | 横断的な情報の持ち出しを防ぐ |
| 入力 | 外部データを「データ」として扱う指示、不可視文字の除去 | 成立確率を下げる(完全には防げない) |
| 出力 | 機密情報のパターン検査、送信先の許可リスト | 持ち出しを検知・阻止する |
| 記録 | 入力・出力・実行した操作のログ | 事後の検知と原因究明 |
この表の1行目と2行目が対策の中心です。「外部データを読み込む」かつ「操作を実行できる」の両方が成立している仕組みは、それだけで高リスクとして扱ってください(第16章の判定基準)。
データポイズニング・モデル汚染
学習に使うデータに悪意のあるデータを混入させ、モデルの振る舞いを変える攻撃です。
実務で関係する場面
基盤モデルの事前学習に対する攻撃は、利用者側で対処できる範囲を超えます。実務で関係するのは次の場面です。
- ファインチューニング用のデータ ― 外部から収集したデータを学習に使う場合。
- RAGの参照文書 ― 参照する文書に誤った情報や指示文が混入する場合。これは間接型プロンプトインジェクションと重なります。
- 利用者の入力を学習に使う仕組み ― フィードバックを自動的に反映する設計では、意図的に誤った評価を与える攻撃が成立し得ます。
- 継続的な再学習 ― 業務データを定期的に学習に反映する構成。
対処
- 学習・参照に使うデータの出所を管理する ― 誰が追加できるかを制限します。
- 追加時に確認の工程を置く ― 自動的に学習・参照対象に加える設計を避けます。
- 検証セットで挙動の変化を検知する ― 学習・データ追加の前後で結果を比較します(第14章)。
- 参照文書の変更履歴を残す ― 何がいつ追加されたかを追えるようにします。
3番目が、この種の攻撃に対する最も実用的な検知手段です。回帰テストは品質管理の道具ですが、同時にセキュリティ上の検知手段でもあります。
サプライチェーンリスク
外部から取り込む要素を経由した脅威です。AI関連では取り込む要素が増えるため、この観点の重みが増しています。
取り込む要素と確認点
| 要素 | リスク | 確認点 |
|---|---|---|
| 公開されているモデル | 出所不明のモデルに悪意のある振る舞いが含まれる可能性 | 配布元の信頼性、ライセンス、改変の有無(第3章) |
| ライブラリ・パッケージ | 依存関係を経由した脆弱性・不正コード | 依存の一覧管理、既知の脆弱性の確認、更新の運用 |
| 外部の連携先 | 接続先の乗っ取り、応答の改変 | 接続の認証、応答の検証 |
| 再委託先の事業者 | 上流でのデータの取り扱い | 再委託先の開示(第17章) |
| プロンプトのテンプレート | 外部から取得したテンプレートに不適切な指示が含まれる | 内容の確認、自社での管理(第13章) |
| 拡張機能・連携ツール | 付与された権限を経由した情報の取得 | 権限の一覧の把握、必要最小限への制限 |
最後の行が、実務では見落とされやすい領域です。AIに接続する拡張機能や連携ツールに付与した権限は、そのまま攻撃面になります。付与した権限の一覧を定期的に確認してください(第16章の棚卸し)。
モデル盗用・情報抽出
自社で構築したモデルや、モデルに与えた情報を外部に取得される脅威です。
- 大量の問い合わせによる振る舞いの再現 ― 入出力の組を大量に収集し、同等の振る舞いをする別のモデルを作る手法が知られています。外部に公開するAI機能では、利用回数の制限が対処になります。
- 学習データの推定 ― 特定の入力に対する応答から、学習に使われたデータの内容を推定する手法が研究されています。機密情報をファインチューニングで学習させる設計では、この観点の検討が必要です。
- システムプロンプトの取得 ― 前述のとおり、秘密として扱えません。
- RAGの参照文書の抽出 ― 質問を工夫することで、参照している文書の内容を引き出せる場合があります。権限設計で、その利用者が見てよい文書のみを参照対象にすることが対処です。
実務的な要点は、機密情報をモデルに学習させるより、権限管理された参照(RAG)で扱うほうが制御しやすいということです。学習させた情報は取り出しの制御が難しく、削除も容易ではありません。
自作ツールの脆弱性
第12章で扱った内容を、セキュリティの観点から整理します。自作ツールで実際に見つかる不備は、種類が限られています。
| 不備 | 実際に起きること | 対処 |
|---|---|---|
| 認証がない | URLを知る誰でも利用・閲覧できる | 社内向けでも認証を入れる |
| 権限の確認がない | 他部署・他人のデータが見える | データ取得時に利用者の権限を確認する |
| 入力の検証がない | 想定外の値で誤動作・情報の露出 | 入力の形式と範囲を検証する |
| 秘密情報の埋め込み | APIキーがコードや設定ファイルに残り、共有先に渡る | 環境変数などで外部化し、共有対象から除外する |
| ログへの機密情報の記録 | 個人情報がログに蓄積し、閲覧権限が広い | 記録項目を選び、保持期間と権限を設定する |
| エラーの詳細の表示 | 内部構造や接続先が利用者に見える | 利用者向けと記録用のメッセージを分ける |
| 外部への送信範囲 | 文書全体を送る実装で、不要な機密情報が外部に出る | 送信項目を必要最小限に絞る |
| 更新されない依存 | 既知の脆弱性が残る | 依存の一覧と更新の運用を決める |
この8項目は、公開前の確認リストとして使えます(第27章にも収録)。とくに4番目(APIキーの埋め込み)は、コードを共有した時点で外部に渡るため、影響が広範になります。
放置される構図
技術的な不備そのものより、組織的な問題が事故につながることがあります。
- 指摘を受けても、修正の担当者が決まっていない(第12章の引き継ぎ)
- そのツールが業務に組み込まれており、止められない
- 作った担当者が異動し、修正できる人がいない
- 把握されていないため、そもそも点検の対象に入っていない
対処は技術ではなく運用です。把握(棚卸し)と、担当者の明示。この2つがないと、指摘は修正につながりません。
エージェント型の仕組みに対する設計原則
本章の内容を、エージェント型の仕組みに集約して整理します。自律的に動く仕組みは、セキュリティ上の設計が特に重要です。
- 権限は必要最小限にする ― 道具の一覧がそのまま権限の一覧です(第2章)。読み取りで足りる処理に書き込み・送信・削除を与えない。
- 取り返しのつかない操作は人が承認する ― 送信、削除、公開、外部システムの更新、支払い。
- 外部データを扱う処理と社内データにアクセスする処理を分離する ― 両方の権限を同時に持たせない。
- 操作先を許可リストで限定する ― 送信先のドメイン、アクセス可能なパス、実行可能なコマンド。
- 実行した操作を記録する ― 何を読み、何を実行したかのログ。
- 1回の実行での操作回数・費用に上限を設ける ― 暴走時の影響を限定します。
- 権限の変更を承認の対象にする ― 道具の追加は、実質的にアクセス権限の付与です(第16章)。
3番目が最も効きます。「外部から来たデータを読む」ことと「社内の機密情報にアクセスする」ことを同じ仕組みに担わせないだけで、間接型プロンプトインジェクションによる情報の持ち出しは構造的に困難になります。
画面やブラウザを人と同じように操作させる形態では、上の1番目の原則がそのままでは成立しません。権限は「渡した道具の一覧」ではなく、その端末やブラウザが既にログインしている先すべてになります。業務用のログイン状態が残った環境でこの形態を動かすと、意図していない範囲まで操作できる状態になります。専用の利用者と専用の環境で動かし、業務用のログイン状態と混ぜないでください。
二年目の三月五日、朝凪精機の情報システム課の森は、CS課の回答案づくりにつないだ社内文書検索の対象フォルダを一つずつ開いていました。前日、問い合わせに紛れた指示文で社内手順書の一節が顧客への回答に入ったと分かったためです。手順書のフォルダの下に「受領資料」という階層があり、CS課が顧客から受け取った図面や資料が置かれていました。フォルダ単位で指定した検索対象に、外から来た文書がそのまま入っていたのです。ここに指示文が紛れれば、回答に影響し得ます。調べると、この仕組みにはメールを送る権限がなく、外への出口は人が確認して送る回答だけという設計でした。翌日、受領資料の置き場所を検索対象から分けると決まりました。送信の権限を持たせていなかったことと、領域を分離したことの両方が対処になっています。
この場面は網羅物語之巻 第14章「小さな事故」に出てきます。
セキュリティ確認の最小構成
AI関連の仕組みについて、確認すべき項目をまとめます。
- 外部から来たデータを処理するか(該当すれば間接型の対象)
- AIに与えている操作権限は何か(読み取り・書き込み・送信・削除・実行)
- 取り返しのつかない操作に人の承認があるか
- 外部データの処理と社内データへのアクセスが分離されているか
- 参照・検索の対象が、利用者の権限に応じて絞られているか
- システムプロンプトに機密情報が書かれていないか
- APIキーなどの秘密情報がコードに埋め込まれていないか
- ログに機密情報が記録されていないか。保持期間と権限が設定されているか
- 依存しているライブラリ・モデル・拡張機能の一覧があるか
- 回帰テスト(検証セット)が定期実行されているか
10項目のうち、1番目と2番目の答えが両方「はい(外部データを処理し、操作権限がある)」の場合、その仕組みは高リスクです。3番目と4番目の対処を優先してください。