🔥 IAM이란 무엇인가: 계정 보안의 문지기

현실적으로 AWS에서 제일 먼저 만나는 서비스는 EC2나 S3가 아니다. IAM이다. 계정을 만들고, 누군가를 로그인시키거나 어떤 서비스에 권한을 주는 순간 이미 IAM을 쓰고 있기 때문이다.

처음 이걸 알았을 때 조금 허탈했다. 콘솔 화면에서 'IAM'은 작은 글씨로 구석에 붙어 있고, 자습서는 늘 "일단 EC2부터 띄워보자"로 시작하니까. 그런데 실제로는 반대다. IAM이 제일 밑에 깔려 있고, 그 위에 다른 모든 서비스가 얹히는 구조다.

계정 보안의 앞단을 맡는 IAM은 User·Group·Role·Policy 네 축으로 움직이고, 요청 하나가 평가되는 순서까지 붙여 놓으면 왜 이 서비스를 '문지기'에 비유하는지 드러난다.

IAM이란 무엇인가

IAM(Identity and Access Management)의 한 줄 정의는 이렇다.

AWS에 접근하려는 '누가' 무엇을 할 수 있는지 관리하는 서비스.

두 단어가 중심이다. Identity(자격증명)와 Access(접근 권한). 사람이든 코드든 AWS 리소스를 건드리려면 두 가지를 통과해야 한다.

1. 네가 누구인지를 증명할 것. 이게 인증(Authentication)이다.
2. 그 신원에 지금 하려는 행동을 할 권한이 있는지 확인받을 것. 이게 인가(Authorization)다.

IAM은 이 두 관문을 모두 떠맡는다. 공식 문서가 "controls access to AWS resources"라고 한 줄로 말하는 이면에는 사실 이 두 가지가 맞물려 돌아간다.

한 가지 더. IAM은 글로벌 서비스다. 서울 리전(ap-northeast-2)이든 버지니아든, 내 계정 안의 User 하나는 전 리전에 동일하게 존재한다. 서비스 이용료도 따로 받지 않는다(IAM 가격 페이지). 다만 "IAM이 공짜다"와 "IAM 설정 실수가 공짜다"는 전혀 다른 얘기다. 바로 다음에 짚는다.

IAM을 구성하는 네 가지 벽돌

IAM을 다루는 책들이 조금씩 다르게 나눠 소개하지만, 실전에서 만나는 얼굴은 네 가지다. 엄밀히 말하면 앞의 셋은 공식 문서가 "IAM Identities"라고 부르는 신원 유형이고, Policy는 신원이 아니라 권한을 기술한 문서다. 그래도 IAM을 처음 머리에 넣을 때는 네 덩어리로 묶어 외우는 편이 훨씬 빠르다.

벽돌	한 줄 요약	대표 예
User	사람이나 앱 하나에 대응하는 신원. 보통 장기 자격증명이 달려 있지만 반드시 그런 건 아니다.	개발자 본인 계정, CI 서버용 계정
Group	User들의 묶음. 권한을 한 번에 걸기 위한 컬렉션	Developers, Billing-Read-Only
Role	장기 자격증명 없이 '가정'해서 쓰는 신원. 쓸 때마다 임시 자격증명을 발급받는다.	EC2 인스턴스 역할, 교차 계정 접근
Policy	무엇을 허용·거부할지 JSON으로 기술한 권한 문서. 신원이나 리소스에 붙는다.	AmazonS3ReadOnlyAccess 관리형 정책

제일 헷갈리는 건 User와 Role의 경계다. User는 '이 사람이나 앱이 계속 쓰는 계정'에 가깝고, Role은 '잠깐 가면처럼 쓰고 벗는 신원'에 가깝다. Role을 쓴다는 건 AssumeRole API를 통해 만료 시간이 붙은 임시 자격증명을 받아오는 일이다. 그래서 장기 access key를 꽂아 쓰는 방식보다 안전하다고 말한다.

Group은 User만 담는다. Role을 담는 'Role Group' 같은 건 없다. Policy는 User·Group·Role 어느 쪽에도 붙을 수 있고(identity-based policy), 일부 서비스에서는 S3 버킷·SQS 큐처럼 리소스 쪽에도 직접 붙는다(resource-based policy). 이 두 방향의 Policy가 어떻게 합쳐지는지는 다음 편들에서 이어 본다.

요청 하나가 IAM을 통과하는 흐름

IAM을 제대로 이해하려면 '권한이 어떻게 평가되는가'를 한 번 따라가보는 게 빠르다. S3 버킷에 있는 파일을 GetObject하는 요청이 들어왔다고 해보자. 공식 How IAM works 문서는 이 과정을 세 단계로 요약한다.

1. 인증: 요청에 실린 서명을 검증해 '이 요청이 누구의 것인지' 확정한다. 서명이 깨져 있으면 여기서 바로 거부.
2. 요청 컨텍스트 구성: 누가(principal), 무엇을(action), 어느 리소스에(resource), 어떤 조건에서(condition) 요청했는지를 한 덩어리로 모은다.
3. 인가: 이 컨텍스트를 적용 가능한 모든 정책과 맞춘다.

3단계 앞에 놓이는 정책은 한 가지가 아니다. 정책 평가 로직 문서가 열거하는 타입을 적어두면 이렇다.

• Identity-based policy: User·Group·Role에 붙은 정책
• Resource-based policy: S3 버킷 정책처럼 리소스 쪽에 붙는 정책
• Permissions boundary: User·Role이 넘지 못하는 '최대 권한' 상한선
• Organizations SCP·RCP: 조직 전체에 내리는 가드레일
• Session policy: AssumeRole 시 함께 좁히는 임시 정책

이 모든 정책을 훑은 뒤 AWS는 기본적으로 이렇게 결론을 낸다.

1. 명시적 Deny가 하나라도 있으면 즉시 거부. 무조건.
2. 명시적 Allow가 있고 Deny가 없으면 허용.
3. 아무것도 명시되지 않으면 암묵적 거부(default deny).

그러니까 IAM의 기본 태도는 '금지'다. 뭐든 하려면 명시적으로 Allow를 얹어줘야 한다는 뜻이다. 단, 위 세 줄은 '가장 단순한 형태'의 요약이다. 실제로는 권한 경계, SCP, RCP, 세션 정책 같은 경계 규칙이 함께 허용해야 최종적으로 통과한다. 이 평가 규칙이 겹겹이 붙는 과정은 정책 평가 흐름: Allow와 Deny가 만나면에서 제대로 파고든다.

공짜 서비스인데 사고는 제일 크게 난다

IAM은 서비스 이용료가 없다. 공짜다. 그런데 비용 사고라는 관점으로 보면 IAM도 예외가 아니다. IAM에서 돈이 새는 경로는 대체로 이 셋이다.

• Root user로 계속 일하다가 키가 유출된 경우. 공격자는 계좌 한도 안에서 리소스를 마구 만든다. 국내에서도 야간에 수천만 원이 나간 사례가 심심찮게 올라온다. AWS는 root user에게 access key를 만들지 말라고 분명히 적어 둔다.
• 와일드카드 정책("Action": "*", "Resource": "*")을 편의상 복붙한 경우. 최소 권한 원칙이 깨지고, 나중에 IAM Access Analyzer 같은 검사 도구로 따로 걷어내야 한다.
• 장기 Access Key를 개인 PC나 깃허브에 올려둔 경우. AWS Support의 보안 점검 페이지에도 적혀 있듯이 AWS는 공개 코드 저장소를 훑으며 노출된 키를 찾는다. 이런 키는 사람보다 자동화된 스캐너가 훨씬 빨리 잡아낸다는 말이 많다. 한번 노출되면 과금이 곧바로 따라온다.

공짜 서비스인데도 체감상 IAM 실수가 가장 비싼 사고를 만든다. IAM 설정을 잘못 건드리면 결국 다른 모든 서비스의 비용 청구서가 돌아오기 때문이다.

그래서 요즘 AWS는 root user MFA를 사실상 의무화했다. 공식 문서 기준으로 MFA가 아직 등록되지 않은 root 사용자가 처음 콘솔에 로그인하면 35일의 유예 기간을 받고, 그 안에 등록하지 않으면 콘솔에 들어가지 못한다. 현재 AWS가 가장 강하게 미는 방향은 FIDO 기반 passkey와 보안 키 같은 피싱 저항형 MFA다.

언제 IAM을 '쓰지 말아야' 하는가

질문을 조금 바꿔야 한다. IAM에는 "언제 이 서비스를 쓰지 말아야 하는가"보다 다른 물음이 맞다. IAM은 선택할 수 있는 서비스가 아니다. AWS 계정을 쓰는 순간 강제로 엮이기 때문이다.

그래서 질문을 바꿔 잡는다.

• Root user를 일상 작업에 쓰지 말아야 한다. 일상 관리용 User 혹은 IAM Identity Center로 만든 계정을 쓴다.
• 장기 Access Key를 쓰지 말아야 한다. EC2에서는 Instance Profile, Lambda에서는 실행 역할, 로컬 개발자 PC에서는 SSO나 AssumeRole로 임시 자격증명을 받는다.
• 와일드카드 *를 최소 권한 대신 쓰지 말아야 한다. 처음엔 귀찮아도 필요한 Action만 나열하는 쪽으로 시작해야 나중 비용을 훨씬 적게 치른다.

다음 편 예고

오늘은 IAM이 무엇이고 요청이 어떻게 평가되는지 큰 지도만 훑었다. 다음 편인 User, Group, Role: 세 가지 주체의 차이에서는 IAM의 네 주체 중 가장 헷갈리는 세 가지를 해부한다. "Role이 왜 교차 계정과 EC2 양쪽에서 갑자기 튀어나오는가", "장기 자격증명과 임시 자격증명의 경계가 어디인가" 같은 질문이 중심이다.

참고 자료

• How IAM works (AWS 공식 문서): 인증·요청 컨텍스트·인가 흐름의 공식 정의
• Policy evaluation logic (AWS 공식 문서): 명시적 Deny가 왜 최우선인지의 근거와 평가 타입 목록
• IAM Identities (AWS 공식 문서): User·Group·Role의 공식 비교 문서
• Security best practices in IAM: 최소 권한·MFA·단기 자격증명 등 보안 원칙 체크리스트
• Root user best practices: Root access key를 만들지 말고 MFA를 반드시 걸라는 공식 가이드