3. 数据安全与加密：为你的自动化流程穿上防弹衣

聊到数据安全，我脑子里第一个蹦出来的画面，是几年前帮一家金融客户做流程自动化改造。他们有个核心系统，每天要处理几万条客户交易记录。结果上线第一天，安全审计就亮了红灯——数据在传输过程中是明文的。说白了，就像你在大街上把银行卡密码喊出来一样危险。

所以这一章，咱们重点聊聊怎么给数据穿上「防弹衣」。我会从传输、存储、密钥管理到脱敏，一步步拆解。

3.1 数据传输加密：TLS 1.3 是底线

先说传输层。现在谁还用 HTTP 明文传输？那简直是裸奔。我个人习惯，所有 API 调用、服务间通信，必须强制走 HTTPS，而且协议版本至少是 TLS 1.2，最好直接上 TLS 1.3。

为什么我偏爱 TLS 1.3？因为它比 1.2 快了一个量级。握手只需要 1-RTT（一次往返），而 1.2 需要 2-RTT。你想想看，在自动化流程里，成千上万次调用，每次省一个往返，延迟能降多少？

这里有个配置示例，我一般会在 Nginx 或 Envoy 里这样写：

# 强制 TLS 1.3，禁用不安全的密码套件
ssl_protocols TLSv1.3;
ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256';
ssl_prefer_server_ciphers on;
ssl_ecdh_curve X25519:prime256v1;
小提示： 我曾经遇到过一个坑——有些老旧系统不支持 TLS 1.3，导致握手失败。我的做法是：在网关层做协议降级兼容，但内部服务间通信必须强制 1.3。说白了，对外留个口子，对内严加防守。

3.2 数据存储加密：AES-256 是标配

数据到了磁盘上，更不能裸着。我见过太多案例，数据库被拖库，几百万条用户信息直接泄露。所以存储加密，我推荐用 AES-256-GCM。

为什么是 GCM 模式？因为它同时提供了加密和完整性校验。你想想看，如果只加密不校验，攻击者篡改了密文，你解密出来就是一堆乱码，甚至可能被利用做 padding oracle 攻击。GCM 模式自带认证标签，能检测数据是否被篡改。

在代码里，我一般这样实现：

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os

def encrypt_data(plaintext: bytes, key: bytes) -> bytes:
    # 生成随机 nonce，每次加密必须不同
    nonce = os.urandom(12)
    aesgcm = AESGCM(key)
    ciphertext = aesgcm.encrypt(nonce, plaintext, None)
    # 返回 nonce + 密文，方便解密时提取
    return nonce + ciphertext

def decrypt_data(data: bytes, key: bytes) -> bytes:
    nonce = data[:12]
    ciphertext = data[12:]
    aesgcm = AESGCM(key)
    return aesgcm.decrypt(nonce, ciphertext, None)
注意： 千万不要用固定的 nonce！我见过有人图省事，把 nonce 写死在代码里。结果呢？同样的密钥、同样的 nonce，加密两次相同的明文，得到的密文完全一样。攻击者一看就知道「哦，这两条数据内容相同」。这等于把信息泄露了一半。

3.3 密钥管理方案：别把钥匙挂在门上

加密算法再强，密钥泄露了全白搭。所以密钥管理，是数据安全的核心中的核心。

我个人强烈建议，不要自己写密钥管理系统。轮子已经有人造好了，而且造得比你好。我常用的两个方案：

  • AWS KMS / 阿里云 KMS： 适合云原生架构。密钥由云厂商的硬件安全模块（HSM）保护，你只需要调用 API 加解密。好处是省心，坏处是绑定厂商。
  • HashiCorp Vault： 适合混合云或自建机房。Vault 支持动态密钥、密钥轮换、审计日志。我在一个金融项目里用过，它甚至能做到「密钥用完即焚」——每次服务启动时申请一个临时密钥，服务关闭后密钥自动失效。

这里是一个 Vault 的简单配置示例，用于自动轮换数据库密码：

# Vault 策略：允许读取数据库动态密钥
path "database/creds/my-role" {
  capabilities = ["read"]
}

# 应用启动时获取临时凭证
vault read database/creds/my-role

# 输出示例：
# Key                Value
# ---                -----
# lease_id           database/creds/my-role/abc123
# lease_duration     1h
# lease_renewable    true
# password           A1b2C3d4E5f6
# username           v-token-my-role-xyz789
核心原则： 密钥永远不要出现在代码里、配置文件里、日志里。我曾经接手过一个项目，密钥直接写在 application.yml 里，还上传到了 Git 仓库。嗯，那感觉就像把家门钥匙挂在门外，还贴了张纸条「钥匙在此」。

3.4 敏感数据脱敏策略：该藏的藏，该露的露

最后聊聊脱敏。很多流程自动化系统需要处理用户手机号、身份证号、银行卡号。但你不能把这些数据原样存到日志里、传到下游系统里。

我的脱敏策略分三级：

级别 场景 示例
L1 - 完全脱敏 日志输出、监控告警 手机号：138****1234
L2 - 部分保留 客服查询、业务审核 身份证：110101******5678
L3 - 明文 支付交易、实名认证 银行卡号：6222021234567890

具体实现时，我习惯用注解 + AOP 的方式，在数据出系统前自动脱敏。比如：

@Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Sensitive {
    SensitiveLevel level() default SensitiveLevel.L1;
}

// 使用示例
public class UserDTO {
    @Sensitive(level = SensitiveLevel.L1)
    private String phone;
    
    @Sensitive(level = SensitiveLevel.L2)
    private String idCard;
    
    private String name; // 不脱敏
}
避坑指南： 我曾经犯过一个错——在日志框架里直接打印了完整的请求体。结果生产环境一出问题，日志里全是用户的明文手机号。后来我加了个 Logback 的过滤器，对所有包含敏感字段的日志自动替换。嗯，从那以后，我再也不敢在日志里偷懒了。

好了，数据安全这块，说白了就是三件事：传输用 TLS 1.3 加密通道，存储用 AES-256-GCM 加密数据，密钥用 KMS 或 Vault 托管。至于脱敏，记住一个原则：能少暴露就少暴露，能脱敏就脱敏。做到这几点，你的自动化流程至少能挡住 90% 的常见攻击。

← 上一章 📖 返回目录 下一章 →