ホテルのチェックインシステムが100万件のパスポート情報を漏洩
日本のテクノロジースタートアップReqreaが運営するホテルチェックインシステム「Tabiq」が、100万件以上の顧客のパスポートや運転免許証、セルフィー確認写真をインターネット上に公開してしまいました。このデータは、TechCrunchが同社に通知した後にオフラインになりました。問題の原因は、Amazonのクラウドストレージバケットが公開設定になっていたことです。Reqreaは、外部の法律顧問と共に調査を行い、影響を受けた個人に通知する計画を立てています。今回の事件は、基本的なサイバーセキュリティの実践を怠った結果であり、個人情報の漏洩がもたらすリスクを再認識させるものです。
メトリクス
このニュースのスケール度合い
インパクト
予想外またはユニーク度
脅威に備える準備が必要な期間が時間的にどれだけ近いか
このニュースで行動が起きる/起こすべき度合い
主なポイント
- ✓ Tabiqシステムは、顔認識と文書スキャンを利用してゲストをチェックインさせる仕組みです。
- ✓ Reqreaは、データ漏洩の原因を調査中で、影響を受けた顧客に通知する予定です。
社会的影響
- ! 個人情報の漏洩は、アイデンティティ詐欺のリスクを高める可能性があります。
- ! 政府が年齢確認法を導入する中で、個人情報の取り扱いに対する懸念が高まっています。
編集長の意見
解説
100万件超の旅券・免許・セルフィーが公開状態に──ホテルチェックインSaaS「Tabiq」のS3設定ミスが突きつける現実です
今日の深掘りポイント
- クラウドの初歩的ミス(S3の公開設定)が、旅券・運転免許・顔写真という「eKYC完全セット」を丸裸にしました。攻撃者に侵入を要しない“ゼロクリック漏えい”の典型です。
- 旅行・出張をまたぐ横断的サプライチェーン漏えいで、標的型フィッシングと成りすまし口座開設の現実的リスクが跳ね上がります。
- 技術対策の本丸は「デフォルト拒否の徹底」と「自動検知の常時化」。AWSではBlock Public Accessの強制、Access Analyzer、CloudTrail Data Events、Macieの組み合わせが最短距離です。
- 監査・契約の更新ポイントは「公開設定の組織強制」「全バケットのデータイベント監査」「保存期間の自動削減」。SaaSベンダのIaCとパイプラインに“公開抑止のガードレール”を入れるのが肝です。
- いま必要なのは「即時のベンダ確認」「お客様向け注意喚起」「メール・決済・不正申込の監視強化」。被害規模は大きく、対処は待ったなしです。
はじめに
日本のスタートアップReqreaが提供するホテル向けチェックイン基盤「Tabiq」で、Amazon S3の公開設定ミスにより、100万件以上のパスポート・運転免許・セルフィー確認写真がインターネットから無認証で閲覧可能になっていました。TechCrunchの通報後にオブジェクトはオフライン化されています。対象データには2020年から直近までの世界中の来訪者情報が含まれると報じられています。Reqreaは外部法律顧問と調査を進め、影響個人への通知を予定しています。TechCrunchの一次報道に基づけば、侵入やマルウェアは不要、単なる公開設定だけで生じた「扉のかけ忘れ」型漏えいです。
本件の重さは、技術的には初歩の設定ミスでありながら、漏えいしたデータの“攻撃価値”が突出している点にあります。旅券番号・運転免許情報・顔写真という組み合わせは、近年のeKYCや年齢確認の要件をそのまま満たし、犯罪者にとっては極めて再利用性が高いからです。
深掘り詳細
事実関係(何が起き、どこがまずかったか)
- 影響内容
- 100万件超のパスポート、運転免許、セルフィー確認写真が無認証アクセス可能な状態でS3に置かれていたと報道されています。期間は2020年から直近までを含むとされます。TechCrunch
- 原因の一次要因
- S3バケット/オブジェクトの公開設定(ACLまたはバケットポリシー)の誤り。AWSは「Block Public Access(BPA)」を提供し、組織・アカウント・バケットの各層で“公開を一括遮断”できますが、これが未強制/未適用であれば、ポリシーの一行ミスで世界公開が起き得ます。Amazon S3 Block Public Access
- 組織的背景の典型
- IaCやCI/CDでの権限・ポリシー差分レビュー不足
- 変更管理での「四つ目の原則」不徹底(少なくとも2名レビュー)
- バケット公開検知・警告の自動化不足(Access Analyzer/Config/Security Hub)
- S3データイベント(GetObject等)の監査無効化(コスト回避の“悪しき最適化”)
インサイト(なぜ繰り返され、何を直すべきか)
- “否定からの例外”ではなく“許可の例外”へ
- S3は柔軟ゆえに危うい。正解は、アカウント全体でBPAをオンにし、SCPや組織ガードレールでBPA解除・公開ACL/ポリシーを物理的に不可能化する運用です。公開が必要な場合はCloudFront+Origin Access Controlで閉域連携に寄せ、直接の公開オブジェクトを作らない設計に寄せるのが再発防止の王道です。S3 Access Analyzer
- 「見える化」をケチらない
- 被害規模やアクセス有無の確定には、CloudTrail Data Eventsの有効化が事実上必須です。S3サーバアクセスログやCloudTrailのデータイベントがなければ、実際に第三者が取得したかは“推測の域”を出ません。監査コストは保険料と割り切るべきです。CloudTrail Data Events for S3
- “集めない・長く持たない”が最強の防御
- 顔写真+本人確認書類は最も高価値の個人データです。最小権限だけでなく“最小収集・最小保存”が肝心です。S3ライフサイクルで短期自動削除し、必要時は都度再取得する運用の方が、総リスク・総コストで勝ちやすい。機密検知にはAmazon Macieなどの自動分類を常時回すのが効果的です。Amazon Macie
- サプライチェーン視点の再設計
- ホテル業界では、ベンダ横断で同一人物の旅程情報が連鎖しやすく、単一SaaSの設定ミスが“旅の全貌”につながりかねません。第三者リスク管理では、監査項目に「アカウントレベルのS3 BPA強制」「全バケットのデータイベント監査ON」「公開検知の自動アラート」「保存期間の自動削減」を明記し、証跡提出を義務付けるべきです。
脅威シナリオと影響
本件は侵入を要さず、公開ストレージを漁るだけで収集できるため、攻撃者にとってコスト対効果が非常に高いシナリオです。以下は仮説に基づく想定です(いずれもMITRE ATT&CKの該当技術にリンクを付しています)。
- 公開ストレージの横断スキャン
- クラウドストレージからの大量取得
- 攻撃フェーズ: 収集
- 技術: Data from Cloud Storage Object(T1530)
- 内容: 認証不要のGetObjectで画像・PDFを吸い上げ、顔写真とIDを紐付けた“eKYC完全パッケージ”を作成します。
参考: T1530
- 個人情報の集約とプロファイリング
- 攻撃フェーズ: リコン/準備
- 技術: Gather Victim Identity Information(T1589)
- 内容: 旅券/免許から生年月日・国籍・住所、セルフィーから顔特徴量を抽出し、他の漏えいデータと照合して高精度な人物プロファイルを作ります。
参考: T1589
- 具体的な悪用例(仮説)
- 標的型フィッシング(T1566): 宿泊施設名・渡航日程を織り込んだ極めてリアルな請求/変更通知メールで決済情報を詐取。
- 不正な口座開設/本人確認突破: 旅券+顔写真の組み合わせで、弱いeKYC実装を迂回(各事業者の対策レベルに依存)。
- なりすまし予約/ポイント詐取: 会員ID再発行手続きに本人確認画像を流用して奪取。
- 社会的・地政学的リスク: 渡航履歴の推定から人物の関心領域・雇用先・会議参加歴を逆算し、物理的ストーキングやスパイ活動の補助に活用。
CISO視点では、本件は「即時性が高く」「業界をまたぐ波及が広い」案件です。新規性は低いものの(過去にもクラウド設定ミスは多発)、漏えいデータの感度が突出し、アクションの明確性が高い──ゆえに“手を動かすべきニュース”に分類されます。
セキュリティ担当者のアクション
- いま(48時間以内)やること
- 取引ベンダ確認
- Tabiqの採用有無、対象期間・ロケーション、保存データの種別を即時確認。アクセスログ(CloudTrail Data Events/S3アクセスログ)の有無を問い合わせ、なければ“取得有無不明”としてリスクコミュニケーションを準備します。
- 社内/顧客向け注意喚起
- 旅行・宿泊文脈を装う巧妙なフィッシングを想定し、社内メール・決済ワークフローの二重承認/差戻しルールを一時的に強化します。顧客には、宿泊変更・返金・本人確認依頼を名乗る連絡に注意喚起を実施します。
- 監視強化
- メール: 旅行関連キーワード+画像添付のフィルタを強化、偽装ドメイン類似度検知をON。
- 不正申込/口座開設: eKYCの再申請急増・同一顔類似スコアのスパイクをアラート閾値引き下げ。
- 取引ベンダ確認
- 1週間以内にやること
- 第三者リスク管理(契約・監査項目の更新)
- 「S3 Block Public Accessのアカウントレベル強制」「Access Analyzerの常時監視」「CloudTrail Data Events(全バケット)有効化」「S3ライフサイクルによる短期削除」「Macie等の機密検知常時実行」をセキュリティ付帯条項として明文化し、証跡提出を義務化します。
参考: S3 Block Public Access, Access Analyzer, CloudTrail Data Events, Amazon Macie - AWS Config/Security Hubのマネージドルールで「s3-bucket-public-read-prohibited」「s3-bucket-public-write-prohibited」を全アカウントに適用し、例外は経営承認に限定します。
参考: AWS Config ルール: public-read 禁止
- 「S3 Block Public Accessのアカウントレベル強制」「Access Analyzerの常時監視」「CloudTrail Data Events(全バケット)有効化」「S3ライフサイクルによる短期削除」「Macie等の機密検知常時実行」をセキュリティ付帯条項として明文化し、証跡提出を義務化します。
- インシデント・リーガル
- APPI(改正個人情報保護法)の報告・本人通知義務の検討を法務と連携して着手します(対象・重大性の判定枠組みを確認)。
参考: 個人情報保護委員会(英語版・法令等)
- APPI(改正個人情報保護法)の報告・本人通知義務の検討を法務と連携して着手します(対象・重大性の判定枠組みを確認)。
- 第三者リスク管理(契約・監査項目の更新)
- 30日以内にやること
- 技術基盤の恒久対策
- SaaS/社内双方で、S3公開を防ぐ“物理的ガードレール”を導入します(SCPでBPAの解除禁止、公開ACL/ポリシー禁止、CloudFront+OACへ統一、プリサインドURLの期限短縮)。
- IaCにポリシーアズコード(OPA/Conftestなど)を導入し、CIで公開設定をビルドブレーク。PRにセキュリティ・レビューを必須化します。
- 監査・検知は「常時が標準」。Access Analyzerの検出をSecurity Hubに集約し、SOCで週次レビューを回す体制を敷きます。
- データ最小化の実装
- eKYC画像・本人確認書類は“目的達成後速やかに削除”をデフォルトに。どうしても保持が必要な場合は、短期(例: 30〜90日)の自動削除をS3ライフサイクルで確実化し、長期保存は暗号化・分離・アクセス審査を義務付けます。
- レッドチーム/紫チーム演習
- 「オープンバケット発見から取得まで」を外部視点で演習し、SOC検知・危機広報・法務連携の一連動線を検証します。
- 技術基盤の恒久対策
参考までに、MITRE ATT&CKの該当技術は以下の通りです(仮説ベース)。
- Active Scanning(T1595)
- Search Open Websites/Domains(T1596)
- Data from Cloud Storage Object(T1530)
- Gather Victim Identity Information(T1589)
- Phishing(T1566)
最後に一言。クラウドの“便利さ”は、デフォルトで安全を約束してくれません。公開の扉は、組織的に二重三重に溶接しておく──これが、顔写真と身分証という“二度と取り戻せないデータ”を預かる者の最低条件です。
参考情報
- TechCrunch: A hotel check-in system left a million passports and driver’s licenses open for anyone to see(2026-05-15) https://techcrunch.com/2026/05/15/a-hotel-check-in-system-left-a-million-passports-and-drivers-licenses-open-for-anyone-to-see/
- Amazon S3 Block Public Access(公式ドキュメント) https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html
- Amazon S3 Access Analyzer(公式ドキュメント) https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-analyzer.html
- AWS CloudTrail Data Events for S3(公式ドキュメント) https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html
- Amazon Macie(公式ドキュメント) https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html
- AWS Config ルール: s3-bucket-public-read-prohibited(公式ドキュメント) https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-public-read-prohibited.html
- MITRE ATT&CK: Active Scanning(T1595) https://attack.mitre.org/techniques/T1595/
- MITRE ATT&CK: Search Open Websites/Domains(T1596) https://attack.mitre.org/techniques/T1596/
- MITRE ATT&CK: Data from Cloud Storage Object(T1530) https://attack.mitre.org/techniques/T1530/
- MITRE ATT&CK: Gather Victim Identity Information(T1589) https://attack.mitre.org/techniques/T1589/
背景情報
- i Tabiqは、顔認識技術と文書スキャンを用いて、ホテルのチェックインプロセスを効率化するシステムです。顧客の個人情報を安全に管理することが求められますが、今回の事件では基本的なセキュリティ設定が不十分でした。
- i Amazonのクラウドストレージは、デフォルトでプライベート設定になっていますが、誤って公開設定に変更されることがあります。これにより、誰でもデータにアクセスできる状態になり、個人情報が漏洩するリスクが高まります。