Day37-26｜18.8.1 电子商务系统的安全性设计：从登录、交易到风控与灾备

对应教材目录：第 18 章 安全架构设计理论与实践 → 18.8 安全架构设计案例分析 → 18.8.1 电子商务系统的安全性设计

学习目标：掌握电子商务系统的主要资产、威胁和安全目标；能够设计覆盖用户、商品、订单、支付、物流、运营和数据平台的纵深防御架构；能够在案例分析中把认证、授权、机密性、完整性、抗抵赖、风控、审计和灾备形成闭环。

一、电子商务系统为什么是典型安全案例

电子商务系统同时处理身份、商品、订单、支付、优惠、库存、物流和个人信息，既有高并发，又有直接经济价值。攻击者可能盗取账号、刷券、篡改价格、制造超卖、伪造支付回调、批量导出数据或利用管理接口控制促销规则。

它的安全目标不能只写“防止黑客攻击”，而应分解为：

1. 用户身份可信，账号和会话不被轻易接管。
2. 租户、用户、商户和运营人员只能访问授权资源。
3. 商品、价格、优惠、订单和支付金额不能被非法篡改。
4. 支付、退款、结算等关键行为可验证、可追溯、不可抵赖。
5. 个人信息、支付信息和经营数据得到分级保护。
6. 大促和异常流量下系统保持可用，安全控制不因降级而失效。
7. 事故发生后能够发现、隔离、恢复和对账。

二、系统资产与信任边界

典型电子商务架构包括客户端、接入层、用户中心、商品中心、订单中心、库存中心、支付中心、营销中心、物流中心、数据平台和运营后台。

用户/商户/运营人员
          |
    CDN/WAF/网关
          |
  用户、商品、订单、营销服务
    |       |       |
库存服务  支付服务  物流服务
    |       |       |
数据库/缓存/消息/对象存储/数据平台
          |
     审计、风控、监控、灾备

主要信任边界包括：公网与接入层、用户与服务、服务与服务、业务服务与支付机构、生产与运营后台、在线库与数据平台、主环境与灾备环境。每个边界都要说明身份、授权、加密、审计和故障处理。

三、用户身份与账号安全

1. 注册和登录

注册需要控制验证码、设备频率、手机号或邮箱验证和异常注册。登录应使用安全口令策略、风险识别、登录失败限制、设备和地域分析，并在高风险场景触发多因素认证。

2. 会话与令牌

访问令牌应设置有效期、受众、作用域和版本，刷新令牌要可撤销。登录、改密、绑定支付账户和修改收货地址等操作应使高风险会话重新认证。令牌不得出现在 URL、日志和错误响应中。

3. 账号接管防护

应监控异地登录、设备突变、异常速度、批量下单、异常退款和支付工具变化。风控不应只在登录时判断，还要贯穿下单、优惠、支付和提现等关键行为。

四、访问控制与后台分权

用户只能查看和操作属于自己的订单、地址和优惠；商户只能管理本商户商品、库存和订单；客服可以查看必要信息但不能修改支付结果；运营人员可以配置活动但不能直接调整结算；财务人员可以对账和退款，但不能同时审批自己的退款。

可以采用 RBAC 管理岗位职责，结合 ABAC 处理商户、区域、项目、订单状态和风险属性，再用业务状态机限制操作顺序。高风险后台操作要求临时授权、双人复核和全量审计。

主体身份 + 组织/商户属性 + 资源归属 + 动作 + 订单状态 + 风险等级
                              |
                              v
                       授权决策与增强认证

前端菜单权限不能作为安全边界；每个服务端接口都要执行资源级和动作级授权，批量接口和导出接口要单独建模。

五、商品、价格和营销完整性

商品价格、库存、优惠规则和结算金额属于高价值业务数据。客户端提交的价格、折扣、库存和活动状态都不可信，服务端应从可信数据源读取并重新计算。

1. 价格校验

订单保存商品快照、价格版本、优惠计算版本和税费信息。支付金额必须由订单服务端计算，支付服务应校验订单号、商户号、币种和金额，不能信任客户端回传。

2. 优惠和防刷

优惠券应具备唯一使用记录、有效期、适用范围、并发扣减和幂等键。领取、核销和退款时都要校验状态，避免重复使用和跨用户转移。风控可根据设备、账号、IP、收货地址和支付工具识别批量套利。

3. 库存一致性

库存扣减应采用原子更新、预占和释放机制，并通过订单、库存和支付对账发现差异。超时订单释放库存必须幂等，消息重复或延迟不能造成重复回补。

六、订单与支付安全

1. 订单状态机

待确认 -> 待支付 -> 支付处理中 -> 已支付 -> 配送中 -> 已完成
   |          |           |             |
取消       超时关闭     查询补偿       退款/售后

状态转换应由服务端控制，明确主体、前置条件、动作、后置事件和幂等规则。禁止客户端直接传递目标状态。

2. 支付请求

支付请求要绑定订单号、商户、金额、币种、用户和时间，采用签名或认证机制防止篡改。支付页面和回调链路采用加密通信，支付密钥由密钥管理系统保护。

3. 支付回调

回调处理顺序建议为：验证来源和签名、检查时间窗口和回调号、查询服务端订单、校验金额和商户、检查当前状态、事务更新、记录幂等结果、发布后续事件。回调重复、乱序和超时都应有明确处理。

4. 退款与结算

退款不能超过已支付减去已退款金额；退款申请、审批和执行应职责分离。结算数据应从不可变交易流水生成，定期与支付机构账单对账，差异进入人工复核和补偿流程。

七、通信、数据和隐私保护

外部访问采用 TLS，服务间根据风险采用双向认证和服务身份。支付、身份和高敏感接口不能因为处于内网就跳过授权。

数据保护可以分层设计：

搜索、缓存、消息、报表和测试环境必须继承相应保护级别，不能只保护主数据库。

八、风控与反欺诈架构

风控系统可由规则引擎、特征平台、设备指纹、行为分析和人工审核组成。规则包括登录异常、批量注册、优惠套利、虚假交易、异常退款、盗卡支付和提现风险。

事件采集 -> 特征计算 -> 规则/模型决策 -> 通过/拦截/增强认证/人工审核
    |                                              |
    +---------------- 风险反馈 <-------------------+

风控决策应可解释、可审计、可回放。不能因为模型服务短暂不可用就默认放行高风险操作；应设计分级降级策略。模型和规则本身也要有权限、版本、审批和回滚控制。

九、审计、监控与应急响应

重点审计事件包括登录、改密、绑定支付工具、价格变更、优惠规则发布、库存调整、订单状态变化、支付回调、退款、导出和管理员授权。日志应关联用户、设备、IP、订单号、requestId、策略版本和结果。

监控指标包括登录失败率、支付失败率、回调重复率、订单状态异常、库存差异、退款异常、批量导出、风控拦截率和消息积压。安全事件发生后，应能够冻结账号或商户、关闭活动、暂停退款、隔离服务并保留证据。

十、可用性、灾备与恢复

电子商务系统需要在大促、局部故障和支付机构不可用时保持核心能力。可采用多副本、限流、熔断、降级、缓存、异步削峰和多机房部署，但安全策略不能随意绕过。

灾备设计要覆盖数据库、对象存储、密钥、配置、消息、审计和风控规则。恢复后不能立即全量开放交易，应先完成数据校验、订单状态对账、支付账单对账和权限检查，再逐步恢复。

十一、综合安全架构图

客户端/商户/运营后台
          |
    CDN + WAF + 防刷
          |
统一身份认证 + API网关 + 风控
          |
用户 | 商品 | 订单 | 库存 | 支付 | 物流
          |
  服务身份/授权/加密/幂等/状态机
          |
数据库 | 缓存 | 消息 | 对象存储 | 搜索
          |
密钥管理 | 审计日志 | 监控告警 | 备份灾备

十二、案例题答题模板

电子商务案例题可以按以下顺序组织：

1. 识别用户、商户、运营、支付机构和系统服务等主体。
2. 识别订单、金额、库存、优惠、支付信息和个人信息等资产。
3. 说明认证、授权、传输加密、存储加密和脱敏。
4. 说明价格重算、状态机、幂等、签名、防重放和对账。
5. 说明风控、限流、反刷、审计和异常告警。
6. 说明后台分权、临时授权、双人审批和操作留痕。
7. 说明高并发、支付机构故障、消息重复和灾备恢复策略。
8. 给出验证指标和测试方法，形成安全闭环。

十三、课后练习

练习 1

为什么电子商务系统不能信任客户端提交的订单金额？

参考答案：客户端数据可被篡改，必须由服务端根据商品、优惠、税费和活动版本重新计算，并在支付请求和回调时校验订单号、商户和金额。

练习 2

支付回调处理的关键步骤有哪些？

参考答案：来源和签名验证、时间窗口和回调号检查、订单与商户查询、金额和币种校验、状态机判断、事务更新、幂等记录、审计和后续事件发布。

练习 3

请列出电子商务后台至少四种职责分离设计。

参考答案：活动配置与结算分离；退款申请、审批和执行分离；商品维护与价格审核分离；权限申请与授权审批分离；运维操作与审计复核分离。

练习 4

论文题：论“高并发电子商务系统的安全架构设计”。

参考答案要点：接入防护、身份认证、访问控制、订单状态机、库存并发、支付签名、幂等、风控、防刷、数据分级、密钥管理、审计、灾备和对账，并说明可用性与安全性的权衡。

十四、今日复盘

• 我能否画出电子商务系统的主要组件和信任边界？
• 我是否能分别说明账号、订单、支付、库存和优惠的安全问题？
• 我能否写出支付回调和退款的完整性控制？
• 我是否考虑了风控、后台分权、日志和数据副本？
• 我能否解释大促和故障降级时如何保持安全？
• 我能否用案例答题模板形成完整闭环？

电子商务系统安全设计的核心结论是：安全必须贴近业务交易链路。只有把用户身份、商品和价格完整性、订单状态、支付证据、库存一致性、风控、后台分权、审计和灾备放在同一架构中，才能真正防止“账号被盗、订单被改、金额不一致、支付不可追溯和故障后无法恢复”等复合风险。