Ramp 按团队拆分 AWS 角色，随后将生产访问权限改为临时且需申请

Ramp 的员工规模从不足 100 人增长到 600 多人，但后端工程访问权限仍依赖 3 个 AWS 角色：Junior-Engineers、Engineers 和 Admins。每有新的资源访问请求，基础设施团队就得手动编辑 IAM 策略，这造成了两个长期问题：高级工程师积累的常设生产访问权限远超其实际工作所需，放大了任何一次失误或账户被攻破的影响范围；而初级工程师则不得不把日常查询转交给高级工程师处理，耗费了后者的时间。

团队的修复方案分为两层。第一层是细粒度访问控制：他们用 20 多个 AWS SSO 组取代了原来的 3 个角色，每个工程团队对应一个组，每个组由一个 Terraform 模块（`engineers_X.tf`）定义，精确列出该团队可以访问哪些 CI/CD 流水线、Lambda 函数、ECS 容器、S3 路径和密钥。这让归属关系变得清晰可读——工程师可以查看自己团队的文件来了解自己的权限，并通过拉取请求申请变更，而无需提交基础设施工单。

第二层是即时（JIT）访问：他们为每个团队角色创建了一个对应的提权生产角色，且不设常设成员资格。借助 Ramp 已部署用于应用配置的 ConductorOne，符合条件的工程师可以申请生产角色；申请本团队角色会自动批准，申请其他团队角色则会转交给该团队的技术负责人审批，授权在选定的时间窗口后过期。他们先在一个团队试点，迭代改进后在全 AWS 范围内部署，并将申请流程整合进工程师现有的 CLI，这样工程师无需离开终端。

结果收紧了安全态势——缩小了常设访问的覆盖面，并将每一次生产操作与明确的理由绑定——同时将申请到获得访问的延迟保持在 10 秒以内，因此安全性的提升并未重新引入原先基于工单的系统所带来的摩擦。

让每个生产角色都成为工程师必须申请的限时超集，而非常设授权

在自动化访问之前先按团队拆分角色，为自动批准（本团队）和路由审批（其他团队的所有者）创造了自然的单元——JIT 需要一张归属关系图来路由请求。

让生产角色成为非生产团队角色的超集，意味着移除常设访问权限并不会改变工程师日常已经能做的事情——只是增加了一个申请步骤。

自动批准同团队请求、将跨团队请求转交给技术负责人，使审批摩擦与实际风险相匹配：自己的资源是常规操作，他人的资源则需要多看一眼。

将申请流程嵌入工程师已用于部署和 SSH 的 CLI，意味着采用与否不取决于在时间压力下是否记得打开一个单独的 Web 应用。

即时访问要发挥作用，必须先存在细粒度的归属关系——如果没有先建立映射到真实团队归属的范围化角色，就没有合理的单元可供授予或自动批准。

Ramp 表示，JIT 的推行使其在 SOC 2 和 ISO 27001 等框架下的安全态势得到加强——审计人员在这些框架中关注的是限时访问而非常设授权——并通过将每一次生产操作与明确的理由绑定，缩小了审计范围。团队总结的经验教训是：必须先确定系统归属关系，再构建访问工具；让数百名工程师入职所花的精力比构建工作流本身更多；尽早选择适合自身规模的供应商，可以在员工人数持续增长时避免返工。