보안 연구원 Frank Chu는 Zoom과 Teams에 연결되는 AI 기반 회의록 서비스인 tl;dv가 단 하나의 Firebase 보안 규칙 누락으로 인해 181,874개의 비공개 회의 녹취록을 유출했음을 발견했습니다. 이로 인해 어떤 로그인된 사용자라도 전체 기록 세트를 읽을 수 있었습니다. 이번 침해 사고는 35,003개 도메인에 걸쳐 84,312명의 사용자에게 영향을 미쳤으며, 이는 아주 작은 설정 실수가 가장 기밀한 기업 대화를 노출할 수 있음을 상기시켜 줍니다.
유출 발생 경위
tl;dv는 Google Firebase의 Firestore 데이터베이스에 노트를 저장합니다. Firestore에서 개발자는 각 문서를 읽거나 쓸 수 있는 권한을 결정하는 보안 규칙을 작성합니다. tl;dv의 대부분의 컬렉션은 올바르게 잠겨 있었으나, meetings 컬렉션에는 요청자의 신원을 확인하는 규칙이 누락되어 있었습니다. 결과는 간단했습니다. 사용자가 앱에 로그인하기만 하면, API가 서비스에 저장된 모든 회의 문서 목록을 반환했습니다.
정교한 공격이나 악성 페이로드, 또는 기반이 되는 AI 모델의 침해는 없었습니다. 이 취약점은 전형적인 접근 제어 관리 소홀로, "소유자 또는 초대된 참가자만 이 회의를 볼 수 있다"라고 명시되어 있어야 할 코드 한 줄이 빠진 것이었습니다. 규칙이 누락되었기 때문에, 초대 여부와 관계없이 인증된 사용자라면 누구나 모든 녹취록을 열거하고 다운로드할 수 있었습니다.
이것이 중요한 이유
회의 녹취록에는 이사회 심의 내용, 제품 로드맵, 법률 자문 및 영업 협상 내용이 포함되는 경우가 많습니다. 이러한 내용이 공개적으로 읽힐 수 있게 되면, 경쟁사가 전략적 통찰력을 수집할 수 있고, 변호사는 기밀 유지 의무를 재검토해야 할 수도 있으며, 직원은 자신이 사용하는 도구에 대한 신뢰를 잃게 됩니다. 수십만 개의 기록이 유출된 이번 사건은 tl;dv의 권한 모델을 면밀히 검토하지 않고 도입한 조직이라면 어디든 영향을 미칠 수 있는 시스템적 실패입니다.
대응 지연
Chu는 1월에 tl;dv 팀에 누락된 규칙을 보고했습니다. 적절한 읽기 제한을 추가하고 규칙 세트를 재배포하는 수정 작업은 8월이 되어서야 적용되었습니다. 민감한 데이터에 대한 무제한 읽기 권한을 부여하는 취약점에 대해 발견부터 해결까지 6개월이 걸린 것은 이례적으로 긴 시간입니다. 이러한 지연은 분류(triage)부터 패치 배포에 이르기까지 회사의 취약점 관리 프로세스에 결함이 있음을 보여줍니다.
AI 기반 에이전트를 위한 더 넓은 교훈
이 사건은 흔히 "AI 리스크"로 규정되지만, 근본 원인은 전통적인 접근 제어 실수입니다. 회의를 녹취하거나, 이메일을 초안하거나, 문서를 요약하는 AI 에이전트는 인간 사용자와 동일한 데이터에 접근할 수 있는 서비스 계정 권한으로 실행됩니다. 이러한 권한이 지나치게 광범위할 경우, AI는 다른 백엔드 서비스와 마찬가지로 데이터 유출의 통로가 되기 쉽습니다.
오늘날 조직이 할 수 있는 일
- 권한 부여 로직 감사 – AI 도구가 사용하는 모든 데이터베이스 컬렉션, API 엔드포인트 또는 클라우드 스토리지 버킷이 최소 권한 원칙(least-privilege)을 준수하는지 확인하십시오. tl;dv에서 발생한 것과 같이 누락되었거나 과도하게 허용된 규칙이 있는지 살펴보십시오.
- 녹음 범위 제한 – 회의 녹취 에이전트가 명시적으로 승인한 회의만 캡처하도록 구성하십시오. 기본적으로 녹음이 활성화되는 설정은 공격 표면을 넓히지만, 옵트인(opt-in) 모델은 노출 범위를 좁게 유지합니다.
- AI 에이전트를 서비스 계정으로 취급 – 모든 서드파티 AI 통합을 목록화하고, 전용 ID를 할당하며, 기능을 수행하는 데 필요한 권한만 부여하십시오. 사용하지 않는 계정은 정기적으로 검토하고 취소하십시오.
- 보안 규칙 스트레스 테스트 – 적절한 자격 증명 없이 컬렉션에서 데이터를 읽으려는 시도를 하는 자동화된 테스트를 실행하십시오. 이러한 점검을 CI/CD 파이프라인에 포함하여 배포 전에 누락된 규칙을 찾아내십시오.
- 사고 대응 가속화 – 보고된 취약점을 확인, 분류 및 패치하기 위한 명확한 타임라인을 수립하십시오. 이번 사례와 같이 6개월의 해결 기간이 소요되는 것은 단순한 버그의 영향을 증폭시킬 수 있는 프로세스 실패입니다.
향후 주목해야 할 점
회의록 작성, 통화 요약 또는 실시간 녹취를 위해 AI 어시스턴트에 의존하는 기업은 다른 클라우드 네이티브 서비스에서도 유사한 설정 오류가 발생할 수 있음을 예상해야 합니다. AI 에이전트가 일상적인 워크플로에 더 깊숙이 통합됨에 따라 "AI 리스크"와 "전통적인 보안 리스크" 사이의 경계가 모호해지고 있습니다. 권한 검토를 지속적으로 수행하고, 벤더에게 투명한 보안 규칙 감사를 요구하며, 다음 "규칙 하나 누락" 사건이 또 다른 기밀 대화 더미를 유출하는 것을 방지하기 위해 신속한 패치 주기를 추진하십시오.
핵심은: AI 도구의 보안은 해당 도구가 다루는 데이터를 보호하는 액세스 제어 수준에 달려 있습니다. 단 하나의 Firestore 규칙 누락이 유용한 노트 작성 보조 도구를 대규모 데이터 유출 사고로 변질시켰으며, 정기적으로 테스트된 권한 설정만이 유일하고 신뢰할 수 있는 방어책입니다.