TVING·BGF 개인정보 유출 사건이 보여준 것 — DB 침투를 막는 실전 방어 7단계
DB 침투(데이터베이스 비인가 접근)는 CI·DI 같은 민감 식별자가 통째로 빠져나가는 가장 심각한 유출 경로다.
2026년 6월, 스트리밍 서비스 TVING의 이용자 개인정보가 DB에 직접 침투한 비인가 접근으로 유출됐다. 아이디·이름·생년월일·성별·CI·DI·휴대전화·이메일·환불 계좌번호·비밀번호가 포함됐고, 개인정보보호위원회(개인정보위)는 2026년 6월 4일 공식 조사에 착수했다(개인정보위 보도참고자료, 2026-06-04).
같은 시기 BGF리테일 계열사 관련 침해 사고도 보도됐다. 두 사건은 별개지만 구조가 같다. DB에 들어오면 막을 방법이 없다.
이 글은 피해 기업을 비판하는 게 목적이 아니다. 비슷한 구조로 서비스를 운영하고 있다면, 지금 어떤 방어가 필요한지 실무 체크리스트를 정리한다.
SENTRIX는 보안 실무 10년의 레드팀이 운영하는 보안 전문 기업이다. 비슷한 DB 구조를 진단하면서 반복 발견하는 빈틈 7가지를 중심으로 정리했다.
한눈에 보는 이번 사건
- Q. TVING 개인정보 유출 사건의 핵심은 무엇인가요?
- A. 2026년 6월 2일 TVING 이용자 정보를 저장한 데이터베이스(DB)에 비인가 접근이 발생했습니다. CI(연계정보), DI(중복가입확인정보)를 포함한 이름·생년월일·이메일·환불 계좌번호·비밀번호가 유출됐고, 개인정보보호위원회는 다음 날(6월 3일 오전 2시경) 신고를 받아 6월 4일 조사에 착수했습니다. — 출처: 개인정보보호위원회 보도참고자료(2026-06-04)
- Q. CI·DI가 유출되면 왜 더 위험한가요?
- A. CI(연계정보)는 주민등록번호를 해시한 본인 확인 고유값, DI(중복가입확인정보)는 사이트별 중복 확인에 쓰이는 식별자입니다. 한 번 유출되면 다른 서비스 연계 인증에 악용 가능하고 변경이 불가능합니다. 주민번호보다 유통성이 높아 실제 피해로 이어지는 속도가 빠릅니다.
- Q. "DB 비인가 접근"은 어떤 방식으로 이루어지나요?
- A. 대표 경로는 ①웹 애플리케이션 취약점(SQL Injection, 인증 우회)을 통한 DB 직접 질의 ②서버 내부망 침투 후 DB 포트 직접 연결 ③탈취한 DB 계정 정보 재사용 ④관리 도구(phpMyAdmin, Adminer 등) 외부 노출입니다. 유출 경위는 현재 개인정보위 조사 중으로 공식 확정되지 않았습니다.
- Q. 개인정보보호법상 이번 사건의 처벌 수위는 어느 정도인가요?
- A. 2023년 개정 개인정보보호법 기준으로 안전조치 의무 위반 시 위반행위 관련 매출액의 최대 3%, 중대 위반 시 최대 전체 매출액의 3%까지 과징금이 부과됩니다. 유출 규모·안전조치 수준·신고 이행 여부에 따라 달라지며, 2026년 9월 시행 예정인 개인정보보호법 개정안에서는 산정 기준이 더 강화됩니다.
- Q. 우리 회사 DB가 비슷한 위험에 노출돼 있는지 빠르게 확인하는 방법이 있나요?
- A. 외부에서 접근 가능한 DB 포트·관리 도구·API 엔드포인트를 먼저 스캔하는 것이 1단계입니다. CodeScan 무료 스캔으로 30초 내 외부 노출 자산과 알려진 취약점 패턴을 자동 점검할 수 있습니다. 내부 접근 통제와 쿼리 감사는 수동 진단이 병행돼야 합니다.
사건 타임라인 — 알려진 사실만
| 일시 | 내용 | 출처 |
|---|---|---|
| 2026-06-02 | TVING DB에 비인가 접근 발생 | 개인정보위 보도참고자료 |
| 2026-06-03 새벽 2시 | TVING이 개인정보위에 유출 신고 | 개인정보위 보도참고자료 |
| 2026-06-04 | 개인정보위 조사 착수 발표, 자료제출 요구·현장 조사 예고 | 개인정보위 보도참고자료 |
| 2026-06월 초~중순 | BGF리테일 계열사 관련 침해사고 보도 | 보안뉴스 등 복수 언론 |
유출된 정보: 아이디, 이름, 생년월일, 성별, CI, DI, 휴대전화번호, 이메일, 환불 계좌번호, 비밀번호(일부 암호화). — 개인정보위 보도자료 기준. 피해 규모(이용자 수)는 조사 중이며 공식 확정 전 수치는 이 글에서 표기하지 않는다.
BGF리테일 계열사 관련 사건은 현재 상세 조사 내용이 공개되지 않아, 확인된 언론 보도 내용만 참조하고 구체적 수치는 인용하지 않는다.
왜 DB가 뚫리나 — 반복되는 3가지 구조적 원인
10년간 레드팀 진단에서 DB 침투 사건의 전제 조건은 거의 세 가지로 압축된다.
첫째, 외부 노출된 공격 표면. DB 포트(MySQL 3306, PostgreSQL 5432, MSSQL 1433)가 방화벽 없이 외부에 열려 있거나, phpMyAdmin·Adminer 같은 관리 도구가 공개 URL에 있는 경우다. 내부망 설계를 제대로 못 하거나, 개발 편의로 열어둔 채 운영으로 넘어간 사례가 가장 많다.
둘째, 웹 애플리케이션 취약점을 통한 간접 경로. SQL Injection, 인증 우회, 파라미터 조작(IDOR)으로 서버 내부에 발판을 만든 뒤 DB에 도달한다. 자동화 스캐너로 잡히지 않는 비즈니스 로직 취약점이 이 경로에서 주로 활용된다.
셋째, 유출된 자격증명 재사용. 서버 접속 계정, DB 계정, 내부 인프라 비밀번호가 다른 사이트 유출 데이터와 겹치는 경우다. 직원 계정이나 서버 관리 계정이 개인 메일과 동일한 비밀번호를 쓰다 다크웹 크리덴셜 스터핑에 노출된다.
방어 7단계 — 구조별로 막는다
1단계: 외부 노출 자산 파악부터
방어는 공격자가 보는 것과 같은 눈으로 시작해야 한다. 퍼블릭 IP, 서브도메인, 열린 포트, 외부에서 접근 가능한 관리 도구를 정기적으로 스캔해야 한다.
많은 기업이 "우리는 내부망에 DB가 있다"고 생각하지만, 클라우드 마이그레이션·개발 서버 방치·Nginx 설정 오류로 의도치 않게 외부 노출이 생긴다. 지금 당장 모르면, 공격자는 이미 알고 있을 가능성이 있다.
2단계: DB 네트워크 격리
DB 서버는 애플리케이션 서버와 동일한 보안 그룹에 두면 안 된다. 권장 구성은 DB를 프라이빗 서브넷에 배치하고, 인바운드 규칙을 애플리케이션 서버 IP(또는 보안 그룹 ID)만 허용하는 것이다. 포트 번호도 기본값에서 변경하면 자동 스캐너 노출을 줄일 수 있다.
클라우드(AWS VPC, Azure VNet, GCP VPC) 환경이라면 Security Group 또는 Network ACL로 DB 레이어를 별도로 분리하는 것이 기본이다.
3단계: 애플리케이션 레이어 취약점 제거
DB가 격리돼 있어도 웹 애플리케이션에 SQL Injection이 있으면 DB 쿼리가 뚫린다. 점검 우선순위는 다음 순서다.
- 검색·필터·정렬 파라미터에서 raw SQL, f-string SQL 사용 여부
- 로그인·비밀번호 변경·계정 찾기 라우터의 인증 우회 가능성
- 파라미터(id, pk, uuid)에 소유자 검증(IDOR) 없는 라우터
자동 스캐너로 1차를 잡고, 비즈니스 로직 취약점은 수동 진단이 필수다.
4단계: DB 계정 최소 권한 원칙
많은 웹 애플리케이션이 DB에 접속할 때 root 또는 전체 권한 계정을 쓴다. 애플리케이션 전용 DB 계정은 해당 DB·테이블에 대한 SELECT/INSERT/UPDATE/DELETE만 허용하고, DROP·CREATE·FILE·SUPER 권한은 제거해야 한다.
SQL Injection 공격자가 잡을 수 있는 권한의 범위가 곧 사고 피해 범위와 같다. root 계정으로 SQL Injection이 발생하면 OS 명령어 실행까지 가능해진다.
5단계: 자격증명 관리
DB 비밀번호, API 키, 서버 접속 계정은 코드에 하드코딩하거나 .env 파일을 git에 커밋하면 안 된다. AWS Secrets Manager, HashiCorp Vault, 또는 환경변수 주입 방식으로 분리해야 한다.
정기적인 비밀번호 회전 정책도 필요하다. 특히 퇴직자 계정, 외부 협력사 계정, 개발용으로 생성한 임시 계정이 장기간 유효하게 남아 있는 경우가 레드팀 진단에서 빈번히 발견된다. 다크웹 크리덴셜 스터핑 공격에 대비해 서버·DB 계정에 MFA(다중 인증)를 적용하는 것이 현실적인 추가 방어선이다.
6단계: DB 접근 로깅과 이상 탐지
공격이 시작된 뒤 최대한 빨리 감지하는 것이 피해를 줄이는 열쇠다. DB 수준에서 실행된 쿼리를 로깅(MySQL general log, PostgreSQL pg_audit, AWS RDS audit log)하고, 비정상 패턴(짧은 시간 내 대량 SELECT, 새벽 시간대 대용량 덤프 쿼리, 처음 보는 IP에서의 접속)을 모니터링해야 한다.
TVING 사건에서 유출 신고가 발생일 다음 날 새벽 2시에 이루어진 점은, 이상 탐지가 작동했을 가능성을 시사한다. 감지 체계가 없었다면 훨씬 늦게 인지됐을 수 있다.
2025 한국 사이버보안 사고 결산에서도 감지 지연이 피해 규모와 직결되는 패턴이 반복됐다.
7단계: CI·DI 최소 수집 원칙
CI·DI는 본인 확인이 필요한 시점에만 요청하고, 이후에는 암호화·마스킹된 형태로만 저장해야 한다. 많은 서비스가 가입 시 CI·DI를 받아 DB에 평문 또는 약한 암호화로 저장한다. 공격자는 이걸 알고 CI·DI 필드만 타깃으로 쿼리를 구성한다.
서비스 특성상 CI·DI가 반드시 필요하다면 저장 방식을 재설계해야 한다. 최소한 AES-256 암호화와 복호화 로직 접근 통제를 분리해야 한다.
DB 보안 자가점검 체크리스트
| 구분 | 점검 항목 | 자동화 | 수동 |
|---|---|---|---|
| 네트워크 | DB 포트 외부 노출 여부 | ✅ | △ |
| 네트워크 | phpMyAdmin/Adminer 공개 URL 노출 | ✅ | △ |
| 계정 | DB 계정 최소 권한(root 미사용) | - | ✅ |
| 계정 | 서버·DB 계정 MFA 적용 | - | ✅ |
| 계정 | 퇴직자·임시 계정 비활성화 | - | ✅ |
| 코드 | SQL Injection 취약 패턴 | ✅ | △ |
| 코드 | .env git 커밋 여부 | ✅ | - |
| 암호화 | CI·DI 저장 방식 (평문 여부) | - | ✅ |
| 암호화 | 비밀번호 bcrypt/argon2 저장 | ✅ | △ |
| 로깅 | DB 쿼리 로그 활성화 | - | ✅ |
| 로깅 | 이상 접근 알림 설정 | - | ✅ |
자동화: CodeScan, pip-audit, gitleaks 등 / 수동: 레드팀 진단 또는 내부 보안 리뷰
법적 리스크 — 개인정보보호법이 묻는 것
개인정보보호법 제29조는 개인정보 처리자에게 안전조치 의무를 부과한다. 침해사고 발생 시 조사에서 확인하는 핵심은 세 가지다.
- 안전조치 이행 여부 — 암호화, 접근 통제, 접속 기록 관리가 되어 있었는가
- 유출 통지·신고 이행 여부 — 피해자 통지(72시간 내)와 기관 신고(정보통신서비스 제공자: 24시간 내)를 제때 했는가
- 과실 여부 — 알려진 취약점을 방치했거나, 최소한의 보안 투자도 없었는가
2023년 개정법 이후 과징금은 위반행위 관련 매출액의 최대 3%까지 올라갔다. 스트리밍·유통 서비스처럼 수천만 이용자를 보유한 기업은 과징금 규모 자체가 수백억이 될 수 있다.
2026년 9월 시행 예정인 개인정보보호법 개정안에서는 CPO(개인정보보호책임자) 권한과 의무가 강화되고, 과징금 산정 기준도 추가 조정된다.
SENTRIX가 보는 실무 인사이트
레드팀이 진단하면서 DB 침투가 가장 쉬웠던 환경에는 공통점이 있었다. 개발 서버와 운영 서버가 같은 네트워크에 있고, DB가 내부망이라고만 생각하고 접근 제어를 별도로 두지 않았으며, 로그가 없거나 아무도 보지 않는 상태였다.
무서운 건 이런 환경을 만든 게 의도가 아니라는 것이다. 빠르게 만들다 보면 보안 설계는 나중으로 밀린다. 그 "나중"이 언제 오는지는 공격자가 결정한다. TVING 사건에서 유출된 CI·DI는 변경 불가능한 식별자다. 이걸 보유한 이용자는 사실상 영구 피해를 안고 가야 한다.
서비스 운영자가 선택할 수 있는 시간은 사고 전까지다. 사고가 나면 선택지가 줄어든다.
다음에 해야 할 한 가지
TVING 사건은 "대형 서비스의 일"이 아니다. 수만 명 규모 서비스도 같은 구조로 뚫린다.
- 👉 개발자·보안 실무자: CodeScan 30초 무료 스캔 — DB 포트·관리 도구 노출·알려진 취약점 패턴 자동 점검
- 👉 임원·CISO·CPO: 30분 1:1 보안 상담 — 현재 DB 접근 통제 수준과 개인정보보호법 리스크를 실무 관점에서 점검
관련 글
- 2025 한국 사이버보안 사고 결산 — 매월 1건, 12건의 교훈
- 개인정보보호법 개정 — 과징금 10%, CPO 의무화 (2026년 9월 시행)