쿠팡 정보유출, “대학 2학년 수준 보안도 무시”…보안체계 신뢰추락

대규모 개인정보 유출 사고가 발생한 쿠팡의 인증 시스템 설계를 두고, 정치권에서까지 기초 보안 수준을 문제 삼는 비판이 쏟아지고 있다. 국민 다수가 이용하는 빅테크 플랫폼에서 기본적인 보안 아키텍처 원칙조차 지키지 않았다는 지적이 제기되면서, 국내 전자상거래와 클라우드 기반 서비스 전반의 보안 체계와 규제 수준을 재점검해야 한다는 목소리가 커지는 분위기다. 업계에서는 이번 사태가 국내 플랫폼 산업의 보안 경쟁 구도를 바꾸는 분기점이 될 수 있다는 관측도 나온다.  

이준석 개혁신당 대표는 최근 발생한 쿠팡의 대규모 정보 유출 사태와 관련해, 설계 단계에서의 보안 원칙 위반이 사고를 키웠다고 지적했다. 이 대표는 2일 국회 과학기술정보방송통신위원회 긴급 현안질의 직후 자신의 사회관계망 서비스에 글을 올려 “시작은 키 탈취였지만 그 키를 만능키로 만들어준 것은 잘못된 유저 인증 시스템 설계였다”고 비판했다. 이어 “대학교 2학년 수준의 수업에서 알려주는 설계 원칙을 간과했던 것”이라며 문제의식을 드러냈다.  

쿠팡 측은 사고 직후 “프라이빗 서명 키를 탈취한 공격자가 가짜 토큰을 만들어 다른 사용자인 것처럼 가장했다”고 설명해왔다. 내부 접근 권한을 가진 키가 유출되면서 외부 공격자가 합법 사용자로 위장할 수 있는 토큰을 대량으로 생성해, 로그인 인증을 우회했다는 설명이다. 그러나 이 대표는 해당 설명만으로는 수천만 명 단위의 계정 침해 경로를 충분히 설명하기 어렵다고 보고 질의를 이어갔다고 밝혔다.  

그는 “아무리 키가 털렸다 한들, 해커가 수천만 명의 사용자 계정을 뚫으려면 각 사용자의 이메일 주소를 다 알고 있어야 대입해 볼 수 있는 것 아닌가 하는 의문이 들었다”며 “그 방대한 이메일 리스트는 애초에 어떻게 확보했는가라는 질문으로 이어졌다”고 말했다. 이러한 의문을 바탕으로 국회 질의 과정에서 쿠팡 시스템 구조를 파악했고, 그 결과 두 가지 구조적 결함을 확인했다고 설명했다.  

첫 번째로 이 대표가 지목한 결함은 데이터베이스 설계 단계에서의 사용자 식별값 관리 방식이다. 그는 쿠팡 내부 데이터베이스의 사용자 식별값, 이른바 프라이머리 키가 암호화된 난수나 예측 불가능한 랜덤 값이 아니라, 1씩 증가하는 정수 형태의 자동 증가 값으로 설정돼 있었다고 전했다. 이 경우 공격자는 키를 탈취한 뒤, 단순히 숫자 1부터 순차적으로 대입해 모든 사용자의 계정을 특정할 수 있는 구조가 된다.  

이 대표는 “숫자 1부터 차례대로 대입만 하면, 모든 사용자의 계정을 특정할 수 있었다”며 “만약 이를 예측 불가능한 값으로 설계했더라도, 키가 탈취된 것만으로는 수천만 명의 정보가 통째로 털리는 일은 막을 수 있었을 것”이라고 강조했다. 보안 설계 관점에서 사용자 식별값 노출과 예측 가능성을 동시에 줄이는 것은 기본 원칙에 속하는데, 쿠팡이 이 요구 사항을 충족하지 못했다는 지적이다.  

두 번째 결함은 인증 토큰을 발급하는 내부용 응용프로그램 인터페이스가 외부 네트워크에 노출돼 있었다는 점이다. 이 대표는 “숫자만 넣으면 인증 토큰을 내어주는 이런 API는 보통 시스템 내부의 마이크로서비스 간 통신에나 사용돼야 한다”며 “서로 신뢰하는 내부 서버끼리만 쓰고 닫아뒀어야 할 이 API가, 황당하게도 일반 인터넷에서 누구나 접근 가능한 상태로 열려 있었다”고 말했다.  

마이크로서비스 아키텍처에서는 서비스 간 통신을 위해 내부 전용 API를 두고, 방화벽과 네트워크 분리, 접근제어 목록 등으로 외부 접속을 차단하는 것이 일반적이다. 특히 인증 토큰을 발급하는 인터페이스는 시스템 전체의 신뢰 기반이기 때문에, 별도의 보안 게이트웨이 뒤에 두거나 다단계 검증을 거치도록 설계하는 것이 통상적이다. 이 대표가 지적한 구조대로라면, 쿠팡의 경우 이러한 보안 경계 설정이 허술해졌고, 키 탈취와 결합되면서 대규모 계정 탈취 경로가 열렸을 가능성이 커진다.  

이 대표는 이번 사고를 단순한 비밀키 분실 사고로 축소할 수 없다고 강조했다. 그는 “이번 사태는 단순한 관리자 키 분실 사고가 아니다”라며 “누구나 예측 가능한 번호표를 달아놓고, 직원 전용 출입구를 활짝 열어둔 것과 다름없는 안일한 보안 아키텍처가 불러온 예견된 인재”라고 말했다. 사용자의 민감 데이터를 대규모로 다루는 플랫폼에서 가장 기초적인 설계 원칙이 지켜지지 않았다는 점이 핵심 문제라는 진단이다.  

국민 다수가 사용하는 전자상거래 플랫폼에서 이런 수준의 구조적 결함이 드러나자, 국내 IT 업계 전반의 보안 설계 기준에 대한 불신도 커지고 있다. 특히 클라우드 네이티브 환경에서 마이크로서비스 구조를 도입한 기업들이 유사한 패턴의 내부용 API를 외부에 개방해두었는지, 데이터베이스의 프라이머리 키를 어떻게 설계하고 있는지 재점검해야 한다는 지적이 나온다. 개인정보를 다루는 플랫폼 서비스에서 PK 구조와 토큰 발급 구조는 곧 공격 표면과 직결되기 때문이다.  

글로벌 시장에서는 이미 대형 플랫폼과 클라우드 사업자를 중심으로 제로트러스트 보안, 최소 권한 원칙, 키 관리 인프라 강화 등이 표준처럼 자리 잡고 있다. 미국과 유럽의 주요 사업자들은 사용자 식별자와 인증 토큰 구조를 분리하고, 내부용 API에도 세분화된 접근 통제와 모니터링을 적용하는 추세다. 반면 국내에서는 여전히 인증 체계의 설계와 운영을 개발 효율 관점에서만 다루는 경우가 적지 않다는 평가가 제기된다.  

정책 측면에서 보면, 개인정보 보호 당국과 과학기술정보통신 관련 부처가 이번 사태를 계기로 빅테크 플랫폼의 보안 설계 기준을 보다 구체적으로 제시할 필요성이 커지고 있다. 데이터베이스 구조와 내부 API 노출 여부 같은 기술적 세부 항목까지 점검할 수 있는 가이드라인과 인증 제도 마련 요구도 힘을 얻는 분위기다. 규제 기관이 사후 사고 조사에 그치지 않고, 사전적 설계 검증 역할을 확대해야 한다는 주장도 있다.  

이 대표는 “국민의 데이터를 다루는 거대 플랫폼이 이런 기초적인 보안 설계를 놓치고 있었다는 점, 매우 뼈아픈 대목”이라며 “과방위 위원으로서 끝까지 책임을 묻고 근본적인 대책을 챙기겠다”고 밝혔다. 산업계에서는 이번 사고가 국내 플랫폼 기업들이 보안 아키텍처를 다시 설계하는 계기가 될지, 아니면 일시적 논란에 그칠지 주목하고 있다.