合规与扫描 — CodeRoadMap合规与扫描
SOC 2/ISO/NIST 与漏洞扫描。
合规与扫描
这一课你将能做到
- 说清 SOC 2、ISO 27001、NIST CSF、等保 2.0 四个框架的定位差异，并判断什么场景该选哪个
- 用 Nessus/OpenVAS 对一台服务器做一次漏洞扫描，解读报告并按 CVSS 分级排期修复
- 建一张「控制项 → 证据 → 负责人 → 复查周期」的合规对照表，把抽象要求变成可审计的交付物
为什么要学
安全做了不算数，能证明你做了才算数。客户签合同前要你的 SOC 2 报告；政企客户要你的等保备案；出海要 GDPR。合规不是形式主义——它逼你把「我们挺安全的」翻译成「每条控制项都有证据、有负责人、有复查记录」。
人话：合规框架是「安全检查的标准答案格式」。你的安全措施可能已经很到位，但审计师不认识你的系统，只认证据。合规工作 = 把已有的安全实践，按框架要求的格式整理成可出示的证据链。
先建立图像
四大框架速查：
┌─────────────┬──────────────┬─────────────────┬──────────────┐
│ 框架 │ 性质 │ 适用场景 │ 产出物 │
├─────────────┼──────────────┼─────────────────┼──────────────┤
│ SOC 2 │ 审计报告 │ SaaS 卖给企业客户 │ Type II 报告 │
│ ISO 27001 │ 国际认证 │ 国际化、品牌建设 │ 认证证书 │
│ NIST CSF │ 自愿框架 │ 安全成熟度自评 │ 差距分析 │
│ 等保 2.0 │ 中国强制 │ 国内业务系统 │ 备案+测评报告 │
└─────────────┴──────────────┴─────────────────┴──────────────┘
关系：ISO 27001 是"体系认证"，SOC 2 是"持续运行的证据"，
NIST CSF 是"自评打分卡"，等保 2.0 是"国内法律要求"。
NIST CSF 五函数（安全工作的通用语言）：
识别(Identify) → 保护(Protect) → 检测(Detect) → 响应(Respond) → 恢复(Recover)
资产清单 访问控制 SIEM/告警 IR 流程 备份重建
风险评估 加密 漏洞扫描 Runbook 灾难恢复
跟着做
步骤 1：用 OpenVAS 做一次漏洞扫描
OpenVAS（开源，现为 Greenbone）是最常用的免费漏洞扫描器：
# Docker 方式启动 Greenbone Community Edition
docker run -d -p 443:443 --name openvas greenbone/openvas
# 或 Kali Linux 自带
sudo gvm-start
# 浏览器访问 https://localhost:9392
扫描流程：
1. 配置 Target: 目标 IP（如自己的测试服务器 192.168.1.100）
2. 配置 Scan Config:
- Full and fast: 全量快速（推荐起步）
- Full and fast ultimate: 含耗时检查
3. 启动扫描，等待完成（单机 30 分钟-2 小时）
4. 查看报告，按 CVSS 分级:
- 9.0-10.0 Critical: 立即修
- 7.0-8.9 High: 本周修
- 4.0-6.9 Medium: 本月修
- 0.1-3.9 Low: 排期或接受
报告解读示例：
CVE-2023-1234 OpenSSH 8.x 远程代码执行 CVSS 9.8
→ 解法: 升级 OpenSSH 到 9.x
→ 命令: yum update openssh / apt upgrade openssh-server
CVE-2023-5678 Nginx 版本过旧 CVSS 5.3
→ 解法: 升级到稳定版
→ 注意: 测试环境先验证兼容性
步骤 2：建立合规对照表
把抽象要求变成可审计证据。以「访问控制」为例：
| 控制项 | 证据 | 负责人 | 复查周期 |
|--------------------|-------------------------------|--------|---------|
| 生产服务器禁用密码登录 | sshd_config 截图 | 运维 | 季度 |
| 数据库账号最小权限 | SHOW GRANTS 输出存档 | DBA | 季度 |
| 员工离职 24h 内销权 | HR 流程记录 + 账号禁用日志 | IT | 半年 |
| 管理员账号启用 MFA | 云控制台 MFA 状态截图 | 安全 | 季度 |
| 生产变更走审批 | 发布系统审批记录导出 | 研发 | 月度 |
| 日志保留 180 天 | ES ILM 策略截图 + OSS 归档清单 | 运维 | 半年 |
关键原则：每个控制项必须有「拿得出手的证据」——截图、导出文件、系统配置、流程记录。审计师只认证据，不认口头承诺。
步骤 3：用 Burp Suite 做应用层手动测试
自动扫描器抓不到业务逻辑漏洞，用 Burp（社区版免费）手动测：
1. 配置浏览器代理 → 127.0.0.1:8080（Burp 默认）
2. 正常操作本站：登录、浏览课程、提交进度
3. Burp 抓到的每个请求，检查:
- 修改 JWT payload 里的 userId → 越权测试
- 修改 trackId 为不存在的 ID → 参数校验测试
- 重放请求 100 次 → 限流测试
- 提交 `' OR '1'='1` → 注入测试
4. 重点关注 Repeater 模块：单请求反复修改重放
步骤 4：Wireshark 抓包验证加密
# 服务器上抓 MySQL 流量
tcpdump -i any port 3306 -w mysql.pcap
# Wireshark 打开 mysql.pcap
# 如果能看到明文 SQL 语句（SELECT * FROM users...），说明内网传输未加密
# 解法: MySQL 配置 require_secure_transport=ON，强制 TLS
# my.cnf
[mysqld]
require_secure_transport = ON
ssl_ca = /etc/mysql/ca.pem
ssl_cert = /etc/mysql/server-cert.pem
ssl_key = /etc/mysql/server-key.pem
步骤 5：把扫描接入 CI（持续合规）
# .github/workflows/security-scan.yml
name: Weekly Security Scan
on:
schedule:
- cron: '0 2 * * 1' # 每周一凌晨 2 点
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
# 依赖漏洞
- run: mvn org.owasp:dependency-check:check
# 静态代码
- run: mvn spotbugs:check
# 报告归档，供合规审查出示
- uses: actions/upload-artifact@v4
with:
name: security-reports-${{ github.run_number }}
path: target/dependency-check-report.html
合规要点：扫描记录的留存本身就是证据。审计时出示「过去 12 个月每周扫描报告归档」比任何口头说明都有力。
讲清楚要点
-
合规是证明题不是论述题：审计师问「你们如何做访问控制」，正确答案是出示账号清单、权限矩阵、审批记录、季度复查记录——不是讲设计理念。平时就要按「可出示证据」的方式工作。
-
SOC 2 Type I vs Type II：Type I 审「某时点」控制设计是否合理；Type II 审「一段时间（通常 6-12 个月）」控制是否持续有效运行。企业客户要的都是 Type II——这就是为什么合规是持续工程不是一次性项目。
-
扫描器各有分工：Nessus/OpenVAS 扫主机和网络层漏洞（OS 补丁、弱配置）；OWASP ZAP/Burp 扫 Web 应用层（注入、XSS）；Trivy 扫容器镜像；Dependency-Check 扫依赖。一个都不能少，也别指望一个覆盖全部。
-
漏洞修复要按 CVSS + 业务上下文排序：CVSS 9.8 的漏洞在一个根本访问不到的内网测试机上，优先级低于 CVSS 6.0 但在公网核心接口上的漏洞。评分是输入不是结论。
-
等保 2.0 是国内业务的法律底线：在中国境内运营的信息系统必须定级（通常二级或三级）、备案、定期测评。不是可选项。定级看系统被破坏后对国家安全/社会秩序/公民权益的影响程度。
你可能会懵的地方
-
初创公司先做哪个认证？
卖 SaaS 给企业：SOC 2（客户会要）。做国内市场：等保二级起步（法律要求）。追求国际认可：ISO 27001。别同时启动多个，一个做扎实再说。
-
合规会不会拖慢开发？
设计得好不会。把控制项嵌进已有流程：代码评审清单里加安全检查、发布流程里加扫描门禁、入职离职流程里加账号开通销权。合规失败的项目通常是把合规做成了「安全团队单独的一套流程」，和业务两张皮。
-
扫描出 500 个漏洞怎么办？
这是第一次全量扫描的常态。按 CVSS 过滤出 Critical+High（通常 20-50 个），分批修复，每批修复后复扫确认。Medium/Low 建工单排期。不要试图一次清零，会 burnout。
-
渗透测试和漏洞扫描什么区别？
扫描器是自动化工具，找已知漏洞（CVE、配置错误），每周跑。渗透测试是人工服务，找业务逻辑漏洞（越权、薅羊毛、组合利用），每年 1-2 次。合规通常两个都要证据。
-
控制项证据要保留多久？
通常覆盖审计周期 + 一年。SOC 2 Type II 审计期 6-12 个月，证据至少保留 2 年。截图、导出文件统一归档到带时间戳的目录。
错法对照
| 错法 | 问题 | 正解 |
|---|
| 审计前突击补证据 | 连续性证据补不出来 | 日常按可审计方式工作 |
| 扫描报告不修只存档 | 审计会被开 finding | 高危按期修复+复扫闭环 |
| 一个扫描器打天下 | 覆盖不全 | 主机+应用+镜像+依赖分层扫 |
| 只按 CVSS 排序 | 忽略业务上下文 | CVSS × 暴露面 × 资产价值 |
| 合规是安全团队的事 | 控制项落不了地 | 每个控制项有业务负责人 |
| 忽视等保备案 | 法律风险 | 上线前定级备案 |
卡点急救
-
OpenVAS 扫描极慢或卡死：NVT 库没更新完就启动扫描。先 greenbone-nvt-sync 同步特征库（首次需 1-2 小时），确认 Feed 状态为 Current 再扫。扫描目标多时拆分成多个小任务。
-
审计师要的证据系统里没有：典型如「季度权限复查记录」——你没做过自然没有。解法：把复查做成自动化脚本（每季度自动导出账号权限清单 + 邮件提醒负责人确认），从此证据自动产生。
-
漏洞修了复扫还在报：可能是：扫描器特征库旧（更新 NVT）、修了一台漏了另一台（确认资产清单完整）、修复未生效（复扫前手动验证，如 openssl s_client 确认 TLS 版本）。漏洞管理的关键是「修复验证」环节不能省。
面试常问
-
SOC 2 和 ISO 27001 的区别？
ISO 27001 是信息安全管理体系（ISMS）认证，证明你「建立了体系」，发证书，3 年有效期+年度监督审核。SOC 2 是审计报告（AICPA 标准），基于信任服务准则（安全、可用性、保密性等），证明你的控制「持续有效运行」，Type II 覆盖 6-12 个月。美国企业客户普遍认 SOC 2，欧洲和国际化场景认 ISO 27001。两者控制项高度重叠，很多公司先建 ISMS 再过 SOC 2。
-
漏洞扫描后如何管理漏洞生命周期？
五阶段闭环：发现（扫描/通报）→ 评估分级（CVSS+业务上下文）→ 修复（按 SLA：Critical 24-72h，High 1 周，Medium 1 月）→ 验证（复扫确认）→ 关闭归档（留存证据）。关键是 SLA 要写进制度且有人跟踪，否则漏洞永远停留在「已知」状态。
-
什么是等保 2.0？流程是什么？
中国网络安全等级保护制度。流程：定级（一~五级，业务系统通常二级/三级）→ 备案（公安机关）→ 建设整改（按对应级别的技术和管理要求）→ 等级测评（第三方测评机构，每年）→ 监督检查。三级系统要求年测评、关键设备冗余、安全审计、入侵防范等。法律强制，不是自愿认证。
自测三问
- SOC 2 Type I 和 Type II 的区别是什么？客户通常要哪个？
- 为什么说「扫描记录留存本身也是合规证据」？
- 一个 CVSS 9.8 的内网漏洞和一个 CVSS 6.0 的公网漏洞，先修哪个？为什么？
小结一句话
合规 = 把安全实践翻译成可审计的证据链：框架选对（SOC 2/ISO/等保看业务）、扫描分层（主机/应用/镜像/依赖）、每个控制项有证据有负责人、修复有 SLA 有闭环。
延伸