IAM 및 AWS CLI

 

IAM부터 확장성 설계까지 한 흐름으로 이해하기

이 구간은 AWS 아키텍처의 “기초 뼈대”를 설명하는 핵심 파트다.

IAM으로 접근을 통제하고 → EC2를 실행하고 → 스토리지를 붙이고 → 네트워크를 구성하고 →
데이터 저장하고 → 글로벌 트래픽을 처리하고 →확장성과 고가용성을 확보하는 구조

이 흐름으로 이해하면 전체가 한 번에 정리된다.

---

1️⃣ IAM – AWS 보안의 출발점

 IAM은 Global 서비스다

먼저 중요한 사실 하나, IAM은 리전 기반 서비스가 아니다.Global 서비스다.

즉, 서울 리전이든, 도쿄 리전이든, IAM에서 설정한 사용자와 권한은 전체 AWS 계정에 적용된다.

---

2️⃣ IAM의 기본 구성 요소

• User → 사람
• Group → 사용자 묶음(admin,developers)
• Role → AWS 서비스 또는 외부 계정에 부여하는 권한(EC2가 S3에 접근해야 할 때)
• Policy → 실제 권한을 정의하는 문서

콘솔 로그인도 가능하고, Access Key 발급도 가능하다.

결국 핵심은 Policy다.

---

3️⃣ 🔐 IAM Policy – 권한의 본질

IAM Policy는 JSON 기반 권한 문서다. AWS는 기본적으로 모든 요청을 거부(Deny)한다.
우리가 명시적으로 Allow 해야만 접근이 가능하다.

 

Policy 구성 요소

• Effect → Allow / Deny
• Action → 어떤 작업을 허용할지
• Resource → 어떤 리소스에 대해
• Condition → 조건부 설정 (선택)

예시:

{
 "Effect": "Allow",
 "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::my-bucket/*"
}

 

---

🚨 Allow vs Deny 규칙

기본값은 Deny -> Explicit Deny가 있으면 무조건 Deny

Allow가 있어야 접근 가능

그리고 반드시 기억해야 할 개념: ✅ 최소 권한 원칙 (Least Privilege)

-> 필요한 최소한의 권한만 부여한다.

bad example :  "Action": "*"

good example:  특정 버킷에 대해 GetObject만 허용

 

 

 

4️⃣ IAM Password Policy

보안은 권한만으로 끝나지 않는다.
계정 자체도 안전해야 한다.

AWS에서는 IAM 사용자에 대해 비밀번호 정책을 설정할 수 있다.

설정 가능한 항목:

• 최소 길이 설정
• 대문자 / 소문자 / 숫자 / 특수문자 요구
• 비밀번호 만료 설정
• 이전 비밀번호 재사용 방지

기업 환경이라면 반드시 설정해야 하는 부분이다.

---

5️⃣ MFA (Multi-Factor Authentication)

비밀번호만으로는 부족하다.

MFA는 다음 구조다.

내가 아는 것 (비밀번호)+ 내가 가진 것 (OTP 디바이스)

즉, 비밀번호가 유출되어도
두 번째 인증이 없으면 로그인할 수 없다

반드시 MFA를 설정해야 하는 계정

- Root 계정 (무조건)

- 관리자 계정

- 중요한 리소스 접근 계정

---

6️⃣ AWS에 접근하는 방법 3가지

AWS에 접근하는 방법은 크게 3가지다.

1. AWS Management Console

 웹 브라우저 로그인 방식 → 비밀번호 + MFA

 가장 직관적이고 많이 사용된다.

2. AWS CLI

 터미널에서 명령어로 AWS를 제어하는 도구다.

aws s3 ls

자동화 스크립트 작성에 매우 유용하다.

3. AWS SDK

코드에서 AWS를 호출할 때 사용한다.

Python (boto3)

Java

Node.js 등

---

7️⃣ Access Key, 그리고 반드시 알아야 할 것

CLI와 SDK는 보통 Access Key를 사용한다.

Access Key는 두 부분으로 구성된다.

• Access Key ID → 사용자 이름 같은 역할
• Secret Access Key → 비밀번호 같은 역할

⚠️ 절대 공유하면 안 된다.

🚨 그런데 정말 중요한 것 EC2나 Lambda에서 S3 접근하려고 Access Key를 코드에 저장하면 안 된다.

정답은 항상: 👉 IAM Role 사용

 

---

8️⃣ IAM Roles for Services – 그런데 서비스는 어떻게 접근할까?

Access Key는 사람이 CLI나 SDK를 사용할 때 쓰는 방식이다.

그렇다면 이런 상황은 어떻게 할까?

- EC2 인스턴스가 S3에 접근해야 한다.

- Lambda가 DynamoDB를 호출해야 한다.

- CloudFormation이 EC2, VPC를 생성해야 한다.

이건 사람이 아니라 AWS 서비스가 우리 대신 작업을 수행하는 상황이다.

여기서 등장하는 것이 바로 IAM Role이다.

 

🔐 IAM Role의 역할

IAM Role은 특정 AWS 서비스가 우리 계정 안에서 권한을 가지고 행동할 수 있도록 해주는 장치다.

즉,“이 서비스는 이 리소스에 접근해도 된다” 라고 공식적으로 허가해주는 구조다.

 

❌ 절대 하면 안 되는 것

EC2 안에 Access Key를 저장해서 S3 접근시키는 것.

왜 위험할까? 키 유출 위험, 키 교체 번거로움, 보안 사고 가능성 증가

 

---

9️⃣ IAM Security Tools – 권한을 “관리”하는 도구들

IAM은 설정도 중요하지만, 지속적인 점검(Audit) 이 훨씬 더 중요하다.

AWS는 이를 위해 두 가지 보안 점검 도구를 제공한다.

 

✔ IAM Credentials Report (계정 단위)

계정 전체 IAM 사용자에 대한 보고서다.

포함 내용:

• 사용자 생성 여부
• 비밀번호 사용 여부
• Access Key 존재 여부
• Access Key 마지막 사용 시점
• MFA 활성화 여부

즉, “우리 계정의 보안 상태를 한 번에 확인하는 리포트”

보안 감사(Audit) 상황에서 매우 중요하다.

 

✔ IAM Access Advisor (사용자 단위)

Access Advisor는 “이 사용자가 어떤 서비스를 언제 마지막으로 사용했는지” 보여준다.

예:

S3 권한은 있지만 1년 동안 사용 안 함

EC2 권한은 있지만 최근 사용 없음

 

이 정보를 통해:

👉 불필요한 권한 제거, 최소 권한 원칙 강화가 가능하다.

---

🔟 IAM 전체 요약 

Users → 사람

Groups → 사용자 묶음

Policies → 권한 정의 (JSON)

Roles → AWS 서비스 권한

Security → Password Policy + MFA

Programmatic Access → CLI / SDK + Access Keys

Audit → Credentials Report & Access Advisor