🔥 User, Group, Role: 세 가지 주체의 차이

IAM 콘솔에서 왼쪽 사이드바를 처음 누르면 User, Group, Role, Policy가 나란히 붙어 있다. 넷 다 비슷한 아이콘에 비슷한 크기로 놓여 있어서, 나는 한참 살피고도 네 항목의 경계를 구별하지 못했다. 특히 User와 Role을 "둘 다 누군가의 신원을 표현하는 거면 왜 따로 나뉘어 있지?"라고 오래 의심했다.

IAM의 네 벽돌이 왜 따로 서 있는가에서는 네 요소를 한 문단 표로만 훑었다. 여기서는 User·Group·Role 셋만 떼어 내 구조를 살핀다. Policy는 뒤로 미루고, 이 셋이 왜 서로 다른지와 장기 자격증명·임시 자격증명이라는 두 종류가 어디서 나뉘는지만 집중한다.

User: 고정된 신원, 기본값은 장기 자격증명

IAM User는 가장 직관적인 개념이다. 사람 한 명, 혹은 프로그램 하나에 대응하는 고정된 신원이다. 이메일·이름으로 콘솔에 로그인하는 그 "나"라고 생각하면 대강 맞다.

User가 붙들고 있는 건 두 종류의 자격증명이다.

• 콘솔 비밀번호: 웹 콘솔용. 브라우저에서 로그인할 때 쓴다.
• Access Key(Access Key ID + Secret Access Key): 프로그래밍 접근용. CLI·SDK·Terraform이 API를 호출할 때 이 한 쌍을 싣는다.

둘 다 한 번 발급받으면 누군가 지우기 전까지 유효하다. 그래서 '장기(Long-term) 자격증명'이라 부른다. 편리하지만, 내 PC·CI 서버·깃허브 중 어디에 꽂아두느냐에 따라 유출 위험도 그만큼 커진다. IAM 설정 실수가 왜 비싸게 터지는가에서 이미 말했듯, 이런 실수는 곧바로 가장 비싼 사고로 번질 수 있다.

수치로 몇 가지만 짚어두면, IAM 공식 쿼터 기준으로 한 User당 access key는 최대 2개(활성/비활성 합산)다. 보통의 보안 권고는 키 교체 기간 외에는 1개만 활성화해 두는 쪽이다. 두 번째 슬롯은 "새 키를 발급해서 코드에 적용하는 동안 잠깐 겹쳐두기 위한 것"이라고 기억해 두면 혼란이 줄어든다.

Group: User들의 묶음, 신원이 아니다

IAM Group은 이름 때문에 오해를 사기 쉽다. Group은 '권한을 가진 주체'가 아니라 User들에게 공통 권한을 부여하기 위한 컨테이너다. 그래서 Group은 AWS에 요청을 날리지 않는다. 요청은 언제나 User(또는 Role)가 한다.

구조에 대한 사소하지만 중요한 제약이 세 가지 있다.

1. Group은 User만 담는다. 다른 Group도, Role도 담지 못한다. AWS IAM에는 'Group 안에 Group' 같은 중첩이 없다.
2. 한 User는 동시에 여러 Group에 속할 수 있다(공식 쿼터 기본 10개).
3. Role을 가정할 때의 "누가 이 Role을 쓸 수 있는가" 목록, 즉 Trust Policy의 Principal에는 Group을 넣지 못한다. AWS 서비스·AWS 계정·특정 IAM User·다른 Role·페더레이션 주체만 넣을 수 있다.

이 셋은 Group의 성격을 잘 드러낸다. Group은 "권한을 일관되게 바르기 위한 라벨"이지, 그 자체가 행동하는 주체가 아니다.

Role: 가면처럼 쓰고 벗는 신원

IAM Role은 User와 비슷해 보이지만 결정적으로 다르다. Role에는 기본값으로 꽂혀 있는 장기 자격증명이 없다. 대신 "이 Role을 가정하고 싶다"는 요청이 들어오면 그때마다 STS가 짧은 수명의 임시 자격증명 한 벌을 발급한다.

그 한 벌은 아래 세 조각으로 나온다.

• Access Key ID
• Secret Access Key
• Session Token: HTTP 요청 헤더 X-Amz-Security-Token으로 따로 실어 보내는 토큰

User의 장기 자격증명은 Access Key ID와 Secret Access Key, 이렇게 두 조각으로 끝난다. 반면 Role에서 받은 자격증명에는 Session Token이 하나 더 붙고, 유효 시간도 함께 들어 있다. 기본 1시간(DurationSeconds=3600), Role 설정에 따라 최대 12시간(43200)까지 발급할 수 있다고 AssumeRole API 문서가 명시한다. 시간이 지나면 AWS가 그 자격증명을 더 이상 받지 않는다. 잃어버려도 12시간 뒤에는 남이 쓰지 못한다.

Role이 누구에게 열려 있는가는 Role 자체에 붙은 Trust Policy가 정한다. Trust Policy의 Principal에 "이 AWS 서비스에게 허용"이라고 적으면 그 서비스가 Role을 가정할 수 있고, "이 다른 AWS 계정에게 허용"이라고 적으면 그 계정이 교차 계정 접근 권한을 얻는다. AssumeRole의 내부 시퀀스·Session Policy·교차 계정 예시는 Assume Role: 임시 자격증명이 만들어지는 순간에서 이어간다.

EC2·Lambda 같은 AWS 서비스가 Role을 쓰는 흔한 경로는 Instance Profile(EC2)과 실행 역할(Lambda)이다. EC2의 메타데이터 서비스가 어떻게 자격증명을 주입받는지는 Instance Profile: EC2는 IAM을 어떻게 얻는가에서 이어서 다룬다.

장기와 임시의 경계가 왜 중요한가

User가 쥐고 있는 access key가 유출되면 폐기 전까지 남이 내 계정으로 API를 날린다. 반면 Role에서 받은 임시 자격증명은 유출되더라도 수명이 짧다. 최악의 경우에도 12시간 뒤엔 스스로 사망한다.

이 수명 차이는 운영 관점에서 관리 책임이 어디에 놓이는지 드러낸다. User는 내가 직접 관리한다. 주기적으로 교체하고, 유출 시 비활성화하고, 폐기까지 책임져야 한다. Role은 STS가 발급하고 알아서 만료시킨다. 관리 부담의 큰 부분을 AWS가 맡는다.

여기서 다시 보이는 것도 관리형이 감추는 비용이다. 사람·CI·EC2·Lambda. 이 넷에 각자 User를 붙여두면 단기적으로는 편하지만, 결국 access key 교체 스케줄을 내가 쥐어야 한다. Role로 넘기면 이 부담이 사라지는 대신, Trust Policy라는 새로운 '신뢰 관계' 설계를 내가 쥐어야 한다. 공짜 점심은 없다. 다만 후자가 스케일이 커질수록 덜 아프다.

언제 User를 만들지 말아야 하는가

여기서는 먼저 "언제 만들지 말아야 하는가"를 따져야 한다. IAM User는 특히 아래 세 상황에서 다시 검토할 가치가 크다.

• 사람 한 명마다 User 하나를 습관처럼 만들 때. 두세 명짜리 팀까지는 버틸 수 있지만, 인원이 늘고 이직이 잦아지면 IAM Identity Center(구 AWS SSO)로 옮기는 쪽이 교체와 회수를 더 깔끔하게 처리한다. 자세한 구조는 IAM Identity Center: 사람 계정을 관리하는 현대적 방법에서 다룬다.
• GitHub Actions·CircleCI용 access key를 만들 때. OIDC 기반 AssumeRoleWithWebIdentity로 Role을 가정하게 하면 장기 Access Key를 아예 발급하지 않아도 된다. 여전히 많은 레포가 키를 박아놓고 쓰는데, 이쪽은 되돌아올 숙제다.
• EC2·Lambda에 User를 붙일 때. EC2에는 Instance Profile, Lambda에는 실행 역할이 있다. User의 access key를 EC2 안에 넣어둘 이유는 대부분 없다.

Policy로 넘어갈 지점

User·Group·Role의 차이는 장기 자격증명과 임시 자격증명을 비교할 때 가장 또렷하다. 남은 한 축은 Policy: JSON으로 권한을 표현하는 법이다. 여기서 Effect·Action·Resource·Condition이 권한을 어떻게 구성하는지, 그리고 관리형 정책과 인라인 정책이 왜 따로 존재하는지 바로 들어간다.

참고 자료

• IAM Users (AWS 공식 문서): User의 정의와 자격증명 종류 공식 설명
• IAM User Groups (AWS 공식 문서): Group의 제약(중첩 금지·User 전용 컨테이너) 1차 근거
• IAM Roles (AWS 공식 문서): Role과 임시 자격증명의 공식 정의
• AssumeRole API Reference (AWS 공식 문서): DurationSeconds 기본 3600·최대 43200의 공식 근거
• Temporary security credentials in IAM (AWS 공식 문서): Access Key ID·Secret·Session Token 3종 구조 설명
• AWS JSON policy elements: Principal (AWS 공식 문서): Trust Policy Principal에 Group이 허용되지 않는 근거
• IAM and AWS STS quotas (AWS 공식 문서): User당 access key 2개, User당 Group 10개 등 쿼터 근거