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

문제 정의 (As-Is)

스타트업이나 소규모 개발 조직에서는 운영 환경 접근 권한 관리가 표준화되어 있지 않거나, 수동 작업에 의존하는 경우가 많습니다. 하지만 팀 규모가 10명에서 20명, 50명으로 커질수록 이 방식은 점점 운영 병목이 됩니다.

예를 들어 개발자가 운영 환경에 접근하려면, 데브옵스 조직을 통해 별도의 운영용 IAM Role을 발급받고 AssumeRole 방식으로 접근한다고 가정해보겠습니다. 이때 권한 부여와 회수는 Jira나 Github Issue 같은 티켓 발급 절차를 통해 처리하고 있습니다.

현재 방식

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

문제점

이 방식은 적은 인원의 조직에서는 큰 문제 없이 운영될 수 있습니다. 권한 요청 건수 자체가 많지 않고 누가 언제 왜 요청했는지 맥락도 비교적 쉽게 파악할 수 있기 때문입니다. 하지만 조직이 커질수록 문제가 생기기 시작합니다.

• 운영 Toil 증가: 개발자 수가 늘어날수록 권한 부여 요청과 회수 작업도 함께 증가합니다. 데브옵스 조직은 반복적인 작업을 수행하며 가치가 낮은 일에 시간을 소모합니다.
• 권한 회수 누락 위험: 회수가 수동으로 이루어지니 일부 권한이 회수되지 않고 남아 있을 수 있습니다.
• 권한 표준 부재: 요청 건마다 개별적으로 권한을 설계하고 생성하고 있어 일관성이 떨어집니다. Least Privilege 원칙을 준수하기도 어렵습니다.
• 확장성 부족: 소규모 조직에선 수동 작업으로 처리할 수 있지만 개발자 수가 증가할수록 데브옵스 조직의 병목이 심해집니다.

해결 정의 (To-Be)

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

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

해결 방안 후보들

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

운영 환경 접근 권한을 표준 Role로 미리 정의하고, 필요할 때마다 수동으로 부여하는 방식입니다.

Pros

• 권한을 표준화할 수 있습니다.
• 요청마다 새 Policy를 설계하지 않아도 됩니다.
• Least Privilege 원칙을 적용하기 용이합니다.

Cons

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

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

AWS에서 제공하는 IAM Identity Center를 사용해 사용자와 권한을 중앙에서 관리하는 방식입니다. Permission Set을 사용해 권한을 표준화할 수 있습니다. Temporary Elevated Access 방식을 통해 일시적 권한 요청도 가능합니다.

Pros

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

Cons

• 초기 설정과 사용자/그룹 체계 정비가 필요합니다.
• 작은 조직에서는 다루기 무거운 편입니다.

3. Google Workspace + SSO + AWS Role 매핑

사용자 관리는 외부 IdP에서 처리합니다. AWS 접근은 SSO를 통해 필요한 Role만 매핑해 부여합니다.

Pros

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

Cons

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

선택한 해결 방안

저는 1번 방안을 기반으로 자동화 시스템을 덧붙이는 방법을 택했습니다.

3번은 사용자 관리는 편리해지겠지만, 본질적인 해결책은 아니었으며 대규모 조직에 적합한 방식입니다. 2번 방안인 IAM Identity Center도 충분히 좋은 선택지긴 하였으나, 기존 AWS 계정 관리가 IAM Identity Center 기반으로 이루어지지 않고 있었기 때문에 이를 사용하기 위해서는 계정 관리부터 정비해야 하는 단점이 있었습니다.

반면 1번 방안은 당장 적용 가능한 현실적인 선택지였습니다. 표준 Policy/Role을 미리 정의하여 권한 모델을 단순화할 수 있고, 여기에 자동화만 얹으면 현재 조직 규모에서 필요한 문제를 해결할 수 있다고 판단했습니다.

실제 구현 방식

실제 구현은 비교적 단순합니다. 권한 모델은 표준화하고, 운영 절차는 자동화하는 방향으로 접근하였습니다.

• 개발자는 슬랙봇을 통해 필요한 Role, 간단한 요청 사유, 만료 기한, 승인자를 작성해 권한을 요청합니다.
• 슬랙봇은 권한 부여 권한이 있는 관리자에게 승인 요청 메시지를 전달합니다.
• 관리자가 승인/거절 버튼을 눌러 권한을 부여/반려합니다.
• 승인된 권한은 정해진 만료 시점 이후 자동으로 회수됩니다.
• 이 과정에서 요청, 부여, 회수 등 감사 로그는 DB에 남겨 추적 가능하도록 합니다.

한계점 및 보완점

• IAM Access Analyzer 사용: 실제 사용 권한 기록 분석을 바탕으로 Least Privilege를 더 완벽하게 준수할 수 있도록 만드는데 도움이 될 수 있을 것입니다.
• 이후 조직 확장 시 IAM Identity Center 재검토: 개발 조직이 커지고 조직 단위의 설정이 필요해지는 시점이 온다면 IAM Identity Center를 도입해 체계화하는 방향을 고려할 수 있을 것입니다.
• 권한 카탈로그 고도화: 표준 Role을 정의하더라도 실제 운영 과정에서는 부족한 권한에 대한 추가 요청이 계속 발생합니다. 따라서 수정된 권한 구성을 다시 문서화해 개발 조직에 제공해야 합니다. 그렇지 않으면 개발자는 어떤 권한을 요청해야 하는지 알기 어렵습니다. 조직이 커질 수록 문서를 계속 수동으로 수정하는 작업도 Toil이 됩니다. 장기적으로는 IAM Policy를 읽어 권한 정리 문서를 자동 생성하는 방식까지 고려해볼 수 있습니다.

소규모 조직이 커지는 과정에서는 완벽한 체계를 갖추기보다는 Toil을 줄이면서도 실제로 잘 동작할 수 있는 구조를 갖추는 것이 중요하다고 보았습니다.