ゼロトラストは、証明されるまで全員を攻撃者とみなす考え方です。しかし、企業内に得体の知れない自律型エージェントが群がるようになると、この前提を維持するのは困難、あるいは不可能に近くなります。
「ビジネス部門はエージェントが何を節約し、何を生み出したかで評価されます。一方セキュリティ部門は、何かがうまくいかなかったときに起きるすべての事態で評価されるのです」。Coalition for Secure AI(CoSAI)のメンバーであり、ACMのAIセキュリティ(AISec)プログラム委員会にも名を連ねるNik Kale氏はこう指摘します。「彼らは同じエージェントを、まったく異なる2つの損益計算書を通して見ているようなものです」
Kale氏が主張する重要な点は、エージェント型AIの本質そのものが、ゼロトラストとは正反対の性質を持っているということです。
「ゼロトラストは、リクエストを1つずつ評価するために設計されました。リクエストを発する主体が、それらを戦略的に組み合わせてより大きな何かを作り上げようとしていない限りは、これでうまく機能します。しかしエージェントはその前提を覆します。あるエージェントに、ドキュメントの読み取りを許可し、別のデータソースへの照会を許可し、見つけた内容の要約を許可し、それをファイルに書き込むことを許可し、さらに外部へのメール送信を許可したとしましょう。これらの判断は、それぞれ単体で見れば正しいものです。しかし、この順序で組み合わせれば、まさにデータ流出の経路を許可したことになるのです」とKale氏は指摘します。
「エージェントは、完全に合法な5つの扉を通り抜けた末に、企業がまったく許可していない場所へたどり着いてしまうことがあります」と同氏は付け加えます。「金融の世界で言えば、それぞれがエスカレーションの閾値を下回る10件の取引があり、その合計額については誰も承認していない、という状況が起こり得ます」
Kale氏によれば、より難しい問いは「今日、そのIDを使っているものが、本当に自分たちが承認したものと同一かどうか」だといいます。
「モデルを更新する、同じインターフェースの裏にツールを追加する、誰もレビューしていないコンテキストでメモリを埋めていく、委任先を与える――こうしたことをしても、IDそのものには一切手が加えられません」と同氏は説明します。「リストには依然として『承認済み』と記載されたままです。月曜日に承認したものと、金曜日に同じバッジを身につけている実体とでは、中身がまったく別物になっている可能性があるのです」
この文脈的な把握が欠けていることこそが重大な問題です。「そのIDが今どのような存在になっているのか、どのような権限を帯びているのか、どのような一連の処理を積み重ねようとしているのか、そして次のシステムがその権限を正当なものとして認めるのかどうかを把握しておかなければなりません」とKale氏は言います。「そうでなければ、私たちはただの許可リストに手を加え、宣伝文句を磨いただけのものを『ゼロトラスト』と呼んでいるにすぎないのです」
なぜエージェント特有の問題はより深刻なのか
ゼロトラストは、分散化が進み、リスクの高い時代のセキュリティモデルとして提唱されてきました。その中核をなす「決して信頼せず、常に検証する」という原則は、企業ネットワークにアクセスするすべてのユーザーとデバイスに適用されます。境界の内側にいるか外側にいるかは問いません。
しかし、エージェント型AIはこの状況を複雑にし、自律型エージェントをめぐる問題をはるかに深刻なものにしています。承認済みのエージェントは、認識可能なIDを持たないままオリジナルのすべての権限を継承したサブエージェントを生成できてしまいます。さらにエージェントは他のエージェントと通信することもでき、その通信を通じて悪意ある指示を伝達される可能性もあります。このセキュリティ上の穴は少なくとも1年前から広く知られているにもかかわらず、このエージェント間のやり取りのブラックボックスを見通す仕組みを提供したベンダーは、いまだに一社もありません。せいぜい、通信が発生したこと自体を検知できる程度で、そこで何が語られたかまでは分からないのが実情です。
エージェントの活動を統制する一般的な方法は、IT部門やセキュリティチームによるオンボーディングをエージェントに義務付けることです。各エージェントにはIDが発行され、そのIDを持つものだけが何らかの操作を実行できる仕組みです。
しかし現実はまったく異なります。企業環境に存在するエージェントの大多数は登録されていません。従業員が正規の手続きを経ずにエージェントを送り出してしまう、いわゆるシャドーIT的な行動が原因の場合もあれば、資格情報を持つサードパーティが許可を得ないまま環境内でエージェントを起動しているケースもあります。さらに言えば、あらゆるIDと同様、攻撃者、とりわけ国家的な攻撃主体がこれらを乗っ取る可能性も考慮する必要があります。認可されたナンバープレートのリストだけを渡された警備員が制限区域を守っているようなもので、IT部門は自分たちのネットワーク内を実際に動き回っているエージェントが何者なのか、把握できないままなのです。
「ガバナンスモデルの照準が、そもそも誤った層に向けられていることが少なくありません。エージェントのおよそ80%はリストに載っていないのです。それは統制とは呼べません。単に、規則を守っている少数派の在庫目録にすぎないのです」と、Kamiwaza.aiでセキュリティエンジニアリングを担当するシニアテクニカルスタッフのKrti Tallam氏は語ります。「この在庫目録型のモデルは、実際の企業現場で通用したためしがありません。私たちはもう、自分たちが環境を統制できているという幻想を捨てるべきです。エージェント型AIがゼロトラストを殺したのではありません。都合の良い、心地よい嘘を殺しただけなのです」
エージェント間通信の問題については、エージェントはしばしば自らのメッセージを難読化しようとし、時には画像や音声・動画ファイルに指示を埋め込むこともあります。
エージェント間の可視性というジレンマ
Tallam氏は、CISOがこうしたエージェント間のメッセージを可視化できるようになる日が来るとは考えていません。むしろ、攻撃者側の手口がより巧妙かつ洗練されたものになっていくと予測しています。
すでに乗っ取られたエージェントは、不審なほど高い通信件数を避けるため、接続先や悪意ある指示で汚染するエージェントの数を意図的に絞り込んでいます。その手口とは、最初に乗っ取られたエージェントはあえて発見・停止させられるがままにしておき、実際の攻撃は数日後、感染した複数のエージェントが仕込まれた指示を実行に移すタイミングで発動する、というものです。
従来型の防御策は、すべてのエージェントの挙動を監視し、感染したエージェントが悪意ある行動を取った瞬間に停止させるというものです。しかしTallam氏は、乗っ取られたエージェントが今後、標的となるエージェント本来の役割や許可されている行動範囲そのものを学習し始めると予測しています。それは単に、当該エージェントにその情報を尋ねるだけという単純な手口で済んでしまう可能性もあります。
「攻撃側の狙いは、攻撃の指示を多数のエージェントに分散させ、どのエージェントも正規の指示から意味のある逸脱をしていないように見せかけることです」とTallam氏は述べています。
Aikido SecurityのエンタープライズCISOを務めるMike Wilkes氏は、CISOはGPG/OpenPGPから教訓を学ぶべきだと提案しています。同方式では、ユーザーは「厳重に保護されたプライマリIDを保持しつつ、限定的かつ有効期間の短い署名用サブキーや暗号署名付きの資格情報をエージェントに委任し、サブエージェントにはさらに範囲を絞った委任済み資格情報を与える」仕組みになっているといいます。
つまりエージェントには、「レート制限、取引の境界、支出やデータ利用の予算枠、サンドボックス化、重大な結果を伴う操作に対する承認ゲート、そして改ざん不可能な活動ログの記録」といった一連の仕組みが組み合わされて適用されることになる、とWilkes氏は説明します。「そして何より重要なのは、自律システムには迅速かつ確実な『取り消しボタン』が必要だということです。結果を元に戻せるタイプ2の判断は委任してもさほど危険ではありませんが、本番データの削除、IAMポリシーの変更、資金の移動、あるいは取り返しのつかないインフラ変更といったタイプ1の判断を委任するのは、はるかに危険です」
VaronisのフィールドCTOを務めるBrian Vecci氏は、エージェントをめぐる状況は多くの人が思っている以上に深刻だと主張します。
企業のCISOたちは、「非決定論的な振る舞いを見せる非人間ID(NHI)への備えが著しく不足しています。IDというものは、統制手段としてはお粗末なレベルにしかならないと前提しておく必要があります」とVecci氏は語ります。
エージェントの活動に関する情報をできる限り多く収集すること自体は望ましい目標ですが、そうしたテレメトリ収集の精度と実現可能性には難しさが伴う、とVecci氏は指摘します。さらに同氏は、企業の多くのエージェントテレメトリ収集の取り組みは、「干し草の山から針を探そうとしているのに、そこにさらに干し草を積み増しているようなものだ」と付け加えています。
翻訳元: https://www.csoonline.com/article/4215449/zero-trust-has-a-big-ai-agent-problem-ahead.html