티빙 해킹, 개인정보 유출보다 더 큰 문제는 AWS 액세스 키 노출이었다

이건 단순 개인정보 유출보다 클라우드 권한 사고에 가까움

• 티빙 해킹 사고가 고객 정보 유출을 넘어 내부 시스템 제어권 노출 가능성으로 번지고 있음

  • 국회 과학기술정보방송통신위원회 소속 이해민 의원실이 입수한 한국인터넷진흥원(KISA) 침해사고 신고서 내용이 근거로 제시됨
  • 비인가자가 내부 시스템에 직접 접근해 데이터 조회와 수정 명령, 즉 쿼리를 실행한 정황이 확인됐다고 함

• 주요 원인으로는 GitHub에 노출된 자격증명과 AWS 핵심 액세스 키 관리 부실이 지목됨

  • 개발 플랫폼인 GitHub 계정이 유출되면서 소스코드 안의 민감 정보가 드러난 것으로 추정됨
  • 특히 자격증명을 암호화하지 않고 문자열 그대로 코드에 적어두는 하드코딩이 문제로 언급됨

• 티빙은 사고 직후 해당 키를 교체했지만, 그걸로 끝났다고 보기 어렵다는 지적이 나옴
  • 시스템 구조가 이미 노출됐을 수 있기 때문임
  • 보안 전문가들은 우회 침투 경로, 즉 백도어 가능성까지 고려해 정밀 포렌식 조사가 필요하다고 봄

신고와 공지도 ‘법적 마감 맞추기’처럼 보였다는 비판

• 티빙은 사고를 인지한 지 23시간 59분 만에 KISA에 신고함

  • 현행법상 침해사고 의무 신고 시한은 24시간 이내임
  • 말 그대로 마감 1분 전에 들어간 셈이라, 빠른 대응이라기보다는 규정 턱걸이로 보일 수밖에 없음

• 이용자 공지는 더 늦어서 사고 인지 이틀 뒤에야 이뤄짐

  • 개인정보보호위원회의 72시간 이내 통보 기준은 충족해 법적 처벌은 피한 것으로 보임
  • 하지만 대형 플랫폼이라면 피해 확산을 막기 위한 선제 조치가 먼저 아니냐는 비판이 나옴

• 이 대목이 중요한 이유는 침해사고 대응에서 시간 자체가 보안 조치이기 때문임

  • 사용자는 비밀번호 변경, 결제수단 점검, 피싱 주의 같은 행동을 빨리 해야 함
  • 공지가 늦어질수록 피해자가 스스로 방어할 시간도 줄어듦

더 아픈 지점은 자체 탐지가 아니라 서버 과부하로 알아챘다는 점

• 신고서에 따르면 해커가 대량의 회원 정보를 조회하면서 DB 서버 CPU 사용률이 100%까지 치솟았음

  • 이상 징후가 발생한 시점은 지난달 30일 오후 6시 1분으로 언급됨
  • 티빙이 이를 인지한 건 21시간 뒤인 다음 날 오후 3시 9분임

• 보안 전문가들은 이걸 ‘탐지 시스템이 막아낸 사고’로 보기 어렵다고 설명함

  • 대량 데이터 추출로 서버 과부하가 난 뒤에야 사후 확인이 이뤄진 흐름에 가깝다는 것임
  • 월간 활성 이용자수(MAU) 770만 명이 넘는 서비스라면 꽤 뼈아픈 지점임

• ISMS 인증을 갖고 있었는데도 기본 수칙 누락 의혹이 제기됨
  • 클라우드 관리자 접속 시 스마트폰 2차 인증(OTP) 같은 기본 보호 장치가 현장에서 빠졌다는 지적이 나옴
  • 인증 보유와 실제 운영 보안 수준이 항상 같지 않다는, 매우 현실적인 사례임

보안 투자 축소 얘기까지 나오면서 구조적 문제로 커짐

• 티빙의 정보보호 투자액은 2022년 약 22억 원에서 2024년 약 17억 원으로 줄었다고 공시됨

  • 2년 연속 감소한 수치임
  • 사고가 난 뒤 보면 비용 절감이 보안 운영 역량 저하로 이어진 것 아니냐는 의심을 피하기 어려움

• 보안 인력 규모도 논란 포인트임

  • 전담 보안 인력은 내부와 외주를 합쳐 총 7.5명으로 언급됨
  • 최고정보보호책임자(CISO)도 전임 임원이 아니라 겸직 팀장급이라고 보도됨

• 티빙 측은 정부 합동조사단 조사가 진행 중이라 구체적 확인은 어렵다는 입장을 냄

  • 경위 조사가 끝나면 투명하게 밝히겠다고 설명함
  • 다만 이번 사안은 이미 ‘누가 몇 명 털렸나’보다 ‘클라우드 권한을 어떻게 관리했나’로 초점이 이동한 상태임

---

기술 맥락

• AWS 액세스 키가 위험한 이유는 권한 범위가 계정 설정에 따라 매우 커질 수 있기 때문이에요. 단순히 DB 하나 읽는 수준이 아니라, 서버와 저장소, 네트워크 설정까지 접근 가능한 권한이면 사고 반경이 인프라 전체로 커져요.

• 하드코딩이 특히 나쁜 습관인 이유는 코드 저장소와 자격증명의 생명주기가 엮여버리기 때문이에요. GitHub 계정이나 저장소 권한이 한 번 뚫리면, 코드뿐 아니라 운영 환경으로 들어가는 열쇠까지 같이 노출될 수 있거든요.

• 이런 사고를 줄이려면 장기 액세스 키를 최소화하고, 필요한 권한만 주는 최소 권한 원칙이 중요해요. 기사에서는 구체적인 권한 정책이 나오진 않지만, 키 노출이 인프라 제어권 논란으로 이어졌다는 점만으로도 권한 범위 관리가 핵심이라는 걸 알 수 있어요.

• 탐지도 별도 문제예요. CPU가 100%까지 올라간 뒤에야 알아챘다면, API 호출 패턴, 대량 조회, 비정상 리전 접근, 권한 사용 이벤트 같은 신호를 더 빨리 잡았어야 해요. 클라우드 보안은 방화벽 하나보다 로그와 이벤트를 얼마나 빨리 해석하느냐가 중요해요.

• 사고 대응 시간도 기술 운영의 일부예요. 신고 시한을 맞추는 것과 피해 확산을 줄이는 건 다른 문제라서, 대형 서비스라면 키 폐기, 세션 무효화, 사용자 공지, 포렌식 범위 확정을 거의 동시에 굴릴 수 있는 체계가 필요해요.