Ramp은 팀별로 AWS 역할을 분리한 뒤, 프로덕션 접근 권한을 일시적으로 만들고 요청하도록 했다

Ramp는 직원 수가 100명 미만에서 600명 이상으로 늘어나는 동안에도 백엔드 엔지니어링 접근 권한을 여전히 3개의 AWS 역할, 즉 Junior-Engineers, Engineers, Admins로 운영하고 있었다. 새로운 리소스 접근 요청이 있을 때마다 인프라 팀이 IAM 정책을 직접 수정해야 했고, 이로 인해 두 가지 고질적인 문제가 생겼다. 시니어 엔지니어는 실제 업무 범위보다 훨씬 넓은 프로덕션 접근 권한을 상시로 누적하게 되어 단 한 번의 실수나 계정 탈취가 미치는 영향 범위가 커졌고, 주니어 엔지니어는 일상적인 조회를 시니어 엔지니어를 거쳐 처리해야 해서 시니어의 시간이 소모되었다.

팀의 해결책은 두 계층으로 이루어졌다. 첫째, 세밀한 접근 제어: 3개의 역할을 20개 이상의 AWS SSO 그룹으로 대체했고, 각 그룹은 엔지니어링 팀 하나에 대응하며, 각 그룹은 해당 팀이 접근할 수 있는 CI/CD 파이프라인, Lambda 함수, ECS 컨테이너, S3 경로, 시크릿을 정확히 나열한 Terraform 모듈(`engineers_X.tf`)로 정의되었다. 이로써 소유 관계가 명확해졌다. 엔지니어는 자기 팀의 파일을 읽어 자신의 접근 권한을 확인하고, 인프라 티켓 대신 풀 리퀘스트로 변경을 요청할 수 있게 되었다.

둘째, 적시(JIT) 접근: 각 팀 역할마다 상시 멤버십이 없는 대응하는 상승된 프로덕션 역할을 만들었다. 이미 Ramp에서 앱 프로비저닝에 사용 중이던 ConductorOne을 통해 자격을 갖춘 엔지니어가 프로덕션 역할을 요청하는데, 자기 팀 역할에 대한 요청은 자동 승인되고, 다른 팀 역할에 대한 요청은 해당 팀의 테크 리드에게 승인을 위해 전달되며, 부여된 권한은 선택한 기간이 지나면 만료된다. 먼저 한 팀에 배포해 반복 개선한 뒤 AWS 전반에 배포했고, 요청 흐름을 기존 CLI에 통합해 엔지니어가 터미널을 떠나지 않아도 되게 했다.

그 결과 상시 접근 권한의 범위를 줄이고 모든 프로덕션 작업을 명시된 정당화 사유와 연결함으로써 보안 태세를 강화하면서도, 요청에서 접근까지의 지연 시간을 10초 미만으로 유지해 보안 개선이 기존 티켓 기반 시스템의 마찰을 다시 불러오지 않게 했다.

모든 프로덕션 역할을 상시 부여가 아니라 엔지니어가 요청해야 하는 시간 제한된 상위 집합으로 만들기

접근 권한을 자동화하기 전에 역할을 팀별로 분리한 것이 자동 승인(자기 팀)과 승인 전달(다른 팀의 소유자)을 위한 자연스러운 단위를 만들었다. JIT는 요청을 전달할 대상이 되는 소유권 맵을 필요로 한다.

프로덕션 역할을 비프로덕션 팀 역할의 상위 집합으로 만든 덕분에 상시 접근 권한을 제거해도 엔지니어가 일상적으로 할 수 있는 일은 달라지지 않았고, 요청 단계만 추가되었다.

같은 팀의 요청은 자동 승인하고 팀 간 요청은 테크 리드에게 전달한 것은 승인 마찰을 실제 위험에 맞춘 것이었다. 자신의 리소스는 일상적이고, 다른 사람의 리소스는 한 번 더 확인이 필요하다.

요청 흐름을 엔지니어가 배포와 SSH에 이미 사용하던 CLI에 내장한 덕분에, 도입이 시간 압박 속에서 별도 웹 앱을 열어야 한다는 기억에 의존하지 않게 되었다.

적시 접근이 작동하려면 세밀한 소유권이 먼저 존재해야 한다. 실제 팀 소유권에 매핑된 범위 지정 역할이 먼저 없으면, 부여하거나 자동 승인할 합리적인 단위가 없다.

Ramp는 JIT 배포가 SOC 2와 ISO 27001 같은 프레임워크에 대한 자사 태세를 강화했다고 보고했는데, 감사자들은 이런 프레임워크에서 상시 부여보다 시간 제한된 접근을 찾으며, 모든 프로덕션 작업을 명시된 정당화 사유와 연결함으로써 감사 범위를 줄였다. 팀이 밝힌 교훈은 다음과 같다. 접근 도구를 구축하기 전에 시스템 소유권이 정리되어야 했고, 수백 명의 엔지니어를 온보딩하는 데 워크플로 자체를 구축하는 것보다 더 많은 노력이 들었으며, 규모에 맞는 벤더를 일찍 선택한 것이 인원이 계속 늘어나는 동안 재작업을 줄여 주었다.