[탐정사무소]티빙 침해사고, 접속키 하나로 361개 프로젝트가 열렸다

개발환경 키 탈취에서 운영환경과 이용자 데이터베이스 침투로 이어진 티빙 사고를 통해 권한 분리와 키 생애주기 관리의 중요성을 살펴봅니다.

사고는 한 개의 키에서 넓어졌습니다

티빙 사고는 보안 수단 하나가 무너졌다는 이야기보다, 하나가 무너졌을 때 어디까지 열리도록 설계돼 있었는지를 보여줍니다. 과학기술정보통신부 조사단은 공격자가 개발자의 개발환경 접속키를 사전에 확보해 내부 개발환경으로 들어간 사실을 확인했습니다. 문제는 모든 개발자에게 전체 개발 프로젝트를 볼 수 있는 권한이 주어져 있었다는 점입니다. 접속키 관리가 사용자 인증에만 머물고 권한의 폭을 줄이지 못하면 단 하나의 키 문제가 조직 전체의 기술자산 문제로 커질 수 있습니다.

권한이 넓으면 작은 실패가 전체로 번집니다

외부로 나간 개발 프로젝트는 361건, 30.35GB 규모였습니다. 여기에는 추천·검색 알고리즘뿐 아니라 이용자 관리와 인증, 결제 관리, 유료 서비스 운영에 필요한 기술자료도 포함됐습니다. 업무에 필요한 최소 범위로 권한을 나눴다면 한 사람의 키로 접근할 수 있는 범위도 제한됐을 것입니다. 조사단은 키의 발급·사용·변경·폐기와 정기점검 절차가 마련되지 않았다고 지적했습니다. 결국 접속키 관리는 비밀번호를 복잡하게 만드는 문제가 아니라 누가 어떤 업무를 위해 어느 범위까지 사용할 수 있는지를 정하는 통제 체계입니다.

코드 속 43개 키가 다음 통로가 됐습니다

공격자는 개발 프로젝트 안에 그대로 들어 있던 운영환경 접속키 43개를 추가로 확보했고, 이 가운데 2개를 실제 침투에 사용한 것으로 조사됐습니다. 이용자 데이터베이스의 아이디와 비밀번호도 암호화되지 않은 상태로 저장돼 있었습니다. 개발 편의를 위해 중요한 값을 소스코드나 설정값에 그대로 두면 한 구역의 문제가 다른 구역으로 연속해서 번질 수 있습니다. 접속키 관리는 개발환경과 운영환경을 분리하고, 중요한 값은 별도 보관하며, 사용 이력을 지속해서 점검하는 구조로 설계돼야 합니다.

이미 발견된 취약점이 남아 있었습니다

2024년 모의 점검에서는 소스코드에 키를 그대로 두는 문제가 확인됐지만 개선되지 않은 것으로 발표됐습니다. 전체 임직원 265명과 개발인력 149명에 비해 외주 인력을 제외한 정보보호 전담인력은 4명 안팎이었습니다. 취약점을 발견하는 절차와 실제로 고치는 절차가 분리돼 있었음을 보여주는 대목입니다. 기업이 사고 원인과 미조치 항목을 정리할 때 활용할 수 있는 기업 이슈의 사실관계 정리 범위도 결국 담당자, 기한, 완료 여부를 문서로 연결하는 데서 출발합니다. 접속키 관리 역시 기술부서만의 과제가 아니라 경영진이 이행 상태를 확인해야 하는 조직 문제입니다.

Q&A 보안 도구를 새로 사면 해결될까요

새 장비는 일부 위험을 줄일 수 있지만 권한이 지나치게 넓고 키의 발급부터 폐기까지 책임자가 없다면 같은 문제가 반복될 수 있습니다. 이번 조사에서는 비정상 행위를 살피는 체계가 충분하지 않았고, 신규 VPN의 접속기록도 약 6일만 보관된 것으로 나타났습니다. 따라서 접속키 관리는 최소 권한, 별도 보관, 주기적 교체, 이상 사용 탐지, 충분한 기록 보존을 하나의 흐름으로 묶어야 합니다. 기술과 인력, 보고 절차 가운데 어느 하나만 강화해서는 전체 위험을 설명하기 어렵습니다.

외부 사실확인이 맡을 수 있는 선이 있습니다

사고가 발생한 기업이 외부 지원을 받더라도 내부 시스템을 임의로 열어보게 하는 방식이어서는 안 됩니다. 회사가 정당한 권한으로 제공할 수 있는 자료를 기준으로 시간표를 만들고, 권한 변경 이력과 점검 결과, 조치 완료 여부를 대조하는 방식이 적절합니다. 외부 사실확인 업무와 다른 전문 영역을 구분하는 기준처럼 업무의 목적과 결과물도 계약 단계에서 분명히 해야 합니다. 이번 티빙 사고의 핵심은 공격 방법의 신기함이 아니라 기본 통제가 여러 단계에서 이어지지 않았다는 데 있습니다.