ACCESSの台湾子会社ACCESS AP TAIWANが、海外に進出するEC事業者向けに提供する業務支援サービス「CROS」で不正アクセスがあり、取引先が運営する通販サービスの利用者の個人情報とクレジットカード情報が流出しました。ACCESSは2026年10月15日に公表し、侵入の起点は取引先1社だけに提供していたBI（Business Intelligence）ツールだったと説明しています。本記事の前半で整理するのは、対象地域・件数・カード情報の内訳・時系列という、公式発表で確認できる事実です。後半では開発・運用の担当者に向けて、BIツールに渡すデータベースの権限の絞り方と、盗まれたメール送信キーの作り直し方をSQLとAPIの例で示します。
まとめ：ACCESS CROS不正アクセスで公表された事実と事業者・開発者の対応
漏洩が確認されたのは、台湾・香港・マカオ・シンガポールの通販利用者のお客様ID15万5,280件と受注ID23万1,998件、決済が未完了だった受注のカード情報1,305アカウント分です。BIツールのアプリケーション層から侵入され、そのツールが参照できたデータベースの範囲が被害の範囲になりました。さらにサーバーから盗まれたメール送信サービスの鍵で、別のリスト宛てに不正メール11,441件が送られています。
| 項目 | 公表されている内容（2026年10月23日時点） |
|---|---|
| 兆候の検知 | 2026年9月11日 |
| 公表 | 2026年10月15日（ACCESS） |
| 侵入の起点 | 取引先1社向けのBIツール |
| 個人情報 | お客様ID15万5,280件など |
| カード情報 | 1,305アカウント（延べ1,671件） |
| 不正メール | 11,441件 |
| 未公表 | BIツールの製品名と取引先名 |
開発者が持ち帰る教訓は2つです。BIツール用のデータベースユーザーには、集計に要る列と行だけを渡すこと。外部サービスの鍵は、用途を絞って作り、漏れたら即座に失効できる状態にしておくことです。
公式発表で確かめるCROS不正アクセスの対象範囲・漏洩項目・時系列
台湾・香港・マカオ・シンガポールの通販利用者が対象とされた範囲
ACCESSの10月15日の開示によると、流出したのはAP台湾の取引先企業が運営する通販サービスの利用者の情報です。項目は氏名・電話番号・住所・メールアドレスと関連する受注情報で、対象地域は台湾・香港・マカオ・シンガポールの4つとされています。日本は対象地域に挙げられていません。
CROSを使う取引先は複数ありますが、開示は「現時点までに他の取引先企業に関連する個人情報の漏洩は確認されておりません」としています。利用者への通知を行うのは、各通販サービスの事業者です。日本から台湾などへ販売している事業者は、自社がCROSの取引先か、BIツールを提供されていた1社に当たるかを、AP台湾からの連絡で確かめることになります。
カード情報1,305アカウントの内訳とセキュリティコードまで漏れた4件
カード情報の数字は3つあり、混同しやすい箇所です。延べ件数が1,671件、重複登録や複数注文を突き合わせた後のアカウント件数が1,305件です。対象項目はカード番号・セキュリティコード・有効期限・氏名などで、全項目が漏れたのは4件、残る1,301件はセキュリティコード以外の情報でした。
漏れたカード情報は、決済が完了していなかった受注のものに限られます。開示は、決済完了時には従来からカード情報を保持していないと説明しています。つまり、決済途中で止まった注文のデータだけがデータベースに残っていました。ほかに、取引先が利用している決済サービスのアカウント情報も漏洩項目に挙がっています。
9月11日の兆候検知から10月15日の公表まで34日の時系列と措置
- 9月11日：CROSのサーバーで不正アクセスの兆候を検知し、緊急停止と隔離を実施
- 調査の過程：BIツールが起点で、アプリケーションレベルで行われた不正アクセスと判断
- 判明後：メール送信用の認証情報の無効化と更新、CROS全体を一時停止してデータベースのパスワードを変更（現在は復旧済み）
- 判明後：全取引先のカード情報にマスク処理、決済サービスの秘密鍵を更新（一部は作業中）
- 10月15日：ACCESSが適時開示で公表
BIツールから参照できたデータベース以外への影響や、CROS本体の基盤システムへの直接の侵入は検出されていないとしています。再発防止策は、BIツールのセキュリティを強化したうえでの再稼働と、決済未完了のカード情報を保持しないようにするCROS本体の改修です。
BIツールが起点になった構造：取引先1社向けツールから届いたデータベース
アプリケーション層の侵入で、ツールが参照できたデータが被害範囲を決めた理由
開示の書き方で注目すべきは、侵入が「BIツールのアプリケーションレベル」で行われ、被害が「同ツールから参照可能であったデータベース」に収まったという点です。攻撃者はサーバーの管理者権限を奪ったのではなく、BIツールが持つデータベースへの接続をそのまま使えた、と読めます。BIツールは集計のためにデータベースへ常時つながっており、その接続ユーザーに与えた権限が、侵入されたときに持ち出せる上限になります。
BIツールの脆弱性や公開設定から侵入された別の事例はLEAN BODYの不正アクセスとMetabaseの公開設定・パッチ適用で扱っています。今回の製品名は公表されておらず、同じ製品かどうかはわかりません。ツール側の更新と公開範囲を締めるのが第一の防御で、接続ユーザーの権限を絞るのは突破された後の被害を小さくする第二の防御です。
決済未完了の受注にカード番号とセキュリティコードを残さない設計
1,305アカウント分のカード情報は、決済が完了しなかった受注に残っていたものでした。決済完了後は保持しない設計でも、途中で離脱した注文の情報が消されずに残れば、そこが漏洩の対象になります。ACCESSが再発防止策に「決済未完了のクレジットカード情報自体を保持しない」改修を挙げたのはこのためです。
EC基盤を作る側は、カード番号を自社のデータベースに一度も書かない構成（決済代行会社のトークン化や外部の決済画面）を選べば、BIツールがどれほど広く読めても漏れるカード番号はありません。カード情報の保護基準の全体像はPCI DSSの12要件と準拠レベルで、決済画面を改ざんされた事例はPhotoGoodsのカード情報漏えいで解説しています。
BIツールに渡すDBユーザーの権限を最小化する手順：PostgreSQLの列単位GRANT
Metabase推奨の読み取り専用ロールとpg_read_all_dataを避ける理由
BIツールの公式ドキュメントは、専用のデータベースユーザーに読み取り専用の権限を渡すよう求めています。たとえばMetabaseのデータベースユーザーとロールのページは、CONNECTと、使うスキーマやテーブルへのSELECTを最小権限とし、全権限を付与する構成を本番で使わないよう明記しています。書き込みが必要な機能には、用途別に別のロールを作る方式です。
同じページは選択肢の1つとして、PostgreSQL 14以降の定義済みロールpg_read_all_dataを挙げています。PostgreSQLの定義済みロールの説明のとおり、これは全スキーマのテーブル・ビュー・シーケンスを読めるロールです。設定は1行で済みますが、カード列や連絡先の列まで読めるため、外部の取引先向けに出すBIツールには付けません。Metabase自体の構成と運用はMetabaseの構成とエディション差にまとめています。
取引先別のビューと列単位のSELECTでカード列と連絡先を外すSQL
取引先1社向けのBIツールには、その取引先の行だけを、集計に要る列だけ見せます。下の例は、受注テーブルから取引先Aの行と5列だけを取り出すビューを作り、BIツール用のユーザーにはそのビューの参照だけを許可します。
-- BIツール用のログインユーザー（取引先Aのツール専用）。パスワードは psql の \password で設定する
CREATE ROLE bi_tenant_a LOGIN;
-- 新しいデータベースは PUBLIC に CONNECT が付くため、外してから個別に許可する
REVOKE CONNECT ON DATABASE cros FROM PUBLIC;
GRANT CONNECT ON DATABASE cros TO app_rw, bi_tenant_a;
-- 集計用スキーマに、取引先Aの行と集計に要る列だけのビューを置く
CREATE SCHEMA report_a;
CREATE VIEW report_a.orders AS
SELECT order_id, ordered_at, total_amount, currency, status
FROM shop.orders
WHERE tenant_id = 'tenant_a';
-- BIツールにはビューだけを渡す。shop スキーマには何も付与しない
GRANT USAGE ON SCHEMA report_a TO bi_tenant_a;
GRANT SELECT ON report_a.orders TO bi_tenant_a;
-- ビューを使わず元テーブルの一部の列を許可するなら、列を並べて付与する
-- GRANT SELECT (order_id, ordered_at, total_amount, status) ON shop.orders TO bi_tenant_a;PostgreSQLのビューは、既定では元テーブルをビューの所有者の権限で読みます。BIツール用のユーザーはshop.ordersに直接の権限を持たないまま、ビューに出した5列だけを読めます。app_rwはアプリ本体が使う既存のユーザーを想定した名前です。上のSQLは本記事の環境では実行しておらず、構文はPostgreSQL 18の公式ドキュメントとMetabaseの推奨例に基づきます。
テーブル単位の付与後に列だけ取り消しても効かない落とし穴と確認クエリ
既にGRANT SELECT ON shop.ordersでテーブル全体を許可しているユーザーから、カード列だけをREVOKEしても読めるままです。PostgreSQL 18のGRANTのページは、テーブル単位で付与した権限は列単位の操作の影響を受けないと書いています。一度テーブル単位の権限を取り消し、必要な列を並べて付与し直す必要があります。
-- テーブル所有者で実行。テーブル単位の付与も列ごとに展開されて表示される
SELECT table_schema, table_name, column_name
FROM information_schema.column_privileges
WHERE grantee = 'bi_tenant_a' AND privilege_type = 'SELECT'
ORDER BY 1, 2, 3;
-- カード列と連絡先の列が読めないこと（f が返れば読めない）
SELECT has_column_privilege('bi_tenant_a', 'shop.orders', 'card_number', 'SELECT') AS card,
has_column_privilege('bi_tenant_a', 'shop.orders', 'email', 'SELECT') AS email;権限の変更後、この2本の結果を残しておくと、次に取引先が増えたときの比較に使えます。実務でまず確かめるのは2本目です。BIツール用のユーザーでカード列がtになっていたら、今回と同じ条件がそろっています。
窃取されたメール送信キーで11,441件が送られた手口と送信キーの作り直し
漏洩した宛先ではなく別のリストに送られた不正メールが示す鍵の価値
開示によると、不正メール11,441件には漏洩した個人情報は使われていません。侵入者が用意した別のリストに対し、サーバーから盗んだメール送信サービスの鍵情報で送られたと判断されています。攻撃者にとって送信キーは、正規の送信元ドメインと送信実績を借りてフィッシングメールを配る道具になります。
ACCESSはどのメール送信サービスかを公表していません。ここからは、広く使われているTwilio SendGridを例に、送信キーの作り方と失効の手順を示します。鍵の保管とローテーションの一般論はAPIキー管理の発行・保管・失効で、SendGridの基本はSendGridの直販と国内版の違いで扱っています。
scopes省略時のFull Accessキーをmail.send限定で再発行する手順
SendGridのAPIキー作成のリファレンスは、scopesを省略するとFull Access（全APIへの全権限）のキーが作られると書いています。アプリのサーバーに置くキーは、送信だけを許すmail.sendに限ります。
# 1. 送信だけを許すキーを作る（scopes を省くと Full Access になる）
curl -s -X POST https://api.sendgrid.com/v3/api_keys \
-H "Authorization: Bearer $SENDGRID_ADMIN_KEY" \
-H "Content-Type: application/json" \
-d '{"name": "cros-mail-send-2026-10", "scopes": ["mail.send"]}'
# 2. 応答の api_key をアプリの環境変数に入れ、送信できることを確かめる
# 3. 古いキーを失効させる（成功すると 204 が返る）
curl -s -o /dev/null -w "%{http_code}\n" -X DELETE \
https://api.sendgrid.com/v3/api_keys/<古いキーのapi_key_id> \
-H "Authorization: Bearer $SENDGRID_ADMIN_KEY"SENDGRID_ADMIN_KEYはキーの作成と削除ができる管理用のキーで、アプリのサーバーには置きません。SendGridのAPIキーの説明によると、キーは作成時に1回だけ表示され、削除したキーによる呼び出しは拒否されます。上のコマンドは本記事の環境では実行しておらず、削除APIのリファレンスを根拠とした記載です。漏洩が疑われるときに鍵を当日中に替える順番はStudio不正アクセスでAPIキーを今日替える手順にまとめています。
事業者の判断：取引先別にBIツールを出すEC基盤が見直す範囲と点検先
取引先が個人情報保護委員会へ報告し、AP台湾は台湾当局へ報告した分担
開示によると、BIツールを利用していたサービス事業者（AP台湾の取引先）が個人情報保護委員会への報告を進め、AP台湾は台湾当局に報告しています。利用者への通知も取引先が行い、AP台湾は情報提供と技術支援に回る形です。データを預けた側が本人と当局に向き合う構造は、日本の委託関係と同じです。
個人情報保護委員会の案内のとおり、不正の目的によるおそれがある漏洩は件数にかかわらず報告対象で、カード番号を含む漏洩も報告対象の類型にあたります。報告の期限と判断の手順は個人情報保護委員会への報告義務の実務で解説しています。越境ECで現地の基盤を使う構成を選ぶ際の参照先は、越境ECの出店方式と始め方です。
EC基盤で見直しを急ぐ構成と、第三者の脆弱性診断に任せる場面の線引き
見直しを急ぐべきなのは、複数の取引先のデータを1つのデータベースに置き、取引先ごとにBIツールやダッシュボード、外部連携を提供しているEC基盤やSaaSです。点検は4点に絞れます。BIツール用ユーザーが取引先の行と集計列だけを読めるか、未完了の決済データにカード番号が残っていないか、メール送信や決済のキーが用途限定で作られているか、そのキーを当日中に失効できる手順があるか、です。1点目が満たせていない構成では、取引先1社向けのツールの穴が全取引先のデータの穴になります。
逆に、BIツールを社内の分析担当だけが使い、社外に公開していない小規模なECサイトなら、取引先別のビュー設計までは過剰です。その場合は、BIツール用ユーザーからカード列と連絡先の列を外すだけで足ります。取引先向けのツールや公開APIが外から突ける状態になっていないかは、運用担当者が自分で確かめられる範囲に限界があるため、第三者による点検も検討の対象です。取引先に出しているBIツールやEC基盤のデータベース権限を外部の目で点検するなら、脆弱性診断・セキュリティ診断で相談できます。
よくある質問
ACCESSのCROSへの不正アクセスについて、越境EC事業者や開発者から出やすい質問をまとめました。
ACCESS CROSの不正アクセスで漏洩した情報は何ですか？
10月15日の開示では、通販利用者の氏名・電話番号・住所・メールアドレスと関連する受注情報（お客様ID15万5,280件、受注ID23万1,998件）、決済未完了だった受注のカード情報1,305アカウント分、取引先が使う決済サービスのアカウント情報が挙げられています。対象地域は台湾・香港・マカオ・シンガポールです。
日本の通販サイトの利用者は対象に含まれますか？
開示に記載された対象地域は台湾・香港・マカオ・シンガポールの4つで、日本は挙げられていません。個人情報の漏洩が確認されたのはBIツールを提供されていた取引先1社に関連するデータで、ほかの取引先の漏洩は確認されていないとされています。利用者への通知は各通販サービスの事業者が行います。
カード情報はセキュリティコードまで漏れたのですか？
1,305アカウントのうち、セキュリティコードを含む全項目が漏れたのは4件で、残る1,301件はセキュリティコード以外の情報です。延べ件数では1,671件です。対象は決済が完了していなかった受注に限られ、決済完了時のカード情報は従来から保持していないと説明されています。
侵入の起点になったBIツールの製品名は公表されていますか？
10月23日時点で、BIツールの製品名と、ツールを提供されていた取引先の名前は公表されていません。開示が述べているのは、取引先1社だけに提供していたBIツールのアプリケーションレベルで不正アクセスが行われ、そのツールから参照できたデータベース以外への影響は検出されていないという点です。
不正メール11,441件は漏洩した宛先に送られたのですか？
ACCESSは、漏洩した個人情報そのものは使われず、侵入者が用意した別のリストに送られたと判断しています。送信には、サーバーから盗まれたメール送信サービスの鍵情報が使われました。AP台湾はメール送信用の認証情報を無効化し、更新しています。
関連記事
- LEAN BODYの不正アクセスと約44万件の取得｜Metabaseの脆弱性とBIツールの公開設定・パッチ適用：BIツールが侵入口になった別の事例
- PhotoGoodsの不正アクセスとカード情報漏えい｜決済画面の改ざんとアップロード機能の締め方：カード情報が漏れた別の経路
- Studio不正アクセスで全顧客の情報流出か｜パスワード・APIキー・Webhook URLを今日替える手順：外部サービスの鍵を当日中に替える手順
- 情報漏洩対策とは：原因別4類型の防ぎ方と発生時の報告義務【2026年10月版】：漏洩の原因別の防ぎ方
- 不正アクセス対策とは：IPA・JPCERTの2026年10月注意喚起に沿った企業の点検手順：企業として点検する範囲の全体像
