AIセキュリティは壊れていない、ただ間違ったものを守っているだけだ

サイバーセキュリティ業界には、新しいテクノロジーが登場するたびに、すぐにその周りに壁を築き始めるというパターンがあります。クラウドでもそうでしたし、コンテナでもそうでした。そして今、AIでも同じことをしています。ただ今回は、私たちが築いている壁が完全に間違った場所にあるのです。

今日、企業のセキュリティレビューに参加すれば、同じ優先事項が聞かれるでしょう：AIモデルの保護、学習データの保護、出力の検証、AI搭載コパイロットの導入です。ベンダーは、ガードレール、プロンプトインジェクション対策、モデル監視プラットフォームなど、モデルレベルの制御に特化した「AIセキュリティ」ツールの販売に躍起になっています。

しかし、攻撃者はあなたのAI統合を、他のすべてへの高速道路として利用しています。

誰も監視していない真の攻撃対象領域

企業環境全体で一貫して観察される一つのパターンは、セキュリティチームがAI開発環境の保護に多額の投資をしているという憂慮すべき状況を示しています：モデルアクセス制御、データガバナンスフレームワーク、MLOpsセキュリティツール。これにより、彼らのAIは「ロックダウンされている」という誤った自信が生まれます。

しかし、実際の攻撃対象領域をマッピングすると、AIチャットボットがしばしば数十のSaaSプラットフォームへのOAuthトークンを保持していたり、過剰なクラウド権限を持つAPIキーを持っていたり、単純なプロンプトインジェクションから本番インフラへの直接的な経路を作り出すアイデンティティ信頼関係を持っていたりすることがわかります。モデル自体は安全かもしれませんが、それが存在するエコシステムはしばしば広く開放されており、これは例外的なケースではありません。

企業は現在、平均130以上のSaaSアプリケーションを使用しており、AI統合はアイデンティティプロバイダー、クラウドインフラ、データベース、ビジネスクリティカルなシステムにまたがっています。各統合は潜在的な攻撃経路であり、各API接続は攻撃者が積極的に探っている信頼境界です。

問題は、AIセキュリティツールが壊れていることではありません。私たちが個々のコンポーネントを保護している間に、攻撃者がそれらの間の接続を悪用していることです。

モデル中心のセキュリティが要点を外す理由

現在のAIセキュリティへのアプローチは、現代の攻撃がどのように機能するかについての根本的な誤解の上に成り立っています。私たちはAIを、データベースやWebアプリケーションを保護するのと同様に、保護が必要な独立した資産として扱います。しかし、本番環境のAIは孤立して存在しません。それは、アイデンティティ、権限、API、データフローの複雑なグラフにおける一つのノードです。

典型的な企業のAI導入を考えてみてください。Google Workspaceにアクセス権を持つAIエージェントがあります。それはAPIを通じてSalesforceに接続されています。通知のためにSlackと統合されています。AWS S3バケットからデータを取得します。OktaやAzure ADを通じて認証されます。ServiceNowでワークフローをトリガーします。

従来のAIセキュリティはモデル自体に焦点を当てます：そのセキュリティ態勢、プロンプト検証、出力の安全性。しかし、攻撃者は統合に焦点を当てます：侵害されたサービスアカウントを通じて何に到達できるか、API操作を通じてどこにピボットできるか、悪用された統合を通じてどの信頼境界を越えられるか。

攻撃はAIモデルで始まりも終わりもしません。モデルは単なる入口です。

攻撃経路は製品の境界を尊重しない

ここがほとんどの組織が行き詰まるところです。彼らは、それぞれが単一のドメインへの可視性を提供するセキュリティツールを導入しています。あるツールはクラウド権限を監視し、別のツールはSaaS構成を追跡し、3つ目はアイデンティティガバナンスを管理し、4つ目は脆弱性管理を扱います。

各ツールはパズルの一部を見せてくれます。しかし、それらのピースがどのようにつながっているかを示すツールは一つもありません。

Gartnerによると、組織は現在平均45以上のセキュリティツールを使用しています。しかし、この莫大な投資にもかかわらず、単一のツールでは完全な攻撃経路を見ることができないため、攻撃者はこれらのドメインにまたがる設定ミスを連鎖させることに成功しています。

攻撃者はあなたのAIモデルに重大な脆弱性を見つける必要はありません。彼らに必要なのは、連鎖を見つけることだけです。それは、あなたのAIサービスにアタッチされた設定ミスがあるIAMロールかもしれません。そのロールはS3バケットへの権限を持ち、そのバケットにはSaaSアプリケーションへの認証情報が含まれており、そのアプリケーションはあなたの本番環境への管理者アクセス権を持っています。

個々の設定ミスは、あなたのセキュリティツールでは「中程度」または「低」と評価されるかもしれません。しかし、それらが連鎖したら？それは重大なエクスポージャーです。そして、各セキュリティドメインを孤立して見ている限り、それは完全に見えません。

エクスポージャー管理の必要性

これが、「AIセキュリティ」から、AI統合環境のための継続的な脅威エクスポージャー管理へと会話を移行させる必要がある理由です。

私たちのAIモデルが安全かどうかを問うだけでは十分ではありません。セキュリティチームは、攻撃者がAIサービスアカウントを侵害した場合に実際に何に到達できるかを理解する必要があります。クラウド、SaaS、アイデンティティシステムにまたがる設定ミスがどのように連鎖する可能性があるかについての可視性が必要です。AI統合が攻撃対象領域をリアルタイムでどのように変化させているかを知る必要があります。そして、深刻度スコアだけでなく、実際の攻撃可能性に基づいてリスクを優先順位付けする必要があります。

ほとんどのセキュリティプログラムは依然として、リスクを孤立して優先順位付けしており、CVSSスコアやコンプライアンスチェックリストを使用していますが、それらは脆弱性があなたの特定の環境で実際に悪用可能かどうかを完全に無視しています。

このギャップは、AIシステムではさらに顕著です。なぜなら、それらは絶えず変化するからです。新しい統合が毎週追加されます。権限は進化します。API接続は変化します。先月の攻撃対象領域は今日の攻撃対象領域ではありませんが、あなたのセキュリティ評価はおそらくそうなっています。

攻撃経路を意識したセキュリティの実際の姿

本番環境のAIを保護するには、根本的に異なるアプローチが必要であり、それは考え方の4つの重要な転換に帰着します。

第一に、セキュリティドメイン全体での統一された可視性が必要です。各セキュリティツールが独自のサイロで動作することをやめましょう。あなたのクラウドセキュリティ、アイデンティティガバナンス、SaaS管理、脆弱性スキャンツールはすべて、攻撃経路パズルのピースを保持しています。それらはリアルタイムでデータを共有し、設定ミスがどのように連鎖するかを確認できるようにする必要があります。

第二に、継続的な攻撃経路シミュレーションを受け入れましょう。侵入テストやレッドチーム演習で悪用可能な経路を発見するのを待たないでください。理論上の深刻度スコアに頼るのではなく、実際の悪用可能性に焦点を当てて、攻撃者があなたの環境をどのように移動できるかを継続的にテストしてください。

第三に、文脈に基づいて優先順位を付けましょう。設定ミスがあるS3バケットが、公開されているからといって重大なわけではありません。それが公開されており、認証情報を含み、それらの認証情報が特権アクセスを持ち、かつインターネットに公開された資産から到達可能である場合に重大なのです。文脈は個々のスコアよりも重要です。

第四に、先制的な修復に向けて動きましょう。SOCチームがアラートを調査している時点で、あなたはすでに貴重な対応時間を失っています。現代の防御には、インシデントの後ではなく、悪用可能な経路が武器化される前にそれを閉じる能力が必要です。

無視できない警告

AIが企業スタックのあらゆる層に組み込まれるにつれて、攻撃対象領域はセキュリティチームが手動で推論できる速度よりも速く拡大しています。私たちは、AIを保護する速度の10倍の速さでAI統合を追加しています。

もしあなたがAIを孤立して保護し、モデルを保護しながらそれが動作するエコシステムを無視しているなら、あなたはすでに遅れを取っています。攻撃者はツールではなく経路で考えます。彼らは個々の脆弱性を悪用しません。彼らはあなたの環境全体にわたる設定ミスを連鎖させます。

AIをうまく保護する企業は、最も多くのAIセキュリティツールを持っている企業ではなく、AIセキュリティが攻撃対象領域全体にわたるエクスポージャー管理から切り離せないことを理解している企業になるでしょう。

モデルセキュリティは基本条件です。重要なのは、攻撃者がAI統合を侵害したときに何に到達できるかを理解することです。セキュリティチームが、環境全体で継続的かつリアルタイムにその質問に答えられるようになるまで、彼らはAIを保護しているのではありません。彼らはただ、自分たちが築いた壁が正しい場所にあることを願っているだけです。