compliance-review

合规审查

根据行业特定的监管要求评估你的应用。本次审查将复杂的合规框架转化为具体、可测试的技术检查，并通过基于浏览器的测试进行验证。不合规可能导致高额罚款、法律诉讼和业务损失。

适用场景

在以下情况使用 /compliance-review：

• 为受监管行业（医疗保健、金融、政府）构建应用
• 准备合规审计（SOC 2、HIPAA、PCI-DSS）
• 添加支付处理或健康数据功能
• 拓展到受 GDPR 监管的市场
• 基础设施或架构变更影响数据处理后

参考标准

• HIPAA —《健康保险流通与责任法案》（技术保障措施 §164.312）
• SOC 2 — 服务组织控制（信任服务标准）
• PCI-DSS v4.0 — 支付卡行业数据安全标准
• GDPR —《通用数据保护条例》（技术措施）

阶段概览

Phase 1: EDUCATE   → Compliance context and applicable frameworks
Phase 2: SCOPE     → Determine which frameworks apply, identify regulated data
Phase 3: ANALYZE   → Browser-based checks against framework requirements
Phase 4: REPORT    → Findings mapped to specific regulatory sections
Phase 5: REMEDIATE → Fix guidance + YAML regression tests for continuous compliance

---

阶段 1：了解背景

重要性： 违反 HIPAA：每年每类违规最高罚款 190 万美元。违反 PCI-DSS：每月罚款 5,000 至 100,000 美元，此外还需承担数据泄露责任。SOC 2 审查失败：失去要求通过该审查的企业客户。违反 GDPR：最高罚款为全球年收入的 4%。这些并非纸上谈兵——监管执法正在进行且力度不断加大。

合规框架篇幅庞大。本次审查提取出可在 Web 应用中测试的技术要求，不包括需要人工流程审查的组织或程序要求（政策、培训、供应商管理）。

---

阶段 2：确定范围

确定适用的框架

1. 从代码库中自动检测：

   • 健康数据处理（HIPAA 指标：HL7、FHIR、患者记录、PHI 相关引用）
   • 支付处理（PCI-DSS 指标：Stripe、Braintree、信用卡字段、支付表单）
   • 欧盟用户数据（GDPR 指标：同意横幅、Cookie 通知、欧盟部署）
   • 审计日志（SOC 2 指标：审计跟踪、事件日志、访问日志）

2. 询问用户：

   • 适用哪些框架？（自动检测后确认）
     • HIPAA — 医疗保健 / 受保护的健康信息
     • SOC 2 — 企业 SaaS / 客户数据
     • PCI-DSS — 支付卡数据
     • GDPR — 欧盟个人数据
     • 其他（请注明）
   • 目标 URL：应用运行在哪里？
   • 受监管的数据类型：应用处理哪些受监管的数据？（自动检测）
   • 测试凭据：用于测试且可访问受监管数据的账户

3. 映射受监管的数据流：

   • 受监管数据进入系统的位置（表单、API、导入）
   • 数据显示的位置（仪表板、报告、导出）
   • 数据在客户端存储的位置（如有）
   • 数据传输的位置（API 端点、第三方服务）

---

阶段 3：分析

根据阶段 2 确定的范围，仅运行适用部分。使用 new_session 打开浏览器会话，并设置 record_evidence: true。

HIPAA 技术保障措施（HIP）

适用情形：应用处理受保护健康信息（PHI）。

检查 ID	检查项	HIPAA 条款	方法
HIP-01	未经身份验证不得显示 PHI	§164.312(d)	未经身份验证访问 PHI 页面，确认返回 401 或重定向
HIP-02	闲置后会话自动超时	§164.312(a)(2)(iii)	等待闲置一段时间，确认会话过期
HIP-03	URL 参数中不包含 PHI	§164.312(e)(1)	浏览 PHI 页面并检查 URL
HIP-04	浏览器控制台／日志中不包含 PHI	§164.312(b)	检查 get_browser_console_logs 中是否存在 PHI 模式
HIP-05	PHI 不缓存在浏览器存储中	§164.312(a)(2)(iv)	检查 localStorage、sessionStorage 中是否存在 PHI
HIP-06	PHI 仅通过 HTTPS 传输	§164.312(e)(1)	确认所有 PHI API 调用均使用 HTTPS
HIP-07	访问 PHI 时留下审计跟踪	§164.312(b)	访问 PHI，确认存在相应的审计日志条目
HIP-08	基于角色控制 PHI 访问权限	§164.312(a)(1)	使用不同用户角色测试 PHI 访问权限
HIP-09	PHI 显示遵循最低必要原则	§164.502(b)	检查界面是否仅显示必要的 PHI 字段
HIP-10	设有紧急访问流程	§164.312(a)(2)(ii)	检查是否有紧急访问或紧急授权界面
HIP-11	错误消息中不包含 PHI	§164.312(b)	在 PHI 页面触发错误并检查错误消息
HIP-12	注销后彻底终止 PHI 访问	§164.312(a)(2)(iii)	注销后点击后退按钮，确认不再显示 PHI

浏览器验证： 浏览含 PHI 的页面。测试访问控制。检查 URL、存储和控制台中是否存在 PHI。等待一段时间以测试会话超时。测试注销是否彻底。

SOC 2 信任服务准则（SOC）

适用情形：处理客户数据的企业 SaaS。

检查 ID	检查项	SOC 2 准则	方法
SOC-01	访问所有数据均须进行身份验证	CC6.1	未经身份验证访问数据页面
SOC-02	强制执行强密码要求	CC6.1	使用弱密码测试注册／更改密码
SOC-03	用户账户支持 MFA	CC6.1	检查账户安全设置中是否有 MFA 选项
SOC-04	安全管理会话	CC6.1	检查 Cookie 标志、超时和注销行为
SOC-05	传输中的数据经过加密	CC6.7	确认所有页面均使用 HTTPS，并检查混合内容
SOC-06	访问操作均有记录（审计跟踪）	CC7.2	执行操作并确认存在相应的审计日志条目
SOC-07	监控登录失败尝试	CC7.2	多次尝试登录失败，检查是否触发警报／锁定
SOC-08	用户权限基于角色分配	CC6.3	测试不同角色并确认其拥有适当的访问权限
SOC-09	支持删除数据	CC6.5	测试账户／数据删除功能
SOC-10	提供系统状态页面或健康检查端点	CC7.1	检查是否有状态页面或 /health 端点
SOC-11	错误处理不会泄露内部详情	CC7.4	触发错误并检查是否显示堆栈跟踪
SOC-12	有变更管理迹象（版本控制）	CC8.1	检查版本信息和变更日志

浏览器验证： 测试身份验证边界、密码策略、MFA 流程、基于角色的访问控制，以及审计日志的可见性。

PCI-DSS v4.0 (PCI)

适用场景：应用会处理、存储或传输持卡人数据。

检查 ID	检查项	PCI-DSS 要求	方法
PCI-01	信用卡号绝不完整显示	3.4	查看已保存的卡片，验证是否已遮蔽（仅显示末尾 4 位）
PCI-02	授权后绝不存储或显示 CVV	3.3.2	检查存储内容和 API 响应中是否包含 CVV
PCI-03	支付表单使用 HTTPS	4.1	验证支付页面 URL 和所有资源
PCI-04	支付表单位于符合要求的 iframe 中或通过重定向实现	SAQ A	检查是否使用 Stripe Elements、PayPal 或类似服务
PCI-05	URL 参数中不包含持卡人数据	4.2	检查支付流程中的 URL
PCI-06	客户端存储中不包含持卡人数据	3.2	检查 localStorage、sessionStorage、cookies
PCI-07	控制台日志中不包含持卡人数据	3.2	在支付期间检查 get_browser_console_logs
PCI-08	支付表单会阻止卡片字段自动填充	最佳实践	检查敏感字段是否设置了 autocomplete="off"
PCI-09	支付管理采用强身份验证	8.3	验证管理后台／支付管理是否要求强身份验证
PCI-10	持卡人数据的访问受到角色限制	7.1	使用非管理员用户测试支付数据的访问权限
PCI-11	支付错误消息不会泄露卡片详情	3.2	触发支付错误并检查错误消息
PCI-12	CSP 会阻止在支付页面上运行未经授权的脚本	6.4.3	专门检查支付页面上的 CSP 标头

浏览器验证： 完整体验支付流程。检查卡片显示是否经过遮蔽。检查存储内容和控制台中是否包含持卡人数据。验证支付表单是否使用 iframe／托管式页面（符合 SAQ A 要求）。

GDPR 技术要求（GDPR）

适用场景：应用会处理欧盟个人数据。（注意：隐私专项检查见 /privacy-review — 本节涵盖 GDPR 的技术／合规义务。）

检查 ID	检查项	GDPR 条款	方法
GDPR-01	在处理数据前收集同意	Art. 6, 7	加载页面，检查是否在获得同意前就开始处理数据
GDPR-02	隐私政策可访问且为最新版本	Art. 13, 14	查找并验证隐私政策页面
GDPR-03	提供数据主体访问请求机制	Art. 15	查找数据导出／下载功能
GDPR-04	已实现删除权	Art. 17	查找并测试账户删除功能
GDPR-05	数据可携带性（以标准格式导出）	Art. 20	测试数据导出，并验证格式（JSON/CSV）
GDPR-06	撤回同意与给予同意一样简单	Art. 7(3)	比较给予同意和撤回同意的用户体验
GDPR-07	对未成年人进行年龄验证（如适用）	Art. 8	检查是否有年龄门槛或家长同意机制
GDPR-08	可查阅数据处理记录	Art. 30	检查是否有数据处理活动文档
GDPR-09	数据泄露通知机制	Art. 33, 34	检查是否有事件响应文档
GDPR-10	跨境传输保障措施	Art. 44-49	检查第三方服务的托管位置

浏览器验证： 测试同意流程、数据导出、账户删除和隐私政策的可访问性。检查第三方脚本的来源，留意跨境传输相关问题。

---

阶段 4：报告

生成结构化报告，并保存至 shiplight/reports/compliance-review-{date}.md：

# Compliance Review Report
**Date:** {date}
**URL:** {url}
**Frameworks evaluated:** {HIPAA, SOC 2, PCI-DSS, GDPR}
**Regulated data types:** {PHI, cardholder data, EU personal data}

## Overall Compliance Score: {X}/10 | Confidence: {X}%

## Framework Scores
| Framework | Score | Pass | Fail | N/A | Critical Gaps |
|-----------|-------|------|------|-----|---------------|
| HIPAA | 6/10 | 8 | 3 | 1 | Session timeout, PHI in URL |
| SOC 2 | 7/10 | 9 | 2 | 1 | No MFA, weak audit trail |
| PCI-DSS | 8/10 | 10 | 1 | 1 | Card data in console |
| GDPR | 5/10 | 5 | 4 | 1 | Consent, data export, erasure |

## Compliance Status by Check
(Full table of all checks with PASS/FAIL/N-A status, evidence, and confidence)

## Critical Non-Compliance Items
(Findings that could result in regulatory action, ordered by risk)

## Audit Preparation Checklist
- [ ] Fix all CRITICAL findings
- [ ] Fix all HIGH findings
- [ ] Document accepted risks for MEDIUM findings
- [ ] Run YAML regression tests before audit date
- [ ] Prepare evidence documentation from this report

置信度评分

• 90-100%：已通过浏览器验证，确认存在合规违规（例如，未经身份验证即可看到 PHI，控制台中出现卡号）
• 70-89%：检查中发现有力证据（例如，缺少标头、没有超时行为）
• 50-69%：基于代码模式的架构问题（例如，审计日志可能不完整）
• 低于 50%：不要报告 — 合规发现必须有证据支持

---

阶段 5：修复

1. 修复指南（示例）

#### HIP-02: No session auto-timeout
**Regulation:** HIPAA §164.312(a)(2)(iii) — Automatic logoff
**Risk:** Unattended sessions with PHI visible
**Current:** Sessions persist indefinitely
**Fix:** Implement idle timeout (HIPAA recommends ≤15 minutes for PHI access)
- Add client-side idle detection (mouse, keyboard events)
- Server-side session expiry as backup
- Show warning dialog at 12 minutes
- Auto-logout and clear screen at 15 minutes

2. YAML 回归测试

- name: hip-02-session-auto-timeout
  description: Verify session auto-timeout for HIPAA compliance
  severity: critical
  standard: HIPAA-164.312(a)(2)(iii)
  steps:
    - URL: /login
    - intent: Log in with test credentials
      action: fill
      locator: "getByLabel('Email')"
      value: "[email protected]"
    - intent: Enter password
      action: fill
      locator: "getByLabel('Password')"
      value: "testpass123"
    - intent: Submit login form
      action: click
      locator: "getByRole('button', { name: 'Sign in' })"
    - WAIT_UNTIL: Dashboard with PHI is visible
      timeout_seconds: 15
    - VERIFY: Session timeout warning appears after inactivity period
      timeout_seconds: 900
    - VERIFY: User is automatically logged out after timeout expires
      timeout_seconds: 300

将所有 YAML 测试保存至 shiplight/tests/compliance-review.test.yaml。

---

深度级别

• --quick：仅进行关键检查——身份验证边界和数据暴露。约 3 分钟。
• 默认：完整的适用框架。约 10-15 分钟。
• --thorough：所有检查 + 多角色测试 + 边缘情况 + 文档审查。约 25-40 分钟。

提示

• 运行针对特定框架的合规审查：“仅运行 HIPAA 检查”
• 合规审查需要证据——使用 record_evidence: true 和 generate_html_report 编制审计文档
• 本次审查生成的 YAML 回归测试可用于持续合规监控
• 本次审查仅涵盖技术要求——组织要求（政策、培训）需要人工审查
• 对于隐私相关问题，请配合使用 /privacy-review
• 对于安全相关问题，请配合使用 /security-review
• 使用 close_session 结束会话，并使用 generate_html_report 获取证据