第九周的实训，我和小组几个人没有继续往前赶新功能，而是把整个模拟项目X的所有接口、数据库和部署配置重新过了一遍，主题就一个：数据加密与安全性实现。起因很直接——项目上线前，评审方给了一份整改意见，里面好几条都点在我们的痛处：接口全程走明文、密码用MD5存、日志里躺着完整手机号。这篇周记记录的就是这周从“知道有问题”到“把问题修掉”的全过程，包括方案怎么选、代码怎么写、坑在哪里。如果你也在负责一个需要真实上线的小项目，或者正在系统学习安全加固，这周内容可以直接当参考。
1. 安全方案设计：先想清楚防谁，再动手加密
1.1 安全评审暴露的问题清单
第一次拿到评审意见的时候，我们其实是有点懵的。功能都能跑，页面也正常，为什么在安全评估这边被打回？一项项拆开看才明白，问题全都出在“看不见的角落”：
- 接口采用HTTP明文传输，抓包就能看到手机号和口令。
- 数据库里的密码是MD5加固定盐，用GPU机器跑批量爆破，几分钟就能还原相当一部分弱口令。
- 日志系统打印了完整手机号，运营导出日志等于变相泄露用户数据。
- 接口没有防篡改机制，请求参数被替换后服务端完全无法识别。
这些问题单独看都不算“高级漏洞”，但组合在一起，等于把大门钥匙挂在了门口。评审意见促使我们重新审视：安全性实现不是某一层的事，而是要贯穿数据从“产生”到“传输”再到“落库”的完整链路。
1.2 分层防护：传输、应用、存储各管一段
设计加固方案时，我们确定了三个层面分开做：传输层、应用层、存储层。这就像一个防盗系统——门锁负责拦住陌生人，室内报警器负责发现异常，保险柜负责让偷到手的东西也派不上用场。三个层面职责不同，缺一个都不完整。
传输层解决的是“路上被偷听”的问题。HTTP是明文，等于你在电话里报银行卡号，旁边有人拿着听筒在听。配置TLS之后，数据在通道内是密文，抓包看到的是乱码，这层防护解决“会话被截获”。应用层解决的是“业务逻辑被篡改”的问题，比如请求里的金额、用户ID能不能被随意替换，这层防护靠HMAC签名、校验和、鉴权完成。存储层解决的是“数据落库后被拖走”的问题，数据库被拖库、备份文件泄露、运维人员登录服务器直查数据库，这些场景下敏感字段必须是密文，这层防护靠字段级加密解决。
三层方案确定之后，我们才开始选具体的算法和工具。先后顺序不能反，否则很容易出现“哪里都加了密，但链路中间某个环节仍然是裸奔”的情况。
1.3 威胁模型：先搞清楚要防谁
安全性实现最忌讳漫无目的地堆功能。在动手前，我们列了一个简化版威胁模型，把重点攻击者分为三类：
| 攻击者类型 | 典型手段 | 主要防护目标 |
|---|---|---|
| 外部窃听者 | 抓包、中间人攻击、网络嗅探 | 传输层TLS，保证通道机密性 |
| 数据窃取者 | SQL注入、拖库、备份泄露 | 存储层字段加密，保证密文不可读 |
| 内部低权限人员 | 直查数据库、查看日志、越权访问 | 字段级加密权限隔离，日志脱敏，审计留痕 |
这个模型不追求教科书式的完整性，但足够让我们在每个环节明确“我在防谁”。后续所有加密决策都围绕这个表展开：传输层防外部窃听，存储层防拖库和内部接触，应用层防篡改和越权。方案不会白做，后面每一个技术选型都能在这个表里找到对应位置。
2. 传输层加密落地：TLS配置与安全响应头
2.1 HTTPS强制跳转与证书安装实操
传输层的第一件事是把全站改成HTTPS。我们部署环境是Nginx，改动不算大，但有几个细节特别值得注意。
证书选型上，内部测试环境一开始用自签名证书，后来发现客户端App的SSL校验在这里卡了很久（这个坑下面单独说）。生产环境我们统一使用受信任CA签发的证书。配置方式参考如下：
# 80端口强制跳转HTTPS server { listen 80; server_name api.example.test; return 301 https://$host$request_uri; } # HTTPS服务主配置 server { listen 443 ssl http2; server_name api.example.test; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384'; ssl_prefer_server_ciphers off; ssl_session_cache shared:SSL:10m; ssl_certificate /etc/nginx/ssl/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/privkey.pem; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; } }几个点解释一下。ssl_protocols我直接关掉了TLS 1.0和TLS 1.1，这两个老版本协议已经被证明存在多个可利用的弱点，现在主流客户端都支持TLS 1.2以上，没必要为兼容古董浏览器牺牲安全性。ssl_ciphers只保留支持前向保密的套件，这里列的都是GCM模式的套件，性能和安全性都更好。还有那个proxy_set_header X-Forwarded-Proto $scheme，如果没配这个，后端应用会误以为请求还是HTTP，导致某些框架里的安全策略不生效。
2.2 混合内容与证书链不完整：两个典型坑
HTTPS配好后，接下来两件事直接把我们的天真想法击碎了。
第一件事是混合内容。浏览器地址栏明明已经显示锁标志，但页面里某个图片、某个脚本还是走HTTP加载，结果锁标志又消失了，甚至直接被浏览器拦截。这个问题的排查方法很简单：打开浏览器开发者工具里的Network面板，筛选所有HTTP请求，把协议不匹配的资源全部改成HTTPS加载。但更好用的做法是，在应用层写入内容安全策略（CSP），从源头禁止非HTTPS资源加载，后面表格会列出推荐的配置。
第二件事是证书链不完整。我们第一次部署时只把站点证书放到了服务器上，没有附带中间证书。桌面浏览器因为内置了完整证书库，勉强能通过校验；但部分移动端App和物联网设备直接报证书错误，半天排查不出原因。后来仔细看了证书颁发机构的说明才发现，部署时应该合并站点证书和中间证书为一份fullchain.pem。判断方法很简单：
curl -I https://api.example.test 2>&1 | grep "SSL certificate verify" openssl s_client -connect api.example.test:443 -servername api.example.test </dev/null 2>/dev/null | grep "Verify return code"如果返回值不是ok (0)，那就是证书链有问题，把中间证书补上再试。
2.3 安全响应头配置清单
除了TLS本身，我们还在Nginx层加了一批安全响应头。这些头不加密数据，但能帮助浏览器以更安全的方式处理页面，属于性价比极高的加固项：
| 响应头 | 作用 | 推荐配置 |
|---|---|---|
Strict-Transport-Security | 强制客户端只走HTTPS，防止降级攻击 | max-age=31536000; includeSubDomains |
Content-Security-Policy | 限制页面可加载的资源来源，降低XSS风险 | default-src 'self' |
X-Content-Type-Options | 禁止浏览器对响应内容进行MIME类型猜测 | nosniff |
X-Frame-Options | 禁止页面被嵌入iframe，防止点击劫持 | DENY |
Referrer-Policy | 控制跨域请求时Referrer信息的泄露 | no-referrer |
Nginx里添加方式是在server块内增加add_header指令。特别提醒，HSTS的max-age别一上来就设成31536000，先在测试环境用小一点的max-age验证没有副作用，确认无误后再调大。因为HSTS一旦被浏览器记住，到期之前即使服务端关了HTTPS，浏览器也拒绝访问HTTP。
3. 存储层加密落库：字段级AES-GCM与密钥管理
3.1 为什么选择字段级加密而不是整库加密
传输层解决完“路上被偷听”，接下来是存储层。数据库里的敏感字段包括手机号、身份证号、银行卡号和部分业务机密数据。一开始我们考虑过整库加密（透明数据加密），理由是不用改代码。但深入之后发现它有两个问题难以接受：加密后所有查询都无法走索引，性能开销主要靠SQL条件扫描；权限管理没有细化到字段级别，一旦拥有数据库读取权限，整库内容都能解密。
对比之后，我们选择了字段级加密。只对真正敏感的字段加密，查询条件和索引设计完全不受影响；解密权限按应用和用户控制，不会出现“读一个表等于读出所有用户手机号”的情况。缺点也很明显：需要改代码，密钥管理要自己设计，密文长度会膨胀，这几点在3.2和3.3会详细说。
3.2 AES-GCM落地细节：随机IV、AAD与密文格式
字段级加密我们用的是AES-GCM，这个选择不是随手拍脑袋。AES-GCM属于AEAD算法，它同时提供机密性和完整性。也就是说，加密后的数据不仅能防被读取，还能防被篡改，篡改后的密文在解密时会被检测出来并直接报错。相比之下，老的AES-CBC模式只保证机密性，要额外叠加HMAC做认证，一旦实现不当就会出现填充预言攻击之类的问题。GCM把这些复杂逻辑封装好了，在项目里使用起来更不容易踩坑。
核心加解密代码的Python示例如下：
import os import base64 from cryptography.hazmat.primitives.ciphers.aead import AESGCM # 16字节/24字节/32字节的密钥，分别对应AES-128/AES-192/AES-256 # 生产环境密钥不允许出现在代码中，建议从密钥服务或环境变量读取 def encrypt_field(plaintext: str, user_id: str, key: bytes) -> str: # 1. 每次加密必须使用独立的随机nonce，固定长度12字节 nonce = os.urandom(12) # 2. 将业务上下文信息绑定为AAD # 这样密文被挪到其他用户或其他业务场景时，解密必然失败 aad = f"user:{user_id}".encode("utf-8") # 3. 加密，返回的密文中已经包含16字节认证标签 ciphertext = AESGCM(key).encrypt(nonce, plaintext.encode("utf-8"), aad) # 4. 格式: v1:base64(nonce + ciphertext) # 前缀v1是密钥版本号，后续做密钥轮换时靠它识别用哪把密钥 return "v1:" + base64.b64encode(nonce + ciphertext).decode("utf-8") def decrypt_field(payload: str, user_id: str, key: bytes) -> str: version, b64_data = payload.split(":", 1) raw = base64.b64decode(b64_data) nonce, ciphertext = raw[:12], raw[12:] aad = f"user:{user_id}".encode("utf-8") plaintext = AESGCM(key).decrypt(nonce, ciphertext, aad) return plaintext.decode("utf-8")这里面有三个细节必须讲清楚。
第一，nonce必须随机且每次不同。GCM对nonce复用极其敏感，复用nonce会直接导致密钥流重复，攻击者拿到两段密文就可以做异或运算恢复明文。我见过有人把nonce写死在配置里的，那是灾难级的错误。所以代码里用os.urandom(12)生成随机nonce，不采用自增计数器方案——分布式环境下计数器管理太容易出错。
第二，GCM不需要填充。它本质上是基于CTR模式构建的认证加密，明文任意长度都可以直接处理。不要在GCM外面再套一层PKCS#7填充，那是CBC的遗留习惯，放进GCM只会增加无意义的数据膨胀和出错概率。
第三，AAD的作用是防止密文被搬移。最早我们没绑AAD，结果测试发现：把用户A的一条加密手机号复制到用户B的数据行中，解密居然成功了，因为密钥和算法都一样。把user_id放进AAD之后，再搬移密文直接抛InvalidTag异常，这个防御效果立竿见影。
还要提前算好字段长度。AES-GCM每加密一个字段会多出16字节的认证标签，再加上Base64编码的膨胀率（约33%），再加上版本号前缀，实际存储长度会比原始数据大不少。我们一开始只改了加密逻辑没改表结构，结果数据库直接报Data too long。后来按“加密后最大长度 = ceil((明文长度 + 16)/3) * 4 + 版本前缀长度”的公式重新算了字段长度，才把问题解决。
3.3 密钥管理：版本号、轮换与环境分离
密钥管理是存储层加密里最容易被低估的部分。我们一开始的做法是把AES密钥写死在配置文件里，后来意识到这是给自己埋雷：代码仓库一泄露，所有密文全部失效。最终我们采用了一套轻量但规范的密钥管理方案，对中小项目足够用。
密钥与代码分离。开发环境、测试环境、生产环境使用不同的密钥，密钥文件放在独立路径，只允许运维账号读取，权限设为600。生产环境密钥放到托管密钥服务里，应用启动时从环境变量或专用配置中心读取，代码仓库里永远只留占位符。
增加密钥版本机制。密文格式里带上前缀v1:，后面解密时先解析出版本号，再从密钥表里取对应的密钥。轮换流程分四步：新增生成一把新版本密钥并标记为current；新写入的数据全部使用新版本密钥加密；存量数据在业务低峰期批量解密再重新加密；确认所有节点都切到新版本后，下线旧版本密钥。这套流程在不停服的情况下也能平滑完成轮换。
这里特别提一句依赖版本的问题。在实现GCM时我们用了较新的加密库版本，因为旧版本实现中GCM的认证标签截断校验可能存在缺陷。加密这种基础组件，尽量跟随库的更新节奏，这比业务代码升级更迫切。
4. 密码哈希与认证会话加固
4.1 密码哈希算法选型与参数
密码存储是安全整改意见里被点名最多的一项。我们原来的做法是MD5加固定盐，这在今天已经完全站不住脚。MD5的运算速度太快，GPU并行计算下每秒能跑几十亿次，加固定盐也无法抵挡批量撞库。后来我们讨论过直接用SHA-256多次迭代的方案，但同样不推荐——SHA系列是为速度设计的通用哈希，在密码场景下反而是它最大的缺点。
密码存储的正确方向是慢哈希算法：bcrypt、scrypt、Argon2。这类算法的共同特点是计算成本可控可调，故意让单次哈希计算变慢，暴力破解的代价呈指数级上升。经过对比，我们选了Argon2id，它是密码哈希竞赛的胜出算法，同时抗GPU和ASIC攻击，也是目前各安全组织推荐的首选方案。
参数上直接参考了OWASP推荐值：
| 算法 | 关键参数 | 输出示例 |
|---|---|---|
| Argon2id | m=19456KiB, t=2, p=1 | $argon2id$v=19$m=19456,t=2,p=1$... |
| bcrypt | cost=12 | $2b$12$... |
| scrypt | N=2^17, r=8, p=1 | $scrypt$ln=17,r=8,p=1$... |
注意，Argon2的PHC字符串本身包含了盐和所有参数，直接存这一个字段就够了，不需要再单独加盐列。字段长度要预留到97字符以上，因为Argon2输出字符串就是97字符左右，不要只留个varchar(60)坑了后面的自己。
4.2 老哈希算法的无缝迁移
存量用户密码已经是MD5了，不可能让所有用户立刻重置密码，所以需要一套渐进迁移策略。我们实现方式是：数据库口令字段增加算法标识，登录时先检查前缀。
$md5$e10adc3949ba59abbe56e057f20f883e $argon2id$v=19$m=19456,t=2,p=1$...验证流程如下：如果是$md5$前缀，说明是旧算法，先用MD5验证密码；验证通过后立刻用Argon2id重新计算哈希并更新数据库字段。整个过程对用户无感知，下一次登录直接走新算法分支，旧算法哈希慢慢就全部被替换掉了。这比强制全量重置密码温和得多，也符合真实项目中的迁移习惯。
4.3 会话与Token的安全实践
密码存好了，登录链路本身也有一堆细节。我们复盘时总结出三条：
登录成功后强制重新生成Session ID。这是为了防止会话固定攻击。攻击者先拿到一个未认证的合法Session ID，诱导受害者用这个ID登录，如果服务端登录后不更换Session ID，攻击者就可以共享这个会话。重新生成可以彻底切断这条链。
Token签发的生命周期需要分层。我们以前一个Token管半个月，泄露了等于裸奔半个月。现在改成短期Access Token（15-30分钟）加长期Refresh Token的组合，Refresh Token可以主动吊销，Access Token即使泄露影响窗口也小。
JWT相关的实现细节要注意：不要使用alg: none，服务端验签前先固定算法类型；密钥必须强随机且至少256位；payload里带iat、exp、iss等标准字段，并且每一端校验时都要检查，不能只管过期时间。
5. 数据完整性校验与审计日志
5.1 接口防篡改：HMAC签名实操
传输层加密保证数据在通道内不被窃听，但服务端如何确认收到的请求就是客户端原始发出的、中间没有被篡改？这需要HMAC签名。HMAC（基于哈希的消息认证码）使用共享密钥对请求内容生成一个摘要，服务端用同样的密钥重新计算。只要内容被改动，摘要必然不匹配。它和常规HASH的区别在于：HMAC有密钥参与，没有密钥无法伪造合法摘要。
我们的签名规则比较简单，适合多数业务场景：
import hmac import hashlib def generate_sign(params: dict, secret: str) -> str: # 1. 去掉签名本身的字段，按key字母序排列 items = [(k, params[k]) for k in sorted(params) if k != "sign"] # 2. 拼接为 key=value&key=value 格式 raw = "&".join(f"{k}={v}" for k, v in items) # 3. 使用HMAC-SHA256生成摘要 return hmac.new(secret.encode("utf-8"), raw.encode("utf-8"), hashlib.sha256).hexdigest()服务端验证时，重点在于用常量时间比较函数，而不是普通==比较：
import hmac def verify_sign(params: dict, secret: str) -> bool: received = params.get("sign", "") expected = generate_sign(params, secret) # 使用恒定时间比较，防止时序侧信道攻击 return hmac.compare_digest(expected, received)这里解释一下为什么不用==。==在字符串比较时一旦发现第一个字符不同就立即返回，攻击者可以利用响应时间的差异逐位推测合法签名。hmac.compare_digest在整个比较过程中耗时恒定，从根本上封堵了这个侧信道。
签名密钥绝对不能放在客户端。如果是C/S架构，签名通常由服务端之间相互调用时使用，或者由客户端持有专门的签名密钥并做好防提取加固。如果是Web应用，建议把签名逻辑放在网关层，业务服务之间统一校验。
5.2 日志脱敏与审计字段设计
日志是安全环节中最容易被忽略又最容易泄露数据的部分。我们之前的日志里到处是用户手机号、请求参数甚至是明文密码，这在评审中被单独拎出来批评。脱敏规则我们设计成了这样：
- 手机号保留前三位和后四位，中间用星号代替，例如
138****8000。 - 身份证号码保留前一位和后一位，中间全部打码。
- 银行卡号保留前六位和后四位，这是支付行业通行规则。
- 密码、Token、支付相关字段一律不写入日志。
- SQL慢查询日志中禁止把绑定参数拼进SQL文本再打印，必须打印带占位符的SQL和独立参数列表。
审计日志和业务日志分开存储。业务日志服务于排查问题，审计日志服务于安全追溯。审计日志核心字段：时间（统一UTC）、用户ID、操作类型（增删改查）、对象ID、来源IP、请求ID、操作结果。敏感值本身一律不记录，只记录对什么数据做了什么操作。请求ID最好贯穿整个调用链路，从网关到业务代码到存储层，出问题时顺着请求ID就能把完整行为串起来。
5.3 上线前自测清单
安全性实现做完之后，不能嘴上说“应该没问题”，要有一份可操作的验证清单。我们把这周验收用的检查项整理成了表格，新功能上线前照着走一遍：
| 检查项 | 通过标准 | 常用方式 |
|---|---|---|
| HTTPS强制跳转 | 访问HTTP自动301到HTTPS | curl -I http://... |
| 证书链完整性 | 证书校验返回 ok (0) | openssl s_client -connect ... |
| 安全响应头 | 响应包含HSTS、CSP、X-Frame-Options等 | curl -I https://... |
| 敏感字段落库 | 数据库表中敏感字段均为密文，无明文残留 | SQL查询生产表 |
| 密码哈希算法 | 口令字段为PHC字符串，长度≥97，无MD5残留 | 查看表结构 |
| 密钥安全 | 源码中无硬编码密钥，密钥文件权限为600 | grep扫描 + 检查文件权限 |
| 日志脱敏 | 日志中搜不到明文手机号、明文密码、Token | 全量日志搜索 |
| 依赖漏洞 | 依赖扫描无高危及以上漏洞 | pip-audit/npm audit/trivy |
这份清单的价值在于把安全要求变成了可执行动作，不再依赖某个人的“记得”。
6. 这一周踩过的坑和后续规划
6.1 三个印象最深的坑
第一个坑是加密字段长度不够。前面提到了，AES-GCM加密后数据会膨胀，Base64编码后更明显。我们改完加密逻辑没有同步改表结构，第一批数据插入就直接报了Data too long。这个问题的教训是：任何加密方案定了之后，先按“最坏情况”计算字段长度，再决定表结构，别等报错再返工。
第二个坑是AAD没绑定业务上下文。最初版本只有密钥和nonce，所有用户共享同一把密钥，密文就处于“能解密但无法确认属于谁”的状态。测试时发现把用户A的密文搬给用户B居然能正常解密，才意识到需要把用户ID绑进AAD。这个是最容易忽略但价值最高的一个环节。
第三个坑是自签名证书在测试环境的连锁反应。我们图省事，测试环境直接用了自签名证书，结果某客户端SDK对证书链校验严格，一直握手失败。排查了两天才发现不是代码问题，是证书信任链问题。后来测试环境也一律换成受信任CA签发的证书，避免浪费了大量时间在环境差异上。
6.2 下一步计划
这周的安全加固只是一个起点，后续还有几件事列入了计划：
密钥轮换脚本化。当前版本机制已经就绪，但轮换步骤还是半手动，准备实现一个脚本自动完成新版本密钥生成、存量数据重加密提醒、旧版本下线三步操作。
CI流水线接入依赖漏洞扫描。现在安全检查还是靠人工定时执行，后续要再接一个pip-audit或trivy到CI流程里，高危漏洞直接阻断发布。
测试环境统一强制HTTPS。开发环境和测试环境里的明文HTTP有时会掩盖一些只有在HTTPS下才暴露的问题，统一之后能提前发现兼容性隐患。
准备做一轮内部渗透测试，重点看越权访问（IDOR）和接口水平越权。这两类问题往往藏在业务逻辑里，工具扫不出来，需要人工逐个接口过。
这一周做下来，我个人最大的感受是：安全问题从来不是某一个加密函数能解决的，它是由传输层加密、存储层加密、密码哈希、完整性校验、审计日志这几根柱子一起撑起来的，任何一个环节漏了，攻击者就会专挑那个环节下手。另外，别迷信某种算法，关键是使用方式——随机IV没做好，AES-GCM一样翻车；哈希参数调得太低，Argon2和MD5也没有本质区别。后面我们准备把这套加固方案沉淀成一份内部清单，新功能上线前照着勾一遍，至少能把低级问题挡在门外。
