---
title: "トラスト・ログイン情報漏洩：2,492社・45,030人の原因と利用企業の確認点、公開ストレージを防ぐ実装"
url: "https://www.issoh.co.jp/tech/details/19247/"
published: 2026-11-03
updated: 2026-11-03
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# トラスト・ログイン情報漏洩：2,492社・45,030人の原因と利用企業の確認点、公開ストレージを防ぐ実装

GMOグローバルサインのIDaaS「GMOトラスト・ログイン」で、ロゴ画像を配信するための公開ストレージに顧客情報を含むファイルが置かれ、2017年11月頃から2026年9月15日まで外部から取得できる状態でした。2026年10月30日の第三報で、対象は2,492社・45,030人に確定しています。本記事では、トラスト・ログインを使う企業が知りたい「自社は対象か」「何が漏れたか」「何をすればよいか」に第三報の文言で先に答える構成です。後半では、公式が挙げた原因を実装の単位に分解し、自社のストレージが外から一覧で読めないかを確かめるコマンドと、一時ファイルを署名付きURLで渡すコードを示します。

## まとめ：トラスト・ログイン情報漏洩で確定した事実と利用企業・開発者が今やること

確定している事実は次のとおりです。外部のセキュリティ研究者が2026年9月14日17時48分に脆弱性報告制度で通報し、GMOグローバルサインは同日23時45分頃から翌15日16時にかけて外部からの取得を段階的に遮断しました。調査は10月23日に完了し、第三者による取得が確認されています。ログインパスワード、多要素認証の情報、連携先サービスのパスワード、決済情報は含まれていません。

利用企業が今やることは3つです。GMOからの個別連絡で自社が対象かを確かめること、対象なら個人情報保護委員会への報告を済ませること、契約更新やライセンス超過を装う連絡を社内に警告することです。SaaSを作る側は、公開配信用のストレージに利用者のファイルを置いていないか、認証なしでファイル一覧が取れないかを今週中に確かめてください。

| 項目       | 第三報（2026年10月30日）の内容       |
| -------- | ------------------------- |
| 対象       | 2,492社・45,030人（メール重複除外）   |
| 取得できた期間  | 2017年11月14日頃〜2026年9月15日   |
| 取得を記録で確認 | 2021年6月8日〜2026年9月15日      |
| 原因       | 一時ファイル公開・一覧取得可・リンク署名と期限なし |
| 二次被害     | 10月30日時点で報告なし             |

## 対象と漏えい項目の確認｜2,492社・45,030人の内訳とパスワードを含まない範囲

### 2,184社は一括操作ファイル・217社は請求先のみという3つの区分

[第三報](https://news.trustlogin.com/20261030)は、対象企業を3つに分けています。管理画面の一括操作で作られたファイルの個人情報を取得された企業が2,184社、請求送付先担当者の情報だけを取得された企業が217社、管理者アカウントの削除などで特定できない企業が91社です。人数は、一括操作ファイルに含まれる人が44,836人、請求送付先担当者が194人です。

自社が対象かどうかは、GMOからの個別連絡で分かります。[9月16日の第一報](https://news.trustlogin.com/20260916)の時点で、対象の管理者への個別連絡が始まっています。管理者が退職していると連絡が届かない場合があるため、問い合わせ窓口（03-4545-2303、平日10時〜18時）に企業IDを伝えて確かめるのが確実です。

### 第一報の2,007社・37,747人から増えた理由と件数の読み方

第一報の暫定値は2,007社・37,747人でした。第三報で増えた理由として、初回の調査で調べるべきファイルが足りなかったことと、判定条件に誤りがあったことが挙げられています。あわせて、請求送付先担当者の情報だけを取得された企業と、所属企業を特定できない管理者アカウントが新たに対象に入りました。

第一報で「対象外」と受け止めた企業も、第三報の時点で改めて確かめる必要があります。取得を記録で確認できたのは2021年6月8日以降で、それより前はアクセス記録がありません。GMOは2017年11月から2021年6月7日までも取得された恐れがある期間として扱っています。

### 漏えいした項目と含まれていない項目｜社員番号や所属が入りうるカスタム属性

一括操作ファイルに含まれていたのは、メールアドレス、氏名、対象アプリ名、カスタム属性値です。カスタム属性は企業が独自に設定する欄で、第三報は例として社員番号と所属を挙げています。契約情報ファイルには、企業ID、ライセンス数、利用状況、解約日、請求送付先担当者の氏名・住所・電話番号・メールアドレスが含まれていました。

見落としやすいのは「対象アプリ名」です。社員のメールアドレスと、その社員がシングルサインオンで使っているSaaSの名前が組で漏れたことになります。攻撃者にとって、その組は実在するSaaSの名前を使った偽の通知を作るための材料です。パスワードが漏れていなくても、偽のログイン画面に誘導されれば認証情報を入力してしまいます。IDaaSの仕組みと連携の構造は[IDaaSとは](https://www.issoh.co.jp/tech/details/16401/)で解説しています。

## 原因の技術的な分解｜ロゴ配信用の公開領域に置いた一時ファイルと署名なしリンク

### ロゴ画像の配信負荷対策で2017年に公開領域へ変えた保存先の問題

第三報によれば、2017年11月頃、ロゴ画像の配信負荷を下げるために、保存先のストレージを外部から閲覧できる公開領域に変更しました。ロゴは誰に見られてもよいデータです。問題は、同じ保存先に管理画面の一括操作で作られたひな形やエラーファイル、契約情報ファイルも置かれていたことでした。

第一報は「外部からの攻撃やシステムへの侵入によるもの」ではないと説明しています。認証を破られたのではなく、公開された場所に読める状態で置かれていたファイルを取得された事案です。GMOはクラウド事業者名を公表していません。本記事では一般的な例としてAmazon S3の設定を示しますが、本件がS3だったという意味ではありません。

### ファイル一覧の外部取得と署名・有効期限のないリンクが重なった構造

公開領域に置いただけなら、ファイル名を知らない第三者はたどり着けません。今回は、公開領域のファイル一覧を外部から取得できる設定でした。一覧が取れれば、ファイル名を推測する必要はありません。加えて、ファイルへのリンクには署名も有効期限もありませんでした。一度知られたリンクは、何年たっても使えます。

4つ目の原因として、定期診断の対象がアプリケーションとサーバーで、ストレージが入っていなかったことが挙げられています。9年近く気づかれなかったのはこのためです。設定の不備は単独では小さく見えても、「公開領域」「一覧取得」「期限なしリンク」「診断対象外」が重なると、外部の研究者が通報するまで誰も止められません。

### 9月16日の署名付きリンクから10月6日の一覧停止までの対応順

実施済みの対策は次の順です。

1. 9月16日：ダウンロードリンクを署名付き・有効期限1時間に変更
2. 9月24日：保存場所に残っていた個人情報を含むファイルを削除
3. 9月25日：該当の保存場所でファイル一覧の外部取得を停止
4. 10月2日：全保存場所を棚卸しし、常時監視と自動通知を導入
5. 10月6日：すべての保存場所でファイル一覧の外部取得を停止

今後の対策として、原則非公開の構成への変更、公開領域に置いてはいけないファイルの自動確認、データの種類ごとの保存期間と期限切れファイルの自動削除を2026年11月30日までに行うとしています。ファイル処理の共通部品化だけは2027年1月31日が期限です。外部診断は年2回とし、対象をクラウド環境全体と公開資産全体に広げます。

## 自社のストレージを点検するコマンド｜公開設定と認証なしの一覧取得を確かめる

### 公開ブロック4項目とバケットポリシーの公開判定を読む2つのAPI

Amazon S3には、公開を一括で止める[ブロックパブリックアクセス](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html)があります。項目は`BlockPublicAcls`・`IgnorePublicAcls`・`BlockPublicPolicy`・`RestrictPublicBuckets`の4つで、AWSはアカウント単位とバケット単位の両方で4つとも有効にすることを推奨しています。新しいバケットは既定で公開されませんが、後からバケットポリシーやACLで公開に変えることは可能です。今回のように「配信負荷対策で公開に切り替えた」保存先は、この既定から外れています。

次のコマンドは、1つのバケットについて、公開ブロックの設定、バケットポリシーが公開と判定されているか、認証なしでファイル一覧が取れるかを順に確かめます。AWS CLI v2で実行します。

```
# 1. 公開ブロック4項目がすべて true か
aws s3api get-public-access-block --bucket example-logo-assets

# 2. バケットポリシーが公開と判定されているか（IsPublic が true なら公開）
aws s3api get-bucket-policy-status --bucket example-logo-assets

# 3. 認証情報を付けずに一覧を取る（外部の第三者と同じ条件）
aws s3 ls s3://example-logo-assets/ --no-sign-request
```

3つ目の`--no-sign-request`は、署名を付けずに要求を送るオプションです。非公開のバケットならアクセス拒否のエラーが返ります。ファイル名が並んだら、今回と同じ状態です。設定値を読むだけの1と2よりも、3の結果のほうが判断を誤りません。

### アカウント単位で公開ブロック4項目を有効にする前に公開配信を移す順番

全バケットの公開を一度に止めるには、アカウント単位で4項目を有効にします。

```
aws s3control put-public-access-block \
  --account-id 123456789012 \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
```

ただし、ロゴのように公開で配信している画像があると、このコマンドで表示されなくなります。先に配信をCloudFrontへ移し、[オリジンアクセスコントロール（OAC）](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html)でCloudFrontからだけ読めるようにしてから有効にします。この構成なら、バケットは非公開のままで、画像だけを配信できる仕組みです。設定の手順は[CloudFront OACとは](https://www.issoh.co.jp/tech/details/3684/)にまとめました。ストレージの仕組み全体は[Amazon S3とは](https://www.issoh.co.jp/tech/details/15433/)で扱っています。

## 一時ファイルを公開領域に置かない実装｜非公開バケットと有効期限1時間の署名付きURL

### 公開配信用と利用者ファイル用でバケットを分けるという設計の起点

今回の根は、ロゴと顧客のファイルが同じ保存先にあったことです。公開してよいデータと、利用者ごとに見せる相手が違うデータは、バケットから分けます。公開配信用のバケットにはロゴや静的ファイルだけを置き、アプリケーションが書き込む一時ファイルは非公開のバケットに置きます。アプリケーションに書き込み権限を付ける対象も、非公開のバケットだけです。公開配信用のバケットに書き込めなければ、実装の誤りで顧客のファイルが紛れ込むこともありません。

### 権限確認のあとに有効期限1時間の署名付きURLを発行するPython

一括操作のエラーファイルのように、管理者に一度だけ渡せばよいファイルは、[署名付きURL](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html)で渡します。署名付きURLは、発行した人の権限で、期限付きの読み取りを許すURLです。次のコードは、推測できないキーでファイルを保存し、要求した人がそのテナントの管理者かを確かめてから、1時間で切れるURLを発行する例です。boto3を使います。

```
import uuid
import boto3

s3 = boto3.client("s3", region_name="ap-northeast-1")
BUCKET = "example-tenant-files"  # 非公開。公開ブロック4項目を有効にしたバケット


def save_error_file(tenant_id, body):
    # 推測できないキーにして、テナントごとのプレフィックスに置く
    key = f"tmp/{tenant_id}/{uuid.uuid4()}.csv"
    s3.put_object(Bucket=BUCKET, Key=key, Body=body, ServerSideEncryption="AES256")
    return key


def download_url(user, key):
    # URLを発行する前に、要求者がそのテナントの管理者かをアプリ側で確かめる
    if not user.is_admin or not key.startswith(f"tmp/{user.tenant_id}/"):
        raise PermissionError("このファイルを取得する権限がありません")
    return s3.generate_presigned_url(
        "get_object",
        Params={"Bucket": BUCKET, "Key": key},
        ExpiresIn=3600,  # 1時間で失効させる
    )
```

期限は秒で指定します。[AWS CLIのpresign](https://docs.aws.amazon.com/cli/latest/reference/s3/presign.html)では既定が3600秒、上限が604800秒（7日）です。GMOが9月16日に変えた「有効期限1時間」は、この既定と同じ長さです。権限の確認はURLを発行する前に行います。署名付きURLは、手に入れた人なら誰でも期限内は使えるからです。Google Cloud Storageにも同じ役割の[署名付きURL](https://cloud.google.com/storage/docs/access-control/signed-urls)があり、考え方は共通です。

### ライフサイクル設定で非公開の一時ファイルを1日後に自動で消す設定例

今回は2017年から2026年までファイルが残っていました。署名付きURLの期限が切れても、ファイルそのものは残ります。一時ファイルは、[ライフサイクル設定](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)で作成から1日後に消えるルールを付けるのが確実です。次の内容をlifecycle.jsonとして保存します。

```
{
  "Rules": [
    {
      "ID": "expire-tmp-files",
      "Filter": { "Prefix": "tmp/" },
      "Status": "Enabled",
      "Expiration": { "Days": 1 }
    }
  ]
}
```

```
aws s3api put-bucket-lifecycle-configuration \
  --bucket example-tenant-files \
  --lifecycle-configuration file://lifecycle.json
```

期限を過ぎたファイルは、S3が非同期に削除します。削除が実行されるまで少し時間差があるため、厳密に消した時刻を記録したい場合はアプリケーション側でも削除し、その時刻を記録してください。保存したファイルに個人情報が残っていないかを機械的に探すなら[Amazon Macieとは](https://www.issoh.co.jp/tech/details/15886/)、全アカウントの公開設定を継続して監視するなら[CSPMとは](https://www.issoh.co.jp/tech/details/16228/)が次の手になります。

## 利用企業の対応｜個人情報保護委員会への報告と契約更新を装う連絡への備え

### 利用企業にも報告が要るとした10月7日の続報と個人情報漏えいの確報の期限

[10月7日の続報](https://news.trustlogin.com/20261007-1)は、サービスに情報を預けている利用企業にも、個人情報保護委員会への報告が必要だと案内しています。GMOは同日から、報告に関する案内のメール送付を始めました。社員のメールアドレスや氏名を預けているのは利用企業で、利用企業はその個人データを扱う事業者として報告の当事者になります。

期限は[個人情報保護委員会の「漏えい等の対応とお役立ち資料」](https://www.ppc.go.jp/personalinfo/legal/leakAction/)に示されています。速報は発覚から3〜5日以内、確報は30日以内で、不正な目的で行われたおそれがある場合は60日以内です。第三報は、第三者による取得を不正目的の恐れがあると判断しています。GMO自身は11月12日に確報を出す予定です。報告の主体と流れは[個人情報保護委員会への報告義務](https://www.issoh.co.jp/column/details/17840/)で整理しました。

### 契約更新やライセンス超過を装う連絡を見分ける社内向けの3つの規則

GMOは、契約更新、ライセンス超過、アカウント確認などを装ってIDやパスワードの入力や送金を求める連絡に注意するよう呼びかけています。漏れたのは請求送付先担当者の連絡先と、ライセンス数や解約日です。「ライセンス数が超過しています」「解約に伴う精算です」という連絡は、受け取った人にとって事実に見えます。

- GMOはメールや電話でパスワードなどの認証情報を尋ねないと明記しているため、尋ねる連絡はすべて偽物として扱う
- 振込先の変更や追加請求は、メールに書かれた番号ではなく、契約書に記載の窓口に電話で確かめる
- 連携しているSaaSの名前を出した通知は、メールのリンクではなくブックマークからログインして確かめる

3つ目は、対象アプリ名が漏れた今回ならではの規則です。経理担当と管理者だけでなく、一括登録の対象になった社員全員に共有します。偽の通知の手口は[フィッシング詐欺とは](https://www.issoh.co.jp/tech/details/13548/)で解説しています。

## 今月中にストレージを点検すべきサービスと次回の定期診断でよいサービス

### 利用者がアップロードや一括処理をするSaaSは今月中に点検する

CSVの一括登録、帳票の出力、エラーファイルのダウンロードなど、利用者のデータからファイルを作る機能を持つSaaSは、今月中に点検してください。確かめるのは、そのファイルがどのバケットに、いつまで置かれ、どのリンクで渡されているかの3点です。公開配信用のバケットに一度でも書き込んでいれば、今回と同じ構造です。定期診断の範囲にストレージが入っていない場合も、同じ扱いにします。

アプリケーション、クラウドの設定、外から到達できる保存先までを第三者の目で洗い出したいときは、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で点検できます。APIの認可やトークンの失効まで見直すなら[API不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)も参考になります。

### 静的な公開ファイルしか置かず4項目を有効にしているなら定期診断でよい

公開しているのが静的なWebサイトの画像やCSSだけで、利用者のデータを保存先に書き込む機能がなく、アカウント単位で公開ブロック4項目を有効にしているなら、次回の定期診断で構いません。今回の対策で先に効くのは、診断の対象にストレージを含めることです。GMOも、外部診断の対象をクラウド環境全体と公開資産全体に広げるとしています。

## よくある質問

GMOトラスト・ログインの情報漏洩について、利用企業の管理者とSaaSの開発者から出やすい質問をまとめました。

### トラスト・ログインのパスワードを変える必要はありますか？

第三報では、GMOトラスト・ログインのパスワード、秘密の質問と回答、多要素認証の情報、連携サービスのパスワードは含まれていないとされています。漏えいを理由にパスワードを変える必要は、公式発表の上ではありません。注意すべきは、漏れたメールアドレスと対象アプリ名を使った偽のログイン画面への誘導です。リンクからではなく、ブックマークからログインしてください。

### 自社が対象かどうかはどうすれば分かりますか？

GMOから管理者へ個別に連絡が届いています。管理者の交代や退職で連絡が届いていない可能性がある場合は、問い合わせフォームか電話（03-4545-2303、平日10時〜18時）で確かめてください。第一報の暫定値から対象が増えているため、9月の時点で連絡が無かった企業も、第三報の後に確認するのが確実です。

### なぜ9年近くも気づかれなかったのですか？

第三報は、定期診断の対象がアプリケーションとサーバーで、ストレージが入っていなかったことを原因の1つに挙げています。また、取得の記録が残っているのは2021年6月8日以降で、それ以前のアクセスは追えません。発覚のきっかけは、2026年9月14日の外部研究者からの脆弱性報告でした。

### お名前.com デスクトップクラウドの不正アクセスと関係がありますか？

どちらもGMOインターネットグループの事業ですが、別の事案です。トラスト・ログインは保存先の設定不備による漏えいで、お名前.com デスクトップクラウドは侵入による不正アクセスです。トラスト・ログインの第三報は、デスクトップクラウドの事案に触れていません。デスクトップクラウドの経緯は[お名前.com デスクトップクラウドの不正アクセス](https://www.issoh.co.jp/tech/details/18761/)で整理しています。

### 署名付きURLにすれば公開領域に置いても安全ですか？

安全になりません。署名付きURLは、非公開のバケットにあるファイルを期限付きで読ませる仕組みです。バケット自体が公開で一覧も取れる状態なら、署名の有無に関係なくファイルを取得されます。非公開のバケットに置く、権限を確かめてから短い期限で発行する、ライフサイクルで消す、の3つを組み合わせて初めて今回の原因を塞げます。

## 関連記事

- [お名前.com デスクトップクラウドの不正アクセス：11月2日の会見で判明した8月の侵入とMT4口座・自分のPCで今すること](https://www.issoh.co.jp/tech/details/18761/)：同じGMOグループで起きた別の事案と、利用者の確認点
- [CSPMとは？設定ミス検出の仕組みとCNAPPとの違い・導入判断を実装視点で解説](https://www.issoh.co.jp/tech/details/16228/)：公開設定の誤りを継続して検出する仕組み
- [CloudFront OAC（オリジンアクセスコントロール）とは？OAIとの違いとS3バケットポリシー設定手順](https://www.issoh.co.jp/tech/details/3684/)：バケットを非公開のまま画像を配信する設定
- [IDaaSとは？SSO・IdPとの違いとSAML・OIDC・SCIM連携を実装視点で解説](https://www.issoh.co.jp/tech/details/16401/)：トラスト・ログインと同じ種類のサービスの仕組み
- [個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務](https://www.issoh.co.jp/column/details/17840/)：利用企業が行う報告の手順

---

出典: [トラスト・ログイン情報漏洩：2,492社・45,030人の原因と利用企業の確認点、公開ストレージを防ぐ実装](<https://www.issoh.co.jp/tech/details/19247/>)（株式会社一創）