リクリエ「Tabiq」のAmazon S3設定不備による本人確認書類画像の露出（対象1,060,338人）
公表日
ホテル向けチェックインシステム「Tabiq」で、クラウドの保存場所の設定に不備があり、1,060,338人分の顔写真やパスポート等の画像が第三者から見られる状態になっていました。実際に第三者が取得・悪用した事実は確認されていません。
対象者は？
2020年1月20日から2026年5月14日までの期間に、Tabiqのデータに含まれていた1,060,338人（確定）。対象の情報は顔写真、署名画像、パスポートや運転免許証等の本人確認書類の画像です。予約情報やクレジットカード情報など、画像データ以外は含まれていません。
リクリエが対象者への個別通知を準備中です（報道による。通知の時期や方法はまだ発表されていません）。通知が届くかどうかを確認してください。
いますぐできること
- 身に覚えのないメール・電話・郵便には注意し、記載のリンクや番号をすぐには使わない。
- リクリエはパスワード変更や金銭の支払いを求めることはないとしているので、そのような連絡は不審なものとして扱う。
- リクリエからの個別通知が届いていないか、メールや郵便を確認する。
何が起きたのか
2026年5月13日、リクリエは、Tabiqで使うクラウドの保存場所に入っていた本人確認書類の画像などが、外部の第三者から見られる状態だったことを把握しました。翌14日に外部からのアクセスを遮断しました。5月15日に海外のニュースサイトTechCrunchが報じ、外部の研究者が見つけて知らせたと伝えられました。リクリエは5月18日に個人情報保護委員会へ速報し、6月12日に確報を出しました。6月30日には、専門会社の調査を踏まえた正式な報告を公表しました。
なぜ起きたのか・なぜ広がったのか
原因は、リクリエが使うクラウドストレージ（Amazon S3）の設定に不備があったことと説明されています。報道では、保存場所の名前を知っていれば、パスワードなしでブラウザから見られる状態でした。どのようにして公開状態になったのかは、公表されていません。
いまの状況2026-07-14 時点続報待ち
2026年7月14日時点の情報です。リクリエのセキュリティ監視の記録上、画像が不正に取得・悪用された事実や、外部からの被害の報告は確認されていません。再発防止策として、権限設定の見直し、監視の強化、Privateバケットへの移行、運用の改善が示されました。対象者への個別通知は準備中で、通知の時期や補償についてはまだ発表されていません。
企業として考えたいこと
自社が預かっているお客様の本人確認書類や写真は、どこに保存されていて、誰でも見られる状態になっていないかを、自社より先に外部の人が見つける前に確認できる仕組みがありますか。
技術的な要約
リクリエが提供するホテル向け電子チェックインシステム「Tabiq」で、本人確認書類画像等を保存していたAmazon S3の設定不備により、外部から第三者がアクセス可能な状態となっていた。リクリエは2026年5月13日に判明し、翌14日に外部アクセスを遮断した。5月15日にTechCrunchが報じて公になった。対象は1,060,338人（確定）、対象期間は2020年1月20日から2026年5月14日で、顔写真・署名画像・パスポートや運転免許証等の画像が含まれる。予約情報やクレジットカード情報は含まれず、二次被害は確認されていない。個人情報保護委員会へ5月18日に速報、6月12日に確報を行い、対象者への個別通知は準備中である。
公開情報が限られている点について
攻撃の分類
- 侵入口
- クラウド設定不備公表で確認公式は、本人確認書類画像等を保存していたクラウドストレージ(Amazon S3)の設定不備により外部から第三者がアクセス可能な状態となっていたと説明。報道ではバケット名「tabiq」を知っていれば認証なしでブラウザから閲覧できた。バケットがどのように公開状態になったかの具体的経緯は公表されていない。
- 脆弱性
- CVE 非公表公表で確認Amazon S3ソフトウェアの脆弱性ではなく、バケットの公開設定の不備。S3は既定で非公開であり、公開に至った経緯は不明。
- 攻撃者
- 特定・主張なし
- ATT&CK
影響
- 業務停止
- なし
- データ
- おそれ上限 1,060,338確定 —人顔写真本人確認書類パスポート氏名住所生年月日その他対象人数1,060,338人で確定（アクセス可能だった対象者数）。内容は顔写真、署名画像、パスポート・運転免許証等の本人確認書類の画像データ。報道では氏名・住所・生年月日・証明書番号が画像に含まれると報じられた。予約情報やクレジットカード情報は対象外。第三者が実際にアクセスしたかは確認されておらず、不正取得・悪用による二次被害は確認されていない。
- 波及先
- —
- 金銭影響
- —
- サプライチェーン
- Tabiqは日本国内の複数のホテルで使われるチェックインシステムで、リクリエ自身が利用するクラウドストレージの設定不備が原因とされる。世界各国のホテル宿泊者が対象に含まれる。
時系列
技術解説
露出の構造：S3の公開設定と認証なしの閲覧 事実
リクリエは、Tabiqで本人確認書類画像等を保存していたクラウドストレージ(Amazon S3)の設定不備により、外部の第三者がアクセス可能な状態になっていたと説明している。報道によれば、バケット名「tabiq」を知っていれば、ブラウザだけで認証なしに内容を閲覧できた。TechCrunchは、このバケットが公開状態のクラウドストレージを索引化するGrayHatWarfareにも捕捉されていたと報告している。TechCrunchは、高度なサイバー攻撃ではなく公開設定（ミスコンフィギュレーション）の問題だと伝えた。リクリエはバケットがどのように公開状態になったかを把握していないとしており、公表内容でも具体的な経緯は明らかにされていない。
対象範囲と数字の扱い 事実
リクリエの報告では、対象人数は1,060,338人で確定、対象期間は2020年1月20日から2026年5月14日まで。内容は顔写真、署名画像、パスポートや運転免許証等の本人確認書類の画像データで、予約情報やクレジットカード情報など画像データ以外は含まれない。報道では氏名・住所・生年月日・証明書番号が含まれると伝えられ、世界各国のホテル宿泊者が対象とされる。海外報道は「100万件超」と表現し、公式の人数は1,060,338人である。第三者が実際にデータへアクセスしたかは報道時点で確認されておらず、リクリエのセキュリティ監視の記録上、不正取得や悪用による二次被害も確認されていない。
判明から公表までの経過 事実
リクリエの説明では、2026年5月13日に第三者がアクセス可能な状態だったことが判明し、翌14日に外部からのアクセスを遮断する措置を完了した。5月15日にTechCrunchのZack Whittaker氏が報じ、独立系セキュリティ研究者のAnurag Sen氏が発見して通報したと伝えられた。報道では、TechCrunchがリクリエとJPCERT/CCに連絡した後にバケットが非公開になったとされる。リクリエは5月18日に個人情報保護委員会へ速報し、第三者機関によるフォレンジック調査を実施、6月12日に確報、6月30日に正式報告を公表した。再発防止策として、IAM権限・バケットポリシー・ACLの棚卸し、アクセスログ取得とCSPM等による監視強化、脆弱性診断とPrivateバケットへの移行、運用フロー改善が示された。対象者への個別通知は準備中である。
読み取れること：設定不備型の事案としての特徴 解釈
S3バケットは既定で非公開とされるため、公開状態になるまでにどこかで設定変更があったと考えられるが、その経緯は公表されていない。対象期間が約6年に及ぶことから、本人確認書類の画像が長期間同じ保存先に蓄積されていた可能性がある。ただし公開が始まった時期は不明で、この点は推測にとどまる。発見は外部の研究者によるもので、公式の遮断日（5月14日）と報道の「連絡後に非公開」との前後関係は、公表資料だけでは確定できない。パスポートや免許証の画像は本人が簡単に差し替えられない情報であり、悪用が確認されていなくても、対象者には長く注意が必要になるとみられる。一方、リクリエは調査結果と再発防止策を公表しており、個別通知の進み方が今後の確認点になる。
対応
- 封じ込め
- 2026年5月14日に外部からのアクセスを遮断する措置を完了し、以降の外部アクセス履歴は確認されていない。第三者機関によるフォレンジック調査を実施。再発防止策として、IAM権限・バケットポリシー・ACLの棚卸しと最小権限での再設計、アクセスログ取得とCSPM等による監視強化、脆弱性診断とPrivateバケットへの移行、運用フローの改善が示された。
- 公表の仕方
- 2026年5月15日のTechCrunch報道で明らかになり、6月30日にリクリエが正式な報告を公表。対象者への個別通知は準備中。不審な連絡への注意を呼びかけ、同社がパスワード変更や金銭の支払いを求めることはないとしている。
- 当局対応
- 個人情報保護委員会（2026年5月18日速報、6月12日確報）
教訓と対策
| 教訓 | 具体的な対策 |
|---|---|
| クラウドストレージの公開設定は、個別バケットの注意に頼らず組織全体の統制で防ぐ | AWSアカウントと組織の両方でS3 Block Public Accessを有効化し、SCPで公開化・無効化の操作を管理者ロール以外に禁止する。新規バケットはIaC(Terraform等)のモジュールで公開禁止を既定にし、レビューを通らない手作業の変更をなくす。 |
| 公開状態は外部の第三者より先に自社で検知する | AWS Configのs3-bucket-public-read-prohibitedとs3-bucket-public-write-prohibited、IAM Access Analyzer、Security Hub等のCSPMを有効にし、公開検知を即時アラートでオンコールに通知する。自社名やサービス名を含むバケット名が公開バケット検索サービスに載っていないかも定期的に確認する。 |
| 本人確認書類の画像は保持量と保持期間を最小化する | チェックイン完了後の保持期限を定め、S3ライフサイクルルールで自動削除する。保存時はSSE-KMSで暗号化し、閲覧はバケット直接公開ではなく短時間有効の署名付きURLなど認可を通した経路に限定する。 |
| 第三者アクセスの有無を後から判断できるログを事前に取る | S3サーバーアクセスログまたはCloudTrailのデータイベントを有効にして別アカウントのバケットに保管し、保持期間を決める。ログから匿名アクセスを抽出するAthenaクエリを事前に用意し、事案発生時に影響範囲を短時間で確定できるようにする。 |
| 外部の研究者や報道機関からの通報を受け取る窓口を用意する | security.txtを公開し、脆弱性・露出の連絡先を専用メールアドレスで受ける。受信後の初動(遮断担当、判断者、規制当局への連絡の基準)を手順書にし、年1回は机上訓練で確認する。 |
自組織などでの確認項目
- 自組織のAWSアカウントでS3 Block Public Accessは、アカウント・組織の両方のレベルで有効になっているか。例外のバケットがあれば、理由と承認者を説明できるか。
- 自組織で本人確認書類や顔写真などの画像を保存している場所はどこか。保持期限は決まっているか、その削除は自動化されているか。
- 自組織のクラウドストレージについて、公開状態を検知するアラートは何分以内に誰へ届くか。外部の研究者から通報があった場合の受付窓口と初動は決まっているか。
- 自組織でバケットやストレージのアクセスログは取得・保管されているか。公開を止めた後、遮断前に第三者が取得したかを確認できる状態か。
未解明点
- バケットがどのような操作・設定変更で公開状態になったか、具体的な経緯は公表されていない。
- 公開状態が始まった正確な時期と、公開されていた期間は不明とされている。
- 遮断前に第三者が実際にデータを取得したかについて、ログ調査の詳しい結果は公表されていない。
- 対象者への個別通知の開始時期と方法、対象者への支援策は、報道時点でまだ発表されていない。
- 対象人数1,060,338人の内訳（国・地域別、利用ホテル別など）は公表されていない。
出典
- 1セキュリティ対策Lab（合同会社ロケットボーイズ）2026-07-01報道本文確認済
- 2セキュリティ対策Lab（合同会社ロケットボーイズ）2026-05-20報道本文確認済
- 3ScanNetSecurity2026-07-14報道本文確認済
- 4Security Affairs2026-05-18報道本文確認済
- 5State of Surveillance2026-05報道本文確認済
- 6Privacy Guides2026-05-22報道本文確認済
- 7SC Media2026-05-18報道本文確認済