账号与 IAM

1 IAM 回答什么问题：谁能对哪些资源做什么

C13 已经把数据库的职责收束到数据层。现在假设订单服务、对象存储和数据库都已经建好：应用应该能写订单附件，值班人员应该能扩容，但任何能登录账号的人都能删库吗？资源存在、网络可达，只说明操作具备了部分条件。每次资源操作还要回答：请求来自谁，这个身份带着什么权限，权限覆盖哪个资源，以及此刻是否满足限制条件。

IAM 是身份与访问管理。身份让系统识别调用者，权限判定决定调用者能否执行这次操作。它既包括真人在控制台点按钮，也包括程序调用接口。读对象、修改安全组、删除数据库看起来分属不同产品，但都可以整理成“主体、动作、资源、条件”这组信息。AWS IAM、华为 IAM 等名称可以帮助你在控制台定位入口；本课学习的是这组关系，具体动作名与判定细节仍要查所用产品的说明。

把“默认是否开放”写清楚，比说“这个账号很安全”更有用。下面假设刚创建了 1 个普通业务身份，尚未给它附加授权，也没有其他继承或资源侧授权；这里的默认值不适用于具备特殊权限的根身份。

这 5 类动作并不因为“同属订单系统”就自动捆绑。能读配置不意味着能读订单内容，能读审计也不意味着能改资源。操作记录可能包含敏感信息，所以“读审计也是一种权限”。日志产品的使用留到 C19；此处只确认谁有权读取哪些记录。

还要区分账号与账号里的身份。云账号通常是资源归属、管理和账单的边界；用户、角色等身份则在其中承接具体职责。业务人员口中的“给应用 1 个账号”容易混淆这 2 层。更准确的需求是：为订单应用建立独立身份，授予它所需动作，并让账单仍归属于既定的云账号。

验收时不要只问“登录成功了吗”。登录成功说明认证通过，接下来的资源操作仍可能被拒绝。反过来，有些应用从不进入控制台，却持续带着身份调用接口。可以拿同一资源验证 2 次：应用读取自己的订单附件应成功，应用删除数据库应失败。成功与拒绝共同说明边界，单独看到 1 次成功不足以证明授权正确。

2 身份主体：用户、角色与服务身份

用户通常适合承接真人的交互访问。为每位运维人员保留可区分的身份，才能知道谁申请权限、谁发起操作、离职时撤销谁的访问。真人也可以通过企业统一登录接入，再临时扮演角色，并非必须给每人创建本地 IAM 用户。关键是让身份对应明确的人，避免多人共享密码或同一组访问密钥。

角色适合表达职责，如订单应用、生产变更、审计只读。角色通常不靠永久密码登录，而由满足信任条件的主体临时扮演，并获得有期限的会话凭证。角色不是用户的另一个名字：用户回答“这个人是谁”，角色更接近“这次以什么职责行动”。同一位值班人员上午可以使用只读角色查看状态，执行已批准的变更时再切换到运维角色。

扮演角色要过 2 个问题。第 1 个是“谁可以成为这个角色”，由信任关系及相关扮演授权约束；第 2 个是“成为角色后可以做什么”，由角色权限及其他适用边界约束。把外部测试环境误列为可信主体，即使角色权限写得很精细，也可能让不该进入的人拿到权限。只修改权限策略，不能代替检查信任关系。

服务身份、实例角色、函数执行角色等机制，解决的是机器怎样取得身份。应用在受支持的运行环境中启动后，通过平台提供的身份机制获取临时凭证，再调用允许的接口。这样不必把长期 Access Key 写入镜像、代码仓库或启动脚本。不同云的名称与领取方式不同，但目标一致：凭证由运行环境按身份提供，业务代码只使用获准的能力。

CI 也属于机器身份。它可以通过受支持的工作负载身份联合机制换取短期会话，信任条件应绑定明确的项目、流水线或部署环境。假设 1 条测试流水线和 1 条生产流水线共用高权限身份，测试脚本被修改后便可能触及生产资源。把它们拆成 2 个身份，生产角色只信任生产部署入口，才能让环境边界落到实际授权上。

人和机器的生命周期也不同。员工离职时要关闭个人入口、撤销可撤销的会话并处理遗留访问；应用扩容时应让新实例自动取得相同职责，不能靠某位员工手工复制密钥。应用下线时，则要解除工作负载绑定并清理闲置角色，避免留下可被重新利用的入口。平台服务代表你执行任务时也可能使用专门的服务角色，授权前应确认服务真正需要操作的资源。

可以用 1 张身份台账落实这些区别：记录身份所有者、可信入口、用途、可扮演角色和停用条件。不要把密钥值记进台账。若某个身份的所有者写成“大家都在用”，或者用途写成“方便测试”，就还没有解释清楚它为什么应该拥有生产权限。

3 策略直觉：允许、拒绝与作用范围

策略是关于权限的陈述：在哪些资源上，允许或拒绝哪些动作，在什么条件下生效。先用自然语言读懂它，再考虑产品的 JSON 语法。例如：“允许订单应用读取 orders-prod 桶中 app/ 前缀下的对象，要求请求使用 TLS。”这句话包含了动作、资源范围与条件；主体可以由策略绑定位置确定。只写“允许访问订单桶”则没有说清能列举、读取、写入还是删除。

本课采用简化的判定直觉：没有适用允许时拒绝；存在适用允许且没有适用显式拒绝时，才可能通过；显式拒绝通常优先于允许。真实产品还可能叠加组织规则、权限边界、会话策略、资源策略等，不能只截取某 1 条允许就断言必然成功。控制台的策略说明、模拟工具与实际返回共同决定结论。

假设应用有 2 条适用规则：允许读取 app/ 下对象；拒绝读取 app/private/ 下对象。请求 app/2026/order-42.json 命中允许，可以继续判定；请求 app/private/export.csv 同时命中允许与拒绝，应按拒绝处理。再给它添加 1 条读取全桶的允许，也不能用这条允许冲掉适用的显式拒绝。排查时应寻找所有适用规则，而不是只找到最宽的那条。

作用范围可以从 3 个角度理解。账号级规则覆盖某个管理边界内的资源与身份；资源级范围把对象缩小到某个桶、某个前缀或某个实例；条件进一步限定请求环境，如来源网段、是否使用 TLS。它们不是所有产品都支持的固定层级：某些动作只能按较大范围授权，某些资源支持独立的资源策略，条件键也必须对当前动作有效。

数字例子能帮助发现“看起来很窄”的错误。桶内有 10 个业务前缀，应用只需 app/。若授予“全桶读取”，即使只包含 1 个读取动作，也可能覆盖 10 个业务范围。收窄为 app/ 后，再考虑是否需要列举。对象读取与桶级列举往往是不同动作，且可能要求不同资源标识；列举范围还可能需要前缀条件。仅把对象路径复制到所有动作上，可能让本该成功的列举失败。

资源标识也要精确核对。AWS 常用 ARN 标识资源，其他平台有自己的资源路径或标识方式。区域、账号、桶名、实例标识、前缀以及大小写错误，都可能让允许规则不匹配。教学上可以写“订单桶/app/”，落地时必须替换成所用平台认可的表达式，并确认前缀匹配是否包含你以为的子路径。

条件不是装饰。若只允许来自指定出口网段的请求，运维人员换到另一个网络后，即使角色与动作都正确也可能被拒绝。若要求 TLS，则客户端需要实际使用受支持的安全连接。设定条件前要确认业务调用链中的请求属性，不能把“我电脑的地址”误当成“应用经过网关后的来源地址”。检查策略时，动作、资源与条件应放在同一次请求里一起看。

4 最小权限：从业务动作反推授权

最小权限的起点是业务用例。先写“订单 API 要读取已生成的附件”，再转成动作与资源；不要从管理员策略开始删减。业务语言说明目的，权限动作说明实现，资源范围说明边界，验收请求说明怎样证明。每增加 1 项权限，都应该能指回某项业务需求，而不是解释成“也许以后会用”。

以附件读取服务为例，它按数据库保存的完整对象键读取 orders-prod/app/receipts/ 下的文件。当前用例只需要 GetObject，不需要写入、删除，也不需要遍历整个桶。若以后增加按日期搜索附件，应先确认搜索是否由数据库完成；只有确实需要对象列举时，才增加相应动作与范围。界面上出现“对象存储访问”这个类别，不代表应用需要该类别中的全部动作。

建立 1 份可验收的动作清单，可以避免权限讨论停留在形容词上：

注意表中的数据库权限不能全部用云 IAM 策略代替。连接 RDS 类托管数据库时，平台身份可能负责取得连接资格或相关认证令牌，但 SQL 的查询、更新和建表权限仍要由数据库账号、角色及授权机制约束。若平台不支持身份认证，仍要通过适当的凭证管理方式连接业务用户。应用使用业务库权限，不应因此取得云上删除数据库实例的管理权限。

假设业务库有 12 张表，订单 API 需要查询 3 张、更新其中 1 张。需求应写成明确的表与操作，不能直接简化成“整个数据库读写”。当需要事务或迁移时，再分别分析事务所需的数据权限与迁移身份。迁移工具可能需要建表，但平时接收流量的应用不必永久保留建表能力。

运维也要按职责拆分。扩容角色可以调整订单实例和指定安全组，但不包含删除数据库；审计只读角色可以读取授权记录，不修改资源。若变更确实需要删除资源，应走专门受控的高权限路径，不能因为偶尔会用，就让每次常规扩容都带着删除能力。

授权完成后，设计 2 组测试。正向测试验证必需操作，例如读取 receipts/ 下已存在的测试对象；反向测试验证相邻边界，例如读取另一个业务前缀、覆盖历史对象或调用删除数据库接口。危险动作应使用策略模拟、权限检查或隔离测试资源验证，不在生产数据上尝试删除。若正向失败，定位缺失项后逐项补充；若反向成功，停止扩大上线范围并查明多出来的允许来自哪里。

5 临时凭证与长期密钥的取舍

长期 Access Key 通常以访问标识与秘密部分组成，程序持有它就能发起相应请求。秘密一旦被复制进代码、镜像层、构建日志或个人电脑，复制件不会随着原文件删除而消失。它往往持续有效，直到被禁用、删除或受到其他限制。难点不只是换 1 个字符串，而是找出所有使用者、安排切换并确认旧值不再被使用。

临时凭证带有过期时间，通常还包含会话令牌。应用通过实例、容器或函数的身份机制获得临时会话，使用 SDK 或平台推荐组件在有效期内调用并刷新。它仍然是需要保护的秘密，窃取者在可用条件下也可能使用。优势在于会话生命周期有明确边界，而且无需把某个永久秘密随业务镜像分发。

可以用“泄漏面 ≈ 凭证有效期 × 权限广度”建立直觉。这里的乘法是教学模型，不是事故概率公式。假设凭证 A 可用 24 小时，覆盖 20 个动作、10 个资源范围；凭证 B 可用 1 小时，覆盖 2 个动作、1 个资源范围。粗略机会量分别是 4800 与 2 个“动作范围小时”，差距来自时间和范围同时收缩，不能据此推算实际损失金额或安全倍数。

模型也提醒我们：只缩短时间不够。拥有全账号管理权限的 15 分钟会话，仍可能在短时间内造成严重后果；权限很窄但长期有效的密钥，也会留下持续暴露的入口。数据敏感性、条件限制、攻击速度和能否撤销会话都影响真实结果。滑块帮助比较授权选择，不提供“低于某个分数就安全”的结论。

假设应用会话有效期为 60 分钟，SDK 在到期前按平台规则刷新。运维人员把此刻的 3 项凭证值导出到静态环境变量，再复制给另一个进程，并不会得到永久身份。到期后若没有刷新入口，后续请求会失败；若为避免失败而改用长期高权限密钥，则把原本受控的工作负载身份退化成共享秘密。

正确的做法是让工作负载使用适合其运行环境的凭证提供链，并保证刷新所需入口可用。不要在日志打印凭证，也不要把取凭证接口暴露给不可信代码。容器或实例中若存在长期环境变量密钥，SDK 可能优先选择它，导致“已经绑定角色，却仍以旧用户调用”的现象。因此验收必须查看实际调用身份，不能只看实例页面上绑定了哪个角色。

有些外部系统暂时只能使用长期密钥。此时应给它独立、受限的机器身份，明确持有人、存放位置、到期复核与替换流程，并验证旧密钥失效。访问密钥是请求认证材料；用于数据加密的密钥属于另一个管理主题，盘加密与 KMS 的体系分别见 C6、C42，本课不展开其轮换与授权实现。

6 与网络、数据层的分工：IAM 不替代安全组

安全组决定网络流量能否到达相应端口，IAM 决定身份能否执行受其控制的 API 或数据面动作，数据库自身还可能继续判断 SQL 权限。它们是不同位置的门。业务请求要成功，所有适用的门都要通过；其中任意 1 处拒绝，就足以阻断相应步骤，并不需要同时失败。也不能因为某处拒绝，就推断其他边界已经配置正确。

例如订单应用连接数据库，要先有正确的网络路径与端口许可，再完成数据库认证和数据库内授权；采用平台身份认证时还需满足相应身份条件。端口不通时，扩大 IAM 权限不会修复路由或安全组。连接已建立却收到数据库的表权限错误时，放开更多端口也不会补上表的更新权限。排查要依据失败发生的位置选择证据。

另一个常见误解是“数据库端口只对应用开放，所以应用不能删库”。删除云数据库实例通常属于管理 API。应用如果拥有对应管理权限，并能访问管理 API，可能根本不需要连接数据库端口就能请求删除实例。数据库端口的安全组限制，不能代替对管理动作的拒绝或缺省不授权。

反过来，只读 IAM 角色也不保证数据库数据只读。若应用还拿着 1 个有更新权限的数据库用户，且连接路径可达，它仍可能通过数据库协议修改数据。云 API 的只读范围与 SQL 权限必须分别记录。这里沿用 C10 的网络边界与 C13 的数据层职责，不重新设计安全组矩阵，而是把每种身份要通过的门对齐。

数据面也有产品差异：对象读取常可直接受 IAM 或资源策略控制，关系数据库的行表访问则经常由数据库授权控制。不要把“所有数据操作都查同一份 IAM 策略”当成前提。方案中应标明每项动作的最终授权点，让排查人员知道该看云策略、数据库授权，还是两者都要看。

读审计同样要授权，但能读审计不意味着能修改被记录的资源，能改资源也不自动意味着能读审计。日志产品的开启、投递和检索操作归 C19。此处只需要登记审计读取者、允许范围与访问入口，并确认故障处理者能够在授权范围内取得必要证据，避免事故发生后才发现没有人具备读取权限。

7 常见坑：根账号日常登录、通配符权限、把角色当用户永久密钥

根账号或主账号通常掌握特殊管理能力，不适合作为每天查看状态和修改配置的入口。若值班记录只显示“主账号操作”，很难区分具体操作者，也容易让普通操作附带过高权限。日常使用可区分的个人身份，再按职责扮演角色；特殊账号保留给确有需要的管理与恢复场景，保护其认证入口并明确使用责任。

Action:* 加 Resource:* 的问题是同时放大动作与资源。假设某服务涉及 8 类动作、生产有 6 个业务范围，教学上就有 48 个动作与范围组合，而应用实际上只需要其中 2 个。即使当前测试只调用这 2 个，也不能证明其余组合不存在。某些动作确实不支持资源级限制时，要按产品能力采用条件、独立角色和其他适用边界约束，而不是把全量策略当作默认模板。

把角色凭证导出成永久环境变量，是另一个容易误判的做法。角色会话本来有到期时间；复制出来的值既不会自动延长，也不会自动刷新。发生过期故障后，应检查工作负载身份和凭证刷新链，不能直接给角色“补 1 个永久密钥”。角色的可信入口与权限、会话的有效期、程序使用凭证的方式，需要分别理解。

应用与人共用 1 个高权限用户，会把生命周期和责任搅在一起。运维人员离职时不能直接停用它，因为应用仍在使用；应用泄漏密钥时又可能影响所有运维操作。把个人入口、应用身份和 CI 身份拆开后，才能分别停用、收权、追踪。拆分必须落实到实际凭证与绑定关系，只给同一共享密钥起 3 个名字没有效果。

测试策略直接复制到生产也很危险。测试中允许删除临时库，是为了重建环境；生产运行中的应用未必需要这种能力。上线时应按生产用例重新核对动作清单，明确测试与生产资源标识、可信入口和条件。若复制后只改了角色名称，却保留全资源通配符，名称中的“prod”不会提供隔离。

最后要警惕残留授权。你可能已经从应用角色移除读取全桶的策略，但另一份附加策略、用户组授权或资源侧规则仍然放行。修正后应使用同一调用身份重做受控验证，并记录生效时间；部分平台存在权限传播延迟，旧会话是否继续有效也要按产品规则判断。不要把刚修改页面上的截图当成最终权限结果。

8 案例：订单系统的应用角色与运维角色

订单系统使用 1 个对象桶 orders-prod、1 个托管关系数据库和 2 台应用实例。桶内有 app/orders/、app/uploads/ 与 finance/ 这 3 个前缀。应用需要读写前 2 个前缀中的订单文件，通过数据库业务用户查询与更新订单；它不负责财务导出，不负责数据库迁移，也不负责删除数据库实例。先把这些业务事实写出来，角色设计才有依据。

设计 app-role 承接运行时访问，由订单应用实例的工作负载身份取得。它可以在规定前缀执行 GetObject、PutObject，不默认包含 DeleteObject。若应用通过已知对象键读写，初版不授予列举；后续若证明需要列举，再按平台支持方式补充桶级动作与前缀限制。数据库中使用 app_order 业务用户，授予所需表的查询与更新等业务权限，迁移职责独立。

ops-role 承接日常运维变更。值班人员通过个人身份按要求扮演，允许查询目标资源、调整订单实例规格、修改指定安全组；不授予删除数据库。修改安全组本身影响范围较大，即使它是合法职责，也要把目标限制为订单系统资源并保留变更依据。是否需要审批、会话期限与来源条件，由组织的运维流程明确。

audit-reader 承接审计读取。它可以读取订单系统相关的授权记录，不修改应用资源，也不管理应用密钥。它读到的内容及时间范围按平台能力和组织要求限定。C19 再讨论日志产品；这里先保证角色与读取入口明确，必要时能识别谁在什么时间对哪些资源发起过调用。

这张表表达目标边界，“不授予”并不等于已经写入显式拒绝；还要检查其他适用授权是否能补出该能力。对于必须牢固限制的高风险动作，可结合平台支持的权限边界或上层限制实施，但要明确其作用对象，不能凭表格文字假定已经生效。

上线验收分成 6 项。第 1 项，确认应用镜像、配置与启动环境没有控制台用户的长期密钥，调用身份实际为 app-role 会话。第 2 项，用测试对象验证 app/orders/ 的读写成功。第 3 项，验证 finance/ 读取与历史对象删除被拒绝。第 4 项，在隔离环境或模拟器中确认应用角色没有删库能力。第 5 项，值班人员扮演 ops-role 后能对目标实例扩容，而非使用主账号。第 6 项，audit-reader 能取得所需记录，却不能修改目标资源。

假设扩容失败，不能为了赶上线把 app-role 改成管理员。扩容属于 ops-role，先确认执行者是否真的切换到该角色，再检查目标实例与动作是否匹配。同样，应用 SQL 更新失败，也不能直接授予云数据库管理权限。每次故障都沿着原先的职责边界修正，避免修复 1 个操作时顺便开放整条管理路径。

交付时保存身份与角色绑定、策略版本、信任关系和验收结果。后续从 2 台扩容到 6 台应用实例，应复用受控的工作负载身份机制，不分发 6 份个人密钥；新增财务功能则重新评估是否应使用独立角色，而不是因为桶相同就自动放开 finance/。

9 排查案例：AccessDenied、越权成功、密钥泄漏后的收敛

排查前先固定同一次调用的证据：实际调用身份及会话、动作名、资源标识、请求时间与时区、请求标识和错误返回。随后关联当时生效的策略版本、角色信任关系与相关条件。不要收集完整凭证秘密，也不要只凭操作者口述“我用的是应用角色”。环境变量、缓存会话或另一个配置文件，都可能让真实调用身份偏离预期。

路径 A 是 AccessDenied。10:02，订单应用读取 app/orders/2026/42.json 被拒绝。先确认对象存在与目标路径正确，再核对实际调用者为 app-role 会话。策略中允许的是 app/order/，少了末尾的 s，因此动作 GetObject 正确，资源却不匹配。将范围修正为业务要求的 app/orders/ 后，用相同身份读取测试对象验证，再确认 finance/ 仍被拒绝。修复点是资源范围，不是增加所有动作。

若资源正确，继续看缺动作与条件。例如 SDK 在读取前先发起列举，而策略只允许 GetObject；应先判断业务是否真的需要列举，再决定修改程序还是增加受限列举权限。又如角色要求指定来源网段，请求经过出口变更后已不符合条件；应核实真实出口与预期边界，不能直接删掉所有条件。若存在适用显式拒绝，再加允许通常也无法解决。

路径 B 是越权成功。10:20，用 app-role 读取 finance/report.csv 竟然成功，虽然目标策略只写了 app/。先核实请求不是被缓存的旧结果，再查看实际身份和全部适用授权。调查发现 app-role 还附着了测试遗留的全桶读取策略。移除这条多余允许，检查资源侧授权及其他附加规则，然后重做合法读取与越界读取。若实际身份却是共享管理员用户，则应优先修正凭证来源与工作负载绑定。

越权排查也包括信任关系。权限内容符合设计，但某个测试流水线仍能扮演生产 app-role，同样属于边界失守。这里该收紧的是“谁能取得角色”，并评估已经签发的会话，而不是随意删除应用必需的 GetObject。保存异常会话、策略版本与信任变更的时间窗，才能区分配置错误、旧会话残留和新的错误绑定。

路径 C 是密钥泄漏。11:00 发现构建输出中出现 1 组长期应用密钥。先停止进一步传播并禁用受影响密钥，确认依赖服务的替代身份入口；同时收紧相关身份权限与可信入口。只删除日志中的字符串不能使复制件失效，只生成新密钥而保留旧密钥有效，也没有完成止损。必要的业务连续性安排应使用独立、受限的替代身份，不把已知泄漏凭证重新启用。

随后替换仍有必要使用的凭证，并优先迁移到工作负载临时身份。检查泄漏开始至禁用完成的时间窗，确认是否有异常调用、权限修改或新增身份。长期源密钥被禁用后，由它此前取得的临时会话是否仍可用，需依平台规则核实，必要时采用平台支持的会话撤销或限制措施。修复凭证来源后，再清理仓库历史、构建产物及其他复制位置。

证据追踪需要读取权限。若响应人员无法取得相关记录，应使用既定的审计读取角色协作取证，日志产品操作见 C19。没有查到记录不能直接等同于没有发生调用，还要确认可见范围与记录覆盖。最终交付应写明：受影响身份、暴露时间窗、停用或撤销结果、策略与信任关系修订、合法请求成功和越权请求失败的验证。AccessDenied 的目标是补足必要能力，越权与泄漏的目标是收敛暴露；不能把 3 条路径都处理成“先给管理员再说”。

放进方案里

在订单系统方案中增加身份清单，把人、应用和 CI 分开列出。每项记录所有者、用途、认证或可信入口、关联角色、停用条件与责任人；凭证秘密不进入文档。真人通过个人身份进入，运维变更通过扮演角色完成，根账号或主账号不作为日常入口。应用采用工作负载身份，CI 的生产入口与测试入口分别约束。

附上角色与权限边界表，至少列出 app-role、ops-role、audit-reader。按业务动作写出允许的动作、精确资源、必要条件和禁止跨越的范围，并注明这些限制由哪项机制落实。订单应用仅访问规定对象前缀，数据库业务用户仅有目标表所需权限；运维可以按职责扩容与修改指定安全组，不因方便而获得删库权限。

写明临时凭证取得与刷新方式、会话有效期选择、运行环境绑定以及实际调用身份的验收方法。确需长期密钥的依赖单列例外，注明保存与替换责任、停用方法及迁移计划。检查镜像、流水线和环境变量中的旧凭证，避免它们覆盖已经配置的角色身份。

把边界落实到验收：列出必需操作成功、其他前缀访问失败、应用删库权限检查失败、运维扮演角色后变更成功等结果。危险动作使用模拟或隔离资源验证，并保存策略版本、信任关系与测试时间。说明安全组负责网络到达，IAM 负责适用接口的身份授权，数据库负责其内部数据权限，任何单层检查都不能代替其他层。

最后登记审计读取角色、授权范围和取证负责人，产品操作指向 C19；加密密钥体系指向 C42。密钥泄漏处置应能找到停用入口、替代身份与会话收敛办法。让接手人员从方案中回答“谁能对哪些资源做什么，以及怎样证明”，而不必依赖某位管理员的记忆。

10 小结：身份边界就绪，下一步看清账单（C16）

IAM 把身份、动作、资源与条件连起来。按业务清单授予最小权限，让人和机器各有生命周期，用临时会话缩短凭证暴露窗口，再用允许与拒绝的实际结果验收边界。网络、IAM 与数据库授权各守自己的门。

当你能说明谁有权创建、扩容和删除资源，下一步就能追问这些动作带来多少费用。C16 将进入计费与成本入门，把资源使用与账单联系起来。