IAM은 “누가(인증, Authentication)”, “무엇을(인가, Authorization)”할 수 있는지를 제어하는 AWS의 글로벌 서비스이다.

1. IAM의 핵심 요소

IAM을 이해하려면 아래 4가지를 반드시 구분해야 한다.

1.1. 사용자 (User) - 실제 사람 또는 애플리케이션

• AWS 리소스를 사용하는 주체이다.
• 사람: 콘솔에 로그인하기 위한 ID/Password를 가진다.
• 애플리케이션(비권장): API 호출을 위한 Access Key와 Secret Access Key를 가질 수 있다.
  • 하지만 서버 애플리케이션은 Role을 사용하는 것이 정석적이다.)

1.2. 그룹 (Group) - 사용자 집합

• 사용자들을 묶어서 권한을 한 번에 관리하는 단위이다.
• 예: Developers, Admins, HR-Team
• Developers 그룹에 ‘EC2 조회 권한`을 주면, 그룹에 속한 사람들 모두 EC2를 조회할 수 있다.

1.3. 역할 (Role) - 모자 또는 완장

• 특정 권한을 가진 자격이다. 사용자처럼 영구적인 자격 증명(패스워드)이 없고, 임시 보완 자격 증명을 사용한다.
• 사용처
  • AWS 서비스: EC2나 Lambda가 S3에 접근해야 할 때, EC2 인스턴스에 이 역할(Role)이라는 모자를 씌워준다
  • 다른 계정 사용자: 협력사 계정에서 우리 계정 리소스를 접근해야 할 때
• 백엔드 개발자에게 Role이란?: 내 코드가 서버에서 돌아갈 때, 하드코딩된 키 없이도 AWS API를 사용할 수 있게 해주는 마법의 권한.

1.4. 정책 (Policy) - 출입 규정 문서

• A는 B를 할 수 있다(Allow) 혹은 없다(Deny)를 JSON 형태로 정의한 문서이다.
• 이 정책 문서를 사용자, 그룹, 역할에 연결(Attach)해야 비로소 권한이 생긴다.

---

2. 정책(Policy) 해부하기 (JSON)

백엔드 개발자는 이 JSON을 읽고 쓸 수 있어야 한다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",            // 1. 허용할 것인가 차단할 것인가?
      "Action": "s3:ListBucket",    // 2. 어떤 행동(API)을?
      "Resource": "arn:aws:s3:::my-bucket-name"  // 3. 어떤 대상(리소스)에?
    },
    {
      "Effect": "Deny",
      "Action": "s3:DeleteObject",
      "Resource": "*"               // 모든 리소스에 대해 삭제 금지
    }
  ]
}

• Effect: Allow또는 Deny (기본값은 묵시적 Deny이다. 명시적으로 Allow해야 한다.)
• Action: 서비스:동작 형식이다. (예: dynamodb:PutItem, ec2:StartInstances)
• Resource: 권한이 적용될 대상의 ARN(Amazon Resource Name)이다.

---

3. 백엔드 개발자를 위한 실무 패턴: Access Key vs IAM Role

핵심은 절대로 서버 코드에 Access Key를 사용하지 않는 것이다.

나쁜 예 (Access Key 사용)

1. IAM 사용자를 만들고 Access Key와 Secret Key를 발급받는다.
2. 스프링 부트 application.yml에 이 키를 적는다.
3. 코드를 깃허브에 올린다 → 해킹 당함.

좋은 예 (IAM Role 사용)

1. S3 접근 권한을 가진 IAM Role을 만든다.
2. EC2(또는 ECS/Lambda)를 생성할 때 이 Role을 부여(Assign)한다.
3. 코드에서는 아무런 키 설정 없이 AWS SDK(S3Client)를 호출한다.
4. SDK가 알아서 EC2의 메타데이터에서 임시 권한을 가져와 통신한다. (보안 사고 위험 X)

---

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

개발 편의를 위해 AdminisratorAccess을 주고 시작하는 경우가 많다. 하지만 운영 환경에서는 반드시 필요한 권한만 줘야한다.

• 상황: 이미지를 리사이징하면 Lambda 함수
• 권한
  • O: S3의 images 버킷에 대한 GetObject, PutObject 권한.
  • X: S3의 모든 버킷(*)에 대한 모든 권한 (`s3:`*)

---

5. IAM 트러블슈팅 403 Access Denied 해결법

백엔드 개발중 Access Denied 에러가 떴을 때 확인 순서이다.

1. Who: 현재 내 코드가 어떤 신분(User/Role)으로 실행 중인가? (로컬이면 as sts get-caller-identity로 확인)
2. Policy: 그 신분에 연결된 정책(Policy)에 해당 Action(예: s3:PutObject)이 Allow되어 있는가?
3. Resource: 정책의 Resource 부분이 정확한가? (버킷 이름 오타 등)
4. Condition: IP 제한이나 시간 제한 같은 조건(Condition)이 걸려있지 않은가?
5. SCP/Boundary: 조직(Organization) 차원에서 금지된 권한(SCP)이거나, 권한 경계(Permission Boundaty)에 막혔는가? (고급)