TL;DR
- 01何が起きたか
韓国の科学技術情報通信部(MSIT)は 2026 年 9 月 3 日、動画配信 TVING の侵害事故の調査結果を公表した。攻撃者は開発者の接続キーで開発環境に入り、開発プロジェクト 361 件をすべて持ち出した。その中(ソースコードと設定値)に、本番環境に入れるキーが 43 本あった。攻撃者はそのうち 2 本で本番環境に入り、データベースに入るための ID とパスワードを得た。そして 3,954 万アカウント(重複を含む)の利用者情報を外部へ持ち出した。
- 02なぜ検出で止まらなかったか
1 回目の持ち出しは、データベースの CPU 使用率が 100% に跳ねた警報を受けて、TVING が止めた。翌日、攻撃者は別のキーでクラウドに仮想サーバを作り、そこから持ち出した。CPU 使用率は 10% 以内にとどまり、警報は鳴らなかった。
- 03欠けていた層
負荷の監視は 1 回目を止めた。無かったのは、本番のキーが使われるたびに、それが誰のどの作業のための使用かを照合する層である。
何が起きたか
- 当事者: TVING。韓国の動画配信サービス。
- 調査: MSIT は 6 月 2 日に韓国インターネット振興院(KISA)と現場調査を始め、6 月 3 日に民官合同調査団を組んだ。キーが盗まれた経緯を調べるため、開発者の端末 9 台を解析(フォレンジック)した。侵入の経路は、セキュリティ機器・データベース・システムのログを突き合わせてたどり、5 段階に分けた(MSIT)。
- 流出したソースコード: 開発プロジェクト 361 件(30.35GB)。おすすめ・検索のアルゴリズム、利用者の管理と認証、決済などを含む。開発環境への侵入は 2 回あり、1 回目に 14 件、2 回目に 361 件すべてが持ち出された。開発環境のキーは 2 本が使われた(MSIT)。
- 流出した利用者情報: 3,954 万アカウント(ログインできるアカウント 2,206 万、休眠・退会 1,737 万、テスト 11 万。同じ人が最大 13 アカウントを持つ例を含む)。ID、一方向に暗号化されたパスワード、氏名、電話番号、メールアドレス、生年月日、本人確認に使う韓国の識別番号(CI)など 20 項目。電話番号の末尾 4 桁とメールアドレスの @ の前は暗号化されていたが、暗号化の鍵も一緒に流出したため、調査団は平文と同じと判断した(MSIT)。
- 特定されていないこと: 最初の開発環境のキーがどう盗まれたか。調査団は、フィッシング、マルウェア、サプライチェーン攻撃、キーの共有、脆弱性の 5 つの筋を調べたが、特定できなかったとしている(MSIT)。
- 調査団が挙げた問題点(MSIT):
- 本番のキーが、ソースコードに直接書かれ(41 本)、設定値に平文で置かれていた(3 本、1 本は重複)。
- すべての開発者に、すべての開発プロジェクトへの権限が与えられていた。キー 1 本でも、すべてのプロジェクトに届いた。
- キーの発行・使用・変更・廃棄を管理する手順が無く、権限の無い者の接続を制御する方針も無かった(例として、接続元の IP の制限や多要素認証を挙げた)。
- 監視は CPU の負荷などに頼り、ネットワークやデータの流れを見て止める仕組みが無かった。整っていれば、大量の流出には至らなかったと判断した。
- 2024 年の模擬ハッキングで、キーがソースコードに直接書かれている点が見つかっていたが、直されていなかった。
用語メモ
TVING(ティービング) — 韓国の動画配信(OTT)サービス。
開発環境と本番環境 — 開発環境は、ソースコードを保管し、開発者が共同で直す場所。本番環境は、サービスを動かすクラウドのシステム(調査結果では AWS)。どちらも、入るには「接続キー」が要る。
接続キー — システムに入るための鍵の文字列。パスワードと同じく、持っている者は持ち主と同じ権限で使える。
仮想サーバ — クラウドの上で、必要なときに作って消せるサーバ。作る権限があれば、データの通り道にも使える。
民官合同調査団 — 韓国の科学技術情報通信部(MSIT)が、韓国インターネット振興院(KISA)などと組んだ調査団。
止めどころは ③ と ⑤。本番のキーを使うときに、誰のどの作業のための使用かを照合していれば、申請された作業と結びつかないキーでは本番に入れず、仮想サーバも作れない。① のキーがどう盗まれたかは特定されていない。
5 月 29 日。キーの盗まれ方は特定されていない。
キー 1 本でも、すべてに届く権限だった(調査団)。
平文で置かれていたと調査団は指摘した。
5 月 30 日。CPU 100% の警報で止められる。
5 月 31 日。警報は鳴らず、サーバは後で消された。
時系列 — 公表と対応
- 模擬ハッキングで、接続キーがソースコードに直接書かれている点が見つかる。調査団によれば、直されていなかった。
- 14 時 42 分から、開発環境の接続キーで開発環境に入られる。15 時 15 分からは本番環境(AWS)にも入られる。
- 9 時 22 分から 1 回目の持ち出しが試みられる。18 時、データベースの CPU 使用率が 100% に達して警報が出る。TVING は警報を見て、その作業を止めた。調査団によれば、この異常の兆候から約 14 時間後に、情報保護の専任組織と CISO に状況が共有された。
- 10 時 10 分、本番のキーが盗まれ情報が流出した疑いが、情報保安チームに伝わる。19 時から 22 時 20 分、別のキーで作られた仮想サーバから、利用者情報が外部に送られる。調査団は、このときの CPU 使用率は 10% 以内で、攻撃者が警報を避けるために使用率を抑えたと判断した。
- 15 時 8 分、TVING が KISA に届け出る。TVING は事故に気づいた時点を 5 月 31 日 15 時 9 分と届け出たが、調査団は 10 時 10 分と判断し、そこから法の定める 24 時間を過ぎたとした。
- MSIT が調査結果を公表する。
事実は、MSIT が 9 月 3 日に公表した民官合同調査団の調査結果(一次)に拠る。時刻と件数も同じ資料による。個人情報の詳しい流出規模は、個人情報保護委員会が分析の後に公表するとしている。調査結果の公表時点で、利用者への被害や、ダークウェブでの売買の兆しは確認されていない。
対応
- TVING: 6 月 3 日から被害相談の窓口を開いた。持ち出されたソースコードの脆弱性を、民間のセキュリティ会社に診断させている(MSIT)。
- MSIT: 届け出の遅れに過料を科す予定。TVING に 9 月中に再発防止の計画を出させ、10〜12 月の実施を 2027 年 1 月から点検する。足りない点には是正を命じるとした。
なぜ止まらなかったか
この事案の失敗は、キーが盗まれたことだけではない。本番のキーは、持っている者をそのまま通し、誰のどの作業のための使用かは、使うときに問われなかった。
本番のキーは、持っている者を通した。誰のどの作業のための使用かは、使うときに問われなかった。
ここでいう証明は、本番のキーで影響の大きい操作をする前に「誰の、どの作業のための使用か」を照合し、記録に残すこと。検出は、負荷などの異常から、起きている操作に気づくこと。
仮想サーバが作られた
検出は 1 回目を止めたが、見ていたのは CPU の負荷だけだった。「キーを持っている」と「この人が、この作業のために使う」は別々の事実で、前者を後者と照合する層が無かった。この隔たりが検出と証明の落差であり、構造的な欠落である。
同じ構造は、Studio の事案(データと一緒に、それを復号する鍵も読まれた)にも現れている。
対策するには
本番のキーで影響の大きい操作(仮想サーバの作成、データの一括の読み出しなど)をするときは、そのたびに、誰のどの作業のための使用かを照合する。そうすれば、コードからキーを取られても、申請された作業と結びつかない操作は通らない。検出の代わりではなく、検出の手前に置く層である。
注意したい業界・業務
- 業界メディア・コンテンツ
- 会員と決済の情報を長く持つ動画・音楽の配信サービス。今回のデータベースは 2011 年からの情報を持ち、休眠・退会したアカウントも含んでいた。
- 業界開発者・エージェント運用
- 開発者が多く、キーを手元やコードに置きやすい組織。調査結果では、コードの中の 43 本とは別に、開発者 8 人の端末から開発環境のキー 37 本と本番のキー 52 本が見つかった。
- 業務アカウント・権限の管理
- 開発者とキーに与える権限の範囲と、キーの発行・廃棄の管理。
- 業務照会・参照
- データベースの一括の読み出しと、その ID とパスワードの置き方。
いまの対策で防げるか
| 対策 | 今回 | 理由 |
|---|---|---|
| 漏れたキーの無効化 | 一部 | 分かったキーは止まる。ただ、プロジェクトの中のキーは 43 本あり、2 回目は 1 回目と別のキーが使われた。 |
| CPU の負荷の監視 | 一部 | 1 回目は止めた。2 回目は使用率が 10% 以内にとどまり、警報は出なかった。 |
| 接続元の制限・多要素認証 | 一部 | 調査団は接続を制御する方針が無かったと指摘した。入口は狭まるが、入った後に何に使うかは問わない。 |
| 模擬ハッキング | 一部 | 2024 年にキーの置き方は見つかっていた。見つけることと、使わせないことは別である。 |
- キーをコードに置かず、持ち主と担当に結びつける。開発者のキーは、担当するプロジェクトにだけ届くようにする(調査団の指摘のとおり、必要最小限)。
- 影響の大きい本番の操作は、そのたびに誰のどの作業かを照合してから通す。仮想サーバの作成や、データベースの一括の読み出しは、作業の申請と結びつかなければ、キーが正しくても通さない。通すときも期限を区切る。
- キーの発行と使用を、使う側とは別に残す。誰のどの作業で、どのキーが何をしたかを、後から照合できる形、つまり証明として残す。
開発と本番のキーについて、組織で確認する 3 項目
- ソースコードや設定ファイルに、本番のキーやデータベースのパスワードが平文で残っていないか。
- 開発者のキー 1 本で、すべてのリポジトリに届く設定になっていないか。
- 大量の読み出しや仮想サーバの作成に、負荷の監視のほかにも気づける手段があるか。
注:開発者本人の端末ごと乗っ取られ、作業の申請まで偽装された場合は、この照合を通りうる。最初の開発環境のキーがどう盗まれたかは、調査団も特定できていない。続報で判明すれば、この Brief を改訂する。
Sources
- 一次・政府の調査結果科学技術情報通信部 MSIT「티빙(TVING) 침해사고 조사결과 발표」(TVING 侵害事故の調査結果の発表、2026-09-03)