6일 국회 과학기술정보방송통신위원회 소속 이해민 조국혁신당 의원실을 통해 입수된 티빙의 ‘한국인터넷진흥원(KISA) 침해사고 신고서’에 따르면, 이번 사태는 단순한 데이터베이스(DB) 유출에 그치지 않았다.
사고 당시 비인가자가 내부 시스템에 직접 접근해 데이터 조회 및 수정 명령(쿼리)을 실행한 정황이 확인됐으며, 개발 플랫폼인 깃허브(GitHub)에 노출된 자격증명과 아마존웹서비스(AWS)의 핵심 액세스 키 관리 부실이 주요 원인으로 추정된다.
보안 전문가들은 이번 사고가 클라우드 인프라 전반의 통제권과 직결된 사안이라는 점을 들어, 사태의 심각성을 다음의 세 가지 요인으로 분석했다.
|
◇①인프라 전반의 제어권 노출 가능성
당초 이번 사고는 특정 회원의 데이터베이스(DB)만 유출된 것으로 알려졌으나, 실제로는 티빙의 핵심 인프라인 아마존웹서비스(AWS) 클라우드 시스템의 자격증명(액세스 키)이 노출된 것으로 파악됐다.
개발자들의 온라인 작업 공간인 깃허브(GitHub) 계정이 유출되면서, 프로그램 소스코드 내에 암호화하지 않은 문자 그대로 자격증명을 적어두는 이른바 ‘하드코딩’ 방식이 원인으로 지목된다. AWS 액세스 키는 클라우드 내 서버와 저장소, DB 전체에 접근할 수 있는 권한을 가진다.
보안 전문가들은 개발 편의를 위해 소스코드 내에 비밀번호를 직접 기입하는 행위는 기본적인 보안 원칙을 위반한 것이라고 지적했다.
티빙은 사고 직후 해당 키를 교체했으나, 시스템의 구조가 이미 노출된 만큼 향후 우회 침투 경로(백도어)를 통한 추가 리스크 가능성을 배제할 수 없어 정밀 포렌식 조사가 필요한 상황이다.
|
◇②침해 인지 후 늑장 대처 및 신고 논란
사고 발생 이후 티빙의 대응 시점도 도마 위에 올랐다. 티빙은 사고를 인지한 지 23시간 59분 만에 한국인터넷진흥원(KISA)에 신고했다.
이는 현행법상 침해사고 의무 신고 시한인 ‘24시간 이내’를 불과 1분 남겨둔 시점이었다.
이용자들을 향한 대고객 공지는 이보다 더 늦은 이틀이 지난 뒤에야 이뤄졌다. 개인정보보호위원회의 규정인 ‘72시간 이내 통보’ 기준은 충족하여 법적인 처벌 대상은 피했으나, 대형 플랫폼으로서 피해 확산을 막기 위한 선제적인 이용자 보호 조치보다 규제 회피 중심의 소극적 대응에 치중했다는 비판이 나온다.
|
◇③해킹 사태 자체 탐지 실패와 보안 투자 축소
가장 취약한 대목은 티빙의 자체 보안 시스템이 해커의 침입을 사전에 감지하지 못했다는 점이다.
이데일리가 입수한 신고서에 따르면 해커가 대량의 회원 정보를 조회하면서 DB 서버의 CPU 사용률이 100%까지 치솟는 극심한 이상 징후가 발생한 시점은 지난달 30일 오후 6시 1분이었다.
하지만 티빙이 이를 인지한 것은 21시간이 지난 다음 날 오후 3시 9분이었다. 보안 전문가들은 시스템 방어 체계가 해커를 탐지한 것이 아니라, 대량 데이터 추출로 인한 서버 과부하 현상이 발생한 후에야 사후 확인이 이루어진 것이라고 설명한다. 월간 활성 이용자수(MAU) 770만 명이 넘는 대형 플랫폼의 이상 탐지 기능이 제대로 작동하지 않은 셈이다.
이러한 기술적 한계는 예고된 결과라는 지적이 나온다. 국가 공인 정보보호관리체계(ISMS) 인증을 보유했음에도 클라우드 관리자 접속 키 등을 프로그램에 그대로 노출했다.
그 배경에는 지속적인 보안 부문 투자 축소가 자리 잡고 있다. 공시에 따르면 티빙의 정보보호 투자액은 2022년 약 22억 원에서 2024년 약 17억 원으로 2년 연속 감소했다. 전담 보안 인력은 내부와 외주를 합쳐 총 7.5명에 불과하다.
티빙 측은 “현재 정부 합동조사단의 조사가 진행 중인 사안으로 구체적인 확인은 어렵다”며 “경위 조사를 마치는 대로 투명하게 밝히겠다”고 입장을 전했다.
Copyright ⓒ 이데일리 무단 전재 및 재배포 금지
본 콘텐츠는 뉴스픽 파트너스에서 공유된 콘텐츠입니다.
다음 내용이 궁금하다면?
광고 보고 계속 읽기
원치 않을 경우 뒤로가기를 눌러주세요
