4주차 - IAM

- 접근 제어가 필요한 이유

1)  보안 유지: 고객 개인정보, 금융 정보, 내부 문서 같은 민감한 데이터는 인증된 사용자만 접근할 수 있어야 한다.

2) 권한 분리. 사용자 또는 역할별로 업무에 필요한 권한만 부여해서 오남용을 방지해야 한다. 내부 직원이라도 일반 직원은 읽기 전용, 관리자만 쓰기·삭제 가능하게 하는 최소 권한 원칙이 반드시 지켜져야 한다.

3) 법적·규제 준수. 유럽의 GDPR(위반 시 매출의 4% 벌금), 우리나라 개인정보보호법, 금융권 전자금융 감독 규정 등 접근 제어는 법적으로 기업이 살아남기 위한 최소 조건이다. 감사가 들어왔을 때 언제 누가 무슨 데이터에 접근했는지 로그가 반드시 남아 있어야 한다. 

 

- IAM: 
IAM(Identity and Access Management)은 AWS 리소스에 대한 접근을 안전하게 제어할 수 있도록 도와주는 서비스

쉽게 말하면 누가, 어떤 리소스에, 어떤 권한으로 접근할 수 있는지를 관리하는 도구

- 인증(Authentication) / 인가(Authorization)

구분	설명	수단
인증 (Authentication)	사용자의 신원을 확인	웹 콘솔 → ID/PW CLI/SDK → Access Key
인가 (Authorization)	어떤 리소스에 어떤 행위를 할 수 있는지 결정	정책(Policy)으로 권한 부여

 

AWS 루트 계정 하나로만 모든 작업을 하면 보안 사고 위험이 너무 크기 때문에 IAM을 사용해서 최소 권한 원칙(Least Privilege)을 실현하면 보안성이 크게 향상된다.

 

- IAM 루트 사용자 (IAM Root User)
루트 사용자는 AWS 계정 생성과 동시에 만들어지는 계정으로 모든 권한이 무제한

이메일/패스워드 또는 액세스 키로 인증이 가능한데 액세스 키는 프로그래밍 방식으로 접근할 때 쓰이기 때문에 유출 시 피해 규모가 훨씬 크다.

- 루트 사용자 권장 사항

항목	권장 사항
MFA	반드시 설정 (Google OTP 앱 또는 하드웨어 디바이스)
일상 사용	금지. 비상용/관리용으로만 사용하고 일반 작업은 IAM 사용자로 수행
액세스 키	발급하지 않거나 즉시 삭제 권장

 

- IAM 사용자
IAM 사용자는 AWS 계정 내에서 개별적으로 생성되는 사용자 계정으로 기본적으로 아무 권한이 없고, 필요한 권한만 부여받아 작업을 수행한다.
- 인증 방법

인증 수단	사용 용도
ID / 패스워드	웹 관리 콘솔 로그인
Access Key ID + Secret Access Key	CLI, SDK 등 프로그래밍 방식 접근

IAM 사용자 권장 사항도 루트 사용자와 비슷한 맥락

(최소 권한 원칙 적용, MFA 설정, 액세스 키는 주기적으로 회전 및 노출 주의, CloudTrail로 사용자 활동 로깅 활성화)  

 

- IAM 사용자 생성 실습 (Demo 4-1)
① IAM 서비스 접속

② 사용자 생성 버튼 클릭

③ 사용자 이름 입력 (예: administrator), 웹 콘솔 로그인 체크박스 활성화, IAM 사용자 생성 선택

체크박스를 표시해야 콘솔에서 사용 가능하다.

④ 콘솔 로그인용 암호 입력 → 다음
⑤ 권한 설정 - 직접 정책 연결 → AdministratorAccess 선택

모든 접근 권한을 부여한다.

⑥ 검토 후 사용자 생성

 

위와 같이 만들어진다.

- 액세스 키 생성

사용 용도 선택

- IAM 그룹
IAM 그룹은 여러 IAM 사용자에게 공통된 권한을 한 번에 부여하기 위한 논리적인 단위임. 직접 권한을 사용자에게 하나하나 부여하지 않고, 그룹에 정책을 붙이면 소속된 모든 사용자에게 동일한 권한이 부여됨

- 장점

특징	설명
권한 관리 일관성	동일 역할을 가진 사용자에게 일괄 권한 부여
운영 효율성	신규 입사자도 그룹에 추가만 하면 권한 자동 부여
정책 변경의 일괄 적용	그룹 정책만 수정하면 모든 소속 사용자에게 즉시 반영
중복 소속	한 사용자가 여러 그룹에 속할 수 있음

 

- IAM 정책(Policy)
IAM 정책은 AWS 리소스에 대해 누가 어떤 작업을 어떤 조건에서 수행할 수 있는지를 정의하는 권한 설정 문서

JSON 형식으로 작성되며 IAM 사용자, 그룹, 역할에 부착(attach)해서 권한을 부여한다.

분류 기준	종류	설명
연결 대상	신원(Identity) 기반 정책	IAM 사용자, 그룹, 역할에 연결
	리소스(Resource) 기반 정책	AWS 리소스(예: S3 버킷 정책)에 연결. 누가 이 리소스를 사용할 수 있는지 명시
재사용 여부	관리형 정책 (Managed Policy)	저장해 두고 여러 대상에 재사용 가능
	인라인 정책 (Inline Policy)	특정 대상에만 한 번 사용, 재사용 불가

 

- IAM 정책 평가 우선순위
하나의 리소스에 여러 정책이 중복 적용될 수 있어서 우선순위가 존재한다.

순위	종류	설명
1	명시적 거부 (Explicit Deny)	Effect: "Deny"가 명시된 작업은 어떠한 Allow보다도 우선해서 거부. 다른 정책에서 Allow를 받았어도 무조건 막힘
2	명시적 허용 (Explicit Allow)	Effect: "Allow"로 명시된 작업은 명시적 거부가 없을 때만 허용
3	묵시적 거부 (Implicit Deny)	기본 상태. 정책에 아무 언급이 없으면 자동으로 거부됨. S3 읽기 권한만 있으면 쓰기는 묵시적으로 거부

명시적 거부가 필요한 이유: 묵시적 거부 상태인 사용자가 나중에 다른 정책으로 Allow를 받게 될 경우에 대비해서 절대 이 리소스를 사용하지 못하게 하기 위하여

 

- IAM 정책의 JSON 구조
IAM 정책은 JSON(JavaScript Object Notation) 형식

(JSON: (key): 값(value) 쌍의 모음으로, XML보다 가볍고 대부분의 언어에서 지원하는 표준 데이터 포맷)

항목	설명
Version	정책 언어의 버전. 항상 "2012-10-17" 사용 (변경된 적 없음)
Statement	정책 문장의 배열. 여러 개의 권한 규칙이 여기에 들어감
Effect	Allow 또는 Deny
Action	허용/거부할 작업 (예: s3:ListBucket, ec2:StartInstances, s3:*)
Resource	적용할 리소스의 ARN (예: arn:aws:s3:::my-bucket/*)
Condition	(선택) 조건 기반 제한. 특정 IP, MFA 여부 등 조건 추가 가능

정책 문서 예시 (S3 버킷 목록 조회만 허용)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::my-bucket"
    }
  ]
}

 

- ARN(Amazon Resource Name)
:AWS 리소스를 고유하게 식별하는 문자열로, IAM 정책의 Resource 항목에 사용됨. AWS 리소스의 주민등록번호 같은 존재

형식: arn:partition:service:region:account-id:resource

요소	의미	예시
arn	고정 문자열	항상 arn으로 시작
partition	파티션	aws (일반), aws-cn (중국), aws-us-gov (GovCloud)
service	리소스가 속한 서비스	s3, ec2, iam, lambda
region	리전	ap-northeast-2 (서울)
account-id	AWS 계정 ID (12자리)	123456789012
resource	리소스 이름/경로	버킷명, 인스턴스ID, 역할명 등

ARN 예시

리소스 종류	ARN 예시	비고
S3 버킷	arn:aws:s3:::my-bucket	S3는 글로벌 서비스라 리전·계정 ID 생략
S3 객체	arn:aws:s3:::my-bucket/images/cat.jpg	버킷 안의 특정 파일 경로
EC2 인스턴스	arn:aws:ec2:ap-northeast-2:123456789012:instance/i-0abcd1234	리전·계정 ID 포함
IAM 사용자	arn:aws:iam::123456789012:user/Alice	IAM은 글로벌이라 리전 생략, 계정 ID 포함

 

- IAM 사용자/그룹 생성 및 정책 연결 실습 (Demo 4-2)
① AWS 웹 관리 콘솔 루트 유저로 접속
② IAM 사용자 생성 (예: devuser, 콘솔 로그인 설정 체크) → 시크릿 창 열어서 해당 사용자로 로그인

유저 생성 (일단 어떤 권한도 부여하지 않고 생성한다)

어떤 권한도 부여하지 않고 생성하였으므로 모든 접근이 막히는 것을 확인할 수 있다.

③ 사용자 그룹 생성 (예: devgroup)

④ 그룹에 정책 연결: devuser을 그룹에 포함하고 AmazonS3FullAccess권한을 그룹에 부여

⑤ 다시 S3 버킷 생성을 시도해 보면 이제 생성 가능한 것을 확인할 수 있다

 

- IAM 역할(Role)의 개념
IAM 역할은 AWS 리소스에 접근할 수 있는 임시 권한을 부여하는 신원(Identity)임. IAM 사용자처럼 정책으로 권한을 받지만, 고유한 로그인 자격 증명(비밀번호 등)은 없고 다른 주체가 수임(Assume)해서 사용하는 방식임

모자에 비유할 수 있음. 역할이라는 모자를 만들어 두고 권한(정책)을 붙여 놓은 뒤, 필요한 사람이나 서비스가 그 모자를 쓰면 해당 권한을 임시로 갖게 됨. 모자를 벗으면 권한도 사라짐

역할을 수임하면 임시 자격 증명(임시 키)이 발급됨. 이 키는 만료 시간이 있어서 시간이 지나면 자동으로 사용 불가 상태가 됨. 영구 키가 유출되는 것보다 보안상 훨씬 유리한 이유임

역할을 사용하는 주요 이유는 세 가지임

이유	설명
임시 권한 제공	액세스 키 없이 단기적으로 권한 부여 가능. 시간이 지나면 자동 만료
서비스 간 접근	EC2 → S3, Lambda → DynamoDB 같은 AWS 서비스 간 안전한 연동
연동 사용자	외부 계정, SSO 등 외부 계정에게 AWS 권한 위임 가능

 

 

- IAM 역할 수임 가능 주체

주체	예시 상황
IAM 사용자 (같은 계정)	개발자가 일주일 동안 B팀의 S3 버킷에 접근해야 할 때
다른 AWS 계정의 사용자	개발 계정(A)의 사용자가 운영 계정(B)의 리소스에 접근 필요 시 (Cross-Account Access)
연동 사용자	회사 SSO, 카카오/Google/Apple 로그인 등 외부 자격 증명으로 AWS 접근
AWS 서비스	EC2 인스턴스가 S3에 로그 저장, Lambda 함수가 DynamoDB 조회할 때

 

 

- 서비스의 역할 수임 예시

EC2 인스턴스 위에서 실행되는 애플리케이션이 S3에 파일을 업로드해야 하는 상황을 생각해 볼 수 있음. 잘못된 방법은 개발자의 IAM 액세스 키를 EC2에 직접 심어 두는 것임. 이 인스턴스를 여러 명이 공용으로 사용하거나 누군가 접근하면 키 유출 위험이 있음

올바른 방법은 역할을 만들고 S3 접근 정책을 연결한 뒤, EC2 인스턴스에 그 역할을 부여하는 것임. 그러면 EC2 내부에서 AWS CLI나 SDK를 쓸 때 자동으로 임시 키가 세팅되어 전달되고, 개인 키를 코드나 서버에 남길 필요가 없어짐

Lambda도 마찬가지, Lambda 함수에 역할을 연결하면 코드에 키를 넣지 않고도 DynamoDB를 안전하게 사용할 수 있다

 

 

- IAM 역할 수임 
① 루트 계정으로 IAM 역할 생성 (예: EC2FullRole)

신뢰할 수 있는 엔티티: AWS 계정 (현재 계정)

정책: AmazonEC2FullAccess 선택

② EC2FullRole의 신뢰 관계(Trust Policy) 편집
   - 수임 가능 대상을 루트가 아닌 특정 IAM 사용자(daegu-user)로 수정

③ devuser로 로그인, 콘솔 우측 상단 계정명 클릭 → 역할 전환 클릭

④  계정 ID 입력, 역할 이름(EC2FullRole) 입력 후 역할 전환

위와 같이 역할을 수임하면 devuser에서도 EC2 인스턴스를 생성하고 삭제할 수 있다. 다만 역할을 수임하였으므로 기존에 devuser에 있던 S3FullAccess 권한은 회수된다.

역할을 수임한 상태이므로 기존에 있었던 S3 버킷 생성 권한이 막힌 것을 확인할 수 있다.