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 路徑和密鑰。這讓歸屬關係變得清楚可讀——工程師可以閱讀自己團隊的檔案來查看自己的存取權，並透過 pull request 而非基礎架構工單來申請變更。

第二，即時（JIT）存取：他們為每個團隊角色建立對應的提權生產環境角色，且沒有常設成員資格。利用 Ramp 已為應用程式佈建部署的 ConductorOne，符合資格的工程師可申請生產環境角色；申請自己團隊的角色會自動核准，申請其他團隊的角色則會轉給該團隊的技術主管核准，授權會在選定的時間窗後到期。他們先向一個團隊推行、反覆調整，然後在整個 AWS 部署，並將申請流程整合進既有的 CLI，讓工程師不必離開終端機。

結果收緊了安全態勢——縮小常設存取的足跡，並讓每個生產環境動作都連結到明確的理由——同時將申請到取得存取的延遲維持在 10 秒以內，因此安全性的提升並未重新引入原本以工單為基礎的系統所帶來的摩擦。

讓每個生產環境角色都成為工程師必須申請、有時限的超集，而非常設授權

在自動化存取之前先按團隊拆分角色，創造了自然的分類單位，可用於自動核准（自己團隊）和轉送核准（其他團隊的擁有者）——JIT 需要歸屬對應表才能轉送申請。

讓生產環境角色成為非生產團隊角色的超集，意味著移除常設存取並未改變工程師日常原本就能做的事——只是增加了一個申請步驟。

自動核准同團隊的申請，同時將跨團隊申請轉給技術主管，使核准摩擦與實際風險相符：自己的資源是例行公事，別人的則需要再看一眼。

將申請流程嵌入工程師原本就用於部署和 SSH 的 CLI，意味著採用與否不取決於在時間壓力下是否記得開啟另一個網頁應用程式。

精細的歸屬關係必須先存在，即時存取才能運作——若沒有先將範圍受限的角色對應到真實的團隊歸屬，就沒有合理的單位可供授予或自動核准。

Ramp 表示，JIT 的推行強化了其因應 SOC 2 和 ISO 27001 等框架的態勢，在這些框架中，稽核人員會尋找有時限的存取而非常設授權，並透過將每個生產環境動作連結到明確的理由，縮小了稽核範圍。團隊自述的經驗教訓是：必須先確定系統歸屬，才能建置存取工具；讓數百名工程師上手所花的功夫，比建置工作流程本身還多；及早選擇適合其規模的供應商，隨著員工人數持續成長，省下了重做的工作。