[2026-06-15] GitHub Actions 태그가 악성 커밋으로 변경… CI/CD 인증키 유출 위험

 

 

 

오늘의 뉴스클리핑의 이슈는 바로 티빙 개인정보 유출 입니다 - !

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

티빙 개인정보 유출

 

티빙 개인정보 유출 사고의 피해 규모는 약 1,300만 명이며, 정부는 이를 중대한 사고로 판단해 조사에 착수했다. 과학기술정보통신부는 외부의 비인가 접근으로 티빙 이용자의 개인정보 일부가 유출됐다고 밝혔고, 유출 정보는 아이디·이름·생년월일·CI·DI·전화번호(마지막 4자리 암호화)·이메일(도메인 제외 ID 부분 암호화)·환불 계좌번호(암호화)·비밀번호(단방향 암호화) 등이다. 지난달 기준 티빙 월간 활성 이용자수(MAU)는 882만 명이며, 유출 대상은 유료·무료 가입자를 모두 포함한다. 다만 주민등록번호와 신용카드 등 결제 관련 정보는 유출되지 않았다. 

이번 사고의 핵심은 단순 DB 유출이 아니라는 점이다. 범인은 데이터베이스를 외부에서 긁어간 것이 아니라 내부 시스템에 접속해 통제권을 얻은 뒤 직접 명령어(쿼리)를 입력해 데이터 조회를 실행했고, 이상 조회·명령이 발생하고 인지하기까지 21시간이 걸렸다. 티빙은 공격에 사용된 것으로 확인된 AWS 액세스 키를 폐기하고 깃허브의 하드코딩을 제거·교체했으며, 사고를 중대한 사고로 판단한 정부는 과기정통부·KISA·민간 전문가로 구성된 민관합동조사단을 긴급 출범시켰다.

 

CI (연계정보, Connecting Information)
1) 주민등록번호를 일방향으로 암호화한 88바이트 고유값

2) 금융·통신·공공 서비스에서 본인을 식별하는 데 쓰여 온라인 주민번호라고 불림

3) 어느 사이트에서나 같은 값이 쓰이며, 한 번 유출되면 교체가 불가능

 

DI (중복가입확인정보, Duplicated Information)
1) 한 사람이 같은 사이트에 중복 가입하는 것을 막기 위해 만든 식별값

2) CI와 달리 사이트마다 다른 값이 생성되므로 서비스 간 연결에는 쓰이지 않고, 해당 사이트 내 중복 확인 용도로만 쓰임

 

AWS 액세스 키 (Access Key)

1) 클라우드 서버와 DB 같은 핵심 자원에 접근할 수 있는 인증 정보

2) 사람이 입력하는 비밀번호가 아니라 프로그램이 클라우드에 접속할 때 쓰는 자격증명이며, 액세스 키(아이디 역할)와 시크릿 키(비밀번호 역할) 한 쌍으로 구성

 

 

 

 

공격과정 1 : 깃허브 자격증명 노출 (초기 침투)

 

공격의 출발점은 외부 침투 기술이 아니라 자격증명 관리 실패다. 하드코딩이란 시스템 접근에 필요한 인증정보(아이디·비밀번호·API 키 등)를 별도 보관소가 아닌 소스코드 본문에 문자 그대로 작성하는 방식을 말한다. 티빙은 개발자들이 코드를 공유하고 함께 작업하는 플랫폼인 깃허브의 하드코딩을 제거하고 교체했다고 신고했으며, 이는 가장 기본적인 보안 수칙이 지켜지지 않은 정황이다. 문제의 본질은 보관 위치다. 클라우드 자원에 접근하는 AWS 키가 소스코드에 평문으로 포함된 채 깃허브에 올라갔다. 깃허브는 전 세계에서 검색되고 자격증명을 자동으로 스캔하는 봇이 상시 돌아다니기 때문에, 코드에 직접 넣은 인증 정보가 공개 저장소에 올라가는 순간이 문제가 된다. 올바른 방식은 키를 코드에서 분리해 환경변수나 AWS Secrets Manager로 관리하는 것이다. 공격자는 노출된 자격증명을 수집해 클라우드 진입 수단을 확보했다. 이 유형은 국내에 국한된 사고가 아니다. 우버는 2016년 공격자가 개발자들이 쓰던 비공개 깃허브 저장소에서 로그인 정보를 확보한 뒤 AWS에 저장된 이용자 DB에 접근해 5700만 명의 정보가 유출됐고, 토요타도 2022년 차량 연결 서비스 소스코드 일부가 깃허브에 공개되면서 데이터 서버 접근키가 함께 노출돼 29만 명 이상의 고객 정보가 영향을 받았다.

 

 

환경변수 (Environment Variable)
1) 프로그램이 실행될 때 외부에서 읽어 들이는 설정값

2) 키 같은 민감 정보를 소스코드에 직접 쓰지 않고 코드 바깥에 분리 보관하는 방법으로, 하드코딩의 대안

 

import os
aws_key = os.environ["AWS_ACCESS_KEY"]   # 코드에는 '이름표'만, 실제 값은 없음

실제 키값은 코드가 아니라 서버 환경에 설정

export AWS_ACCESS_KEY="AKIA1234REALSECRETKEY5678"

코드는 AWS_ACCESS_KEY라는 이름으로 값을 요청할 뿐, 그 값이 무엇인지는 코드 어디에도 적혀 있지 않아 비교적 안전

 

 

 

AWS Secrets Manager

1) AWS가 제공하는 시크릿(키·비밀번호 등) 전용 보관·관리 도구

2) 민감 정보를 코드에서 분리해 안전하게 저장하고 접근을 통제

 

 

 

공격과정 2 :  탈취한 AWS 키로 클라우드 접근 (내부망 진입)

공격자는 확보한 키로 티빙의 클라우드 인프라에 접속했다. 신고서 대응현황에 공격에 사용된 것으로 확인된 AWS 액세스 키를 폐기했다고 적혔으며, 접근 키 관리 부실이 주요 원인이다. 이 단계가 위험한 이유는 두 가지다. 첫째, 공격자가 정상 자격증명을 그대로 사용했기 때문에 별도의 취약점 공격 없이 내부 데이터 영역까지 도달했다. 외부에서 방어벽을 뚫는 침입이 아니라 정당한 인증 절차를 통과하는 접근이므로, 일반적인 침입 탐지 방식으로 걸러내기 어렵다. 둘째, 접근 통제 설계에 허점이 있었다. 티빙이 사고 후 클라우드 접근 통제 정책을 변경했다고 밝힌 점은 기존 접근 통제에 허점이 있었음을 보여주며, DB 접속 경로가 제대로 잠겨 있지 않았거나 접근 권한이 필요 이상으로 넓게 열려 있었던 정황이다. 즉 키 하나에 부여된 권한 범위가 과도했고(최소 권한 원칙 위배), 접근 가능한 IP 대역 제한 등 추가 통제가 작동하지 않았다. 그 결과 단일 자격증명의 노출이 고객 DB까지 이어지는 단일 실패 지점이 됐다. 세부 침입 경로는 민관합동조사단 조사 중이다.

 

 

 

 

공격과정 3 : DB 직접 접속 및 쿼리 실행 (데이터 탈취)

내부 통제권을 얻은 공격자는 고객 DB에 직접 접속했다. 데이터베이스를 밖에서 긁어간 것이 아니라, 범인이 내부 시스템에 접속해 통제권을 확보한 뒤 직접 명령어(쿼리)를 입력해 데이터 조회를 실행한 정황이 확인됐다. 이는 외부 웹 서비스의 취약점(SQL 인젝션 등)을 이용한 공격과 구분된다. 공격자는 정당한 접근 권한을 가진 사용자처럼 DB 시스템 내부에서 직접 조회·전송 명령을 실행했고, 그 결과 약 1,300만 명 규모의 회원 정보가 외부로 전송됐다. 탐지 실패의 구체적 양상은 다음과 같다. 해커가 대량의 회원 정보를 조회하면서 DB 서버 CPU 사용률이 100%까지 치솟는 이상 징후가 발생한 시점은 5월 30일 오후 6시 1분이었으나, 티빙이 이를 인지한 것은 21시간이 지난 다음 날 오후 3시 9분이었다. 중요한 것은 인지 경로다. 전문가들은 시스템 방어 체계가 해커를 탐지한 것이 아니라, 대량 데이터 추출로 인한 서버 과부하 현상이 발생한 후에야 사후 확인이 이루어진 것이라고 설명한다. 즉 침입자가 하루 가까이 내부에서 활동하는 동안 이상행위 탐지 기능은 작동하지 않았고, 공격을 멈춘 것은 보안 시스템이 아니라 과부하라는 부수적 현상이었다.

 

 

 

 

시사점

첫째, CI 유출의 위험이 크다. CI는 디지털 주민등록번호로 불리는 온라인 고유번호로 어느 사이트에서나 같은 값이 쓰이며, 한 번 유출되면 교체가 불가능하고 타 사건의 유출 정보와 결합해 신원을 특정하는 데 악용될 수 있다. 이름과 전화번호는 이미 다른 사고로 유통되는 정보이지만, 거기에 CI가 더해지면 공격자가 조합할 수 있는 정보가 훨씬 정밀해진다. 통합 로그인이 연동된 연계 서비스로 피해가 확산될 가능성도 제기된다. 둘째, 암호화가 곧 안전을 보장하지 않는다. 암호화된 상태로 유출된 정보라 해도 무조건 안전한 것은 아니며, 암호화 강도나 암호화 키 관리 상태에 따라 공격자가 복원할 수도 있다. 디지털 안전장치가 제 기능을 했느냐가 이번 조사의 쟁점이다. 특히 소스코드가 함께 노출됐다면 위협은 더 커진다. 소스코드 내부에는 민감 정보를 보호하기 위한 암호화 알고리즘과 키 관리 로직이 포함돼 있어, 공격자가 이 설계도를 확보했다면 양방향으로 암호화된 데이터를 복호화할 수 있다. 셋째, 이번 사고의 본질은 외부 침투 기술이 아니라 하드코딩과 접근 키 관리 부실이라는 기본 보안 수칙 위반이다. 그리고 21시간의 탐지 지연은 이상행위 모니터링 체계의 부재를 드러낸다. 즉 예방(자격증명 관리)과 탐지(이상행위 모니터링) 두 단계 모두에서 통제가 작동하지 않았다.

 

 

 

 

 

개인 의견

이번 사고는 고도의 해킹 기법이 동원된 사건이 아니라 개발 단계에서 지켜야 할 가장 기본적인 비밀정보 관리 원칙이 무너진 결과라는 점에서 더 심각하다. 자격증명을 환경변수나 시크릿 관리 도구로 분리하고, 키에 IP·권한 제한을 두며, 이상 쿼리를 실시간 탐지하는 체계만 갖췄어도 충분히 차단하거나 조기에 발견할 수 있는 사고였다. 세 가지 통제 중 하나만 작동했어도 피해 규모는 크게 줄었을 것이다. 특히 변경이 불가능한 CI가 유출된 만큼 비밀번호 변경 같은 사후 조치로는 한계가 있으며, 기업이 본인확인 정보를 수집·보관하는 방식 자체에 대한 제도적 점검이 필요하다. 기술적 대응을 넘어, 평문 자격증명 노출을 코드 단계에서 차단하는 개발 프로세스(시크릿 스캐닝, 코드 리뷰)와 비정상 데이터 접근을 실시간으로 잡아내는 운영 체계가 함께 갖춰져야 동일한 사고의 반복을 막을 수 있다.

 

 

 

 

 

 

 

 

기사 출처 : https://v.daum.net/v/20260609145827033?f=p