소규모 조직에서 IAM 권한은 어떻게 관리되어야 할까

문제 정의 (As-Is)

10~50인 규모의 소규모 개발 조직이 있다. 조직은 점진적으로 성장하고 있다.

개발자가 운영 환경에 접근하기 위해서는 운영 환경용 IAM Role을 데브옵스 조직으로부터 부여받아야 한다. 권한 요청과 회수는 Ticket을 발급하여 요청함으로써 이루어지고 있다.

현재 방식

• 개발자가 Jira 혹은 Github Issue 같은 이슈 트래커에서 티켓을 발급해 운영 접근 권한을 요청한다.
• 데브옵스 조직은 수동으로 필요한 IAM Policy와 Role을 생성해 부여한다.
• 일정 시간이 지난 뒤 데브옵스 조직이 수동으로 권한을 회수한다.

문제점

현재 방식은 데브옵스 조직의 수동 운영에 의존하고 있어 다음과 같은 문제가 발생한다.

• 운영 Toil 증가: 개발자 수가 늘어날 수록 권한 부여, 회수 요청이 증가한다. 데브옵스 조직이 반복적인 작업을 수행하며 가치가 낮은 일에 시간을 빼앗긴다.
• 권한 회수 누락 위험: 수동으로 이루어지는 권한 회수 작업 특성 상 일부 권한이 회수되지 않을 위험이 존재한다.
• 권한 표준 부재: 요청 건마다 개별적으로 권한을 생성하고 있어 일관된 권한을 부여하지 못한다. Least Privilege 원칙을 준수하기 어렵다.
• 스케일링 불가: 소규모 조직에선 수동 작업으로 처리할 수 있지만 개발자 수가 증가할 수록 데브옵스 조직의 병목이 심해진다.

해결 정의 (To-Be)

운영 환경 접근 제어는 다음을 만족시키는 형태로 개선되어야 한다.

• 권한 부여/회수 자동화: 운영 접근 권한은 요청 승인시 자동으로 부여되고, 정해진 기간이 지나면 자동으로 회수되어야 한다.
• 표준화된 권한 모델: Least Privilege에 입각하여 사전에 정의된 정책/역할을 기반으로 권한을 관리하여야 한다.
• Audit 로그 확보: 누가, 언제, 어떤 권한을 부여 받았는지 추적이 가능해야 한다.
• 운영 공수 감소: 데브옵스 조직이 수동으로 요청을 처리하지 않아도 되는 구조여야 한다. 조직이 커지더라도 작업량이 선형적으로 증가하여서는 안된다.

해결 방안 후보들

1. 사전 정의된 IAM Role을 수동 할당하는 방법

• 운영 환경 접근 권한을 표준 Role로 정리하여 정의해둔다.
• 필요 시 수동으로 Role을 부여한다.

Pros

• 권한을 표준화한다.
• 요청마다 새 Policy를 설계하지 않는다.
• Least Privilege 원칙을 적용하기 용이하다.

Cons

• 부여/회수 자체는 여전히 수동이다.
• 권한 만료 관리가 자동화되지 않으면 회수 누락이 발생한다.
• 표준 Role 설계가 부정확하면 과권한 Role이 고착화된다.

2. AWS IAM Identity Center 기반 권한 관리

• AWS에서 제공하는 IAM Identity Center를 기반으로 관리한다.
• IAM Identity Center는 Permission Set으로 표준화해 관리하는 기능을 지원한다.
• Temporary Elevated Access 방식도 제공한다.

Pros

• AWS 매니지드 서비스를 쓸 수 있다.
• Permission Set 기반 권한 표준화가 용이하다.
• 계정 단위 접근 제어와 사용자 관리가 체계적이다.
• Temporary Elevated Access를 사용해 일시적 접근 요청/승인/추적이 가능하다.

Cons

• 초기 설정과 사용자/그룹 체계 정비가 필요하다.
• 작은 조직에서는 무겁다.

3. Google Workspace + SSO + AWS Role 매핑

• AWS 접근은 SSO를 통해 필요한 Role만 부여한다.
• 관리는 외부 IdP에서 처리한다.

Pros

• 사용자 라이프사이클 관리가 용이하다. 입/퇴사 관리가 편리하다.
• AWS 뿐만 아니라 다른 SaaS 연계도 용이하다.

Cons

• 작은 조직에서는 무겁다.
• AWS 내부 권한 설계는 여전히 별도다. 이 방법 자체는 문제 해결을 위한 본질적 방법이 아니다.

선택한 해결 방안

3번 방안은 본질적으로 AWS 권한 관리를 위한 해결책이 아니다. 그리고 소규모 조직에서는 너무 크다. 2번 방안인 IAM Access Analyzer도 고려해보았지만 IAM Identity Center로 계정을 생성하고 있지 않았기에 이 시스템을 도입하기 위해서는 바닥부터 다시 정비해야 하는 제약이 있다.

그래서 1번 방안에 자동화 시스템 개발해 얹는 방식을 채택했다. 권한을 표준화하고 재사용하는 것은 1번 방식과 동일하다. 하지만 1번 방식에서는 여전히 요청/부여/회수가 수동 작업이다.

이 부분을 슬랙봇과 백엔드 서버를 구현해 보완했다. 개발자들은 슬랙봇을 통해 권한을 요청한다. 슬랙봇은 백엔드 서버로 연결되고, 백엔드 서버는 aws-sdk를 기반으로 IAM 권한을 제어한다.

한계점 및 보완하면 좋을 사항들

• IAM Access Analyzer 사용: 실제 사용 권한 기록 분석을 바탕으로 Least Privilege를 더 완벽하게 준수할 수 있도록 만드는데 도움이 될 수 있다.