中国の万里の長城は、北方の襲撃者の進軍を遅らせ、ステップ地帯の軍隊が帝国の中枢へ一直線に乗り込むのを防ぐために築かれた。ところが1644年、その最も難攻不落の要塞は包囲戦もなく陥落した。
長城が渤海に接する山海関では、呉三桂将軍が東の門を守っていた。背後では、反乱軍が北京を陥落させ、皇帝は死に、明王朝は内政危機で揺らいでいた。前方には、数十年にわたり弱点を探り続けてきた満州軍。呉は要塞戦の最古のジレンマに直面した――より大きな脅威は誰なのか?
彼は門を開いた。満州軍は雪崩れ込み、反乱軍を打ち破り、そのまま去らなかった。彼らは清王朝を樹立し、その後268年間、中国を統治した。共和制以前の最後の皇朝である。
長城が失敗したのではない。石は持ちこたえた。壊れたのは、それが依存していた人間の仕組みだった。
壁が崩れるのは、レンガが弱いからではない。壁の周囲の仕組みが弱いからだ。薄給の衛兵は買収され、門の手順は形骸化し、補給線は途絶える。攻撃者は、門を通って歩いて入れるなら、壁を叩き壊す必要はない。
だからこそ私は、AIセキュリティは本質的にクラウドインフラの問題だという、近年ますます広まっている捉え方に同意しない。クラウドセキュリティは重要だ。アイデンティティ、テレメトリ、インシデント対応は最低限の前提である。だがAIリスクを、主としてホスティング層を堅牢化することで解決できるものとして扱うのは、安心感のある単純化であって、完全な脅威モデルではない。
Palo Alto Networksは最近の報告で、過去1年にAIシステムへの攻撃を少なくとも1回経験した組織が99%にのぼると述べた。ほぼ全員が攻撃を受けているなら、正しい結論は「もっと高い壁を築け」ではない。「私たちは間違った境界を守っている」だ。
要塞の誤謬
要塞的な発想は、暗黙の前提から始まる。インフラを守ればシステムも守れる、という前提だ。このメンタルモデルは、システム境界が明確で、ワークロードが決定論的な場合には機能し得る。しかしAIはその両方の前提を壊す。現代のAIスタックは、モデルがあなたのクラウドテナント内で動いていても、整然とした境界の外側にあるコンポーネントに依存するエコシステムだ。オープンソースライブラリ、データパイプライン、評価ツール、プラグイン、エージェントフレームワーク、そしてそれらのいずれも変更できる人間。セキュリティ計画がクラウド制御で始まりクラウド制御で終わるなら、攻撃者が正面から攻めるつもりのないシステムの周りに、優れた防御を築くことになる。攻撃者は強みを迂回し、弱点を狙う。門番が薄給で過重労働だったり、不可能な選択を迫られていたりするのに、なぜ壁を拡張するのか?
信頼の問題を考えてみよう。多くの組織は、別の場所で訓練されたモデルを利用し、それを微調整して、本番環境へ投入しているが、社内の専門知識は限られている。たとえ自社ホストであっても、あなたはモデルを書いたわけでも、学習データをキュレーションしたわけでもない。クラウドの堅牢化はその依存関係を変えない。箱がより安全に見えるだけだ。最も危険な失敗は、侵入とは限らず、許可された結果であることも多い。AIエージェントは混在する信頼レベルの入力を実行へと変換し、エージェントが内部コンテンツを読み、チケットを起票し、ワークフローを起動できるなら、攻撃面はエージェントに許されている行為そのものへ移動する。攻撃者がエージェントが取り込むものに影響を与えられるなら、マルウェアやエクスプロイト連鎖がなくても、実行されるものに影響を与えられることが多い。現実世界のAIインシデントは、しばしば「接着剤」の部分――テレメトリ、オーケストレーション、プラグイン、そしてモデルの横にあるベンダーサービス――に関わっている。
人間は依然として最大の弱点だ。AIセキュリティの議論はアーキテクチャに執着する一方で、脅威アクターはアクセス経路に執着する。クラウド制御では、強要、ソーシャルエンジニアリング、内部不正を防げない。少数の人がAIシステムのツールやポリシーの変更を承認できるなら、攻撃者はそこに集中する。
歴史はこの教訓を明確に示している。万里の長城の守備兵は、商人や密輸業者を通すため、巡回を省くため、見張りの任務を怠るために、金を受け取っていた。不規則な支払いと賃金の遅配が、彼らを付け込みやすくした。今日の「賄賂」は、しばしば現金ではない。フィッシングリンクかもしれないし、偽のベンダー依頼かもしれないし、本番障害の最中に手順を省くよう迫る圧力かもしれない。門を守る人が説得されて開けてしまうなら、どれほど強固な壁でも意味がない。
内側からのセキュリティ
まず、セキュリティリーダーがすでに受け入れるべき前提から始めよう。あらゆるものは侵害され得る。あなたの仕事は、確率を下げ、脅威を迅速に検知し、予防が失敗したときの被害を限定することだ。
ホストされている場所だけでなく、AIシステム全体を脅威モデル化せよ。データのサプライチェーン、ツール群、評価パイプライン、プラグイン、エージェント、そしてそれらを変更できる人々を含める。脅威モデルが上流・下流の依存関係を除外しているなら、それは不完全だ。
非人間のアイデンティティを重大なリスクとして扱え。エージェント、サービスアカウント、ツールの資格情報は、特権ユーザーアカウントと同様に管理すべきだ。常時付与の権限をゼロにし(常時オンのアクセスをなくす)、ジャストインタイムのアクセス、高影響アクションに対する文脈に応じた承認、異常なツール挙動の監視を適用する。「生産性のため」にエージェントへ広範な権限を与えた瞬間、攻撃者が乗っ取れる新たなコントロールプレーンを作ったことになる。
監査に耐える変更管理を構築せよ。答えられるべきだ――誰がエージェント権限、検索(リトリーバル)ソース、ツールのバインディング、またはポリシーゲートを変更したのか? それらの制御が密かに変更できるなら、あなたは、急いだ変更ひとつでセキュリティインシデントになり得るシステムを運用している。
侵害だけでなく、操作を前提とした検知に投資せよ。AI悪用の難しさは、悪意ある行為が従来のログでは正当なものに見え得る点にある。入力から結果までの追跡可能性が必要だ。どんなコンテキストが投入され、どんなツール呼び出しが起き、どのポリシーが有効で、どの境界が越えられたのか。
クラウドセキュリティは必要だ――しかし十分ではない。ベンダーがAIセキュリティは主にクラウドインフラの問題だと言うとき、私には「壁は高いから安全だ」という現代版に聞こえる。呉三桂の壁も高かった。帝国の端で海まで伸びていた。それでも、周囲の仕組みが崩壊したときには何の意味もなかった。帝国は内側から崩れる。
AIセキュリティは、より良い要塞を築くことで解決しない。委任された権限を統治し、サプライチェーンを堅牢化し、何かが――いつではなく――起きたときに何が起きたのかを証明できるシステムを構築することで解決する。
David SchwedはSVRNのCEOであり、 データプライバシーと自律的な計算能力によってユーザーを支援する、分散型で主権的なインテリジェンスシステムの構築に注力するAIインフラ企業である。
翻訳元: https://cyberscoop.com/ai-threat-modeling-beyond-cloud-infrastructure-op-ed/