AWS Summit Seoul 2025 후기 | NEXON의 대규모 계정관리 대장정(IAM Identity Center)

7.3.7 2025. 5. 15. 14:19

AWS Summit을 다녀와서 , , 내용 정리를 해보고자한다. 스따뚜

1. 클라우드 접근 제어의 도전 과제

- 복잡하고 다양해지는 환경
- 증가하는 ID, 계정 수
- 최소 권한 원칙 구현
- 다양한 라이프 사이클.
- 각종 규제에서 요구하는 접근제어 수준(모든 과정이 기록으로 남아야함. api를 한개마다 로그를 남기는 등)
- 원격/분산 업무 환경의 보안 위협 증대
- GenAI의 등장. 필요할때 권한을 적시에 주고, 회수하는게 필요

> 이것의 대한 답이 IAM Identity Center !

2. IAM Identity center 소개

✅ ID 소스 연결 1회로 구성 가능

- ID Provider와 연결(SAML/SCIM)하고, 자동으로 프로비저닝을 수행할 수 있음

✅ 대규모 AWS계정 및 자원에 대한 접근 제어 관리 용이

- AWS 조직 내 모든 AWS 계정에 걸쳐 접근을 중앙에서 관리
- 각 계정 별로 사용자/그룹에 대한 접근을 정의하기 위해 권한 세트 할당
- 개별 애플리케이션을 ID 소스에 일일이 연결할 필요없음

✅ AWS 계정에 유저를 생성하지 않고도 외부에 있는 사용자 들이 AWS 서비스와 자원 사용 가능

- 써드파티 SaaS 제품 연동 가능(ex OAuth2.0, SAML 2.0)
- 기존의 IAM 계정에 대한 액세스 구성을 변경하지 않고도 AWS 서비스/자원에 대한 접근 구현 가능(기존 구성에 추가만 하면됨)

2.1 IAM VS IAM Identity Center

🔸 IAM

✅ 사용자 직접 생성 필요
- 각 AWS 계정에 직접 IAM 사용자/그룹을 생성해야 함
- 사용자 수가 많거나 계정이 많으면 관리 복잡도 급증

✅ 멀티 계정 접근 어려움
- 여러 계정 간 권한 공유나 중앙 관리가 어렵고 수동 설정 필요

✅ 외부 IdP 연동 제한적
- SAML 연동은 가능하나 복잡하고, 앱 단위로 일일이 구성해야 함

✅ 타 SaaS 앱 연동 부재
- AWS 외부 SaaS 애플리케이션(OAuth2, SAML 등)과의 통합 부족

🔸 IAM Identity Center

✅ 중앙 통합 사용자 관리
- 하나의 ID 소스(예: Azure AD, Okta 등)로 전체 AWS 계정 관리 가능
- 사용자 계정은 외부 IdP에 있고, AWS에는 생성할 필요 없음

✅ 멀티 계정·조직 관리에 최적화
- AWS Organizations와 연계하여 수십~수백 개 계정에 대한 권한을 중앙에서 제어 가능

✅ 권한 세트(Role Set) 기능
- 사용자/그룹에 역할을 부여해 계정별 세부 권한 구성 가능
- 반복적이고 일관된 권한 부여 구조 설계 가능

✅ SaaS 앱과의 광범위한 연동
- OAuth2.0, SAML2.0 기반의 300개 이상의 애플리케이션과 연동 가능

이미 IAM 사용중인데, 이관이 어렵지 않나 ?

IAM Identity Center는 기존에 구성되어 사용중인 IAM SAML 공급자를 수정/변경하지 않으며, 고객 관리형 역할을 수정하지 않음. 즉 기존 IAM 사용자 계정에 영향을 주지않아 이관이 어렵지 않음

가장 좋은 점은, 사내 인사시스템에 연동할 수 있다는 점이다. 따라서 개인별로 새로 IAM 계정, AWS가입을 하지 않고도 AWS 서비스에 접근이 가능하여 번거로움을 줄이고, 퇴사 및 휴직 시에도 인사시스템에서 정보 변경 시 자동으로 동기화 되어 일을 두번 안해도 된다는 점.!

3. 넥슨의 적용 과정

3.1 넥슨의 도전과제

1) 이전 넥슨 현황 및 문제점

  - AWS 계정 수 300+, 웹 콘솔 가능 IAM USER 수 1,500+ 로 관리 어려움
  - 조직 담당자가 계정을 직접 운영(root 회수, 제어정책, 로그연동을 통한 모니터링 수행)
  - AWS 계정 별로 접근 관리를 해야하므로 계정수 만큼의 MFA, 계정별 로그 관리가 필요함
  - 제어 정책을 일일이 작업해야하는 어려움
  - 관리하던 담당자 퇴사 시, 업무 인수 인계 어려움

2) 설계 시 고려해야할 점

- 새로운 공통 정책이 기존 서비스에 영향을 끼치지 않아야함(ex, 신규 절챙 할당 시 라이브중인 다른 정책에 영향이 없어야함)
- 불필요하지 않게 복잡하지 않은 정책

3.2 주요 도입 과정

✅ 별도의 제어 콘솔 할당

- AWS IdC를 도입하면서, 기존처럼 각 계정에 관리자용 IAM 유저를 만들 수 없어서(IdC에서는 제한됨) 직접 백오피스 콘솔을 만들어서 사용자/그룹/권한 관리를 중앙에서 처리하였음
- 즉, IAM Identity Center + 자체 관리 도구 조합으로 운영

✅ 권한 할당 구조 단순화

- 그룹, Permission SET, 계정이라는 1:1:1 구조로 '권한 그룹'이라는 하나의 레코드로 단순화하여 설계함.

✅ 사용자 접속 정보 가시성 확보

  - Permission Set 이름 자체에 계정/권한 정보를 표기하여 한눈에 계정의 권한을 파악할 수 있도록 설계
  - Permission Set은 AWS 로그인 시 오른쪽 상단에 표기되는 계정 고유 정보

3.3 도입 장점 및 한계

1) 도입 장점

✅ 계정 대비 유저 수 감소

- 기존 유저수는 1500+ 였으나, IAM IdC 활성화 한 시점에서 생성된 SSO User 수는 100+

✅ 관리 중앙화

   - 사용자는 SSO 계정 하나만 사용
   - 공통 정책 적용 용이하고 개별 대응도 유연
   - 근무 정책 변경(휴직/퇴직) 시 사내 인사 시스템에서도 삭제해야하고, 직접 AWS 계정도 삭제해야함에 비해 IdC는 자동으로 동기화 되어 비활성화 되기때문에 대응 용이

2) 한계

✅ Rate Limmit

- 위에서 언급했듯이 '그룹:PS:계정' 구조로 시작하게 되어 계정 수만큼 데이터가 발생. 이에따라 백오피스에서 심각한 지연이 발생
- AWS 서포트에 읍소해서 초당 40건으로 증설하였으나 여전히 부족하여 백오피스 캐싱으로 대응하고 있음

✅ SSO 유저 프로필에 한글/콤마 미지원

✅ SSO 유저 상태는 'SCIM'을 통해서만 변경 가능

4.TEAM(Temporary Elevated Access Management)

- AWS IAM Identity Center와 통합되어, 멀티 계정 환경에서 일시적이고 승인 기반의 고권한 접근을 관리할 수 있도록 지원하는 오픈소스 솔루션(유료)
- 세션로그 검토 가능 및 위험행위 발생 시 바로 권한 회수가 가능하며, 시간 제한을 두고 접근제어를 수행할 수 있어 근무 정책 변경(휴가, 퇴사, 휴직 등) 시 사용 용이

5. 후기

지금 회사에 배포된 클라우드 가이드는 IAM 만 확인하고 있는데, 큰 기업들을 보면 IAM이 아닌 IdC로 이동하고 있는 추세다. 이점을 고려해서 보안점검가이드를 새로 만들어야겠다는 생각과... 지금 만들고 있는 스크립트는 그러면... 버려야하나 하는 생각과... 그래도 만들었으니까 .. . ㅠㅠ 삽질은 많을 수록 좋으니까 라는 긍정회로가 공존한다...