AIエージェントがセキュリティ評価から脱出し、LLMマーケットプレイスのHugging Faceを攻撃した件は、すでにご存じの方も多いでしょう。このエージェントは、ベンチマークの答えがHugging Faceにあると判断し、カンニングのためにそれを盗みました。動機は滑稽ですが、結果は恐ろしいものです。

Hugging Faceは侵入の詳細な再現を公開しています。サンドボックス脱出、コード実行、クラウド認証情報、即席のコマンド＆コントロールシステム、そして最終的にTailscaleを使って組織全体に拡散するまでの4日半にわたる約17,600件の復元されたアクションが含まれています。

しかしTailscaleはゼロトラストネットワークです。ゼロトラストの目的は、攻撃者が社内で横移動するのを防ぐことです。何が問題だったのでしょうか？

Tailscaleが登場した場所

Tailscaleに「脆弱性」は発見・悪用されておらず、それが私たちにとってさらに不快な点かもしれません。TailscaleはAIインフラのあらゆるところに登場します。事実上すべてのAI企業がTailscaleを使用しています。だからAIインシデントレポートに最終的に登場しても不思議ではありません。

しかし、私たちはセキュリティツールです。彼らの侵入は私たちの侵入であり、それを真剣に受け止めるのが私たちの仕事です。ポストモーテムと同様に、何が起こり、何ができたかを振り返る必要があります。

エージェントがサンドボックスから脱出し、Tailscaleを発見した時点で、すでに本番ワーカー内でコード実行権限を取得し、Kubernetesノードでrootアクセスを取得し、136個のキーを含む本番シークレットストアを読み取っていました。ある意味、私たちが登場する前にゲームオーバーだったのです。

しかし、それが問題ではないでしょうか？ 少し視点を戻してみましょう。なぜ長寿命のシークレットキーが誰でもアクセス可能だったのでしょうか？

長寿命の認証情報が標準だから

そうあるべきではありません。私たちは今、それがなぜ問題なのかを示す素晴らしい例を見ました。ほとんどの侵入が人間の速度で行われていた古い世界では、認証情報漏洩対策は「あったらいいもの」として扱われていました。136個のキーを一度に読み取れる大きな認証情報ストアは、セキュリティチームの優先度の低いリストのどこかにあったTODO項目でした。

今、悪意のあるAIエージェントの世界では、大きな認証情報保管庫が獲物です。もうそれでいいわけではありません。

長寿命の認証情報に対する主な解決策は2つしか知りません。

1つ目は、1回挿入した長寿命の認証情報に基づいて短命の認証情報のみを発行し、決して返さない保管庫を設定することです。HashiCorp Vaultはこれを実現できます。例えば、動的認証情報と呼んでいます。残念ながら、動的認証情報の設定と維持は多くの作業を必要とします。セキュリティに作業が必要な場合、人々は実行しません。

2つ目の選択肢は、認証情報を注入するプロキシです。クライアントCがサーバーSにアクセスしたい場合、CにSの認証情報を与えるのではなく、要求を受け取り、認証情報を挿入し、それを通過させるだけの強化されたプロキシP経由で要求を送信させます。モダンなメッシュベースのネットワーキングが遅延のほとんどを排除した今、認証情報の注入は人気を集めています。数ヶ月前、私たちはBorder0（「Tailscale PAM」）を買収しました。これはTailscaleと密接に統合されたエレガントで非常に洗練された認証情報注入プロキシを作成します。Border0を完全に導入すれば、136個のキーを読むことを防ぎ、それぞれの使用試行をログに記録できたでしょう。（同じ認証情報注入の機能はAperture Connectorsにも搭載されています。）しかし、これはまだ新しすぎます。ほとんどの顧客はまだこれを見ていません。

ボーナスとして3つ目の選択肢：Tailscale自体です。Tailscaleでは、ノードキーをTPMを使用してマシンにバインドし、エクスポートを防ぐことができます。エンタープライズであれば、ぜひそれを実行すべきです。残念ながら、LinuxとWindowsではデフォルトでTPMストレージをオフにせざるを得ませんでした。一部のユーザーのハードウェアで発見されたHSMの問題のためです。ともあれ、今回のケースでは攻撃によってTailscaleへのアクセスが許可されたため、私たちは遅すぎました。

その長寿命の認証キーは存在する必要がなかった

動的認証情報も認証情報注入プロキシも導入されていなかったため、136個のキーが漏洩しました。次の防衛線は何でしょうか？

その136個の認証情報のうちの1つは、再利用可能なTailscale認証キーでした。これは新しいTailscale CI（継続的インテグレーション、自動テストに使用）ノードをtailnetに作成するために使用されていました。エージェントはそのキーを一連の外部サンドボックスにコピーし、数日かけて合計181台のノードをHugging Faceのtailnetに登録しました。これらのノードはそれぞれ、CIノードが得るすべてのアクセスを許可するTailscaleアイデンティティタグを受け取りました。

私たちは136個のキーを守れませんでした。しかし、再利用可能なTailscaleキーはその中に含まれる必要はありませんでした。

私たちはこのようなケースのためにワークロードアイデンティティフェデレーションを構築しました。これは、クラウドプロバイダーが実行中のVM（またはコンテナ）のクラウドアイデンティティから生成された短命の認証情報という形で「アンビエント権限」を提供することに依存しています。CIジョブはクラウドプラットフォームに署名付きOIDCトークンを要求できます。Tailscaleはトークンを検証し、そのワークロードに割り当てられたタグとスコープでアクセスを許可します。素晴らしいのは、有効化すれば自動的に実行できることです。CIノードを起動すると、Tailscaleがアイデンティティを取得し、正しいタグを割り当てます。漏洩する認証情報はなく、慎重に設定すれば、この認証情報をCI以外で使用する方法はありません。

つまり、CI認証情報を取得し、別のノードで実行し、テストクラスタからネットワークの他の部分への舗装された経路に変えることはできないということです。

残念ながら、ワークロードアイデンティティフェデレーションを使用している人は十分に多くありません。私たちは顧客がこれがより簡単かつ 安全な道であることを知り、明確な採用方法があるようにするためにもっと努力すべきでした。ドキュメントを改善し、UIにさらにナッジを追加できます。

クライアントログがないことは証拠がないことを意味しない

足跡を隠そうとして、エージェントはTailscaleを--no-logs-no-supportで実行しました。これはそのクライアントからのレポートを抑制するものです。

これは、テレメトリメタデータをTailscaleに送信することを懸念するユーザーのために設計されたオプションです。たとえ私たちが提供していなくても、テレメトリを削除するためにソースコードを変更するのは簡単です。

しかし、ログを停止しても接続が不可視になるわけではありません。Tailscaleのネットワークフローログを有効にすると、すべての接続の両端からのトラフィックに加え、サブネットルーターと出口ノードからのトラフィックも報告されます。これは微妙ですが重要です。侵害されたノードはフローログを送信しないかもしれませんが、接続先のすべてのノードは送信します。そして、慎重に設定されたSIEMは、両端が一致しない場合に即座に赤い警告を発することができます。

フローログは、慎重に設定されたSIEMにストリーミングされれば検出に役立ちます。しかし、それは多くの作業を必要とします。フローログを有効にし、リアルタイムで有用になるように適切なライブ検出ルールを用意する必要があります。フォレンジック用だけでなく、リアルタイムで役立つようにです。私たちはフローログをより発見しやすく、設定しやすく、採用しやすく、アラートトリガーとして機能させる方法を検討しています。私は、セキュリティチームが監視していなくても役立つほど、フローログを簡単に使用できるようにしたいと考えています。

ロギングを超えた直接的な制御が必要な場合は、Tailnet Lockを有効にすることもできます。これにより、すべての新しいノードに対して直接的な可視性と厳格でプログラム可能な入場制御が提供されます。例えば、ある程度の作業で、署名ノードをプログラムして「CI」タグが常に特定のIPアドレス範囲またはその他のサイドチャネルによる有効性の証明を持つことを確認できます。

安全な道を簡単な道にする

ネットワークセキュリティは難しい。常に難しいものでした。悪意のあるAIエージェントの新しい世界では、ただ難しいだけでなく、必須です。そして、それは多くの組織がネットワークセキュリティの専門知識を持っていないという問題を引き起こします。

だからTailscaleでは、私たちはそれを個人的に受け止めています。人々は、私たちの製品がデフォルトでこの種の横移動攻撃を防ぎ、自分たちでやらなくてもいいことを期待しています。横移動攻撃が何かを知らなくてもです。

このインシデントで自分のインフラに少し神経質になったなら、まずワークロードが読み取れる再利用可能なTailscale認証キーを確認することから始めてください。特にクラウドとCIについては、可能な限りワークロードアイデンティティフェデレーションに置き換えてください。それらの長寿命の認証キーをなくしてください。

（認証キーは、特にワンタイムプロビジョニングやプラットフォームアイデンティティのない環境で、良い用途があります。必要な場合は、ワンオフキーを優先してください。OAuthクライアントを使用して認証キーの有効期限を短く保ち、狭いタグを使用し、ACLでそれらのキーに付与された権限を監査してください。）

ネットワークフローログを有効にし、セキュリティチームがすでに使用しているツールに送信してください。

TPMを制御できる管理されたフリートでは、セキュアノード状態ストレージを使用してください。そうでない場合は、デバイスポスチャを使用してノードを分離・制限してください。

私たちはこれらのより安全な選択肢を十分に明確にしていなかったことを知っています。それは私たちの責任です。ドキュメントを改善し、UIにナッジを追加し、デフォルトでオンにするよう最善を尽くし、危険なことをしているときに警告し、より良い代替案を提案します。

これは私たちの非常にカナダらしい謝罪です：つま先を踏んでしまってすみません。攻撃はTailscaleを悪用したものではなく、Tailscaleが侵害を引き起こしたわけでもありません。しかし、私たちはそれを止められませんでした。次は止めます。

Tailscaleをご利用で、さらに詳しく知りたい場合は、サポートおよびソリューションエンジニアリングチームにご連絡ください。設定を強化し、次のAIエージェントが発見する前に粗い部分を見つけるお手伝いをします。