コンテンツへスキップ
OpenAIおよびHugging Faceにおけるセキュリティインシデント

先週、あるAIエージェントが、本来アクセスすべきではない本番環境に侵入した。そのエージェントはゼロデイ脆弱性を発見し、盗んだ認証情報と組み合わせて利用し、自身の権限を昇格させ、運用者が管理していない企業のインフラ内を横方向に移動した。これを指示した攻撃者はおらず、承認した人間もいなかった。ただ、ベンチマークのスコアを追求していただけだった。.

それがその出来事です OpenAI と Hugging Face 今週明らかになった。GPT-5.6 Solおよびそれよりもさらに高性能なプレリリース版モデルに対する内部評価の過程で、OpenAIは、より制限の少ないテストを可能にするため、サイバー拒否に関する一部の安全策を解除した。.

このモデルは予想をはるかに超える成果を上げた。 このモデルは、パッケージレジストリプロキシのゼロデイ脆弱性を悪用してサンドボックスを脱出し、インターネットへの経路を見つけ出し、自身がテストされていたベンチマークの解答キーがHugging Faceでホストされている可能性が高いと推測し、盗んだ認証情報とリモートコード実行のエクスプロイトを組み合わせて、Hugging Faceの本番システムから直接その解答キーを盗み出した。 Hugging Faceは、OpenAIから連絡が来る前に、自社のセキュリティチームとモデルを用いてこの侵入を検知し、封じ込めた。OpenAIは、テスト対象のベンチマークでモデルがなぜこれほど高いスコアを出せたのか疑問に思った後になって初めて、この脱出と一連の行動を検知した。.

AIは、誰にも気づかれず、監視もされず、規制もされないまま広がっている

OpenAIはこの件を「前例のないサイバーインシデント」と呼んだ。しかし、それは単なるそれ以上のものだ。これは、これから起こる事態の前兆に他ならない。.

ゼロデイ脆弱性についてはひとまず無視して構いません。いずれパッチが適用されるでしょう。すべてのCISOが懸念すべきは、このインシデントが、エージェントがどのようにアクセス権を蓄積し、目標を達成するために予期せぬ行動を取る可能性があるかを浮き彫りにしているという点です。このエージェントは、Hugging Faceのインフラにアクセスする許可を誰にも求めませんでした。 そのエージェントは、自身の能力を検証するよう求められた際、一連の脆弱性と継承された認証情報を通じて経路を見つけることが最善の方法であると判断した。そのアクセス権限を付与した者は誰もいなかった。エージェントに攻撃を実行するよう指示した者もいなかった。Hugging Face自身の防御システムが侵入を検知するまで、リアルタイムで監視していた者もいなかった。.

この事案は、ゼロトラストの原則から想像しうる限り最もかけ離れたものでした。 また、これは今日エージェントを実行している企業環境に直接当てはまる部分でもある。コパイロット、自律型パイプライン、エージェント型ワークフローを導入している組織の多くは、それらに関する基本的な質問に答えられない。例えば、実行中のエージェントの数はいくつなのか、各エージェントが実際にどこにアクセスできるのか、管理責任者は誰なのか、どのシステムやデータにアクセスできるのか、そして権限が一度でも見直されたことがあるのか、といった点である。 一度に限られた数の権限しか扱わない人間ユーザーとは異なり、エージェントは、そのすべてのアクセス機能を、高速かつ大規模に、事実上同時に試みることができます。また、エージェントは権限を継承し、それらを連鎖させ、行動を起こします。その速度は、人間が気づくことさえ難しいほど速く、ましてや承認する余裕などありません。.

従来のIAMは、AIを想定して構築されたものではありませんでした

従来のアイデンティティおよびアクセス管理(IAM)は、ユーザーが何にアクセスできるか、どのように認証を行う必要があるか、そしてどのような状況がリスクとなるかを明確にするために構築されました。.

IAMでは、ユーザーがアクセスを申請し、管理者がそれを承認し、レビューサイクルによって逸脱が検出されるという仕組みを前提としています。しかし、呼び出したサービスから認証情報を継承し、週末の間に数千件もの自律的なアクションを実行できるエージェントについては、これらの段階のいずれもが明確に当てはまりません。今回の事案では、おおむねそのような事態が発生しました。Hugging Faceはその後、 17,000 その単一の事象から記録された出来事。.

それはゼロトラストとは程遠いものです。 そして、そのギャップを埋めるには、モデルの整合性を高めるだけでは不十分です(もっとも、OpenAIが指摘するように、それが必要であることは事実ですが)。すべてのエージェントを独立したアイデンティティとして扱い、実際の資産管理、実際のアクセス制御、そして実際の説明責任を課す必要があります。つまり、セキュリティチームがすでに人間やサービスアカウントに対して適用しているのと同じ規律を、非人間的なエージェントに対しても一貫して適用するということです。.

AIのセキュリティを確保するために必要な3つの機能

この課題に対処する上で、セキュリティチームを支援できる3つの機能があります:

  1. セキュリティチームは、登録されていないエージェントを含め、自社の環境で稼働しているすべてのエージェントについて、継続的に可視性を確保する必要があります。.
  2. 各エージェントが実際に実行できることを強制する実行時制御が必要であり、重大な影響を及ぼす可能性のある事柄については、人間が関与する必要があります。.
  3. 彼らには、アクセス権限を継続的に検証し、エージェントの行動に不審な点が見られた時点で、次の監査サイクルを待たずに直ちに是正措置を講じるようなガバナンス体制が必要だ。.

この機能の一覧に、特に目新しい点はありません。インベントリに登録されていないエージェントは、適切に管理することができません。実行時にアクセス制御が強制されない場合は、そのアクセスを信頼することはできません。また、監査証跡がないシステムは、認証を受けることができません。.

AIのセキュリティ対策はどこから手をつければよいか

Hugging Faceの事件は、まずモデルの能力に関する話として受け止められるでしょう。しかし、これはアイデンティティに関する話でもあり、極めて明白なゼロトラストの失敗でもあります。すなわち、管理されていないアイデンティティが、誰も開いていることに気づかなかった扉を見つけ出し、そこから侵入したのです。.

今日、エージェントを運用している企業には、いずれも何らかの形でそのような「抜け穴」が存在しています。今回の事件を受けて問うべきなのは、自社のモデルが安全かどうかではありません。今この瞬間、自社システムにアクセス権を持つすべてのエージェントの完全なリストを作成し、その権限の由来を証明し、誰がそれらを審査しているかを示すことができるかどうか、ということです。.

もし答えが「いいえ」なら、そこから始めればいいのです。.

「決して信用せず、常に確認せよ」

ゼロトラストはアイデンティティから始まります。RSAが、ビジネスの効率を損なうことなく、すべてのユーザーとすべてのアクセス要求を検証するお手伝いをする方法をご覧ください。.
ゼロトラストソリューションについて詳しく見る