第2章：安全合规基础：法律法规概述与合规审计入门
说实话，我刚做DevOps那几年，对「合规」这事儿是有点抵触的。
总觉得安全团队就是来添乱的。动不动就「这个不行」、「那个要改」。直到有一次，我负责的一个电商项目，因为日志留存时间不够，被监管部门点名整改。那叫一个狼狈。
从那以后，我彻底明白了：合规不是绊脚石，而是保护伞。
2.1 全球三大合规法规，你得心里有数
做安全合规，首先得知道「谁在管你」。不同行业、不同地区，管的「衙门」不一样。我个人习惯把最主流的三个法规先搞清楚，其他的都是衍生品。
2.1.1 GDPR：欧洲的「数据铁拳」
GDPR，全称通用数据保护条例。欧洲人搞出来的，但影响力是全球的。
为什么？因为只要你的系统里存了欧洲用户的数据，你就得听它的。我在一家出海公司干过，当时为了合规GDPR，光用户删除数据的接口就重构了三次。
核心要点：
- 数据主体权利：用户有权要求你删除他的所有数据（被遗忘权）
- 同意机制：收集数据前必须获得明确同意，不能默认勾选
- 72小时通报：发生数据泄露，必须在72小时内通知监管机构
- 高额罚款：最高罚全球年营收的4%或2000万欧元（取高者）
我的经验：GDPR最坑的是「数据可移植性」。用户要求你把他的数据导出成通用格式（比如JSON），你得给。我建议在设计数据库时，就预留好用户数据的全量导出接口，不然后面补起来很痛苦。
2.1.2 等保2.0：中国的「安全基本法」
等保2.0，全称网络安全等级保护制度2.0。2019年正式实施，覆盖了几乎所有行业。
说白了，就是国家给你定了个安全「分数线」。你的系统得达到对应的等级要求。我接触过不少国企项目，等保测评是上线前的「硬门槛」，过不了就不能投产。
| 等级 | 保护对象 | 典型要求 |
|---|---|---|
| 第一级 | 一般系统 | 基本防护，自主定级 |
| 第二级 | 重要系统 | 需备案，每年测评一次 |
| 第三级 | 关键信息基础设施 | 需备案，每年测评一次，要求高可用 |
| 第四级 | 极高重要性系统 | 需备案，每半年测评一次，要求异地容灾 |
避坑指南：我曾经遇到一个团队，把等保测评当成「一次性考试」。测评过了就放松了。结果半年后复查，发现日志服务器磁盘满了，日志丢了三天。嗯，直接判定为「不符合」。记住，等保是持续性的，不是一锤子买卖。
2.1.3 PCI-DSS：支付行业的「铁律」
PCI-DSS，支付卡行业数据安全标准。只要你的系统处理信用卡信息，就得遵守。
这个标准特别细，细到什么程度？连你办公室的WiFi密码多久换一次都有规定。我帮一家金融科技公司做过PCI合规，最头疼的是「持卡人数据不能明文存储」这一条。
12项核心要求（精简版）：
- 安装和维护防火墙配置
- 不使用供应商提供的默认密码
- 保护存储的持卡人数据
- 加密传输的持卡人数据
- 使用并定期更新防病毒软件
- 开发并维护安全的系统和应用程序
- 限制对持卡人数据的访问
- 为每个访问系统的人分配唯一ID
- 限制对持卡人数据的物理访问
- 跟踪并监控对网络资源和持卡人数据的访问
- 定期测试安全系统和流程
- 制定并维护信息安全策略
2.2 合规框架：把你的「安全动作」串起来
光知道法规还不够。你得有个框架，把这些要求落地到日常工作中。
我个人比较推荐两个框架：NIST网络安全框架和ISO 27001。
- NIST框架：美国国家标准与技术研究院出的。它把安全分成五个环节：识别、保护、检测、响应、恢复。你想想看，这其实就是一个完整的PDCA循环。
- ISO 27001：国际标准。它更偏向管理体系，强调「你说你做了，你得有证据」。我建议做ISO认证时，把文档管理做好，审计员最喜欢查的就是「有没有记录」。
我的习惯：不管用哪个框架，我都会先画一张「合规地图」。把法规要求、框架控制项、我们的系统组件一一对应起来。这样哪里缺了，一眼就能看出来。
2.3 安全标准：技术层面的「硬杠杠」
法规和框架是「做什么」，安全标准是「怎么做」。这里我挑几个DevOps场景下最常用的。
| 标准 | 适用场景 | 关键点 |
|---|---|---|
| CIS Benchmarks | 操作系统、数据库、云服务 | 提供具体的配置加固指南 |
| OWASP Top 10 | Web应用安全 | 列出最常见的10种安全漏洞 |
| NIST SP 800-53 | 联邦信息系统 | 详细的安全控制目录 |
举个例子，CIS Benchmarks里有一条：禁止root用户远程SSH登录。这个在等保2.0里也是明确要求的。我建议你在CI/CD流水线里加一个安全扫描步骤，自动检查这些配置项。
2.4 合规审计基础：别怕，审计员也是人
很多人一听到「审计」就紧张。其实没必要。
审计的核心就一句话：你说你做了什么，拿出证据来。
我经历过几次大型合规审计，总结出三个要点：
- 证据链要完整：比如你说你做了代码安全审查，那就要有审查记录、审批记录、修复记录。缺一个环节，审计员就会打问号。
- 日志要留好：谁在什么时间、做了什么操作，都要有日志。我曾经因为日志时间戳格式不一致，被审计员揪着问了半小时。从那以后，我统一用UTC时间。
- 自动化是王道：手动操作容易出错，也容易遗漏。我建议把合规检查尽量自动化。比如用工具自动扫描配置、自动生成审计报告。
避坑指南：千万不要在审计前临时补文档。审计员一眼就能看出来哪些是「现写的」。我见过一个团队，为了应付审计，一天之内补了三个月的变更记录。结果笔迹颜色都不一样，直接被判定为「无效证据」。嗯，得不偿失。
好了，这一章的内容就这些。合规这事儿，说白了就是「把安全变成习惯」。下一章我们聊聊怎么在DevOps流水线里嵌入安全控制，让合规变成自动化的一部分。