Security

43억 건 정보 저장된 몽고디비, 전체 공개로 노출

문가용 기자

Published: 13:20, 15 Dec 2025 (Updated: 20:18, 14 Jan 2026)

💡

Editor's Pick
- 16TB의 데이터가 보호 장치 없이 노출돼 있어
- 개인정보와 민감 정보가 다량으로 섞여 있어
- 지금은 비공개 전환돼 있으나, 그 동안 누가 무슨 짓 했는지 몰라

방대한 정보가 저장돼 있는 데이터베이스가 ‘열려 있는 채로’ 발견됐다. 아무런 보호 장치가 없이 무려 16TB의 정보가 고스란히 노출돼 있었다. 열람해 보니 약 43억 건의 전문직 관련 기록이었다고 최초 발견자 밥 디아첸코(Bob Diachenko)가 밝혔다. 해당 데이터베이스는 몽고디비(MongoDB)였다. 해당 데이터베이스는 현재 비공개 상태로 전환됐다.

디아첸코는 문제의 데이터베이스를 분석해 9개의 컬렉션을 추출해 낼 수 있었다. 몽고디비 체제에서 ‘컬렉션’이란, 관계형 데이터베이스의 테이블에 해당하는 것으로, 정보를 저장하는 기본 단위라고 이해하면 된다.

💡

여기서 잠깐!
MySQL이나 오라클 등으로 대표되는 관계형 데이터베이스는 데이터를 테이블 형태로 저장한다. 데이터 간 관계를 테이블로 정리할 수 있기 때문에 이런 데이터베이스를 ‘관계형’이라고 부른다. 컬렉션은 몽고디비처럼 ‘관계형이 아닌’ 데이터베이스가 정보를 저장하는 최소 단위로, 테이블처럼 정해진 구조가 없다. 없기 때문에 유연하며, 대규모 처리에 장점이 있지만, 복잡한 분석을 할 때는 불리하다. 데이터 덩어리를 분류 체계 없이 묶어두어야 할 때 비관계형이 선호되지만, 좀 더 정제된 데이터를 후가공 할 목적으로 저장한다면 관계형이 낫다.

9개 컬렉션의 이름과 용량은 다음과 같이 정리될 수 있다.

1) intent : 604.76GB(20억 건의 문서 포함)
2) profiles : 5.85TB(11억 건의 문서 포함)
3) unique_profiles : 5.63TB(7억 건의 문서 포함)
4) people : 3.95TB(1.6억 건의 문서 포함)
5) sitemap : 20.22GB(1.6억 건의 문서 포함)
6) companies : 72.9GB(1.7억 건의 문서 포함)
7) company_sitemap : 3.76GB(1700만 건의 문서 포함)
8) address_cache : 26.78GB(800만 건의 문서 포함)
9) intent_archive : 620MB(200만 건의 문서 포함)

여기서 말하는 ‘문서’란 무엇일까? 여러 정보가 기록돼 있는 파일을 말한다. 이 중에는 개인정보가 적잖이 포함돼 있었다고 디아첸코는 설명한다. “20억 건에 달하는 이름, 이메일, 전화번호, 링크드인 링크, 직무, 고용주, 이력, 학력, 위치 정보, 기술, 모국어, 소셜미디어 계정 등이 이번에 노출됐습니다. 다소 중복되는 데이터가 있을 수는 있지만 대부분은 고유한 정보들이었습니다.”

누가 운영하던 데이터베이스였나?

아직까지 해당 데이터베이스의 소유주는 밝혀지지 않았다. 다만 컬렉션 중 하나인 sitemap에서 특정 기업의 것으로 보이는 흔적이 나오긴 했다. “이 기업은 일종의 마케팅 회사였습니다. 잠재 고객의 정보를 수집하고 정리해서 이를 또 다른 광고 회사 등에 판매하는 기업이죠. 아직 고객은 아닌데, 고객이 될 수 있을 만한 사람들을 분야나 사업 아이템별로 추리는 작업을 대신 하는 데 전문성을 가지고 있는 단체이며, 따라서 위와 같은 데이터를 수집할 만하다고 할 수 있습니다.”

게다가 해당 기업이 자사 홈페이지를 통해 “7억 명 이상의 전문가 데이터를 보유하고 있다”고 자랑하고 있는 것을 디아첸코는 확인했다고 한다. “7억이라면 3번 컬렉션인 unique_profiles를 통해 공개된 문건의 수와 비슷한 수치입니다. 물론 정확한 관계성을 입증할 만한 증거가 나오지는 않았지만요.” 디아첸코는 이 기업에 데이터베이스가 열려 있다는 사실을 전달했고, 문제의 데이터베이스는 바로 다음 날 비공개로 재설정됐다.

조치가 이뤄졌는데도 소유주가 누구인지 모른다?

여기서 한 가지 이상한 점을 눈치 챘을 수 있다. “아직까지 해당 데이터베이스의 소유주가 밝혀지지 않았다”고 했으면서 “특정 기업에 사실을 통보하니 하루 만에 조치가 취해졌다”고 쓴 부분이 그렇다. 이게 사실이라면 그 기업이 데이터베이스의 소유주인 것 아닐까?

정황상 그럴 가능성이 상당히 높아 보이는 게 사실이다. 하지만 ‘사실을 통보했더니 바로 조치가 취해졌다’는 것만으로 이런 데이터베이스의 소유주가 그 기업이라고 결론을 지을 수 없는 게 디아첸코와 같은 보안 연구자들의 입장이다. 소유주가 아니더라도 이와 같은 인과 관계를 설명할 수 있는 시나리오가 더 존재하기 때문이다.

“예를 들어 누군가가 해당 기업의 데이터를 탈취하거나 스크랩 했을 수도 있습니다. 그런 후 그 기업 모르게 몽고디비에 저장해 둔 것이죠. 그런 경우 디아첸코의 경고를 듣고서 그 기업은 자신의 데이터베이스나 서버를 닫아두었을 수 있고, 그 서버가 닫힌 것을 보고 스크랩을 진행하던 공격자도 놀라서 자신의 몽고디비를 비공개로 했을 수도 있습니다.” 디아체노의 설명이다.

혹은 해당 기업의 파트너사가 업무상의 이유로 몽고디비를 따로 운영했을 수도 있다. 그렇다면 디아첸코가 사실을 통보했을 때 해당 기업이 내부 조사를 진행해 파트너사의 운영 실태를 파악했을 수도 있다. 그런 후 서로의 합의 하에 문제의 DB를 닫았다는 시나리오는 충분히 있을 법한 일이다. 이런 경우 책임 소재를 다루는 것도 불분명해진다.

DB 설정 오류 사고, 피해 규모 확인 불가

이런 식으로 DB 설정을 잘못하는 바람에 대규모 정보가 유출되는 사고의 가장 큰 약점은, 피해 규모를 짐작하기도 어렵다는 것이다. 어느 시점부터 DB가 열려 있었는지, 그로부터 누가 접근해 무슨 데이터를 얼마나 열람하거나 긁어 갔는지 확인할 방법이 없기 때문이다.

“심지어 이번에 노출된 데이터는 추가 공격을 위한 재료 그 이상이었습니다. 즉시 활용 가능한 공격용 무기에 더 가까웠습니다. 이 데이터들은 아주 정교한 스피어피싱도 가능하게 하고, CEO 등을 사칭한 BEC 공격도 할 수 있게 합니다. 보다 깊고 광범위한 공급망 공격도, 정밀 랜섬웨어 공격도 다 가능합니다. AI를 활용한 자동화 공격의 연료로서도 안성맞춤이죠. 누가 얼마나 이 DB에 접근해 왔는지 알 방법이 없습니다만, 제발 아무도 없었기를 바라는 건 이 때문입니다.”

이런 류의 DB 보안 사고는 대부분 테스트용으로 잠깐 열어둔 것을 깜빡 잊었다가 벌어진다. 잠시만 열어두는 것이라 하더라도 비밀번호 설정 등 간단한 보안 장치는 항상 적용하는 게 습관이 되어야 한다고 보안 전문가들은 강조한다. 데이터베이스 생성 시 인증 단계를 디폴트로 탑재시키고, 공공 인터넷으로의 연결을 차단하는 등 여러 안전 장치를 회사 차원에서 강제하는 것도 좋은 방법으로 꼽힌다. “설정 오류는 사람의 책임이긴 하지만, 자동화 기술로 크게 줄이는 것도 가능합니다. 교육과 함께 차단 방지 기술을 적극 검토하는 것을 권장합니다.”🆃🆃🅔

by 문가용 기자(anotherphase@thetechedge.ai)