---
title: "ハノワ情報漏洩：本人確認書類も閲覧可能だった4.9万人分の範囲とクラウド設定の点検"
url: "https://www.issoh.co.jp/tech/details/18829/"
published: 2026-10-24
updated: 2026-10-24
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# ハノワ情報漏洩：本人確認書類も閲覧可能だった4.9万人分の範囲とクラウド設定の点検

歯科医療人材マッチングサービス「ハノワ」を運営する株式会社HANOWAは2026年10月19日、クラウド上の保存領域で閲覧制限の設定が適切でなく、利用者の個人情報と提出書類の画像が第三者から閲覧できる状態だったと公表しました。対象は重複を除いて最大4万9,309人で、本人確認書類・免許証や口座確認書類の画像も含まれます。前半で整理するのは、公式発表で確認できる範囲・期間と、登録している歯科衛生士や歯科医院がとる対応です。後半は開発者向けに、公表された原因と同じ形の設定ミスをS3やCloud Storageで点検するコマンドを示します。

## まとめ：ハノワ情報漏洩で公表された範囲・期間と利用者が取る対応

閲覧できる状態は2019年6月から2026年10月16日まで、約7年4か月続きました。閲覧の記録が残っておらず、実際に誰かが見たかを確かめられないため、同社は「漏えいのおそれ」として公表しています。

| 項目      | 公表内容（10月20日更新版） |
| ------- | --------------- |
| 対象者     | 重複を除き最大49,309名  |
| 書類画像    | 最大10,311名分      |
| 閲覧可能な期間 | 2019年6月〜10月16日  |
| 原因      | 保存領域の閲覧制限の不備    |
| 対象外     | パスワード・カード情報     |
| 被害の報告   | 公表時点で受けていない     |
| 対象者への連絡 | 登録メールへ個別に送付     |

登録者がまず確かめるのは、登録メールアドレスに同社からの個別連絡が届いているかです。届いていれば、ハノワを装う電話やメールに注意し、本人確認書類の悪用に備えて信用情報機関への本人申告を検討します。開発者にとっての論点は、ログインした利用者なら誰でも読める保存領域の規則と、閲覧の記録を取っていなかった運用の2つです。

## 公式発表で確かめるハノワ情報漏洩の対象者4万9,309人と閲覧可能期間

### 氏名・書類画像・旧チャットの3区分に分かれる最大4万9,309人の内訳

[HANOWAの公式発表](https://hanowa.co.jp/3fe09d1d0be580f88364c519d5196b72)は、漏えいのおそれがある情報を3つの区分に分けています。

- 氏名・ニックネーム・メールアドレス・医院名：最大47,683名分
- 本人確認書類・免許証の画像と口座確認書類の画像：最大10,311名分（2019年6月から2025年12月に提出した人）
- 旧チャット機能（2024年10月まで提供）のメッセージと添付ファイル：最大15,482名分

3つを足すと7万人を超えますが、同じ人が複数の区分に入るため、重複を除いた対象者は最大4万9,309名です。書類画像の区分は、2026年に入ってから書類を出した人は含まれていません。公式発表は「本人確認書類・免許証」とだけ書いており、運転免許証なのか歯科衛生士免許などの資格の免許証なのかは明示していません。

### 2019年6月のログイン利用者から2020年6月18日の第三者へ広がった期間

閲覧できた相手は、時期によって2段階に分かれます。2019年6月から2020年6月17日までは、ハノワにログインした他の利用者から閲覧できる状態でした。2020年6月18日から2026年10月16日までは、ログインしていない第三者からも閲覧できる状態です。

同社は、通常の画面操作でこれらの情報が表示されることはなく、閲覧には技術的な知識を要する操作が必要だったと説明しています。保存先のアドレスを知っていれば外から直接読める状態だった、と読めます。この2段階の広がり方は、後半で扱う保存領域の規則の典型的な誤りと同じ形です。

### 10月14日の社内点検での発覚から10月19日の委員会報告までの時系列

1. 10月14日11時台：社内の点検で事実を把握
2. 10月14日17時台〜15日9時台：閲覧制限の設定を修正
3. 10月16日13時台：閲覧可能だった書類画像を削除
4. 10月19日：個人情報保護委員会へ報告し、公式発表を掲載。対象者へ個別にメールで連絡
5. 10月20日15時50分：公式発表を更新

[個人情報保護委員会の案内](https://www.ppc.go.jp/personalinfo/legal/leakAction/)では、本人の数が1,000人を超える漏えい等は、おそれの段階でも報告対象です。速報の目安は発覚から3〜5日以内とされ、発覚から5日後の今回の報告はこの範囲に収まります。確報の期限や記載項目は[個人情報保護委員会への報告義務の実務](https://www.issoh.co.jp/column/details/17840/)で解説しています。本記事は10月24日に公式発表を確認した時点の内容で、その時点で続報は出ていません。

## 歯科衛生士・歯科医院の利用者がとる本人確認書類の悪用対策と問い合わせ先

### 個別メールで対象を確かめる方法とハノワを装った連絡を見分ける基準

自分が対象かは、ハノワに登録したメールアドレスに同社からの個別連絡が届いているかで確かめます。届いていない、または登録アドレスを覚えていない場合の問い合わせ先は、公式発表にある「ハノワ事務局 個人情報に関するお問い合わせ窓口」です。受付は平日10時から17時で、メールは24時間受け付けています。

同社は、メールや電話でパスワードや口座の暗証番号を尋ねることはないと明記しています。漏れたおそれがあるのは氏名・メールアドレス・医院名なので、「ハノワの求人について」「報酬の振込口座を確認したい」といった実在しそうな用件で連絡してくる手口が考えられます。暗証番号やログイン情報を聞かれた時点で、本物ではないと判断して差し支えありません。

### 免許証画像の悪用に備える全国銀行個人信用情報センターへの本人申告

書類画像の区分は1万311名分です。本人確認書類の画像には、通常は氏名や生年月日、住所が写っています。画像が手に入れば、本人になりすましたローンやクレジットの申込みに使われるおそれがあります。

備えとして使えるのが、信用情報機関の本人申告です。[全国銀行個人信用情報センターの案内](https://www.zenginkyo.or.jp/pcic/return/)によると、本人確認書類の紛失・盗難・漏えい等で名義を使われるおそれがある場合に、申告内容を信用情報として登録し、会員の金融機関からの照会に回答します。ただし照会は与信取引の判断に限られ、預金口座の開設時には行われません。悪用の防止を保証する制度ではない点も同センターが明記しています。同じ時期に本人確認書類の画像が漏れた事案として[Lili不正アクセスと本人確認書類の縮小画像](https://www.issoh.co.jp/tech/details/18791/)も参考になります。

身に覚えのない契約や申込みに気づいた場合は、ハノワの窓口にも連絡するよう同社が求めています。

### 旧チャットに患者情報や医院の内部情報を書いていた歯科医院の確認事項

歯科医院の側で確かめたいのは、2024年10月まで提供されていた旧チャットの中身です。勤務日程や条件のやり取りに、患者の名前や症例の写真、院内の書類を添付していた場合、その内容も対象に含まれた可能性があります。

医院名が含まれるのは、最大4万7,683名分と公表された情報の区分です。旧チャットで患者の情報を送っていたなら、医院自身が個人データを漏えいさせた側になるかを確かめる必要があります。医療従事者の情報が同じ週に漏れた事案は[エンタッチ不正アクセスの対象範囲と窓口](https://www.issoh.co.jp/tech/details/18795/)で扱っています。

## ログイン利用者なら読める設定が招いた事故：保存領域の規則の書き方

### 認証済みなら全員に読み取りを許す規則と本人だけに絞る規則の違い

ハノワが使っているクラウドやストレージの製品は公表されていません。ここからのFirebase・S3・Cloud Storageは、公表された症状と同じ形の設定ミスを説明するための例です。

「ログインした他の利用者から閲覧できる」状態は、Firebaseの公式ドキュメント[Avoid insecure rules](https://firebase.google.com/docs/rules/insecure-rules)が避けるべき例として挙げる規則と同じ形をしています。ログインしているかだけを確かめ、誰のファイルかを確かめない規則です。

```
// 避けるべき例：ログインしていれば、どの利用者のファイルも読める
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if request.auth != null;
    }
  }
}

// 本人だけに絞る例：パスの userId とログイン中の UID が一致したときだけ許可
service firebase.storage {
  match /b/{bucket}/o {
    match /user/{userId}/{fileName} {
      allow read, write: if request.auth.uid == userId;
    }
  }
}
```

上の規則は公式ドキュメントの例に基づくもので、本記事の環境では実行していません。マッチングサービスでは、歯科医院が応募者の書類を見る必要があるなど、本人以外による閲覧も想定すべき場面です。その場合も`auth != null`で全員に開けず、応募や契約の関係をデータベースで確かめる条件を規則に書きます。ログインの仕組みそのものは[Firebase Authenticationの認証方式とIDトークン検証](https://www.issoh.co.jp/tech/details/5921/)で解説しています。

### 保存時に付く公開ACLと閲覧記録なしの環境で漏えいを否定できない理由

公式発表は原因の1つに「一部の提出書類の画像について、保存時に閲覧を制限しない設定が付与されていた」ことを挙げています。S3でいえば、アップロード時にオブジェクト単位のACLで公開読み取りを付けた状態にあたります。[S3のObject Ownership](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html)は現在、新しいバケットではACLを無効にする「Bucket owner enforced」が既定です。数年前から使っているバケットは、ACLが有効なまま残っている場合があります。

もう1つの論点が閲覧の記録です。[S3のサーバーアクセスログ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerLogs.html)は明示的に有効にする必要があり、配信もベストエフォートで全リクエストの記録は保証されません。[Cloud Storageの監査ログ](https://docs.cloud.google.com/storage/docs/audit-logging)は、データアクセスのログが既定で無効で、公開状態のオブジェクトへのアクセスは追跡しないと書かれています。公開してしまった後では、ログで「誰も見ていない」と証明する手段がほぼありません。設定の段階で公開を防ぐ以外に、確実な手はないということです。

## 開発者がS3とCloud Storageで公開設定と閲覧ログを点検するコマンド

### AWS CLIでS3のブロックパブリックアクセスとACL無効化を確かめる手順

[S3のブロックパブリックアクセス](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html)には4つの設定があり、バケットとアカウントの設定のうち厳しいほうが適用されます。個人情報や書類画像を置くバケットでは、4つ全てが`true`になっているかを確かめます。

```
# 1. アカウント全体のブロックパブリックアクセス（4項目とも true が望ましい）
aws s3control get-public-access-block --account-id 123456789012

# 2. バケット単位の設定
aws s3api get-public-access-block --bucket example-user-documents

# 3. ACL が無効（BucketOwnerEnforced）かどうか
aws s3api get-bucket-ownership-controls --bucket example-user-documents

# 4. サーバーアクセスログが有効か（何も返らなければ無効）
aws s3api get-bucket-logging --bucket example-user-documents
```

2番目の出力例は[AWS CLIのget-public-access-blockのリファレンス](https://docs.aws.amazon.com/cli/latest/reference/s3api/get-public-access-block.html)に載っており、`BlockPublicAcls`・`IgnorePublicAcls`・`BlockPublicPolicy`・`RestrictPublicBuckets`の4項目が返ります。3番目で`ObjectOwnership`が`BucketOwnerEnforced`以外なら、保存時に付けた公開ACLが効く余地が残っています。上のコマンドは本記事の環境では実行していません。S3の基本構成は[Amazon S3の仕組みと採用判断](https://www.issoh.co.jp/tech/details/15433/)で整理しています。

### gcloudでCloud Storageの公開アクセス防止と閲覧の監査ログを有効にする

Cloud Storageでは、[公開アクセス防止](https://docs.cloud.google.com/storage/docs/public-access-prevention)を強制すると、IAMやACLでバケットのデータを公開できなくなります。組織ポリシーの制約`storage.publicAccessPrevention`で、プロジェクトや組織の単位でも強制できます。

```
# 1. 公開アクセス防止の状態を確かめる（inherited なら未強制）
gcloud storage buckets describe gs://example-user-documents \
  --format="default(public_access_prevention)"

# 2. 公開アクセス防止を強制する
gcloud storage buckets update gs://example-user-documents --public-access-prevention
```

コマンドは[公開アクセス防止の使い方](https://docs.cloud.google.com/storage/docs/using-public-access-prevention)の記載に基づき、本記事の環境では実行していません。Firebaseの保存領域も実体はCloud Storageのバケットなので、同じコマンドで状態を確かめられます。データアクセスの監査ログ（DATA\_READ）を有効にする場所は、プロジェクトのIAM監査ログの設定です。GCSとS3の違いは[Cloud Storage（GCS）の仕組みとS3との違い](https://www.issoh.co.jp/tech/details/15663/)にまとめています。

## 判断：個人情報を預かるマッチングサービスが先に固める3つの運用ルール

### 提出書類画像を確認後に削除する保管期限と、自前で持たない選択の線引き

今回の書類画像は、2019年6月から2025年12月に提出されたものでした。本人確認が済んだ後も、画像を消さずに持ち続けていたことになります。同社も原因の1つに、使わなくなった過去の情報を削除せず保管し続けていたことを挙げています。

本人確認に使った書類画像は、確認が終わった時点で役目を終えます。法令で保存が求められる記録がある場合も、残すのは確認日・書類の種類・番号の一部といった記録で足りるかを先に検討します。画像を残す場合に必要なのは、[S3のライフサイクル設定](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)のように期限が来たら自動で消える仕組みに載せる運用です。月に数百件程度の本人確認なら、画像を自社で保管せず、画像を保持しない外部の本人確認サービスに任せる選択のほうが、漏れる対象そのものを減らせます。

### 設定の定期点検を人手に任せず仕組みにする場面と外部診断を入れる時期

同社は、閲覧制限の設定を確認する手順や仕組みがなく、長期間誤った設定に気づけなかったことも原因に挙げています。前の章のコマンドを人が思い出したときに打つ運用では、同じことが起きます。個人情報を置くバケットが複数あるなら、組織単位でのブロックパブリックアクセスや公開アクセス防止の強制に切り替えるべきです。S3に置いた個人情報の所在を洗い出すには[Amazon Macieの機密データ検出](https://www.issoh.co.jp/tech/details/15886/)も選択肢になります。

一方、外から突ける穴が本当に無いかは、設定を書いた本人には見えにくいものです。今回も画面操作では見えない経路でした。サービス開始から数年たち、仕様変更や機能の廃止を重ねたシステムほど、旧機能のデータや使われていない保存領域が残りやすい状態です。外部の目で点検するなら、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で相談できます。不正アクセスの侵入口を塞ぐ側の対策は[API不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)で扱っています。

## よくある質問

ハノワの情報漏洩について、登録者や歯科医院、開発者から出やすい質問をまとめました。

### ハノワの情報漏洩で漏れた可能性がある情報は何ですか？

氏名・ニックネーム・メールアドレス・医院名（最大47,683名分）、本人確認書類・免許証と口座確認書類の画像（最大10,311名分）、2024年10月まで提供の旧チャットのメッセージと添付ファイル（最大15,482名分）です。重複を除いた対象者は最大49,309名で、パスワードとクレジットカード情報は含まれていません。

### 自分がハノワ情報漏洩の対象かどうかはどう確認できますか？

同社は対象者の登録メールアドレスへ個別に連絡しています。届いていない場合や登録アドレスが分からない場合の問い合わせ先は、公式発表にある「ハノワ事務局 個人情報に関するお問い合わせ窓口」です。受付は平日10時から17時で、メールは24時間受け付けています。

### 実際に第三者に見られたかどうかは分かっていますか？

分かっていません。保存領域では閲覧の記録が残っておらず、第三者による閲覧の有無を確認できないため、同社は「漏えいのおそれ」として公表しています。10月19日の公表時点で、本件に起因する被害の報告は受けていないとしています。

### 免許証の画像が漏れたおそれがある場合、何をすればよいですか？

全国銀行個人信用情報センターなどの信用情報機関に本人申告をすると、会員の金融機関が与信の判断をする際に申告内容が伝わります。預金口座の開設時には照会されず、悪用を確実に防ぐ制度ではありません。身に覚えのない契約や申込みに気づいたら、金融機関とハノワの窓口に連絡します。

### ハノワは今も使っても大丈夫ですか？

同社は10月15日までに閲覧制限の設定を直し、10月16日に閲覧可能だった書類画像を削除したと説明しています。同社が挙げた再発防止策は、クラウドと外部サービスの権限設定の総点検、アクセス記録の取得、不要データの削除ルールの整備です。続けて使うかは、これらの進み具合を公式発表の更新で確かめて判断します。

## 関連記事

- [情報漏洩対策とは：原因別4類型の防ぎ方と発生時の報告義務【2026年10月版】](https://www.issoh.co.jp/column/details/18315/)：設定ミスを含む漏えいの防ぎ方の全体像
- [不正アクセス対策とは：IPA・JPCERTの2026年10月注意喚起に沿った企業の点検手順](https://www.issoh.co.jp/column/details/18313/)：企業として点検する範囲
- [エンタッチ不正アクセス：医療従事者と面談予約の情報が漏洩、対象範囲と窓口](https://www.issoh.co.jp/tech/details/18795/)：同じ週の医療人材サービスの事案
- [Lili不正アクセス：パスワード平文流出の可能性と本人確認書類の縮小画像、偽Cloudflare画面への対応](https://www.issoh.co.jp/tech/details/18791/)：本人確認書類の画像が対象になった別の事案
- [Amazon S3とは？オブジェクトストレージの仕組み・ストレージクラスと料金・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15433/)：書類画像の保存先の基本

---

出典: [ハノワ情報漏洩：本人確認書類も閲覧可能だった4.9万人分の範囲とクラウド設定の点検](<https://www.issoh.co.jp/tech/details/18829/>)（株式会社一創）