RampはAWSのロールをチームごとに分割し、その後、本番アクセスを一時的なものにして申請制にした

Rampは従業員数が100人未満から600人超に成長する間も、バックエンドエンジニアリングのアクセスを3つのAWSロール（Junior-Engineers、Engineers、Admins）で運用し続けていた。新しいリソースへのアクセスを申請するたびに、インフラチームがIAMポリシーを手作業で編集する必要があり、これが2つの慢性的な問題を生んでいた。シニアエンジニアは実際の業務範囲をはるかに超えた本番アクセスを常時蓄積し、単一のミスやアカウント侵害が及ぼす影響範囲（ブラストラディウス）を広げていた。一方、ジュニアエンジニアは日常的な問い合わせをシニアエンジニア経由で行わざるを得ず、シニアの時間を消耗させていた。

チームの解決策は2層構造だった。第一に、細粒度のアクセス制御である。3つのロールを20以上のAWS SSOグループに置き換え、各グループをエンジニアリングチームごとに1つずつ設けた。各グループはTerraformモジュール（`engineers_X.tf`）で定義され、そのチームが触れられるCI/CDパイプライン、Lambda関数、ECSコンテナ、S3パス、シークレットを正確に列挙していた。これにより所有権が可読になった。エンジニアは自分たちのチームのファイルを読めば自分のアクセスを確認でき、インフラへのチケットではなくプルリクエストで変更を申請できるようになった。

第二に、ジャストインタイム（JIT）アクセスである。チームロールごとに、常設メンバーシップを持たない対応する昇格本番ロールを作成した。Rampですでにアプリのプロビジョニングに導入済みだったConductorOneを使い、対象となるエンジニアが本番ロールを申請する。自チームのロールへの申請は自動承認され、他チームのロールへの申請はそのチームのテックリードに承認のためにルーティングされ、付与は選択した期間の経過後に失効する。まず1チームに展開して反復改善し、その後AWS全体に展開した。さらに申請フローを既存のCLIに組み込み、エンジニアがターミナルを離れずに済むようにした。

その結果、常設アクセスの範囲を縮小し、すべての本番操作を明示された正当化理由に紐づけることでセキュリティ態勢を強化しつつ、申請からアクセスまでのレイテンシを10秒未満に保った。これにより、セキュリティ上の利点が元のチケットベースのシステムが抱えていた摩擦を再び持ち込むことはなかった。

すべての本番ロールを、エンジニアが申請しなければならない時間制限付きのスーパーセットにし、常設の付与にしないこと

アクセスを自動化する前にロールをチームごとに分割したことで、自動承認（自チーム）と承認ルーティング（他チームの所有者）の自然な単位が生まれた。JITは申請をルーティングするための所有権マップを必要とする。

本番ロールを非本番のチームロールのスーパーセットにしたことで、常設アクセスを削除してもエンジニアが日常的にできることは変わらず、申請ステップが加わるだけだった。

同一チームの申請は自動承認し、クロスチームの申請はテックリードにルーティングすることで、承認の摩擦を実際のリスクに合わせた。自分のリソースは日常的だが、他人のリソースは再確認が必要である。

申請フローを、エンジニアがデプロイやSSHですでに使っていたCLIに埋め込んだことで、導入は時間に追われる中で別のWebアプリを開くことを覚えておく必要に依存しなかった。

ジャストインタイムアクセスが機能するには、細粒度の所有権がまず存在していなければならない。実際のチーム所有権にマッピングされたスコープ付きロールが最初になければ、付与や自動承認を行う妥当な単位が存在しない。

Rampは、JITの展開によりSOC 2やISO 27001といったフレームワークに対する態勢が強化されたと報告した。これらのフレームワークでは監査人が常設の付与よりも時間制限付きアクセスを重視し、すべての本番操作を明示された正当化理由に紐づけることで監査スコープが縮小した。チームが述べた教訓は次のとおりである。アクセスツールを構築する前にシステムの所有権を確定させる必要があったこと、数百人のエンジニアのオンボーディングはワークフローの構築そのものよりも手間がかかったこと、そして増え続ける人員数に備えて自社の規模に合ったベンダーを早期に選んだことで手戻りを避けられたことである。