--- title: "GETTIIS不正アクセスの件数と対応：主催者向けGettii-Liteから会員DBを分ける設計" url: "https://www.issoh.co.jp/tech/details/18769/" published: 2026-10-22 updated: 2026-10-22 categories: ["セキュリティ"] publisher: "株式会社一創" --- # GETTIIS不正アクセスの件数と対応：主催者向けGettii-Liteから会員DBを分ける設計 チケット購入サービス「GETTIIS（ゲッティーズ）」を運営するリンクステーションは2026年10月19日、主催者向けの公演登録サービス「Gettii-Lite」のサーバーに不正アクセスがあり、GETTIISの会員情報が外部に流出したと公表しました。翌20日の第二報では、会員ID317,971件をはじめ項目ごとの件数が示されています。本記事では、公式発表から対象になる情報と会員がいま行う対応を整理したうえで、主催者向けの管理系アプリから購入者の会員DBに届かない構成を、PostgreSQLの権限設定のSQLで解説します。 ## まとめ：GETTIIS不正アクセスで漏えいした会員情報と会員が行う3つの対応 第二報で確定しているのは、2026年10月18日の午前0時頃から7時頃にかけて、第三者がGettii-Liteのプログラムの脆弱性を悪用し、GETTIISの会員情報を取得したことです。対象は会員ID、ハッシュ化されたパスワード、氏名、電話番号、メールアドレス、カード番号の一部を暗号化した情報などです。完全なカード番号とセキュリティコードは保存されておらず、漏れた情報だけでは決済できないとされています。脆弱性の種類は公表されていません。 会員が行うのは次の3つです。 1. GETTIISにログインし、パスワードを変更する（10月20日20時から8〜64文字・記号ありで設定できる） 2. GETTIISと同じパスワードを使っている他のサービスで、別のパスワードに変える 3. 本件に便乗したメール・SMS・電話で、パスワードやカード番号を答えない 主催者の立場で読む方は、後半の構成と権限設計の章から読んでください。管理画面の脆弱性が購入者のデータに届くかどうかは、DBに接続するロールの権限でほぼ決まります。 ## 自分は対象か｜GETTIIS会員ID317,971件と項目別件数の読み方 ### 10月20日の第二報が示した項目別件数9項目と合計人数として読めない理由 [リンクステーションの第二報](https://www.gettiis.jp/notice/detail/42)は、漏えいした情報を9つの項目に分けて件数を出しています。 | 項目 | 件数 | | ------------- | -------- | | 会員ID | 317,971件 | | ハッシュ化されたパスワード | 311,451件 | | メールアドレス | 311,426件 | | 氏名 | 309,759件 | | 電話番号 | 309,668件 | | クレジットカード関連情報 | 29,515件 | | 性別 | 5,900件 | | 生年月日 | 5,192件 | | 郵便番号 | 489件 | 第二報には、これらが各項目の件数であって合計人数ではないと注記があります。足し上げて「約130万件」と読むのは誤りです。最も多いのは会員IDの317,971件で、漏えいの対象になった人数そのものは公表されていません。性別・生年月日・郵便番号は数千件以下にとどまります。第一報が「対象となる情報は、お客様のご登録内容によって異なります」と書くとおり、どの項目が漏れたかは人ごとに変わります。 ### クレジットカード関連情報29,515件の中身と決済に使えないとされた根拠 カード関連情報は、カード番号の先頭4桁と末尾4桁、名義、有効期限を暗号化したものです。完全なカード番号とセキュリティコードは保存していないため、漏れた情報だけではカード決済ができない、と同社は説明しています。カードの再発行を求める記載はありません。 注意したいのは、先頭・末尾の4桁と名義、有効期限がそろうと、本人しか知らない情報に見えることです。「ご登録のカード（末尾1234）に不正利用の疑いがあります」という連絡は、本物らしく作れてしまいます。カードの利用明細は、カード会社のアプリか、自分で開いた公式サイトで確かめてください。 ### 漏えい対象の登録情報をGETTIISのマイページで確かめる手順 対象の会員には、同社から個別にメールで連絡済みです。メールを受け取った会員は、GETTIISにログインし、画面右上の「MENU」から「登録情報編集」に進むと、自分の登録状況を見られます。「プロフィール編集」に出ている会員ID・氏名・電話番号・メールアドレス・郵便番号・性別・生年月日と、「クレジットカード登録」の有無が、漏えいの対象になった情報です。 10月18日より後に登録情報を書き換えた場合は、いまの画面と漏えい当時の内容が一致しません。電話番号やメールアドレスを最近変えた人は、変える前の値も漏れたものとして扱います。 ## 10月18日の不正取得から第二報まで｜公式発表の時系列と第一報からの更新点 ### 10月18日0時〜7時の不正取得から緊急メンテナンスまでの時系列 公式のお知らせを日付順に並べると、取得の発覚から第二報まで2日で進んでいます。 | 日時 | 出来事 | | -------------- | ------------------------ | | 10月18日 0時〜7時頃 | Gettii-Lite脆弱性悪用で会員情報の取得 | | 10月18日 | 不審なアクセスを確認し調査を開始 | | 10月19日 | 第一報、パスワード変更方法を掲載 | | 10月20日 | 第二報で項目別件数を公表 | | 10月20日 20時 | パスワードの設定条件を変更 | | 10月21日 22時〜翌2時 | PHPの脆弱性対策で緊急メンテナンス | 第二報の時点で、対象サーバーの切り替えと、悪用された脆弱性への対策は完了済みとされています。関係機関への報告も済んでおり、警察への相談と情報提供を続けるとしています。不正アクセスによる個人データの漏えいは、件数にかかわらず個人情報保護委員会への報告の対象です。報告の段取りは[個人情報保護委員会への報告義務](https://www.issoh.co.jp/column/details/17840/)で整理しています。 10月21日夜の[緊急メンテナンスのお知らせ](https://www.gettiis.jp/notice/detail/44)は、目的を「PHPの重大な脆弱性へのセキュリティ対策」と書き、[IPAの注意喚起](https://www.ipa.go.jp/security/security-alert/2026/pre-alert20261021.html)を関連情報に挙げています。今回の不正アクセスとの関係には触れていません。Gettii-Liteで悪用された脆弱性がPHPのものだと読むのは、公式発表の範囲を超えます。PHPの脆弱性そのものは[PHP2Shellとは](https://www.issoh.co.jp/tech/details/18738/)で解説しました。 ### 第一報の「取得していた可能性」から第二報の「流出を確認」への更新点 [10月19日の第一報](https://www.gettiis.jp/notice/detail/40)は、会員情報を「取得していた可能性がある」とし、対象の範囲と件数を調査中としていました。取得の時間帯も「同日未明」です。20日の第二報では、取得は「判明」に変わり、時間帯が午前0時頃から7時頃と特定され、項目別の件数が加わりました。 対象の会員への連絡も、第一報の「順次、個別にご連絡」から、第二報では「個別にメールでご連絡いたしました」と完了形になっています。今後も、追加で分かったことは同じお知らせのページ等で伝えるとしています。 ## 会員が今日やること｜パスワード変更と8〜64文字への条件変更・便乗連絡への備え ### GETTIISのパスワードを変える3手順と先に変える使い回し先の順番 パスワードはハッシュ化して保存されており、平文のパスワードは漏れていません。それでも同社は、安全のためにGETTIISのパスワードの変更を求めています。[パスワードの変更方法](https://www.gettiis.jp/notice/detail/41)のページにある手順は次のとおりです。 1. GETTIISにログインし、画面右端の「会員ID＋ポイント数」のボタンを押す 2. 登録情報編集ページで「パスワード編集」を押す 3. 新しいパスワードを入力し、「変更する」を押す 10月20日20時からは、8〜64文字で、英字・数字に加えて記号も使えるようになりました。すでに変えた人はそのまま使えますが、短いパスワードにしていたなら、長いものに変え直す価値があります。他のサービスで使い回しているなら、メール、決済のあるサービス、チケットやECのアカウントの順に変えます。メールを乗っ取られると、他のサービスのパスワード再設定まで相手に許すからです。 ### リンクステーションを装う連絡の見分け方とPMS個人情報相談窓口 今回は氏名・電話番号・メールアドレスが組で漏れています。本名で呼びかけるメールや、登録した電話番号への着信があっても、本物の証拠にはなりません。同社は、メールや電話でパスワード、クレジットカード番号、暗証番号を尋ねることはないと明言しています。この3つを聞かれたら、その時点で偽物です。 本件の問い合わせ先は、リンクステーションのPMS個人情報相談窓口（メール：pms@linkst.jp、24時間受付・順次対応）です。届いたメールのリンクや返信からではなく、GETTIISの公式サイトのお知らせから第二報を開き、そこに書かれた宛先へ自分で送ってください。 ## 主催者向けGettii-Liteから会員DBへ届いた構成｜公表事実と分離の効き方 ### 主催者向けGettii-Liteの脆弱性で購入者側の会員情報が取得された構図 第二報によると、Gettii-Liteは主催者向けの公演登録サービスで、GETTIISはお客様向けのチケット購入サービスです。脆弱性があったのは主催者が使う側のプログラムで、取得されたのは購入者側の会員情報でした。つまり、主催者向けのアプリから、購入者の会員情報を持つデータに手が届く経路があったことになります。 どの経路だったかは公表されていません。同じDBの同じテーブルを読めたのか、アプリのサーバーに置かれた接続情報が使われたのか、別の仕組みなのかは分からない。ここから先は、本件の原因の推定ではなく、同じ構図を自社で作らないための設計の話です。 ### 別環境のGettiiとGettii-ECに影響なしとされた点から読める分離の効果 第二報は、GettiiとGettii-ECについて「Gettii-Liteとは異なるシステム環境で運用しており」、影響は確認されていないと書いています。環境を分けていた部分には被害が及ばなかった、という公式の説明です。分離は効く。問題は、分けた環境の内側で、管理系と購入者のデータがどこまでつながっているかです。 [OWASPのDatabase Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Database%5FSecurity%5FCheat%5FSheet.html)は、DBのアカウントは1つのアプリかサービスだけが使い、アプリの動作に必要な最小限の権限だけを持たせるよう求めています。DBサーバーを専用の内部ネットワークに置き、ファイアウォールで接続元のホストを絞ることも同じ資料の推奨です。次の章では、このうちDBの権限で切る部分を実装します。 ## 管理系アプリのDB接続を最小権限にする実装｜PostgreSQLのロールと列権限・RLS ### 主催者向けアプリ用ロールから会員テーブルの全列SELECTを外すSQL 会員のパスワードハッシュや電話番号を持つ `members` と、公演ごとの購入記録を持つ `orders` がある構成を例にします。主催者向けの画面が必要とするのは、自分の公演の購入者名と座席くらいです。そこで、主催者向けアプリ専用のロールを作り、`members` は一切読めず、`orders` は必要な列だけ読める状態にします。 ``` -- PostgreSQL 18系で確認した構文（2026年10月時点） BEGIN; -- 主催者向けアプリ専用のロール。テーブルの所有者にはしない CREATE ROLE organizer_app LOGIN PASSWORD 'change-me' NOSUPERUSER NOBYPASSRLS; -- 1. テーブル単位の権限を先に外す（PUBLIC 経由の権限も外す） REVOKE ALL ON TABLE members FROM organizer_app, PUBLIC; REVOKE ALL ON TABLE orders FROM organizer_app, PUBLIC; -- 2. 主催者画面が表示に使う列だけを列単位で渡す GRANT SELECT (order_id, organizer_id, buyer_name, seat) ON orders TO organizer_app; COMMIT; -- 確認：会員テーブルと購入記録の member_id が読めないこと SELECT has_table_privilege('organizer_app', 'members', 'SELECT') AS members_table, has_column_privilege('organizer_app', 'orders', 'member_id', 'SELECT') AS orders_member_id, has_column_privilege('organizer_app', 'orders', 'buyer_name', 'SELECT') AS orders_buyer_name; -- 期待値: members_table = f, orders_member_id = f, orders_buyer_name = t ``` 手順1を省けない理由は、[PostgreSQLのGRANTの説明](https://www.postgresql.org/docs/current/sql-grant.html)にあります。列への操作は、その列の権限かテーブル全体の権限のどちらかがあれば通り、テーブル単位で付与したあとに1列だけ取り消しても、テーブル単位の付与は残ると明記されています。「全部許してから危ない列を外す」書き方は効きません。ロールの実効権限には `PUBLIC` に付与された権限も足されるため、`PUBLIC` からも外します。確認に使った `has_table_privilege` と `has_column_privilege` は[システム情報関数](https://www.postgresql.org/docs/current/functions-info.html)の一つで、デプロイ後の自動テストに入れておくと、権限の付け直しで戻ったときに気付けます。 ### RLSで主催者ごとの購入者だけを返す設定と所有者ロールの抜け道 列を絞っても、主催者Aが主催者Bの公演の購入者名を読めるなら、漏れ方の規模は変わりません。行の範囲は、RLS（Row Level Security）で主催者ごとに切ります。 ``` -- orders に RLS を有効化（ポリシーが無い行は誰にも見えない） ALTER TABLE orders ENABLE ROW LEVEL SECURITY; -- 主催者向けロールには、自分の organizer_id の行だけを返す CREATE POLICY organizer_own_orders ON orders FOR SELECT TO organizer_app USING (organizer_id = current_setting('app.organizer_id', true)::bigint); -- アプリ側：ログイン中の主催者IDをトランザクションごとに設定する BEGIN; SET LOCAL app.organizer_id = '1024'; SELECT order_id, buyer_name, seat FROM orders; -- 1024 の行だけが返る COMMIT; ``` `current_setting` の第2引数を `true` にすると、設定し忘れたときにエラーでなくNULLが返り、条件が成り立たずに0行になります。設定漏れが「全件見える」ではなく「何も見えない」に倒れる書き方です。[PostgreSQLのRow Security Policies](https://www.postgresql.org/docs/current/ddl-rowsecurity.html)によると、RLSを有効にしてポリシーが無い場合は既定で拒否になります。一方で、テーブルの所有者、スーパーユーザー、`BYPASSRLS` 属性を持つロールはRLSを素通りします。マイグレーション用の所有者ロールでアプリを接続すると、上の設定は何も守りません。所有者にもRLSをかけたい場合は `ALTER TABLE ... FORCE ROW LEVEL SECURITY` を使います。 RLSには限界もあります。主催者IDはアプリが `SET LOCAL` で渡すため、アプリが[SQLインジェクション](https://www.issoh.co.jp/column/details/3030/)などで乗っ取られれば、攻撃者は別の主催者IDを設定できる。RLSが防ぐのはアプリの条件の書き忘れであって、アプリ自体の侵害ではありません。それでも列権限の範囲は越えられないため、パスワードハッシュとカード関連情報は守れます。RLSの基本は[RLS（Row Level Security）とは](https://www.issoh.co.jp/tech/details/5442/)で解説しています。 ## パスワード登録を8〜64文字・記号可にする実装｜NIST SP 800-63B-4との差 ### GETTIISの8〜64文字と記号可への変更をNISTの15文字基準と並べた差 GETTIISは10月20日20時に、パスワードを8〜64文字にし、記号も使えるようにしました。変更前の条件は公表されていませんが、「より長いパスワードや記号を含むパスワードを設定できるようになりました」という説明から、以前は長さと文字の種類に制限があったと読めます。 [NIST SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html)の3.1.1.2節は、最大長を64文字以上にすること、印字可能なASCII文字とスペースを受け付けることを推奨（SHOULD）し、文字種の混在を求めるルールは課してはならない（SHALL NOT）としています。最小長は、パスワードだけでログインさせるなら15文字以上、多要素認証の一要素としてだけ使うなら8文字以上です。GETTIISの64文字と記号の受け付けはこの推奨に沿う変更で、8文字という下限は多要素認証を前提とした値に当たります。GETTIISが多要素認証を提供しているかは、公式発表に書かれていません。社内ポリシーへの落とし込み方は[パスワード管理のベストプラクティス](https://www.issoh.co.jp/column/details/13508/)にまとめています。 ### 長さと漏えい照合だけで判定するPythonの登録時バリデーション NISTに沿う登録時の判定は、長さとブロックリストの2つだけです。英大文字や記号を必須にする判定は書きません。 ``` # Python 3.10 以降・標準ライブラリのみ MIN_LEN_SINGLE_FACTOR = 15 # パスワードだけでログインさせる場合 MIN_LEN_WITH_MFA = 8 # 多要素認証の一要素としてだけ使う場合 MAX_LEN = 64 def validate_password(password: str, mfa_enabled: bool, blocklist: set[str]) -> list[str]: """登録できない理由を返す（空のリストなら登録してよい）""" errors = [] min_len = MIN_LEN_WITH_MFA if mfa_enabled else MIN_LEN_SINGLE_FACTOR if len(password) < min_len: # len は Unicode のコードポイント数 errors.append(f"{min_len}文字以上にしてください") if len(password) > MAX_LEN: errors.append(f"{MAX_LEN}文字以内にしてください") if password in blocklist: # 部分一致ではなくパスワード全体で照合する errors.append("漏えい済みか推測されやすいパスワードです") return errors if __name__ == "__main__": blocklist = {"password123", "qwerty12345"} print(validate_password("password123", True, blocklist)) # ['漏えい済みか推測されやすいパスワードです'] print(validate_password("correct horse battery staple", False, blocklist)) # [] ``` Pythonの `len()` はコードポイント数を返すため、NISTの「各Unicodeコードポイントを1文字と数える」という要件にそのまま合います。ブロックリストの照合もNISTの要件です。照合の対象はパスワードに含まれる一部の単語ではなく、入力されたパスワードの文字列全体です。実運用では手書きの集合ではなく、漏えい済みパスワードのデータベースと照合します。k-匿名性で照合するAPIの使い方は[パスワードリスト攻撃とは](https://www.issoh.co.jp/tech/details/18730/)で解説しました。 ## 会員テーブルを別DB・別ネットワークに分ける判断｜分離の4段階と見送る場面 ### 分離の4段階｜ロール分離・スキーマとビュー・別DBとAPI・別ネットワーク 管理系と会員データの分け方は、強さの順に4段階あります。 | 段階 | 分け方 | 管理系が侵害されたとき | | -- | --------------- | --------------- | | 1 | DBロールの列権限とRLS | 許した列・行は読まれる | | 2 | 会員テーブルを別スキーマ化 | 公開したビューの範囲は読まれる | | 3 | 会員DBを分けAPI経由に限定 | APIが返す範囲だけ読まれる | | 4 | 会員DBを別ネットワークに配置 | 接続元以外からは届かない | 実務で最初に入れるのは段階1です。追加の機器も費用も要らず、前の章のSQLを流してテストに組み込めば終わります。段階3では、管理系アプリが会員DBの接続情報を持たなくなります。APIの側で件数の上限や主催者の認可を確かめられるため、一度に31万件を抜き取る形の漏えいは起きにくい。APIの認可とレート制限の実装は[API不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)で扱っています。 ### 別DB化まで進めるべき条件と、ロール分離だけで止めてよい規模の場面 段階3以上に進めるべきなのは、次のどれかに当てはまる場合です。管理系の利用者が社外の主催者や加盟店など自社の外にいる、会員が10万件を超える、カード関連情報やパスワードハッシュを同じDBに持っている。Gettii-Liteのように外部の事業者がログインする管理画面は、社内の管理画面よりも攻撃者が触れる面が広くなります。この条件で同じDBを共有し続けるのは、構成の段階で失敗しています。 段階1で止めてよいのは、管理画面を使うのが社内の数名だけで、社内ネットワークかVPNからしか開けず、会員数が数千件規模の場合です。この規模で別DBとAPIを用意すると、運用の手間が守れるデータの価値を上回ります。ただし、管理系アプリがテーブルの所有者ロールで接続している状態は、規模にかかわらず直してください。最小権限の考え方は[ゼロトラストネットワークの7つの要件](https://www.issoh.co.jp/column/details/4239/)でも整理しています。 ### 外部の脆弱性診断で確かめたい管理系画面から会員DBまでの到達経路 権限の設計は、図面で正しくても、本番のロールの付与状況とずれていれば効きません。診断で確かめるのは、管理画面の入力から会員テーブルへ届く経路があるか、管理系アプリの接続ロールが所有者や `BYPASSRLS` を持っていないか、アプリのサーバーに会員DBの接続情報が残っていないか、の3点です。主催者や加盟店にログインさせる管理画面を運営していて、外からの検査で到達経路を洗い出したい場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で相談できます。 ## よくある質問 GETTIISへの不正アクセスについて、会員と主催者から出やすい質問をまとめました。2026年10月22日時点の公式発表に基づきます。 ### GETTIISから漏えいのメールが届いていなければ対象外ですか？ 第二報では、漏えいの対象になった会員には個別にメールで連絡済みとされています。届いていなければ対象外の可能性が高いものの、迷惑メールのフォルダに入っていることもあります。受信箱を探しても見当たらない場合は、GETTIISの公式サイトのお知らせから開いた第二報の窓口に問い合わせてください。どちらにしても、パスワードの変更と、使い回している他のサービスのパスワード変更は済ませておくと安心です。 ### クレジットカードの再発行は必要ですか？ 公式発表は再発行を求めていません。漏れたのはカード番号の先頭4桁と末尾4桁、名義、有効期限を暗号化した情報で、完全なカード番号とセキュリティコードは保存されていないため、漏れた情報だけでは決済できないと説明されています。不安な場合は、カード会社のアプリや公式サイトで利用明細を確かめ、身に覚えのない請求があればカード会社へ連絡してください。 ### 漏えいしたのはいつ時点の登録情報ですか？ 第三者が会員情報を取得したのは、2026年10月18日の午前0時頃から7時頃とされています。その時点の登録内容が対象です。それより後に電話番号やメールアドレスを変えた場合、マイページに出ている今の値は漏れておらず、変える前の値が漏れています。マイページで見られるのは今の登録状況なので、変更の履歴は自分で思い出して照らし合わせる必要があります。 ### 主催者としてGettii-Liteを使っていますが何をすればよいですか？ 第二報が漏えいの対象として示しているのはGETTIISの会員情報で、主催者アカウントの情報については記載がありません。主催者側でまず行うのは、Gettii-Liteのログインパスワードの変更と、同じパスワードを使っている他のサービスの変更です。自社の公演でチケットを買った顧客への案内が必要かどうかは、リンクステーションに確認してください。自社でも会員情報を持っているなら、個人情報保護委員会への報告の要否を確かめます。 ### 10月21日の緊急メンテナンスは今回の不正アクセスと関係がありますか？ GETTIISの告知は、10月21日22時から翌2時までの緊急メンテナンスの目的を「PHPの重大な脆弱性へのセキュリティ対策」とし、IPAの注意喚起を関連情報に挙げています。今回の不正アクセスとの関係については何も書かれていません。PHPの脆弱性は同じ時期に広く報じられたもので、Gettii-Liteで悪用された脆弱性と同じものかは、公表された情報からは判断できません。 ## 関連記事 - [RLS（Row Level Security）とは？DBの行レベルセキュリティの仕組みと設定例](https://www.issoh.co.jp/tech/details/5442/)：主催者ごとに行を切るRLSの基本 - [RBACとは？ロールベースアクセス制御の仕組みと導入判断を実装視点で解説](https://www.issoh.co.jp/tech/details/6488/)：管理画面の権限をロールで設計する考え方 - [API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効](https://www.issoh.co.jp/tech/details/18346/)：会員DBをAPI経由にしたときの認可と件数制限 - [パスワードリスト攻撃とは？検知の指標と漏えい照合・レート制限の実装](https://www.issoh.co.jp/tech/details/18730/)：漏れたパスワードが他サービスで試される手口 - [個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務](https://www.issoh.co.jp/column/details/17840/)：漏えい発覚後の報告の段取り --- 出典: [GETTIIS不正アクセスの件数と対応：主催者向けGettii-Liteから会員DBを分ける設計]()（株式会社一創）