[Threat Analysis] 티빙(TVING) 개인정보 유출 사고 분석과 실무적 시사점

[Threat Analysis] 티빙(TVING) 개인정보 유출 사고 분석과 실무적 시사점

최근 국내 최대 토종 OTT 플랫폼인 티빙(TVING)에서 대규모 개인정보 유출 사고가 발생하면서 보안 업계와 기업 CISO들에게 거대한 경종을 울리고 있습니다. 이번 보안 이벤트는 단순한 웹 애플리케이션 취약점이나 크레덴셜 스터핑(Credential Stuffing) 수준을 넘어, 클라우드 환경의 핵심 권한 자산인 '액세스 키(Access Key)' 관리 부실과 탐지 체계의 공백이 결합하여 발생한 전형적인 클라우드 타깃형 침해사고입니다. 타사의 포스트모템(Post-Mortem) 데이터를 현미경 분석하는 것은 우리 조직의 방어 아키텍처를 점검하고 컴플라이언스 통제 포인트를 리허설할 수 있는 가장 확실한 기회입니다. 본 리포트를 통해 기술적 위협 요인과 실무자가 즉시 적용해야 할 거버넌스 대책을 상세히 짚어봅니다.

---

1. Incident Summary (사고 개요 및 규제 현황)

국내 온라인동영상서비스(OTT) 시장에서 급성장하던 티빙이 외부 비인가 접근으로 인해 역대급 규모의 데이터 유출 피해를 입었습니다. 침해사고 발생 직후 한국인터넷진흥원(KISA) 및 관계 기관이 조사에 착수하였으며, 현재까지 파악된 원시 데이터 기반의 사고 개요는 다음과 같습니다.

• 사고경위 정보 및 인프라 현황

  구분	내용
  사고 인지 시점	2026년 6월 2일 (비정상 쿼리 실행 후 인지까지 약 21시간 소요)
  최초 대응 조치	공격에 도용된 AWS(Amazon Web Services) 액세스 키 즉시 폐기 및 외부 접근 경로 차단
  조사 참여 기관	개인정보보호위원회, 과학기술정보통신부, 한국인터넷진흥원(KISA), 방송통신위원회

• 침해 유형 및 자산: 밖에서 데이터를 단순히 긁어간 스크래핑 형태가 아닌, 해커가 내부 시스템 통제권을 탈취하여 직접 데이터베이스(DB) 내에 명령어(쿼리)를 입력해 조회를 실행한 '내부 인프라 침투형 DB 유출'입니다.
• 피해 Scale: 잠정 파악된 유출 규모는 유·무료 회원을 망라한 약 1,300만 명에 달합니다.
• 유출 데이터 항목: 회원 아이디(ID), 이름, 생년월일, 성별, 휴대전화번호(마지막 4자리 암호화), 이메일 주소(도메인 제외 ID 일부 암호화), 환불 계좌번호(암호화), 비밀번호(단방향 암호화), 연계정보(CI), 중복가입확인정보(DI)가 유출되었습니다. (주민등록번호 및 결제 관련 신용카드 정보는 미수집 상태로 유출 제외)
• 법적 행정처분 전망: 현재 유출 통지 및 조사가 진행 중이나, 디지털 주민등록번호로 불리는 'CI'와 'DI'가 대규모로 유출되었고 인지까지 21시간의 공백이 발생한 점을 미루어 볼 때, 개인정보보호법 제29조(안전성 확보조치) 위반에 따른 대규모 과징금 및 시정명령 처분이 불가피할 것으로 분석됩니다.

---

2. Root Cause Analysis (공격 벡터 및 기술적 결함 분석)

티빙이 관계 기관에 제출한 침해사고 신고서 및 보안 관점의 아키텍처 분석을 바탕으로 파악한 근본 원인(RCA)과 공격 기법(TTPs)은 크게 두 가지 결함으로 요약됩니다.

① TTPs 및 주 공격 벡터: AWS 엑세스 키(Access Key) 탈취 및 악용

해커는 정상적인 웹/앱 인터페이스를 우회하여, 내부 개발자 혹은 시스템 권한이 매핑된 AWS API 액세스 키(Access Key ID / Secret Access Key)를 손에 넣었습니다.

• 메커니즘: 유출된 권한을 기반으로 AWS CLI 또는 SDK를 통해 프로비저닝된 DB 인프라(RDS 또는 클라우드 네이티브 NoSQL/RDB 환경)에 직접 접근을 시도했습니다.
• 직접 명령어 실행: 합법적인 관리자 권한으로 위장했기 때문에, 전통적인 웹 방화벽(WAF) 차단 레이어를 통과한 후 DB에 대량의 조회를 수행하는 쿼리문을 직접 밀어 넣어 데이터를 추출하는 '직정 제어 쿼리' 기법을 구사했습니다.

[공격자] ──(탈취된 AWS Access Key 활용)──> [AWS API / IAM 통과] ──> [내부 DB 직접 접근 및 대량 쿼리 실행] 

② Technical Vulnerabilities: 접근통제 아키텍처 및 탐지 프로세스의 공백

• 하드코딩 및 키 관리 부실: 운영 환경이나 소스코드 레포지토리(GitHub 등), 혹은 테스트 환경 내에 클라우드 최고 권한을 가진 정적(Static) 장기 액세스 키가 노출되어 있었거나, 키 로테이션 주기가 제대로 준수되지 않았을 가능성이 매우 높습니다.
• 이상 행위 탐지 프로파일링 미흡 (DLP 및 SIEM 공백): 일반적인 서비스 트래픽 범위를 한참 상회하는 대규모 데이터 조회 명령어(Query)가 21시간 동안 지속 수행되었음에도 실시간 모니터링 경보(Alert)가 작동하지 않았습니다. 데이터 유출 차단(DLP) 솔루션이나 SIEM(보안 정보 및 이벤트 관리) 연동을 통한 통합 임계치(Rate Limiting) 설정에 치명적인 공백이 있었음을 방증합니다.

---

3. Compliance Gap Analysis (법적·인증 기준 매칭)

ISMS-P 심사원 관점에서 이번 사고를 분석했을 때, 기업 측이 방어하지 못한 규제 조항과 주요 결함 사항(Gap)은 다음과 같이 도출됩니다.

개인정보 보호법 제29조 (안전성 확보조치 기준 위반)

• 고시 제4조(접근통제): 권한이 있는 자에게만 액세스 키가 부여되고 안전하게 보관되어야 하나, 외부 비인가자가 권한을 도용할 수 있도록 방치하여 접근통제 기능이 무력화됨.
• 고시 제5조(접근권한의 관리): 불필요한 상위 권한의 키가 상시 활성화되어 있었던 점, 그리고 침해 사고 인지 시까지 계정 탈취 상태를 차단하지 못한 점에서 상시 모니터링 통제가 미흡함.

ISMS-P 인증기준 매칭 결함 예측

• 인증기준 2.6.2 (접근통제): 클라우드 서비스 환경(AWS)의 API 관리 키 및 소스코드 보안 관리가 부실하여 외부 유출을 방지하지 못함 (결함).
• 인증기준 2.6.7 (인터넷 접속 통제): 개발 및 내부 시스템에서 클라우드 자산에 접근하는 경로 상에 강력한 다중인증(MFA)이나 접근 IP 제한 등이 적용되지 않아, 유출된 키만으로 외부(해커 환경)에서 즉시 내부 DB 통제권을 확보함 (결함).
• 인증기준 2.10.1 (침해사고 예방 및 대응): 비정상적인 대량의 명령어 실행 및 데이터 외부 유출 징후를 실시간으로 탐지·로그 분석하지 못하고, 사고 발생 후 무려 21시간이 경과한 시점에 인지하여 초기 대응 골든타임을 실기함 (결함).

---

4. Mitigation Strategies (실무자를 위한 3대 아키텍처 보완 대책)

이와 같은 참사를 예방하기 위해, 우리 조직의 클라우드 및 데이터 레이어에서 즉시 수행해야 할 구조적 보안 통제 기법을 제안합니다.

[1] IAM 롤(Role) 기반 임시 자격 증명 전환 및 장기 액세스 키 전면 폐기

정적 액세스 키(Static Access Key)는 한 번 유출되면 공격자가 시공간 제약 없이 악용할 수 있어 위험도가 가장 높습니다.

• 조치 사항: 개발자 PC나 애플리케이션 서버 내에 저장된 모든 장기 AWS 엑세스 키를 찾아내어 폐기(Revoke)합니다.
• 기술 통제: EC2 인스턴스나 자사 인프라에는 IAM Role(역할)을 부여하여, 수명이 수 분~수 시간에 불과한 임시 자격 증명(STS token)을 발급받아 통신하도록 아키텍처를 전면 변경합니다. 외부 솔루션 연동이 필수적일 경우 AWS Secrets Manager를 연동하고 90일 주기로 자동 로테이션(Rotation) 정책을 강제해야 합니다.

[2] 위험 기반 적응형 인증(Adaptive Authentication) 및 API 엔드포인트 IP 화이트리스팅

인증 정보가 유출되더라도 '컨텍스트(Context)' 분석을 통해 2차 방어선이 작동해야 합니다.

• 기술 통제: 클라우드 콘솔 및 중요 API 엔드포인트 접근 시, 사전에 허가된 사내 가상사설망(VPN) 또는 개발실 공인 IP 대역으로만 인바운드를 허용하는 IP 화이트리스팅(Whitelisting) 정책을 적용합니다.
• 적용 기법: 유출된 키가 평소와 다른 이기종 국가나 생소한 IP 대역에서 호출될 경우, 통신을 즉시 드롭(Drop)시키거나 세션을 차단하는 위험 기반 적응형 접근 통제 정책을 IAM 및 CloudTrail 레벨에서 구현합니다.

[3] DB 이상 행위 프로파일링 및 데이터 반출 임계치(Rate Limiting) 탐지 룰 세팅

데이터베이스 레이어에서의 실시간 탐지 체계 고도화가 핵심입니다.

• 기술 통제: AWS GuardDuty, CloudTrail Insight 및 DB 감사 로그(Audit Log) 분석 솔루션을 상시 연동합니다.
• SOC 탐지 룰 고도화: 단일 세션 또는 단일 API 계정에서 평소 트래픽 대비 분당 조회(SELECT) 건수가 급증하거나, 대규모 데이터 반출(Data Exfiltration) 징후가 포착되는 순간 즉시 해당 세션을 자동으로 차단(Kill)하고, 보안관제(SOC) 포탈에 크리티컬 알람을 전송하는 임계치(Rate Limiting) 및 자동차단 플레이북(Playbook)을 구축합니다.

---

5. Conclusion & Takeaway

이번 티빙의 1,300만 명 개인정보 유출 사고는 우리에게 "아무리 단단한 암호화 알고리즘을 사용하고, 주민등록번호를 수집하지 않더라도, 클라우드 권한 자산(Access Key) 하나가 뚫리면 데이터베이스 전체 통제권이 단숨에 무너진다"는 엄중한 사실을 보여줍니다. 특히 온라인상의 주민등록번호 역할을 하는 CI가 결합되어 유출된 이상, 향후 타사 유출 데이터와 결합한 2차, 3차 피싱 및 스미싱 범죄로 이어질 리스크가 고도로 극대화된 상태입니다.

현대의 CISO/CPO들은 단순히 "규제 요건을 충족했다"는 컴플라이언스 체크리스트 위주의 방어에서 벗어나, 우리 인프라의 보안 가시성(Visibility)을 클라우드 API 레벨까지 확장하고, 침해 발생 시 즉각 자동 격리할 수 있는 회복 탄력성(Resilience) 중심의 제로 트러스트(Zero Trust) 아키텍처로 변모해야 할 시점입니다.

자료 출처

• [단독] 티빙 개인정보 유출 1300만명...DB 침투에 유료·무료 회원 다 털렸나 (다음뉴스 / 아시아경제) - https://v.daum.net/v/20260609145827033
• 티빙 개인정보 1,300만건 유출...참여연대 "집단소송법 더 이상 미룰 수 없다" (NGO뉴스) - https://www.ngonews.kr/news/articleView.html?idxno=230925
• 개인정보 유출한 티빙·CU…쿠팡 최종 제재 수위만 기다린다 (아주경제) - https://www.ajunews.com/view/20260608152309575