Where "The Cloud Takes Care of It" Ends

한국어 원문으로 표시합니다.

한 줄 요약

클라우드 사업자는 인프라의 보안(security of the cloud) 을 책임지고, 우리는 그 위에 올린 것의 보안(security in the cloud) 을 책임집니다. 사고의 대부분은 이 경계를 오해한 자리에서 납니다.

Concept map: S3 버킷을 공개로 열어 둔 것 · 데이터와 접근 권한 · 켜야 · 환불 기준

왜 이게 필요했나

뉴스에 나오는 "AWS 에서 고객 데이터 유출" 사고를 열어 보면 거의 전부 S3 버킷을 공개로 열어 둔 것입니다. AWS 는 뚫리지 않았습니다. 설정을 그렇게 한 쪽은 고객입니다.

반대로 하이퍼바이저 취약점이나 데이터센터 물리 침입은 우리가 손댈 수 없는 영역이고, 그건 사업자 책임입니다.

경계를 모르면 두 방향으로 틀립니다 — 사업자가 해 줄 일을 우리가 중복으로 하거나(낭비), 우리가 할 일을 사업자가 해 줄 거라 믿거나(사고).

어떻게 동작하나

경계는 서비스 모델에 따라 움직인다

        IaaS(EC2)      PaaS(RDS)       SaaS(Workspaces)
데이터        고객           고객              고객      ← 항상 고객
접근 권한     고객           고객              고객      ← 항상 고객
애플리케이션  고객           고객            사업자
런타임        고객           사업자          사업자
OS 패치       고객           사업자          사업자
하이퍼바이저  사업자         사업자          사업자
물리          사업자         사업자          사업자

위 두 줄 — 데이터와 접근 권한 — 은 어떤 모델에서도 고객 몫입니다. "관리형이니 안전하다" 가 성립하지 않는 이유가 여기 있습니다. RDS 를 써도 비밀번호를 admin/admin 으로 두면 그건 우리 사고입니다.

자주 착각하는 다섯 가지

믿음	실제
"관리형이니 백업도 알아서"	자동 백업은 대개 켜야 하고, 보존 기간도 우리가 정한다
"암호화는 기본"	저장 암호화는 옵션인 경우가 많고, 전송 암호화는 앱이 강제해야 한다
"패치는 사업자가"	IaaS 의 OS 패치는 고객 몫. 관리형이라도 유지보수 창을 우리가 정한다
"삭제하면 사라진다"	스냅샷·복제본·로그에 남는다. 백업 보존이 곧 삭제 지연이다
"가용성 99.99% 보장"	SLA 는 환불 기준이지 무장애 약속이 아니다

마지막 줄이 특히 중요합니다. SLA 99.99% 는 "연간 약 52분까지는 정상 범위이고, 넘으면 요금 일부를 크레딧으로 돌려준다" 는 계약입니다. 우리 서비스가 그 52분을 견딜 수 있는지는 우리가 설계해야 합니다.

그래서 우리가 반드시 하는 것

접근 권한 — 누가 무엇을 할 수 있는지. 다음 코스의 주제입니다.
데이터 분류와 암호화 — 무엇이 민감한지 정하고, 그것부터 암호화합니다.
백업과 복구 리허설 — 백업을 켜는 것과 복구되는 것은 다릅니다.
설정 감시 — 공개된 버킷·열린 보안그룹을 자동으로 찾아냅니다.
로그 보존 — 사고가 났을 때 조사할 재료. 사업자가 남겨 주지 않습니다.

서비스 유형마다 경계가 다르다

"공동 책임" 은 한 줄이지만 실제 경계는 서비스마다 달라집니다.

	내가 하는 것	제공자가 하는 것
IaaS (EC2)	OS 패치, 방화벽, 애플리케이션, 데이터	하이퍼바이저, 물리 보안, 네트워크
PaaS (RDS)	스키마, 계정, 파라미터, 백업 정책	OS·엔진 패치, 하드웨어
SaaS (S3)	권한, 암호화 선택, 수명주기	그 밖의 전부
서버리스 (Lambda)	코드, 의존성, 권한	런타임, 확장, 패치

위로 갈수록 내 몫이 줄지만 데이터와 권한은 어느 층에서도 내 몫 입니다. 이 두 가지가 실제 사고의 대부분입니다.

실제로 나는 사고의 순위

순위	원인	누구 책임인가
1	잘못된 권한 설정(공개 버킷, 과한 IAM)	나
2	자격 증명 유출(git 커밋, 로그)	나
3	패치 안 한 애플리케이션 의존성	나
4	백업 없음·복구 미검증	나
5	제공자 장애	제공자(그래도 영향은 내가 받는다)

클라우드 제공자의 결함으로 데이터가 새는 일은 드뭅니다. 대부분은 설정입니다. 그래서 "클라우드라서 안전하다" 는 문장은 위험합니다 — 안전해지는 것은 내가 안 하던 일 중 일부일 뿐이고, 새로 생기는 일(권한 설계, 자격 증명 관리)이 더 많습니다.

5번도 대비해야 한다

제공자 책임이라고 손 놓을 수는 없습니다. 장애가 나면 사용자는 우리에게 항의합니다.

다중 AZ 는 기본 — 단일 AZ 구성은 그 AZ 가 죽으면 함께 죽습니다.
리전 장애는 계획으로만 — 다중 리전은 비쌉니다. RTO 를 정하고 그에 맞는 수준을 고릅니다. "몇 시간 안에 다른 리전에서 복구" 도 유효한 답입니다.
의존하는 관리형 서비스의 SLA 를 곱한다 — DB 99.95%, 큐 99.9%, 스토리지 99.99% 를 직렬로 쓰면 전체는 99.84% 입니다. 월 70분입니다.

마지막 줄이 설계에 영향을 줍니다. 가용성을 올리려면 직렬 의존을 줄이는 것 이 각 요소를 좋게 만드는 것보다 효과가 큽니다.

현장에서 만나는 모습

감사에서 "암호화 여부" 를 물었는데 아무도 답을 모름 → 분류가 없었다.
장애 후 SLA 를 근거로 보상을 요구 → 크레딧 몇 달러가 전부였다.
관리형 DB 를 썼는데 복구가 안 됨 → 자동 백업이 꺼져 있었다.

다음에 볼 것

서비스 모델(IaaS/PaaS/SaaS)이 이 경계를 구체적으로 어떻게 움직이는지 봅니다.