安全架构

1 安全架构要覆盖什么

把订单 API 部署到云上之后，团队很容易先问：入口有没有防火墙，数据库有没有加密？这些问题有用，但安全架构要回答更完整的问题：哪些东西值得保护，谁可以对它做什么，攻击或误操作沿什么路径造成损失，控制失效后怎样发现和恢复。它把部署、身份、网络、数据与可观测性连接起来，使安全成为服务设计的一部分。

本课使用这样一个服务：顾客通过手机提交订单，请求经过公网入口到达应用，应用写入订单数据库，并把收据保存到对象存储；开发者通过持续集成流水线发布应用，值班人员查看日志。持续集成通常简称 CI，它负责从代码生成可部署产物。顾客请求与流水线发布虽然都与这个服务有关，却不应拥有相同权限，也不应共享相同凭据。

先列出保护对象。订单记录需要防止未经授权的读取和修改；支付状态需要保持准确；应用要在合理时间内响应；部署配置和访问策略需要防止被偷偷改变；操作记录要能帮助追溯事故。这里分别涉及机密性、完整性、可用性与可追溯性。对订单服务来说，泄漏地址和重复扣减库存都是损失，安全架构不能只关注“数据有没有被下载”。

再列出参与者。顾客、客服、开发者、值班人员、流水线和应用进程都是主体，其中有些是人，有些是工作负载。主体通过凭据证明身份，再由授权规则决定允许的动作。识别主体不等于授权主体：能够登录后台的客服，也未必可以导出全部订单。相反，应用即使没有人工登录界面，也需要明确身份和受限权限。

安全范围还包括责任归属。云平台可能维护底层设施，团队仍然要决定数据库是否公开、应用使用哪个身份、备份能否恢复、谁能修改日志设置。使用托管服务会改变工作分工，却不会消除配置责任。画架构时应把团队负责的控制和依赖平台提供的能力都标出来，并为每项关键决定指定负责人。

本课的起点不是购买更多安全产品，而是解释正常行为和损失路径。先写出“订单应用只读取自己的配置，只访问订单库，只写收据目录”，再检查技术设置能否落实这些限制。如果连正常行为都没有定义，告警再多，也很难判断哪次访问值得调查。清晰的允许范围，是权限设计、网络设计和事件响应共同的基础。

2 控制面、数据面与身份面

控制面负责创建和改变资源，例如部署应用、修改安全组、调整数据库参数、授予角色以及关闭日志。数据面承载服务实际处理的业务，例如提交订单、查询订单记录和写入收据。身份面关注主体是谁、如何取得凭据、如何获得权限，以及身份何时失效。这是理解架构的 3 个视角，不一定对应 3 套物理系统。

区分它们的价值在于识别权限后果。订单应用需要写订单，并不意味着它需要修改数据库的公开访问设置。流水线需要更新应用版本，也不意味着它需要读取顾客地址。某个角色即使没有数据库查询权限，如果能够修改应用运行身份，仍可能间接获得查询能力。因此，检查权限时既要看当前能操作什么，也要看它能否改变其他主体的权限或运行环境。

沿着正常请求走 1 次：顾客在入口提交有效凭证，应用确认顾客身份，检查该顾客是否有权访问目标订单，再使用应用自己的工作负载身份连接数据库。数据库看到的通常是应用身份，未必直接看到顾客身份。因此，云资源授权无法自动替代应用内的订单归属检查。网络允许连接、身份验证成功和业务授权通过，是不同条件。

再沿着发布过程走 1 次：开发者提交代码，流水线在满足发布条件后取得部署身份，把固定产物部署到指定环境。部署身份应限制目标资源、允许动作与有效时间。测试环境身份不应自然延伸到生产环境，生产应用身份也不应回流到构建任务。把环境与任务分开，可以缩小误配置和凭据泄漏造成的影响范围。

短期凭据可以减少泄漏后长期有效的风险，但“短期”不代表权限合理。有效期只有 15 分钟的管理员凭据，仍可能在这段时间内造成重大损失。入门阶段先把握 3 个问题：凭据如何签发，使用时允许什么，撤销后如何确认失效。至于令牌协议和签名验证的内部过程，可以在身份专题中继续学习。

观测也要沿这些视角安排。控制面记录谁修改了部署和策略，数据面记录请求结果与敏感操作，身份相关记录反映登录、凭据签发和授权变化。不同记录通过时间、主体标识和请求标识建立关联。它们的用途是支持具体判断，例如“这次异常导出之前，应用角色是否被扩大”，而不只是留下一份很大的日志文件。

3 纵深防御与信任边界

信任边界是信任条件发生变化的位置，例如公网进入应用网络、顾客身份进入后台业务、构建环境进入生产环境、应用访问数据存储。边界不只画在网段之间，也可能存在于同一进程处理的不同租户请求之间。画出边界后，要说明跨越它需要满足什么条件，以及检查由哪个组件执行。

纵深防御意味着为重要损失路径安排相互补充的控制。入口限制异常流量，应用检查订单归属，数据库身份限制可访问范围，备份支持恢复，告警帮助发现异常。这些控制分别降低不同风险，不能简单理解为把相同防火墙重复放置多次。若所有控制都由同一个高权限身份随意关闭，它们之间的独立性也很有限。

以“攻击者读取大量订单”为例，入口认证可能挡住匿名访问，但无法保证已登录账号不会被盗。应用授权限制账号访问自己的订单，数据库权限限制应用只访问必要资源，异常读取告警帮助发现失控行为。即使请求来自允许的网络，也仍需身份与业务授权。每道控制都应有清晰目标，不要把任何单项控制描述为绝对保障。

最小权限是只授予完成任务所需的动作、资源与条件。可以从动作看：查询和修改是否需要分开；从资源看：测试库和生产库是否区分；从条件看：是否只允许特定流水线或受控会话使用。开始时可以用容易维护的角色表达职责，再依据实际需要细化。过度细碎而无人维护的规则，也可能促使团队绕过正常流程。

默认拒绝表示未明确允许的操作不应自然获得许可。但落实默认拒绝之前，要梳理合法依赖，否则可能把正常发布、健康检查和恢复通道一起阻断。一个可用的设计需要写出例外流程：谁能申请临时权限，范围多大，何时到期，谁复核使用记录。紧急通道也属于架构，不能靠事故发生时临时寻找共享管理员密码。

数据控制需要覆盖传输、存储和恢复。传输加密降低链路被窃听的风险，存储加密保护特定存储介质风险，访问授权决定谁能正常读取明文。若攻击者已经取得合法读取身份，存储加密通常不会阻止这次读取。备份则必须验证恢复能力，并考虑备份是否会被同一受损身份删除，否则它可能与生产数据同时失守。

纵深防御最终要接受故障假设：入口规则配置错了怎么办，应用身份被窃取怎么办，日志投递中断怎么办。对每种假设，至少说明剩余限制、可见信号与恢复动作。安全架构的可信度来自这些可解释的退路。它并不承诺每道控制永不失效，而是让单处失效不轻易演变成整个服务失控。

4 动手：画一张威胁与控制矩阵

现在把图转成可讨论的表。准备订单服务的简图，标出入口、应用、订单库、收据存储、流水线与日志存储，并在箭头上写明动作和所用身份。随后选择重要资产，写出可能发生的坏结果。“数据库不安全”太宽泛，“流水线凭据泄漏后可导出生产订单”才足以指导控制设计。

威胁描述可以按“主体或起点—动作—目标—后果”组织。起点既可以是外部攻击者，也可以是误操作、受损工作负载或配置错误。不要把威胁等同于某个产品缺失。没有购买特定工具并不自动构成威胁；未经授权的主体能修改部署配置，才是需要解释和处理的问题。

实际动手时，先挑 3 条最影响业务的路径，逐行补齐。每行至少包含预防或限制、检测、响应或恢复，以及可观察证据。若某条路径只能写出“加强管理”，就继续追问具体由谁执行、在哪个入口生效、失败时看到什么。若无法给出验证方法，这项控制通常还没有落实到可验收的程度。

矩阵需要与架构图互相核对。表里写“应用无数据库删除权限”，图上就应该能找到应用身份和数据库之间的授权关系；表里写“日志独立留存”，图上就应该能看到日志去向与管理身份。若同一管理员可以同时修改生产配置、关闭记录并删除历史日志，应如实记录这种共同失效风险，而不是只画出 3 个存储图标。

验证应在获准的测试范围内进行。使用测试身份检查允许动作能否成功，禁止动作是否确实被拒绝，并观察记录是否到达预期位置。不要为证明风险而下载真实顾客数据。证据可以是脱敏的拒绝事件、策略评审记录、恢复演练结果与配置快照。测试通过只证明选定条件下的行为，环境变化后还需要重新判断。

矩阵最后加上负责人、完成时间和剩余风险。风险不必都在本次上线前消除，但接受它需要明确原因和复查条件。例如暂时保留人工审批发布，原因是发布频率较低；当发布频率增加或服务接入敏感数据时重新评估。这样矩阵才会随着服务变化更新，而不是在评审结束后变成无人查看的附件。

5 便利与强制控制取舍

安全控制会影响开发速度、排障体验与运行成本。共享管理员凭据看似方便，但难以区分操作者，也难以只撤销某个人的访问。每次只读查询都要求多人审批，虽然增加手续，却可能拖慢正常排障。合理取舍要围绕具体动作的后果，而不是把所有操作都套进同一流程。

可以把操作分成普通读取、敏感读取、生产修改和权限管理等类别。普通指标查看可通过常规角色提供；批量导出订单需要更明确的范围和记录；修改生产身份策略可能需要独立复核。分类不是为了制造永久等级，而是让控制强度与数据敏感性、影响范围和可恢复性相匹配。能立即回退的配置与无法收回的数据导出，后果并不相同。

便利还可以通过自动化获得。预先定义受限的部署角色、可复用的网络配置和默认日志设置，能够减少每次发布时的人工选择。自动化必须有明确边界：执行流水线的身份不能因为负责部署，就顺便获得组织内全部资源权限。把安全默认值做进正常路径，往往比事后反复提醒更容易持续执行。

强制控制的价值是让要求不依赖每个人都记住。例如禁止普通部署角色公开数据存储，能直接阻止一类危险配置；只在文档里写“请勿公开”，则依赖操作者阅读和遵守。但强制规则也需要测试、错误提示与例外流程，否则团队可能为了完成任务而寻找绕过方式。控制是否可执行、可解释，同样影响它的实际效果。

下面的滑块比较同一操作下不同控制强度的示意结果。数值只用于理解方向，不能作为真实风险概率或采购依据。拖动时观察访问前提、操作摩擦、权限持续时间与剩余风险如何变化。即使强度提高，也保留业务授权、日志和恢复需求；任何滑块位置都不意味着服务已经绝对安全。

选择时还要考虑紧急情况。值班人员可以通过实名身份申请短期生产权限，说明事件编号，限定目标并记录操作；权限到期后自动收回，再由负责人复核。若撤销依赖某个人记得处理，临时授权就可能长期存在。紧急通道要定期演练，确保平时受限制，事故时又确实能用。

取舍应留下可复查的理由。例如“订单导出仅允许受控任务执行，任务限定字段和时间范围，因为导出后的数据难以收回”。这比“为了安全增加审批”更具体。记录控制的目的后，团队才能判断未来的替代方案是否仍满足目标，也能发现已经失去业务依据的繁琐步骤。

6 常见坑：边界安全代替身份

最常见的误解是“数据库没有公网地址，所以数据库安全”。私有网络减少了直接暴露，但应用仍然需要连接数据库；应用被攻陷后，攻击者可能沿现有连接访问数据。如果应用身份拥有全部表的读写与管理权限，网络隔离并不会自动缩小这部分权限。边界限制与身份授权解决的是不同问题，需要同时存在。

另一个误解是“来自公司网络的请求都可信”。公司网络中可能存在被盗设备、受损构建任务和配置错误的代理。来源位置可以成为访问条件，却不应替代具体主体。审计记录若只有共享出口地址，就难以确认究竟是谁、哪个任务、哪个应用版本发起了操作。实名人员身份和独立工作负载身份有助于保留这种区分。

还有一种情况更隐蔽：应用已验证顾客登录，却直接使用请求里的订单标识查询并返回结果。攻击者只需更换标识，就可能读取其他顾客的订单。这不是继续增加安全组规则就能修复的问题。必须在应用内检查订单与顾客的关系，并对查询、修改、取消和导出等入口一致执行。

“已经加密”也常被误用为完整结论。存储加密不能替代授权，传输加密不能确认业务操作合理，密钥由谁使用、谁能修改使用权限仍然重要。入门阶段不必深入密码算法内部，但应能说明加密保护哪个环节、不能阻止哪些合法接口上的滥用，并把密钥管理权限纳入控制面审查。

日志同样存在误区。收集了应用日志，不代表能追踪身份策略变更；收集了控制面事件，也未必知道某个订单是否被越权读取。把完整令牌、顾客地址或请求正文直接写入日志，还可能创造新的敏感数据副本。应按调查需要选择字段，限制访问与保留时间，并对日志投递失败设置可见信号。

最后，不要把“没有告警”理解为“没有事件”。可能是控制生效，也可能是日志未开启、时间不同步、规则覆盖不足或投递链路中断。验证应包含正向信号：用无害的测试操作产生已知事件，确认它被记录、关联并送达负责人。可观测性只有进入处理流程，才能帮助缩短发现与处置时间。

7 案例：CI 密钥泄漏横向扩散

某团队把长期部署密钥存入 CI 变量，发布脚本意外把它输出到构建日志。日志可被较多协作者查看，密钥随后被未授权使用。泄漏本身只是起点；真正决定损失范围的是密钥对应的角色。这个角色为了“以后方便”，同时拥有生产部署、身份策略修改、数据存储读取和日志设置权限。

攻击者先使用密钥查询可访问资源，再修改应用配置，使受控代码以生产应用身份运行。该身份能读取订单库并访问收据存储，于是攻击路径从构建环境跨入生产业务数据。这里的横向扩散是访问范围从原本的发布任务延伸到其他资源与身份，并不要求每一步都出现新的网络连接。

随后攻击者尝试关闭部分记录并创建额外凭据。若团队只撤销泄漏密钥，新增凭据和已部署的异常版本仍可能继续发挥作用。因此，“密钥已更换”不足以证明事件结束。处置范围应根据它曾经拥有的能力和可见操作确定，同时检查权限变化、部署变化、其他凭据与异常数据访问。

先限制继续发生的损失：停用受损凭据，必要时暂停相关发布路径，隔离可疑工作负载，并保存调查所需记录。撤销在途会话或已签发凭据的效果取决于身份系统与服务行为，需要实际确认。暂停流水线可能影响正常修复，因此应准备独立、受控的恢复通道，让处置人员不必重新使用受损身份。

再建立时间线：密钥何时可能暴露，哪些主体能够看到日志，首次异常调用是什么，之后修改了哪些角色和部署，哪些数据可能被访问。控制面事件、身份记录、应用版本和数据访问记录各自提供部分证据。缺少某类记录时，应明确调查盲区，不能把无法证明发生的数据访问直接当成没有发生。

恢复时撤销异常授权与新增凭据，重新部署可信产物，轮换可能暴露的其他秘密，并验证应用与审计链路。可信产物需要能追溯到受控源代码和构建过程；若构建环境也受损，只回退应用版本可能不够。恢复后继续观察异常身份活动和访问模式，确认控制确实重新生效。

预防改进应对应事故路径。减少日志接触秘密的机会，限制日志查看范围；让流水线按任务取得短期部署凭据；收窄部署角色，使它不能修改身份策略、读取订单或关闭审计；限制应用身份的数据范围。秘密扫描可以帮助发现部分泄漏，但不能替代这些权限边界。每项改进都应回到矩阵中，写明验证证据和负责人。

8 把安全架构写进基线方案

基线是团队为一类服务规定的最低可接受状态。它需要足够明确，让不同开发者部署出的服务仍满足共同要求。订单 API 的基线可以覆盖环境隔离、人员与工作负载身份、入口与出站路径、数据访问、备份恢复、变更记录和异常处置。基线不是把全部最佳实践塞进清单，而是选出当前服务必须持续满足的条件。

每项基线最好同时写要求、实现位置、责任人与验收方式。例如“应用只能访问指定订单库”是要求，应用角色与数据库授权是实现位置，服务负责人承担维护责任，使用测试身份验证其他数据库访问被拒绝是验收方式。只写“遵循最小权限”，不同评审者可能得到完全不同的结论。

部署基线应明确产物来源、发布身份和回退方式。身份基线应区分日常人员访问、流水线部署与应用运行，并定义离职、任务结束和异常情况的撤销流程。网络基线应说明哪些入口公开，哪些连接被允许，以及必要的外部依赖。数据基线则应列出敏感字段、使用目的、备份要求与删除责任。

可观测性基线要写到事件类别与处理归属。例如权限扩大、生产部署、公开访问策略变化、敏感导出和日志中断应有相应记录或信号。告警必须有接收人和初步处理动作，避免把“通知已发送”当成事件已处理。日志保存期限与访问范围应根据业务和适用要求确定，不能为了方便永久保存所有原始数据。

基线还需要管理例外。某个遗留组件暂时依赖长期密钥时，应记录密钥保管、可用范围、轮换方式、补偿控制与到期复查时间。例外应绑定明确资源和负责人，不能变成所有服务都可套用的豁免。到期时重新判断风险和迁移进展，才能避免临时安排逐渐成为无人解释的默认配置。

最后，把基线放进变更过程。上线前检查关键条件，运行中检查配置偏离，发生事件后更新威胁与控制矩阵。自动检查适合验证明确规则，例如是否公开存储、是否开启指定日志；人工评审适合判断业务授权、职责分离与例外合理性。检查通过不等于风险消失，但能提供持续、可比较的证据。

9 从安全架构走向合规与治理（C59）

安全架构回答“怎样让系统按预期受到保护”，合规关注适用要求及其证据，治理关注谁有权决定、谁承担责任、如何持续监督。它们彼此关联，但不能互相替代。有一张合规检查表，不代表订单归属检查一定正确；有合理的技术设计，也不代表团队已经保存了要求的审批和复查记录。

进入 C59 前，可以先建立从要求到证据的连接。例如业务要求限制订单数据导出，架构将导出交给受限任务执行，权限配置限制任务身份，应用记录导出范围，负责人定期复查授权。这样外部要求能够落到具体控制，控制又能产生可检查证据。不要从“需要证明安全”直接跳到收集大量截图。

治理还需要处理跨团队边界。平台团队维护公共网络和日志能力，服务团队维护业务授权，身份管理人员负责人员生命周期，数据负责人判断敏感字段的使用范围。职责可以分配给不同团队，但每项关键控制应有人负责确认其有效性。否则，所有人都可能认为问题属于别人，最终无人处理告警或更新例外。

本课留下的架构图、威胁与控制矩阵、基线及例外记录，就是后续治理工作的输入。保持它们与实际资源一致，比追求复杂格式更重要。当服务新增合作方、批量导出或跨环境访问时，先更新路径和信任边界，再判断原有控制是否足够。C59 将在这些技术事实之上，进一步讨论规则、责任与持续监督。

放进方案里

订单 API 的安全目标是保护顾客信息、订单状态和服务可用性，并使生产变更可追溯。保护范围包括公网入口、应用、订单数据库、收据存储、CI 发布路径与日志链路。服务负责人维护威胁与控制矩阵；涉及新数据、新身份或新增访问路径的变更，需要同步更新架构与风险记录。

身份设计区分顾客、运维人员、流水线和应用。顾客访问订单时执行业务归属检查；人员使用实名身份；流水线取得限定目标的短期部署权限；应用仅获必要数据权限。部署角色不能修改身份策略或关闭日志。紧急访问限定资源、记录原因并设置到期时间，由指定负责人复核。

网络仅开放业务必需入口，应用与数据存储之间按实际依赖允许连接。私有网络与身份授权共同限制访问。敏感数据在传输和存储环节采用适当加密，日志避免记录完整凭据和不必要的个人信息。备份管理与生产删除权限分离，并通过隔离环境中的恢复演练验证可用性。

记录生产部署、权限变化、存储访问策略变化、敏感导出与日志中断，并明确告警接收人。发现 CI 凭据泄漏时，停用受损凭据、限制相关发布路径、保留证据，检查新增授权、异常部署及潜在数据访问，随后恢复可信产物并验证撤销效果。

上线验收覆盖合法访问成功、越权访问失败、部署权限受限、关键事件可见及备份可恢复。每项验收保存脱敏证据和负责人。暂未满足基线的事项记录影响范围、补偿控制与复查期限；验收结论仅覆盖已检查条件，配置或业务变化后重新评估。

10 小结：下一步合规与治理（C59）

安全架构把资产、主体、访问路径、信任边界、控制与证据连接起来。控制面改变资源，数据面处理业务，身份面决定主体与权限；网络边界、业务授权、数据保护和恢复能力需要配合。威胁与控制矩阵让设计可以讨论，基线让要求能够持续执行。

继续学习前，尝试回答：为什么私有数据库仍需要受限应用身份？为什么撤销泄漏密钥之后还要检查部署与授权变化？为什么“已开启日志”还不足以证明事件可追溯？如果能结合订单服务解释这些问题，就可以带着本课的图、矩阵和证据要求进入 C59，讨论如何以合规与治理持续维护这些决定。