1. 合规风暴：为什么你的口令策略总被审计挑战？——从等保2.0到GDPR的合规全景图
说实话，我见过太多团队在口令策略上栽跟头了。
明明觉得自己做得挺到位——密码长度够了，复杂度也上了，定期修改也开了。结果审计一来，啪啪打回来一堆整改项。为什么？因为你以为的「合规」，跟审计眼里的「合规」，根本就不是一回事。
这一章，咱们就把这事彻底掰扯清楚。
1.1 审计到底在查什么？
先问个问题：你被审计挑战过吗？
我自己的经验是，审计人员翻你的口令策略，其实就盯三件事：
- 有没有明文规定——你的制度文件里，写没写口令长度、复杂度、有效期？
- 规定有没有落地——系统配置跟制度写的是不是一致？
- 落地有没有证据——日志、配置截图、审批记录，拿得出来吗？
嗯，这里要注意。很多团队只做了第二点，第一点和第三点全空白。审计一来，你说你配置了，拿什么证明？
1.2 等保2.0：国内绕不过去的坎
等保2.0（GB/T 22239-2019）对口令的要求，说白了就几个硬杠杠。我把它整理成了一张表，你对照着看看自己踩了几个：
| 等保2.0要求项 | 具体内容 | 常见翻车点 |
|---|---|---|
| 长度 | 口令长度不小于8位 | 很多老系统只支持6位，直接不达标 |
| 复杂度 | 包含大写、小写、数字、特殊字符中至少三类 | 只设了两类，或者特殊字符被系统过滤了 |
| 有效期 | 90天内必须修改 | 管理员账号没设过期，一用就是三年 |
| 历史记录 | 至少5次内不能重复 | 只记了3次，或者根本没启用 |
| 锁定策略 | 连续失败5次锁定账号 | 锁定时间太短，或者没设自动解锁 |
你看，每一条都很具体。但实际项目里，我见过最离谱的情况是——制度里写了「密码必须包含特殊字符」，结果系统把 !@#$% 全给过滤了。用户设的密码根本过不去，最后全改成 Password123 这种。审计一查日志，全暴露了。
1.3 GDPR：欧洲的合规大棒
如果你做的是面向欧洲用户的产品，GDPR 才是真正的噩梦。
GDPR 没有像等保那样列出一二三条口令要求，但它有一条原则叫「数据安全原则」（Article 32）。说白了，你得证明你采取了适当的技术措施来保护个人数据。口令策略就是其中一环。
我个人习惯把 GDPR 的口令要求理解为三个层次：
- 基础层——跟等保类似，长度、复杂度、有效期这些得有。
- 增强层——多因素认证（MFA）必须上，尤其是管理员账号。
- 证据层——你做的所有配置、所有策略变更，都得有日志、有审批、有记录。
为什么会这样？因为 GDPR 的罚款是按「全球年营收的 4% 或 2000 万欧元」算的。你没有证据，就等于没有做。审计来了，你拿什么自证清白？
1.4 合规全景图：从制度到技术到运营
说了这么多，其实就一个核心逻辑：合规不是单点配置，而是一个闭环。
我画了张图，帮你把这事理清楚：
你看，三层是串起来的。制度层定了规矩，技术层去执行，运营层留证据。哪一层断了，审计都能给你揪出来。
1.5 避坑指南：审计最常开的整改项
我这些年帮客户做过不下30次合规整改，总结出几个高频翻车点。你直接拿去对照自查：
- 制度与配置脱节——制度写8位，系统配6位。这是最常见的低级错误。
- 管理员账号没特殊对待——普通用户90天改密，管理员也90天？审计会问：管理员权限这么大，凭什么跟普通用户一样？
- 默认口令没改——系统装完，admin/admin 还挂着。我见过某大厂因为这个被开了高危漏洞。
- 口令明文存储——数据库里密码字段是明文。这已经不是合规问题了，这是安全事故。
- 没有口令强度校验——用户设个
12345678也能过。你策略写得再漂亮，用户不执行等于零。
1.6 小结：合规不是终点，是起点
说白了，合规不是为了让审计满意，而是为了让你的系统更安全。等保2.0和GDPR虽然要求不同，但核心逻辑是一样的——你得有制度、有技术、有证据。
这一章我们搭好了全景图。接下来，我会带你一步步把每一层都做扎实。先从制度层开始，把口令策略文件写得滴水不漏。