안녕하세요, 주식회사 TIMEWELL의 하마모토 류타입니다.
AI 회의록 서비스의 취약점이 공개되었습니다. 18만 건이 넘는 회의 레코드가 다른 회사의 사용자에게도 보이는 상태였다는 내용입니다.
숫자가 크다 보니 「또 허술한 회사가」로 읽히기 쉬운데, 보고서를 읽어 보면 실은 그런 이야기가 아니었습니다. 같은 시스템 안에서 열 개의 그릇 중 아홉 개는 제대로 지켜지고 있었습니다. 빠진 것은 하나뿐.
그리고 이 「하나만 놓친다」는 실패의 형태는, 저희를 포함해 멀티테넌트 구성의 서비스를 만드는 회사 모두에게 구조로서 내재해 있습니다. 남의 일로 돌릴 수 있는 이야기가 아니므로 차례대로 씁니다.
기술자용 글로는 쓰지 않습니다. SaaS를 도입하는 쪽이 벤더에게 무엇을 물으면 되는지 알 수 있는 형태를 목표로 합니다.
우선, 무슨 일이 있었나
보안 연구자 BobDaHacker가 2026년 8월 4일에 공개한 보고에 따르면, AI 회의록 서비스 tl;dv에서 회의 메타데이터를 보관하는 데이터베이스상의 한 그릇에 테넌트 간 접근 제어가 설정되어 있지 않았습니다1.
그 결과 로그인한 사용자라면 플랫폼상의 다른 회사 회의 레코드도 읽을 수 있는 상태였다고 합니다. 규모는 181,874건의 회의 레코드, 84,312명의 사용자, 35,003개의 메일 도메인. 23개국의 정부기관, 여러 대학, 다수 기업의 회의가 포함되어 있었다고 보고되었습니다1.
보이던 항목은 회의 작성자의 메일 주소, 녹화 상태, 타임스탬프, 그리고 회의 ID입니다. 이 회의 ID가 까다로운데, Google Meet나 Teams의 「그 회의에 들어가기 위한 번호」였습니다. 연구자는 실증으로 초대받지 않은 타인의 라이브 회의에 실제로 2건 입장했습니다. 하나는 말레이시아 교육부의 157명 규모 회의, 다른 하나는 미국 대학발 스타트업의 21명 회의로, 화면 공유가 이루어지고 있었다고 합니다1.
보고는 2026년 1월 28일에 이루어졌습니다. 공개 시점에 6개월이 지나 있었습니다1. 또한 공개 후 tl;dv 측은 보고 후 얼마 지나지 않아 해소했다는 취지의 코멘트를 냈고, 연구자는 6개월 뒤에도 재현했다고 반박하고 있습니다. 사실관계에는 이 어긋남이 남아 있습니다. 본 기사는 어느 쪽이 옳은지를 재정하기 위한 것이 아닙니다. 보고 싶은 것은 왜 이 구멍이 생겼는가라는 구조 쪽입니다.
「멀티테넌트」를 아파트로 생각하기
용어를 하나만 설명하겠습니다.
멀티테넌트란 하나의 시스템을 여러 회사가 공동 이용하는 구조입니다. 아파트를 떠올려 보십시오. 건물도 엘리베이터도 배관도 공용이지만, 각 회사는 자기 호실만 사용합니다. 이 「호실의 칸막이」에 해당하는 것이 테넌트 분리입니다.
SaaS가 왜 싼가 하면, 이 공용에 의해 비용을 나누기 때문입니다. 한 회사마다 서버를 세우는 것보다 훨씬 효율이 좋습니다. 따라서 멀티테넌트 자체는 악이 아니라, 오히려 현대 클라우드 서비스의 전제입니다.
다만 안전성이 이 「칸막이」 하나에 얹히게 됩니다. 칸막이가 한 군데 빠지면 옆방이 보입니다. 이번에 일어난 것이 바로 그것입니다.
아홉은 지켜졌고, 하나만 빠졌다
여기가 이 사건의 핵심입니다.
연구자의 기술에 따르면, 같은 시스템상의 사용자, 채팅, 전사, 클립, 녹음, 동영상, 메모, 팀, 조직이라는 아홉 개의 그릇은 모두 제대로 접근을 거부하고 있었습니다1. 동영상 자체도, 대화의 전사도 지켜지고 있었던 것입니다.
지켜지지 않았던 것은 회의 메타데이터 하나뿐이었습니다.
즉 「보안을 경시하던 회사가 당연하다는 듯 전부 열어 두었다」는 이야기가 아닙니다. 분리라는 설계 사상을 갖고, 대부분을 올바르게 구현할 수 있었던 조직이 하나만 놓친 이야기입니다.
저는 여기에 오히려 무서움을 느꼈습니다. 아홉까지 해내고도 사고가 난다면, 대부분의 회사가 같은 위치에 있기 때문입니다.
덧붙여 한 단계 더 있는 교훈이 있습니다. 빠진 것이 「동영상 본체」가 아니라 「메타데이터」였다는 점입니다. 메타데이터는 본체가 아니니 중요도가 낮다는 감각은 많은 현장에 있습니다. 그런데 이번에 그 메타데이터 안에는 회의 ID가 들어 있었습니다. 놓여 있던 것은 내용물이 아니라, 내용물에 들어가기 위한 열쇠였던 것입니다.
기밀도를 「본체 데이터인가, 부수 정보인가」로 나누면 이 함정을 반드시 밟습니다. 판단해야 할 것은 거기에 무엇이 적혀 있는가가 아니라, 그 데이터로 무엇을 할 수 있는가입니다. 회의 ID, 초대 링크, 공유 토큰, 추측 가능한 파일 경로. 어느 것이나 단독으로는 내용을 갖지 않지만, 열쇠로 기능합니다.
구멍은 왜 「나중에」 열리는가
처음 설계에서는 분리되어 있었을 것이 개수를 거듭하는 사이에 구멍이 열린다. 이는 태만이 아니라 몇 가지 역학이 작용한 결과로 일어납니다. 세 가지로 좁혀 씁니다.
첫째, 「쓴 곳만 닫히는」 방식이 되어 있는 것.
지키는 규칙을 데이터 그릇마다 하나씩 써 나가는 방식을 취하면, 그 방어는 「명시적으로 닫은 곳만 닫혀 있는」 상태가 됩니다. 새로운 그릇이 늘었을 때, 아무것도 쓰지 않으면 그것은 열려 있습니다.
이는 개발이 빠른 조직일수록 불리해지는 구조입니다. 그릇이 늘어나는 속도가 방어를 쓰는 속도를 웃돌기 때문입니다. 올바른 형태는 반대로, 우선 전체에서 「원칙 모두 거부」를 선언하고 명시적으로 허가한 것만 통과시킵니다. 그러면 새로운 그릇은 아무도 아무것도 하지 않아도 닫힌 상태에서 시작합니다. 이 한 가지 설계 차이가 5년 10년 운용했을 때의 결과를 결정적으로 가릅니다.
그리고 이런 종류의 구멍은 인증 배지로는 잡히지 않습니다.
이런 서비스의 보안 페이지에는 대개 각종 인증이나 암호화 배지가 늘어서 있습니다. 그것들은 거짓이 아닙니다. 다만 이번 노출은 정규로 인증된 세션에서, 데이터베이스가 「허가된 요청」으로 응답한 결과입니다.
- 제3자 인증이 증명하는 것은 프로세스의 존재이지, 모든 그릇, 모든 경로, 모든 신기능에서의 구현의 올바름이 아닙니다
- 저장 시 암호화가 지키는 것은 복호 키를 갖지 않은 상대이지, 인가 판정을 그르친 상대가 아닙니다
「인증을 받았으니 안전」은 성립하지 않습니다. 인증은 하한을 보장하는 것이지 상한을 보장하는 것이 아닙니다.
덧붙이면, 저희는 취득하지 않은 인증을 제품 설명에 쓰지 않는 방침을 취하고 있습니다. 쓸 수 있는 회사일수록 강조하고 싶어지는 대목이라 굳이 명기해 둡니다.
둘째, 기능 개수가 「경계를 넘는 정당한 이유」를 계속 만드는 것.
서비스가 성숙하면 반드시 이런 요구가 옵니다. 전사 횡단으로 검색하고 싶다. 관리자용으로 조직 전체의 이용 현황 대시보드를 원한다. 일괄 내보내기 기능을. 유사 사례를 추천하고 싶다. 쿼리가 느리니 집계 테이블을 만들고 싶다.
어느 것이나 정당한 비즈니스 요구입니다. 그리고 어느 것이나 테넌트 경계를 넘는 구현을 요구합니다. 악의도 날림도 없이 경계에 구멍이 열릴 이유가 쌓여 갑니다. 특히 위험한 것이 속도 개선을 위한 집계 테이블과 캐시입니다. 원본 데이터에는 소속 회사를 식별하는 표시가 있어도, 거기서 파생된 집계 데이터에서 표시가 떨어지는 사고가 매우 많습니다. 경계는 「처음 만든 곳」이 아니라 데이터가 복제, 변형되는 모든 곳에서 유지되어야 합니다.
셋째, 만드는 것이 빨라진 만큼 면이 계속 늘어나는 것.
이번 보고에는 덤이 붙어 있습니다. tl;dv의 사내용 월드컵 예측 앱 API가 인증 없이, 자사 직원 19명의 이름과 회사 메일 주소를 취득할 수 있는 상태였다는 것입니다1. 사내용, 놀이, 일시적. 그런 위치로 만들어진 것이 운영 도메인 아래에 놓여 실재하는 공격면이 되어 있었습니다.
생성형 AI에 의해 이런 종류의 「가볍게 만들어진 면」을 만드는 비용이 극적으로 낮아졌습니다. 만드는 것이 빨라진 만큼, 닫는 것도 자동이 아니면 따라잡지 못합니다. 그래서 첫 번째 이야기로 돌아갑니다.
AI를 더하면 유출의 형태가 바뀝니다
여기서부터가 AI를 다루는 저희에게 진짜 본론입니다.
AI 기능은 본질적으로 「횡단」을 원합니다. 검색 색인은 테넌트를 넘어 만드는 편이 정확도도 효율도 올라갑니다. 지식그래프는 노드끼리 잇는 데 가치가 있습니다. 「비슷한 사례」 「과거의 유사 안건」을 내는 기능은 경계를 넘었을 때 가장 유용해집니다. 임베딩, 요약, 캐시 같은 중간 처리는 원본 데이터의 구조를 떨어뜨려 다른 형태로 저장합니다.
즉 AI 기능의 추가는 앞의 「경계를 넘는 정당한 이유」를 가장 강한 형태로 들여옵니다. 게다가 중간 생성물이 늘어나는 만큼, 소속 회사를 식별하는 표시가 떨어지는 지점도 늘어납니다.
그리고 노출되었을 때 피해의 성질이 바뀝니다.
종래의 테넌트 분리 사고는 「다른 회사의 데이터가 검색되어 버린다」였습니다. AI를 끼우면 다른 회사의 데이터가 모델에 건네지는 맥락에 섞여 들어가, 모델이 능동적으로 그것을 말하기 시작합니다. 공격자가 탐색할 필요조차 없습니다. 평범한 사용자가 평범하게 질문한 것만으로 다른 회사의 정보가 답변에 섞입니다.
탐지도 어려워집니다. 접근 로그에는 「정상적인 질문」밖에 남지 않기 때문입니다.
따라서 AI 기능을 가진 멀티테넌트 SaaS에서는 다음이 필수 요건이 된다고 봅니다. 색인 자체를 테넌트 단위로 나누거나, 적어도 검색 전에 구분한다(나중에 거르는 방식은 상위 후보를 다른 테넌트의 데이터에 먹힌 시점에 품질 저하와 정보 유출을 동시에 일으킵니다). 임베딩, 요약, 캐시, 중간 생성물 모두에 소속 회사의 식별 표시를 갖게 하고, 사라지지 않았음을 테스트한다. 모델에 건네기 직전의 맥락에 대해 테넌트 정합성을 검사하는 층을 둔다.
사내 지식을 어떤 구조로 갖는가라는 이야기는 그래프 엔지니어링이란 무엇인가에서 지식의 구조 쪽으로 정리했습니다.
맡기는 쪽이 확인할 수 있는 것
마지막으로 도입을 검토하는 입장에서 무엇을 물으면 되는지 세 가지를 듭니다. 기술자가 아니어도 물을 수 있는 것으로 했습니다.
첫째, 「새로 기능을 추가했을 때 그 기능은 기본으로 닫혀 있습니까, 열려 있습니까」. 이 질문에 즉답할 수 있는 회사는 원칙 거부 설계입니다. 「매번 규칙을 쓰고 있습니다」라는 답이라면 앞서의 역학이 작용하는 구조입니다. 좋고 나쁨이 아니라 사실로서 짚어 둡니다.
둘째, 「테넌트를 넘을 수 없다는 것을 자동 테스트로 확인하고 있습니까」. A사의 권한으로 B사의 데이터를 가지러 가서 거부되는 것을 기계적으로 확인하는 구조가 있는가. 사람 손 테스트는 새 기능이 늘었을 때 「테스트를 쓰는 것을 잊는다」는 같은 실패 형태를 반복합니다.
셋째, 「취약점 보고를 받고 나서 막기까지 평균 어느 정도입니까」. 이번에 가장 무거웠던 것은 기술적인 설정 실수 자체가 아니라 보고를 받은 뒤의 시간이었습니다. 설정 실수는 일어납니다. 아무리 우수한 팀이라도 오래 운용하면 하나쯤은 놓칩니다. 보안의 성숙도는 취약점의 유무로는 잴 수 없습니다. 잴 수 있는 것은 알려지고 나서 막기까지의 시간입니다.
저희가 ZEROCK을 일본 국내 AWS 서버에서 운용하고, 누가 어떤 지식에 접근할 수 있는지를 통제하는 설계로 하고 있는 것도, 이 선 긋기를 제품 안쪽에 두고 싶기 때문입니다. 회의도, 사내 문서도, 심사 프로세스도 앞으로 가속도적으로 AI 서비스에 맡겨져 갑니다. 그때 맡기는 쪽이 물어야 할 것은 「어떤 인증을 갖고 있는가」가 아니라, 「경계가 기본으로 닫혀 있는가」와 「문제를 알려졌을 때 몇 시간 만에 움직이는가」라고 생각합니다.
자사의 지식을 어떻게 맡길지에 대해 구체적으로 상담하고 싶으시면 개별 상담으로 연락 주십시오.
Footnotes
-
보안 연구자 BobDaHacker의 공개 보고(2026년 8월 4일 공개). tl;dv가 이용하는 Firestore의
meetings컬렉션에 테넌트 간 접근 제어가 설정되어 있지 않아 인증된 사용자라면 플랫폼상의 회의 레코드에 접근할 수 있는 상태였던 것, 규모가 181,874건의 회의 레코드, 84,312명의 사용자, 35,003개의 메일 도메인인 것, 노출 필드에 작성자의 메일 주소, 회의 ID(Google Meet 또는 Teams의 입장 가능한 회의 ID), 제공자 정보, 녹화 상태, 타임스탬프가 포함되는 것,userschatstranscriptsclipsrecordingsvideosnotesteamsorganizations각 컬렉션은 제대로 403을 반환하고 있었던 것, 실증으로 말레이시아 교육부의 157명 규모 회의 및 미국 대학발 스타트업의 21명 규모 회의에 초대 없이 입장한 것, 보고가 2026년 1월 28일이며 공개 시점에 미수정이었다고 되는 것, 사내용 앱worldcup.tldv.io의/api/entities/Player가 인증 없이 자사 직원 19명의 이름과 회사 메일 주소를 포함한 데이터를 반환하는 상태였던 것은 모두 해당 보고에 따름. https://bobdahacker.com/blog/tldv-hack 공개 후 tl;dv 측은 보고 후 얼마 지나지 않아 해소했다는 취지의 코멘트를 냈고, 연구자는 6개월 뒤에도 재현했다고 반박하고 있다. 사실관계에는 이 차이가 남아 있으며, 본 기사는 어느 쪽이 정확한지의 판정을 하지 않는다. ↩ ↩2 ↩3 ↩4 ↩5 ↩6
