LLMjackingと盗まれたAPIキーの隠れたコスト

本記事は「LLMjacking and the Hidden Cost of a Stolen API Key」を翻訳した記事です。

過去数年間、世界中の技術専門家の頭から離れないトピックが一つあります。それはAIです。

AIはもはや技術スタックの一部ではなく、急速に基盤になりつつあります。カスタマーサポートやデータ分析パイプラインなどの主要なビジネス機能は、大規模言語モデル(LLMs)に移行しており、企業は日々LLMへの依存度を高めています。攻撃者は依存関係を見逃していません。LLMが中核的なビジネスプロセスにおいて中心的な役割を果たすようになるにつれて、LLM自体が価値のある標的になっています。

本記事では、LLMjackingの仕組み、攻撃に関連する潜在的なリスクとコスト、そして検出と防止のためにできることについて説明します。

LLMjackingとは何か

LLMjackingは、攻撃者がLLMへのアクセスを乗っ取る手法です。LLMの普及は比較的最近の出来事ですが、LLMjacking自体は、盗まれたり公開状態になったりした認証情報へのアクセスを取得するという、よく知られた攻撃の別の側面にすぎません。LLM時代以前、犯罪者はAWSやGCPのアクセスキーを探していました。アクセスキーを入手すると、コンピューティングリソース、ストレージ、機密性の高い企業情報にアクセスできる可能性がありました。

盗まれたり公開状態になったりした認証情報による悪影響は十分に深刻ですが、LLMjackingは組織とクライアントの両方に、財務的または評判的にさらに大きな損害をもたらす可能性があります。LLMの利用は従量課金制で高額になることが多いため、悪用は直接的な財務的影響につながります。キーがカスタムモデル、内部プロンプト、または機密データパイプラインに結びついている場合、リスクはコンピューティングリソースだけにとどまりません。盗まれたクラウドキーとは異なり、侵害を受けたLLM認証情報は、攻撃者に生データ以上のものへのアクセスを与える可能性があります。

LLMjackingがもたらす被害とは

LLMjackingインシデントの影響は、予期しないAPIの利用や請求額の膨張にとどまりません。重大な財務的損失、日常業務の混乱、機密性の高い企業データや顧客データの漏洩へと急速に発展する可能性があります。

潜在的な結果がビジネスの複数の側面に及ぶため、リスクを詳細に理解することが重要です。

LLMjackingの財務的影響

通常、最初に「何かがおかしい」と気づくのは財務面です。請求書でLLMjackingの影響を確認した場合、攻撃はすでに大きな損害を与えている可能性が高いです。LLMのAPIに自由にアクセスできる攻撃者は、スパムメールのテンプレート、フィッシングサイト、さらにはマルウェアを自身の悪質な目的のために簡単に作成した可能性があります。

利用制限や請求制限を設けていれば、安全だと考えるかもしれません。攻撃者がLLMでできることには限界があると思うでしょう。しかし、LLMに依存する下流のエージェントプロセスや自動化されたワークフローも影響を受けます。プロセスが重要なビジネス機能に結びついている場合、組織にさらに大きな財務的影響を与える可能性があります。

カスタムモデルの悪用

一部の組織はカスタムモデルに大きく依存しています。モデルが組織の運営方法をよりよく理解できるように、通常は内部文書やビジネスプロセスでトレーニングします。このようなモデルは、新入社員や既存社員向けの「Wiki」のようなものとして利用が増えています。特定の文書をどう扱うべきか、あるいは特定の状況についてどの従業員に相談すべきかわからない場合は、カスタムモデルを使用してLLMに尋ねるだけです。

しかし、攻撃者がモデルにアクセスした場合、公開を意図していなかった組織に関する知識を得る可能性があります。このような情報は、ネットワーク上の足場をさらに拡大するために利用されたり、攻撃者がダークウェブで情報を販売したりするのに役立ちます。

データポイズニング

一部の環境では、同じカスタムモデルが新しい組織データや財務データを使用して常に改良およびトレーニングされています。攻撃者がトレーニングデータやカスタムモデルのトレーニング方法にアクセスした場合、データポイズニングの機会を生み出す可能性があります。

攻撃者は時間をかけて徐々にモデルに影響を与え、従業員に誤解を招くような回答や偏った回答を提供する可能性があります。時間のかかる作業ですが、意思決定を誘導したり、誤った情報を表面化させたり、内部プロセスを操作したりできます。モデルに加えた変更は通常非常に微妙であるため、検出は困難です。

さまざまな攻撃ベクトル

前述のとおり、LLMjackingは決して新しいものではありません。攻撃ベクトルは、攻撃者がAWS、GCP、Azureへのアクセスを取得するためにすでに採用しているものと似ています。違いは、LLMへのAPIキーが組織にさらに大きな損害をもたらす可能性がある点です。

実際には、LLMjackingは通常、攻撃者がフィッシングやソースコードの漏洩、誤って構成した環境、または公開したクライアント側コードを通じてAPIキーを取得することで発生します。

昔ながらのフィッシング

AIを活用した攻撃がますます巧妙になっているにもかかわらず、攻撃者は依然として最も古い手口の一つに依存しています。それは、誰かを説得して認証情報を引き渡させることです。フィッシングキャンペーンはテクノロジーではなく人を標的とするため、LLMリソースへのアクセスを取得するための非常に効果的な方法であり続けています。

巧妙に作ったフィッシングページは、おそらくほとんどの攻撃者が認証情報へのアクセスを取得するための最も簡単な方法です。誤った切迫感を生み出したり、プラットフォームの通知を偽装したりするなど、古い戦術はすべて依然として有効であり、ユーザーに迅速な行動を促すように設計されています。

クラウドやアプリケーションの不適切な構成

誤って構成したクラウド環境は、攻撃者が機密の認証情報を取得するための最も簡単な方法の一つであり続けており、LLMの統合も例外ではありません。APIキーは、公開を意図していない環境変数、構成ファイルやコンテナイメージ、CI/CDパイプライン、またはログシステムに保存しがちです。過剰な権限を持つS3バケット、公開したKubernetesダッシュボード、またはセキュリティが不十分なGitリポジトリは、脆弱性を直接悪用することなく、攻撃者に必要なすべてを渡す可能性があります。

現代の技術スタックにLLM統合を展開するスピードは、攻撃ベクトルの潜在的な影響をさらに悪化させます。チームはセキュリティのベストプラクティスよりも機能を優先することがよくあります。まさにこのようにして認証情報が漏洩し、潜在的な攻撃者にLLMへの自由で完全なアクセスを与えてしまいます。

LLMjacking攻撃をどのように監視および検出するか

LLMjackingインシデントの検出は、単一の明白な侵害を見つけることよりも、異常な利用パターンを特定することに重点を置きます。もちろん、明白な侵害にも注意を払う必要があります。

盗まれたAPIキーは正当な利用を模倣する方法で使用することが多く、従来のセキュリティ監視ツールでは異常を発見しにくくなります。

まず組織のLLM利用のベースラインを確立する

異常な動作を検出する前に、組織にとっての「正常」がどのようなものかを知る必要があります。つまり、APIリクエスト量、トークン消費量、一般的なAPIエンドポイントのベースラインを確立します。ベースラインは異なる期間にわたっても確立する必要があります。通常、月末に利用の急増があるか、あるいは第2火曜日はどうかなどを確認します。

確固たるベースラインは、自然な利用の変化と潜在的な悪用を区別するのに役立ちます。ベースラインを使用して現在の利用パターンと常に比較し、異常があればできるだけ早く調査して、正当な利用の急増か、より悪質なものかを判断する必要があります。

請求利用アラートを監視する

請求利用アラートは、おそらく環境内で「正常」以外の何かが起きている最初の兆候になります。攻撃者が紛れ込み、「低速かつゆっくり」とした方法でLLMを悪用している場合、気づかない可能性があります。

しかし、ほとんどの攻撃者は、必要なことを実行する前にアクセスを失うことを恐れて、LLMリソースを可能な限り利用しようとするでしょう。結果として必然的に請求利用アラートをトリガーするため、その場合はできるだけ早く調査して行動する必要があります。

LLMjackingからどのように防御するか

LLMjackingからの防御は、主に最初から認証情報を取得しにくくすることです。攻撃は通常、モデル自体を悪用するのではなく有効なAPIキーに依存するため、従来のファイアウォールやその他のセキュリティハードウェアは本記事ではあまり重要ではありません。代わりに、効果的な防御は、強力な認証情報管理、厳格なアクセス制御、およびシステム全体で認証情報がどのように使用されているかの継続的な可視化の組み合わせに依存します。

適切な認証情報の衛生管理を徹底する

衛生管理の徹底は、LLMjackingインシデントの影響を制限する最も効果的な方法の一つです。キーの一つが公開状態になった場合に攻撃者が持つ機会の窓を減らします。APIキーを定期的にローテーションすることで、漏洩した認証情報の寿命を確実に制限できます。

ワークロード固有のキーは、封じ込めのためのもう一つの重要なレイヤーを追加します。複数のサービスにわたって幅広いアクセスを許可する一つの共有認証情報の代わりに、各アプリケーション、サービス、または環境が独自の狭くスコープされたIDを取得します。異常な利用は一般的なトラフィックに紛れるのではなく、特定のワークロードまで追跡できるため、悪用の検出と分離がはるかに容易になります。

ワークロード固有のキーには、侵害を受けたキーの影響範囲を縮小するという追加の利点もあります。キーは、特定の操作セットのための特定のエンドポイントにのみアクセスできるようにする必要があります。

最小特権の原則を適用する

ワークロード固有のキーは、最小特権の原則を達成する一つの方法です。最小特権の原則を適用するとは、すべての統合に「念のため」のレベルのアクセスを与えたいという誘惑に抵抗することです。単一のAPIキーが複数のモデル、環境、または下流システムに到達できる場合、キーを盗んだ者は、キーが本来持つべきであったよりもはるかに多くの機能を事実上継承することになります。

同じ原則を人間のユーザーにも適用する必要があります。マーケティング部門のキャロルは、本番環境のプロンプト、顧客データパイプライン、および微調整した法的要約モデルへのアクセスを本当に必要としているでしょうか。おそらく必要ありません。繰り返しになりますが、権限を特定のワークロード、エンドポイント、さらにはモデルに厳密にスコープすることで、侵害を受けたキーから攻撃者が得る可能性のある機能を確実に制限できます。

基本的なセキュリティ原則

基本的な対策がLLMjacking攻撃からの保護に役立つことを忘れがちです。LLMjackingは、組織全体を崩壊させる恐れのある派手な新しいエクスプロイトではありません。以下のポイントは、全体的なセキュリティ体制を強化し、LLMjackingインシデントの検出と防止に役立ちます。

• Hashicorp Vaultのような適切なシークレット管理プラットフォームを使用します。侵害を受けたキーの有用性を最小限に抑えるために、ワークロード固有のキーのローテーションを自動化するのに特に役立ちます。
• GitHubはすべてのリポジトリでデフォルトでプッシュ保護を有効にしており、シークレットを含むコミットがコードベースに到達する前にブロックします。リポジトリの設定で無効になっていないことを確認してください。シークレットがすり抜けないわけではありません。すり抜けた場合は、シークレットが侵害を受けたと見なし、すぐにローテーションしてください。
• たとえばSIEMソリューションを使用して、監査ログとアクセスログを集中管理します。初期ベースラインの作成や異常の監視を、すべて一元化された場所から実行するのに役立ちます。

LLMjackingは新しいが、悪用する脆弱性は新しくない

リソースの乗っ取りは、多くのサイバーセキュリティ専門家にとっておなじみの話です。攻撃者は認証情報を盗み、被害者の犠牲の上に自身の利益のために悪用します。LLMjackingは物語の新しい章の一つにすぎず、以前のものよりもリスクが高い可能性があります。LLMjackingにより、攻撃者はシステムや従業員と同じレベルのアクセスを取得します。結果として財務的な損害につながり、企業や顧客の機密データを公開するリスクが生じます。

LLMが現代の技術スタックに深く組み込まれているため、脅威は特に懸念されます。LLMはもはや孤立したツールではなく、意思決定に影響を与え、プロセスを自動化し、リアルタイムでデータと対話するコンポーネントです。

LLMjackingからの防御には、目新しいセキュリティメカニズムは必要ありません。基本を正しく理解することが求められます。APIキーを価値の高い資産として扱い、スコープを制限し、意図を持って利用を監視します。キーの背後にあるテクノロジーは新しいものですが、悪用している弱点はよく知られており、十分に理解されています。