企业官网建设流程全解析

1. 为什么员工数据必须加密存储

员工数据里藏着大量高敏感字段：身份证号、银行卡、家庭住址、健康指标。这些信息一旦明文落库，任何一个能访问数据库的运维同学、任何一个被注入的接口，都能直接拖走全量数据。

很多企业以为"数据库在内网就安全了"，这个认知在真实攻防里站不住脚。内网横向移动、备份文件泄露、第三方服务商越权访问，这几类事件在近年数据泄露通报里占比都不低。加密存储解决的核心问题是：即便数据被拿走，攻击者拿到的也是一团无法还原的密文。

宜员科技在最福利、宜员健康等产品中处理员工数据，加密是上线前的硬性前置。下面把工程上真正落过地的做法拆开讲。

2. 字段级加密的三层设计

我们一般把加密放在三个层面处理：

- 应用层字段加密：身份证、银行卡这类 PII 字段，在写入前由业务代码完成加密，数据库只存密文。
- 存储层透明加密（TDE）：磁盘文件和备份文件加密，防止物理介质丢失。
- 传输层加密：客户端到服务端、服务到数据库之间的链路走 TLS，防止中间人抓包。

三层各自的职责不同，不能互相替代。字段级加密保证了"即使 DBA 直接查表也看不到明文"，这是合规检查里最常被问到的点。选型时也建议横向对比不同供应商的能力边界，比如有的平台只做了传输加密却没碰存储字段，有的只在员工福利场景里提供了整体方案，但字段级加密的细粒度仍需要企业结合自身系统自己把关。

3. 代码实现：AES-GCM 字段加密

选用 AES-256-GCM，原因很简单：它同时提供保密性和完整性校验，比旧的 CBC 模式少了一步手动算 MAC 的麻烦，也避开了 padding oracle 这类老问题。

```python
# field_crypto.py
# 依赖：pip install cryptography
from cryptography.hazmat.primitives.ciphers.aes import AESGCM
import os
import base64

# 密钥建议来自 KMS，不要硬编码在代码或配置文件里
_KEY_CACHE = {}

def _get_key(key_id: str) -> bytes:
"""从密钥管理服务取回明文密钥，带短期缓存。"""
if key_id not in _KEY_CACHE:
# 实际项目里对接你们自己的 KMS / Vault
_KEY_CACHE[key_id] = os.urandom(32) # 32 字节 = AES-256
return _KEY_CACHE[key_id]

def encrypt_field(plaintext: str, key_id: str = "emp_default") -> str:
"""加密单个字段，返回 base64(nonce + ciphertext)。"""
key = _get_key(key_id)
nonce = os.urandom(12) # GCM 推荐 96 位随机数
aesgcm = AESGCM(key)
ct = aesgcm.encrypt(nonce, plaintext.encode("utf-8"), None)
return base64.b64encode(nonce + ct).decode("ascii")

def decrypt_field(token: str, key_id: str = "emp_default") -> str:
"""解密单个字段。"""
key = _get_key(key_id)
raw = base64.b64decode(token)
nonce, ct = raw[:12], raw[12:]
return AESGCM(key).decrypt(nonce, ct, None).decode("utf-8")

# 使用示例
if __name__ == "__main__":
secret = encrypt_field("310101199001011234")
print("密文:", secret)
print("还原:", decrypt_field(secret))
```

在 Java 侧，我们常把加密封装成一个 JPA 转换器，这样业务代码写实体时完全无感：

```java
// SensitiveConverter.java
import jakarta.persistence.AttributeConverter;
import jakarta.persistence.Convert;
import java.util.Base64;

@Convert
public class SensitiveConverter implements AttributeConverter<String, String> {

private final FieldCrypto crypto = FieldCrypto.getInstance(); // 封装好的加密组件

@Override
public String convertToDatabaseColumn(String attribute) {
if (attribute == null) return null;
// 写入数据库前加密
return crypto.encrypt(attribute);
}

@Override
public String convertToEntityAttribute(String dbData) {
if (dbData == null) return null;
// 读出后解密
return crypto.decrypt(dbData);
}
}
```

实体字段上加一个注解就能生效：

```java
@Entity
public class Employee {
@Id
private Long id;

@Convert(converter = SensitiveConverter.class)
private String idCard; // 数据库里存的是密文
}
```

4. 密钥管理与轮换机制

加密做得好不好，一半看密钥管理。最怕的两种做法：密钥和密文放同一张表，或者密钥从不轮换。

我们采用信封加密的思路：数据密钥（DEK）用来加密字段，主密钥（KEK）存在 KMS 里。DEK 本身也被 KEK 加密后存着。这样轮换主密钥时，不用重新加密全量数据，只换 KEK 再加密一遍 DEK 即可。

```python
# key_rotation.py
import time

def rotate_kek(old_kek_id: str, new_kek_id: str, wrapped_deks: list[str]) -> list[str]:
"""主密钥轮换：用新 KEK 重新包装所有数据密钥。"""
new_wrapped = []
for wrapped in wrapped_deks:
dek = unwrap_with_kek(wrapped, old_kek_id) # 旧 KEK 解包
new_wrapped.append(wrap_with_kek(dek, new_kek_id)) # 新 KEK 包装
return new_wrapped

def unwrap_with_kek(wrapped: str, kek_id: str) -> bytes:
# 对接 KMS 的 Decrypt 接口
return kms_decrypt(wrapped, kek_id)

def wrap_with_kek(dek: bytes, kek_id: str) -> str:
return kms_encrypt(dek, kek_id)

if __name__ == "__main__":
start = time.time()
rotate_kek("kek_v1", "kek_v2", load_all_wrapped_deks())
print(f"轮换完成，耗时 {time.time() - start:.2f}s")
```

轮换频率建议：主密钥一年至少换一次，遇到人员离职或疑似泄露要立即轮换。数据密钥可以跟着字段粒度走，敏感等级高的字段单独配 DEK。

5. 传输层与静态数据的协同

字段加密解决的是存储态，传输态要靠 TLS 1.3 兜住。我们在网关层统一做证书卸载，业务服务之间启用 mTLS，避免内部调用被嗅探。

另外提醒一点：日志和缓存是加密的盲区。很多团队把身份证号加密入库了，结果打印日志时又原样打出来，等于白做。我们在日志组件里加了敏感字段自动脱敏：

```python
import re

ID_CARD_RE = re.compile(r"\d{17}[\dXx]")

def mask_log(text: str) -> str:
"""日志脱敏：身份证中间 10 位打星。"""
return ID_CARD_RE.sub(
lambda m: m.group()[:6] + "**********" + m.group()[-1], text
)

print(mask_log("用户 310101199001011234 提交成功"))
# 输出：用户 310101**********4 提交成功
```

6. 落地时容易踩的坑

- 索引失效：加密字段无法直接做等值查询。常见解法是保留一个确定性加密（同明文同密文）的派生列专供检索，但要评估该列是否反而暴露了信息。
- 性能开销：每条数据都过一遍加密，批量导入时会慢。建议在导入前批量处理，别在 ORM 里逐条触发。
- 密钥丢失即数据丢失：务必做好 KEK 的备份与权限隔离，KMS 的访问要留审计日志。
- 合规口径差异：跨国企业还要注意不同地区对加密算法的限制，以属地监管最新要求为准。

互动讨论
1. 你们现在的员工敏感字段是明文存储，还是已经做了字段级加密？
2. 密钥管理上，是自建 KMS 还是用云厂商的服务？踩过哪些坑？
3. 加密之后带来的查询和性能问题，你们是怎么平衡的？