機密データを置き換えるトークンと、アクセス権を提示するトークンは役割が異なります。使用範囲とサーバー側の権限確認が不可欠です。
置換した値にもリスクは残る
データのトークン化は機密値を別の値で置き換えます。可逆・不可逆の方式があり、対応表を保管する方式も、そうでない方式もあります。トークンが記録の関連付けや許可された操作に使える場合、盗難は無害ではありません。仮名化は匿名化と同じではなく、GDPRの条件を満たせば個人データのままです。
通信と個々の操作を別々に保護する
TLSが保護するのは終端間の通信であり、権限設定の誤りや侵害されたサーバーを修復しません。署名付きJWTは必ずしも暗号化されず、内容が読める場合があります。プロトコルに従って署名、発行者、対象サービス、有効性を検証し、対象ごとの権限を確認します。OAuthではRFC 9700を参照し、有効期間、失効、再利用への対策を構成に応じて定めます。
三つの仕組みと保護範囲
| 仕組み | 役割 | 確認すべき限界 |
|---|---|---|
| データのトークン化 | 機密値を置き換える。 | 対応関係、再識別、トークンで可能な操作。 |
| 暗号化 | 鍵を使って機密性を保護する。 | 鍵管理と復号後の露出。 |
| アクセストークン | サービスに権限を提示する。 | 盗まれたBearerトークンは再利用され得るため、サーバーで権限を確認する。 |
出典と適用範囲
- PCI SSC · Tokenization Product Security Guidelines · 2015 · pp. 6–8
- IETF · RFC 7519 · JSON Web Token · 2015
- IETF · RFC 9700 · OAuth 2.0 Security BCP · 2025
- EUR-Lex · GDPR / RGPD · Art. 4(5), recital 26
編集確認日：2026年10月31日。
保護されたデータと承認されたアクションを混同しないでください。
暗号化とトークン化はデータ漏洩のリスクを軽減しますが、API呼び出しがオブジェクトを読み取るか、操作をトリガーできるかを決定するものではありません。OWASPは、オブジェクトレベルと関数レベルの認証を主要なAPIリスクとして挙げています。
- 認証済みゲートウェイの背後であっても、要求された各オブジェクトとアクションの権限を確認してください。
- デモデータを使用して、アカウント間およびロール間のリクエストをテストする。
- 機密情報や機密性の高い値を平文でログに記録することなく、調査準備のための記録を保持する。
一次資料：OWASP API Security Top 10 — 2023. 関連する方法：実践ガイドを読む.
パスキー：ドメインとRP IDの変更を準備する
アカウント、ウェブのオリジン、RP IDを分け、認証情報を黙って付け替えない移行を計画します。
- 旧・新のオリジン、RP ID、対応するアカウントを記録します。同じアカウント名でもパスキーが別のRP IDに有効になるわけではありません。WebAuthnの許される組合せと移行中のログイン経路を確認します。
- 許可されたテスト環境で適切なライブラリを使い、チャレンジ、オリジン、RP ID、アカウントの関連付けを確認します。想定外のオリジンとチャレンジの再利用を試します。RP IDが変わる場合は認証済みの新規登録を準備し、行のコピーを鍵の移行と扱いません。
- 旧認証情報だけを持つ利用者、復旧、既存セッションを試します。確認した戻し方とともに経路の開設・廃止順を決めます。新ドメインでの登録成功は全旧セッションの失効を証明しません。
再現できる受け入れ事例
架空の例です。顧客や実際の観測結果を示すデータではありません。
事例の入力を見る
{
"old_origin": "https://login.old.example",
"old_rp_id": "old.example",
"new_origin": "https://login.new.example",
"new_rp_id": "new.example",
"same_service_account": true,
"expected": "authenticated_new_registration"
}期待される判断
架空例：アカウントは同じでもold.exampleから別のRP IDのnew.exampleへ移ります。旧認証情報を黙って付け替えず、新規登録は計画した認証済み経路で行います。
データベースの編集でパスキーのRP IDを変更できますか？
できません。RP IDは認証情報の検証される範囲の一部です。新しい範囲の有効な登録と認証済みのアカウント対応付けを準備します。
一次資料：W3C — Web Authentication Level 2. 関連する方法：実践ガイドを読む.
TLS更新：実際に提示される証明書を確認する
更新をTLS終端とクライアントまで追跡してから変更を完了します。
- 名前、CDN、負荷分散、プロキシ、内部接続を列挙し、提示証明書、チェーン、有効期限、担当者を記録します。発行成功は全ノードへの導入を証明しません。秘密鍵を保護し台帳に含めません。
- 提供される場合は事業者のテスト環境で自動化を試します。検証チャレンジ、SAN名、保護された保存先、再読み込みを確認します。鍵方針上使える証明書がある場合は起動ごとの発行を避けます。
- 対応クライアントと関連経路で名前、日付、信頼チェーンを確認します。TLS検証は有効に保ちます。スケジューラーだけでなく提示証明書の期限を監視します。戻すには有効証明書と侵害されていない鍵が必要で、それ以外は修正または隔離します。
再現できる受け入れ事例
架空の例です。顧客や実際の観測結果を示すデータではありません。
事例の入力を見る
{
"issuance_succeeded": true,
"proxy_count": 2,
"proxies_serving_expected_certificate": 1,
"other_proxy_certificate_expired": true,
"tls_verification_enabled": true,
"expected": "change_incomplete_fix_and_verify_client_paths"
}期待される判断
架空例：更新は成功しましたが二つのプロキシの一つが期限切れ証明書を提示します。未完了として修正し、TLS検証を無効化せず経路を確認します。
一次資料：Let’s Encrypt — Integration Guide. 関連する方法：実践ガイドを読む.
参照資料：データ・用途・限界
資料確認日 .
この言語版の詳しい参照メモは英語で提供しています。
| 出典と目的 | 確認済みのデータ・指標 | 利用方法 | 留意する限界 |
|---|---|---|---|
| MITRE · Common Weakness Enumeration Name classes of software and hardware weakness. |
A CWE describes a weakness that can contribute to vulnerabilities. It does not represent a particular incident. | Connect the weakness to the observed mechanism: input, processing and missing control. Use it to fix the cause and plan regression tests. | A keyword in a report alone does not establish the correct CWE classification. |
| OASIS · TAXII 2.1 Exchange threat intelligence through an application protocol. |
TAXII 2.1 is an OASIS Standard dated 10 June 2021. It includes service discovery and access to collections. | Test authentication, collection permissions, pagination and recovery after interruption. Record which objects were actually received and processed. | TAXII transports data; it replaces neither the content model nor assessment of reliability. |
CISA KEVカタログを調べる
この言語版の詳しい参照メモは英語で提供しています。
One identifier can span several technical layers
An entry may concern a library, server or component embedded in an appliance. Search the exact name, known dependencies and the distributed product’s advisory. Catalogue aliases are not a complete list of affected versions.
- Connect the CVE, component supplier and final-product supplier.
- Check version, configuration and execution path in the authorised environment.
- Do not infer remediation from an empty search result.
CISA KEV · 2026.11.06 · Documentary review : 2026-11-07
媒体：サニタイズと証拠
この言語版の詳しい参照メモは英語で提供しています。
Encryption and erasure require different evidence
Encryption protects access while keys and implementation retain their properties. Cryptographic erase requires suitable encrypted scope and sanitization of relevant keys; it does not follow from API-token removal.
- Map data-encryption, wrapping and derivation keys and external copies.
- Check whether target sensitive data previously existed in plaintext.
- Record technical outcome, limits and validation without retaining secrets in the evidence.
Read the methods, evidence points and annotated situations →
NIST · SP 800-88 Rev. 2 · Guidelines for Media Sanitization · Final · 2025-09-26 · consulted 2026-10-23