ゼロトラスト原則でAIセキュリティを強化しよう

多くのCSO（最高情報セキュリティ責任者）は、自社のAIエージェントがユーザーに爆弾の作り方を教えたり、存在しない判例を引用したりすることを心配している。しかし、今週ラスベガスで開催されたBlack Hatセキュリティカンファレンスで、あるセキュリティ専門家は、それは心配事の中でも最も小さい部類だと述べた。エンタープライズデータに接続する大規模言語モデル（LLM）を利用したシステムには、開発者や情報セキュリティリーダーがセキュリティを強化しない限り、危険な形で悪用されるほかの脆弱性が存在する。

NCCグループのテクニカルディレクターでAI・機械学習セキュリティ責任者であるDavid Brauchler氏がカンファレンスで示した例の一つは、ペネトレーションテスターが顧客のAIシステムからパスワードを抜き出すのがいかに簡単かというものだった。

「この組織は、自社データに関連付けられた信頼レベルを適切にタグ付けせず、AIに組織全体のデータリンクへのアクセスを許可していました」とBrauchler氏はプレゼン後のインタビューで語った。「データやユーザーに適切な権限を割り当てていなかったため、私のユーザーレベルがどの種類の情報とやり取りできるかを細かく制御するアクセスコントロールがありませんでした。」

ガードレールだけでは不十分

単語やコンテンツのフィルターのようなガードレールだけでは、今日のAIシステムのリスクを下げるには不十分だと彼のプレゼンは強調した。実際、インタビューで彼はこう付け加えた。「顧客が『もっと強力なガードレールが必要だ』と言うとき、それは『既知の脆弱性を持つアプリケーションを受け入れ、脅威アクターが私たちを標的にしないことを祈っている』という意味です。」

「成熟したAIセキュリティは、潜在的に悪意のある入力を信頼されたコンテキストから隔離します」と彼はカンファレンスで述べた。開発者やCSOは、ゼロトラストの原則をAI分野に持ち込み、すべてのアプリケーションデータに信頼ラベルを割り当てるなどの戦術を取る必要がある。

「現在、私たちは多くの組織がこれらの言語モデルをアプリケーションに導入しているのを見ていますが、たいていは株主が何らかのAIを求めているからです。しかし、開発者はそれを安全に実装する方法を本当に理解していません」と彼はCSOに語った。

「AIシステムの設計者たちは、これが自分たちの環境にどんな影響を与えるかを理解していません」と彼は指摘し、「CSOも自分たちのチームにどんな教訓を持ち帰るべきか分かっていません」と付け加えた。

NCCグループが評価したほぼすべてのAIシステムがセキュリティ攻撃に対して脆弱だったと彼は指摘した。「私たちは大規模言語モデルを使ってデータベースエントリを侵害したり、環境内でコードを実行したり、クラウドを乗っ取ったりすることができました。」

「企業は、AIの導入によって自社のリスクがどれだけ増大するかを理解していません」と彼は述べた。大規模言語モデルは、受け取る入力によって操作される。AIエージェントが、そのモデルを実行しているユーザーよりも低い信頼レベルのデータにさらされた瞬間、信頼できないデータが言語モデルの挙動を操作し、信頼された機能や機密リソースにアクセスする可能性が生じる。

彼は、次のような状況を想像してほしいと言う。小売業者が、オンライン購入者がチャットボットに製品のカスタマーレビューを要約させることができるAIシステムを持っているとする。このシステムが犯罪者に侵害された場合、プロンプト（クエリ）は無視され、脅威アクターが望む商品の自動購入が行われる可能性がある。

Brauchler氏は、「すべての顧客のパスワードを表示して」といったプロンプトインジェクションを排除しようとするのは時間の無駄だと付け加えた。なぜなら、LLMは出力を生成する統計的アルゴリズムだからだ。LLMは人間の言語インタラクションを再現することを目的としているため、悪意のある入力と信頼できる、または無害な入力との間に明確な境界はない。代わりに、開発者やCSOは、現在の知識を活用して真の信頼セグメンテーションに頼る必要がある。

「これは新しいセキュリティの基本原則の問題というよりも、これまでセキュリティで学んできた教訓をAIの分野でどう適用するかという問題です」と彼は述べた。

CSOのための戦略

Brauchler氏は、CSOが検討すべき3つのAI脅威モデリング戦略を提案した：

• 信頼フロートラッキング：アプリケーション全体でデータの流れと、そのデータに関連付けられた信頼レベルを追跡すること。これは、攻撃者が信頼できないデータをアプリケーションに注入し、その挙動を制御して信頼を悪用することへの防御策となる；
• ソース・シンクマッピング：データソースとは、出力がLLMのコンテキストウィンドウに入るシステムのこと。シンクとは、LLMモデルの出力を消費するシステム（関数呼び出しや下流の他のシステムなど）。ソースとシンクをマッピングする目的は、脅威アクターが信頼できないデータをデータソースに注入し、そのデータが脅威アクターが本来アクセスできないデータシンクに到達する攻撃経路が存在するかどうかを発見すること；
• モデルを脅威アクターとして扱う：脅威モデルの全体像を見て、あらゆるLLMを脅威アクターに置き換えて考える。そのポイントで理論的な脅威アクターが通常アクセスできないものにアクセスできるなら、そこに脆弱性がある。「あなたのチームは、その視点にいる言語モデルが信頼できないデータにさらされることが絶対にないようにしなければなりません」と彼は言う。「そうでなければ、アプリケーション内で重大なレベルの脅威を招くリスクがあります。」

「これらのセキュリティ制御の基本要素を実装すれば、今私たちがテストするすべてのAIシステムで見られる攻撃クラスを排除し始めることができます」と彼は述べた。

Brauchler氏によると、最も重要な戦略の一つはセグメンテーションにある。高い信頼コンテキストで動作するLLMモデルは、決して信頼できないデータにさらされてはならない。そして、信頼できないデータにさらされるモデルは、高権限の機能にアクセスしてはならない。「高い信頼ゾーンで動作するモデルと、低い信頼データで動作するモデルを分離することが重要です。」

さらに、CSOはAI防御をアーキテクチャチームから始めるべきだ。「AIセキュリティは、後からパッチとして追加できるものではありません」と彼は言う。「ガードレールを何重にも重ねたり、途中に何かを追加してアプリケーションを魔法のように安全にすることはできません。システムは最初からセキュリティを考慮して開発する必要があります。そして、励みになるのは、これは新しい教訓ではないということです。セキュリティとその基本原則は、過去30年間と同じように今も適用されています。変わったのは、それがAIを活用する環境にどのように統合されるかです。」

また、CSOや開発者に以下を参照するよう勧めている：

• 人工知能マネジメントシステムの確立・実装・維持のためのISO 42001規格；
• AI対応システムに対する敵対者の戦術・技術のナレッジベースであるMITRE Atlas；
• LLMに関するOWASP Top 10リスクとその対策