Four Incident Paths and the Line That Stops Each

한 줄 요약

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

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

왜 이게 필요했나

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

어떻게 동작하나

경로 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. 백업을 다른 계정에 둔다

권한을 좁히는 일을 실제로 굴러가게 만들기

최소 권한은 누구나 동의하지만 실행되지 않는다. 좁히다가 무언가 멈추면 그 사람이 욕을 먹기 때문이다. 그래서 순서를 뒤집는다: 먼저 재고, 그다음 좁힌다.

실제로 쓴 권한을 기준으로 삼는다. 클라우드마다 접근 기록을 분석해 "지난 90일 동안 이 역할이 실제로 호출한 API" 를 뽑아 주는 도구가 있다. 사람이 상상해서 정책을 쓰는 것보다 정확하고, 무엇보다 무엇이 깨질지 미리 안다.

한 번에 막지 말고 경고부터 남긴다. 정책을 두 개로 나눠, 실제로 막는 것은 그대로 두고 좁힌 정책은 "이 요청은 새 정책에서는 거부됩니다" 를 기록만 하게 한다. 며칠 지켜보고 기록이 조용해지면 그때 바꾼다.

긴 수명의 열쇠를 없애는 것이 정책을 다듬는 것보다 효과가 크다. 유출 사고의 대부분은 정책이 넓어서가 아니라 어딘가에 적혀 있던 액세스 키 때문이다. 사람은 SSO 로, 워크로드는 역할 위임이나 OIDC 연동으로 바꾸면 훔쳐 갈 열쇠 자체가 사라진다. CI 에서 클라우드에 붙는 자리가 특히 그렇다.

남은 열쇠는 만료를 강제한다. 도는 것과 안 도는 것을 목록으로 관리하지 말고, 90일이 지나면 자동으로 비활성화되게 만든다. 사람의 성실함에 기대는 통제는 바쁜 분기에 반드시 무너진다.

권한 경계를 하나 두면 실수의 폭이 줄어든다. 개발자에게 역할을 만들 권한을 주되, 그 역할이 가질 수 있는 권한의 상한을 정해 둔다. 그러면 스스로 권한을 넓히는 경로가 막히면서도 일상 작업은 남에게 부탁하지 않아도 된다. 요청과 승인이 줄어드는 만큼 실제로 지켜진다.

마지막은 기록이다. 감사 로그를 쓰기 전용 저장소에 따로 보내고, 그 저장소를 지울 수 있는 사람을 다른 계정으로 분리한다. 침해 뒤 가장 먼저 하는 일이 로그를 지우는 것이므로, 로그가 남아 있는지가 조사할 수 있는지를 가른다.

현장에서 만나는 모습

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

다음 코스

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