API：区分数据令牌化、加密与访问令牌

发布 · 更新 · API与系统集成 · 9 分钟阅读 · 作者 Cyber Intelligence Embassy

内容摘要

替代敏感数据的令牌与授予访问权限的令牌用途不同。令牌的使用范围和服务端权限检查仍然决定实际保护效果。

无人设备间内的通信机架与网络布线
本文目录

替代敏感数据的令牌与授予访问权限的令牌用途不同。令牌的使用范围和服务端权限检查仍然决定实际保护效果。

替代值不代表风险消失

令牌化用另一个值替代敏感值。设计可以是可逆或不可逆的，也可以使用或不使用映射保险库。令牌仍可能支持关联分析或获准操作，因此被盗并不一定无害。假名化不等于匿名化：符合GDPR条件时，相关数据仍属个人数据。

分别保护通道与每项操作

TLS保护其终止点之间的通信，不能修复授权缺陷或已被入侵的服务器。签名JWT不一定经过加密，其载荷可能可读。应按协议验证签名、签发者、目标接收方和有效性，再检查对象权限。OAuth应参考RFC 9700，并根据架构确定有效期、撤销机制和防重放措施。

三类机制及其保护边界

三类机制及其保护边界
机制作用需要检查的边界
数据令牌化替代敏感值。映射关系、重新识别及令牌仍可执行的操作。
加密通过密钥保护机密性。密钥管理及解密后的暴露。
访问令牌向服务出示授权。被盗的Bearer令牌可能被重放；服务端仍须检查权限。

来源与适用范围

编辑核验日期：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。不能悄悄重绑旧凭据；新注册必须经过计划的身份验证路径。

W3C — Web Authentication Level 2

修改数据库能更改通行密钥的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

一手资料：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