네 가지 사고 경로와 각각의 차단선

한 줄 요약

클라우드 보안 사고는 대개 정교한 공격이 아니라 우리가 열어 둔 문으로
들어옵니다. 경로가 몇 가지로 정해져 있고, 각각에 대응하는 차단선도 정해져
있습니다.

> 방어를 위한 내용입니다. 각 경로마다 '무엇이 잘못됐고 무엇으로 막는가' 를
> 짝지어 다룹니다.

왜 이게 필요했나

클라우드 사고는 제품마다 달라 보여도 공개 설정, 유출된 자격증명, 과도한 권한,
메타데이터 악용이라는 몇 개의 경로로 수렴합니다. 경로별 최초 차단선과 사고 뒤
증거 보존 순서를 알아야 같은 설정 실수가 조직 전체 침해로 번지는 것을 막습니다.

어떻게 동작하나

경로 1 — 공개된 스토리지

가장 흔합니다. 버킷을 공개로 열어 두고 잊는 것입니다.

어떻게 일어나나 — 임시로 파일을 공유하려고 열었다가 되돌리지 않음.
또는 정적 웹사이트 호스팅 설정을 하다 전체를 공개로 바꿈.

차단선

• 계정 수준에서 공개 접근 차단을 켜 둔다(개별 버킷 설정을 무력화)
• 조직 가드레일로 공개 설정 자체를 Deny
• 설정 감시로 공개된 버킷을 자동 탐지해 알림

경로 2 — 유출된 자격증명

어떻게 일어나나 — 저장소 커밋, CI 로그 출력, 스크린샷, 채팅.
공개 저장소에 올라간 키는 분 단위로 발견됩니다.

차단선

• 애초에 장기 키를 만들지 않는다(역할·OIDC)
• 커밋 전 시크릿 스캔을 훅으로 건다
• 이상 사용 탐지 — 평소와 다른 리전·시각·API 호출량
• 예산 알림 — 채굴 인스턴스는 요금 급증으로 먼저 드러난다

마지막 항목이 의외로 실효가 큽니다. 사고를 막지는 못하지만 몇 시간 안에
알게 됩니다.

경로 3 — 과도한 권한의 오용

어떻게 일어나나 — 내부자 실수 또는 침해된 계정이 넓은 권한을 그대로 사용.
s3:* 를 가진 주체가 침해되면 삭제까지 가능합니다.

차단선

• 최소권한 + 권한 경계
• 삭제·권한 변경 같은 고위험 동작에 조건 강화(MFA 요구 등)
• 중요 데이터에 버전 관리와 삭제 방지를 켠다
• 백업을 다른 계정에 둔다 — 이게 결정적입니다

침해된 계정에서 백업까지 지울 수 있으면 백업이 아닙니다. 계정 경계를 넘겨
두어야 랜섬 상황에서 살아남습니다.

경로 4 — 메타데이터 서비스 남용 (SSRF)

어떻게 일어나나 — 애플리케이션에 URL 을 넣으면 서버가 그 주소로 요청을
보내는 기능(이미지 가져오기 등)이 있고, 공격자가 인스턴스 메타데이터 주소를
넣습니다. 그러면 그 인스턴스의 임시 자격증명이 응답으로 나옵니다.

차단선

• 메타데이터 서비스의 최신 버전만 허용(토큰이 필요한 방식)
• 애플리케이션에서 사용자 제공 URL 을 검증 — 사설 대역 차단
• 인스턴스 역할의 권한을 최소로. 유출돼도 할 수 있는 게 적게

사고가 났을 때의 순서

1. 범위를 정한다 — 어떤 자격증명·자원이 관련됐나
2. 차단한다 — 키 폐기, 역할 신뢰 정책 수정, 세션 무효화
3. 보존한다 — 로그와 스냅샷을 먼저 확보. 지우면 조사가 끝난다
4. 조사한다 — 감사 로그로 무엇을 했는지 타임라인 복원
5. 막는다 — 같은 경로가 다시 열리지 않게 가드레일 추가

2번에서 자주 놓치는 것이 이미 발급된 임시 자격증명입니다. 역할의 정책을
바꿔도 이미 나간 세션은 만료까지 유효할 수 있어, 세션 무효화를 따로 해야 합니다.

평시에 해 둘 다섯 가지

1. 감사 로그를 켜고 다른 계정에 보관한다
2. 루트 계정에 MFA 를 걸고 일상적으로 쓰지 않는다
3. 예산 알림을 건다 — 채굴성 사용량 급증을 뒤늦게 발견하는 보조 탐지선이다
4. 공개 접근 차단을 계정 수준에서 켠다
5. 백업을 다른 계정에 둔다

현장에서 만나는 모습

• 평소와 다른 리전에서 권한 탐색이 이어짐 → 감사 로그 기반 이상 행위 알림이 먼저 울림.
• 뒤늦게 요금도 급증함 → 비용 알림은 유용했지만 침해의 최초 탐지선은 아니었다.
• 키를 폐기했는데 공격이 계속됨 → 이미 발급된 세션이 살아 있었다.
• 랜섬 후 백업도 지워짐 → 같은 계정에 있었다.

다음 코스

네트워크. 권한이 '누가' 를 정한다면 네트워크는 '어디서' 를 정합니다.