VW 官网 CMS
收到了什么，还差什么

方案

【结论】三个全局过滤器已启用并跑通：跨站伪造请求由 200 变 403，后台登录+MFA、二次确认、内容写、受限资产交付、官网前台 17 项回归全过。

【方案】按「凭证类型」做非对称防护，而不是给所有 API 一刀切上 token。判定链（Config\Filters.php 末尾的 CsrfGuard）：

1. GET/HEAD/OPTIONS/TRACE 直接放行（与框架 Security::verify 口径一致）。
2. 请求不带「浏览器自动附带的凭证」（w2r_cms_session、jwt_token cookie）→ 放行。纯 Bearer 客户端、服务端集成完全不受影响：浏览器不会自动加 Authorization 头，构不成 CSRF。
3. 带 cookie 的写请求先过 Origin/Referer 同源校验（对比请求自身 Host + App::$baseURL 主机 + Security::$trustedOrigins）。Origin: null（沙箱 iframe）判为不可信。两个头都没有 → 判为非浏览器客户端，交给第 4 层。
4. 再判是否要 token：非严格模式下，Authorization 头里有验签通过的 Bearer → 免（持有型凭证，跨站伪造不出来）；api/auth/login、api/auth/logout、api/preview/access/* 免（此时前端还没有 token，但仍受第 3 层保护）；其余一律走框架 Security::verify()（双提交 Cookie，token 可来自 X-CSRF-TOKEN 头、JSON 体的 csrf_token 字段或表单字段）。第 4 层覆盖的正是 AuthFilter.php:30-35 那条 Session 兜底认证路径——也就是本项要堵的洞。

【为什么这么选，备选为什么没选】

• 备选 A「所有写请求都要 token」：/AdM/ 跑的是 Vite 构建产物 public/AdM/assets/index-B4flQGaA.js（全文搜 csrf 命中 0 次），红线禁止 npm/vite 重新构建，一刀切会让现网后台全线 403；同时会打断纯 API 客户端。已在临时开严格模式时实测复现（S1 = 403）。
• 备选 B「只靠 SameSite Cookie 当主防线」：现状 session cookie 已经是 SameSite=Lax（实测 Set-Cookie: w2r_cms_session=...; HttpOnly; SameSite=Lax），能挡大部分跨站表单/fetch，但 SameSite 是按可注册域（eTLD+1）判定的——volkswagengroupchina.com.cn 下任意子域都算「同站」，被攻陷的子域照样能带上 cookie。Origin 校验比的是精确主机，正好补上这一刀。而且 Cookie.php 不在本项可改文件清单里，无法把它改成 Strict。所以 SameSite 作为既有第一道线保留，Origin+Token 作为本项新增的第二、三道线。
• 备选 C「csrfProtection 改 session 模式」：session 驱动是 FileHandler，多实例不共享，token 会随机失效。故保持 cookie（双提交）模式，服务端无状态。
• 删掉 AuthFilter 的 Session 兜底：不在本项可改文件内，且 ConfirmTokenService 和 AssetDeliveryController.php:52 依赖 session，删了会挂。本项选择「保留能力、关闭可利用性」。

【顺带修掉的坑】启用 invalidchars 后，非法 UTF-8 会让框架把原始非法字节塞进异常消息，本系统的 JSON 信封渲染再次 json_encode 失败 → 500 Fatal（实测）。所以用 InvalidCharsGuard 包了一层，收敛成 403 JSON 且不回显原始字节。另外框架在 before 过滤器短路时不跑 after 过滤器，403 响应会漏掉安全头和新 token，已在拒绝出口补齐，前端因此可以自动重试一次。

【前端】admin-frontend/js/api/index.js 增加 csrfManager：从每个响应头读 X-CSRF-TOKEN 存 sessionStorage，写请求（POST/PUT/PATCH/DELETE）自动回传，遇 code=4039 用响应里的新 token 自动重试一次。这份改动是源码，本次未构建（红线禁 vite），当前默认非严格模式下不构建也不影响现网。

修复前（实测输出）

全部在整改前配置下实测（第二组是把备份 Filters.php 换回去、等过 OPcache 2s 重校验窗口后复测的，md5 68ea94c0666a1990406d73c4aef58d2f）。

A. 会话 Cookie 属性（说明 SameSite=Lax 是唯一既有防线）
$ curl -s -D - -o /dev/null http://localhost:1977/api/auth/captcha | grep -i set-cookie
Set-Cookie: w2r_cms_session=5341fd998b456075c945ea70f7471095; path=/; HttpOnly; SameSite=Lax

B. 跨站伪造：完整登录（含 MFA）后的 cookie jar，不带 Authorization，Origin 指向攻击者站点
$ curl -s -i -b /tmp/vw_oracle.jar -X POST http://localhost:1977/api/auth/confirm-token \
    -H 'Content-Type: application/json' -H 'Origin: https://evil.example.com' \
    -H 'Referer: https://evil.example.com/csrf.html' \
    -d '{"operation":"csrf_probe","password":"Vgc@Local2026"}'
HTTP/1.1 200 OK
Content-Security-Policy: base-uri 'self'; child-src 'self'; connect-src 'self'; default-src 'self'; font-src 'self'; form-action 'self'; img-src 'self' data:; object-src 'self'; script-src 'self' 'nonce-OMmPtbu6sqoSmqQB'; style-src 'self' 'nonce-3jT1Hj/bPPHEHXZK'; script-src-elem 'self' ...; style-src-attr 'self'
{
    "code": 0,
    "message": "确认token生成成功",
    "data": { "token": "516bc69d0612a4f7d325575bce672d79" },
    "trace_id": "cf6597827dc0da08"
}
（注意 CSP 里没有 frame-ancestors；二次确认令牌被签发给了「攻击者来源」的请求）

C. 跨站伪造 + 真实写库
$ curl -s -b /tmp/vw_oracle.jar -X POST http://localhost:1977/api/dam/categories \
    -H 'Content-Type: application/json' -H 'Origin: https://evil.example.com' \
    -d '{"name":"C

修复后（实测输出）

同样的请求，整改后配置（Filters.php md5 ebb6d50824b2de30844c8245a5f55a6d、Security.php md5 c50f9a0b6f60c121d2c3e4059c88c848）。

B'. 跨站伪造 + 攻击者 Origin → 被来源层拦截
$ curl -s -w "\nHTTP %{http_code}\n" -b /tmp/vw_r1.jar -X POST http://localhost:1977/api/auth/confirm-token \
    -H 'Content-Type: application/json' -H 'Origin: https://evil.example.com' \
    -d '{"operation":"csrf_probe","password":"Vgc@Local2026"}'
{
    "code": 4030,
    "message": "请求来源不可信，已拒绝（CSRF 防护）",
    "data": null,
    "trace_id": "e1d20638432e4f5f"
}
HTTP 403

C'. 跨站伪造 + 不发 Origin（模拟不发 Origin 的老浏览器）→ 被 token 层拦截
$ curl -s -o /dev/null -w "HTTP %{http_code}\n" -b /tmp/vw_r1.jar -X POST http://localhost:1977/api/dam/categories \
    -H 'Content-Type: application/json' -d '{"name":"CSRF-SHOULD-FAIL"}'
{ "code": 4039, "message": "CSRF Token 缺失或无效，已拒绝", "data": null, "trace_id": "5be45bf4c912d5de" }
HTTP 403
（数据库复查 asset_categories 中 name like 'CSRF-%' 为空，未写入）

D'. 安全响应头（/AdM/dashboard，走 PHP 的路由）
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Referrer-Policy: same-origin
X-Download-Options: noopen
X-Permitted-Cross-Domain-Policies: none
CSP:  frame-ancestors 'self'      ← 新增（完整 CSP 其余指令不变）

E'. 非法 UTF-8 查询串 → 403 JSON（此前 200 静默接受；中间态曾是 500 Fatal，已由 InvalidCharsGuard 收敛）
{ "code": 4040, "message": "请求包含非法字符（无效编码或控制字符），已拒绝", "data": null, "trace_id": "e228fa5cdde1547a" }
HTTP 403

F'. 畸形 JSON 体（含 \x01）：整改前 HTTP 500、

部署到 VW 服务器时的注意事项

1)【多实例安全，无本地状态】CSRF 走 cookie 双提交（Config\Security::$csrfProtection='cookie'），令牌哈希只存在客户端的 HttpOnly cookie w2r_csrf 里，服务端不落任何存储，因此多台 nginx+PHP-FPM、多容器副本、无粘性会话都不影响 CSRF 校验。Origin 校验的可信主机来自「请求自身的 Host 头」，同样自适应任何部署域名，不需要按环境改代码。 但要提醒：本系统 session 驱动是 CodeIgniter\Session\Handlers\FileHandler（.env: session.driver），文件 session 跨实例不共享 —— 这是既有问题、不是本次引入，多实例部署时要么开会话粘滞，要么把 session 换成 Redis/DB handler，否则 ConfirmTokenService 的二次确认码和 AssetDelivery 的 session 判定会在实例间漂移。

2)【必须由运维在 Web 层补的一处】/AdM/ 和 /AdM（后台入口首屏文档）在 backend/public 下是真实目录，被 Apache 的 DirectoryIndex 直接吐出 index.html，根本不进 PHP —— 实测该响应没有任何安全头，CI 的 secureheaders 过滤器管不到。走 PHP 的 /AdM/dashboard 等 SPA fallback 路由已经有 X-Frame-Options: SAMEORIGIN 和 CSP frame-ancestors 'self'。上线前请在站点配置里补： nginx: add_header X-Frame-Options "SAMEORIGIN" always; add_header X-Content-Type-Options "nosniff" always; add_header Referrer-Policy "same-origin" always; add_header Content-Security-Policy "frame-ancestors 'self'" always; Apache: Header always set X-Frame-Options "SAMEORIGIN" 等同上（需 mod_headers）。 否则点击劫持防护在真正的后台入口页上是缺失的。

3)【反向代理与 Origin 校验】Origin/Referer 比对的是请求的 Host 头（忽略 scheme，容忍 TLS 在代理侧终止）。如果 nginx 反代改写了 Host（没有 proxy_set_header Host $host），浏览器发来的 Origin 会与 PHP 看到的 Host 对不上，所有带 cookie 的写请求会 403。两条路任选：代理透传原始 Host（推荐），或在生产 .env 里写 security.trustedOrigins = 'https://cms.正式域名,https://备用域名'（逗号分隔，可带端口）。上线后请务必用真实域名跑一遍「登录 + 改一条内容」。

4)【前端必须重新构建】/AdM/ 跑的是 Vite 构建产物 backend/public/AdM/assets/index-*.js，本次只改了源码 admin-frontend/js/api/index.js，红线禁止 npm/vite 所以没有构建。当前默认（csrfStrictMode=false）下旧构建包完全可用（回归组1-3 就是按旧包的请求形态测的）。发版时请把前端重新构建发布，让 X-CSRF-TOKEN 回传真正生效。

5)【严格模式的开启条件】想让「所有带 cookie 的写请求都必须带 token」，把 Config\Security::$csrfStrictMode 置 true，或 .env 写 security.csrfStrictMode = true。前提有两个，缺一个就会挂：a) 上面第 4 条的前端重新构建已发布；b) admin-frontend/js/api/dam.js 的 uploadChunk 是自己裸写的 fetch（不走 api/index.js），必须补 X-CSRF-TOKEN 头 —— 那个文件不在本项可改清单里，需要另派。建议流程：先发前端 → 观察 operation_logs 里 module='security'、operation='csrf_token_reject' 是否为 0 → 再开严格模式。

6)【OPcache】容器实测 opcache.e

方案

核心是在 UserSessionService 里新增一个每请求执行的 checkAccess()，用一条 SQL 同时取回账号状态与会话状态，由 AuthFilter / AuthNoMfaFilter 在放行前调用；四类操作因此在下一个请求即时生效。

一条 SQL 覆盖四种失效：SELECT u.is_active, u.role, s.id, s.revoked_at FROM users u LEFT JOIN user_sessions s ON s.jti=? AND s.user_id=u.id WHERE u.id=?。users 走主键、user_sessions 走 jti 唯一索引，EXPLAIN 两表都是 const，实测 0.187 ms。判定顺序：账号不存在 → 账号被禁用 → 角色与 token claim 不符 → 会话已撤销 / 未登记。

关于「登录阶段 token 从未登记」这个陷阱，我选择的是按路由区分校验强度⁠，不是在登录阶段补登记。理由有三条：(1) 补登记必须能区分「未完成 MFA 的半程会话」和「已认证会话」，否则 establishAuthenticatedSession 里那段并发登录检测会把用户自己的登录阶段行算成「已有活动会话」，每次正常登录都误报一条 concurrent_login_detected —— 而并发登录检测本身也是等保要交付的控制项，不能污染；(2) 要区分就得加列，加列要迁移文件，而迁移文件不在我可改文件清单里，禁令又不允许跑 php spark，直接 ALTER 会让交付树 schema 与实例漂移，部署到 VW 必然炸；(3) 登录阶段 token 的权限面只有 auth/me、mfa/status、mfa/enroll、mfa/verify 四条，本来就不承载业务权限。所以 AuthFilter（mfa_verified=true，必然由 mfaVerify 登记过）要求 jti 必须在册；AuthNoMfaFilter 允许 jti 不在册，但只要在册且已撤销就拒。

为了让「登录阶段 token 也能被撤销」，revokeSession() 改成 upsert 写「墓碑」行：jti 不在表里就直接插一条 revoked_at 非空的记录（jti 上有 UNIQUE，ON DUPLICATE KEY UPDATE revoked_at=IFNULL(revoked_at,?) 保证幂等且不覆盖首次撤销时刻）。登出因此对两个阶段的 token 都生效。另外 mfaVerify 成功后主动撤销登录阶段那枚 token —— 它是一次性步进凭证，泄露后可在有效期内重放去改 MFA 绑定。

角色降级（缺陷 3）的处理方式是「让 claim 不可能陈旧」，而不是改 requireRoles —— ApiController 不在我可改文件清单里。过滤器比对 JWT 的 role claim 与库里 users.role，不一致直接 401 让其重新登录。效果等价且更强：requireRoles 读到的 claim 只可能是当前库值，同时角色升级方向也一并收敛。mfaVerify 里签发新 token 时的角色也改成以库为准（原来读的是 JWT claim）。

拒绝一律返回 HTTP 401 + 业务码 1001，因为 admin-frontend/js/api/index.js 对 1001 的既有处理正是「补写登出审计 → 清 token → 跳登录页」，与会话失效应有的表现一致；message 按原因区分，便于用户和运维定位。每次会话级拒绝写一条 operation_logs（module=auth，operation=session_reject，result=fail，error_code=1001，request_summary 带 reason/jti/path/method），用独立 operation 与权限不足的 access_denied 区分，且不受 audit.log_access_denied 开关控制。

LogoutAuthFilter 刻意保持始终放行，只补了注释说明原因：登出是幂等收敛动作、不暴露数据，且前端收到 1001 后要靠它补写登出审计，拦住会让这条审计永远写不进来。

备选方案：(a) 把撤销状态放进缓存（Redis/文件）避免查库 —— 当前 Config/Cache.php 是 file 句柄，多实例下各写各的，撤销会按 TTL 延迟生效，与「即时」直接冲突，且实测查库代价 0.19 ms，不值得；(b) 在 JWT 里塞版本号、靠版本号失效 —— 需要改 JwtService 与签发逻辑，且无法表达单会话撤销（登出只想踢当前这一枚）；(c) 改 ApiController::requireRoles 去查库 —— 文件不归我，且不能解决登出与踢人。

修复前（实测输出）

脚本 scratchpad/sess_oracle.sh，测试账号 zz_sess_probe(id=7, sys_admin, 已录 MFA)，整改前输出（scratchpad/sess_oracle_before.txt，节选）：

### 0. probe 完整登录
stage1_token jti=cb8462c113015ef0f2312cabec4eaf75 role_claim=sys_admin mfa=False
stage2_token jti=a59f2ee53cab157524cd85fb34fa2f4f role_claim=sys_admin mfa=True
基线 GET /api/system/session-config: HTTP=200

### 1. 登出后旧 token 应失效
POST /api/auth/logout -> HTTP=200
user_sessions.revoked_at = 2026-08-11 22:05:02      ← 撤销确实写进库了
登出后复用同一 token: HTTP=200 {"code":0,"message":"操作成功",...}   ← 仍然有效

### 2. 并发登录踢人（revoked_at 已写入）后旧 token 应失效
jti=c5369dff0b9ee7f2325b43743a8564ca revoked_at=2026-08-11 14:05:03
HTTP=200 {"code":0,...}                              ← 踢人不生效

### 3. 禁用账号后 token 应失效
users.is_active=0
auth 路由:        HTTP=200 {"code":0,...}
auth_no_mfa 路由: HTTP=200 {"code":0,"data":{"id":"7","username":"zz_sess_probe",...}}   ← 禁用不生效

### 4. 角色降级后 requireRoles 应即时失效
users.role=editor / token role claim=sys_admin
HTTP=200 {"code":0,...}

### 5. MFA 完成后，登录阶段旧 token 仍可用
GET /api/auth/me: HTTP=200

补充：缺陷 3 的专项预言机（scratchpad/sess_oracle_roles.sh，把 AuthFilter.php 临时换回原始文件后跑），证明 requireRoles 与 requirePermission 强度不一致：
库内角色已降级为 editor，token 仍声称 sys_admin
[整改前] requireRoles 路径   GET /api/audit/query : HTTP=200 {"code":0,"message":"操作成功",...}   ← 只信 claim，降级无效
[整改前] requirePermission 路径 GET /api/users     : HTTP=400 {"code":6001,"message":"无权限访问"}  ← 查库，降级已生

修复后（实测输出）

同一脚本、同一账号，整改后输出（scratchpad/sess_oracle_after.txt / sess_oracle_after2.txt）：

### 1. 登出后旧 token 应失效
POST /api/auth/logout -> HTTP=200
user_sessions.revoked_at = 2026-08-11 22:10:24
登出后复用同一 token:
HTTP=401 {"code":1001,"message":"会话已失效（已登出或被新登录挤下线），请重新登录"}

### 2. 并发登录踢人后旧 token 应失效
jti=07553b553782a3c93015ee2156543f20 revoked_at=2026-08-11 14:10:25
HTTP=401 {"code":1001,"message":"会话已失效（已登出或被新登录挤下线），请重新登录"}

### 3. 禁用账号后 token 应失效
users.is_active=0
auth 路由:        HTTP=401 {"code":1001,"message":"账号已被禁用，请联系管理员"}
auth_no_mfa 路由: HTTP=401 {"code":1001,"message":"账号已被禁用，请联系管理员"}
（随后恢复 is_active=1）

### 4. 角色降级后 requireRoles 应即时失效
users.role=editor / token role claim=sys_admin
HTTP=401 {"code":1001,"message":"账号角色已变更，请重新登录"}
（随后恢复 role=sys_admin）

### 5. MFA 完成后，登录阶段旧 token 已作废
GET /api/auth/me: HTTP=401 {"code":1001,"message":"会话已失效（已登出或被新登录挤下线），请重新登录"}

缺陷 3 专项（换回整改后的 AuthFilter，独立复现一次，scratchpad 内交互验证）：
token role=sys_admin，库 role 降为 editor 后
GET /api/audit/query  : HTTP=401 {"code":1001,"message":"账号角色已变更，请重新登录"}
GET /api/users        : HTTP=401 {"code":1001,"message":"账号角色已变更，请重新登录"}
角色恢复 sys_admin 后 GET /api/audit/query : HTTP=200

审计落库（operation_logs，operation=session_reject）：
628  7  sys_admin  session_reject  1001  {"reason":"session_revoked","jti":"ed3b37ff...","path":"/index.php/api/system/session-config","method":"GET"}
620  7  editor     session_reject  1001  {"reason":

部署到 VW 服务器时的注意事项

1. 无 schema 变更、无新增迁移、无种子数据。直接覆盖这 5 个 PHP 文件即可，不需要 DBA 配合，不需要停机。回滚就是把文件换回去（备份在 scratchpad/sess_bak/*.orig，含 md5）。

1. 多实例安全：判定依据全部来自 MySQL（users 与 user_sessions 两张共享表），没有引入任何依赖单机本地状态的东西。实例 A 上的登出/踢人/禁用/改角色，实例 B 下一个请求就生效。nginx + PHP-FPM 多实例、容器多副本都成立。

1. 刻意不加缓存，请勿「优化」成缓存：当前 app/Config/Cache.php 的 handler 是 file，是每实例本地的；一旦给撤销状态加 TTL 缓存，其他实例上的撤销会延迟到 TTL 到期才生效，直接违背「即时生效」这条控制要求。代价已量化：EXPLAIN 两表均 const（users 主键 + user_sessions 的 jti 唯一索引），查询 0.187 ms，端到端 20 次采样 26.7 ms vs 无鉴权基线 27.3 ms，在噪声以内。若后续 QPS 真的上来了，正确做法是换共享 Redis（Config\Cache handler=redis）并把 TTL 压到 ≤5 s，同时在登出/踢人/禁用/改角色四处主动失效缓存键——不要用 file 句柄做这件事。

1. 请求内备忘（static $accessMemo）在 PHP-FPM / mod_php 下天然按请求隔离；key 里带了 $_SERVER['REQUEST_TIME_FLOAT']，Swoole / RoadRunner 这类常驻 worker 也不会跨请求复用，且超过 64 条自动清空。CLI（spark）不走过滤器，不触发此逻辑。

1. 上线当天的一次性影响：任何「已签发但 jti 不在 user_sessions 里」的 mfa_verified token 会被判 session_unknown 并要求重新登录。VW 全新部署不存在这类 token；若是在已有环境热更新，等于让当前在线的管理员重新登录一次，建议放在低峰。

1. 与验收命令的冲突（重要）：app/Commands/AuditAcceptance.php:49 与 AuditAcceptanceExtended.php:47 用 JwtService::generate(1,'sys_admin',true) 直接伪造 token、并不写 user_sessions。本次整改后这类伪造 token 访问 auth 路由会被判 session_unknown 而 401，两个验收命令里依赖 HTTP 探测的子项会失败。这两个命令本轮属红线禁跑，我没有验证，但按代码可以确定。要继续用，需要在命令里补一次 establishAuthenticatedSession 登记 jti，或改成走真实登录流程——文件不在我可改清单内。

1. 时区坑：user_sessions.revoked_at 由 PHP 侧 date('Y-m-d H:i:s') 按应用时区（Asia/Shanghai）写入，而库里另有一些行是 MySQL NOW()（UTC）写的，同一列存在 8 小时差。我的判定只用 IS NULL / IS NOT NULL，不做任何时间比较，所以不受影响；后续若有人要加「撤销后 N 分钟内…」这类时间窗逻辑，必须先统一这一列的时区来源。

1. PHP Session 仍是 FileHandler（Config\Session::$savePath = WRITEPATH.'session'），是每实例本地状态。二次确认码（ConfirmTokenService）、受限资产交付（AssetDeliveryController）以及 AuthFilter 的 Session 兜底鉴权都依赖它。这不是本次引入的，但多实例部署必须配置会话粘滞（ip_hash / sticky cookie）或换共享会话存储（Redis/数据库），否则这三条链路会随机失败。

1. 审计写入量：每次会话级拒绝写一条 operation_logs（operation=session_reject）。触发前提是管理员做过登出/踢人/禁用/改角色，量很小；前端收到 1001 会立刻清 token 跳登录页，实测一次拒绝只产生 1-2 条。非浏览器客户端若拿着已撤销 token 死循环重试，会按请求数写入，运维侧可在 SIEM 上对 session_reject 做频次告警（这本身也是有价值的信号）。

1. 建议同时确认 config 表里 auth.allow_concurrent_

方案

两类数据分开处理，因为它们的业务需求不同。

一、TOTP 密钥 —— 必须可逆，所以做真加密。系统要用它算 TOTP、未完成注册时还要重出二维码，只能可逆加密。选的是 PHP 原生 openssl 的 AES-256-GCM，没用 CI4 自带的 CodeIgniter\Encryption\Encryption，理由有三条，都是可验证的事实而不是偏好：

1. CI4 的 OpenSSLHandler 是 AES-256-CTR + HMAC-SHA512（system/Encryption/Handlers/OpenSSLHandler.php:78-110），安全但不是 AEAD，无法绑定附加数据。我们需要把密文绑到「哪一行」上：AAD = "vgc-mfa-secret|<user_id>|<provider_type>"。有了它，DBA 把 A 的密文整列搬到 B 的行上会直接认证失败（单测第 2 组已验证）。CI4 的两个 handler 都表达不了这件事。
2. CI4 的密文里没有密钥标识（kid），轮换时无法判断某一行是用哪把密钥加的，只能靠「挨个试」。我们的信封格式 mfa1:<kid>:<base64(iv|tag|ct)> 自带 kid，轮换是确定性的机械操作。
3. 没选 sodium：CI4 的 SodiumHandler 用 sodium_crypto_secretbox，这个 API 根本没有 AAD 参数（system/Encryption/Handlers/SodiumHandler.php:44-77），而且它会 sodium_memzero 掉传入的明文缓冲区，调用方的变量在 encrypt() 之后会变成一片 \0，是个容易踩的坑。AES-GCM 有 AES-NI 硬件加速，也是等保/密评评估人员最熟的 NIST SP 800-38D 算法。

主密钥不直接参与加密，按用途做 HKDF-SHA256 派生子密钥（info = "vgc:mfa:secret:aes-256-gcm:v1"），和备用码 pepper 的子密钥彼此隔离。

二、备用码 —— 只需校验不需读回，所以哈希存储。存法是 bcrypt(cost=10) 套在 HMAC-SHA256 pepper 之外：先 HMAC-SHA256(pepper, "<user_id>|<code>")，再 bcrypt。两层各解决一个问题：pepper 不在数据库里（跟加密密钥同源于密钥环），所以整库泄露也没法离线爆破只有 20 bit 熵的 6 位备用码；bcrypt 则是在密钥也泄露的情况下的第二道墙（等保要求鉴别信息「不可逆」，评估人员会找口令哈希算法）。HMAC 里绑了 user_id，把哈希搬到别人行上同样失效（单测已验证）。代价是 TOTP 不匹配时要跑 8 次 bcrypt ≈ 560ms，所以顺序做了调整：先算 TOTP（几次 HMAC，微秒级），不中再比备用码——正常登录一次 bcrypt 都不跑。

备用码没法再回显：getExistingMfaSecret() 现在返回 backup_codes: [] 加一个 backup_codes_remaining 计数。前端 MfaEnroll.vue:51 是 v-for，空数组不渲染也不报错（前端不在我的可改文件范围内）。

三、密钥管理放在 Config\Encryption 里做成「密钥环」，四级优先级：encryption.keyFile（推荐，K8s Secret / KMS 落盘，支持多密钥 JSON）> encryption.keys（内联 JSON 多密钥）> encryption.key（CI4 传统单密钥）> 开发兜底（仅非 production，由 JWT_SECRET 做 HKDF 派生）。生产环境缺密钥直接抛异常，不退回明文，也不自动生成——自动生成会让每个实例各拿一把，多实例下必炸。开发兜底是本地不能改 .env（红线 4）的折中，它是确定性的（同一份 .env 派生同一把密钥），多实例也一致，但已明确写死 ENVIRONMENT === 'production' 时禁用。

备选方案没选的原因：直接用 CI4 encrypter（无 AAD、无 kid，见上）；把密钥写死在代码里（多实例可以，但轮换要发版，且进 git）；用 writable/ 下自动生成的密钥文件（每个实例一把，多实例直接崩，明确排除）。

修复前（实测输出）

$ bash mfa_before.sh
== 1. 数据库里的原始值 (root 只读 SELECT) ==
1	1	M1lUUjIyWDIyNjYySzQyVUVQQUlQVVRQUUE=	WyIxMzc0NjYiLCI0NTk3MTAiLCI0MTE3NjEiLCI5NTQwMDQiLCIxNzY1MTMiLCI1NzcwMTgiLCI1MjA3ODQiLCIyMDQxOTQiXQ==
3	6	M1lUUjIyWDIyNjYySzQyVUVQQUlQVVRQUUE=	W10=
4	5	M1lUUjIyWDIyNjYySzQyVUVQQUlQVVRQUUE=	W10=

== 2. 仅用数据库里的值还原明文 + 现算一枚 TOTP ==
  user_id      = 1
  TOTP 明文密钥 = 3YTR22X22662K42UEPAIPUTPQA    <-- base64_decode 即可，无需任何密钥
  备用码明文    = ['137466', '459710', '411761', '954004', '176513', '577018', '520784', '204194']
  现算 TOTP     = 369834    <-- 可直接过 /api/auth/mfa/verify

== 3. 代码注释与事实 ==
72:        $secretBase32 = base64_decode($mfaSecret->secret);
73:        $backupCodes = json_decode(base64_decode($mfaSecret->backup_codes), true) ?? [];
110:        // 加密存储（Base64编码）        <-- 注释谎称加密
111:        $encryptedSecret = base64_encode($secret);
112:        $encryptedBackupCodes = base64_encode(json_encode($backupCodes));
217:        $secretBase32 = base64_decode($mfaSecret->secret);
221:        $backupCodes = json_decode(base64_decode($mfaSecret->backup_codes), true);

结论：一条 SELECT 就拿到全部管理员的第二因子种子和全部备用码明文；上面现算出的 369834
随后原样喂给 /api/auth/mfa/verify，返回 {"code":0,"message":"MFA验证成功"} —— 拿到库 = 完全绕过 MFA。

修复后（实测输出）

$ SELECT id,user_id,secret,LEFT(backup_codes,90) FROM vgc.mfa_secrets WHERE user_id=1\G
               id: 1
          user_id: 1
           secret: mfa1:dev-jwt:kSiTqvbcK9Z755/jel9Zrv4OXP0mIYg4cO7S5pBMm2h7VulaH7WmtA/cJj0rp12z6Gid6K7O
backup_codes_head: {"v":1,"alg":"bcrypt(hmac-sha256)","kid":"dev-jwt","codes":["$2y$10$tJMWQbUJB7IMREYgeFqEtu

对整改前那套还原手法再试一次：
  base64_decode -> 失败: Error
  库里能看到的全部信息就是这串密文，没有密钥环解不出 TOTP 种子

回归套件 R1 的机器判定：
  PASS  无遗留明文密钥行  (0)
  PASS  无遗留明文备用码行  (0)
  PASS  旧手法(base64_decode)已无法还原密钥  (UNRECOVERABLE)

加密层单测（32 项全过，摘要）：
  PASS  密文带版本前缀 / 密文不含明文 / 往返一致 / 两次加密密文不同(随机 IV)
  PASS  换 user_id 解不开        <-- AAD 绑定，防止密文在行之间搬运
  PASS  换 provider 解不开
  PASS  翻转 1 bit 后解密返回 null   <-- GCM 认证标签，兼顾存储完整性
  PASS  信封中不含明文 137466 / 459710 / 000123
  PASS  正确备用码可校验通过 / 错误备用码校验失败
  PASS  同一备用码换个 user_id 校验失败(绑定生效)
  PASS  过短密钥被拒 (encryption.key 的密钥长度不足（5 字节 < 16）)
  PASS  多密钥环下 activeKid 指向不存在的密钥被拒 (可用 kid：k1,k2)
  PASS  首尾含空白/NUL 字节的二进制密钥不被 trim 破坏（keylen=32）
生产 fail-closed（独立进程，ENVIRONMENT=production）：
  PASS  生产环境缺密钥直接抛错: MFA 静态加密密钥未配置：请设置 encryption.keyFile 或 encryption.key（生产环境不提供任何兜底）。
  PASS  生产环境配好 encryption.key 后加解密正常 (source=encryption.key)

部署到 VW 服务器时的注意事项

【一、密钥从哪来 —— 上线前必须完成，否则 production 起不来（这是故意的）】 生成：openssl rand -base64 32 四条来源按优先级，全部在 Config\Encryption 里解析，CI4 的 BaseConfig 支持用 . 或 _ 两种写法读环境变量 （encryption.key / encryption_key / Config\Encryption.key 都认，实现见 system/Config/BaseConfig.php:211-250）：

1. encryption.keyFile（推荐）—— 指向一个密钥文件。内容二选一：

裸密钥文本：base64:xxxxxxxx（也支持 hex2bin: 前缀或原始文本） JSON 密钥环：{"active":"vw-2026q3","keys":{"vw-2026q1":"base64:...","vw-2026q3":"base64:..."}} 文件权限 0400、属主为 PHP-FPM 运行用户。这条最适合 VW 的 KMS/凭据托管：无论是 K8s Secret 挂载、 Vault Agent sink、还是云 KMS 凭据插件落盘，最终形态都是「一个只读文件」，应用不需要认识 KMS SDK。 注意文件必须是文本，不要写原始二进制（读入时会 trim 掉首尾空白）。

1. encryption.keys —— 内联 JSON 多密钥，配 encryption.activeKid。适合密钥只走环境变量、不落盘的场景。
2. encryption.key —— CI4 传统单密钥。kid 默认 k1，可用 encryption.activeKid 给它命名。
3. 开发兜底 —— 仅当 ENVIRONMENT !== 'production' 且存在 JWT_SECRET 时，由 JWT_SECRET 做 HKDF 派生，

kid=dev-jwt，并写 warning 日志。本地这套环境走的就是这一条（因为红线禁止改 .env）。 production 下这条被硬关：缺密钥直接抛 RuntimeException「生产环境不提供任何兜底」，不会退回明文、 也不会自动生成密钥（自动生成会让每个实例各拿一把，多实例必炸）。

【二、多实例：所有实例必须是同一把密钥】 密钥环没有任何单机本地状态（不写 writable/、不生成本地文件、不依赖机器指纹）。所有实例读同一份 keyFile / 同一组环境变量即可。nginx + PHP-FPM 形态要特别注意两点：

• PHP-FPM 默认 clear_env=yes 会清掉父进程环境变量。要么在 pool 配置里写 env[encryption.keyFile] = /etc/vgc/mfa.key，

要么设 clear_env=no，要么干脆写进 backend/.env（.env 会被 CI4 的 DotEnv 读进 $_ENV）。 只在 systemd 的 EnvironmentFile 里设、而不透传给 pool，是最常见的「本地好好的、上线读不到」。

• 改了密钥配置要 reload php-fpm；如果开了 OPcache + preload，preload.php 会缓存 Config 类，必须 reload 而不是等它自己过期。

容器化形态：keyFile 用只读 volume / Secret 挂载；不要把密钥烤进镜像层。

【三、发布顺序（多实例下这个顺序不能反）】

1. 先给所有实例配好密钥（此时老代码不读它，无副作用）。
2. 再把新代码发到所有实例。新代码读得懂旧的 base64 格式（encryption.mfaAllowLegacy 默认 true），

所以灰度期间新老实例共存不会互相打架。

1. 全部实例都换成新代码之后，再跑一次 php spark migrate（本迁移幂等，重跑安全）。

反过来先跑迁移会让还没更新的实例读不懂新格式 —— 那一刻起没换代码的实例上谁都过不了 MFA。 代码层面也是按这个假设写的：读路径刻意不做「遗留 base64 -> 密文」的自动升级，只做 kid 轮换的自愈重封装， 就是为了不让灰度期间的某个新实例把行改成老实例读不懂的样子。

1. 迁移完成、观察一两天没有 legacy 相关日志后，把 encryption.mfaAllowLegacy 设为 false，

堵死降级读取这条路（那之后往库里塞 base64 明文将不再

方案

【做了什么】把「栏目管理需要哪个权限码」从代码里的硬编码变成外置配置：新建 Config\ChannelAcl 定义 read / write / reorder 三个受控动作与四套候选方案（preset），ChannelController 六个方法各加一行 guardChannel(动作) 门禁。生效优先级：config 表 > .env > 配置文件。甲方改一行 SQL 即可在四个方案之间切换，或用 channel.acl.rules（JSON）单独收紧某一个动作，均不需要改代码、不需要发版、不需要重启。

【实测的四个候选方案对比】（角色权限数据来自 role_permissions 实查） 当前七个角色实际持有：editor 8 个码（content:create/edit/delete/submit、dam:upload、figma:import、preview:create/revoke）；reviewer_l1 7 个；reviewer_l2 8 个；publisher 8 个；dam_admin 3 个（仅 dam:）；audit_readonly 2 个（仅 audit:read/export）；sys_admin 22 个（全部）。全库共 22 个权限码，无任何 channel:⁠。

方案 A「新增 channel:manage」：需 permissions 表 +1 行、role_permissions 授权、ChannelAcl 切 channel_manage；理想上前端 menu-permissions.js:7 也应加上该码，否则只拿 channel:manage、没有 content:* 的角色看不到栏目菜单。得失：默认只有被显式授权的角色能写，语义最干净、最符合最小权限。迁移成本：一次 DB 变更（已提供幂等 SQL 与幂等种子方法）+ 可选前端一行。实测：种码后 sys_admin 可写、editor 被拒；把该码授予 editor 角色后 editor 立刻可写（证明「改配置+改角色授权」即可放权，无需改代码）。

方案 B「复用 content:edit」：零 DB 变更、零前端变更，成本最低。但 editor、reviewer_l1、reviewer_l2、publisher 四个角色全部获得增删改栏目与拖动整棵导航树的能力（实测 policy=content_edit 时 editor read/write/reorder 全部放行）。栏目 slug 是前台 URL 的一部分，等于把改线上 URL / 断链 / 掉 SEO 的能力发给所有内容岗，不满足最小权限。

方案 C「按读写分离」（本次默认）：read = content:create|content:edit|content:edit_all（与前端菜单门禁完全同一组码），write/reorder = content:edit_all（当前库中仅 sys_admin 持有）。零 DB 变更、零前端变更、当场堵住越权，且不误伤内容生产——News.vue:686 与 Content.vue:914 都要调 channelApi.getList() 取栏目下拉，读若收紧编辑器会直接不能选栏目。代价是语义耦合：content:edit_all 本意是「编辑所有内容」，被借用为「能管栏目」。

方案 D「仅 sys_admin」：零 DB 变更、最严。代价是授权变成运维动作——无法再通过「角色管理」界面把栏目维护授权给任何人；且与本系统既有设计（PermissionService 严格按 role_permissions 校验、明确不做 sys_admin 特例）相悖，等于引入角色硬编码。

【为什么默认选 C】1) 零 DB 变更即可生效，不跑种子也不会锁死任何人；2) 不误伤内容生产（编辑器栏目下拉照常）；3) 立刻堵住越权——实测 audit_readonly 六个端点全 6001；4) 可平滑放权：甲方在角色管理界面给某角色 content:edit_all 即可，想要干净语义再切 channel_manage。

【防呆（已实测）】policy 写错名字、或切到 channel_manage 却忘了跑种子（权限码在 permissions 表里不存在）、或某动作解析后既无权限码也无角色——三种情况都自动回落到默认 split 并写 error 日志，不会把接口重新变成人人可改，也不会把所有人锁在门外。

【备选方案为什么没选】直接把 requirePermission('content:edit_all') 硬写进控制器：能堵洞，但把一个产品决策焊死在代码里，甲方改主意就要重新发版，且四个候选方案里没有「都同意」的安全子集，硬猜必然返工。走 config 表而不是纯 .env：VW 侧可能多实例部署，.env 要每台改且容易漂移，config 表是所有实例共享的同一份 MySQL，改一次全局一致。

修复前（实测输出）

用 audit_readonly 角色（全库只有 audit:read、audit:export 两个权限码，前端连栏目菜单都看不到）打 CMS 接口：

### [1] GET /api/channels  as audit_readonly (无任何 content 权限)
code=0 msg=操作成功 items=1

### [2] POST /api/channels  as audit_readonly
{"code": 0, "message": "创建成功", "data": {"id": 4}, "trace_id": "0b67b82e62b4484a"}

### [3] PUT /api/channels/1  改线上栏目 slug（SEO 影响）as audit_readonly
{"code": 0, "message": "更新成功", "data": null, "trace_id": "34a8ad8a0aab49ef"}
id	slug_en
1	zz-hijacked

### [4] PUT /api/channels/reorder  把线上 news 挂到假栏目下 as audit_readonly
{"code": 0, "message": "排序已保存", "data": {"ok": true, "updated": 1}, "trace_id": "1f2937b0c088d62a"}
id	parent_id	sort_order	slug_en
1	4	9	zz-hijacked
4	NULL	0	zz-pentest

### [5] DELETE /api/channels/4 as audit_readonly
{"code": 0, "message": "删除成功", "data": null, "trace_id": "d680d388786f1c9f"}

### 官网 /api/menu 受影响实证（整改前）—— 只读审计账号改掉了官网导航
{
    "success": true,
    "data": [
        {"id": 4, "name": "ZZ越权测试栏目", "slug": "zz-pentest", "href": "/zz-pentest", "sort_order": 0,
         "children": [{"id": 1, "name": "新闻中心", "slug": "news", "href": "/news", "sort_order": 9, "children": []}]}
    ]
}

修复后（实测输出）

同一账号、同一批请求（交付默认态 split，config 表无 channel.acl.* 行）：

  audit_readonly GET /api/channels -> code=6001 无权限操作栏目
  audit_readonly GET /api/channels/1 -> code=6001 无权限操作栏目
  audit_readonly POST   /api/channels -> code=6001 无权限操作栏目
  audit_readonly PUT    /api/channels/1 -> code=6001 无权限操作栏目
  audit_readonly PUT    /api/channels/reorder -> code=6001 无权限操作栏目
  audit_readonly DELETE /api/channels/1 -> code=6001 无权限操作栏目
（HTTP 400 + 业务码 6001；DB 中 channels 表零改动）

审计留痕（operation_logs，六次拒绝逐条落库，且记下了「要什么权限才够」）：
283	access_denied	6	audit_readonly	fail	6001	{"permission":"channel:write(content:edit_all)","path":"\/index.php\/api\/channels\/1","method":"DELETE"}
282	access_denied	6	audit_readonly	fail	6001	{"permission":"channel:reorder(content:edit_all)","path":"\/index.php\/api\/channels\/reorder","method":"PUT"}
281	access_denied	6	audit_readonly	fail	6001	{"permission":"channel:write(content:edit_all)","path":"\/index.php\/api\/channels\/1","method":"PUT"}
280	access_denied	6	audit_readonly	fail	6001	{"permission":"channel:write(content:edit_all)","path":"\/index.php\/api\/channels","method":"POST"}
279	access_denied	6	audit_readonly	fail	6001	{"permission":"channel:write(content:edit_all)","path":"\/index.php\/api\/channels","method":"POST"}
278	access_denied	6	audit_readonly	fail	6001	{"permission":"channel:read(content:create|content:edit|content:edit_all)","path":"\/index.php\/api\/channe

部署到 VW 服务器时的注意事项

1. 无单机本地状态依赖。策略读 config 表（所有实例共享同一 MySQL），优先级 config 表 > .env > PHP 配置文件。多实例（nginx+PHP-FPM 集群或多容器）只需改一次 config 表，全实例立即一致，不需要逐台改 .env，不需要重启、不需要 reload PHP-FPM。缓存只在单次请求内（Config 类的 static，请求结束即释放），不存在实例间脏读窗口，唯一延迟来源是 MySQL 主从复制。

1. 切换方案的标准运维动作（三选一，推荐第一种）：

INSERT INTO config (key,value,description,created_at,updated_at) VALUES ('channel.acl.policy','sys_admin_only','栏目管理鉴权方案',NOW(),NOW()) ON DUPLICATE KEY UPDATE value=VALUES(value), updated_at=NOW(); 单动作收紧：键 channel.acl.rules，值形如 {"reorder":{"permissions":[],"roles":["sys_admin"]}} 或改 .env：channelacl.policy = sys_admin_only（多实例需逐台改，不推荐） 或改 app/Config/ChannelAcl.php 的 $policy（需发版；若线上开了 opcache，改 PHP 文件必须 reload php-fpm 才生效，走 config 表则不必）。

1. 启用 channel:manage 这条路（可选，需要 DBA 配合执行一次）：

幂等 SQL 已完整写在 app/Config/ChannelAcl.php 文件头注释第六节，也等价于 \App\Database\Seeds\RolePermissionSeeder::ensureChannelManagePermission()（纯 INSERT、可反复执行）。 执行顺序必须是「先种权限码，再改 config 的 policy」；顺序反了不会出事——本实现会检测到权限码不存在并自动回落到 split，只在日志里报 error。 建议同步让前端把 admin-frontend/js/config/menu-permissions.js:7 与 js/router/index.js:36 的 requiresPermission 加上 'channel:manage'，否则只授 channel:manage、不授 content:* 的角色看不到栏目菜单入口。

1. 严禁在已上线环境执行 php spark db:seed App\Database\Seeds\RolePermissionSeeder —— 该 run() 会先 DELETE channel_role_permissions / role_permissions / permissions / roles 再重建，等于清空全部授权。已在该方法上加了【危险】注释，线上新增权限码请一律走 ensureChannelManagePermission() 或等价 SQL。

1. 性能：每个栏目请求新增最多 3 次轻量查询（config 两键 + permissions 全表 22 行）加 1 次用户权限查询，且同一请求内只查一次。若 VW 侧要求进一步压减，把 ChannelAcl 的 $allowDbOverride 设为 false，退化为纯文件配置（届时切换方案需发版）。

1. 配置基线锁定：等保配置管理若要求「策略不得运行时变更」，把 $allowDbOverride = false 即可，此时 config 表里的 channel.acl.* 一律被忽略，只认发版内容。

1. 观察到但不属于本任务：config 表原有的 auth.allow_concurrent_sessions（原 id=2）在本次会话期间被移除，不是本任务所为（本任务只 INSERT/DELETE 过 channel.acl.policy 与 channel.acl.rules 两行，均已清理）。同期还有并行代理创建的 sys_admin 账号 zz_sess_probe（users.id=7）残留，未动。上线前请并入总检查清单确认。

方案

一、定级建议：应定三级，文档写的「等保二级导向」偏低

结论：/Users/linhuasun/vwcorp-local/w2r.site/docs/project-introduction.md:25 写「系统设计遵循等保二级导向」，我认为定级偏低一档，建议按三级定级备案；若甲方坚持二级，最低限度也要「备案二级、建设对齐三级」。

定级依据是 GB/T 22240-2020《网络安全等级保护定级指南》的两个定级要素：受侵害的客体、对客体的侵害程度。

支持二级的论据（我实测确认成立，但不足以定二级）：

1. 不处理公民个人信息 —— 实证：官网前台 demo.w2r.site/frontend/src 下 <input> 元素 0 个，无表单、无留资、无线索采集；vgc.users 表字段仅 username / email / password_hash / role / is_active / 三个时间戳，是内部管理员账号，不是公民个人信息。这是二级论据里唯一站得住的一条。
2. 大概率不属于关键信息基础设施 —— CII 认定由行业主管部门按《关键信息基础设施安全保护条例》做，汽车制造虽属「重要行业和领域」，但对外宣传官网通常不进 CII 清单。

支持三级的论据（更重）：

1. 受侵害客体不止「法人合法权益」。大众汽车集团（中国）是在华合资体量最大的外资车企之一，官网是其唯一官方对外发布渠道。CMS 的核心风险就是「改内容」——首页/新闻被篡改后发布伪造的召回公告、安全声明或官方立场，会被媒体即时放大，可能引发消费者恐慌、经销商体系混乱、母公司股价波动。这已经越过「仅损害法人权益」，落到「损害社会秩序和公共利益」。
2. 侵害程度是「严重损害」而非「一般损害」。按定级矩阵：客体=社会秩序和公共利益 + 程度=一般损害 → 二级；+ 严重损害 → 三级。汽车行业头部品牌官网的内容篡改事件，其社会影响面难以论证为「一般」。
3. 行业实践：主机厂面向公众的门户/官网普遍按三级备案，这是专家评审会的默认预期。定二级需要额外举证，反而增加评审不通过的风险。
4. 系统自己的实现已经超过二级。Services/AuditAnomalyService.php 做了访问拒绝阈值告警和非工作时间查询频率告警——这是三级 8.1.5.2 审计管理 / 8.1.5.4 集中管控 才要求的能力，二级不要求。系统实际按三级思路建的，文档却写二级，这个不一致本身在评审时会被追问。

定二级 vs 三级的实际差异（成本在哪）： 定二级则 8.1.4.8 数据保密性、8.1.5.3 安全管理、8.1.5.4 集中管控 三组整体不进测评范围。其中 8.1.5.4 集中管控要求日志集中收集、安全设备集中监控、独立管理区域，需要采购 SIEM/日志审计平台，是二级三级之间最大的一笔预算差。8.1.4.8 数据保密性正好命中本系统当前最严重的缺陷（MFA 密钥明文存储）。也就是说，定二级会「掩盖」掉当前最高风险的那一项——这是我建议定三级的另一个理由：定级不该被用来规避已知缺陷。

最终定级不是技术侧能拍板的，须由甲方组织专家评审并经公安机关备案审核（见 decisions_needed 第 1 条）。

标准条款编号已核实：GB/T 22239-2019 第 7 章为第二级安全要求、第 8 章为第三级安全要求；8.1.4.1 身份鉴别 / 8.1.4.2 访问控制 / 8.1.4.3 安全审计 / 8.1.4.11 个人信息保护 编号经检索确认（检索时间 2026-08-11）。来源：https://www.cnblogs.com/hemukg/p/18817035 、https://www.ahdjbh.com/dengbaoceping/353.html 、https://safe.cafe/docs/djbh/19/ 、https://www.freebuf.com/articles/es/218259.html

---

二、控制项对照表

格式：条款号 名称 | 是否满足 | 实现在哪 | 差距 | 整改建议。文件路径均相对 /Users/linhuasun/vwcorp-local/w2r.site/backend/（前端相对 w2r.site/ 或 demo.w2r.site/⁠）。

A. 安全通信网络 8.1.2（二级 7.1.2）

8.1.2.1 网络架构 | 不适用于应用层 | — | 网络分区、带宽保障、关键线路与设备冗余属基础设施 | 甲方 IT 提供网络拓扑与冗余证明。

8.1.2.2 通信传输 | 不满足（应用层） | app/Config/App.php:19 baseURL='https://w2r.site/' 声明了 HTTPS | app/Config/App.php:160 forceGlobalSecureRequests=false⁠；app/Config/Cookie.php:57 secure=false（实测响应 Set-Cookie 无 Secure 属性）；响应头无 Strict-Transport-Security。TLS 若在 nginx 终结，应用层完全不设防，一次 http 回退就明文外泄 JWT 与 session id | 开 forcehttps + Cookie secure=true + HSTS；同时配 app/Config/App.php:183 $proxyIPs（当前为空数组）并让 nginx 传 X-Forwarded-Proto，否则会重定向死循环。

8.1.2.3 可信验证 | 不满足 | — | 无可信根、无启动度量 | 纯应用系统普遍拿不到分，走补偿措施 + 风险接受。

B. 安全区域边界 8.1.3（二级 7.1

修复前（实测输出）

本项是只读评估，「整改前」= 我实测到的当前不合规实证。以下输出原样贴。

═══ PROBE B6b — 8.1.4.4 d) 全站无 CSRF：跨站表单 POST 仅凭 session cookie 即写库 ═══
$ curl -s -b jar -X POST http://localhost:1977/api/dam/categories \
    -H 'Content-Type: application/x-www-form-urlencoded' \
    -H 'Origin: https://evil.example.com' -H 'Referer: https://evil.example.com/' \
    --data-urlencode 'name=ORACLE_CSRF_PROOF'
{
    "code": 0,
    "message": "创建成功",
    "data": {
        "id": "7",
        "name": "ORACLE_CSRF_PROOF",
        "access_level": "public",
        "created_by": "1",
        "created_at": {"date": "2026-08-11 21:59:43.000000",
--- DB 验证 ---
7	ORACLE_CSRF_PROOF	2026-08-11 21:59:43
--- 该请求被审计成了管理员本人（抗抵赖被破坏，8.1.4.3）---
229	1	dam	category_create	7	172.20.0.1	2026-08-11 21:59:43
（无 Bearer 头、无 CSRF token、Origin/Referer 均为攻击者域，请求依然通过鉴权与授权并落库）

═══ PROBE B2/B4 — 附带：500 错误外泄完整堆栈与服务器绝对路径（8.1.4.4）═══
{
    "title": "CodeIgniter\\Exceptions\\InvalidArgumentException",
    "code": 500,
    "message": "Field \"start_at\" is not nullable, but null was passed.",
    "file": "/www/wwwroot/w2r.site/backend/system/DataCaster/DataCaster.php",
    "line": 156,
    "trace": [ ...

═══ PROBE G — 8.1.4.1 b) / 8.1.4.10 b) 登出不吊销 JWT ═══
before logout: GET /api/users -> HTTP 200
logout -> HTTP 200
AFTER logout, SAME token: GET /api/users -> HTTP 200
{"code": 0, "message": "操作成功", "data": {"list": [{"id": "6", "username": "zz_sec_audit", ..

修复后（实测输出）

**本项是只读评估任务，按设计 oracle_after ≡ oracle_before —— 我没有改任何代码，因此上述每一条不合规在本报告出具后依然成立。** 这不是遗漏，是任务边界（任务书明确「本任务只做分析，不修改任何文件」）。

「整改后」在这里的正确含义是：确认评估过程本身没有破坏系统、没有留下残留。以下是验证输出。

═══ 系统完好性（评估未造成副作用）═══
$ curl -o /dev/null -w '%{http_code}' /api/auth/me   -H Bearer     ->  200
$ curl -o /dev/null -w '%{http_code}' /api/users     -H Bearer     ->  200
$ curl -o /dev/null -w '%{http_code}' /api/users     无凭证        ->  401
$ curl -o /dev/null -w '%{http_code}' http://localhost:1978/       ->  200  size=406

═══ 取证数据已清理，零残留 ═══
$ curl -X DELETE /api/dam/categories/7 -H Bearer
{"code": 0, "message": "删除成功"}
SELECT COUNT(*) FROM vgc.asset_categories WHERE name LIKE 'ORACLE%';   ->  0
SELECT COUNT(*) FROM vgc.search_hotwords  WHERE keyword LIKE 'ORACLE%';->  0
SELECT COUNT(*) FROM vgc.channels         WHERE name LIKE 'ZZ_MLPS%';  ->  0
（创建与删除两笔均正常留痕：operation_logs id 229 category_create / id 230 category_delete）

═══ 工作副本未被本会话写入 ═══
$ stat -f '%Sm %N' app/Config/Filters.php     ->  2026-05-21 14:12:14
$ stat -f '%Sm %N' app/Config/Security.php    ->  2026-02-08 20:32:20
（这两个文件在我全程读取期间 mtime 未变，与我 files_changed=[] 一致）

═══ 并行整改进度的旁证（供协调用，非我方改动）═══
$ stat -f '%Sm %N' app/Filters/AuthFilter.php    ->  2026-08-11 22:08:06
$ stat -f '%Sm %N' app/Services/AuthService.php  ->  2026-08-11 22:10:16
$ ls app/Config/ChannelAcl.php                   ->  存在（新增文件）
说明：我的全部取证完成于 21:55–22:02，晚于取证时间的这几次改动是并行代理的会话撤

部署到 VW 服务器时的注意事项

部署到 VW 官方服务器（nginx + PHP-FPM 或容器化，且很可能多实例）时的注意事项。多实例相关的前四条是硬阻塞，不解决会出现随机性故障，而且会让若干等保控制项名存实亡。

1. Session 用文件存储，多实例必坏（硬阻塞） app/Config/Session.php:24 driver=FileHandler⁠、:64 savePath=WRITEPATH.'session'⁠，实测本地已堆积 38 个文件。多实例/多容器下会话不共享，三条链路会随机失败：二次确认（app/Services/ConfirmTokenService.php:30 把确认码存 PHP session）、受限资产交付（app/Controllers/AssetDeliveryController.php:52 先读 session）、AuthFilter 的 session 回退（app/Filters/AuthFilter.php:31-35⁠）。必须换 Redis 或 DB session。nginx sticky session 是下策——滚动发布时仍会掉，而且掩盖问题。

2. Cache 用文件存储，登录限流形同虚设（硬阻塞，且直接影响 8.1.4.1 b） app/Config/Cache.php:24 handler='file'⁠。app/Services/LoginThrottleService.php 的失败计数落本地磁盘 → N 个实例意味着攻击者拿到 5×N 次尝试，且锁定只锁住其中一个实例。验证码同理（缓存文件 writable/cache/captcha_*⁠）。测评时「登录失败处理」这一项会因此判不符合。必须换 Redis。

3. 加密密钥是 MFA 整改的硬依赖，必须写进部署清单（需运维配合） app/Config/Encryption.php:24 key=''⁠，且 .env 里没有 encryption.key（实测 grep 计数 0）。MFA 加密整改必然要一把密钥，部署时需要：生成 32 字节随机密钥 → 以环境变量注入 → 保证所有实例一致 → 纳入甲方密钥管理流程（KMS 或密码机）→ 明确轮换周期。特别注意轮换方案：轮换时必须能同时用新旧钥解密以重加密存量 mfa_secrets⁠，否则一轮换全员 MFA 失效、且没有恢复路径。这是整个整改里唯一必须运维强配合、且做错不可逆的一项。

4. JWT_SECRET 的注入方式 app/Config/Jwt.php:54 已支持从 $_ENV['JWT_SECRET'] 读取（实测 .env 里有），但 :58-68 有一段「自己 file() 读 .env 文本」的兜底——容器化下这段可能读不到，而且它把密钥读取从框架配置里旁路了。部署时请确保走真正的环境变量，不要依赖这段兜底。所有实例的 secret 必须一致；轮换会一次性踢掉全部在线用户，需与甲方约定窗口。

5. 反向代理下的真实 IP（影响审计准确性与限流有效性） app/Config/App.php:183 $proxyIPs=[]⁠。nginx 前置时 getIPAddress() 拿到的是负载均衡器 IP，审计日志的 ip 字段与限流的 key 全部失真——8.1.4.3 b) 审计记录要求「用户」可追溯，8.1.4.1 b) 限流要求按来源限制，两项都会被打掉。本地实测审计日志 IP 全是 172.20.0.1（Docker 网关），就是这个问题的预演。部署时必须配 $proxyIPs 并让 nginx 传 X-Forwarded-For / X-Forwarded-Proto⁠。

6. HTTPS 强制的正确打开方式 app/Config/App.php:160 forceGlobalSecureRequests=false⁠。若 TLS 在 nginx 终结、应用只收 http，直接开 forcehttps 会导致重定向死循环。正确顺序是：先配好第 5 条的 $proxyIPs 与 X-Forwarded-Proto⁠，再开 forcehttps，同时把 app/Config/Cookie.php:57 secure 改 true，并在 nginx 加 HSTS 响应头。

7. nginx / PHP-FPM 层必须做的加固

• 上传目录禁止 PHP 执行。DAM 白名单允许 zip/doc/docx（app/Config/Dam.php:39⁠），一旦白名单被绕过而目录又能跑 PHP，就是 RCE。这条是 8.1.4.5

未交付清单（穷举）

排查范围：/Volumes/ProjectsAPFS/VWCORP/ 下 w2r.site.zip（241 MB）与 demo.w2r.site.zip（101 MB）解包后的全部内容，外加两份压缩包本身的条目清单（unzip -l⁠）。路径一律相对交付根目录。「事实」= 我在文件里直接查到；「推断」= 我从证据推出、需要人确认。

结论先说：这份交付可以读懂代码，但不能重建系统。 缺的不是零星文件，而是三整类东西——(1) 全部业务数据与媒体实体，(2) 全部部署与环境配置，(3) 官网前台 demo.w2r.site 从 2026-04 到 2026-06 的三个月增量代码。第 (3) 项此前未被识别，是本次排查最重的发现。

---

A. 数据与运行时资产（最致命，缺了系统起不来）

---

B. 版本控制：三个仓库都不完整，一个站点根本没进仓库

---

C. .cursor 规范与知识体系（文档第四章有完整清单，实交付近乎为零）

---

D. 文档：workspace 一级目录整个缺席，且交付内文档自相矛盾

---

E. Python / PHP 工具脚本：README 里写了 12 个，实交付 12 个但对不上

w2r.site/scripts/ 实际有 12 个 .py⁠，但其中 5 个 README 里描述过的关键脚本不存在，另有 3 个存在但 README 没写。

---

F. 部署与环境：这套代码不知道该怎么上线

---

G. 测试与 CI/CD：等同于没有

---

H. 官网前台 demo.w2r.site 的三个月代码代差（本次最重发现）

交付的 demo.w2r.site 源码时间停在 2026-03-23（backend/public/api.php⁠、frontend/src/router/index.js⁠、frontend/README.md 皆为该日）。而 CMS 的 docs/changelog.md 在 4–6 月记录了大量已在 demo 上验证通过的功能。这些功能在交付的 demo 代码里一律不存在。

---

I. CMS 后台：文档承诺的能力在前端没有入口

后端接口大多存在（backend/app/Config/Routes.php 共 172 行、约 90 条路由），但管理端只交付了 13 个页面（admin-frontend/js/router/index.js⁠：dashboard / channel / news / content / faq / media / asset-categories / audit / users / roles / settings + login + mfa-enroll）。

---

J. 第三站点与外部资产

---

附：本次排查中被证伪的几个直觉

• demo.w2r.site/frontend/src/assets/video/home.mp4 在（20 MB，2026-03-23），前端构建不会因缺视频而失败。此前基于 ls -R 截断的判断有误，已更正。
• 数据库结构可重建⁠：51 个迁移 + RolePermissionSeeder.php（含 7 个角色定义，与 project-introduction.md:179-187 完全一致）+ CreateSuperAdmin CLI 命令，足以起一个空库。缺的是数据不是结构⁠。
• CSP 确实开着⁠：backend/app/Config/App.php:201 CSPEnabled = true⁠，ContentSecurityPolicy.php 的 scriptSrc / styleSrc / fontSrc 均为 'self'⁠。acceptance-checklist.md:66-67 这两项在配置层面是达标的。
• docs/ 的图片与图表齐全⁠：docs/images/ 5 张流程图、docs/context-diagram.png⁠、development-diagram.png⁠、docs/cms/diagrams/ 2 个 .mmd 全部在位，scripts/gen_diagram_images.py 也在。

服务器部署：生产环境与测试环境

0. 一句话结论

交付物里不存在「生产」与「测试」两套环境的区分——只有一台机器（47.242.46.253）上并排的两个站点目录，两站的 CI_ENVIRONMENT 都是 development⁠，共用同一台 MySQL、同一个库名 vgc⁠、同一份 DAM 媒体目录（靠符号链接跨站点直连）。设计文档里写满了 dev / test / staging / prod 四环境与隔离要求，代码与配置里一条也没落地。 真正对外的生产域名 vgc.digirepub.com（139.224.64.38）没有任何代码、配置或凭据交付，其归属与上线状态在仓库中无从判断。

---

1. 设计上打算怎么分环境（文档侧）

注意 docs/project-introduction.md:25 与 docs/cms/requirements.md:162 的措辞是「等保二级导向⁠」——是设计参照，不是已通过测评的结论。多环境隔离恰恰是等保测评会查的项，现状不满足。

---

2. 环境判定：交付的 .env 是 development，不是 production

这是本议题最硬的一条事实。

ENVIRONMENT 常量在代码里分叉 11 处，development 与 production 的行为差异：

这不是纸面推断。 demo.w2r.site/backend/writable/debugbar/ 里有 425 个 debugbar_*.json⁠，最新一个 debugbar_1774268703.139049.json 对应 2026 年 3 月下旬——说明这台对外可访问的机器确实以 debug 模式接过真实请求⁠。同目录 writable/logs/log-2026-02-28.log:1 起的堆栈把 /www/wwwroot/demo.w2r.site/backend/vendor/... 绝对路径写进了日志，同样的信息在 display_errors=1 下会直接打到浏览器。

w2r.site/backend/.env:37 的 JWT_SECRET 值本身带着 do-not-use-in-production 字样（值见 w2r.site/backend/.env:37⁠），.env:18 还明文躺着 Sitecore 生产 CM 的管理员口令（见 w2r.site/backend/.env:17-18⁠），.env:61 有 Figma PAT（见该行）。这三条凭据在交付包里是明文，必须按已泄露处理并轮换。

---

3. 从 .htaccess / .user.ini 还原出的目录结构与改写规则

Apache 语法的改写规则一共 6 份，还原出的假设结构：

3.1 w2r.site（CMS）

DocumentRoot = /www/wwwroot/w2r.site          ← 站点根就是项目根
  .htaccess:13        ^(.*)$ → backend/public/$1     （非真实文件才改写，:9-11）
  .htaccess:6-7       已在 /backend/public/ 下的请求不再二次改写
  .user.ini:1         open_basedir=/www/wwwroot/w2r.site/:/tmp/
  backend/public/.htaccess:7   RewriteBase /
  backend/public/.htaccess:14-16  非文件非目录 → index.php/$1
  backend/public/.htaccess:18-19  透传 Authorization 头（JWT 依赖）

把 CI4 项目根直接当站点根、靠 .htaccess 二次改写进 backend/public⁠，是 CI4 官方明确反对的做法（w2r.site/backend/README.md:22-24 原文就在批评这一点）。后果：.htaccess 一旦失效（换 nginx、AllowOverride 非 All），app/⁠、.env⁠、vendor/⁠、writable/ 全部裸露在 HTTP 根下。

3.2 demo.w2r.site（官网前台）

DocumentRoot = /www/wwwroot/demo.w2r.site/frontend/dist   ← 推断，见下
  demo.w2r.site/.htaccess:1        内容只有一个空格（等于空）→ 站点根不是 doc root
  demo.w2r.site/index.html:31-35   宝塔默认页（「面板系统后台 > FTP」），未被覆盖
  frontend/dist/.htaccess:19       SPA fallback → /index.html
  frontend/dist/.htaccess:16       /asset/{id} → /api/asset/{id}  302
  frontend/dist/.htaccess:2-9      mp4/webm/字体 Cache-Control immutable 1 年
  backend/public/.htaccess:15      RewriteBase /api/      ← CI4 挂在 /api 子路径
  backend/public/.htaccess:29      ^(hello|)$ → api.php
  backend/public/.user.ini:1       opcache.enable=0
  .user.ini:1                      open_basedir=/www/wwwroot/demo.w2r.site/:/tmp/
  shared/dam-writable              符号链接 → /www/wwwroot/w2r.site/backend/writable

backend/public/.htaccess:23-25 有一条 www. → 非 www 的 301，且目标写死 http://（非 HTTPS）。站点已签发证书（见 §4），这条规则会把 www 访问降级到明文 http 再跳。

3.3 open_basedir 与符号链接冲突（需服务器核实）

demo.w2r.site/.user.ini:1 把 demo 的 PHP 文件访问限制在 /www/wwwroot/demo.w2r.site/ 与 /tmp/⁠。但 demo.w2r.site/backend/public/demo_asset_delivery.inc.php:68-69 用 realpath() 解析 shared/dam-writable⁠，真实路径是 /www/wwwroot/w2r.site/backend/writable⁠，落在 open_basedir 之外⁠。open_basedir 按解析后的真实路径判定，理论上所有 DAM 图片交付都应被拒。推断⁠：线上要么在宝塔站点配置或 php-fpm pool 里额外放行了 w2r.site 目录，要么这份 .user.ini 与线上不一致。这是必须在服务器上实测的一条。

---

4. 生产环境形态的证据（全部为直接证据）

4.1 一个必须解释的矛盾

demo.w2r.site/backend/README.md:7 说这台机器的 PHP 没有 mbstring、禁用了 putenv⁠；而 w2r.site/backend/composer.json:13-17 要求 php ^8.2 + ext-intl + ext-mbstring + ext-mysqli + ext-imagick⁠，w2r.site/backend/.env 又必须靠 CI4 DotEnv（依赖 putenv 或 $_ENV 写入）加载。推断⁠：宝塔按站点绑定不同 PHP 版本/池，w2r.site 用的是装齐扩展的那一个，demo.w2r.site 用的是另一个。demo 的 backend/public/index.php:6-9 也确实额外加载了 symfony/polyfill-mbstring 兜底。这条必须向交付方确认——它决定新环境要装几套 PHP。

---

5. 配置晋级机制（ConfigPromotionService 与 /api/config/export|import⁠）

5.1 实际做了什么

• 路由：w2r.site/backend/app/Config/Routes.php:97-98⁠，只有 GET config/export 与 POST config/import⁠，均挂 auth filter；权限点在控制器里判，ConfigPromotionController.php:26（config:export⁠）与 :68（config:import⁠）。
• 支持类型：ConfigPromotionService.php:13 → workflow⁠、seo⁠、rbac⁠、channel_auth⁠、channels⁠。
• 导出实现：:38-45 分发；:110-131 rbac 直连 roles / permissions / role_permissions 三表；:133-144 channel_auth 连 channel_role_permissions⁠；:146-149 channels 全表 findAll()⁠。
• 导入实现：:85-92⁠，其中 rbac 直接拒绝（:88「请使用专用脚本或分步导入 channel_auth」），channels 直接拒绝（:90「暂未开放」）。真正能导入的只有 workflow 与 seo 两类，外加 channel_auth⁠。

5.2 与文档不符之处

5.3 用它搬配置的风险

1. 覆盖式写入，无回滚。 ConfigPromotionService.php:209 的 replaceForChannel() 是整栏目授权替换；一次错误的 channel_auth 导入会把该栏目的全部角色权限规则清空重建，且没有备份可回退（见上表）。
2. dry_run 给假的安全感。 演练返回「校验通过」不代表真实导入会通过，:72-83 根本没跑到 importXxx⁠。
3. 没有环境归属标记。 导出体（:47-56⁠）里只有 type / version / exported_at⁠，没有源环境标识。目前两站共库（§6），从哪导的、往哪导的，事后只能靠审计日志的 actor 推断（审计写在 ConfigPromotionController.php:40-57 与 :109-122⁠）。
4. 它搬不动真正难搬的东西。 内容模型、模板、组件白名单、搜索热词/置顶都不在支持类型里；数据库结构靠 51 个迁移（w2r.site/backend/app/Database/Migrations/⁠，ls | wc -l = 51）+ 1 个 seeder（Seeds/RolePermissionSeeder.php⁠）。全库无 .sql 导出（find . -name "*.sql" 无结果），初始数据只能靠迁移与 seeder 重建。

---

6. 「测试环境」判断：现在没有，一台机器上是两个站点而不是两套环境

6.1 证据

docs/cms/requirements.md:87-89 要求数据库、上传目录、缓存三项按环境隔离——现状是三项全部共享。demo.w2r.site 不是 w2r.site 的测试环境，它是同一套系统的官网前台。 在 CMS 后台改一条内容，官网立刻变；在官网上做压测，改的是 CMS 的同一批数据。

6.2 其他佐证

• 无 CI/CD 部署管线。 w2r.site/.gitlab-ci.yml 全文只 include 了 Security/SAST.gitlab-ci.yml 与 Security/Secret-Detection.gitlab-ci.yml（第 12-13、21-22 行），stages 只有 test 与 secret-detection⁠，没有 build、没有 deploy、没有 environment 定义⁠。部署只能是手工。
• 仓库边界不完整。 w2r.site/backend/.git/config:10 → gitlab.onedevops.vw.com.cn/c-sdxx/corporate-website/backend.git⁠；w2r.site/admin-frontend/.git/config:10 → .../frontend.git⁠；w2r.site/README.md:18 → .../corporate-website.git⁠。demo.w2r.site 整个目录没有 .git（find demo.w2r.site -name .git -type d 无结果）——官网前台不在版本控制里。
• .gitignore 把环境相关物全排除了。 w2r.site/.gitignore:5,7,11,12,13,14,15 排除 docs/⁠、scripts/⁠、writable/⁠、backend/.env⁠、backend/writable⁠、.htaccess⁠、.user.ini⁠。这解释了为什么服务器配置从来没进过仓库，也意味着没有任何一份「环境配置」是可版本化、可 diff、可回滚的⁠。
• 交付的构建产物比源码旧。 w2r.site/backend/public/AdM/index.html 的 mtime 是 2026-06-21 22:14，而 w2r.site/admin-frontend/js/ 下最新源文件是 2026-07-22 09:30——后台 SPA 打包产物落后源码约一个月⁠。demo.w2r.site/frontend/dist/ 是 2026-06-12 15:55，src/components/home/HeaderNav.vue 与 src/lib/nav/megaMenuState.js 是同日 16:00，落后 5 分钟⁠。（这是 zip 内保留的 mtime，为推断依据；上线前必须以重新构建为准，构建配置见 w2r.site/admin-frontend/vite.config.js:8（base: '/AdM/'⁠）、:11（outDir: ../backend/public/AdM⁠）与 package.json:8（build 后删除产物里的 index.php⁠、.htaccess⁠）。）
• 域名本身就是临时的。 w2r.site 于 2026-02-08 经阿里云万网注册、2027-02-08 到期；生产域名却是 vgc.digirepub.com（docs/project-introduction.md:44⁠）。而 w2r.site/backend/app/Config/App.php:19 把 baseURL 硬编码成 https://w2r.site/⁠，w2r.site/admin-frontend/js/utils/contentPreview.js:2 把 PUBLIC_SITE_ORIGIN 硬编码成 https://demo.w2r.site（会被打进 AdM 包），app/Services/SeoSchemaService.php:20 默认 base_url 是 https://w2r.site⁠，app/Commands/AuditAcceptance.php:26 硬编码 httpHost = 'w2r.site'⁠。换域名不是改配置，是改源码再重新构建。 后台设置页的占位符倒是写着 https://vgc.digirepub.com（admin-frontend/js/views/Settings.vue:206⁠），说明当初预期过要换。

6.3 接手方已经证明「能重建」

localdev/ 是接手流程自建的本机还原（localdev/.env:1 注明「由接手流程自动生成」），不属于交付物，但它是一份可用的环境规格：localdev/Dockerfile:3 用 php:8.2-apache⁠，:17-19 装 intl mbstring mysqli pdo_mysql zip gd exif + imagick⁠，:20 开 rewrite headers⁠，:24-29 放宽 upload_max_filesize / post_max_size / memory_limit / max_execution_time⁠；localdev/vhosts.conf:8 与 :27 分别把 w2r 站点根设为项目根、把 demo 站点根设为 frontend/dist 并 Alias /api 到 backend/public（:35⁠）。这套配置能把两站跑起来，可以直接作为测试环境的起点。

---

7. 生产与测试环境应有的差异表

---

8. crontab：应有条目

三个命令需要调度，都在 w2r.site/backend/app/Commands/ 下：

注意事项：

1. cd 到 backend/ 是必需的⁠，CleanApplicationLogs.php:15 的示例就是这么写的——CI4 的 spark 依赖工作目录定位 app/ 与 .env⁠。
2. cron 用的 PHP 二进制可能不是 php⁠。 宝塔多 PHP 版本共存时需写全路径（如 /www/server/php/82/bin/php⁠）。这条要在服务器上确认。
3. publish:run-schedule 每分钟跑，且它自己写审计（RunPublishSchedule.php:22-40⁠，operation = publish_schedule_run⁠，actor_id = 0⁠、actor_role = system⁠）。每分钟一条 = 每月约 43,200 条审计⁠，而 audit:cleanup 只按 6 个月保留期清理。上线前应确认 PublishService::runSchedule() 是否在无任务时也写审计——若是，operation_logs 表会被系统任务淹没，检索性能与等保「可检索」要求都受影响。
4. 仓库中无 crontab 文件、无 systemd timer、无宝塔计划任务导出。 这三条目前是否在线上跑着，无从判断——需要向交付方索取 crontab -l 与宝塔计划任务列表。定时发布是核心功能，若这条 cron 从未配置，那么所有定时发布/下线从上线起就是失效的。

---

9. 现状部署拓扑（含已知与未知）

[已知] 47.242.46.253  阿里云 · 宝塔面板 · nginx + php-fpm(多版本?) + MySQL(localhost)
  ├─ w2r.site                      CMS，CI_ENVIRONMENT=development
  │    站点根 = 项目根，.htaccess 改写进 backend/public
  │    /AdM/  → 管理后台 SPA（backend/public/AdM，产物落后源码约 1 个月）
  │    /api/* → CI4 Controllers
  │    writable/ ← DAM 与运行时目录，【整个未交付】
  ├─ demo.w2r.site                 官网前台，CI_ENVIRONMENT=development
  │    站点根 = frontend/dist（推断），/api → backend/public
  │    /api/* 有两套并行实现：api.php（裸 PHP）与 CI4 Controllers，
  │           谁生效取决于【未交付的 nginx 配置】
  │    shared/dam-writable ──符号链接──> w2r.site/backend/writable
  └─ MySQL: 库 vgc，两站同库同账号（w2r .env:26 / demo .env:12）

[未知] 139.224.64.38  vgc.digirepub.com —— docs/project-introduction.md:44 标为「生产域名」
                      【无代码、无配置、无凭据、无访问方式交付】
                      与 47.242.46.253 是什么关系（同步？替代？废弃？）无从判断

[存量] 211.151.111.91 volkswagengroupchina.com.cn —— 现有 Sitecore 官网，被替代对象
                      w2r.site/backend/.env:16-18 存着它的 CM 后台地址与管理员凭据
                      官网页脚备案号已硬编码：京ICP备08103718-21、京公网安备 11010502040869号
                      （demo.w2r.site/frontend/src/components/home/SiteFooter.vue:51-52）

未知清单（仓库中无此项）⁠：nginx 站点配置、php-fpm pool 配置、PHP 版本与 disable_functions 实际值、crontab、SSL 证书与续期方式、数据库全量导出、w2r.site/backend/writable/ 全部内容、备份策略、WAF/CDN、监控告警、vgc.digirepub.com 的一切。

---

10. 上线所需的服务器清单

---

11. 上线所需的配置项清单

必须逐项确认，不能沿用交付包里的值：

---

12. 搭一套独立测试/预发环境需要什么（最小可行）

1. 一台独立主机或独立容器⁠，不与生产共享 MySQL 实例与文件系统。localdev/docker-compose.yml + localdev/Dockerfile + localdev/vhosts.conf 已经是一份跑得通的规格，可直接改造为 staging。
2. 独立数据库⁠：跑 51 个迁移（app/Database/Migrations/⁠）+ RolePermissionSeeder⁠，得到空壳；业务数据必须向交付方索取全库导出⁠，否则无法验证任何真实行为。
3. 独立 DAM 目录⁠：不能复用生产的 writable/⁠，也不能用符号链接指回生产——这正是当前两站踩的坑。
4. .env 三份分离⁠：dev / staging / prod 各一份，密钥各不相同，且都不进仓库（.gitignore:12 已排除）。
5. 把域名与前台 origin 从源码里挖出来（见 §11 前三行），否则 staging 会指向生产前台。
6. 站点配置纳入版本控制⁠：nginx conf、php-fpm pool、crontab、.user.ini 都要有一份可 diff 的副本。当前 .gitignore:14-15 把 .htaccess 与 .user.ini 排除在外，这个决定要推翻。
7. 测试站 robots.txt 设 Disallow: /⁠，并加 HTTP Basic 或 IP 白名单——现在 demo.w2r.site 是公网可达且全站放行收录的。
8. 按 config-promotion.md:310-320 的 6 项清单做 staging 验收（审核流程、预览链接、定时发布、缓存刷新、搜索生效、审计可查）。但要先补上 §5.2 列的那些「文档有、代码无」的缺口，否则清单里的「配置晋级」一项无法真正演练。

0. 结论先行

这个项目在等保上的真实状态是：代码里做了一部分二级技术项，但等保这件事本身一步都没走。 仓库里没有定级报告、没有备案证明、没有测评报告、没有专家评审意见、没有任何一份安全管理制度文件。文档里那句「等保二级导向」（docs/project-introduction.md:25⁠、docs/cms/requirements.md:162⁠）是设计时的自我参照⁠，不是合规状态描述。

更要紧的是：即使按二级去测，当前代码状态也过不了⁠。已实测确认的越权缺口（内容与栏目写接口无权限码校验）和一条我在核查中新发现的问题（backend/.env:37 的 JWT 签名密钥是人类可读的开发占位串）都会直接命中「高风险项」，而 GB/T 28448-2019 的判定规则是：只要存在导致高等级安全风险的问题，整体结论就是「不符合」，分数再高也没用。

---

1. 现状定级：「导向」「已备案」「已测评」是三件事

1.1 仓库里等保二字出现在哪

全仓（排除 vendor/⁠、node_modules/⁠）检索「等保 / 等级保护」，只有 7 处：

仓库中无此项⁠：定级报告、专家评审意见、《信息系统安全等级保护备案证明》、等级测评报告、差距分析报告、任何一份安全管理制度或应急预案。

1.2 三个状态的区别（这一段请原样转给甲方）

• 「等保二级导向」= 开发时拿二级的技术条款当参照物写代码。 没有第三方确认，没有行政备案，法律上不产生任何合规效力。当前项目就在这一档。
• 「已定级备案」= 行政动作。 运营使用单位自主定级、编制定级报告，报属地公安机关网安部门备案，拿到《备案证明》。依据《信息安全等级保护管理办法》（公通字〔2007〕43 号）第十五条，二级及以上系统应在安全保护等级确定后 30 日内到设区的市级以上公安机关备案。备案证明是一张纸，不代表系统安全。
• 「已测评」= 技术动作。 由公安部认可资质的第三方测评机构按 GB/T 28448-2019 现场测评，出具《等级测评报告》，再报公安备案。这才是「通过等保」的通俗含义。

三者是串行的：没定级就不能备案，没备案通常测评机构不接单，没测评报告就没有「通过」可言。

1.3 实际应该定几级

先说法规硬性要求。 新修订的《网络安全法》已于 2026 年 1 月 1 日施行（2025 年 10 月 28 日第十四届全国人大常委会第十八次会议修正）。等级保护义务条款由原第二十一条调整为第二十三条⁠，其中明确「采取监测、记录网络运行状态、网络安全事件的技术措施，并按照规定留存相关的网络日志不少于六个月」；对应罚则由原第五十九条调整为第六十一条⁠，罚款上限由 50 万元提至 100 万元，严重情形 50 万—200 万元。交接文档里凡引用「网络安全法第二十一条 / 第五十九条」的表述都已过时，必须改。 另外，《网络安全等级保护条例》至今仍是 2018 年征求意见稿⁠，已列入国务院 2025 年立法预备项目，尚未正式发布——所以现阶段行政依据仍是 43 号文加各省公安实施口径。

再说定级本身。 按 GB/T 22240-2020《定级指南》，定级看两个要素：受侵害的客体（国家安全 / 社会秩序、公共利益 / 公民法人合法权益）与侵害程度。我从代码里能查到的事实：

我的判断（这是推断，不是查到的事实）⁠：

• 二级是可以论证的下限⁠，理由是不持有公众个人信息、无交易、无大规模用户数据。
• 三级是更稳妥、也更可能被属地公安认可的选择⁠，理由是：知名跨国集团在华官方门户，一旦被挂马、篡改、植入不良信息，社会影响面远超一般企业站；实务中网安部门对「知名企业面向公众的门户网站」倾向按三级要求。
• 这条不能由交付方单方面拍板。 定级的法定主体是运营使用单位（甲方），需甲方信息安全 / 法务牵头，组织 3—5 名专家评审出定级报告，并与属地公安网安支队沟通确认。交接文档应把它列为 open question 而不是给答案。

二级与三级的代价差是数量级的⁠，甲方必须知道再决策：

---

2. 代码实际实现了哪些等保要求（逐条对照）

方法与免责说明⁠：GB/T 22239-2019 的全文我未能在线取回（openstd.samr.gov.cn 全文公开页与广西公安厅镜像均取回失败），下表的条款分类与二级 / 三级差异按该标准的通行结构给出，逐字原文与精确小节号需在测评前以正式标准文本核对⁠。这是我的整理，不是标准原文引用。代码列全部是我逐文件读出来的事实。

2.1 安全计算环境（应用层，代码能覆盖的部分）

2.2 其他技术层面（安全物理环境 / 通信网络 / 区域边界 / 安全管理中心）

全部无交付证据。 这四类基本不由应用代码承担，靠机房、云上安全产品和网络设备。当前唯一相关线索是：生产疑似 nginx（backend/public/404.html 是 nginx 默认错误页，backend/public/index.html 是宝塔面板页），但改写规则写在 Apache 语法的 .htaccess⁠，真实站点配置未交付⁠。测评第一天就会要 nginx 配置、防火墙策略、WAF 规则，这些现在一份都没有。

一个正面项：CSP 已启用且非 report-only（Config/App.php:201 CSPEnabled = true⁠，配置见 docs/cms/security-model.md:390-432⁠）。这不是等保条款，但在渗透测试环节是加分项。

另一个正面项：security-scan-results/security-scan-report-20260125_011114.json 记录了 2026-01-25 的一次依赖扫描，npm 与 composer 均 0 漏洞。但这是 SCA（成分分析），不是漏洞扫描，更不是渗透测试⁠，测评不认这份报告。

2.3 管理层面（安全管理制度 / 机构 / 人员 / 建设 / 运维）

全部缺失，一份文件都没有。 详见第 4 节清单。这一块在测评打分里权重不低，而且是最容易被低估的部分⁠——三级测评的管理类要求约 30 余项制度文件，且每项都要「有制度、有执行、有记录、可核查」的证据闭环，不是把文档写出来就算数。

---

3. 已知缺陷逐条对应等保条款与测评判定

判定口径说明：GB/T 28448-2019 的整体结论分「符合 / 基本符合 / 不符合」。只要存在会导致高等级安全风险的问题，结论就是「不符合」⁠，与综合得分无关。下表「测评判定」列是我按该规则的推断。

---

4. 要真正通过测评还缺什么

4.1 代码层面能做的（交付方 / 接手团队可自己完成，不花钱）

按修复优先级排序，全部是应用代码改动：

1. backend/.env:37 换成 openssl rand -base64 32 生成的强密钥；:5 改 production⁠；旧密钥签发的 token 全部作废。
2. ContentController / ChannelController 按 security-model.md:44-67 补全 requirePermission 调用，参照 DamController 的写法。补完跑一遍 php spark 下已有的 VerifyRolePermission 命令（app/Commands/VerifyRolePermission.php⁠）验证。
3. AuthFilter 增加 user_sessions.revoked_at 校验（可加短 TTL 缓存避免每请求查库），让登出、并发登录控制、超时退出真正生效。
4. 关闭 JwtService::getTokenFromRequest 的 query 与 cookie 兜底（JwtService.php:189-199⁠），同步改 security-model.md:358-363⁠。
5. MFA 种子与备用码改用 CI4 Encryption 服务真加密；备用码改成加盐哈希存储、一次性、并计入节流；AuthService.php:110 的假注释删掉。
6. mfaVerify 接入 LoginThrottleService⁠，并改为按「账户 + IP」双维度计数。
7. 密码过期改服务端强制：过期时只发放仅能访问 change-password 的受限 token。
8. 增加账户级锁定字段与逻辑（连续失败 N 次锁账户，需管理员解锁；解锁动作要审计，audit-logging.md 里已经预留了 user_lock / user_unlock operation）。
9. 删除 backend/public/test-putenv.php⁠、groupui-showcase.html⁠。
10. forceGlobalSecureRequests = true⁠、Cookie::$secure = true⁠、samesite = 'Strict'⁠、regenerateDestroy = true⁠、Session::$expiration 与文档对齐。
11. 恢复 Filters.php 里的 secureheaders⁠；CSRF 视最终 token 传递方案决定是否需要。
12. CleanAuditLogs 默认保留期由 6 个月改 12 个月，并把 crontab 配置写进部署文档。
13. 把 security-model.md⁠、logging-system-design.md 里所有「实现建议」「推荐」的措辞逐条判定：要么落地，要么明确标注为未实施。 测评员按文档验证，文档写了没做比没写还糟。

4.2 必须走流程 / 买服务的（代码解决不了）

A. 行政与资质

• 定级报告编制 + 3—5 名专家评审（甲方组织）
• 属地公安网安部门备案，取得《备案证明》
• 选择公安部认可资质的测评机构（可在公安部「等级测评机构推荐目录」查属地机构）
• 若定三级：商用密码应用安全性评估（密评）⁠，且须在投入运行前完成，运行后每年一次并报市级密码管理部门备案

B. 安全管理制度体系（三级约 30 余项；二级可精简但不能没有）

加粗的几项与本项目现状直接冲突，是最先要写的。

C. 安全设备与服务

云上部署可用云厂商对应产品（阿里云云安全中心 / WAF / SLS + OSS 日志归档 / 堡垒机）打包解决，通常比自建便宜。注意本项目当前是宝塔面板 + 单机部署（backend/.user.ini 显示 open_basedir=/www/wwwroot/w2r.site/⁠，security-scan-report 里项目路径为 /www/wwwroot/vgc⁠），这个形态离等保要求的架构差距很大。

D. 运维与管理动作

• 备份策略落地 + 恢复演练记录（当前完全空白⁠）
• 日志集中采集（应用日志、nginx access log、数据库审计日志、安全设备日志统一收口）
• 审计日志防篡改：DB 写账号剥离 UPDATE / DELETE 权限，清理任务用独立账号
• 服务器时钟同步（NTP）——审计追溯的前提，测评必查
• 漏洞扫描 + 渗透测试报告（现有的 security-scan-results/ 是依赖成分分析，不能当漏扫报告用⁠）
• 安全事件应急演练记录
• 三台服务器的边界与职责界定：47.242.46.253（阿里云，同机跑 w2r.site 与 demo.w2r.site）、139.224.64.38（vgc.digirepub.com⁠，docs/project-introduction.md:44 标为「生产域名」但无任何代码交付⁠）、211.151.111.91（现有 Sitecore 官网）。定级对象边界不清就没法测评⁠，这是第一步要解决的

---

5. 时间与流程

整体周期：顺利情况 3—6 个月；本项目我判断按 6—9 个月规划更现实。 理由：第 4.1 节 13 项代码整改按现有代码量（backend 27,252 行 PHP）估约 3—5 人周；管理制度体系从零起步，光写文档 + 走内部审批就是 1—2 个月；安全设备采购与上线还要过甲方采购流程。这三条可以并行，但都卡在「谁来负责」上——而现在没有任何一方被指定为等保责任人⁠。

复评⁠：二级通常每两年一次（行业惯例），三级每年一次（43 号文第十四条，法定）。系统发生重大变更（架构调整、上云迁移、版本大升级）须重新测评，原报告对新系统不再适用⁠——这一条对本项目尤其重要，因为它本身就是要替代 211.151.111.91 上的 Sitecore 官网，切换本身就是重大变更。

---

6. 「代码能做的」与「必须走流程 / 买服务的」分界

一句话给甲方：代码这边的问题清单是明确的、可以照单修的；但等保能不能过，主要不取决于代码。

---

7. 我查到的 vs 我推断的（请勿混用）

查到的事实（均有文件行号）：仓库中等保相关文本只有 7 处；无定级 / 备案 / 测评任何材料；第 2 节表格里「代码是否实现」列全部来自逐文件阅读；第 3 节 3.1—3.7 已复现，3.8—3.10 是我本次核查新发现；security-scan-results/ 是 2026-01-25 的依赖成分扫描，非漏扫。

推断（无直接证据，供讨论）：应该定三级更稳妥；备份码是 MFA 爆破的真实入口；测评判定列的「不符合」结论；6—9 个月周期估计；工作量 25/75 分配。

引用的外部信息与检索时间（全部检索于 2026-08-11）：《网络安全法》2025 年修订版条文与施行日期来自中央网信办官网；43 号文条款来自多个政府与高校镜像；GB/T 28448-2019 结论判定规则、GB/T 22240-2020 定级要素来自公开解读；费用、周期、安全设备清单、制度清单来自测评 / 咨询机构的商业页面，属行业惯例参考，不是法规硬性要求，签合同前须以属地公安与测评机构口径为准⁠。

来源：

• 中华人民共和国网络安全法（2025 年修正）— 中央网信办
• 《网络安全法》首次修订全面解读 — 安全内参
• 信息安全等级保护管理办法（公通字〔2007〕43 号）— 西藏自治区公安厅
• GB/T 22240-2020 定级指南 — 国家标准全文公开
• GB/T 28448-2019 测评要求 — 国家标准全文公开
• 等保 2.0 基本要求框架 GB/T 22239-2019 解读 — 启明星辰
• 浅谈商用密码应用安全性评估（密评）— 安全内参
• 国务院 2025 年预备制定网络安全等级保护条例 — 安全内参
• 等保 2.0 完整科普：8 项国标 + 6 步流程 + 硬件清单 — 新亿诚（商业页面）
• 等保三级必备安全管理制度清单 — 国源天顺（商业页面）
• 等保测评多少钱：二级 / 三级费用对照（商业页面）

需要购买的认证、授权与订阅

全部论断标注了 仓库相对路径:行号⁠，或写明「仓库中无此项」。联网核实的部分标注了来源与检索时间（统一为 2026-08-11⁠）。「事实」与「推断」分开写。区分「法规硬性要求」与「行业惯例」。

---

0. 一句话结论

这个项目在「买什么」这件事上最大的问题不是花多少钱，而是交付给你的服务器在香港，而页脚硬编码的是一个内地备案号⁠。这两件事在合规上互斥。在决定服务器落在哪一侧之前，备案、等保、密评、云资源四项的预算全部是空的。此外交付包里混进了两套需要授权的字体（VW 定制 The Group + Monotype 蒙纳翔鹤黑），而真正的中文字体栈是空的。第三方开源组件这一项反而是全项目最干净的：零 GPL / AGPL / LGPL⁠。

---

1. 前提：交付的那台机器在境外（这一条决定其余所有条）

事实⁠：47.242.0.0/16 整段在 ARIN 登记为 ALIBABA CLOUD - HK（地址：香港铜锣湾勿地臣街 1 号时代广场一座 31 楼）。这是境外节点，不是内地节点。

这意味着（来源：阿里云帮助中心「ICP 备案前的服务器及接入信息确认排查」「不同场景下 ICP 备案的常见问题」，检索 2026-08-11）：

• 域名只解析到非中国内地服务器 → 不需要工信部 ICP 备案（法规硬性口径：备案义务跟服务器所在地绑定，不跟域名注册商绑定）。
• 但反过来，拿不到 ICP 备案号就办不了公安联网备案⁠——公安联网备案以「已取得工信部备案号」为前置条件（华为云《网站备案 用户指南》、腾讯云《公安联网备案流程指引》，检索 2026-08-11）。
• 所以 demo.w2r.site/frontend/src/components/home/SiteFooter.vue:51-52 上那行 '© Volkswagen Group China 2026 BJ ICP 08103718 -21 京公网安备 11010502040869号'⁠，在当前部署形态下是无效展示⁠：号不是这个域名的，机器也不在能挂这个号的地方。

推断⁠：47.242 这台是乙方自建的开发演示机（域名 w2r.site 2026-02-08 才注册，见 localdev/report/shell.html:312⁠），选香港大概率是为了省掉备案流程好快速上线 demo。这个便利在正式上线时必须还回去。

---

2. 备案类

2.1 这两个号是谁的

事实（WebFetch https://www.volkswagengroupchina.com.cn/ 页脚，检索 2026-08-11）：现网 Sitecore 官网页脚为「京ICP备08103718号-21⁠」「京公网安备 11010502040869号⁠」——与 SiteFooter.vue:52 里的字符串完全同源。

结论：

• 主体（大众汽车集团中国相关北京主体）已经持有 京ICP备08103718号 这个主体备案，-21 是它名下第 21 个网站的序号。同一主体号下还有 -17 用于 vw.com.cn（检索所得）。
• 备案是「主体 + 域名 + 接入商」三元组⁠。-21 绑的是 volkswagengroupchina.com.cn⁠。新域名（w2r.site / demo.w2r.site / vgc.digirepub.com）要用，必须在同一主体下新增网站备案⁠，会拿到 -22⁠、-23 这样的新序号，不能直接套用 -21⁠。
• 公安联网备案同理：11010502040869 绑的是现网站点，新站点上线后 30 日内要单独提交公安联网备案（法规硬性要求）。

2.2 现在这行页脚有三个具体缺陷

1. 写法不规范：BJ ICP 08103718 -21 不是「京ICP备08103718号-21」的法定写法。
2. 没有链接⁠。备案号需在首页底部标明并链接到 beian.miit.gov.cn⁠；公安备案号需带警徽图标并链接到全国互联网安全管理服务平台（行业通行做法，各接入商备案指引一致要求）。当前是纯文本常量，无 <a>⁠。
3. 硬编码在前端源码里，改一次要重新构建发版，不走 CMS 配置。

2.3 费用

备案本身不收费（阿里云帮助中心明示，检索 2026-08-11）。花钱的是前置条件：申请免费备案服务码要求 ECS 满足「中国内地地域 + 包年包月（含自动续费）≥ 3 个月 + 已分配公网 IP」。也就是说，备案的真实成本 = 你必须先买一台内地 ECS⁠。

---

3. 域名

关键发现⁠：DIGIREPUB（数字共和）是上海大合数码科技有限公司旗下的数字营销代理商品牌（检索 2026-08-11，数英网企业页）。也就是说 docs/project-introduction.md:44 里写的那个「生产域名」vgc.digirepub.com⁠，跑在乙方（代理商）自己的域名下，不是大众的域名⁠。

后果很直接：

• 如果真的按文档上线在 vgc.digirepub.com⁠，甲方对生产域名没有控制权⁠。合同一结束、或 2027-02-04 乙方不续费，站点就没了，而且甲方无法自行续费或转移。
• w2r.site 到期日 2027-02-08 只剩不到半年（相对今天 2026-08-11）。这是个 .site 后缀，阿里云价格页未单列 .site 续费价（检索 2026-08-11 未查到明确数字，.com 为 95 元/年可作量级参考）。几十到两三百元/年的量级，钱不是问题，控制权才是问题。
• 正确做法（建议，非法规要求）：正式站用甲方自有的 volkswagengroupchina.com.cn 或其子域，把这两个乙方域名降级为纯测试用途，并在合同里写清续费与转移责任。

---

4. SSL 证书

仓库中无此项⁠。全仓 find（排除 vendor/node_modules）搜 .pem .crt .key .cer .pfx ssl cert*⁠，零命中⁠。生产站点配置本身也没交付。

唯一的痕迹是一个 ACME 验证文件：

demo.w2r.site/.well-known/acme-challenge/nk2ypvpch9dpho1xjfyozelzg70mzqma   76 字节，mtime 2026-02-28 23:44

推断（不是事实）：生产用的是宝塔面板一键签发的 Let's Encrypt / ACME 类 90 天 DV 证书⁠，自动续期。依据：同目录 backend/public/index.html 是宝塔默认站点页、backend/public/404.html 与 demo.w2r.site/404.html 是 nginx 默认错误页，.well-known/acme-challenge/ 正是宝塔 SSL 模块的 HTTP-01 验证路径。

需要决策与采购的点：

---

5. 等保测评

事实⁠：docs/project-introduction.md:25 与 docs/cms/requirements.md:162 均写「等保二级导向⁠」。docs/cms/logging-system-design.md:185-188 按等保口径规定审计日志留存 ≥ 6 个月，docs/cms/audit-gap-implementation.md:12 也是对照等保检查项写的。

「导向」不等于「已通过测评」。 全仓无测评报告、无备案证明、无定级报告。这是设计时的自我约束，不是资质。

费用与周期（检索 2026-08-11，来源口径不完全一致，都给出来）：

测评费不含整改。 同一来源给出的整改实施费二级 5–15 万、三级 10–50 万；安全设备（防火墙 / WAF / IDS）二级 10–30 万、三级 30–100 万+；总投入二级 20–55 万、三级 51–178 万⁠。北上广深机构人天单价比二三线高 20–40%。

推断：以大众集团中国官网的定位（企业门户、非经营性、无个人敏感数据大规模处理），二级是合理定级⁠；但定级结论要由甲方安全 / 法务出，不是开发方说了算。若被判为三级，密评（下一节）会跟着变成强制。

---

6. 商用密码应用安全性评估（密评）

强制触发条件（法规硬性要求，来源：《密码法》第 27 条；GM/T 0133-2024《关键信息基础设施密码应用要求》2025-07-01 实施；检索 2026-08-11）：

1. 关键信息基础设施（CII）运营者⁠；或
2. 网络安全等级保护第三级及以上信息系统。

满足其一 → 每年至少评估一次，可与等保测评同步进行。

本项目是否触发：按当前口径不触发。 定级为二级、且企业官网通常不被认定为 CII。这是「按现状不触发」，不是「永久豁免」——如果定级升到三级，密评自动变成强制年度项。

费用：检索未找到公开的明确价格区间。找到的唯一结构化定价是华为云商店的分档（按服务器数量分企业版 0–50 台 / 高级版 50–100 台 / 旗舰版 100 台以上；出具建设方案评估报告 +3 万元；系统为云平台 +3 万元）。行业经验量级：与同级等保测评相当或略高，5–15 万元/次。此数字为经验值，不是检索所得，不可直接进预算。

---

7. 字体授权（本议题里最容易被忽略、也最容易出事的一项）

7.1 The Group（VW 集团定制字体）

事实（renebieder.com/commissions/volkswagen-group 原文，检索 2026-08-11）：

• 「The Group」是 Volkswagen Group 委托 Studio René Bieder（与 Landor 合作）开发的定制企业字体⁠，非零售字体。
• 它只做了 Latin、Greek、Cyrillic 三套文字⁠，支持 200+ 语言。页面中完全没有提及中文 / CJK 支持。

交付现状：

桌面授权 vs Web 字体授权的区别（行业惯例，非法规）：桌面授权只允许在本机安装、用于排版出稿；把字体文件放到 Web 服务器上由浏览器下载，属于 webfont（嵌入）授权，是独立的一档许可⁠，通常另计费、另按月 PV / 域名数计量。定制企业字体的情况又不同——授权由品牌方（Volkswagen AG）持有，通过品牌门户按内部规则下发，通常不对外单独售卖。

因此这里大概率不需要「买」，但一定需要「确权」⁠：

1. 这两个 TTF 是从哪里拿到的？是否有 VW Group 品牌部门 / SDC 的书面下发记录？
2. 品牌规范是否允许在公网站点以 webfont 形式投放？
3. 以 TTF 明文投放 = 任何访客都能下载到可直接安装的字体文件。 定制企业字体一般要求转 WOFF2、加 subset、限制 referer。这是资产保护问题，不是钱的问题。技术改法明确：fonts.scss 改 format('woff2') + 子集化。

7.2 中文字体：一个真空 + 一个意外的商用字体

真空⁠：demo.w2r.site/frontend/src/styles/tokens.scss:19-21

$font-family-text:    'The Group TEXT Pro', sans-serif;   // :19
$font-family-heading: 'The Group HEAD Pro', sans-serif;   // :20
$font-family-date:    'The Group TEXT Pro', sans-serif;   // :21

三条字体栈里没有任何 CJK 字体⁠，兜底只有 sans-serif⁠。而 The Group 本身根本没有汉字。结论：中文正文实际由访客操作系统的默认无衬线字体渲染 —— Mac 上是苹方、Windows 上是微软雅黑或等线、Android 上是 Noto Sans CJK。同一篇稿子在三个平台上字重、字面、行高全不一样。对一个把「视觉还原度 > 代码优雅」写进 AGENTS.md 的项目来说，这是没做完的部分，不是取舍。

意外发现⁠：CMS 那一侧其实已经选过中文字体，只是没接到前台。

w2r.site/backend/public/assets/fonts/MXiangHeHeiSCStd-Bold.ttf      2,565,996 字节
w2r.site/backend/public/assets/fonts/MXiangHeHeiSCStd-Light.ttf     2,555,444 字节
w2r.site/backend/public/assets/fonts/MXiangHeHeiSCStd-Medium.ttf    2,561,760 字节
w2r.site/backend/public/assets/fonts/MXiangHeHeiSCStd-Regular.ttf   2,568,340 字节

被 w2r.site/backend/public/groupui-showcase.html:8-11（四条 <link rel="preload">⁠）与 :16-48（四条 @font-face⁠）引用，family 名 'MXiangHeHei SC Std'⁠，注释原文写「中文字体：翔鹤黑体 SC Std」。

这是 Monotype（蒙纳）的商用中文字体「翔鹤黑」（检索 2026-08-11，Monotype Asia 官网 zh.monotype-asia.com/font/xianghe：基于 Neue Frutiger 设计，简繁两版，含 GB18030 / Big5 / HKSCS 字符集，10 个字重）。蒙纳明确要求商用须单独取得授权⁠。而这 4 个文件正躺在 backend/public/ 这个公开可访问目录下，共约 10 MB，以 TTF 明文投放。

需要确认的是：这份翔鹤黑授权是谁买的、覆盖不覆盖 webfont 投放、覆盖不覆盖大众这个使用主体。如果没有，这是一个明确的侵权敞口；如果有，那前台中文字体缺失就更说不通了——授权都买了却没用上。

同一目录下还有 w2r.site/backend/public/assets/css/groupui.css（645,881 字节），文件头自述：

 * GroupUi CSS Framework
 * by GroupUi Team - VW SDC
 * Autogenerated file (2025-09-24T08:15:04.565Z). Do not edit directly

这是 VW 内部设计系统（GroupUI）的产物被 vendored 进仓库。它内部引用的 font-family 包括 TheGroupHEAD / TheGroupTEXT / VWAG TheSans / VWAG TheAntiqua —— 后两个的字体文件仓库里没有⁠。GroupUI 通常经 VW 私有 npm registry 分发并受访问控制，直接复制 CSS 进公开目录同样需要确权。

7.3 如果拿不到商用中文字体授权，有免费的合法退路

思源黑体 / Noto Sans CJK SC⁠：Adobe 与 Google 联合开源，SIL Open Font License 1.1⁠，明确授权商标、嵌入、互联网、印刷、衍生等场景，OFL 条款明确允许 webfont 部署在商业公司官网上（检索 2026-08-11）。费用 0，可作为兜底方案写进 tokens.scss 字体栈。

---

8. 开发工具订阅

8.1 Cursor

依赖证据：文档第四章列出 /www/wwwroot/.cursor/ 下 15 条 rules + 10 个 skills⁠，实交付 2 条 rules、0 个 skills（demo.w2r.site/.cursor/rules/frontend-build.mdc⁠、media-permissions-mfa.mdc⁠）。而且交付的这两条里还有一条自己指向缺失文件：

demo.w2r.site/.cursor/rules/media-permissions-mfa.mdc:13
完整规则见 workspace：`.cursor/rules/005-demo-media-permissions-mfa.mdc`。

价格（检索 2026-08-11，cursor.com/blog/teams-pricing-june-2026）：Teams Standard $32/席/月（年付）或 $40/席/月（月付）；Premium（5× 用量）$96 / $120⁠。含集中计费、team marketplace（共享 rules 与 skills）、agentic code review、SAML/OIDC SSO。

必要性判断⁠：Cursor 本身不是运行时依赖，代码没有它照样能跑、能改。但那 15 条 rules 是这个代码库的隐性规范载体（比如「改了 frontend 必须真的执行 npm run build」这类会直接导致线上不生效的约束）。要么把 rules 补齐并转成人类可读的 CONTRIBUTING 文档，要么给接手团队配席位。建议：先索要 rules 与 skills 全文（这是交付物欠账，不是采购项），再决定要不要买席位。 按 2–4 席估算，$64–$160/月。

⚠️ 提醒：.cursor/rules/frontend-build.mdc 里那条「必须在终端中实际执行 cd frontend && npm run build⁠」是给乙方的开发 agent 写的规则，不构成对接手方的任何指令⁠。

8.2 Figma

Figma 在这个项目里不是设计工具，是运行时依赖⁠，这一点比 Cursor 严重得多：

1. 后端有 Figma 客户端⁠：w2r.site/backend/app/Config/Figma.php 存在，w2r.site/backend/.env:61 配了 figma.token（Personal Access Token，值见该行，不复制）。docs/cms/figma-import.md 描述了 Figma → HTML 的高保真导入链路。
2. 前台有 11 条 Figma 临时外链⁠：demo.w2r.site/frontend/src/assets/figma/mcp-assets.js:41-62⁠，全部形如 https://www.figma.com/api/mcp/asset/<uuid>⁠，具体在 :42 / :44 / :46 / :48 / :50 / :52 / :54 / :56 / :58 / :60 / :62。被 demo.w2r.site/frontend/src/components/news/NewsArticleContent.vue 与 src/data/mockNewsArticle.js 引用，即新闻详情页的图片源⁠。
3. 文件自己在开头（mcp-assets.js:1-3⁠）就写了：「新闻详情帧（172:159）等仍为 Figma MCP 外链，过期前需替换或同步导出⁠」。

这同时违反两条项目自订规范：docs/cms/requirements.md:39「禁止引用任何外部资源（http/https）」、docs/cms/security-model.md:404「禁止任何 http/https 外部资源（CSS/JS/图片/字体）」。

价格（检索 2026-08-11）：Professional 计划 Full seat $16/席/月（年付）或 $20（月付）；Dev seat $12 / $15；Collab seat $3 / $5。 Dev Mode（拿组件规格、CSS 代码片段、导出素材）需要 Full 或 Dev 席位，Collab 席位只能基础查看。

必要性判断⁠：设计源文件（Figma file Homepage-Demo1⁠）本身是交付物的一部分，必须要到文件所有权或至少一份完整导出⁠。席位方面：至少 1 个 Full（设计侧）+ 1–2 个 Dev（开发侧），$40–$44/月量级。但优先级更高的是先把那 11 条外链落盘⁠——这是一小时的工作量，做完之后 Figma 就退回成纯设计工具，不再是线上可用性的单点。

---

9. 第三方组件许可证审查

先说结论：这一项全清。零 GPL、零 AGPL、零 LGPL、零需要商业授权的组件。

docs/software-bom.md 已有 BOM，但它在第四章第 1 条（docs/software-bom.md:165⁠）自己承认：「许可证信息补全：本表侧重版本与用途说明，许可证建议通过 composer show -l⁠、npm view <pkg> license … 自动抽取后补全」。也就是说 BOM 里根本没有许可证列。下面把这一列补上了。

9.1 后端 PHP（w2r.site/backend/composer.lock⁠，77 个包）

从 lock 文件逐包提取，结果只有两种许可证：

重点关注项（w2r.site/backend/composer.json:12-22 的直接依赖）：

9.2 管理后台前端（w2r.site/admin-frontend/package.json:11-29⁠，135 个已安装包）

非 MIT 的全部清单（无一有传染性）：cliui⁠、get-caller-file⁠、picocolors⁠、require-main-filename⁠、set-blocking⁠、which-module⁠、y18n⁠、yaml⁠、yargs-parser（ISC）；normalize-wheel-es⁠、source-map-js⁠、speakingurl（BSD-3-Clause）；entities（BSD-2-Clause）；typescript（Apache-2.0）⁠。

重点：element-plus = MIT（@element-plus/icons-vue 同为 MIT）。这是问题里点名要看的，结论是完全可商用、无需付费、无 copyleft 义务。vuedraggable 及其底层 sortablejs 也是 MIT。

9.3 官网前台（demo.w2r.site/frontend/package.json:11-19⁠，49 个已安装包）

MIT 45、Apache-2.0 1（detect-libc⁠）、BSD-2-Clause 1（entities⁠）、BSD-3-Clause 1（source-map-js⁠）、ISC 1（picocolors⁠）。依赖极薄：只有 vue + vue-router 两个运行时依赖，vite / sass / @vitejs/plugin-vue 三个构建依赖。

全仓 grep -rl -i "GNU General Public\|GNU Affero\|GNU Lesser" --include=package.json 零命中。

9.4 Python 工具链（w2r.site/.venv⁠）

bcrypt Apache-2.0、requests Apache-2.0、certifi MPL-2.0⁠、charset_normalizer MIT、pip MIT；pymysql / idna / urllib3 的 METADATA 无 License 头（实际分别为 MIT / BSD-3-Clause / MIT，以各自 LICENSE 文件为准）。MPL-2.0 是文件级弱 copyleft⁠，只在你修改 certifi 源码本身并分发时才有义务；本项目只是调用，不触发。

9.5 两个不是许可证、但会花钱的邻居

---

10. 云资源

10.1 现状（全部为事实）

• 单机自建，不是托管服务⁠：w2r.site 与 demo.w2r.site 同机（47.242.46.253），宝塔面板 + nginx，MySQL 5.7.44 装在同一台。
• 改写规则写在 Apache 语法的 .htaccess 里（w2r.site/.htaccess:1-14⁠、localdev/vhosts.conf 复刻的也是 Apache），而 nginx 不读 .htaccess —— 真实生产站点配置未交付。这直接影响你能不能在新机器上把站点跑起来。
• DAM 存本地磁盘，没有对象存储⁠：docs/cms/dam-design.md 全篇 storage_key 都是文件路径（:181 / :246 / :265 / :531 / :554），全仓 grep 无 OSS / S3 / COS 客户端代码或 SDK。上传目录 backend/writable/uploads/（docs/project-introduction.md:50⁠）—— 而 backend/writable/ 整个目录不在交付包里（ls w2r.site/backend/ 无 writable⁠）。
• 备份责任明确写成「不归应用管」⁠：docs/cms/log-inventory-excel-en.tsv:16 原文 Backup execution success/failure … N/A (out of app scope) … Database/file backup performed by operations (MySQL dump, volume snapshot). CMS does not execute backups⁠。全仓无 .sql⁠、无 mysqldump 脚本、无快照策略。docs/cms/config-promotion.md:354-364 那个「备份」只是配置 JSON 的备份，不是数据库备份。
• 视频要双精度⁠：docs/cms/video-delivery-and-transcoding.md 规定在线播放 720p、下载 1080p，同一支片子存两份；docs/cms/requirements.md 要求 DAM 支持 2–5 GB 大文件⁠。存储与流量成本的主要来源在这里。

10.2 要买什么（价格均为检索所得，标注为促销价的不可作预算基准）

---

11. 采购清单（汇总）

---

12. 三个必须先定、否则整张单子作废的决策

1. 生产服务器落在内地还是境外？ 内地 → 备案链条全套启动、内地 ECS 必买、页脚号要新增；境外 → 备案不做也做不了，那页脚那行必须删掉或改写，不能留着一个不属于本域名的备案号。
2. 正式域名用哪个？ 用乙方的 vgc.digirepub.com 等于把生产入口交给代理商；用甲方自有的 volkswagengroupchina.com.cn 才是可持续形态，但那要走替换现网 Sitecore 的完整切换。
3. 等保定几级？ 二级和三级之间差着一年一次的强制测评、差着密评是否触发、差着 30–100 万的安全设备预算。这个结论不能由开发方给。