--- title: "TiDB Cloud不正アクセスの範囲と対応：APIキー交換と監査ログ確認の手順" url: "https://www.issoh.co.jp/tech/details/18773/" published: 2026-10-23 updated: 2026-10-23 categories: ["セキュリティ"] publisher: "株式会社一創" --- # TiDB Cloud不正アクセスの範囲と対応：APIキー交換と監査ログ確認の手順 PingCAPは2026年10月21日、第三者が不正に取得したアカウントの認証情報で同社の社内システムに入り、データを複製したと公表しました。日本国内で最大約5万件の個人情報が漏洩し、TiDB Cloudのユーザー名やメールアドレス、SQLエディタの実行履歴、APIキーの一部が含まれます。本記事では、日本語版と英語版の公式発表から対象になる情報と時系列を整理し、TiDB Cloudを使う企業が行う4つの対応を具体的な手順として示す構成です。APIキーの交換はDigest認証のcurlで、コンソール監査ログの確認はPythonで、データベースユーザーのパスワード変更はALTER USERで示します。 ## まとめ：TiDB Cloud不正アクセスで公表された範囲と利用企業が今週行う4つの対応 確認されているのは、9月9日から10月7日（米国時間）にPingCAPの社内システムからデータが複製されたことです。対象はTiDB Cloudのアカウント情報、取引関連情報、APIキーのPublic Key部分（暗号化済み）の3区分。PingCAPと外部調査機関の調べでは、TiDB Cloudそのものへの不正アクセスとクレジットカード情報の流出は確認されていません。 利用企業が行うのは、公式発表の「お客様にお願いしたい対応」に沿った次の4つです。 1. TiDB CloudのAPIキーを新しいものへ交換し、旧キーを削除する 2. コンソール監査ログと関連するクラウドアカウントのログで、不審なIPアドレスや身に覚えのない操作を探す 3. 組織メンバーとロールを見直し、不要なアカウントを削除する 4. PingCAPを装うメールに返信せず、リンクを開かない この4つに加えて、SQLエディタやサポートチケットにパスワードや接続文字列を書いたことがあるなら、その値も変えます。漏れたのは「実行したSQLの文面」だからです。 ## 自社は対象か｜TiDB Cloudアカウント情報・取引情報・APIキーの3区分 ### 日本語版の発表が挙げた3区分と国内最大約5万件に含まれる項目 [PingCAP株式会社の公式発表](https://pingcap.co.jp/trust-hub/security/security-update-october-2026/)は、影響が確認された情報を3つに分けています。すべての利用者に全項目が当てはまるわけではない、と同社は断っています。 | 区分 | 含まれる項目 | | ------- | ------------------------- | | アカウント情報 | ユーザー名、メール、組織とプロジェクトの関連付け | | アカウント情報 | SQLエディタ実行履歴・エラー（クラスタID含む） | | アカウント情報 | サポートチケット（10月21日13時05分に追記） | | 取引関連情報 | 氏名、メール、企業名、電話番号、契約条件 | | 認証情報 | APIキーのPublic Key部分（暗号化済み） | 日本語版は、Private Key部分は流出していないため、Public Keyだけではクラスタを操作できないとしています。それでも同社はAPIキーの交換を求めています。取引関連情報には請求設定や支払い条件も入るため、経理部門宛ての偽の請求連絡にも備えてください。TiDB Cloudの構成そのものは[TiDBとは](https://www.issoh.co.jp/tech/details/16005/)で解説しています。 ### 英語版の報告にあるソースコードの取得と認証情報など調査中とされた論点 米国本社の[英語版の報告](https://www.pingcap.com/trust-hub/security/security-update-october-2026/)は、日本語版より踏み込んでいます。侵入に使われたのは盗まれたサービスアカウントの認証情報で、データの複製に加えてソースコードも取得されたと書いています。 APIキーの記述も少し違う。英語版は「書き出されたテーブルに暗号化されたAPIキーの値が入っていた」とし、外部の調査会社が自社保有の値で試した結果、そのままではAPIキーとして使えなかったと述べます。そのうえで、ほかに使える認証情報が漏れたかどうかは調査中としています。サポート資料に認証情報が含まれていたという攻撃者の主張も、未検証の扱いです。日本語版の「Private Keyは流出していない」だけを根拠に交換を後回しにする判断は、英語版の記述とかみ合いません。 ## 9月9日の侵入から10月21日の追記まで｜日米2つの公式発表の時系列 ### 侵入期間28日間と認証情報の無効化から経路遮断までの対応日付 2つの版を日付順に並べると、認識から経路の遮断まで1週間かかっています。 | 日付（米国時間） | 出来事 | | ------------ | --------------------- | | 9月9日〜10月7日 | 社内システムへの不正アクセスとデータの複製 | | 10月7日 | 認識し、影響を受けた認証情報の無効化を開始 | | 10月10日 | 追加の認証情報を削除、過剰な権限を除去 | | 10月12〜13日 | 外部調査会社が脆弱性4件を報告 | | 10月14日 | 4件を修正、特定した経路をすべて遮断 | | 10月19日 | 英語版の報告を公開 | | 10月21日（日本時間） | 日本語版を公開、13時05分に追記 | 英語版は、10月19日時点の残作業として、顧客ごとの影響範囲の特定と、修正前の脆弱性が悪用されていたかの確認を挙げています。影響が特定できた顧客には個別に連絡するとしているため、連絡が来ていないことは対象外の証拠になりません。 ## TiDB CloudのAPIキーを交換する手順｜新キーの疎通確認から旧キー削除まで ### APIキーを使っている場所の棚卸しと公式サンプルの環境変数名 TiDB CloudのAPIキーは、組織設定（Organization Settings）で作るPublic KeyとPrivate Keyの組です。[Identity Access Management](https://docs.pingcap.com/tidbcloud/manage-user-access/)の表では、APIキーを管理できるのはOrganization Ownerだけ。[公式のAPIサンプル](https://github.com/tidbcloud/tidbcloud-api-samples)は、Private Keyは作成画面を離れると二度と表示されないと注意しています。 交換の前に、旧キーを使っている場所を洗い出します。CIの秘密情報、Terraformの変数、バックアップやスケールの運用スクリプトが典型です。公式サンプルは `TIDBCLOUD_PUBLIC_KEY` と `TIDBCLOUD_PRIVATE_KEY` という環境変数名を使っているため、リポジトリをこの名前で検索すると漏れが減ります。 ``` # 追跡中のファイルと過去のコミットから、キーの参照箇所だけを出す（値は表示しない） git grep -n -E "TIDBCLOUD_(PUBLIC|PRIVATE)_KEY" git log --all -G "TIDBCLOUD_(PUBLIC|PRIVATE)_KEY" --format="%h %ad %s" --date=short --name-only ``` 過去のコミットに値そのものが入っていた場合は、今回の事故とは別に漏えい済みとみなします。キーの保管と失効の設計は[APIキー管理とは](https://www.issoh.co.jp/tech/details/16300/)にまとめました。 ### Digest認証のcurlで新キーを確かめてから旧キーを削除する順番 [TiDB Cloud APIの概要](https://docs.pingcap.com/api/tidb-cloud-api-overview/)によると、すべてのリクエストはHTTP Digest認証で処理され、キーそのものはネットワークに流れません。curlなら `--digest` を付けます。新しいキーを作ったら、先に疎通を確かめてから各所へ配り、最後に旧キーを消します。 ``` # 1. 新しいキーで、プロジェクト一覧が取れることを確かめる export TIDBCLOUD_PUBLIC_KEY="新しいPublic Key" export TIDBCLOUD_PRIVATE_KEY="新しいPrivate Key" curl --digest --silent --output /dev/null --write-out "%{http_code}\n" \ --user "${TIDBCLOUD_PUBLIC_KEY}:${TIDBCLOUD_PRIVATE_KEY}" \ "https://api.tidbcloud.com/api/v1beta/projects?page=1&page_size=10" # 2. 200 が返ったら、CI・Terraform・運用スクリプトの秘密情報を新しいキーへ差し替える # 3. 組織設定で旧キーを削除し、旧キーで同じリクエストが通らないことを確かめる curl --digest --silent --output /dev/null --write-out "%{http_code}\n" \ --user "旧Public Key:旧Private Key" \ "https://api.tidbcloud.com/api/v1beta/projects?page=1&page_size=10" ``` 順番を逆にして旧キーを先に消すと、差し替え漏れの自動処理が夜間のバックアップで止まります。旧キーの削除は、コンソール監査ログに `DeleteAPIKey` として記録されます。次の章の手順で、作成と削除の記録が自社の担当者とIPアドレスになっているかまで確かめてください。トークンの失効を設計に組み込む方法は[API不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)で扱っています。 ## コンソール監査ログで不審な操作元を洗い出す｜operator\_ipとAPIキー操作 ### 既定で無効・保持90日というコンソール監査ログの前提と書き出し期限 [Console Audit Loggingの公式ドキュメント](https://docs.pingcap.com/tidbcloud/tidb-cloud-console-auditing/)には、確認の前に知っておくべき条件が3つあります。機能は既定で無効で、有効にする前の操作は記録されません。ログの保持は90日で、過ぎると自動で消えます。見られるのはOrganization OwnerかOrganization Console Audit Managerのロールを持つ人だけです。 侵入が始まった9月9日の記録は、90日後の12月8日前後から消え始める計算になります。有効にしていた組織は、いまのうちにJSONかCSVで書き出して保管してください。無効だった組織は、ここで有効にしても過去は見えません。その場合は、関連するクラウドアカウント（AWSのCloudTrailなど）とアプリケーション側のログで確認を代替します。 ### 書き出したJSONから許可外IPと要確認イベントを抽出するPythonスクリプト ログの各行には、イベント種別の `type`、時刻の `ends_at`、操作者の種類が `user` か `api_key` かを示す `operator_type`、操作元の `operator_ip` が入ります。次のスクリプトは、書き出したJSONから9月8日以降の行を読み、社内やCIの許可済みIPに含まれない操作元、APIキーによる操作、APIキーやメンバー・接続設定を変えるイベントを一覧にします。 ``` # check_console_audit.py # 使い方: python check_console_audit.py audit_logs.json allowed_ips.txt import ipaddress import json import sys from datetime import datetime, timezone SINCE = datetime(2026, 9, 8, tzinfo=timezone.utc) # 侵入開始（米国時間9月9日）の前日から見る WATCH = { "CreateAPIKey", "EditAPIKey", "DeleteAPIKey", "InviteUserToOrganization", "UpdateUserRoleInOrganization", "InviteUserToProject", "UpdateIPAccessList", "SetRootPassword", "OpenWebSQLConsole", "CreateAWSVPCPeering", "CreatePrivateEndpointService", "RestoreFromBackup", } def load_logs(path): with open(path, encoding="utf-8") as f: text = f.read().strip() try: data = json.loads(text) except json.JSONDecodeError: # 1行1件の形式 return [json.loads(line) for line in text.splitlines() if line.strip()] if isinstance(data, dict): # 配列を包んだ形式 data = next((v for v in data.values() if isinstance(v, list)), [data]) return data def to_utc(value): if isinstance(value, (int, float)): return datetime.fromtimestamp(value / 1000 if value > 1e12 else value, tz=timezone.utc) dt = datetime.fromisoformat(str(value).replace("Z", "+00:00")) return dt if dt.tzinfo else dt.replace(tzinfo=timezone.utc) def load_networks(path): with open(path, encoding="utf-8") as f: return [ipaddress.ip_network(l.strip()) for l in f if l.strip() and not l.startswith("#")] def is_allowed(ip, networks): try: addr = ipaddress.ip_address(ip) except ValueError: return False return any(addr in n for n in networks) logs = load_logs(sys.argv[1]) networks = load_networks(sys.argv[2]) hits = [] for e in logs: if not e.get("ends_at"): continue when = to_utc(e["ends_at"]) if when < SINCE: continue reasons = [] if not is_allowed(e.get("operator_ip", ""), networks): reasons.append("許可外IP") if e.get("operator_type") == "api_key": reasons.append("APIキー操作") if e.get("type") in WATCH: reasons.append("要確認イベント") if reasons: hits.append((when.isoformat(), e.get("type"), e.get("operator_name"), e.get("operator_ip"), e.get("result"), "・".join(reasons))) for row in sorted(hits): print(*row, sep="\t") print(f"{len(hits)} / {len(logs)} 件を抽出", file=sys.stderr) ``` `allowed_ips.txt` には、社内の出口IPやCIのIP範囲を1行に1つ、`203.0.113.0/24` のようなCIDRで書きます。書き出しの時刻がISO形式かエポック秒かはドキュメントに明記がないため、両方を読めるようにしました。抽出された行のうち、担当者が説明できないものを優先して調べます。特に `CreateAPIKey` と `InviteUserToOrganization` が許可外IPから成功していたら、その時点で侵入を前提に動いてください。 ## SQLエディタ履歴とサポートチケットに残った秘密情報の洗い直し ### 履歴に書いたパスワードを持つデータベースユーザーをALTER USERで変える 漏れたSQLエディタの実行履歴は、[AI-Assisted SQL Editor](https://docs.pingcap.com/tidbcloud/explore-data-with-chat2query/)で実行したSQLの文面とエラーです。`CREATE USER` や `ALTER USER` をパスワード付きで実行したことがあれば、その値は外に出たと考えます。WHERE句に顧客のメールアドレスを書いて検索した履歴も、同じく個人情報の漏えいに当たり得ます。 パスワードを書いた記憶があるユーザーは、[TiDBのALTER USER](https://docs.pingcap.com/tidb/stable/sql-statement-alter-user/)で変えます。 ``` -- 1. 現在のデータベースユーザーを一覧にし、SQLエディタで作成・変更したものに印を付ける SELECT user, host FROM mysql.user; -- 2. アプリ用ユーザーのパスワードを変える（値はパスワード管理ツールで生成し、エディタ履歴に残さない） ALTER USER 'app_rw'@'%' IDENTIFIED BY '生成した新しいパスワード'; ``` 2の文もSQLエディタで実行すれば、新しい値が再び履歴に残ります。パスワードの変更はローカルのMySQLクライアントから接続して行い、アプリケーションの接続設定を差し替えてから旧パスワードでの接続が失敗することを確かめてください。クラスタのrootパスワードはコンソールから設定し直せます（監査ログ上は `SetRootPassword`）。サポートチケットに接続文字列やキーを貼った履歴がある場合も、同じ扱いで変更します。 ### IPアクセスリストと組織メンバー・ロールを最小権限に戻す点検項目 認証情報が漏れても、接続元を絞っていれば悪用の余地は狭まります。[Dedicatedの公式手順](https://docs.pingcap.com/tidbcloud/configure-ip-access-list/)は、IPアクセスリストの「Allow access from anywhere」をきわめて危険と書き、IPアドレスかCIDRで登録する方法（最大100件）を推奨しています。StarterとEssentialは、パブリックエンドポイントのファイアウォールルールで同じ接続元制御を行う仕組みです。 メンバーの点検では、退職者や外注先の残りアカウントを消し、Organization Ownerを最小人数に絞ります。SQLエディタでデータを見られるのはProject Data Access系以上のロールなので、メトリクスやバックアップの記録を見るだけの担当者はProject Viewerへ下げます。メールとパスワードで登録しているユーザーは、[Password Authentication](https://docs.pingcap.com/tidbcloud/tidb-cloud-password-authentication/)の手順でMFAを有効にしてください。漏れたメールアドレス宛てに、パスワードやアクセスキーを尋ねる偽メールが届く時期と重なります。PingCAPの説明では、メールでそれらを尋ねることはありません。偽メールの見分け方は[フィッシング詐欺とは](https://www.issoh.co.jp/tech/details/13548/)で解説しています。 ## 全面的な鍵の作り直しを選ぶ条件と見送る場面｜利用形態別の判断基準 ### APIキー交換は全社必須、DBパスワード変更はエディタ履歴次第とする基準 APIキーを1本でも発行している組織は、交換します。Public Key部分が暗号化されていたとしても、英語版の報告は他の認証情報の露出を調査中としており、交換は新キーの作成と差し替え、旧キーの削除で終わる作業だからです。迷う理由がありません。 データベースユーザーのパスワードは、SQLエディタやサポートチケットに書いたかどうかで分けます。書いた、または書いていないと言い切れない場合は変えます。アプリケーションが別の経路で作ったユーザーだけを使い、SQLエディタを読み取りの確認にしか使っていないなら、全ユーザーの一斉変更は見送ってよい。接続先の切り替えで本番を止めるリスクのほうが大きいためです。その場合も、IPアクセスリストの点検とMFAの有効化は行います。 ### 「TiDB Cloud本体は無事」を理由に点検を止める失敗パターンと報告の要否 よくある失敗は、「TiDB Cloudへの不正アクセスは確認されていない」の一文で点検を終えることです。この一文は、PingCAPの社内システムから利用者の情報が持ち出されたことを否定していません。持ち出された情報には、組織とクラスタのIDやSQLの文面が入っています。攻撃者がそれを使って利用者の環境を狙う段階は、これから始まる可能性があります。 自社が預かる個人情報がSQLエディタの履歴に含まれていた場合は、自社の側でも漏えいの報告を検討します。[個人情報保護委員会の案内](https://www.ppc.go.jp/personalinfo/legal/leakAction/)に沿って事実を整理し、速報と確報の段取りは[個人情報保護委員会への報告義務](https://www.issoh.co.jp/column/details/17840/)で確かめてください。クラウドDBの鍵の置き場所、接続元の制限、監査ログの設定を第三者の目で点検したい場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で相談できます。 ## よくある質問 TiDB Cloudの利用企業から出やすい質問をまとめました。2026年10月23日時点の公式発表に基づきます。 ### TiDB Cloudに保存したデータそのものは漏れましたか？ PingCAPと外部調査機関の調査では、TiDB Cloudへの不正アクセスは確認されていません。英語版の報告も、TiDBに保存されたデータが影響を受けた証拠はないとしています。一方で、修正前の脆弱性が悪用されていなかったかについては、本番環境のログで確認中という説明です。持ち出されたのはPingCAPの社内システムにあった利用者の情報で、SQLエディタで実行したSQLの文面は含まれます。文面に書いた値は漏れたと考えてください。 ### 自社が対象かどうかはどう確かめればよいですか？ PingCAPは顧客ごとの影響範囲を調べており、特定できた顧客には個別に連絡するとしています。ただし、連絡を待つ必要はありません。TiDB Cloudの組織を持っていれば、アカウント情報と取引関連情報のどれかが含まれると考えて、APIキーの交換とログの確認を進めるのが安全です。不明な点は、公式発表に記載されたインシデント対応窓口へ、メールのリンクではなく公式サイトから確かめた宛先で問い合わせてください。 ### APIキーはPublic Keyだけの漏えいでも交換が必要ですか？ 必要です。PingCAP自身が、TiDB CloudでAPIキーを発行している顧客に交換を求めています。日本語版はPrivate Keyは流出していないと説明していますが、英語版では他に使える認証情報が露出したかは調査中という説明です。新しいキーをDigest認証のcurlで確かめてから各所へ配り、最後に旧キーを削除する順番なら、運用を止めずに交換できます。 ### コンソール監査ログを有効にしていなかった場合はどうすればよいですか？ コンソール監査ログは既定で無効で、有効にする前の操作は記録されません。過去の確認には使えないため、TiDB Cloudと連携しているクラウドアカウントの操作ログ（AWSならCloudTrailなど）や、アプリケーションの接続ログで代わりに調べます。今後に備えて、Organization Ownerがコンソールの設定から有効にしておいてください。保持期間は90日なので、長く残したい場合は定期的に書き出します。 ### セルフホストのTiDBを使っている場合も対応は必要ですか？ 公式発表が対象としているのは、TiDB Cloudのアカウント情報と取引関連情報、TiDB CloudのAPIキーです。自社のサーバーやKubernetesでTiDBを動かしているだけなら、これらの区分には当たりません。ただし英語版はソースコードの取得にも触れており、修正した脆弱性4件の内容は公表されていません。PingCAPのセキュリティ情報と、使っている版のリリースノートを続けて確認してください。 ## 関連記事 - [APIキー管理とは？発行・保管・失効とローテーションの実装を解説](https://www.issoh.co.jp/tech/details/16300/)：交換を定期作業にするためのキー管理の設計 - [AWS Secrets Managerとは？料金・ローテーション設定と採用判断を実装者目線で解説【2026年版】](https://www.issoh.co.jp/tech/details/15888/)：APIキーやDBパスワードの保管先の選び方 - [Studio不正アクセスで全顧客の情報流出か｜パスワード・APIキー・Webhook URLを今日替える手順](https://www.issoh.co.jp/tech/details/18389/)：同じ時期に起きたSaaS事故での鍵の替え方 - [TiDB Serverlessとは｜TiDB Cloud Starterへの改称・料金・オートスケールの仕組み](https://www.issoh.co.jp/tech/details/7541/)：Starterの構成とファイアウォールの前提 - [TiDBとは：MySQL互換の分散SQLの仕組みとHTAP・検証手順・採用判断を解説](https://www.issoh.co.jp/tech/details/16005/)：TiDBの仕組みと採用判断 --- 出典: [TiDB Cloud不正アクセスの範囲と対応：APIキー交換と監査ログ確認の手順]()（株式会社一創）