'클라우드가 알아서 해 준다' 가 끝나는 지점

한 줄 요약

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

왜 이게 필요했나

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

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

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

어떻게 동작하나

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

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

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

자주 착각하는 다섯 가지

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

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

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

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

현장에서 만나는 모습

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

다음에 볼 것

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