令牌化 vs. 加密：选择合适的数据保护方案

加密和令牌化都能保护敏感数据、支持合规，并出现在每一个主要的安全框架中。然而它们的工作方式从根本上不同；针对特定用例选择了不合适的方法，可能意味着放弃合规范围缩减的机会，或引入不必要的架构复杂性。

许多安全团队在这一决策上会感到困难，正是因为这两种技术在目的上存在重叠。两者都能使敏感数据对未授权方不可读。两者都支持监管要求。

不过，它们在敏感数据存放的位置、数据如何恢复以及哪些系统仍然处于合规范围内方面存在差异。这些差别会直接影响审计负担、基础设施设计以及风险态势。

正确的方法取决于身份（包括人类和 non-human）如何访问数据、数据存放在哪里，以及你究竟在降低哪些风险，从而提升网络韧性并改善整体数据安全态势。

令牌化 vs. 加密：基础知识

在将这两种方法并排比较之前，首先要理解它们各自是如何独立运作的。

以下章节将定义加密和令牌化，概述它们的核心机制，并重点说明它们的目标在哪些地方重合、哪些地方有所分歧。

令牌化（Tokenization）是什么？

令牌化（Tokenization）会用随机令牌或保持格式的令牌来替换敏感数据，并将原始数据保存在一个独立且加固的令牌库（token vault）中。16 位银行卡号会变成另一个看起来真实的 16 位值，但在无法访问该令牌库及其映射关系的情况下，它完全没有任何意义。

PCI tokenization guidelines 定义了三种令牌生成方法：

• 在数学上可逆的加密函数
• 单向不可逆的加密函数（基于哈希）
• 索引或随机分配：该令牌与原始数据在数学上没有任何关联

最后这一类，正是令牌化获得其独特安全属性的地方。如果通过随机分配创建的令牌在运行系统中暴露出来，它们不会透露底层数值。

没有用于反向还原的算法，也没有能将令牌还原为原始数据的解密密钥。返回到真实数据的唯一途径，只有通过金库本身。

什么是加密？

加密是一种可逆的转换，它使用加密算法和密钥将明文转换为不可读的密文。只要交给对方正确的解密密钥，就能把原始数据取回。

在实际应用中，加密会出现在每一层：全磁盘、数据库（TDE）、字段级、应用程序级以及传输中（TLS）。

关键依赖在于密钥管理。加密密钥会经历预激活、启用使用、停用、泄露/受损处理以及销毁等生命周期的各个阶段。每个阶段都会带来围绕密钥生成、分发、轮换和安全存储的运营要求。

令牌化（Tokenization）与加密（Encryption）的核心区别

这两种技术都旨在保护敏感数据、降低事件影响，并支持合规要求。但它们在几个关键方面有所不同：

• 可逆性：使用正确的密钥，加密始终是可逆的。令牌化仅对具有保管库（vault）访问权限的系统可逆；并且某些令牌类型（基于单向哈希）根本不可逆。
• 数据格式：标准加密可能会在不使用格式保留加密（format-preserving encryption，FPE）的情况下，彻底改变数据格式。令牌化通常可以保留原始格式，因此一张 16 位卡号仍会保持为 16 位。
• 合规范围： 加密数据对于 PCI DSS 等框架仍然在范围内，且所有具有密钥访问权限的系统也都保持在范围内。存储在令牌数据环境（token data environment）之外的令牌可能会脱离 PCI 范围，从而有可能显著降低审计负担。
• 性能： 加密会在不依赖外部组件的情况下，增加可预期的计算开销。基于保管库（vault）的令牌化会通过往返保管库查询引入延迟；而不使用保管库（vaultless）的方案则用更快的速度来换取范围方面的优势。
• 密钥管理： 加密要求在每个解密点都进行完整生命周期的密钥管理。令牌化会将这一负担集中到保管库（vault）中，从而将运营责任转移给保管库提供方。
• 最适用： 加密在传输中的数据、非结构化数据以及频繁访问的记录方面最为有效。令牌化非常适合结构化字段（PAN、SSN）、存储优先的数据以及缩小合规范围。

根本的架构差异在于，加密会让原始数据继续存在于你的环境中：没有正确的密钥就无法读取。这样既能让数据仍然广泛可用，但也要求在所有密钥存在的地方都实施强健的密钥管理。

另一方面，令牌化（tokenization）会彻底将敏感数据从运行系统中移除，并将其集中到一个加固的单一保管库（vault）中，从而尽量减少原始数据曾经出现的地点。然而，这也会增加对该保管库的依赖：它将成为你最关键的基础设施。

何时使用令牌化（tokenization）

当敏感数据需要被存储或引用，但又很少以其原始形式进行处理时，令牌化（tokenization）能够带来最大的价值。以下各部分将介绍令牌化的理想使用场景，以及如何有效实施它所需要的实际注意事项。

令牌化的最佳适用场景

令牌化在以下三个领域中最为契合：

• 支付卡数据和国家标识符： 例如 PAN、SSN、政府身份证件号码以及类似的结构化值：应用程序将这些数据用作参考，但很少需要完整的敏感值。若你的系统主要是存储并在环节之间传递账号号码，而并未对其进行实际处理，那么这类数据就是令牌化的候选项。
• SaaS 和微服务环境中的客户标识符： 当多项服务共同处理客户数据时，在入口处对标识符进行令牌化，并仅将令牌向下游传递，会带来显著收益。接触真实 PII 的系统越少，合规影响范围就越小。
• 合规范围缩减： 任何优先事项是减少需满足 PCI DSS 或类似框架要求的系统数量的环境都适用。在运营数据库和应用程序层中用令牌替换敏感值，可以显著缩小下一次评估的范围。

在这些场景中，令牌化能在保持一致的数据安全态势的同时，为数据保护和合规效率提供最佳平衡。

何时使用加密

加密并非“一刀切”的控制措施，但在某些场景中，它显然是必选或强烈推荐的方案。以下各部分将说明加密最适合在哪些情况下使用，以及现代环境如何改变组织部署和管理加密的方式。

加密最匹配的场景

在以下四个领域，加密是必选或强烈推荐的控制措施：

• 传输中的数据： 令牌化保护的是单个数据元素，而不是通信通道本身。TLS 和传输层加密是这里的基础控制措施，任何令牌化策略都无法替代它们。
• 非结构化数据： 文档、图像、通信内容以及大文本字段无法很好地适配令牌化的结构化数据模型。加密能够在文件、磁盘或应用层面自然地处理这些内容。
• 经常访问的数据： 当许多系统需要以原始形式处理数据以进行运维和分析时，加密可以让数据在你的整个环境中保持可用性，同时避免往返访问保管库（vault）。
• 备份和归档： 将密钥单独存储的加密备份能够在整个数据生命周期中持续提供保护。关键规则：切勿将加密密钥与其所保护的数据存放在一起。

在这些场景中，加密通常能在可用性与安全态势的可衡量改进之间取得最佳平衡。

将令牌化与加密结合使用

在许多环境中，最强的架构并不只依赖某一种技术。令牌化和加密分别应对不同的风险向量；将两者进行策略性组合，可以在不引入冗余复杂性的前提下提供分层保护。

为何要同时叠加这两种技术

每种技术都有彼此能弥补的空白：

• 加密可以保护传输过程中的数据并保障非结构化内容，但它不会从你的运行系统中移除敏感数据，也不会缩小合规范围。
• 令牌化会将敏感值从应用程序层中移除，并缩小您的合规影响范围，但它并不能保护这些系统所依赖的通信通道，也不会保护用于存储原始数据的金库(vault)。

将二者叠加的意义在于：对令牌化无法覆盖的内容进行加密（传输过程、非结构化数据、金库(vault)本身），同时对仅靠加密仍会落入范围的内容进行令牌化（运营数据库中静止的、结构化的敏感字段）。

每一层都应针对不同的数据状态或安全域来解决问题。如果在同一系统中对同一数据同时应用这两项控制，但并不为不同目的服务，那么结果只会增加复杂性，而不会带来额外的保护。

实际如何运作

典型的分层架构遵循以下流程：

1. 摄取： Web 应用会接收卡片数据，并通过基于 HTTPS 的 API 调用立即将 PAN 发送到令牌金库（token vault）。通信通道已加密；数据元素即将被令牌化。
2. 存储： 该金库会存储原始 PAN（在金库内静态加密）并向应用返回一个令牌。应用在其数据库中仅存储令牌，而该数据库位于 PCI DSS 范围之外。
3. 处理： 当应用需要处理付款时，它会将令牌发送回金库。金库会检索原始 PAN，并通过加密通道将其转发给支付处理方（payment processor）。
4. 范围隔离： 只有金库及其直接连接的组件会保留在持卡人数据环境（cardholder data environment）中。流程中的其他所有系统都只处理令牌或加密传输，而不是原始敏感数据。

这种模式提供端到端保护：加密覆盖传输中的数据以及静态存储在金库中的内容；令牌化则将敏感值排除在运营系统之外，并最大限度地缩小合规范围。

为你的使用场景选择合适的方法

在清楚理解每项技术如何工作以及它适用于哪里之后，下一步就是将这些能力映射到你的特定环境。以下各部分提供评估标准和决策模式，以指导这一过程。

评估标准

核心问题很简单：这些数据是否需要在处理时以原始形式进行恢复，还是主要用于存储和引用？

经常用于下游处理的数据倾向于采用加密，而很少离开其受保护状态的数据则倾向于采用令牌化。

在此起点之后，五个切实可行的标准将决定你的选择：

• 数据类型和格式：结构化字段（PAN、SSN）是天然适合进行令牌化的候选项。非结构化内容（文档、图像、自由文本字段）则需要加密。
• 访问频率和模式：许多系统需要以原始形式进行处理的数据更适合采用加密，因为加密可以避免进行 vault 往返查询。以引用方式存储并传递的数据则更适合进行令牌化。
• 性能限制：高吞吐、低延迟的工作负载可能无法承受对 vault 的查找。加密性能主要取决于你自身的处理能力和本地 I/O，通常不需要往返访问外部 vault 或服务。
• 监管驱动因素：如果降低 PCI DSS 范围是优先事项，那么令牌化提供了加密无法做到的路径。若 HIPAA 是主要框架，令牌化可以提升安全性，但不会减少范围。
• 第三方集成需求：期望特定数据格式的传统系统（legacy systems）可能会从“格式保持型（format-preserving）token”中受益。需要为分析或运营处理原始数值的系统则需要加密。

将这些标准映射回身份流（identity flows）：哪些人类用户、应用程序和服务会接触到数据，以及 数据生命周期 从摄取（ingestion）到归档（archival）会是什么样？

决策模式

这些模式在大多数环境中都很适用：

• 使用令牌化（tokenization） 当你主要是引用数据，并希望缩小合规范围时。PANS、SSNS 以及医疗记录编号——这些由你的运营系统存储，但很少以其原始形式进行处理。
• 使用加密 当许多系统必须为运营、分析或通信处理原始数据时。包括文档、事务日志、传输中的数据，以及任何非结构化内容。
• 同时使用两者 用于高风险或受监管的工作负载。对静态的结构化敏感字段进行令牌化（tokenize）。对传输中的所有内容进行加密。加密你的令牌金库（token vault）。按数据状态分层实施保护，而不是重复叠加。

当你持续一致地实施这些措施时，你会在强化网络韧性和审计准备度的同时，降低运营复杂性。

Netwrix 如何帮助组织保护敏感数据

在令牌化（tokenization）和加密（encryption）之间做选择，需要回答大多数组织无法自信回答的问题：

• 我们的敏感数据实际存放在哪里？
• 哪些系统中存放着我们未纳入范围的 PAN 或 SSN？
• 谁有访问权限？这些访问权限是否仍然有其合理性？
• 文件中存放着什么？这些文件又被用于哪里？

The Netwrix 1Secure Platform 从这种基础性的可视性入手，能够在文件系统、数据库以及类似 SharePoint 和 Teams 的协作平台中提供自动化发现与分类。仅这一项举措就足以重塑保护策略。因为身份决定谁能够在什么条件下访问敏感数据，因此，对身份与权限的可视性对于有效应用令牌化或加密至关重要。

在此之后，平台会处理加密和令牌化无法覆盖的治理层：也就是获得授权的用户访问之后会发生什么。

它会计算嵌套组成员资格所带来的实际权限，识别数据所有者，暴露仍可访问密钥管理基础设施或令牌金库的过期特权账户，并监控访问异常情况。

针对 PCI DSS、HIPAA 和 NIST 框架的持续合规性报告，用按需获取的证据替代了周期性审计的仓促应对。

请求一份 Netwrix demo ，了解 1Secure Platform 如何在混合环境中支持您的数据保护策略。