[AWS] 4. IAM을 활용한 사용자 권한 관리 및 보안 기초

지난 시간에는 AWS 비용 관리에 대해 알아보았다.

이번에는 AWS 보안의 핵심인 IAM을 배운다.
누가, 어떤 리소스에, 어떤 권한으로 접근할 수 있는지를 제어하는 서비스다.

---

1. 접근 제어의 필요성

왜 접근 제어가 필요한가? 크게 세 가지 이유다.

보안 유지 — 민감한 데이터(고객 개인정보, 금융 정보, 내부 문서 등)에 대해 무단 접근을 차단한다.

권한 분리 — 사용자 또는 역할별로 업무에 필요한 권한만 부여한다. 내부 직원이라도 권한을 최소화하는 것이 원칙이다. 예를 들어 일반 직원은 읽기 전용, 관리자만 쓰기·삭제가 가능하도록 분리한다.

법적·규제 준수 — 개인정보 보호법, ISO 27001, GDPR 등 보안 관련 법률에서 접근 제어를 필수로 요구한다. 감사를 대비한 접근 기록 로그 관리도 필수다.

시스템 안전성 유지 — 인가되지 않은 사용자가 설정을 변경하거나 시스템을 오작동시키는 것을 방지한다.

---

2. IAM 개념

IAM(Identity and Access Management)이란?

AWS 리소스에 대한 접근을 안전하게 제어하는 서비스다.
간단히 말해, 누가(AWS 사용자, 애플리케이션) 어떤 리소스에 어떤 권한으로 접근할 수 있는지를 관리하는 도구다.

인증과 인가

• 인증(Authentication): 사용자의 신원을 확인한다. (예: 비밀번호, 액세스 키 등)
• 인가(Authorization): 어떤 리소스에 어떤 행위를 할 수 있는지 결정한다. (정책으로 권한 부여)

IAM 핵심 구성 요소

구성 요소	설명
사용자(User)	AWS 리소스에 접근할 수 있는 개별 계정 (사람, 시스템 등)
그룹(Group)	여러 사용자를 묶어 공통 권한을 부여하는 단위
역할(Role)	사용자나 서비스가 임시로 맡을 수 있는 신원
정책(Policy)	JSON 형식으로 정의된 권한 집합 (누가, 무엇을, 어디서, 언제, 어떻게 허용/거부할지 정의)

IAM 주요 기능

• 세밀한 권한 제어 (예: S3 읽기만 허용, EC2 시작은 허용하지만 종료는 금지)
• MFA(다단계 인증) 설정 가능
• IAM 역할(Role)을 통해 EC2, Lambda 같은 서비스에 권한을 위임
• 정책 기반 관리로 대규모 계정과 권한 구성이 용이
• 안전한 액세스 키 관리 및 회전 주기 설정

IAM이 왜 중요한가?

AWS는 루트 계정 하나만으로 모든 작업이 가능하다. 이를 나눠서 관리하지 않으면 보안 사고 위험이 크다. IAM은 최소 권한 원칙(Least Privilege)을 실현하여 보안성을 크게 향상시킨다.

---

3. IAM 사용자와 IAM 그룹

IAM 루트 사용자

AWS 계정 생성과 동시에 생성되며, 모든 권한을 무제한으로 가진다. 이메일/패스워드 또는 액세스 키로 인증이 가능하다.

루트 사용자 권장 사항:

• MFA 반드시 설정
• 자주 사용 금지 — 루트 계정은 비상용/관리용으로만 사용하고, 일반 작업은 IAM 사용자로 수행
• 액세스 키 발급 금지 권장 — 루트 사용자에 대한 액세스 키는 되도록 발급하지 않거나 즉시 삭제

IAM 사용자

AWS 계정 내에서 개별적으로 생성되는 사용자 계정이다. 특정 AWS 리소스에 대해 필요한 권한만 부여받아 작업을 수행한다. 사용자 아이디/패스워드 또는 액세스 키로 인증 가능하다.

IAM 사용자 권장 사항:

• 최소 권한 원칙 적용 (필요한 작업만 허용)
• MFA 설정
• 루트 사용자 대신 일상적인 업무나 서비스 운영에 사용
• 액세스 키 사용 시 주기적 회전 및 노출 주의
• CloudTrail로 사용자 활동 로깅 활성화

IAM 사용자 생성 데모

📸 [스크린샷: IAM 서비스 접속 → 사용자 메뉴]

📸 [스크린샷: 사용자 생성 시작 ]

📸 [스크린샷: 콘솔 액세스 활성화 체크]

📸 [스크린샷: 권한 설정 — 그룹에 사용자 추가 또는 직접 정책 연결]

 

📸 [스크린샷: 검토 및 생성 완료 화면]

📸 [스크린샷: 액세스 키 생성]

📸 [스크린샷: 액세스 키 비활성화 및 삭제]

 

💡 실습 중 느낀 점

• IAM 사용자 생성 시 "AWS Management Console 액세스"와 "프로그래밍 방식 액세스" 두 가지를 선택할 수 있다. 콘솔 로그인용이면 전자, CLI/SDK용이면 후자를 선택한다. 둘 다 체크도 가능하다.
• 사용자를 생성한 직후에는 아무 권한도 없다. 명시적으로 허용하지 않으면 모든 작업이 거부(묵시적 거부)되기 때문이다. 생성 후 바로 콘솔에 로그인하면 거의 아무것도 할 수 없다.
• IAM은 글로벌 서비스다. 리전을 변경해도 동일한 사용자가 보인다. EC2처럼 리전별로 분리되지 않는다.

IAM 그룹

IAM 그룹은 여러 IAM 사용자에게 공통된 권한을 한 번에 부여하기 위한 논리적인 단위다. 직접 권한을 사용자에게 하나하나 부여하지 않고, 그룹에 권한을 연결한 후 사용자를 그룹에 추가함으로써 효율적으로 권한을 관리한다.

특징:

• 권한 관리: 그룹에 정책을 붙이면, 소속된 모든 사용자에게 동일 권한 부여
• 중복 소속: 한 사용자가 여러 그룹에 속할 수 있음

IAM 그룹을 왜 사용하나?

• 권한 관리 일관성 유지: 동일 역할을 가진 사용자에게 일괄 권한 부여
• 운영 효율성 향상: 신규 입사자도 그룹에 추가만 하면 권한 자동 부여
• 정책 변경의 일괄 적용: 그룹 정책만 수정하면 모든 소속 사용자에게 즉시 반영

---

4. IAM 정책(Policy)

IAM 정책이란?

AWS 리소스에 대해 누가 어떤 작업을 어떤 조건에서 수행할 수 있는지 정의하는 권한 설정 문서다. JSON 형식으로 작성되며, IAM 사용자, 그룹, 역할(Role)에 부착(attach)하여 권한을 부여한다.

정책 문서 예시:

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

IAM 정책 분류

연결 대상에 따른 분류:

• 신원(Identity) 기반 정책: IAM 사용자, 그룹, 역할(Role) 등에 연결하는 정책
• 리소스(Resource) 기반 정책: AWS 리소스에 연결하는 정책

재사용 유무에 따른 분류:

• 관리형 정책 (Managed Policy): 정책을 저장해 두고 재사용 가능
• 인라인 정책 (Inline Policy): 한번만 사용 가능하고 재사용 불가

IAM 정책 평가 우선 순위

1. 명시적 거부 (Explicit Deny) — 무조건 최우선. Effect: "Deny"가 명시된 작업은 어떠한 Allow보다도 우선해서 거부된다. 보안상 위험한 작업을 반드시 차단할 때 사용한다.
2. 명시적 허용 (Explicit Allow) — 명시적 거부가 없을 때만 적용된다.
3. 묵시적 거부 (Implicit Deny) — 기본 상태. 어떤 작업에 대해 명시적으로 허용하지 않으면 기본적으로 거부된다. 즉, 정책에 언급되지 않은 권한은 자동으로 거부된다.

최소 권한의 원칙

IAM의 기본 원칙은 "사용자나 서비스에게 꼭 필요한 권한만 최소한으로 부여"하는 것이다. 불필요한 권한은 오히려 보안 위협이 된다.

예시: 개발자에게는 EC2 시작/중지 권한만 부여한다. EC2 삭제나 IAM 관리 권한까지 주면 보안 위험이 증가한다.

IAM 정책의 JSON 구조 주요 항목

항목	설명
Version	정책 언어의 버전 (항상 "2012-10-17" 사용)
Effect	Allow 또는 Deny
Action	허용/거부할 작업 (예: ec2:StartInstances, s3:*)
Resource	적용할 리소스 ARN (예: arn:aws:s3:::my-bucket/*)
Condition	(선택) 조건 기반 제한 (예: 특정 IP, MFA 등)

ARN (Amazon Resource Name) 형식

AWS 리소스를 고유하게 식별하기 위한 문자열이다. AWS 정책, CLI, SDK 등에서 "어떤 리소스"를 가리키는 데 사용된다.

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

ARN 예시:

• S3 버킷: arn:aws:s3:::my-bucket (글로벌 서비스라 리전이 비어 있다)
• S3 객체: arn:aws:s3:::my-bucket/images/cat.jpg
• EC2 인스턴스: arn:aws:ec2:ap-northeast-2:123456789012:instance/i-0abcd1234efgh5678
• IAM 사용자: arn:aws:iam::123456789012:user/Alice

IAM 정책 예시 — S3 버킷 읽기 전용 정책

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

my-bucket의 객체 목록 조회(ListBucket)와 다운로드(GetObject)만 허용한다. 데이터 분석가가 결과 파일만 확인하도록 권한을 제한할 때 사용하는 패턴이다.

IAM 정책 예시 — EC2 인스턴스 시작/중지 허용 정책

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances"
      ],
      "Resource": "arn:aws:ec2:ap-northeast-2:123456789012:instance/*"
    }
  ]
}

서울 리전의 모든 EC2 인스턴스에 대해 시작/중지만 가능하다. 운영팀 직원이 서버를 켜고 끄는 작업만 하도록 제한하는 상황이다.

IAM 정책 예시 — DynamoDB 테이블 쓰기 금지 (Deny)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "dynamodb:PutItem",
        "dynamodb:UpdateItem",
        "dynamodb:DeleteItem"
      ],
      "Resource": "arn:aws:dynamodb:ap-northeast-2:123456789012:table/Orders"
    }
  ]
}

Orders 테이블에 쓰기 작업(추가, 수정, 삭제)을 명시적으로 거부한다. 외부 분석가가 테이블을 조회만 하고, 데이터를 변경하지 못하게 막을 때 사용한다.

IAM 정책 예시 — 조건(Condition) 활용: 특정 IP에서만 접근 허용

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "IpAddress": {"aws:SourceIp": "203.0.113.25/32"}
      }
    }
  ]
}

my-bucket 접근을 특정 사무실 IP에서만 허용한다. 회사 네트워크에서만 S3에 접근 가능하도록 제한하는 패턴이다.

IAM 사용자/그룹에 권한 부여 데모

데모 절차:

1. AWS 웹 관리 콘솔 접속
2. IAM 사용자와 IAM 그룹을 생성
3. IAM 사용자를 IAM 그룹에 연결
4. IAM 정책 (S3FullAccess 권한)을 생성한 그룹에 연결
5. 생성한 사용자로 로그인하여 권한 적용 확인

 

📸 [스크린샷: 무 권한 IAM 유저 생성 및 S3 생성 불가]

📸 [스크린샷: 사용자 그룹 생성 및 AmazonS3FullAccess 정책 연결]

 

📸 [스크린샷: 해당 사용자로 로그인 후 S3 접근 성공 확인]

 

📸 [스크린샷: 해당 사용자로 EC2 접근 시 권한 거부 화면]

💡 실습 중 느낀 점

• 사용자에게 직접 정책을 붙이는 것보다 그룹에 정책을 붙이고 사용자를 그룹에 추가하는 방식이 관리가 훨씬 편하다. 사용자가 10명만 넘어도 개별 관리는 비현실적이다.
• S3FullAccess를 그룹에 연결한 후 해당 사용자로 로그인하면, S3는 정상적으로 접근되지만 EC2 콘솔에 들어가면 권한 오류가 뜬다. Allow된 것만 되고, 나머지는 전부 Implicit Deny라는 걸 직접 확인할 수 있었다.
• 정책의 JSON을 직접 작성하지 않아도 AWS에서 기본 제공하는 Managed Policy가 수백 개 있다. AmazonS3FullAccess, AmazonEC2ReadOnlyAccess 같은 이름이 직관적이라 처음에는 이걸 활용하고, 세밀한 제어가 필요할 때 Custom Policy를 작성하면 된다.
• ARN 형식에서 S3는 리전과 계정 ID가 비어 있다 (arn:aws:s3:::my-bucket). S3가 글로벌 서비스이기 때문이다. 반면 EC2는 리전과 계정 ID가 모두 포함된다. 서비스마다 ARN 패턴이 다르므로 공식 문서를 참고해야 한다.

---

5. IAM 역할(Role)과 임시 권한

IAM 역할이란?

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

IAM 역할을 왜 사용하는가?

• 임시 권한 제공: 보안성을 높이기 위해 액세스 키 없이 단기적으로 권한 부여
• 서비스 간 접근 허용: EC2 → S3, Lambda → DynamoDB처럼 AWS 서비스 간 안전한 연동
• 연동 사용자(외부 계정, SSO 등)에게 권한 위임 가능

IAM 역할 수임 가능 주체

• IAM 사용자 (임시 권한 부여)
• 다른 AWS 계정의 사용자 (Cross-Account Access)
• 연동 사용자 (외부 계정, Facebook 로그인, Apple ID 로그인, SSO 등)
• AWS 서비스 (EC2, Lambda 등)

IAM 역할 수임 예

IAM 사용자에 임시 권한 부여 (단기 작업자)

상황: A팀 개발자가 일주일 동안 B팀의 특정 S3 버킷만 접근해야 한다.
방법: 해당 개발자 User에 Role Assume 권한 부여 → 기간 만료 후 자동 차단. 최소 권한 + 만료 기한 설정으로 보안을 강화한다.

Cross-Account Access (계정 간 접근)

상황: 계정 A에 있는 사용자 → 계정 B의 S3 버킷에 접근해야 한다.
방법: 계정 B에서 Role 생성 + Trust Policy에 계정 A를 신뢰 주체로 설정 → 계정 A 사용자가 sts:AssumeRole API 호출 → 임시 자격증명으로 계정 B의 자원에 접근한다. 여러 계정을 운영하는 조직에서 자주 쓰이는 패턴이다.

Federated Access (기업 SSO 연동)

상황: 회사 직원이 회사의 SSO 계정으로 AWS에 접근한다.
방법: SAML/OIDC 기반으로 IAM Role을 Assume → 임시 AWS 콘솔 접근 권한 획득. 사내 계정과 연동해서 편리하게 AWS 리소스에 접근한다.

서비스의 역할 수임 — EC2에서 S3 접근

상황: 애플리케이션 서버(EC2)가 S3에 로그 파일을 저장해야 한다.
잘못된 방법: EC2에 Access Key/Secret Key를 하드코딩 → 보안사고 위험.
올바른 방법:

• IAM Role을 만들고 AmazonS3FullAccess(또는 ReadOnly) 정책 연결
• EC2 인스턴스 실행 시 해당 Role 부여
• EC2 안에서 AWS CLI 실행 → aws s3 ls (정상 동작)

서비스의 역할 수임 — Lambda에서 DynamoDB 접근

상황: Lambda 함수에서 DynamoDB 테이블 조회/갱신이 필요하다.
방법: Lambda에 IAM Role 연결 → AmazonDynamoDBFullAccess 부여. 코드에 키를 넣지 않고도 DynamoDB 작업이 가능하다.

IAM 역할 수임 데모

데모 절차:

1. IAM 역할(Role) 생성
2. 역할에 정책 부여
3. IAM 사용자에 역할 수임 권한 부여
4. 사용자 로그인 및 역할 수임 (콘솔에서 수동 수임)
5. 권한 적용 확인
6. 수임된 역할에서 원래 사용자로 돌아가기

📸 [스크린샷: IAM Role 생성 — 신뢰할 수 있는 엔터티 유형 선택]

📸 [스크린샷: Role에 정책 연결]

📸 [스크린샷: 사용자 역할 전환]

📸 [스크린샷: 역할 수임 후 EC2 생성 및 S3 생성 불가 확인]

EC2 역할 모자가 씌워졌기 때문에 원래의 S3 접근 권한은 없어진다

📸 [스크린샷: 원래 사용자로 돌아가기]

💡 실습 중 느낀 점

• 콘솔에서 역할을 수임(Switch Role)하면 상단 배너 색상이 바뀌면서 현재 어떤 역할을 수임 중인지 표시된다. 누가 어떤 역할로 작업 중인지 시각적으로 바로 확인할 수 있어서 실수를 줄일 수 있다.
• Role에는 Trust Policy(신뢰 정책)와 Permission Policy(권한 정책) 두 가지가 있다. Trust Policy는 "누가 이 역할을 수임할 수 있는가"를 정의하고, Permission Policy는 "이 역할이 무엇을 할 수 있는가"를 정의한다. 둘 다 설정해야 정상 동작한다.
• EC2에 Role을 부여하면 인스턴스 메타데이터 서비스(IMDS)를 통해 임시 자격증명이 자동으로 갱신된다. 코드에 키를 하드코딩할 필요가 없으므로 서비스 간 접근은 무조건 Role을 사용하는 것이 best practice다.
• IAM 사용자에게 직접 S3 권한을 주는 것과 Role을 통해 임시로 S3 권한을 받는 것의 차이: 전자는 영구적 권한, 후자는 임시 권한(만료 시간 존재)이다. 보안 관점에서는 후자가 훨씬 안전하다.

---

학습 정리

• IAM은 AWS 보안 관리의 핵심으로, 사용자별로 세밀한 접근 제어가 가능하다
• 사용자와 그룹 구조를 통해 효율적으로 권한을 분리하고 관리할 수 있다
• IAM 정책은 JSON 형식으로 구성되며, Effect + Action + Resource 조합으로 리소스 단위의 접근 제어를 설정한다
• 정책 평가 순서: 명시적 거부 > 명시적 허용 > 묵시적 거부
• 임시 권한은 IAM 역할을 활용하는 것을 권장한다
• IAM 역할 수임은 IAM 사용자, AWS 서비스, 연동 사용자 등이 가능하다
• 서비스 간 접근(EC2→S3, Lambda→DynamoDB)은 액세스 키 대신 반드시 Role을 사용한다

다음 시간에는 AWS의 네트워킹과 VPC에 대해 알아보겠다.