AWS IAM 완전 정복: '누가, 무엇을, 어디서 할 수 있는가'를 결정하는 기술

들어가며: "모든 것에 Admin 권한을 주면 편하잖아?"

AWS를 처음 배우는 개발자에게 가장 흔한 유혹:

"IAM이 복잡하니까, 일단 모든 서비스에 AdministratorAccess를 주자. 나중에 줄이면 되잖아."

이것은 집의 모든 방에 같은 마스터키를 쓰고, 그 키를 현관 앞에 놓아두는 것과 같다. 편리하다. 누구나 어디든 갈 수 있다. 그리고 어느 날, 그 키가 유출되면 — 모든 것이 끝난다.

IAM은 AWS에서 가장 중요한 서비스다. EC2가 없으면 서버를 못 쓰고, S3가 없으면 파일을 못 저장하지만, IAM이 없으면 어떤 서비스도 안전하게 쓸 수 없다. 그리고 IAM을 잘못 설정하면, 다른 모든 보안이 무너진다.

1. IAM이란 무엇인가

정의

IAM(Identity and Access Management)은 AWS 리소스에 대한 접근을 안전하게 제어하는 서비스다. **"누가(Identity), 무엇을(Action), 어디에(Resource) 할 수 있는가(Allow/Deny)"**를 정의한다.

건물 보안 비유

IAM의 세 가지 질문

모든 AWS API 호출에서 IAM은 세 가지를 확인한다:

2. IAM의 역사: 왜 이렇게 복잡해졌나

초기 AWS: 단순했던 시절

2006년 AWS 출시 초기에는 AWS 계정 하나에 루트 자격증명 하나만 있었다. 팀원이 10명이면 모두 같은 루트 계정으로 로그인했다. 누가 뭘 했는지 추적 불가능.

2010년: IAM 출시

AWS가 IAM을 출시하며 개별 사용자, 그룹, 정책 개념을 도입했다. 팀원마다 별도 사용자를 만들고, 각자 필요한 권한만 부여할 수 있게 됐다.

2012~2015년: 역할(Role)의 시대

EC2 인스턴스가 S3에 접근해야 할 때, 과거에는 인스턴스 안에 액세스 키를 파일로 저장했다. 이것은 보안 재앙의 씨앗이었다 — 그 파일이 유출되면 끝이다.

IAM 역할(Role) 이 이 문제를 해결했다. EC2에 역할을 부여하면, 인스턴스가 자동으로 임시 자격증명을 받아 AWS 서비스에 접근한다. 키 파일이 필요 없다.

3. IAM의 핵심 구성 요소

사용자(User) vs 역할(Role): 가장 중요한 차이

정책(Policy): 권한의 설계도

IAM 정책은 JSON으로 작성되며, **"누가, 무엇을, 어디에, 어떤 조건에서 할 수 있는가"**를 정의한다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/uploads/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

이 정책의 의미: "my-bucket의 uploads/ 경로에 대해 읽기·쓰기를 허용하되, 203.0.113.0/24 IP 대역에서만 가능."

AWS 관리형 정책 vs 커스텀 정책

4. IAM 보안 사고: 키 유출의 공포

GitHub에 AWS 키가 올라가면 벌어지는 일

가장 흔하고 가장 치명적인 IAM 보안 사고: AWS 액세스 키가 GitHub에 커밋되는 것.

이것은 가상 시나리오가 아니다. 매일 수천 건 발생하고 있다.

실제 사고 사례

5. 최소 권한 원칙 (Principle of Least Privilege)

정의

"각 주체(사용자, 역할, 서비스)에게 업무 수행에 필요한 최소한의 권한만 부여한다."

NIST(미국 국립표준기술연구소)의 제로 트러스트 아키텍처(SP 800-207)에서 핵심 원칙으로 정의하고 있다.

현실에서 적용하기

나쁜 예:

{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*"
}

→ 모든 S3 버킷의 모든 작업 허용. Capital One 사고의 원인.

좋은 예:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::my-app-uploads/*"
}

→ 특정 버킷의 읽기만 허용. 이 키가 유출되어도 피해가 제한적.

IAM Access Analyzer: 최소 권한을 자동으로

수동으로 최소 권한 정책을 작성하는 것은 어렵다. AWS는 이를 돕는 도구를 제공한다:

• IAM Access Analyzer: 외부에서 접근 가능한 리소스를 자동 감지
• 정책 생성 도우미: CloudTrail 로그를 분석하여 실제 사용된 권한만으로 정책 자동 생성
• 미사용 권한 탐지: 90일 이상 사용하지 않은 권한을 식별하여 제거 추천

6. IAM 실전 모범 사례

절대 하지 말아야 할 것 5가지

반드시 해야 할 것 5가지

7. IAM vs 다른 ID 관리 시스템

클라우드별 IAM 비교

Cognito vs IAM: 헷갈리기 쉬운 두 가지

8. IAM의 진화: 제로 트러스트로

전통적 보안 vs 제로 트러스트

NIST SP 800-207 "Zero Trust Architecture"(2020)이 제로 트러스트를 공식 프레임워크로 정의한 이후, AWS도 IAM을 제로 트러스트 방향으로 강화하고 있다:

• IAM Roles Anywhere: 온프레미스 서버에도 IAM 역할의 임시 자격증명 발급
• Verified Access: VPN 없이 제로 트러스트 기반 앱 접근
• IAM Identity Center: 중앙 집중 SSO + 세밀한 권한 관리

9. 실제 사례

Netflix: IAM 역할 기반 마이크로서비스

Netflix는 수천 개의 마이크로서비스에 각각 전용 IAM 역할을 부여한다. 추천 서비스는 추천 DB만 접근 가능, 결제 서비스는 결제 API만 호출 가능. 한 서비스가 침해되어도 다른 서비스의 데이터에는 접근 불가.

Airbnb: CloudTrail + 자동 감지

Airbnb는 CloudTrail 로그를 실시간 분석하여 비정상적 IAM 활동(새벽에 관리자 로그인, 알 수 없는 리전에서 API 호출, 대량의 리소스 생성)을 자동 감지하고 알림한다.

한국 기업 사례

• 토스: 금융 서비스의 엄격한 IAM. 모든 IAM 변경에 승인 워크플로우 적용. CloudTrail로 전체 감사
• 쿠팡: 마이크로서비스별 IAM 역할 격리. IRSA로 K8s Pod 수준의 AWS 접근 제어
• 카카오뱅크: IAM Identity Center로 멀티 계정 중앙 관리. 금융 규제 준수를 위한 권한 분리

마치며: IAM은 클라우드의 "면역 체계"다

이 시리즈의 모든 서비스는 IAM 위에서 동작한다:

IAM이 무너지면 이 모든 것이 무너진다. VPC가 네트워크의 기반이라면, IAM은 접근 제어의 기반이다. 두 가지 모두 보이지 않지만, 없으면 모든 것이 위험하다.

Code Spaces는 IAM 실수로 회사가 사라졌다. Capital One은 IAM 과도 권한으로 1억 명의 데이터가 유출됐다. 이 교훈은 분명하다: IAM은 "나중에" 신경 쓸 것이 아니라, "가장 먼저" 제대로 설정해야 할 것이다.

코어닷투데이의 모든 AWS 서비스는 최소 권한 원칙 위에 구축되어 있다. AI 추론 서비스는 Bedrock 호출 권한만, 데이터 파이프라인은 지정된 S3 버킷 접근만, 모니터링은 CloudWatch 읽기 권한만 — 각 서비스가 자기 일에 필요한 최소한의 열쇠만 가지고 있다. 그것이 "잠이 올 수 있는" 보안의 시작이다.