1. 개요
1.1 사고 배경
Juspay는 인도의 핀테크 기업으로, 수백만 건의 일일 결제 트랜잭션을 처리하는 결제 인프라 서비스를 제공하고 있습니다.
1.2 사고 요약
| 항목 | 내용 |
|---|---|
| 사고 일시 | 2020년 8월 18일 (새벽) |
| 공개 일시 | 2021년 1월 5일 (업데이트) |
| 공격 벡터 | 미회수(Unrecycled) 액세스 키 악용 |
| 피해 규모 | 약 3,500만 건 (3.5크로어) 레코드 |
| 유출 데이터 | 마스킹 카드 정보, 카드 핑거프린트, 이메일 주소, 전화번호 |
| 안전 데이터 | 전체 카드번호, CVV, PIN, 비밀번호, 거래내역, API 키 |
오래된 액세스 키가 폐기되지 않은 채 방치되었고, 공격자는 이를 확보하여 내부 데이터 스토어에 무단으로 접근한 것으로 확인되었습니다.
자격증명 관리라는 비교적 기초적인 보안 원칙이 지켜지지 않아 발생한 사고로, 유사한 실수가 국내외 수많은 기업에서 반복되고 있다는 점에서 이 사례는 시사하는 바가 큽니다.
2. 공격 분석
2.1 공격 흐름 (Attack Flow)
아래는 공개된 정보를 바탕으로 재구성한 공격 흐름입니다.
[공격자]
│
▼
[유효한 Access Key 확보]
│ (유출 경로: 공개 저장소, 다크웹 거래, 내부 유출 등 - 미확인)
▼
[대상 데이터 스토어 무단 접근]
│ (격리된 서브시스템, AWS 또는 유사 클라우드 환경으로 추정)
▼
[대량 데이터 수집 시작]
│ (시스템 리소스 급증 → 자동 알람 발생)
▼
[인시던트 대응팀 감지 및 차단]
│
▼
[공격 서버 종료 / 진입점 봉쇄]공격자가 해당 액세스 키를 어떤 경로로 확보하였는지(예: GitHub 등 공개 저장소 노출, 다크웹 구매, 내부 위협 등)는 공식 발표에서 명시되지 않았습니다.
2.2 단계별 공격 프로세스
① 사전 정찰 및 키 확보 단계
공격자는 어떤 방법으로든 유효한 상태의 Juspay 액세스 키를 사전에 확보하였을 것입니다.
오래된 키라는 표현으로 미루어 볼 때, 해당 키는 오랜 기간 동안 유효 상태였으며 이미 일정 시점에 외부로 노출되었을 가능성이 높습니다.
② 무단 접근 및 데이터 탈취 단계
공격자는 확보한 키를 이용하여 Juspay의 격리된 데이터 스토어 중 하나에 접근하였습니다.
해당 스토어는 마스킹된 카드 정보(결제 UI에서 표시 목적으로 사용되는 비민감 데이터)와 일부 사용자 메타데이터(이메일, 전화번호)를 보관하고 있었습니다.
공격자는 이 스토어에서 약 3,500만 건의 레코드를 수집하였습니다.
③ 자동 탐지 및 차단 단계
대량의 데이터 접근 및 수집 과정에서 해당 시스템의 리소스 사용량이 급격히 증가하였고, 이를 탐지한 자동화된 모니터링 알람이 발동되었습니다.
④ 영향 범위 분석 단계
사고 당일 시스템 전반에 대한 감사를 실시하였습니다.
Juspay는 이후 수일간 감사 로그 전수 분석을 통해 정확한 피해 범위를 파악하였으며, 머천트 파트너사에도 같은 날 내용을 공유하였습니다.
3. 대응 방안
3.1 즉각 대응 절차
사고 발생 시 가장 먼저 취해야 할 조치는 피해 확산 차단과 증거 보존의 두 축으로 진행됩니다.
① 의심 자격증명 즉시 비활성화
침해가 의심되는 액세스 키는 즉시 비활성화하거나 삭제하여야 합니다.
이때 단순히 삭제에 그치지 않고, 해당 키로 수행된 모든 API 호출 로그(CloudTrail, S3 Access Log 등)를 별도로 보존하는 것이 중요합니다.
② 진입점 격리 및 네트워크 차단
침해된 시스템 또는 엔드포인트를 네트워크 레벨에서 격리합니다.
서비스 가용성과의 균형이 필요하지만, 추가적인 데이터 유출을 막기 위해 피해 확산 방지가 우선입니다.
③ 로그 수집 및 포렌식 준비
공격자의 행동 경로를 파악하기 위해 관련 시스템의 로그를 즉시 수집하고 무결성을 확보하여야 합니다.
로그를 조기에 수집하지 않을 경우, 로테이션 정책에 의해 증거가 소실될 수 있습니다.
④ 머천트 및 이해관계자 통보
피해 범위가 파악되는 즉시 연동된 머천트 파트너사에 사실을 통보하고, 공동 대응을 위한 API 키 교체 등 협조를 요청하여야 합니다.
Juspay는 이를 사고 당일에 수행한 것으로 확인되었습니다.
⑤ 관련 당국 신고
인도의 경우 RBI(인도 중앙은행) 및 관련 정부 기관에 신고하였습니다.
3.2 사후 조치 및 재발 방지
A. 자격증명 로테이션(Credential Rotation)
① 로테이션 주기 권고 기준
자격증명의 종류에 따라 교체 주기(Rotation Period)에 대한 산업계 권고 기준이 다소 상이합니다.
| 자격증명 종류 | 권고 교체 주기 | 근거 |
|---|---|---|
| AWS Long-term Access Key | 90일 이내 | AWS Security Best Practices, CIS Benchmark |
| DB 패스워드 | 30~90일 | PCI DSS, NIST SP 800-63B |
| API Secret | 30~90일 | OWASP API Security |
| 서비스 계정 키 (GCP/Azure) | 90일 이내 | 각 클라우드 벤더 권고 |
| 사용자 비밀번호 | 최대 1년 (복잡도 보완 시) | NIST SP 800-63B 개정 기준 |
다만 최신 NIST 지침(SP 800-63B Rev.4)에서는 불필요한 주기적 교체보다는 침해 감지 시 즉각 교체와 MFA 병행을 우선시하는 방향으로 변화하고 있습니다.
즉, '주기적 로테이션'만을 맹신하기보다는 자동화된 감지와 연동된 동적 로테이션 체계를 갖추는 것이 더 효과적입니다.
② 자동화된 로테이션의 필요성
수동 로테이션은 규모가 커질수록 오히려 누락 위험이 증가합니다.
Juspay 사고의 핵심도 사람이 수동으로 관리하던 키가 폐기되지 않은 채 방치된 것이었습니다.
따라서 아래에 소개하는 Secrets Manager 계열 도구를 통해 로테이션 자동화를 구현하는 것이 이상적입니다.
B. 자격증명 관리 방식 비교: SSO vs. 장기 키 vs. IAM 역할
① 장기 액세스 키 방식 (Long-term Access Key)
AWS IAM User 등에서 생성되는 정적 키(Access Key ID + Secret Access Key)를 각 시스템에 직접 주입하는 방식입니다.
- 장점: 설정이 단순하며 초기 구성 비용이 낮습니다.
- 단점:
- 키 자체가 유출될 경우 즉각적인 탐지가 어렵습니다.
- 유효기간이 없어 방치 시 영구적인 침입 경로가 됩니다.
- Juspay 사고의 직접적 원인이 이 방식의 남용이었습니다.
② IAM 역할 기반 임시 자격증명 (Role-based Temporary Credentials)
AWS의 경우 IAM Role을 EC2 인스턴스, Lambda, ECS Task 등에 부여하면, STS(Security Token Service)가 단기 유효 토큰(기본 1시간)을 자동 발급·갱신합니다.
- 장점:
- 자격증명이 만료되므로 유출되더라도 피해 창(Window of Exposure)이 최소화됩니다.
- 코드나 설정 파일에 키를 하드코딩하지 않아도 됩니다.
- 자격증명 관리 부담이 사실상 없어집니다.
- 단점:
- 클라우드 환경 밖(온프레미스, 외부 시스템)에서는 직접 적용이 어렵습니다.
- 역할(Role) 설계가 잘못될 경우 과도한 권한 부여(Over-privileged Role)의 위험이 있습니다.
Juspay도 사고 이후 장기 키 방식에서 이 방식으로 전환하였음을 공식적으로 밝혔습니다.
③ SSO(Single Sign-On) 연동 방식
Okta, Azure AD, Google Workspace 등의 IdP(Identity Provider)와 연동하여 중앙 집중형 인증을 구현하는 방식입니다.
사람 계정(Human Account)에 대한 접근 관리에 특히 효과적이며, AWS IAM Identity Center(구 SSO), GCP Workforce Identity Federation 등과 연계할 수 있습니다.
- 장점:
- 단일 IdP에서 전체 접근 권한을 관리하므로 퇴직자·역할 변경 시 즉각 대응이 가능합니다.
- MFA를 일관되게 강제할 수 있습니다.
- 접근 로그가 한 곳에 집약되어 감사(Audit)가 용이합니다.
- 단점:
- IdP 자체가 단일 장애점(Single Point of Failure)이 될 수 있습니다.
- 초기 구축 및 연동 비용이 높습니다.
- 머신(서비스) 계정에는 별도의 방식이 여전히 필요합니다.
방식별 트레이드오프 요약
| 방식 | 보안 수준 | 구축 난이도 | 운영 비용 | 적합 대상 |
|---|---|---|---|---|
| 장기 액세스 키 | 낮음 | 매우 낮음 | 낮음 | 소규모 혹은 초기 프로젝트 (권장하지 않음) |
| IAM 역할 기반 임시 자격증명 | 높음 | 중간 | 낮음 | 클라우드 네이티브 워크로드 |
| SSO + IdP 연동 | 매우 높음 | 높음 | 중간 | 기업 전체 사람 계정 관리 |
| Secrets Manager 활용 | 매우 높음 | 중간 | 중간~높음 | 모든 규모의 서비스 계정/API 키 관리 |
C. Secrets Manager 도구 비교
자격증명을 코드나 설정 파일에 직접 포함하지 않고, 런타임에 안전하게 조회하기 위한 전용 도구입니다.
이를 통해 자격증명 관리를 자동화할 수 있습니다.
① AWS Secrets Manager
AWS에서 제공하는 완전 관리형 시크릿 저장 및 자동 로테이션 서비스입니다.
- RDS, Redshift, DocumentDB 등 AWS 자체 서비스와의 자동 로테이션이 기본 지원됩니다.
- Lambda 함수를 이용한 커스텀 로테이션 로직 구성이 가능합니다.
- CloudTrail과 통합되어 모든 시크릿 접근 이력이 기록됩니다.
- 비용: 시크릿 당 월 $0.40, API 호출 1만 건당 $0.05 (2024년 기준)
- 단점: AWS 종속성이 발생하며, 멀티클라우드 환경에서는 관리 복잡도가 증가합니다.
② HashiCorp Vault
오픈소스 기반의 자격증명 관리 플랫폼으로, 클라우드 종류에 관계없이 사용할 수 있습니다.
- Dynamic Secrets 기능을 통해 요청 시점에 단기 자격증명을 즉석 생성(Just-in-time Provisioning)합니다.
- 데이터베이스, AWS, GCP, Azure, SSH 등 폭넓은 백엔드를 지원합니다.
- AppRole, Kubernetes Auth, AWS IAM Auth 등 다양한 인증 방식을 지원합니다.
- 엔터프라이즈 버전(HCP Vault)은 클라우드 관리형으로 운영 부담을 낮출 수 있습니다.
- 장점: 벤더 종속 없음, 유연한 정책 설정 가능
- 단점: 자체 운영 시 Vault 클러스터 자체의 가용성·보안 관리가 별도로 필요합니다.
참고:
