IAM

1. IAM을 배워야 하는 이유

• AWS 리소스 간 ‘관계’를 정의하는 방식
• IAM(Identity and Access Management)은 단순히 사용자 권한만을 제어하는 것이 아니라, AWS의 각종 리소스(EC2, S3 등) 간 권한 관계를 표현하고 제어한다. 이를 통해 서비스 간 안전하고 유연한 연동이 가능해진다.
• 보안 및 권한 관리의 핵심
• AWS 인프라를 운영할 때, 자격 증명과 권한 설정이 명확해야 한다. 잘못된 권한 설정은 치명적인 보안 사고로 이어질 수 있으므로 IAM을 깊이 이해하고 적절히 활용해야 한다.

---

2. Admin User

• Root 대신 Admin 계정 사용
• Root 계정은 결제 정보 수정이나 계정 전반의 보안 설정 같은 위험도가 높은 작업을 수행할 수 있다. 이로 인해 보안 사고가 발생할 가능성이 높으므로, 실제 운영 환경에서는 Root 계정 대신 Admin User를 생성해 사용한다.
• Root 계정을 안전하게 보관
• Root 계정은 계정 레벨의 작업(결제 관련 설정 등)에만 제한적으로 사용하고, 평소에는 접속을 차단하거나 MFA(Multi-Factor Authentication)를 적용해 관리한다.

---

3. 정책 (Policy)

• 정책의 개념
• 정책은 하나 이상의 권한을 정의한 문서이며, JSON 형식으로 작성된다. 사용자, 그룹, 역할(Role) 등에 정책을 할당하여 AWS 리소스 접근을 허용하거나 거부할 수 있다.
• 동작 방식
  1. 액션(예: 특정 API 호출)이 발생하기 전까지는 결과를 알 수 없다.
  2. 액션이 요청되면, 해당 주체(사용자, 역할 등)가 가진 모든 정책을 확인한다.
  3. 정책 중 명시적으로 Deny가 설정된 항목이 있으면 즉시 거부한다.
  4. 명시적인 Deny가 없고, Allow 규칙이 있다면 허용한다.
  5. 정책에서 언급되지 않은 액션은 기본적으로 거부한다.
• 보수적 접근
• IAM은 ‘명시적으로 허용되지 않은 작업은 거부’한다는 보수적 원칙을 따른다. 이를 통해 불필요한 권한이 부여되지 않도록 방지한다.

---

4. Group

• 정책 상속
• 여러 사용자(User)에게 공통된 권한이 필요할 때 그룹을 만들고, 그룹에 정책을 할당하면 해당 그룹의 모든 사용자가 그 정책을 상속받는다.
• 개인 정책과 그룹 정책이 겹칠 때
  • IAM에서는 ‘가장 보수적인 정책’이 적용된다고 보는 것이 안전하다.
  • 개인(User) 정책과 그룹(내) 정책에서 서로 다른 권한 범위를 부여하더라도, 명시적인 Deny가 있으면 그 권한은 거부된다.
• 그룹 중첩 금지
• 그룹 아래에 또 다른 그룹을 둘 수 없다. 이는 지나친 권한 상속으로 인해 관리가 복잡해지는 것을 막기 위함이다.

---

5. User

• 기본 개념
• User는 AWS 계정 내에서 사용할 수 있는 하나의 엔터티로, 로그인용 자격 증명(ID/Password)과 접근 키(Access Key/Secret Access Key)를 가질 수 있다.
• Access Key/Secret Access Key
  • 프로그래밍 방식(Programmatic)으로 AWS에 접근할 때 사용한다.
  • EC2 인스턴스나 로컬 머신의 AWS CLI, SDK 등에서 필요하다.
  • 키가 유출될 경우 보안 문제가 심각해지므로, 가급적 Role을 사용하는 것이 안전하다.

---

6. Role

• 역할(Role)의 개념
• Role은 일종의 ‘모자’처럼 덮어씌우는 방식으로 정책을 적용한다. 사람(User)이나 AWS 리소스(EC2, Lambda 등)에 할당할 수 있다.
• 정책 재정의
  • 역할이 부여될 경우, 기존에 가지고 있던 모든 정책이 "무효화"된다!
  • 초보자들이 Role 사용 시 실수하는 가장 많은 경우.
  • 만약 특정 리소스에 접근이 되지 않는다면, 예상하지 못한 Role이 씌워져 있진 않은지 확인해야 한다.
• Role을 할당하면 기존 보안 그룹이나 개인 정책을 대체하거나 추가하는 형태로 권한이 적용된다. 따라서 특정 시점에만 제한된 권한을 부여할 수도 있고, 필요 시 Role을 변경해 권한 범위를 조정할 수 있다.
• AWS 서비스에 대한 Role 할당
  • EC2, Lambda, RDS 등 다른 AWS 리소스가 S3 같은 타 서비스 API에 접근할 때, 권한 검증을 위해 Role이 필요하다.
  • 이는 개인 서버 통신처럼 보안 그룹만으로 해결되지 않으므로, IAM Role을 통해 올바른 권한을 부여해야 한다.

---

7. AWS 접근 방식

• 웹 콘솔
• 브라우저에서 직접 로그인해 AWS 리소스를 관리하는 대표적인 방법이다.
• AWS CLI

  aws <command> <subcommand> help
  

  와 같은 도움말을 통해 명령어 사용 방식을 확인할 수 있다.
• 명령줄 도구로, EC2를 생성하거나 S3 파일을 업로드하는 등 반복 작업을 스크립트로 자동화하기 좋다.
• AWS SDK
• 프로그래밍 코드에서 직접 AWS 서비스를 호출한다. Python의 boto3, Java의 AWS SDK for Java 등 다양한 언어용 SDK가 제공된다.
• IAM 권한 검증
• 모든 접근 방식(Web 콘솔, CLI, SDK)은 IAM에 의해 인증(자격 증명 확인)과 권한 검사를 거친 뒤에 리소스에 접근할 수 있다.

---

8. 권한을 부여하는 방법

1. Role을 부여
   • 인스턴스(EC2)나 Lambda 함수에 Role을 직접 할당하면, Access Key/Secret Key를 노출하지 않아도 된다.
   • Role이 부여된 리소스는 필요한 권한을 자동으로 할당받아 안전하게 AWS API를 호출할 수 있다.
2. 정책을 직접 부여
   • 특정 사용자나 그룹에 대해 추가 정책을 적용할 수 있다.
   • 이 경우 Access Key/Secret Access Key를 직접 관리해야 하므로, 주기적으로 키를 회전시키고 보안에 유의해야 한다.