사고 & 취약점

Capital One 데이터 유출 사고(2019) — 단 하나의 SSRF가 1억 건이 넘는 기록을 유출시킨 경위와 방어법

2019년 Capital One에서 약 1억 600만 건의 기록이 유출되었습니다. 단 하나의 SSRF가 클라우드 메타데이터 엔드포인트에 도달해 과도한 권한의 IAM 자격 증명을 탈취하고 S3를 복사했습니다. 공격 사슬을 방어 지도로 풀이하고, 목적지 허용 목록·IMDSv2·IAM 최소 권한 같은 대책을 제시합니다.

게시 2026-06-07 업데이트 2026-06-07 7분 읽기

저희는 실제 공개 사고를 단순한 뉴스 재방송이 아니라 "이것을 어떻게 방어할 것인가"의 관점으로 읽습니다. 이 글은 공개 기록(규제 기관, 보도, 학술 분석, 공식 발표)에 근거하며, 출처는 글 끝에 명시합니다.

1억 600만

피해자 수(미국/캐나다)

약 14만

사회보장번호(SSN)

8천만 달러

OCC 과징금

IMDSv2

이 사고가 도입을 촉발

사건 기록

대상: Capital One(미국 주요 은행)
공개: 2019년 7월 29일(7월 19일 탐지 / 3월 침입)
분류: SSRF로 시작된 클라우드 자격 증명 탈취 및 데이터 유출
규모: 미국/캐나다 약 1억 600만 명(SSN 약 14만 건, 연동된 은행 계좌번호 약 8만 건 포함)
근본 원인: SSRF 결함 + 보호되지 않은 메타데이터 엔드포인트 + 과도한 권한의 IAM 역할
진짜 대책: 심층 방어: 목적지 허용 목록, IMDSv2, IAM 최소 권한

무슨 일이 있었나(쉽게 풀이)

Capital One은 신청 처리의 일부를 클라우드에서 운영하고 있었습니다. 그 앞단에 있던 구성 요소(리버스 프록시 / WAF로 동작)에 SSRF 결함이 있었습니다. 즉 외부에서 지정한 목적지로 서버를 대신해 요청을 보내도록 만들 수 있었습니다.

클라우드 VM에는 내부에서만 도달할 수 있는 특별한 메타데이터 엔드포인트가 있는데, 이 엔드포인트는 해당 머신에 부여된 임시 자격 증명을 반환합니다. 공격자는 SSRF를 이용해 이 내부 엔드포인트에 도달해 키를 획득했습니다. 그 뒤에 있던 IAM 역할(공개 기록에서 ISRM-WAF-Role로 보고됨)은 스토리지를 광범위하게 읽을 수 있는 권한을 갖고 있었기 때문에, 약 700개 스토리지 버킷(S3)의 내용이 그대로 복사되어 빠져나갔습니다.

SSRF가 존재하면 '내부에서만 도달 가능'은 곧 '내부'가 된다

메타데이터 엔드포인트는 "외부에서 도달 불가능"이라는 전제로 보호되고 있었습니다. 그러나 SSRF는 서버 자신이 그 접근을 대리하게 만들어 그 전제를 무너뜨립니다. "내부 전용이므로 안전하다"는 가정은 입구의 SSRF 하나로 붕괴합니다.

공격 사슬은 곧 방어 지도다

중요한 것은 이것이 4단계 사슬이었고 각 단계마다 멈출 수 있는 지점이 있었다는 점입니다. 공격 레시피가 아니라 "어디서 끊을 수 있었는가"로 읽어 주십시오.

① 진입: SSRF

결함으로 인해 서버가 임의의 목적지로 요청을 대리한다.

⊘ 멈춤: 목적지 허용 목록

↓

② 내부 메타데이터 엔드포인트에 도달

"내부 전용" 엔드포인트가 SSRF를 통해 도달 가능해진다.

⊘ 멈춤: IMDSv2(토큰 필수 + 홉 제한)

↓

③ IAM 임시 자격 증명 획득

머신의 역할이 임시 키를 반환한다.

⊘ 멈춤: 최소 권한 역할(스토리지 전체 읽기 금지)

↓

④ 스토리지(S3) 일괄 복사

약 700개 버킷이 그대로 복사되어 빠져나간다.

⊘ 멈춤: 이그레스 제어 + 비정상 조회 탐지

각 단계마다 '멈출' 수 있었다. 심층 방어란 하나의 벽이 아니라 이런 멈춤 지점을 여러 개 두는 것이다.

공개된 타임라인

2019-03
클라우드 환경에 대한 무단 접근(이후에 확정됨).
2019-07-17
외부 제보(GitHub 게시물)가 이상을 알린다.
2019-07-19
Capital One이 내부 조사로 유출을 확인.
2019-07-29
공개 발표. 전직 AWS 엔지니어가 FBI에 체포됨.
2019-11
AWS가 SSRF에 대한 심층 방어책으로 IMDSv2를 발표.
2020-08
OCC가 클라우드 이전 전 위험 평가가 미흡했다는 점을 들어 약 8천만 달러의 과징금 부과.

근본 원인은 하나의 실수가 아니라 계층이 차례로 무너진 것

이를 "SSRF" 하나로 치부하면 반복됩니다. 실제로는 세 계층이 순서대로 무너졌습니다.

당시의 상태

진입점에서 목적지 검증이 없음(임의의 요청 대리가 가능)
메타데이터 엔드포인트가 토큰 없이 키를 반환(레거시 모드)
머신의 IAM 역할이 스토리지를 광범위하게 읽을 수 있음(과도한 권한)

마땅히 그래야 할 상태(예방)

목적지를 허용 목록으로 제한하고 내부 주소로의 대리 접근을 거부
메타데이터는 IMDSv2로: 세션 토큰 필수 + 홉 제한이 대리 도달을 차단
IAM 역할은 최소 권한으로: 실제로 필요한 버킷과 동작만 허용

'책임 공유'의 경계선이 어디에 있는가

클라우드 제공자는 기반을 보호하지만, SSRF를 고치고, IAM 권한을 설계하고, 메타데이터를 보호하는 것은 고객의 책임입니다. 과징금 자체도 "클라우드 이전 전 위험 평가 미흡"을 지적했습니다. 편리한 플랫폼을 이용하는 것이 문제가 아니라, 경계선의 자기 쪽을 충분히 설계했는지가 문제입니다.

여러분의 환경에서 막는 법

규모에 상관없이 작동하는, 우선순위 순서의 대책입니다. "URL을 받아서 가져온다"거나 "웹훅/이미지를 전달한다"는 기능이 하나라도 있다면 이것은 여러분의 이야기입니다.

아웃바운드 목적지를 허용 목록으로(입구에서 SSRF 차단)

서버가 사용자가 제공한 URL로 접근을 대리하는 곳에서는 허용된 목적지로만 제한하십시오. 내부 주소(메타데이터 엔드포인트, 사설 네트워크)로의 도달은 기본적으로 거부합니다. SSRF 용어 설명에서 사람들이 놓치기 쉬운 검증의 함정(리다이렉트 추종, DNS 리바인딩)을 다룹니다.

메타데이터에 IMDSv2 강제

클라우드 메타데이터 엔드포인트를 토큰 필수, 홉 제한 모드(AWS의 IMDSv2)로 제한하십시오. 이것만으로도 SSRF를 통한 자격 증명 탈취가 훨씬 어려워집니다. 핵심은 레거시 모드를 비활성화하는 것입니다.

IAM 최소 권한(폭발 반경 축소)

유출된 키의 피해를 가두기 위해, 머신/서비스의 권한을 필요한 대상과 동작으로만 한정하십시오. "그냥 스토리지 전체 허용"은 하나의 유출을 전면적인 유출로 만듭니다.

이그레스 및 이상 탐지

아웃바운드 트래픽을 필요한 목적지로 제한하고 대량 조회의 급증 같은 이상을 탐지하십시오. 입구를 막지 못하더라도 유출을 알아채는 계층을 남겨 둡니다.

본 사이트의 설계와 겹치는 지점

본 사이트는 URL을 다루는 기능을 검증된 도메인으로만 설계합니다(설계상 SSRF에 안전). 이 사고는 저희가 기반으로 삼는 원칙 — 입구를 검증하고, 최소 권한을 적용하며, "내부"라는 가정에 의존하지 않는다 — 이 왜 필요한지를 가장 웅변적으로 보여주는 사례입니다. 편리함 뒤에서, 경계선의 자기 쪽은 스스로 설계해야 합니다.

출처(공개 기록)

여기 담긴 사실은 다음 공개 정보에 근거합니다. 저희는 재현 절차나 페이로드를 다루지 않으며, 방어적 교훈만 다룹니다.

Krebs on Security, "What We Can Learn from the Capital One Hack" (2019) — krebsonsecurity.com
ACM Transactions on Privacy and Security, "A Systematic Analysis of the Capital One Data Breach" — dl.acm.org
CyberScoop, "US financial regulator fines Capital One $80 million over data breach" (2020) — cyberscoop.com

이어서 읽기

FAQ

QCapital One 유출 사고의 근본 원인은 무엇이었나요?

단일 원인이 아니라 여러 방어 계층이 순서대로 무너진 결과입니다. 진입점은 SSRF 취약점(서버가 임의의 목적지로 요청을 대리 전송하도록 만들 수 있는 결함)이었습니다. 거기서부터 클라우드 메타데이터 엔드포인트에 도달할 수 있었고, 그 뒤에 있던 IAM 역할이 광범위한 권한을 갖고 있었기 때문에 임시 자격 증명으로 공격자가 스토리지 전체를 읽을 수 있었습니다.

Q제 소규모 서비스에도 해당되는 이야기인가요?

그렇습니다. SSRF는 'URL을 받아서 가져온다'는 평범한 기능(미리보기, 웹훅)에서 발생합니다. 클라우드에서는 메타데이터 엔드포인트를 통한 자격 증명 탈취가 규모와 관계없이 일어납니다. 여기서 다루는 세 가지 대책(IMDSv2, IAM 최소 권한, 목적지 허용 목록)은 개인 프로젝트에서도 그대로 작동합니다.

QWAF가 있었다면 막을 수 있었을까요?

아니요. 이 사고에서는 WAF 역할을 하던 구성 요소 자체가 SSRF의 발판이 되었습니다. WAF는 일부 공격을 차단하지만, 잘못 설정하면 오히려 구멍이 됩니다. 'WAF가 있으니 안전하다'는 오해입니다. 입력 검증, 최소 권한, 메타데이터 보호가 진짜 방어책입니다.