要点
- GMOグローバルサインの企業向けログインサービス「GMOトラスト・ログイン」で、2,492社・45,030人分の氏名やメールアドレスなどが外から取れる状態だった。
- 原因は、ロゴ画像を置く「誰でも見られる場所」に、顧客情報を含むファイルも置かれていたことで、約9年間そのままだった。
- 会社は、ファイルが第三者に取得されていたことを確かめており、仕事の連絡を装った詐欺メールに注意するよう求めている。
何が起きたか
GMOトラスト・ログインは、1つのIDとパスワードで社内のいろいろなクラウドサービスに入れるようにする仕組み(シングルサインオン)だ。運営する GMOグローバルサインが、2026年10月30日に第三報を出した。
第三報によると、ロゴ画像を外へ配るための公開の保存場所(ストレージ)が、顧客情報を含む一時ファイルの置き場も兼ねていた。会社は、これを設計の問題として挙げている。置かれたファイルのリンクには、署名(決まった相手だけが使えるようにする印)も使える期限もなかった。保存場所の中身の一覧も、外から取れた。その結果、第三者がファイルを見たり取ったりできた、と会社は説明している。この保存場所を公開にしたのは2017年11月14日ごろで、会社はロゴ配信の負荷への対策だったとしている。
外から取れる状態だったのは、2017年11月14日ごろから2026年9月15日まで。2026年9月14日に、外部のセキュリティ研究者が脆弱性の報告制度を通じて知らせ、発覚した。会社は9月14日23時45分ごろから9月15日16時にかけて、段階的に取得を止めた。
会社の発表では、2,492社の内訳は次のとおりだ。いちばん多いのは、管理者がメンバーの一括追加やパスワードの一括設定をしたときに自動でできたファイルで、2,184社・44,836人分にあたる。中身は、メールアドレス、氏名、連携するサービスの名前と、利用企業が独自に決めた項目(社員番号や所属など)だ。このほか、GMOグローバルサインが持つ契約の記録から、請求書の送り先担当者の氏名・住所・電話番号・メールアドレスが取られた企業が217社ある(人数は、一括操作のファイルと重ならない分で194人)。契約の記録には、企業ID、ライセンス数、利用状況、解約日も入っていた。残る91社は、管理者アカウントの削除などで、どの企業か特定できなかった分だ。
含まれていないと会社が説明しているのは、ログインのパスワード、秘密の質問、多要素認証の情報、連携先のパスワード、クレジットカードの情報だ。
外部の専門機関の調査を受け、会社は「これらのファイルが第三者に取得されていたことを確認しました」と書いている。会社が記録で取得を確かめた期間は、2021年6月8日から2026年9月15日までだ。公開が始まった2017年11月からそれまでの約3年半はログが残っていない。会社は、この期間についても被害がなかったとは言えないものとして扱っている。
数は、9月16日の第一報の2,007社・37,747人から増えた。増えた分には、第一報では数えていなかった2種類が加わっている。請求書の送り先担当者の情報が取られた企業と、どの企業に属するか分からない管理者アカウントだ。あわせて会社は、最初の調査で調べたファイルが足りず、判定の条件にも誤りがあったと明かし、調べ直している。10月30日の時点で、二次被害の報告はないという。
日本の利用者への影響
会社の発表では、対象は2,492社・45,030人分だ。この中には、どの企業か特定できない91社や、契約の記録から担当者の情報が取られた企業も入っている。第三報が一括操作のファイルの項目として挙げているのは、メールアドレス、氏名、連携しているサービスの名前、企業が独自に設けた項目だ。この独自の項目に、社員番号や所属が入っている企業もある。こうした情報があると、「誰が、どのサービスを使っているか」に合わせた、本物らしい偽メールを作りやすくなる。会社は9月16日から、対象企業の管理者に個別に連絡しているとしている。
今すぐやること
- 自社が GMOトラスト・ログインを使っているなら、管理者に会社からの個別の連絡が来ているかを確かめる。分からなければ問い合わせ窓口に聞く。
- GMOグローバルサインの名前や契約の話を持ち出して、ログイン情報の入力や送金を迫る連絡が来たら、まず疑う。会社も、こうした偽の連絡に注意するよう呼びかけている。心当たりがなければ、リンクや添付ファイルは開かず、返信もしない。
- 会社は「メールや電話でパスワードなどの認証情報をお伺いすることはございません」としている。そうした連絡が来たら偽物と考え、社内のセキュリティ担当に知らせる。
- 管理者は、会社の求めのとおり、この件をメンバーにも伝える。連携しているサービスの名前を使った偽のログイン画面にも気をつけるよう呼びかける。
- 自社でクラウドのストレージを使っているなら、公開の設定になっている場所と、そこに何が置かれているかを、担当者に確かめてもらう。
背景
ロゴのように誰に見られてもよいファイルと、顧客の情報を同じ場所に置いたことが、今回の根っこだ。約9年も見つからなかったわけについて、会社は点検の範囲を挙げている。ファイルの置き場は、定期の診断や侵入テストから外れていた。診断の対象になっていたのは、アプリケーションとサーバーだった。
クラウドのストレージを公開の設定にしたまま、中に置いてはいけないファイルが入っていた、という漏えいは国内外でくり返し起きている。一度公開にした場所は、あとから追加された機能のファイルまで公開してしまう。会社は再発防止として、原則は非公開にし、公開するものは配信専用の仕組みだけを通すと書いている。
技術者向けの詳細
- 一次情報: 第三報(2026-10-30)、第一報(2026-09-16)、第二報(2026-10-07)。使っていたクラウドの名前は書かれていない
- 原因として挙げられたもの: ロゴ配信用の公開領域に、顧客情報を含む一時ファイルが保存される設計だった/ファイル一覧が外から取れた/オブジェクトの URL に署名も期限もなかった/診断の範囲にストレージが入っていなかった
- 会社が実施済みとする対策: 9月16日 ダウンロード用リンクを署名付き・有効期限1時間に変更。9月24日 該当ファイルを削除。9月25日・10月6日 一覧の外部取得を不可に。10月2日 保存場所の棚卸しと設定の常時監視・自動通知を導入
- 予定: 2026年11月30日までに原則非公開の構成、公開領域の自動点検、顧客情報を含むファイルや一時ファイルの保存期間を決めた自動削除。ファイル処理の共通部品化(新機能での利用必須)は2027年1月31日まで。個人情報保護委員会への確報は11月12日の予定
- 継続して実施するもの: 外部の専門機関による診断を年2回。対象を Web アプリ、クラウド環境全体、外部に公開しているすべての資産に広げる
- 自社のクラウドを見直すときの一般的な観点(今回の会社の環境についての記述ではない):
- アカウント全体で公開を止める設定を使う(AWS S3 の Block Public Access、Google Cloud Storage の公開アクセス防止、Azure Storage の匿名アクセス無効化)
- 公開が要るバケットは用途ごとに分け、公開用には決めた種類のファイルだけを置く。CDN 経由で出し、バケットそのものは非公開にする
- 一覧の取得(List)を匿名に許していないか、ポリシーと ACL を確かめる
- 利用者へのダウンロードは、期限の短い署名付き URL で渡す
- 一時ファイルにはライフサイクルの設定で自動削除の期限を付ける
- アクセスのログ(サーバーアクセスログ・データアクセスの監査ログ)を有効にし、保存期間を十分にとる。今回は2021年6月7日以前の記録がなく、取得の有無を確かめられなかった
- 例: AWS CLI で
aws s3api get-public-access-block --bucket <名前>を使い、公開を止める設定が有効かを確かめられる


