18万件の会議。1つの会議に5人が参加していたとすれば、90万人分に相当する会話データです。営業交渉、採用面接、人事評価、会社の戦略会議、さらには政府機関の作業部会まで。それらはあるAI会議記録ツールのクラウドデータベースに保存されていましたが、そのデータベースの「鍵」は開いたままでした。無料アカウントを1つ作成するだけで、誰でも18万件もの会議記録を検索でき、さらには現在進行中のリアルタイム会議のリンクを入手してそのまま「飛び入り参加」することさえ可能な状態でした。セキュリティ研究者の Bob Diachenko 氏が実際に試したところ、157名が参加していたマレーシア教育省のオンライン会議に、誰からの招待もなくそのまま足を踏み入れることができました。その会議は、まさに録音中でした。
他人の秘密を守ることで成り立っている企業
問題の企業は tl;dv（「Too Long; Didn’t View（長すぎて見ていられない）」の略称）。Zoom、Google Meet、Microsoft Teams などの会議にボットを参加させ、全編の録音、文字起こし、AIによる要約生成を行うサービスです。200万人以上のユーザーを抱え、ベンチャーキャピタルの出資を受け、LinkedIn の営業コミュニティでも広く推奨されているツールです。
営業電話、採用面接、人事評価、社内戦略会議——ユーザーはあらゆる重要情報をここに保存していました。「この会議は録音されます」という通知音が鳴り、参加者が苦笑いを浮かべた後、45分間にわたって商業機密を語り合う、まさにあの会話の内容です。
脆弱性はなぜ生じたか：ハッカーではなく「鍵のかかっていないドア」
まず明確にしておくべきは、これが高度なサイバー攻撃ではなかった点です。パスワードの解析も、高度なゼロデイ脆弱性の悪用もなく、攻撃者は「破る」というプロセスすら不要でした。
問題はデータベースのアクセス制御（鍵）にありました。Google の Firestore のようなクラウドデータベースには、「各ユーザーは自分のデータのみアクセスできる」という原則（技術用語でマルチテナント隔離）があります。しかし、tl;dv のデータベースにはこの隔離レイヤーが存在していませんでした。マンションに例えるなら、本来は各部屋に個別の鍵がかかっているべきところを、建物全体に1つのロビーしかなく、ロビーに全部屋の番号、居住者のメールアドレス、どの部屋が今会議中かまで記載された大帳簿が置かれていたようなものです。無料アカウントを作成した住人なら誰でもその帳簿をめくり、部屋番号を見てドアをノックできる状態でした。
図：研究者が確認した会議記録の一覧。ログインユーザーであれば誰でも全記録を検索可能だった。出典：bobdahacker.com
研究者が集計したところ、データベース内には 35,003 の企業ドメインに属する 84,312 名のユーザーの会議記録、計 181,874 件が残されていました。23カ国の政府機関の会議、カリフォルニア大学バークレー校や東京大学などの教育機関、三井物産や HubSpot といった大企業の会議も含まれていました。最も増加した昨年7月には、単月で43,209件の会議が新規保存されていました。
さらに深刻だったのはリアルタイム領域です。常時約1,000件の会議が録音中であり、その参加リンクがデータベース内にそのまま置かれていたため、スクリプトを書けば自動で一括参加できる状態でした。研究者がマレーシア教育省の157名の会議にアクセスした際、画面ではプレゼンテーションが行われており、参加者一覧には tl;dv 自身のボットも並んでいました。
図：研究者が招待なしに参加したオンライン会議。157名が参加中で、録音が継続されていた。出典：bobdahacker.com
攻撃者にとって、このデータの価値はテキスト形式の要約にとどまりません。音声そのものに大きな価値があります。ディープフェイク音声による詐欺対策に携わる専門家はコメント欄で、「社員の本物の音声サンプルがあれば、AIを使ってその人物の声を取り counterfeit し、財務担当者に電話をかけて送金を指示することができる。今回の漏洩は、数万人分の『声紋』を全世界に配布したようなものだ」と指摘しています。
会議記録の中に隠されていたもの
1つの会議には何が含まれているでしょうか。給与交渉、リストラ対象者リスト、M&A計画、法的トラブル、顧客への提示下限価格。政府機関の会議では安全保障に関わる内容も含まれます。漏洩リストにはウクライナのデジタル変革省の会議記録も含まれており、掲示板では「ロシアが見ていることをウクライナ側は把握しているのか」と懸念する声が上がりました。また、研究者がアクセスした別の会議では、アメリカの大学の学生起業チームが画面共有でプロトタイプのデモを行っていました。彼らがメール認証機能の実装について議論しているのを聞きながら、研究者は「どうか自分たちのデータベースの権限設定も正しくやってくれ」と心の中で祈ったといいます。
図：研究者が確認したもう一つの会議。学生チームが画面共有でプロジェクトのデモを行っていた。出典：bobdahacker.com
さらに、ユーザーによって「公開」設定にされていた会議も1,000件以上あり、録音データや文字起こしを直接閲覧できる状態でした。そこにはブラジル政府の環境保護に関する会議（WWF や Nature Conservancy も参加）や、HubSpot の営業電話が含まれていました。また、228のドメインにわたる 715 名分の参加者メールアドレスも露出しており、フィッシング攻撃の絶好のターゲットリストとなっていました。
企業の対応：半年の沈黙の末の「公開データ」主張
技術コミュニティが最も憤りを感じたのは、問題発覚後の企業側の対応でした。研究者は1月28日に LinkedIn 経由で tl;dv に連絡を取り、数分後に「ご指摘ありがとうございます！CTO に送ってください」との返信を受け取りました。しかし、その後 CTO からの返信は一切ありませんでした。2月、3月、7月と研究者が追跡連絡を行っても、データベースは開かれたままでした。8月初旬に調査レポートが公表され、メディアが報道を開始して初めて、同社は数日以内に修正を行い、公式見解を発表しました。
その公式説明の中で最も物議を醸したのが、「暴露されたデータは厳密にメタデータに限られており、録音や文字起こしが漏洩したことはない」「閲覧可能だったのはユーザーが明示的に公開を選択した会議であり、これらはパブリックデータに該当する」という主張でした。コミュニティからは批判が殺到しました。研究者は実際に1,000件以上の公開設定会議の全内容を取得できており、ユーザーも「リンクで共有」にチェックを入れた際に、全世界から検索可能になるとは想定していなかったからです。さらに皮肉なことに、同社の CEO は数ヶ月前の公開インタビューで「欧州企業はデータ、セキュリティ、プライバシーをより重視しており、初日から製品にコンプライアンスを組み込んでいる」と語っており、その発言が今回の議論スレッドにそのまま引用される事態となりました。
業界のセキュリティ認証は、一体何をチェックしていたのか
ここでタイトルの疑問に戻ります。「認証」とは何だったのか。同社のウェブサイトのセキュリティページには、SOC 2 認証、GDPR 準拠、AES-256 暗号化といったバッジがトロフィーのように並んでいます。事故の発覚後、技術フォーラムで最も多く聞かれたのは「これらの認証には何の意味もない」という声でした。
セキュリティ認証とは実際に何を審査するものなのでしょうか。端的に言えば、「セキュリティ方針が文書化されているか」および「その文書通りに行動していると証明できるか」です。審査対象に含まれないのは、「方針自体の妥当性」「データベースの鍵がかかっているか」「製品が本当に安全か」といった実効性です。例えるなら、「自分が書いたルールに従って解答しているか」だけを採点し、答えの正誤は問わない試験のようなものです。「1+1=3」と書き、その通りに計算していることを証明できれば合格となります。飲食店に例えれば、衛生検査員が『厨房衛生マニュアル』の掲示と履行を確認するだけで、マニュアルの内容が「毎日掃除する」なのか「開店前に一度掃除する」なのかは問わず、実際の調理場の汚れもチェックしないような状態です。
ある実務者が掲示板で明かしたエピソードは、この状況を象徴しています。彼が所属する会社は認証を取得するため、社用PCに「コンプライアンス監視ソフト」を入れるよう命じられました。彼は言われた通りにインストールした後、そのPCを脇に置き、個人のPCで業務を続けました。「認証は何の支障もなく通過した」といいます。また別のユーザーは、同様の認証を掲げる別のツールで、チャット履歴がベンダーのサーバーに強制アップロードされ、1クリックで公開できる仕様になっていた体験を報告しています。認証制度が証明するのは「言った通りにやっているか」であり、問題は常に「言っている内容そのものに価値があるのか」という点にあります。
信頼とコンプライアンスに関する考察
今回の事故において、技術的な構造自体は決して複雑なものではありません。複雑なのは、損なわれた「信頼」の回復です。ユーザーは会議室での最もプライベートな会話をツールに託し、ツールはそれを鍵のない棚に放置しました。ユーザーは認証バッジを安全の誓約だと信じ、認証制度は「手続きが揃っていること」だけを保証していました。データベースの穴は塞ぐことができ、Firebase の設定もやり直すことができますが、「認証」という言葉に対して人々が抱いた不信感を拭い去るには、長い時間がかかるでしょう。
筆者としては、いずれの側にも断定的な結論を下す意図はありません。企業側は「2つの独立した脆弱性があり、1つ目は早期に修正済みだった」と主張し、研究者側は「6ヶ月間にわたりレスポンスがなく、データベースは開いたままだった」と記録しており、両者の主張には食い違いが存在します。読者の皆様におかれましては、それぞれの原文を参照の上、ご判断いただければ幸いです。ただ、次にオンライン会議で「この会議は録音されます」というアナウンスが流れたとき、一歩立ち止まって考えてみる価値はあるかもしれません——その会議を記録しているツールは、あなたの声を預けるのにふさわしいものですか？
参考リンク：
- Bob Diachenko：Tl;dv 漏洩調査レポート
- Hacker News 議論スレッド（HN）
- tl;dv 公式回答記事『Our thoughts on the darkreading.com article』
- Dark Reading 報道『AI Notetaker Exposes Government, Corporate Video Calls』
- SourceFeed 分析『One Missing Firestore Rule Exposed 181,874 Meetings』
