Day 1 - 공동 책임 모델 심화와 IAM의 기본기

클라우드 이전에는 보안이 어땠나

지금은 "AWS가 어디까지 해주나"를 따지지만, 클라우드 이전에는 따질 것이 없었다. 전부 내 몫이었기 때문이다.

회사가 직접 서버를 사서 전산실에 두던 시절, 보안 담당자의 할 일 목록은 이랬다.

• 전산실 문에 잠금장치를 달고 드나든 사람을 기록한다
• 하드웨어가 고장 나면 부품을 갈고, 폐기할 때는 디스크를 물리적으로 파괴한다
• 운영체제 보안 패치를 직접 챙겨 적용하고, 방화벽 장비를 사서 설정한다
• 그 위에서 도는 우리 프로그램의 로그인과 권한도 직접 만든다

문제는 이 목록의 대부분이 회사의 본업과 아무 상관이 없다는 점이었다. 쇼핑몰을 만드는 회사가 전산실 냉방기와 씨름한다. 잘해도 티가 안 나고, 한 번 못하면 사고가 난다.

클라우드는 이 목록을 반으로 잘랐다. 아래쪽(건물·전원·하드웨어·가상화)은 AWS가 통째로 가져가고, 위쪽(내가 올린 데이터와 내가 한 설정)은 고객이 그대로 맡는다. 이 잘린 선이 바로 오늘의 주제인 공동 책임 모델이다.

공동 책임 모델은 "AWS가 보안을 다 해준다"는 말도, "클라우드는 위험하다"는 말도 아니다. 책임의 경계선을 미리 못 박아 둔 것에 가깝다. 그래서 시험도 이 경계선을 집요하게 묻는다.

공동 책임 모델: "of the cloud" vs "in the cloud"

보안은 시험 비중이 가장 큰 영역(30%)이고, 그 모든 답의 출발점이 공동 책임 모델이다. "이건 AWS가 해주나, 내가 해야 하나?"에 답할 수 있으면 시험 문제의 상당수가 풀린다. 가장 유명한 한 줄 요약은 이렇다 — AWS는 클라우드 자체(of the cloud)의 보안을 책임지고, 고객은 클라우드 안(in the cloud)의 보안을 책임진다.

• AWS 책임 (Security OF the Cloud): 데이터센터 물리 보안, 서버 하드웨어, 네트워크 인프라, 가상화 계층, 관리형 서비스의 기반 소프트웨어.
• 고객 책임 (Security IN the Cloud): 데이터 자체, 데이터 암호화 설정, 운영체제·애플리케이션 패치(EC2의 경우), 네트워크 방화벽 규칙, IAM을 통한 접근 권한 관리.

책임 경계는 서비스 유형에 따라 이동한다. EC2(IaaS)는 OS 패치까지 고객 몫이지만, RDS·Lambda 같은 관리형 서비스로 갈수록 AWS가 더 많은 운영을 책임진다. "관리형일수록 AWS 책임이 커진다"가 핵심 패턴이다. 단, 데이터와 접근 권한은 어떤 서비스든 항상 고객 책임이다.

아파트로 이해하는 책임 경계

가장 잘 통하는 비유는 아파트다.

• 건물 자체 — 외벽, 엘리베이터, 공동 현관 출입 통제, 소방 설비. 이건 관리사무소 몫이다.
• 우리 집 안 — 도어락 비밀번호를 뭘로 할지, 귀중품을 금고에 넣을지 식탁 위에 둘지, 친구에게 비밀번호를 알려줄지. 이건 전적으로 당신 몫이다.

관리사무소가 아무리 훌륭해도, 당신이 현관문을 열어두고 외출하면 도둑이 든다. 그리고 그건 관리사무소 잘못이 아니다.

굵게 표시한 아래 세 줄이 전부 고객 몫이라는 점에 주목한다.

서비스 종류에 따라 선이 움직인다

경계선은 고정된 벽이 아니라 서비스 종류에 따라 위아래로 움직이는 선이다. 내가 직접 다룰 것이 많은 서비스일수록 고객 몫이 늘고, AWS가 알아서 해주는 서비스일수록 AWS 몫이 는다.

표의 맨 오른쪽 열을 세로로 훑어본다. 어느 줄에서도 "AWS"로 바뀌지 않는다. 데이터와 접근 권한은 무슨 서비스를 쓰든 끝까지 고객 몫이다. 이 한 줄이 오늘 배우는 내용 중 시험 판단에 가장 널리 쓰인다.

⚠️ 함정: "관리형 서비스를 쓰면 보안은 신경 쓸 필요가 없다" 같은 선택지는 오답이다. RDS를 쓰면 엔진 패치는 AWS가 해주지만, 누가 접속할 수 있는지, 데이터를 암호화할지는 여전히 고객이 정한다. "S3는 AWS가 운영하니 데이터 유출 책임도 AWS에 있다"도 같은 이유로 오답이다.

한 온라인 교육 스타트업이 수강생 자료를 S3에 백업하면서, 개발 편의를 위해 버킷을 잠깐 "누구나 읽기 가능"으로 열어두고는 그대로 잊어버렸다. 시간이 지나 백업 파일이 외부에 노출되며 사고가 됐다. 이때 AWS 인프라에는 아무 문제가 없었다 — 데이터센터도, 가상화 계층도, S3 서비스 자체도 정상이었다. 원인은 고객이 바꿔 놓은 설정 하나였고, 책임도 전적으로 고객에게 있었다. 공동 책임 모델을 "누구를 탓할지"가 아니라 "내가 점검해야 할 목록"으로 읽어야 하는 이유다.

AWS는 건물을 지키고, 나는 내 집 문을 잠근다. 건물 관리를 맡기게 되어 훨씬 편해졌지만, 내 집 문을 잠그는 일까지 대신해 주지는 않는다.

IAM이란 무엇인가

고객 책임 중에서도 가장 자주 다루는 것이 "누가 무엇을 할 수 있는가"를 정하는 일이고, 이것을 담당하는 서비스가 AWS IAM(Identity and Access Management)이다.

• IAM은 무료이며, 모든 리전에 걸친 글로벌 서비스다(리전별로 따로 만들지 않는다).
• 인증(Authentication): "당신은 누구인가?" — 사용자가 맞는지 확인.
• 인가(Authorization): "당신은 무엇을 할 수 있는가?" — 어떤 작업을 허용할지 결정.

왜 IAM이 필요한가

AWS 계정을 처음 만들면 최고 권한 계정 하나뿐이다. 혼자 쓸 때는 문제가 없다. 그런데 팀이 커지면 이런 일이 벌어진다.

• 새 개발자가 들어와 서버에 접속해야 한다 → 계정 비밀번호를 알려준다
• 경리 담당자가 청구서를 봐야 한다 → 같은 비밀번호를 알려준다
• 그중 한 명이 퇴사한다 → 비밀번호를 바꾸고 남은 전원에게 다시 알려준다

사무실에 만능 열쇠 하나만 두고 모두가 복사해 쓰는 상황과 같다. 누가 언제 들어왔는지 알 수 없고, 한 명만 열쇠를 잃어버려도 전부 위험해진다.

IAM은 이 만능 열쇠를 사람마다 다른 카드키로 바꾸고, 카드마다 열 수 있는 문을 따로 지정해 주는 시스템이다. 경리 담당자의 카드는 청구서 방만 열리고, 퇴사자가 생기면 그 카드 한 장만 정지하면 된다.

인증과 인가는 다른 말이다

IAM 설명에 늘 붙어 나오는 두 단어인데 서로 헷갈리기 쉬우니 표로 갈라둔다.

로그인은 성공했는데 특정 작업만 거부당했다면, 인증은 통과했고 인가에서 막힌 것이다.

IAM의 4가지 핵심 구성요소

IAM을 이해하려면 사용자, 그룹, 역할, 정책 네 가지를 구분해야 한다.

• 1. 사용자(User): 사람 또는 애플리케이션 하나에 대응하는 자격 증명. 로그인 비밀번호나 액세스 키를 가진다.
• 2. 그룹(Group): 사용자들을 묶는 단위.
  • 예: "개발자" 그룹에 권한을 부여하면 그 그룹에 속한 모든 사용자가 같은 권한을 갖는다.
  • 사람마다 일일이 주지 않고 그룹 단위로 관리하면 훨씬 깔끔하다.
  • 그룹은 사용자만 담을 수 있고, 그룹 안에 그룹은 못 넣는다.
• 3. 역할(Role): 비밀번호나 액세스 키가 없는 자격 증명으로, 임시 권한을 빌려주는 용도다.
  • 예: EC2 인스턴스가 S3에 접근해야 할 때 EC2에 역할을 부여하면, 액세스 키를 코드에 박지 않고도 안전하게 권한을 얻는다.
• 4. 정책(Policy): 권한을 정의하는 JSON 문서.
  • "어떤 작업(Action)을, 어떤 리소스(Resource)에, 허용(Allow)/거부(Deny)할지"를 적는다.
  • 정책을 사용자·그룹·역할에 붙여서 권한을 부여한다.

[정책(Policy)]  ── 권한 규칙을 정의 (JSON)
      │ 붙인다
      ▼
[사용자/그룹/역할] ── 실제 자격 증명에 권한 적용

"EC2 인스턴스가 S3에 접근해야 하는데 어떻게 권한을 주는 게 안전한가?"라는 문제가 나오면 답은 거의 항상 IAM 역할(Role)이다. 액세스 키를 코드나 인스턴스에 하드코딩하는 것은 보안상 최악의 선택이다.

사용자와 역할, 무엇이 다른가

네 구성요소 중 헷갈리기 쉬운 짝이다.

핵심 차이는 "계속 가지고 있느냐, 잠깐 빌리느냐"다. 사원증은 지갑에 늘 들어 있지만 임시 출입증은 볼일이 끝나면 반납한다. 반납되는 자격 증명은 새어 나가도 곧 쓸모가 없어지므로 훨씬 안전하다.

정책은 허용만 적는 게 아니다

문서 문법까지 외울 필요는 없고, 아래 세 가지만 잡아두면 이 시험 수준에서는 충분하다.

• 기본은 거부다. 아무 정책도 붙지 않은 사용자는 아무것도 못 한다. 권한은 명시적으로 허용해야 생긴다.
• 명시적 거부(Deny)가 항상 이긴다. 한쪽이 허용하고 다른 쪽이 거부하면 결과는 거부다.
• 정책은 사용자·그룹·역할 어디에든, 여러 개를 겹쳐 붙일 수 있다.

[아무 정책 없음]      → 아무것도 못 함 (기본은 거부)
[허용 정책 붙임]      → 그 작업만 가능
[허용 + 거부 둘 다]   → 거부 (명시적 거부가 우선)

그룹은 왜 쓰나

사용자가 세 명일 때는 한 명씩 권한을 줘도 된다. 서른 명이 되면 이야기가 달라진다. 개발자 12명에게 똑같은 권한을 하나씩 따로 붙여 놨다고 가정한다. 개발팀 전체에 새 권한이 필요해지면 같은 작업을 12번 반복해야 하고, 한 명을 빠뜨리면 "왜 나만 안 되지?"가 시작된다. 반대로 "개발자" 그룹에 정책 하나를 붙여두면 수정도 한 번이면 끝나고, 새 팀원은 그룹에 넣기만 하면 된다.

⚠️ 함정: 그룹은 사용자만 담을 수 있다. 그룹 안에 다른 그룹을 넣어 계층 구조를 만들 수는 없다. 또 그룹 이름으로 로그인하거나 그룹에 액세스 키를 발급받을 수도 없다 — 그룹은 권한을 묶어두는 상자일 뿐 자격 증명이 아니다.

직원 40명 규모의 한 물류 회사가 AWS로 옮기면서 초기에는 편의상 계정 하나를 팀 전체가 공유했다. 어느 날 배포 실수로 서버가 삭제됐는데, 기록을 열어보니 모든 작업이 같은 계정 이름으로 남아 있어 누가 무엇을 했는지 구분할 수 없었다. 이후 이 회사는 사람마다 IAM 사용자를 만들고 직무별 그룹으로 권한을 나눴다. 계정 공유가 위험한 이유는 권한이 넓어서만이 아니라 책임이 흐려지기 때문이다.

사용자는 사원증을 발급받은 개인이고, 그룹은 비슷한 사람끼리 묶어 관리하는 단위다. 서비스에는 임시 출입증(역할)을 빌려주고, 열 수 있는 문의 목록은 정책에 적는다.

루트 사용자 보호와 MFA

AWS 계정을 처음 만들면 루트 사용자(Root User)가 생긴다. 모든 것을 할 수 있는 최고 권한자라서 탈취되면 재앙이므로, AWS는 다음을 강하게 권고한다.

• 루트 사용자는 일상 작업에 사용하지 말 것. 대신 IAM 사용자를 만들어 사용한다.
• 루트 사용자에 MFA(다중 인증)를 반드시 활성화한다.
• 루트 액세스 키는 만들지 말고, 있다면 삭제한다.

MFA(Multi-Factor Authentication)란

• 비밀번호(아는 것)에 더해, 휴대폰 앱의 일회용 코드나 보안 키(가진 것)를 추가로 요구하는 방식.
• 비밀번호가 유출돼도 두 번째 요소가 없으면 로그인할 수 없어 보안이 크게 강화된다.

시험에서 "계정 보안을 강화하는 가장 좋은 첫 단계"를 물으면 거의 항상 루트 사용자에 MFA 활성화 + 루트 사용 자제 + IAM 사용자 생성이 정답 묶음이다.

그러면 루트는 대체 언제 쓰나

"쓰지 말라"고만 하면 "그럼 왜 있나" 싶어진다. 루트 사용자는 계정 그 자체에 관한 일부 작업에 필요하다. 계정 설정 변경, 지원 플랜 변경, 계정 해지 같은 일들이다. 자주 생기는 일이 아니므로 평소에는 잠가두고 필요할 때만 꺼내 쓰는 것이 원칙이다.

1. 계정 생성            → 루트 사용자가 생김
2. 루트에 MFA 활성화     ← 가장 먼저 할 일
3. 관리자용 IAM 사용자 생성
4. 이후 일상 작업은 전부 IAM 사용자로
5. 루트 자격 증명은 금고에 넣듯 보관

집으로 치면 루트는 모든 문을 여는 마스터키다. 금고에 넣어두고, 평소 출입은 각자의 열쇠로 한다.

함정: "루트 사용자에게 최소 권한 정책을 붙여 권한을 제한한다" 같은 선택지가 보이면 오답이다. 루트는 권한을 깎아서 안전하게 만드는 대상이 아니라 아예 쓰지 않는 방식으로 보호한다. 마찬가지로 "루트 액세스 키를 만들어 자동화에 사용한다"도 어떤 상황에서든 오답이다.

마스터키에 해당하는 루트 계정은 MFA를 걸어 금고에 넣는다.

최소 권한 원칙(Least Privilege)

IAM 권한 설계의 황금률이다.

• "업무에 꼭 필요한 만큼만" 권한을 준다.
• 처음부터 넓게 주고 나중에 줄이는 게 아니라, 좁게 시작해 필요할 때 추가하는 방향이 안전하다.

"보안 모범 사례에 맞는 권한 부여 방식"을 묻는 문제의 답은 대부분 최소 권한 원칙이다. "필요 이상으로 넓은 권한"은 오답 신호다.

넓게 주고 나중에 줄이면 왜 안 되나

"일단 관리자 권한을 주고 문제가 생기면 줄이자"는 유혹이 크다. 현실에서는 줄이는 날이 오지 않는다. 권한을 회수하려면 "이 사람이 지금 무엇을 쓰고 있는지"를 전부 알아야 하는데, 그 확인 비용이 애초에 좁게 주는 비용보다 훨씬 크기 때문이다. 그래서 순서를 뒤집는다 — 최소한만 주고, 부족하다는 요청이 오면 그때 더한다.

시험에 이렇게 나온다

CLF 시험의 보안 문항은 표현이 꽤 정형화되어 있다. 아래 표현이 보이면 답의 방향이 거의 정해져 있다.

다음 글에서는 IAM 너머의 보안 서비스들 — WAF, Shield, GuardDuty, Inspector, Macie, Security Hub — 을 "무슨 위협을 막는가"로 묶어 한 줄씩 정리한다.

📖 용어

• 공동 책임 모델 : 클라우드 보안을 AWS와 고객이 나눠 맡는 방식. "클라우드 자체"는 AWS, "클라우드 안에 올린 것"은 고객 몫이다.
• 하이퍼바이저 : 물리 서버 한 대 위에 여러 가상 서버를 띄우는 가상화 계층. AWS가 책임진다.
• IAM : AWS에서 "누가 무엇을 할 수 있는지"를 정하는 서비스. 무료이고 리전 구분이 없다.
• 역할(Role) : 비밀번호 없이 임시로 권한을 빌려주는 자격 증명. EC2 같은 서비스에 붙여서 쓴다.
• 정책(Policy) : 어떤 작업을 어떤 리소스에 허용/거부할지 적어둔 JSON 규칙 문서.
• 루트 사용자 : 계정을 만들 때 생기는 최고 권한 계정. 평소엔 쓰지 않고 잠가두는 것이 원칙이다.
• 액세스 키 : 프로그램이 AWS를 호출할 때 쓰는 문자열 자격 증명. 코드에 박아두면 유출 위험이 크다.
• MFA(다중 인증) : 비밀번호에 더해 휴대폰 코드 같은 두 번째 확인 수단을 요구하는 로그인 방식.
• 최소 권한 원칙 : 일에 꼭 필요한 만큼만 권한을 주는 원칙. 넓게 주고 줄이는 대신 좁게 시작한다.
• 인증(Authentication) : "당신이 누구인지" 확인하는 단계. 비밀번호·MFA 코드로 통과한다.
• 인가(Authorization) : "그 작업을 해도 되는지" 판단하는 단계. 정책에 적힌 내용으로 결정된다.
• 그룹(Group) : 사용자들을 묶어 같은 권한을 한 번에 주는 상자. 그룹 안에 그룹은 못 넣는다.
• 명시적 거부(Deny) : 정책에 적힌 거부. 다른 정책이 허용해도 거부가 이긴다. 정책이 하나도 없으면 기본은 거부다.
• 관리형 서비스 : 운영체제·엔진 관리를 AWS가 대신해 주는 서비스(RDS, Lambda 등). 그래도 데이터와 권한은 고객 몫이다.
• of the cloud / in the cloud : 클라우드 "자체"의 보안(AWS 몫) / 클라우드 "안에 올린 것"의 보안(고객 몫)을 가르는 표현.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

공동 책임 모델에서 다음 중 항상 고객의 책임에 해당하는 것은?

• A데이터센터의 물리적 보안
• B하이퍼바이저(가상화 계층)의 보안
• CS3에 저장한 데이터의 접근 권한 설정
• D서버 하드웨어의 유지보수

문제 2

EC2 인스턴스에서 실행되는 애플리케이션이 S3 버킷에 접근해야 한다. 가장 안전한 권한 부여 방식은?

• A액세스 키를 애플리케이션 코드에 하드코딩한다
• BEC2 인스턴스에 IAM 역할(Role)을 부여한다
• C루트 사용자의 자격 증명을 사용한다
• D모든 사용자에게 관리자 권한을 준다

문제 3

AWS 계정 보안을 강화하기 위한 모범 사례로 옳지 않은 것은?

• A루트 사용자에 MFA를 활성화한다
• B일상 작업은 루트 대신 IAM 사용자로 수행한다
• C루트 사용자의 액세스 키를 만들어 자동화에 사용한다
• D최소 권한 원칙에 따라 권한을 부여한다

문제 4

여러 IAM 사용자에게 동일한 권한을 효율적으로 부여하고 관리하려면 가장 적절한 방법은?

• A사용자마다 정책을 개별적으로 작성한다
• BIAM 그룹에 정책을 붙이고 사용자를 그룹에 추가한다
• C모든 사용자를 루트 사용자로 통합한다
• D사용자마다 별도의 역할을 만든다

문제 5

IAM에 대한 설명으로 옳은 것은?

• AIAM은 리전별로 따로 설정해야 하는 리전 서비스다
• BIAM 사용은 추가 요금이 부과된다
• CIAM은 글로벌 서비스이며 사용에 추가 요금이 없다
• DIAM 정책은 허용(Allow)만 정의할 수 있다