安全架构

1 安全架构要回答什么

零售订单 API 接收顾客提交的商品、数量和收货信息，生成订单，调用库存与支付服务，再向顾客返回处理结果。运营人员需要查询异常订单，运维人员需要部署和恢复服务。业务希望促销期间继续接单，也希望顾客地址不被泄露、订单金额不被篡改、退款不能被任意发起。这些要求同时存在，安全架构的任务就是把它们转成系统边界、权限规则、数据处理约束和可以验证的证据。

安全架构首先回答：保护什么，防谁通过什么路径造成什么损失，由谁负责实施控制，以及控制失效后如何发现和恢复。只写“使用加密、部署防火墙、开启日志”还不够，因为这些措施未必覆盖最重要的业务动作。攻击者即使无法读取数据库文件，也可能利用查询接口看到其他顾客的订单；接口即使只允许登录用户访问，也可能允许普通顾客调用退款操作。控制必须与具体资产和动作对应。

本章统一使用这个订单场景：顾客通过公网访问订单 API；API 在业务网络中访问订单数据库，并调用库存与支付服务；客服通过管理入口处理售后；运维通过管理入口发布服务。订单保存必要的收货信息和支付结果引用，不保存支付凭据原文。支付服务如何处理其内部敏感数据属于外部依赖的责任，订单系统仍要验证返回结果并约束本地状态变化，不能把依赖关系当作责任转移。

先把需求写成可观察的目标。例如，顾客只能读取归属于自己的订单；客服只能在授权范围内查看必要字段；退款必须具有对应业务权限并留下操作记录；服务凭据泄露后能够撤销；管理入口故障时有受控恢复办法。这里既有保密性，也有完整性和可用性。订单持续可访问却允许金额被修改，不能称为安全；所有请求都被拒绝，同样不能满足业务目标。

架构方案还需要说明假设。我们假设身份服务能提供可信身份信息，支付通知来自约定的外部服务，运维人员有可用的值班渠道。但“假设可信”不等于省略验证：令牌仍需校验，支付通知仍需验证来源与业务关联，值班渠道仍需演练。假设应有负责人和失效应对，否则它只是隐藏风险。接下来以资产、身份、边界和数据流为线索，把这些要求逐步展开。

2 身份、边界与数据保护层次

身份回答“请求代表谁”，授权回答“这个身份可以对哪个资源执行什么动作”。顾客登录后获得身份凭据，服务端验证凭据有效，只能说明请求与某个身份关联，不能直接说明它有权读取任意订单。查询订单时，还要依据服务端保存的归属关系判断访问权限。客户端传来的顾客编号和订单编号都是输入，不能因为它们出现在已登录请求里就自动可信。

订单系统至少存在顾客身份、客服身份、运维身份和服务身份。客服读取订单与运维发布程序的职责不同，不能为了方便而共用高权限账号。服务身份用于 API 访问数据库、调用库存等机器之间的操作，也不应借用某位员工的账号。为不同用途建立权限范围，能让撤销、轮换和追踪更清晰。入门阶段先掌握最小权限：只授予完成当前职责所需的资源与动作，并定期回收不再需要的权限。

边界是信任条件发生变化的位置，不仅是网络分区。公网进入 API 是边界，顾客功能进入管理功能是边界，API 调用支付服务也是边界。业务网络中的服务并不天然可信，因为应用可能被攻破，凭据可能泄露，部署配置也可能出错。网络访问控制可以限制谁能建立连接，业务授权则限制连接建立后能做什么。只有网络隔离而没有资源授权，无法阻止获准连接的应用误用权限。

可以把保护层次理解为入口、服务、数据和管理操作之间相互配合的约束。入口限制请求规模并检查基本格式；服务验证身份、资源归属和业务状态；数据库权限限制可访问的数据与操作；管理入口限制人员、设备或网络来源，并记录高风险动作。每层承担明确目标，避免所有控制都依赖同一个网关配置。若网关规则失误，服务自身的订单归属检查仍应发挥作用。

数据保护要沿生命周期考虑。收集时只接收履约必需的信息，传输时使用受保护连接，存储时结合访问控制和加密，展示时按角色隐藏不必要字段，保留期结束后按规则删除。备份、导出文件、日志和排查截图同样可能包含地址与联系方式，不能只保护主数据库。日志通常记录操作对象、结果和关联标识，避免记录完整令牌、密钥或完整收货信息。

加密用于降低数据在特定暴露情况下被直接读取的风险，但有权解密的应用仍可能把数据返回给错误的人。因此，加密不能替代授权，密钥也不能与可公开访问的数据副本一起存放。方案应说明谁可以使用密钥、谁可以管理密钥、异常时如何撤销访问。证书协议和密码算法的内部细节可以后续深入，本章先确保每种控制都有明确保护对象、责任边界和验证方法。

3 威胁建模与控制映射

威胁建模是围绕系统实际工作方式，推演资产可能如何受损的过程。它不要求先掌握大量攻击术语。对订单 API，可以从问题开始：谁可能冒充顾客，谁能修改订单参数，谁能读取别人的地址，谁能滥用管理权限，谁能让关键依赖无法响应？把问题放到数据流和边界上，就能逐步得到可讨论、可验证的威胁，而不是泛泛地说“存在网络攻击风险”。

先列资产，再画数据流，接着标边界，最后逐条检查跨边界动作。关键资产除了数据库中的订单，还包括订单金额和状态、顾客隐私、支付结果、服务凭据、部署权限以及审计记录。部署权限能改变应用行为，审计记录能帮助确定事件范围，它们的价值并不低于业务数据。资产清单应写明业务用途和负责人，帮助团队判断哪些损失最值得优先投入。

威胁描述采用“主体通过入口执行动作，导致资产受到某种影响”的句式。例如，已登录顾客通过查询接口替换订单编号，读取其他顾客地址。这里入口、动作、资产和后果都很明确。相比之下，“接口不安全”无法指导实现与验收。随后写控制目标：每次读取订单都必须验证资源归属。再选实现措施：在服务端授权逻辑中比较可信身份与订单归属，并对不匹配请求返回不泄露额外信息的结果。

控制映射需要覆盖预防、发现和恢复。针对越权查询，预防措施是资源授权；发现措施是记录拒绝结果并监测异常访问模式；恢复措施是撤销相关会话、封堵缺陷并评估受影响订单。监测只能帮助发现，不能替代请求时的授权。恢复也不能消除已经发生的隐私泄露，但可以缩小继续暴露的范围，并为后续通知和整改提供事实依据。

威胁排序可以先用影响和发生可能性作定性判断，标为高、中、低，并记录依据。管理凭据泄露可能导致修改部署和批量读取数据，影响通常较高；是否容易发生则取决于入口暴露、凭据使用方式和检测能力。不要把缺乏依据的分数当成精确概率。对高影响且容易到达的路径先补关键控制，再明确剩余风险由谁接受、何时复查。接受风险必须写明原因，不能只把它从清单里删除。

下面的交互把同一条越权查询威胁从数据流推进到验收证据。观察每步新增的内容：资产说明损失是什么，边界指出检查应发生在哪里，控制目标规定必须成立的条件，证据则证明条件在允许与拒绝场景下都成立。这样得到的清单可以进入设计评审和开发任务，也能帮助测试人员设计真正有业务意义的检查。

4 动手：完成一次关键资产威胁清单

这次练习只使用虚构订单和测试身份，不需要扫描真实站点，也不需要访问生产数据。准备 2 个顾客身份 A、B，1 个只读客服身份和 1 个运维身份。画出顾客入口、管理入口、订单 API、订单数据库与支付服务，并标出数据流方向。把“接口接收到某种输入后，谁判断它是否有权改变状态”写在对应连线上，这能尽早发现职责遗漏。

先选 3 项关键资产：订单归属与收货信息、订单金额与支付状态、服务与部署凭据。为每项资产写正常使用路径。顾客 A 读取自己的订单；支付通知使对应订单进入已支付状态；运维使用个人身份完成受控发布。正常路径是判断异常的参照，缺少它时，团队容易把所有失败请求都视为安全成功，却忘记合法业务也需要完成。

接着为每项资产写 1 条具体威胁。顾客 A 替换编号读取顾客 B 的订单；外部请求伪造支付成功通知；泄露的运维凭据被用于发布恶意版本。分别写出入口、前提和业务后果。不要把“用户输入错误”和“越权读取”混在同一条记录里，因为它们需要不同控制。前者可能主要靠格式校验，后者需要身份与资源之间的授权判断。

对支付通知，不能只检查“成功”字段。应验证约定的来源证明，并核对本地订单、预期金额和允许的状态变化。重复通知可能是正常重试，因此同一支付事件重复到达时，不应重复扣减库存或重复发放权益。来源验证、业务关联和重复处理分别解决不同问题。协议内部算法不在本练习展开，但接口契约必须说明验证失败、重试和人工对账如何处理。

把每条控制再补上故障行为。例如身份信息无法验证时，不返回受保护订单；支付通知无法核实时，不先把订单标成已支付，而是保留待核验状态并进入重试或对账流程。记录这些选择对顾客体验和客服工作量的影响。安全方案需要业务方共同确认状态语义，否则实现人员可能为了减少报错而放宽关键检查，形成与设计相反的实际行为。

最后进行桌面评审：由另 1 名评审者沿数据流逐条提问，指出控制发生的位置、控制失败时的结果以及证据存放位置。输出应包含资产、威胁、控制目标、实现措施、验收证据、负责人和剩余风险。清单允许存在待办，但每项待办要有期限和临时措施。练习的完成标志不是表格填满，而是团队能够解释最重要的攻击路径在哪里被阻断。

5 可用性与控制强度取舍

安全控制本身也会消耗资源并形成依赖。身份校验增加请求处理工作，集中式授权服务可能成为关键路径，审计写入可能受到存储故障影响，严格限流可能误伤促销高峰中的正常顾客。架构取舍不是简单决定安全重要还是可用性重要，而是按业务动作区分风险，规定故障时哪些请求继续、哪些进入待处理、哪些必须拒绝。

以身份服务短时不可达为例，直接跳过验证会把依赖故障变成授权失效。某些架构可以在事先定义的有效期和撤销要求下，本地验证已有凭据；若缺少验证条件，则应拒绝受保护访问。能否缓存授权结果还取决于权限变更的时效要求。普通查询与高权限退款可以采用不同有效期，但每种做法都必须说明最大陈旧窗口，以及紧急撤权能否满足业务要求。

审计故障同样需要分类。普通订单读取日志可以按设计暂存并告警，但要限制缓冲区、说明丢失条件；高风险管理操作若必须具有可靠审计证据，则应在无法保证记录时停止或转入受控流程。不能让每次日志写入都无界等待，也不能静默丢弃所有记录。选择依赖于动作影响和恢复能力，方案必须把“什么情况下可以继续”写清楚。

限流展示了控制强度与业务体验的关系。阈值过宽，异常流量更容易消耗 API、数据库和外部调用额度；阈值过紧，合法顾客可能无法提交订单。按身份、来源和接口成本设置不同限制，比所有接口共用 1 个固定阈值更贴近业务。限流也不等于完整容量保障，还需要容量规划、超时、重试约束与故障隔离。重试没有上限时，拒绝后的重复请求反而可能放大拥塞。

下面的滑块使用虚构的促销请求分布，展示不同阈值下合法流量和异常流量被接纳的变化。它仅用于理解权衡，不能据此预测生产安全效果。观察时要同时看正常请求通过率和异常请求放行量，再讨论现有身份信息是否足以做更细粒度限制。把阈值调到最低并不代表方案最好，因为无法履约本身也会造成损失。

成本评估至少包括建设、持续运行和事件处置。资源授权开发与测试需要工时，审计存储需要容量和保留策略，权限复核需要责任人，演练需要值班参与。高可用方面，关键身份与密钥依赖要有适当冗余，备用路径要经过验证，切换时仍要保持权限约束。不能把绕过认证的备用入口作为高可用设计。记录这些成本后，再用架构决策记录说明选择、备选方案和重新评估条件。

6 常见坑：合规清单代替威胁模型

合规清单适合确认要求有没有被考虑，却不能自动说明具体系统的主要风险已经覆盖。“开启传输加密”可以得到肯定回答，但它无法证明顾客不能读取别人的订单；“保留审计日志”也不能证明记录中包含操作身份和对象，更不能证明有人会处理告警。合规要求是输入，威胁模型把要求与本系统的资产、路径和业务后果连接起来。

常见问题是控制名称写得很多，责任边界却不明确。例如网络团队认为应用负责授权，应用团队认为网关已完成全部检查，最终没有任何位置验证订单归属。解决方法是把控制目标分配到明确组件，并指定负责人。共享责任需要明确接口契约和验收结果，不能只写“由相关团队共同保障”。跨团队控制尤其要验证失败时谁能发现、谁能阻断、谁能恢复。

另一个问题是把“内网”当成统一可信区。订单 API 被入侵后，如果能够读取全部数据、修改权限并访问部署系统，单点失陷就容易扩展。应分别限制服务能访问的资源和动作，使订单读取权限无法自然升级为部署权限。网络分区、服务身份和数据权限各有作用，简单把所有组件放到同一私有网络，不会自动产生这些约束。

还有团队只验证错误请求被拒绝，却不验证合法请求和业务异常。退款接口可能拒绝普通顾客，却错误地允许任何客服退款；支付通知可能拒绝伪造来源，却因为重复通知而多次触发后续动作。验收必须覆盖角色、资源归属、状态和故障条件。测试用例应来自威胁描述与正常路径，这比按控制产品的功能菜单逐项截图更能说明真实效果。

最后要避免“上线时安全，之后默认不变”。新管理接口、临时导出功能、角色调整和依赖迁移都可能改变边界。变更评审需要检查原控制目标是否仍成立，临时权限必须有到期与回收机制。周期性复核可以发现长期漂移，重大变更则要立即更新威胁清单。安全文档应服务于这些决策，过期的合规勾选无法替代持续的责任和证据。

7 案例：管理面暴露导致全站失陷

下面是教学用的复合案例，不对应某家真实企业。订单团队为了便于远程排障，把管理入口接到了公网，并保留了长期使用的共享高权限账号。该入口能修改应用配置、读取运行凭据和触发部署。公网订单 API 本身做了身份验证，但管理面绕过了正常业务路径，成为更直接的攻击入口。问题的起点是部署便利性改变了信任边界，却没有同步调整控制。

攻击者获得泄露的共享凭据后登录管理入口，读取应用运行凭据，再使用这些凭据访问订单数据库。由于运行身份拥有超出业务需要的权限，攻击者进一步修改订单状态，并尝试扩大访问范围。共享账号的审计记录只能说明某个公共身份执行过动作，难以快速定位实际使用者。这里的“全站失陷”指应用部署与订单数据均失去可信保证，不代表每台设备都必然被控制。

攻击链包含多处可阻断位置。管理入口不应无必要地对公网开放；高权限人员应使用独立身份并加强认证；读取运行凭据需要严格限制；服务身份应只拥有必需的数据权限；异常登录、凭据访问与部署变更应能关联告警。任何单项措施都不能保证所有环节无误，但相互独立的约束可以减少同一错误一路扩大影响的机会。

处置时先确认受影响入口、身份、版本和时间范围，再隔离被滥用的访问路径、撤销相关会话与凭据，并从可信构建重新部署。只关闭管理页面不足以恢复，因为已泄露的凭据可能仍可使用；只轮换凭据也不足以证明程序没有被修改。需要核查授权配置、部署记录、订单状态变化及可用审计证据。若记录缺失，应明确调查的不确定范围，不能把“没看到”写成“没发生”。

恢复后要验证正常接单、支付状态同步和受控运维都能完成，并持续观察是否还有旧凭据访问和异常数据操作。改进项应回到架构：管理入口的访问条件是什么，谁能发布，服务能接触哪些数据，管理面故障时如何应急。应急访问需限定身份、时间、权限和审计，并在使用后回收。这样既支持恢复，又避免临时通道长期变成新的公开入口。

8 把控制目标写进安全方案

安全方案应以业务目标开头：保护订单隐私与状态完整性，支持促销接单，允许受控售后与运维。随后用数据流图说明组件、身份、边界和外部依赖，列出最重要的威胁，再给出控制目标、实现位置和验收证据。实现措施可以随技术选择变化，控制目标应保持可理解。例如“任何订单读取都经过资源授权”比“安装某个安全组件”更能约束未来替换方案。

对关键选择写架构决策记录，即 ADR。订单 API 的记录可以描述：为了限制管理凭据泄露的影响，管理入口采用独立访问路径、个人身份和受限发布权限；备选方案是直接复用公网业务入口。选择依据包括攻击面、运维便利性、故障恢复和运行成本。记录还要写不足，例如访问系统故障可能延迟发布，以及经过演练的受控应急路径如何缓解这一影响。

把高可用要求写成故障情境。身份依赖不可用时，哪些已有请求仍能按预定规则验证；审计存储异常时，哪些操作暂停；管理入口所在可用区故障时，谁通过什么受控路径恢复。冗余组件的权限与密钥配置也必须受约束，否则备用环境可能成为薄弱入口。恢复演练既要验证服务能回来，也要验证访问规则和日志在切换后仍然成立。

验收证据应能关联到具体版本、配置和时间。可接受的证据包括角色与资源授权用例结果、凭据撤销演练记录、故障切换记录、告警到处置的关联记录。截图可以辅助说明，但不能独自证明所有路径持续受控。每个重要控制指定负责人，写明例行复核周期与触发复核的变更类型，让文档可以指导后续运营，而不仅用于首次评审。

风险登记则记录控制后仍存在的限制。例如已授权客服仍可能误用可见信息，需要字段最小化和操作追踪；权限缓存存在经过批准的陈旧窗口，需要明确最大期限和紧急撤权方式。风险接受人应是有权承担业务后果的角色。用这些事实讨论预算，团队才能比较增加控制带来的收益、费用和维护负担，避免把安全投入理解成没有边界的功能堆叠。

9 从安全架构走向混合云与多云方案（P20）

当订单系统连接本地库存系统，或在不同云环境部署服务时，资产和业务目标不会自动改变，但边界和责任会增加。顾客订单仍需按归属读取，支付状态仍需可信转换，运维权限仍需可撤销。新的问题是这些规则如何跨环境保持一致，以及不同团队能提供什么证据。P20 将在这个基础上讨论混合云与多云的选择，本章先整理安全交接条件。

首先带走身份映射。环境 A 中的客服角色在环境 B 对应什么权限，服务身份如何被识别，人员离职时是否能在所有环境及时撤权，都需要显式说明。账号名称相同不代表身份相同，角色名称相似也不代表授权范围一致。跨环境连通只解决请求能否到达，不能证明请求代表的身份可信，更不能证明它可以读取目标订单。

其次带走数据流与位置约束。订单主数据、备份、日志和导出结果可能分别落在不同环境，必须逐项说明用途、可访问者、保留规则与删除责任。受保护连接仍需验证对端身份，专用链路也不能替代业务授权。若发生跨环境故障，备用路径是否扩大数据暴露面，应在设计阶段评估，而不是等切换时临时放开所有访问。

最后带走依赖与证据要求。跨环境身份验证、密钥使用、审计汇聚和应急运维都可能受到网络中断影响。方案需要区分本地仍可完成的动作和必须等待远端验证的动作，并说明审计如何在恢复后补齐。进入 P20 时，先比较业务收益与新增复杂度，再决定是否值得跨环境部署。安全边界清楚之后，多环境选择才有可比较的成本、风险与高可用依据。

放进方案里

在零售订单 API 方案中增加安全架构页，开头写明保护订单隐私、金额与状态完整性，并支持促销期间受控接单。附上顾客入口、管理入口、订单服务、数据库及支付服务的数据流图，标注身份来源、信任边界和责任人。说明只收集履约需要的数据，订单系统保存支付结果引用，日志隐藏完整地址与凭据，备份和导出沿用相应保护要求。

列出优先处理的威胁：跨顾客读取订单、伪造支付通知、管理凭据泄露。分别对应服务端资源授权、通知来源与业务关联验证、独立管理访问和最小权限。每项控制都写实现位置、失败行为、责任人与验收证据，包含合法访问成功、越权被拒绝、重复通知不重复执行效果以及凭据撤销后失效。剩余风险写清业务影响、接受人和复查条件。

增加 1 条 ADR，说明为何管理入口采用受限访问与个人身份，比较复用公网入口的成本和风险。预算同时计入开发测试、审计保留、权限复核和值班演练。对身份依赖异常、审计存储故障与可用区切换分别规定处理办法，写明哪些操作暂停、哪些依据已有验证条件继续，避免故障时临时绕过关键授权。

交付时附威胁清单、授权验证结果、撤权和恢复演练记录，并关联版本与日期。由业务负责人确认故障体验和剩余风险，由技术负责人确认实施与运营责任。新管理接口、权限调整或跨环境迁移触发重新评审。进入 P20 时，继续携带这份身份、数据位置、依赖和证据清单，作为比较混合云与多云方案的共同基线。

10 小结：下一步混合云与多云方案（P20）

安全架构把业务损失、系统边界与控制证据连接起来。对订单 API，关键是明确身份与授权的区别，沿数据流识别威胁，把控制映射到预防、发现和恢复，并写清故障行为、成本与责任。合规清单可以提供要求，威胁模型帮助判断这些要求是否真正覆盖业务路径。

自测时用 3 个问题检查方案：已登录顾客为什么仍不能读取其他人的订单？管理入口失陷后，哪些独立约束能限制影响？身份或审计依赖故障时，系统按什么规则继续或暂停？能够指出实现位置和证据，才算完成架构解释。下一课将保持同一订单案例，讨论混合云与多云如何改变边界、成本、风险和高可用选择。