2.1 认证、授权和审计回答不同问题#

• **认证（Authentication）**回答“你是谁”。它可以依赖用户登录、硬件令牌、企业身份提供商或服务身份，但认证成功不代表可以访问所有资源。
• **授权（Authorization）**回答“你能对哪个资源执行什么动作”。授权必须由服务端执行，不能相信前端隐藏按钮、请求参数或网关已经检查过。
• **审计（Accounting/Auditing）**回答“实际发生了什么以及能否追溯”。审计记录不能反向当成授权凭证，也不能用一条普通应用日志证明高风险操作已经被批准。

OWASP Authorization Cheat Sheet 建议默认拒绝、按最小权限授予访问，并持续检查权限蔓延。最小权限不仅适用于人，也适用于服务、批处理任务和数据库连接用户。服务只应拥有它完成工作所需的动作和数据范围，而不是直接使用一个可以读取、修改所有账务表的共享账号。

2.2 RBAC、ABAC 和资源关系如何选择#

三种模型不是互斥产品，而是不同的授权表达方式：

金融后台通常采用组合模型：RBAC 先限制岗位能力，ABAC 再限制金额、机构和环境，资源关系校验最后确认该主体是否能操作这笔具体业务。例如“资金运营专员”角色可以申请退款，但只允许操作所属机构、未结算订单，且单笔金额不得超过阈值；超过阈值必须进入审批状态，而不是把角色替换成“超级管理员”。

授权决策至少应显式接收以下输入：

1
subject      = 用户 / 服务身份 / 任务身份
2
action       = refund / freeze / adjust / export
3
resource     = 订单、账户、批次或报表
4
context      = 机构、金额、币种、来源网络、当前时间、审批状态
5
policy       = 版本化的授权策略

服务端的检查应在资源加载后进行，避免“只校验请求里的 account_id，不查询真实归属”的对象级授权漏洞。授权拒绝要安全失败，不能因为策略服务超时、字段为空或异常分支而放行；必要时应把“策略不可用”单独记录为系统故障，而不是伪装成业务拒绝。

2.3 服务身份不能等同于用户身份#

一个由用户发起的请求经过多个服务时，至少要保留两类身份：

• 原始主体：哪个用户或运营人员提出了请求。
• 当前服务主体：哪个服务、任务或机器人正在执行下一步动作。

下游不能只看到一个共享服务账号，否则无法区分“用户授权的退款”和“定时任务的补偿”，也无法在审计中定位责任主体。可在经过认证的服务间请求中携带不可由客户端自行修改的调用链上下文，并由下游重新验证签名或通过双向认证确认调用方；subject、actor、service、request_id 和 trace_id 应分别建模，不能把一串可编辑的 HTTP 头当成可信审计字段。

服务身份要有独立的权限、短期凭证和轮换路径。开发环境、测试环境和生产环境不能共用密钥；数据库账号、消息生产者、支付渠道账号也不应全部绑定为同一个高权限身份。

3.1 双人复核是职责分离，不是多点一次按钮#

支付、退款、调账、解冻、批量导出和权限提升等动作，往往需要“发起人”和“审批人”分离。NIST SP 800-53 的 AC-5 Separation of Duties 将职责分离定义为把需要相互制约的职能分配给不同个人或角色，以降低单一授权被滥用的风险。

双人复核至少要表达四个约束：

1. 发起人不能审批自己发起的同一笔高风险操作。
2. 审批人必须拥有针对该动作和金额范围的审批权限，而不是只有后台登录权限。
3. 审批对象要绑定交易摘要，金额、币种、收款方、账户和用途任一项改变都必须重新审批。
4. 执行服务在最后一步重新验证审批状态和交易摘要，不能只在提交页面检查一次。

这套流程常被称为 maker-checker。它不是分布式事务，也不是幂等机制；它减少的是错误或滥用能够直接造成资金效果的机会。审批记录和执行效果仍然需要在本地事务、状态机和对账链路中可靠落地。

3.2 绑定交易摘要，防止审批后换参数#

审批不能只批准一个可变的订单 ID。系统应对影响资金效果的字段生成规范化摘要，例如：

1
digest = H(
2
    version || action || account_id || beneficiary_id ||
3
    amount_minor || currency || purpose || expires_at
4
)

审批记录保存 digest、策略版本、审批人、审批时间、有效期和审批结果。最终执行前重新计算摘要并比较；摘要不一致时拒绝执行并进入差错处理。序列化必须规范化字段顺序、编码、金额单位和空值表示，不能依赖语言对象的默认字符串化，否则同一交易在不同服务中可能得到不同摘要。

1
approve(request):
2
    assert request.state == PENDING_APPROVAL
3
    assert request.initiator != current_actor
4
    assert policy.allows(current_actor, request.action, request.amount)
5

6
    request.approval_digest = canonical_digest(request.business_fields)
7
    request.approver = current_actor
8
    request.state = APPROVED
9
    save(request)
10

11
execute(request_id):
12
    request = load_for_update(request_id)
13
    assert request.state == APPROVED
14
    assert request.expires_at > now()
15
    assert canonical_digest(request.business_fields) == request.approval_digest
16
    assert policy.still_allows(request.approver, request.action, request.amount)
17
    execute_idempotently(request)

上面是伪代码，重点不在语法，而在“批准”和“执行”之间的状态与字段校验必须由服务端完成。审批凭证应是一次性或短时有效的，且不能通过修改请求体、删除审批字段或触发异常来跳过最后一道检查。OWASP Transaction Authorization Cheat Sheet 也强调服务端执行授权、按顺序完成交易授权步骤、保护被授权的交易数据，并让每次操作使用唯一且短时有效的授权凭证。

3.3 幂等键和安全防重放不是同一个东西#

二者都可能出现一个 request_id，但目的不同：

• 幂等键解决合法请求因为超时、重试或消息重复而再次到达。服务可以返回第一次执行的结果，避免重复资金效果。
• 防重放凭证解决攻击者拿到一份曾经有效的请求或签名后，在不应再次执行时重新提交。它需要 nonce、时间窗口、签名覆盖字段、使用记录或单调序列等安全约束。

如果把所有重复请求都拒绝，网络重试可能被误判为攻击；如果只做幂等而不验证授权有效期，已经撤销的高权限请求仍可能被重放。一次高风险操作通常需要同时具备：稳定业务幂等键、一次性授权挑战、过期时间、主体绑定和服务端已使用记录。

对于渠道回调，还要校验签名、渠道身份、业务单号、金额和状态，并为回调设置已处理记录及过期窗口。OWASP Third Party Payment Gateway Integration Cheat Sheet 将回调幂等和带过期时间的唯一交易 ID 作为防止重复处理与回放的基本措施。回调验签通过也不代表业务状态一定可以转换，仍需经过本地状态机和资源授权检查。

4.1 不把秘密当普通配置#

数据库密码、支付渠道密钥、签名私钥、访问令牌、证书和加密密钥都属于不同生命周期的秘密。把它们写入代码仓库、镜像、普通配置中心或日志，会让一次代码泄露扩散成长期的生产权限泄露。

OWASP Secrets Management Cheat Sheet 建议集中管理秘密、细粒度授权、自动轮换、使用短期或动态凭证，并为紧急恢复准备经过保护和演练的 break-glass 流程。NIST 的 SP 800-57 Key Management 则把密钥生成、保护、使用、轮换、归档和销毁作为完整的生命周期，而不只是选择一个加密算法。

工程上至少要做到：

• 秘密由专用密钥管理或秘密管理系统托管，应用通过工作负载身份获取短期凭证。
• 每个服务、环境和用途使用独立身份，权限只覆盖必需的秘密路径和操作类型。
• 生产私钥尽量在 KMS 或 HSM 中完成签名，应用拿不到可导出的私钥材料。
• 轮换支持新旧版本并存的迁移窗口，先让新密钥写入，再按读路径逐步淘汰旧密钥。
• 访问秘密、导出、轮换、撤销和失败尝试都进入审计，轮换本身不能静默发生。
• 备份和恢复由受控人员执行，恢复后的秘密立即验证用途、权限和有效期。

4.2 密钥用途要隔离#

不要用同一个密钥同时做数据库加密、接口签名、令牌签发和日志脱敏。不同用途需要不同的权限、轮换节奏和撤销影响；签名私钥泄露时，系统还要能根据密钥版本和签名算法识别受影响的请求范围。

常见的密钥元数据包括 key_id、用途、算法、版本、创建时间、生效时间、轮换时间、撤销状态和责任域。业务记录应保存使用过的 key_id，这样在轮换后仍能验证历史签名和定位受影响交易。加密只解决机密性或完整性的一部分问题，不能替代授权，也不能证明一笔资金操作符合业务规则。

4.3 紧急账号不是共享超级账号#

break-glass 账号应满足最小化、短时化、可审计和事后复核：使用前说明原因，使用时触发告警，凭证采用短期或一次性方式，操作范围受限，使用后立即失效或轮换。禁止把账号密码写在值班手册、聊天记录或脚本中，更不能以“线上出问题先用 root”为常态化运维路径。

5.1 三类记录分别保存什么#

• 账务流水记录资金事实和可逆的业务效果，例如分录、冲正和退款。它必须满足账务约束，不能因为日志采样而缺失。
• 业务审计记录记录谁申请、批准、执行、拒绝或修改了什么业务对象，以及策略和审批证据。它用于追责、复核和合规检查。
• 技术运行日志记录调用、异常、延迟、重试和堆积，用于排障和观测。它不应成为唯一的授权证据。

三者可以通过 business_id、request_id、trace_id 和 audit_event_id 关联，但不应互相替代。一次退款的账务效果可以成功，但授权审计记录缺失；这不是“日志少一行”，而是需要进入安全差错处理和权限复核。

5.2 高风险审计事件的最小字段#

OWASP Logging Cheat Sheet 建议记录安全相关事件、保护日志免受篡改，并避免把口令、令牌、密钥和不必要的个人敏感数据写入日志。PCI DSS v4.x 的资料也把管理员操作、无效访问尝试、认证和权限变化、日志保护与时间同步列为审计重点。具体留存周期和字段仍以适用标准与内部制度为准。

一次权限或资金操作的审计事件通常需要包含：

• event_id、event_type、occurred_at、ingested_at 和时区；
• 原始主体、有效主体、服务身份、租户或机构标识；
• 动作、资源类型、资源标识的脱敏或哈希值；
• 授权策略版本、命中的规则、审批单号和交易摘要；
• 请求来源、设备或网络环境的必要标识、request_id、trace_id；
• 结果、失败原因分类、状态变更前后摘要和影响范围；
• 事件自身的版本、写入来源和完整性校验信息。

“记录所有字段”不是越多越好。日志平台不应保存完整银行卡号、认证令牌、密码、私钥或可直接复用的签名材料。敏感字段可使用截断、掩码、不可逆哈希或单独的受控关联存储，选择方式取决于排障、审计和合规需求。日志内容还要做换行和分隔符清洗，避免日志注入；字段结构优先采用受控的 JSON schema，不让用户输入直接拼接日志行。

5.3 让证据难以被悄悄改写#

审计存储至少应与业务写库和应用管理员权限隔离。常见控制包括：仅追加写入、独立写入身份、集中转发、访问分离、保留期锁定、完整性校验、删除和配置变更告警，以及定期验证日志是否持续产生。高风险事件可以保存前后状态摘要和哈希链，但哈希链只能帮助发现修改，不能代替隔离存储、权限控制和备份。

时间是审计证据的基础。服务、数据库、消息系统和日志平台要使用可监控的时间同步机制，同时保存事件发生时间和接收时间，避免仅凭一个本地时钟重建因果关系。跨时区的账务日期、业务日期和技术时间要分别建模，不能用日志时间直接替代会计日期。

6.1 从资产和信任边界开始#

对一条退款链路，可以按下面顺序做一次轻量威胁建模：

1. 列出资产：余额、分录、支付凭证、客户身份信息、渠道密钥、审批记录和审计证据。
2. 画出主体：终端用户、运营人员、服务、批处理任务、渠道和管理员。
3. 标出信任边界：浏览器到 API、服务到服务、应用到数据库、应用到密钥系统、系统到外部渠道。
4. 逐条问“谁能伪造、重放、修改、跳过、扩大或隐藏这一步”。
5. 为每个高风险威胁指定预防、检测、响应和恢复控制，并写入测试或演练。

典型威胁与控制的映射如下：

威胁建模的产物不应停留在图上。每个风险都要落到接口契约、数据库约束、策略测试、监控告警或应急手册，否则只是把担忧换成了文档。

7.1 资金开关的设计约束#

• 开关按业务、渠道、机构、账户分组和操作类型限定范围，默认关闭危险能力而不是默认放行。
• 开关变更需要强认证、职责分离和短时授权；紧急情况下可以缩短审批路径，但不能删除操作者、原因和时间限制。
• 开关状态带版本号和生效时间，执行服务在实际动作前读取并校验，不能只在管理页面显示。
• 所有变更进入不可静默删除的审计，并触发告警；恢复操作同样需要授权。
• 定期做故障演练，验证开关真的能阻断新请求、不会误伤对账和冲正、恢复后不会重复执行积压任务。

7.2 事件响应的最小闭环#

发现疑似权限滥用、密钥泄露或异常扣款时，可以按以下顺序处理：

1. 确认范围：保留请求、审批、授权决策、服务调用和账务流水的关联证据。
2. 限制影响：暂停高风险动作、收紧限额、冻结受影响账户或撤销相关凭证。
3. 保护证据：保护审计存储和密钥访问记录，不要为了“清理现场”覆盖原始日志。
4. 核对事实：以账务流水、渠道账单和独立对账结果判断实际资金效果。
5. 修复与轮换：修正权限策略，撤销或轮换泄露凭证，处理挂账、冲正和退款。
6. 复盘验证：补充威胁模型、回归测试、监控规则和应急手册，并验证修复不会绕过一致性链路。

“先回滚数据库”不是通用应急方案。外部渠道、用户已看到的结果和审计证据可能已经产生，直接删除本地记录会破坏对账和追责。修复应通过新的冲正、退款、权限变更或差错单表达，让原始事实保留。

身份与授权#

• 认证和授权是否分离，所有非公开动作是否由服务端检查？
• 是否默认拒绝，权限是否按用户、服务、任务和环境分别授予？
• 是否做了对象级、字段级和机构范围校验，而不是只检查接口角色？
• 权限策略是否版本化、可测试、可解释，并有权限蔓延复核？
• 原始用户身份和服务执行身份是否同时保留，未使用共享超级账号？

资金操作与职责分离#

• 高风险动作是否有发起、审批、执行、对账的职责分离？
• 是否禁止自己审批自己发起的同一笔操作，并校验审批人的金额范围？
• 审批是否绑定规范化交易摘要、策略版本、有效期和一次性凭证？
• 执行前是否重新校验审批、摘要、资源状态和授权，而不是信任前端结果？
• 幂等键、防重放 nonce、签名和过期时间是否各司其职？

密钥与凭证#

• 秘密是否不进入代码、镜像、普通配置和日志？
• 服务身份是否只读取必需秘密，生产凭证是否短期化、可撤销、可轮换？
• 签名、加密、数据库访问和令牌用途是否使用隔离密钥？
• 是否保存密钥版本，支持轮换期间的新旧读写兼容和历史验证？
• break-glass 是否有短时授权、告警、审计、备份和演练？

审计与运行#

• 高风险成功、失败、拒绝、越权、策略变更和密钥操作是否都记录？
• 审计事件是否能关联主体、服务、资源、审批、请求和账务事实？
• 是否掩码或移除令牌、密码、私钥、完整卡号和不必要的个人敏感数据？
• 日志是否追加写、权限隔离、完整性可验证、持续产生且可告警？
• 时间同步、留存、访问和导出是否符合所在机构与法域要求？

威胁与应急#

• 是否围绕资产、主体、信任边界和资金效果做过威胁建模？
• 是否测试越权、审批后改参、重复授权、凭证泄露、日志篡改和重放？
• 紧急开关是否可按范围止血，且不会绕过审计、对账和冲正？
• 是否有撤销凭证、冻结账户、轮换密钥、差错处理和证据保护的操作手册？
• 是否定期演练，验证告警、开关、恢复和积压任务的行为符合预期？