TiDB侵害が浮き彫りにしたクラウドセキュリティの誤った前提

オープンソースのデータベースプロバイダーで発生した侵害が、企業のクラウドセキュリティに対する考え方に重大な欠陥があることを、結果的に浮き彫りにした可能性があります。

10月19日、SQLデータベース「TiDB」を販売するソフトウェアメーカーのPingCAPが、侵害を受けたことを公表しました。同社のウェブサイトによると、顧客にはAtlassian、Square、Pinterestといった米国の大手企業のほか、ManusやKimiなど、中国のAI（人工知能）分野の主要企業も名を連ねています。

犯行に及んだのは、「Fulcrum Security」（略称FulcrumSec）というやや紛らわしい名称の、比較的新しい恐喝グループです。同グループのリークサイトには、すでにLexisNexis、Novo Nordisk、Manchester Airports Group（MAG）といった大手組織が掲載されています。FulcrumSecは今年の秋の初めにPingCAPへ侵入したとみられ、クラウド管理、財務、分析、ストレージなどの各システムに、ほぼ自由にアクセスできる状態を1カ月以上続けていたようです。

さらに大きな問題は、下流の顧客が持つ機密データが、この侵害で漏えいしたかどうかです。調査担当者は詳細を調べている最中ですが、初期の証拠からは、顧客にも実際にリスクが及ぶ可能性がうかがえます。顧客のデータベース自体は侵害されていないものの、ベンダーが顧客について保管していた情報だけでも、深刻な問題を引き起こすのに十分かもしれません。

Dark ReadingはPingCAPにコメントを求めましたが、記事の公開時点で回答は得られていません。

ベンダーの侵害でTiDBの顧客にリスク

PingCAPは、インシデントを最初に確認してから12日後に公表したセキュリティ通知で、攻撃者が9月9日から10月7日まで同社のシステムにアクセスできていたことを認めました。同社によると、不正な第三者は窃取したサービスアカウントの認証情報を使って社内システムにアクセスし、データとソースコードをコピーしたということです。

PingCAPが第三者の支援を受けて実施した調査では、攻撃者が悪意あるコマンドを実行した形跡や、同社システム内で永続的なアクセスを維持していた形跡は見つかりませんでした。顧客のデータベースにアクセスした形跡もないとしています。一方で、攻撃者は顧客の請求データやその他の業務データ（契約条件や価格など）に加え、クラウドアカウントや製品の利用状況に関する各種情報（メールアドレス、SQLエディタのテキストやエラーなど）にアクセスしたと説明しています。暗号化されたAPIキーを含むテーブルも持ち出されましたが、調査担当者によると、暗号化によってキーが実際に悪用されることは防がれているということです。

しかし、FulcrumSecが描く状況はより深刻です。

ハッカーらはリークサイトに被害者を名指しする投稿を行い、PingCAPのサービス管理記録、財務記録、Google Cloud内に保存されたファイル、Jiraのサポートチケット、顧客関係管理（CRM）データ、分析データ、ソースコードをすべて入手したと主張しました。さらに、全顧客がTiDB Cloudサービスに対して行ったあらゆる接続の4年分のログも持っているとしています。

重要なのは、ハッカーらがTiDBのデータベースそのものを盗んだとは主張していない点です。代わりに、前述のAPIキーやその他のシークレットといった、悪用される可能性のあるユーザーデータを大量に間接的に入手しました。クラウドデータベースのコマンドを通じて露出した、機微な社内データも含まれる可能性があります。

攻撃者は、巻き込まれた個別の企業も名指ししました。AirBnBやBooking.comなどの米国の有名企業、BaiduやFujitsuといったアジアの大手企業、Capcom、Konami、Square Enixなど世界最大級のゲーム会社も含まれています。最も大きな割合を占めたのはアジアで、日本、中国、香港の影響を受けた組織は合わせて2,000近くに上り、インドからも500組織が挙がっています。

加えてFulcrumSecは、不正アクセスが1カ月ではなく、2カ月近く続いたと主張しています。侵入は広範かつ妨害を受けない状態だったため、その間にPingCAP自身のサービス管理システムのミラーを構築できたといいます。手作業でデータを持ち出す必要はなく、レプリケーションフィードが6時間ごとに社内データベースの最新コピーを自動で取得し、それが22日間続いたということです。

攻撃者の主張には常に一定の懐疑的な目を向ける必要があり、Dark ReadingもFulcrumSecの主張を独自に確認したわけではありません。ただ、同グループには信頼性を裏づける実績がいくつかあります。

たとえば昨年夏、同グループはManchester Airports Group（MAG）に侵入し、86GBのデータを盗んだと主張しました。BleepingComputerの報道によると、そのデータにはMAGが認めていたよりもはるかに多くの本物の個人を特定できる情報（PII）が含まれていました。成果を誇張するハッカーもいますが、このケースはむしろ逆でした。最初の86GBという主張は圧縮後のデータ量で、実際に盗まれた非圧縮の総量は640GBだったとハッカーらは説明しています。

企業はサービスプロバイダーをより厳しく見極めるべき

仮にハッカーの主張をすべて無視し、PingCAPのより限定的な見解を事実として受け入れたとしても、顧客にとって深刻なリスクとなり得ることに変わりはありません。

広範な顧客データや、実際に保護されているのであればAPIキーよりも、おそらく最も差し迫った危険は、目立ちにくい持ち出しデータにあります。Jiraチケット、SQLの履歴、そして組織が無自覚に社内データを漏らしてしまう場所などです。たとえば、顧客がクラウド管理型のデータベースサービスを利用する際、当然ながらベンダーのサーバーにコマンドを送信します。こうしたやり取りには、企業のシークレットやその他さまざまな機微データが含まれていることが少なくありません。

Sysdigのシニアサイバーセキュリティストラテジストを務めるCrystal Morin氏は、次のように説明します。「ベンダーが最初からシークレットを保管しようとすることは通常ありません。しかし、顧客が利便性のために用意された機能を使う際にシークレットを渡してしまうことが多く、そのデータが、認証情報の保管場所とはほとんど考えられていない場所に蓄積されてしまうことがあります」

同氏は一例として、PingCAPのSQLエディタのテキストとエラーを挙げます。「これはクエリ履歴とエラー出力であり、その場で何かをデバッグしようとして誰かが接続文字列を貼り付けると、シークレットが蓄積されかねない場所です」と、Morin氏は付け加えました。たとえばFulcrumSecは、被害者を名指しした投稿の中で、持ち出したSQL文を取り上げています。そこには、ある診療所の患者名簿と、別の診療所の医療従事者リストが丸見えの状態で記載されていました。

Keeper Securityの最高情報セキュリティ責任者（CISO）であるShane Barney氏も、Morin氏の指摘に同意します。「PingCAPのインシデントは、企業セキュリティの日常的な現実を示しています。上流の認証情報を組織的に収集できるのであれば、攻撃者は顧客の主要データベースを直接侵害する必要がありません」と同氏は語ります。「現代のSaaS（Software as a Service）エコシステムでは、顧客のメタデータ、APIキー、診断用のクエリログが、日常的な運用テレメトリーを通じてベンダーの環境に入り込んでいます。プロバイダーからサービスアカウントの認証情報や管理用APIトークンが盗まれると、集約された運用データが攻撃の道しるべに変わってしまいます」

Barney氏は、クラウドセキュリティの基本的な衛生管理の重要性を強調します。具体的には、ベンダー向けAPIキーのローテーション、開発ワークフローにおけるハードコードされた長期有効なシークレットの排除などです。さらに、マネージドサービスプロバイダーを見極めるため、継続的なサードパーティリスク評価を求めることや、SOC 2 Type IIやISO 27001といった独立した認証・証明を要求することも挙げています。

Morin氏は、クラウドプロバイダーを審査する際に、いくつかの具体的な質問をするよう組織に促します。「顧客が提供したデータのうち、ベンダーが何を保持しているのか、その保持ポリシーはどうなっているのかを、チームは把握すべきです。取り込み時にシークレットをスキャンし、見つかったものを秘匿処理しているかどうかも尋ねるべきです」と同氏は言います。「サービスアカウントの認証情報がどう扱われているかも把握したいところです。短期間で失効するのか、スコープはどう設定されているのか、どのくらいの頻度でローテーションされるのか、認証情報やアカウントの異常な使用に対してどのような検知が働くのかといった点です」

そして、同氏はこう付け加えました。忘れてはならないのは、「侵害時の通知について、特にそのタイムラインと、何をきっかけに通知が行われるのかを確認すること」だということです。