零信任讨论的焦点通常在网络层（微分段、mTLS）和身份层（MFA、SPIFFE）。但攻击者的最终目标不是网络，不是身份——是数据。当网络控制和身份验证都失败时（任何安全架构都可能失败），数据本身的保护是最后一道防线。

前置阅读：零信任策略引擎。

一、数据层的 Blast Radius 控制

在零信任中，每一层的 blast radius（爆炸半径）都应该被最小化。对于数据层，blast radius 不是”攻击者能访问多少服务器”，而是攻击者能读到多少条数据记录。

一个常见的盲区：服务 A 的数据库凭据被泄露了——攻击者用这些凭据连接数据库后能读取多少数据？如果服务 A 只需要访问 users 表，但数据库凭据提供了 SELECT * ON *.* 权限，blast radius 就是整个数据库（可能有几百张表）。

零信任数据安全的第一个原则：数据库授权也应该是最小权限的——每个服务账号只被授予它必要的表和操作权限：

-- 不要: GRANT ALL ON database.* TO 'payment-service';
-- 要:
GRANT SELECT, INSERT, UPDATE ON payment.transactions TO 'payment-service';
GRANT SELECT ON payment.users TO 'payment-service';
-- payment-service 不能访问 payment.audit_logs,
-- 也不能访问 user_service.profiles

二、应用层加密 vs 存储层加密

存储层加密（全盘加密、LUKS/dm-crypt、AWS EBS 加密）保护的是物理介质被窃取的场景——硬盘被从数据中心偷走，数据不可读。但它不保护运行中的系统——当攻击者通过 SQL 注入或凭据泄露获得了数据库的读取权限时，数据库服务会自动解密磁盘上的数据并返回明文结果。

应用层加密（Application-Level Encryption, ALE）在数据进入数据库之前就被应用代码加密了——数据库存储的是密文，即使是数据库管理员也无法直接读取：

// 应用层加密: 在写入数据库之前加密敏感字段
encryptedSSN, _ := kms.Encrypt(ctx, user.SSN, dataKey)
db.Exec("INSERT INTO users (name, ssn_encrypted) VALUES (?, ?)", user.Name, encryptedSSN)

// 读取时解密
rows, _ := db.Query("SELECT ssn_encrypted FROM users WHERE id = ?", userID)
var encryptedSSN []byte
rows.Scan(&encryptedSSN)
plainSSN, _ := kms.Decrypt(ctx, encryptedSSN, dataKey)

应用层加密的代价很高——你不能对加密的数据做 WHERE ssn = '123-45-6789' 查询（因为相同的明文用不同的 IV 会加密为不同的密文）。解决方案是盲索引（Blind Index）——在数据旁边存储一个单向哈希，允许等值查询但不能解密：

CREATE TABLE users (
    id INT PRIMARY KEY,
    name VARCHAR(255),
    ssn_encrypted VARBINARY(256),  -- 密文
    ssn_blind_idx VARBINARY(32)    -- HMAC(ssn, blind_index_key)
);
-- 查询: SELECT * FROM users WHERE ssn_blind_idx = HMAC('123-45-6789', blind_index_key)

零信任的数据安全取舍：应用层加密提供了最强的保护（即使数据库完全被攻破，数据也不可读），但代价是查询能力受限、性能下降（每个字段的加密/解密开销）、以及密钥管理的复杂度。

三、数据分类标签

数据分类是授权决策细化的基础——不是”这个人能不能访问数据库”，而是”这个人能不能访问标记为 PII 的数据”。

数据分类标签的层级：

数据分类的系统化实现需要在数据创建或接收时自动打标签：

• 数据库列级别：customers.ssn → RESTRICTED、products.price → CONFIDENTIAL
• 文件级别：Google Drive/Dropbox 的文件标签由数据所有者或 DLP 引擎自动设置
• API 响应级别：API Gateway 检查响应中的字段是否包含 PII，如果有，自动在访问日志中标记

四、密钥管理的零信任化

零信任的最后一层是密钥管理——加密数据的最强形式依赖于密钥，如果密钥本身被攻击者获取，前面的所有加密都无效。

DEK 和 KEK 的分离

• DEK（Data Encryption Key）：直接加密数据的密钥。每个服务、每个数据类型、甚至是每条数据记录都可以有自己的 DEK。DEK 的生命周期与该数据同步——数据被删除时，DEK 也被销毁。
• KEK（Key Encryption Key）：加密 DEK 的密钥。KEK 存储在 KMS/HSM 中，从不离开硬件安全模块。

DEK 在应用内存中可用，但 DEK 的密文（被 KEK 加密后的 DEK）存储在数据库中与数据一起。即使数据库被完全导出，攻击者也看不到 DEK 的明文——因为 KEK 在 HSM 里，且 HSM 的访问受到严格的身份和授权控制。

KMS 的访问控制应使用零信任原则： - 每次密钥操作（加密/解密）都需要验证调用者的身份（SPIFFE ID） - 调用者只能操作它的 DEK，任何尝试解封其他服务的 KEK 的操作被拒绝 - 所有 KMS 操作写入不可篡改的审计日志

五、总结

零信任数据安全的三层结构：

1. 数据库授权层：最小权限原则——每个服务账号只被授予必要的表和操作权限
2. 应用加密层（可选，根据数据敏感度）：应用层加密（ALE）——数据库存储的是密文
3. 密钥管理层：DEK/KEK 分离 + KMS/HSM 强制身份验证——密钥本身是零信任保护的

三个层次独立工作——即使攻击者越过了数据库授权（通过窃取凭据），应用层加密使数据不可读。即使应用层加密的 DEK 被从内存中提取（通过内存 dump），DEK 被 KEK 包裹，而 KEK 在 HSM 中且需要独立身份验证。

下一篇：SaaS 与云原生的零信任。

参考资料

1. NIST SP 800-53. Security and Privacy Controls for Information Systems and Organizations.
2. HashiCorp. Vault Encryption as a Service. https://developer.hashicorp.com/vault/docs/secrets/transit
3. AWS. AWS Key Management Service Cryptographic Details.