[AWS] 7회차: 보안과 IAM - IAM 및 보안 개념 정리

이번 회차에서 다룬 내용

2026년 1월 27일 화요일, AWS Certified Cloud Practitioner(CLF-C02) 스터디 7회차를 진행했다. 이번 회차의 주제는 보안과 계정 관리였다.

발표자 배정표 기준으로 7회차 범위는 다음과 같았다.

• A(대산): Shared Responsibility Model
• B(대산): IAM (User / Group / Role)
• C(지현): IAM Policy & 접근 방식
• D(지현): 암호화 & MFA

개인적으로 이번 회차는 AWS 공부 전체에서 가장 중요하다고 느꼈다. 컴퓨팅, 스토리지, 데이터베이스, 네트워크는 모두 기능이 눈에 보이는 서비스들이다. 그런데 보안은 반대로, 잘하고 있으면 티가 안 나고 잘못하면 한 번에 크게 문제가 생긴다.

Cloud Practitioner 시험에서도 보안은 늘 핵심 축이다. 특정 서비스 이름을 외우는 것보다도:

• AWS와 고객이 각각 무엇을 책임지는가
• 누가 무엇을 할 수 있게 할 것인가
• 루트 계정은 왜 봉인해야 하는가
• Access Key는 언제 쓰고, Role은 언제 쓰는가
• 암호화는 어떤 방식으로 선택하는가

이런 질문이 반복해서 나온다.

즉, 7회차는 “보안 기능 소개”라기보다 AWS를 안전하게 쓰기 위한 기본 태도와 구조를 배우는 시간이었다.

왜 이 회차가 중요한가

처음 AWS를 공부할 때는 보안이 부가 기능처럼 느껴질 수 있다.

• 일단 서버 띄우고
• 저장소 만들고
• DB 붙이고
• 나중에 보안을 보면 되는 것 아닌가

라고 생각하기 쉽다.

그런데 실제로는 그 반대다.

보안은 모든 서비스 위에 따로 덧붙는 층이 아니라, 처음부터 전체 설계에 함께 들어가야 한다.

예를 들면:

• 누가 콘솔에 로그인하는가
• EC2는 어떤 권한으로 S3에 접근하는가
• 데이터는 암호화되어 있는가
• 루트 계정이 안전하게 보호되고 있는가
• 외부 감사가 들어왔을 때 추적 가능한가

이 질문은 특정 서비스의 옵션이 아니라, AWS 사용 방식 전체와 연결된다.

그래서 7회차는 개별 서비스보다도 “AWS를 어떤 원칙으로 써야 하는가”에 가까운 회차였다.

Shared Responsibility Model이란 무엇인가

AWS를 처음 공부할 때 가장 먼저 잡아야 하는 보안 개념이 Shared Responsibility Model(공동 책임 모델) 이다.

핵심은 아주 단순하다.

• AWS가 책임지는 영역이 있고
• 고객이 책임지는 영역이 있다

즉, AWS를 쓴다고 해서 보안을 전부 AWS가 대신해주는 것이 아니다.

Security OF the Cloud

AWS가 책임지는 부분이다.

예를 들어:

• 데이터센터 물리 보안
• 하드웨어
• 전력, 냉각, 시설
• 기본 인프라
• 하이퍼바이저 같은 하부 계층

즉, 클라우드 자체를 안전하게 유지하는 책임이다.

Security IN the Cloud

고객이 책임지는 부분이다.

예를 들어:

• IAM 설정
• 사용자 권한
• 데이터 암호화
• 애플리케이션 설정
• 네트워크 접근 제어

즉, 클라우드 안에서 내가 사용하는 방식에 대한 책임이다.

이 문장을 시험에서는 매우 자주 변형해서 묻는다.

왜 이 모델이 중요한가

많은 초보자가 “클라우드를 쓰면 AWS가 다 해주겠지”라고 생각하기 쉽다. 하지만 IAM을 잘못 설정하거나, 버킷을 공개해버리거나, 루트 계정을 허술하게 관리하면 그건 고객 책임 영역이다.

즉:

• 물리 서버를 지키는 건 AWS 책임
• 내가 그 서버 위에서 만든 계정과 권한을 지키는 건 내 책임

이다.

이걸 이해하면 거의 모든 보안 문제를 풀 때 기준점이 생긴다.

예를 들어 시험에서:

• “데이터센터 출입 통제는 누구 책임인가?” → AWS
• “고객 데이터 암호화 설정은 누구 책임인가?” → 고객

처럼 바로 구분할 수 있다.

IAM이란 무엇인가

IAM(Identity and Access Management)은 AWS에서 누가 어떤 리소스에 무엇을 할 수 있는지 제어하는 핵심 서비스다.

한 문장으로 말하면:

AWS 보안의 중심에서 사용자, 권한, 역할을 관리하는 시스템

이다.

자료에서도 IAM이 “AWS 보안의 심장”처럼 다뤄지고 있었다. 실제로도 그렇다. 권한을 잘못 주면 아무리 좋은 암호화와 네트워크 구성을 해도 소용이 없다.

IAM의 핵심 구성 요소

1. User

실제 사람을 위한 사용자 계정이라고 생각하면 된다.

2. Group

여러 사용자에게 공통 권한을 묶어 주기 위한 집합이다.

예를 들어:

• 개발자 그룹
• 운영자 그룹
• 읽기 전용 그룹

처럼 관리할 수 있다.

3. Role

일시적으로 권한을 위임하는 개념에 가깝다.

특히 AWS 서비스끼리 권한을 주고받을 때 아주 중요하다.

예를 들면:

• EC2가 S3에 접근해야 할 때
• Lambda가 DynamoDB를 읽어야 할 때

Access Key를 코드에 박아 넣는 대신 Role을 사용하는 것이 권장 방식이다.

Root User는 왜 특별한가

자료에서도 가장 강조된 부분 중 하나가 Root User였다.

루트 사용자는 AWS 계정을 처음 만들 때 생기는 슈퍼 관리자 계정이다.

즉:

• 가장 강한 권한을 가지며
• 거의 모든 것을 할 수 있다

그만큼 위험하다.

왜 일상적으로 쓰면 안 되는가

루트 계정이 탈취되면 피해가 매우 크다. 그래서 AWS 모범 사례는 분명하다.

• 루트 계정에는 MFA를 반드시 설정한다
• 루트 계정은 평소 작업에 쓰지 않는다
• 처음 IAM User를 만들고 나면 루트는 봉인한다

시험에서도 이 부분은 거의 정답 패턴처럼 나온다.

즉:

• Root User + MFA
• Root User daily use 금지

를 세트로 기억하면 된다.

IAM User, Group, Role을 어떻게 구분할까

처음 공부할 때는 셋이 비슷해 보여서 헷갈린다.

User

사람 한 명의 계정

Group

사람 여러 명에게 같은 권한 묶음 적용

Role

서비스나 외부 주체에게 일시적 권한 위임

쉽게 말하면:

• User는 개인
• Group은 팀
• Role은 역할

이다.

특히 시험에서는 “EC2가 S3에 접근해야 한다” 같은 문제에서 Role을 떠올릴 수 있어야 한다.

AWS 접근 방식 3가지

자료에서도 별도로 정리된 부분이 있었다. AWS 접근 방식은 크게 세 가지다.

1. Console

웹 브라우저로 AWS 관리 콘솔에 접속하는 방식이다.

보통:

• 아이디
• 비밀번호

로 접근한다.

2. CLI (Command Line Interface)

터미널에서 명령어로 AWS를 다루는 방식이다.

3. SDK (Software Development Kit)

Python, JavaScript, Java 같은 코드 안에서 AWS를 다루는 방식이다.

시험에서는 이 세 가지를 단순히 나열하는 것이 아니라, 어떤 자격 증명이 필요한지와 함께 묻는 경우가 많다.

Console vs CLI vs SDK에서 중요한 포인트

자료에서 강조된 핵심은 이것이었다.

• Console은 보통 사용자 로그인 방식
• CLI와 SDK는 보통 Access Key 기반

즉:

• 웹 화면에서 사람이 직접 들어간다 → Console
• 명령어 또는 코드에서 AWS를 호출한다 → CLI / SDK

이 구조를 기억해야 한다.

Cloud Practitioner 문제에서는 종종:

• “개발자가 CLI로 AWS를 사용하려면?”
• “애플리케이션 코드에서 AWS를 접근하려면?”

같은 식으로 나오며, 이때 Access Key 또는 Role 관련 개념이 연결된다.

IAM Policy란 무엇인가

IAM Policy는 AWS 권한을 정의하는 JSON 문서다.

즉, IAM에서 권한은 감으로 주는 것이 아니라 문서 형태로 명시한다.

자료의 예시처럼 Policy는 대체로 다음 요소를 가진다.

• Effect
• Action
• Resource

이 세 가지가 핵심이다.

Policy 구조를 쉽게 읽는 방법

Effect

허용할지(Allow), 거부할지(Deny)를 의미한다.

Action

무엇을 할 수 있는지 정의한다.

예:

• s3:ListBucket
• ec2:StartInstances

Resource

어떤 대상에 대해 그 권한을 적용할지 정의한다.

즉, Policy는 결국:

누구에게, 어떤 행동을, 어떤 자원에 대해 허용/거부할 것인가

를 적는 문서다.

최소 권한 원칙(Least Privilege)

IAM Policy를 배울 때 같이 붙는 핵심 원칙이 최소 권한 원칙이다.

뜻은 간단하다.

• 꼭 필요한 권한만 부여하라

즉, 편하다고 관리자 권한을 다 주는 것이 아니라, 필요한 범위만 허용하는 것이 보안의 기본이다.

예를 들어:

• S3 읽기만 필요한 사용자에게 삭제 권한까지 줄 필요는 없다
• 특정 버킷만 다루면 되는 애플리케이션에 전체 S3 권한을 줄 필요는 없다

시험에서도 이 원칙은 거의 정답 문장처럼 자주 나온다.

EC2가 S3에 접근할 때 왜 Role이 중요한가

자료의 예제 문제에서도 이 시나리오가 직접 나왔다.

질문은 보통 이런 식이다.

• EC2 인스턴스에서 실행되는 애플리케이션이 S3 버킷에 접근해야 한다
• 가장 안전한 방법은 무엇인가

여기서 정답은 대개 IAM Role을 EC2에 붙이는 것이다.

왜 Access Key를 코드에 넣으면 안 되나

• 노출 위험이 크고
• 관리가 어렵고
• 회전과 폐기가 번거롭다

Role을 쓰면 AWS가 더 안전한 방식으로 권한을 위임해준다.

즉, “서비스가 다른 AWS 서비스에 접근할 때는 Role”이라는 감각을 확실히 잡아두는 것이 중요하다.

MFA란 무엇인가

MFA(Multi-Factor Authentication)는 다중 인증이다.

쉽게 말하면:

• 비밀번호 하나만으로 끝내지 않고
• 추가 인증 수단을 하나 더 요구하는 방식

이다.

예:

• 비밀번호(아는 것)
• 스마트폰 OTP(가지고 있는 것)

이 조합이 대표적이다.

왜 MFA가 중요한가

비밀번호는 유출될 수 있다.

• 재사용했을 수도 있고
• 피싱에 걸릴 수도 있고
• 실수로 노출될 수도 있다

그런데 MFA가 켜져 있으면 비밀번호만 알아서는 바로 들어오기 어렵다.

그래서 AWS에서는 특히:

• Root User에 MFA 필수
• 중요 IAM User에도 MFA 권장

이 반복적으로 강조된다.

시험에서도:

• 루트 사용자 보안 모범 사례
• 계정 보호 강화 방법

같은 문제에서 MFA가 자주 정답으로 나온다.

암호화 파트: KMS vs CloudHSM

자료 후반부에서는 암호화 서비스 비교가 핵심이었다. 특히 AWS KMS 와 AWS CloudHSM 비교가 시험 포인트로 잘 정리되어 있었다.

AWS KMS

AWS의 대표적인 관리형 키 관리 서비스다.

쉽게 말하면:

• 암호화 키를 만들고
• 관리하고
• 여러 AWS 서비스와 연동해 쓰기 쉽게 해주는 서비스

다.

자료에서도 강조된 것처럼 KMS는 일반적인 기업 환경에서 가장 현실적이고 널리 쓰이는 방식에 가깝다.

CloudHSM

전용 하드웨어 기반의 키 관리 환경이다.

즉:

• 더 강한 통제와 전용 장비 요구
• 높은 규제 준수 요구

가 있는 경우에 연결된다.

자료에서는 금융권, 정부, 국방처럼 더 엄격한 환경 예시가 들어 있었다.

KMS와 CloudHSM를 어떻게 구분할까

시험 관점에서 아주 단순하게 정리하면:

KMS

• 일반적인 키 관리
• 관리형
• AWS 서비스와 쉽게 연동
• 감사 추적에 유리

CloudHSM

• 전용 하드웨어 기반
• 더 높은 통제
• 더 복잡하고 비쌈
• 규제 준수 요구가 강한 환경

즉:

• 보통의 기업 환경 → KMS
• 전용 하드웨어가 필요한 특수 규제 환경 → CloudHSM

으로 기억하면 된다.

S3 암호화 옵션

자료에는 S3 암호화 옵션도 정리되어 있었다.

SSE-S3

가장 기본적인 서버 측 암호화 방식으로 생각하면 된다. S3가 키를 관리해준다.

SSE-KMS

KMS를 활용하는 방식이다.

이때 중요한 장점은:

• 키 사용 이력 추적
• 더 세밀한 제어와 감사

와 연결된다는 점이다.

DSSE-KMS

이중 서버 측 암호화 개념과 연결되는 최신 옵션이다.

Cloud Practitioner 수준에서 아주 깊게 들어갈 필요는 없지만, “더 강한 보호를 위한 이중 암호화 옵션” 정도로 이해하면 된다.

암호화에서 자주 나오는 또 다른 구분

시험에서는 종종 다음 구분도 같이 나온다.

• At Rest: 저장 중 암호화
• In Transit: 전송 중 암호화

즉:

• 디스크나 스토리지에 저장돼 있을 때 보호하는 것
• 네트워크를 통해 이동 중일 때 보호하는 것

둘 다 중요하다.

Shared Responsibility Model과도 연결하면, 데이터 암호화 설정은 고객 측 책임 영역으로 자주 이해할 수 있다.

7회차 전체를 한 흐름으로 보면

이번 회차는 개별 키워드를 따로 외우기보다 흐름으로 보면 더 잘 정리된다.

1. 공동 책임 모델

먼저 AWS와 고객 책임 경계를 이해한다.

2. IAM

그다음 누가 무엇을 할지 정한다.

3. Access Method

사용자가 어떤 방식으로 AWS에 접근하는지 구분한다.

4. Policy

권한을 문서로 구체화한다.

5. MFA

계정 보호를 강화한다.

6. Encryption

데이터 자체를 보호한다.

이렇게 보면 7회차는 단순 암기 회차가 아니라, AWS 보안 구조를 아래에서 위로 쌓아 올리는 회차였다.

이번 회차에서 남겨둘 포인트

이번 회차를 하면서 가장 크게 느낀 건, 보안은 서비스 하나가 아니라 운영 습관과 원칙의 집합이라는 점이었다.

예를 들어:

• 루트를 평소에 안 쓰는 것
• 필요 이상 권한을 안 주는 것
• 서비스 간 접근에는 Role을 쓰는 것
• MFA를 켜는 것
• 암호화를 선택하는 것

이런 것들이 다 따로 떨어진 기능이 아니라, AWS를 안전하게 쓰는 기본 규칙이다.

Cloud Practitioner 시험도 결국 이 관점을 보고 있는 것 같다. 기술적으로 복잡한 공격 기법을 묻기보다, 안전한 기본값과 책임 범위를 이해하고 있는가를 반복해서 확인하는 식이다.

시험 전에 다시 볼 포인트

짧게 압축하면:

• Shared Responsibility Model에서 AWS는 클라우드 자체를, 고객은 클라우드 안의 설정과 데이터를 책임진다.
• Root User는 MFA를 켜고 평소엔 사용하지 않는다.
• IAM은 User, Group, Role, Policy로 권한을 관리한다.
• CLI와 SDK는 보통 Access Key와 연결된다.
• 서비스 간 권한 위임에는 Role이 중요하다.
• 최소 권한 원칙은 반드시 기억해야 한다.
• KMS는 일반적인 키 관리 서비스, CloudHSM은 전용 하드웨어 기반 서비스다.
• S3 암호화 옵션은 SSE-S3, SSE-KMS 등이 있다.

7회차까지 오니 AWS 시험에서 왜 보안이 계속 반복되는지 조금 더 이해가 됐다. 어떤 서비스를 쓰든 결국 “누가 접근하고, 어떤 권한으로, 어떤 방식으로 보호되는가”가 빠질 수 없기 때문이다.

자료 다운로드

reference 폴더 기준으로 7회차와 직접 연결되는 자료 파일은 아래 4개였다. 복습용으로 바로 내려받을 수 있게 정적 경로로 옮겨두었다.

• 07aws_security지현.html IAM Policy, 접근 방식, MFA, 암호화 중심의 발표 자료.

• Shared Resposibility Model & IAM.pptx Shared Responsibility Model과 IAM 앞 파트 자료.

다음 글에서는 1월 29일 8회차 주제였던 비용과 아키텍처 원칙, 즉 구매 옵션, Savings Plans, Cost Explorer, Well-Architected Framework를 정리할 예정이다.