Day 3 - 공동 책임 모델

한 문장으로 시작하는 핵심

공동 책임 모델은 이 한 문장으로 요약된다.

AWS는 "클라우드 자체(OF the cloud)"의 보안을, 고객은 "클라우드 안(IN the cloud)"의 보안을 책임진다.

임대 아파트에 비유하면 이렇다.

• 건물주(AWS): 건물 골조, 전기 배선, 공동 현관 잠금 장치, 화재 경보기.
• 세입자(고객): 자기 집 문 잠그기, 누구에게 열쇠를 줄지 정하기, 집 안의 물건 관리.
• 건물이 튼튼해도 세입자가 문을 열어 두면 도둑이 든다 — 그건 건물주 잘못이 아니다.

왜 이런 모델이 필요한가

온프레미스 시절에는 이런 그림이 필요 없었다. 건물부터 코드까지 전부 우리 책임이었기 때문이다. 그런데 클라우드로 옮기면 일부는 AWS가, 일부는 고객이 맡게 된다. 여기서 위험한 착각이 생긴다.

"AWS가 알아서 다 지켜 주겠지."

실제로 클라우드에서 발생하는 보안 사고의 상당수는 AWS 인프라가 뚫려서가 아니라, 고객이 자기 몫을 설정하지 않아서 일어난다. 저장소를 실수로 전체 공개해 두거나, 관리자 열쇠를 아무 데나 흘리거나, 방화벽을 전 세계에 열어 두는 식이다. 공동 책임 모델은 "어디까지가 내 몫인지 착각하지 말라"는 경고문에 가깝다.

렌터카로 바꿔 봐도 같다.

⚠️ 함정: 공동 책임 모델을 "보안 업무를 반씩 나눠 갖는다"로 이해하면 틀린다. 겹치는 구간 없이 층으로 갈라져 있다. 아래층(시설·하드웨어·가상화)은 전부 AWS, 위층(내가 올린 것과 설정)은 전부 고객이다. 그리고 층 자체가 서비스 종류에 따라 위아래로 움직인다는 점이 이 모델의 핵심이다.

AWS의 책임: "클라우드 자체"의 보안

AWS는 서비스를 돌리는 기반 인프라를 책임진다. 고객이 손댈 수 없고, 손댈 필요도 없는 영역이다.

한마디로 콘크리트 바닥부터 가상화 계층까지가 AWS의 영역이다.

여기에는 고객이 아예 볼 수도, 손댈 수도 없는 것들이 들어간다. 데이터센터 주소도 공개되지 않고, 서버실에 들어가 볼 수도 없으며, 하이퍼바이저 설정을 바꿀 수도 없다. "고객이 손댈 수 없는 것 = AWS 책임"이라는 감각을 잡아 두면 관련 문항을 푸는 기준이 된다.

• 디스크가 고장 나서 교체하는 일 → 고객은 알지도 못한다 → AWS
• 데이터센터 경비원과 출입 카드 → 고객이 관여할 수 없다 → AWS
• 리전과 AZ를 잇는 광케이블 → 고객이 만질 수 없다 → AWS
• 폐기하는 저장 장치의 물리적 파기 → 고객이 할 수 없다 → AWS

AWS 문서는 이를 "Security OF the Cloud"라고 부른다. 반대로 고객 몫은 "Security IN the Cloud"다. 시험에서는 이 영어 문구가 보기 그대로 등장하는 경우가 많으니, 한국어 해석뿐 아니라 of / in이라는 전치사 하나로 갈린다는 사실을 기억한다. of = 클라우드라는 시설 그 자체(AWS), in = 그 안에 내가 넣어 둔 것(고객).

고객의 책임: "클라우드 안"의 보안

고객은 AWS가 제공한 기반 위에 자기가 올려 놓고 설정하는 모든 것을 책임진다.

"데이터, 그리고 누가 접근할 수 있는지(IAM)"는 어떤 서비스를 쓰든 항상 고객 책임이다. AWS가 인프라를 아무리 안전하게 만들어도, 고객이 비밀번호를 약하게 설정하거나 데이터를 아무에게나 공개하면 사고가 난다. 이 두 가지는 절대 AWS가 대신해 주지 않는다.

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

공동 책임 모델의 경계선은 고정된 게 아니라, 어떤 서비스를 쓰느냐에 따라 위아래로 움직인다. 더 "관리형(managed)"인 서비스를 쓸수록 고객 책임은 줄어든다.

• EC2(가상 서버): 운영체제 패치, 앱 설치, 방화벽 설정까지 고객이 직접 한다. 책임이 가장 많다.
• RDS(관리형 데이터베이스): 데이터베이스 엔진의 패치·백업은 AWS가 대신해 준다. 고객은 데이터와 접근 권한에 집중한다.
• S3 / Lambda(완전 관리형): 운영체제·서버를 아예 신경 쓸 필요가 없다. 고객은 데이터 분류와 접근 권한 정도만 책임진다.

서비스별로 경계선이 어떻게 움직이는지 항목 단위로 보면 훨씬 선명해진다.

표를 세로로 훑어보면 규칙이 보인다.

• 위쪽 줄(시설·하드웨어·가상화)은 어느 서비스를 쓰든 항상 AWS.
• 아래쪽 줄(애플리케이션·접근 규칙·데이터·IAM)은 어느 서비스를 쓰든 항상 고객.
• 움직이는 것은 가운데 줄(OS·엔진 패치·백업)뿐이다. 관리형 서비스일수록 이 가운데 부분이 AWS 쪽으로 넘어간다.

"서비스의 추상화 수준이 올라갈수록 고객 책임은 위로 좁아진다"는 원칙으로 기억하면 모든 문제가 풀린다. 같은 일을 EC2 → RDS → Lambda로 옮길수록 고객이 신경 쓸 부분이 줄어든다. 단, 데이터와 권한(IAM)만큼은 어느 단계에서도 고객 몫으로 남는다.

사내 데이터베이스를 클라우드로 옮긴다고 가정한다. 방법은 두 가지다. ① EC2에 직접 데이터베이스를 설치하는 방법 — 익숙한 방식 그대로 쓸 수 있고 세부 설정도 마음대로지만, OS 패치·DB 엔진 패치·백업 스크립트·장애 대응이 전부 고객 몫이다. ② RDS 같은 관리형 서비스를 쓰는 방법 — 세부 통제는 줄어들지만 패치와 백업 같은 반복 운영 업무를 AWS가 맡는다. 같은 데이터베이스인데 팀이 야근할 일의 양이 달라진다. 시험에서 "운영 부담을 줄이고 싶다", "패치 관리를 하고 싶지 않다"는 지문이 나오면 답은 관리형 서비스다.

나누는 것은 보안만이 아니다

"공동 책임 모델"이라는 이름 때문에 보안 이야기로만 생각하기 쉽지만, 실제로는 운영 전반이 같은 방식으로 나뉜다.

특히 규정 준수는 오해가 많다. "AWS가 인증을 받았으니 우리 서비스도 자동으로 준수된다"고 생각하면 틀린다. AWS가 보장하는 것은 기반 인프라 수준이고, 그 위에서 데이터를 어떻게 다루는지는 여전히 고객의 몫이다. 이런 구조를 "규정 준수의 상속(inheritance)"이라고 부른다 — 아래 계층의 준수 결과를 물려받되, 위 계층은 스스로 지켜야 한다.

고객은 감사나 심사를 받을 때 "AWS 인프라가 어떤 기준을 충족하는지"를 증빙해야 할 때가 있다. AWS는 이런 규정 준수 보고서를 고객이 직접 받아 볼 수 있는 창구를 제공하는데, 그 서비스가 AWS Artifact다. 이름 정도만 알아 두면 충분하다.

헷갈리기 쉬운 함정

시험에서 헷갈리게 만드는 보기들을 미리 정리해 둔다.

어떤 서비스를 쓰든 바뀌지 않는 두 목록

경계선이 움직인다는 말에 흔들리지 않으려면, 절대 안 움직이는 것부터 외워 두는 편이 빠르다.

언제나 고객 책임 (외워야 할 목록)

• 데이터의 분류 — 어떤 정보가 민감한지 판단하는 일
• IAM 자격 증명 관리 — 계정, 비밀번호, 액세스 키, 다중 인증(MFA) 설정
• 권한 부여 — 누구에게 무엇을 허용할지
• 게스트 OS 패치 (EC2처럼 고객이 OS를 다루는 경우)
• 보안 그룹 등 네트워크 접근 규칙 설정
• 암호화를 켤지 말지의 선택과 그 설정
• 직접 만든 애플리케이션 코드의 보안

언제나 AWS 책임 (외워야 할 목록)

• 물리적 시설 — 데이터센터 건물, 출입 통제, 경비, 화재·전력·냉방
• 하드웨어 — 서버, 스토리지, 네트워크 장비, 고장 교체, 폐기 장비의 물리적 파기
• 가상화 계층(하이퍼바이저)
• 글로벌 네트워크 인프라 — 리전·AZ를 잇는 회선
• 관리형 서비스의 OS·데이터베이스 엔진 패치

⚠️ 함정: 암호화는 보기에서 가장 자주 낚는 항목이다. AWS는 "암호화할 수 있는 기능과 도구"를 제공하지만, 그 기능을 켤지 말지, 어떤 데이터에 적용할지 정하는 것은 고객이다. "AWS가 모든 데이터를 자동으로 암호화해 준다" 같은 보기는 오답으로 보면 된다. 마찬가지로 백업도 AWS가 기능을 주지만 정책을 정하는 건 고객이다.

저장소를 실수로 전체 공개 설정해 두어 내부 자료가 인터넷에 노출되는 사고는 클라우드에서 드물지 않게 보고된다. 이때 AWS 인프라는 아무 문제 없이 정상 동작했다. 스토리지는 고객이 요청한 대로 "누구나 읽을 수 있게" 공개했을 뿐이다. 공동 책임 모델로 보면 접근 권한 설정은 고객 책임이므로 이 사고는 명백히 고객 영역이다. 아파트 비유로 돌아가면, 건물 현관은 멀쩡했는데 세입자가 자기 집 문을 열어 둔 상황이다.

시험에는 이렇게 나온다

공동 책임 모델 문항은 "이 항목은 누구 책임인가" 또는 "이런 상황에서 고객이 해야 할 일은"의 두 형태가 대부분이다.

빠르게 판단하는 요령은 두 가지다.

1. "내가 콘솔에서 클릭해 바꿀 수 있는가?" — 바꿀 수 있으면 고객 책임일 가능성이 높다.
2. "AWS 직원이 물리적으로 가서 해야 하는 일인가?" — 그렇다면 AWS 책임이다.

헷갈리는 짝들도 한 번 정리하고 넘어간다.

다음 글에서는 AWS가 "좋은 클라우드 설계란 무엇인가"를 정리한 Well-Architected Framework의 6대 기둥을 본다.

📖 용어

• 공동 책임 모델 : AWS와 고객이 보안·운영 책임을 어디서 나눠 갖는지 정해 놓은 그림.
• OF the cloud / IN the cloud : "클라우드 자체"(AWS 몫) / "클라우드 안에 내가 올린 것"(고객 몫).
• 하이퍼바이저(가상화) : 물리 서버 한 대 위에서 여러 가상 서버를 돌리는 기반 소프트웨어. AWS가 관리한다.
• 게스트 OS : EC2 가상 서버 안에서 도는 운영체제. 보안 패치는 고객이 직접 해야 한다.
• 관리형(managed) 서비스 : 패치·백업·확장 같은 운영 잡일을 AWS가 대신해 주는 서비스.
• IaaS : 서버·네트워크 같은 기초 인프라만 빌려주는 형태. EC2가 대표. 고객 책임이 가장 많다.
• 완전 관리형 : 서버·OS를 아예 신경 쓰지 않아도 되는 형태. S3·Lambda가 대표.
• 보안 그룹 : AWS 자원 앞에 두는 방화벽 규칙. 설정 책임은 고객에게 있다.
• 추상화 수준 : 내부 복잡함을 얼마나 가려 주는가의 정도. 높을수록 고객이 신경 쓸 일이 적다.
• Security OF the Cloud / IN the Cloud : AWS 공식 문구. of는 시설 자체(AWS 몫), in은 그 안에 올린 것(고객 몫).
• IAM 자격 증명 : 계정·비밀번호·액세스 키·MFA 등 신원을 증명하는 수단. 관리는 항상 고객 책임.
• MFA(다중 인증) : 비밀번호 외에 추가 인증 수단을 더 요구하는 방식. 설정은 고객이 한다.
• 데이터 분류 : 어떤 정보가 민감한지 등급을 나누는 일. AWS가 대신해 줄 수 없는 대표적 고객 업무.
• PaaS(관리형 플랫폼) : 실행 환경까지 제공되어 OS·엔진 패치를 AWS가 맡는 형태. RDS가 대표적이다.
• 운영 부담(운영 오버헤드) : 패치·백업·모니터링처럼 본업이 아닌 반복 업무. 관리형 서비스는 이걸 줄여 준다.

📝 연습 문제

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

문제 1

공동 책임 모델에서 AWS가 책임지는 영역을 가장 잘 설명한 것은?

• A클라우드 안(IN the cloud)의 보안
• B클라우드 자체(OF the cloud)의 보안
• C고객의 데이터 분류
• D고객의 IAM 권한 설정

문제 2

EC2 가상 서버를 운영할 때 고객의 책임에 해당하는 것은?

• A데이터센터의 물리적 출입 통제
• B하이퍼바이저(가상화) 보안
• C게스트 운영체제(OS) 보안 패치
• D서버 하드웨어 교체

문제 3

어떤 AWS 서비스를 쓰든 항상 고객의 책임으로 남는 것은?

• A하드웨어 유지보수
• B데이터와 접근 권한(IAM) 관리
• C데이터센터 냉방
• D글로벌 네트워크 인프라

문제 4

같은 작업을 EC2에서 Lambda 같은 완전 관리형 서비스로 옮기면 책임 경계는 어떻게 변하는가?

• A고객의 책임이 늘어난다
• B고객의 책임이 줄어든다
• C변하지 않는다
• DAWS의 책임이 사라진다

문제 5

다음 중 AWS가 아니라 고객이 책임지는 항목은?

• A보안 그룹(방화벽 규칙) 설정
• B데이터센터의 화재 경보 시스템
• C서버 가상화 계층의 보안
• D리전 간 네트워크 케이블 관리