딥시크: 로그인 없이 열린 로그 DB에 대화와 API 키가

아프로·2026년 11월 1일

해외 보안사고 사례

목록 보기

11/13

딥시크 로그 DB 노출 표지

100만 줄. 클라우드 보안 기업 위즈(Wiz)의 연구팀이 딥시크(DeepSeek) 데이터베이스에서 확인한 로그의 양입니다. 그 로그에는 사용자가 챗봇에 입력한 대화가 평문으로 들어 있었고, API 키도 함께 찍혀 있었습니다. 데이터베이스에는 비밀번호가 걸려 있지 않았습니다. 세계적인 화제가 된 AI 모델을 만든 회사였지만, 사고는 모델 옆의 로그 저장소에서 났습니다.

사고 원인: 인증 없이 열린 데이터 저장소와 로그 속 시크릿. 운영 로그를 담은 분석용 DB가 인터넷에 그대로 열려 있었고, 로그에는 대화 원문과 API 키가 남아 있었습니다. 시크릿은 비밀번호·API 키·서명키·인증키처럼 코드와 로그 밖에 숨겨야 하는 값입니다.

한눈에 보기

항목	내용
시점	2025년 1월. 위즈 블로그 공개 2025-01-29
발견	위즈가 딥시크의 외부 공격 표면(인터넷에서 보이는 서버·서비스 전체)을 점검하다 발견. "몇 분 만에" 찾았다는 보도(The Register)
노출 범위	위즈가 찾은 서브도메인 약 30개 중 2곳에서 클릭하우스(ClickHouse) DB가 외부 포트로 공개
데이터	`log_stream` 테이블에 로그 100만 줄 이상(2025-01-06부터). 평문 대화, API 키·시크릿, 백엔드 세부 정보, 운영 메타데이터, 디렉터리 구조
조치	위즈 알림 뒤 딥시크가 1시간 안에 차단(위즈 CTO, 로이터 보도)
확인되지 않은 것	노출 기간, 위즈 이전에 제3자가 접근했는지 여부. 딥시크는 공식 입장을 내지 않음

이 사건은 같은 시기에 나온 한국 개인정보보호위원회(개인정보위)의 딥시크 시정권고와 다른 사안입니다. 두 사건을 섞지 않도록 개인정보위 사안은 "제재와 비용" 절에서 따로 적습니다.

무슨 일이 있었나

2025-01-06 노출된 log_stream 테이블의 로그가 이날부터 쌓여 있었습니다(위즈).
2025년 1월 딥시크 R1 모델이 세계적인 화제가 된 직후, 위즈가 딥시크의 외부 공격 표면을 점검했습니다.
발견 직후 위즈가 인증 없이 열린 클릭하우스를 확인하고 딥시크에 알렸습니다. 딥시크는 1시간 안에 접근을 막았습니다(위즈 CTO, 로이터 보도).
2025-01-29 위즈가 연구 결과를 블로그에 공개했습니다.

외부에 열린 서브도메인에서 인증 없는 분석 DB, 웹 쿼리 인터페이스, 평문 로그로 이어지는 경로와 막을 수 있었던 네 지점

공격 절차는 다루지 않고 구조만 봅니다. 클릭하우스(대량의 로그를 빠르게 모으고 집계하는 분석용 데이터베이스)는 서비스 운영 로그를 담고 있었습니다. 이 DB가 딥시크의 서브도메인 2곳에서 인터넷 쪽 포트로 열려 있었고, 접속에 인증을 요구하지 않았습니다. DB에는 웹 쿼리 인터페이스(브라우저로 HTTP 요청을 보내 SQL을 실행하는 기능)가 켜져 있었습니다. 그래서 별도 도구 없이 브라우저만으로 SQL을 실행할 수 있는 상태였습니다.

위즈는 목록을 조회하는 수준을 넘는 침해적 쿼리는 하지 않았다고 밝혔습니다. 노출이 언제부터 있었는지, 위즈보다 먼저 누가 접근했는지는 확인되지 않았습니다.

왜 뚫렸나

위즈 연구팀(Wiz Research)이 공개한 원문을 기준으로 원인을 정리하면 다섯 가지입니다.

인증 없는 분석 DB. 운영 로그를 담은 클릭하우스가 인증 없이 인터넷에 공개돼 있었습니다.
로그에 남은 대화와 키. 로그에 사용자 대화와 API 키가 평문으로 들어 있었습니다. 위즈는 로그가 사실상 "두 번째 데이터베이스" 역할을 하고 있었다고 봤습니다.
켜져 있던 웹 쿼리 인터페이스. 브라우저만으로 SQL을 실행할 수 있었고, 설정에 따라서는 서버의 로컬 파일까지 읽을 수 있었습니다. 위즈는 이 상태를 "데이터베이스 전체 제어와 내부 권한 상승 가능성"으로 평가했습니다.
확장 속도를 따라가지 못한 보안. 위즈는 "보안 없이 AI 서비스를 빠르게 도입하는 것 자체가 위험하다"고 표현했습니다 [분석사 의견].
찾기 어려웠던 신고 창구. 위즈가 알릴 보안 연락 창구를 찾기 어려웠다는 보도가 있습니다 [보도, 미확인].

위즈는 이 사건을 "AI 위협은 미래의 이야기지만, 실제 위험은 AI를 받치는 기본 인프라에서 나온다"고 정리했습니다. 모델의 안전성과 별개로, 로그와 분석 도구 같은 주변 인프라가 먼저 무너졌다는 뜻입니다.

개발자 시점: 내 서비스였다면

같은 실수가 일반 서비스의 설정과 코드에서는 어떤 모양인지 보겠습니다. 사고 회사의 코드가 아니라 같은 실수를 보여 주는 일반 예시입니다. 값은 모두 가짜입니다.

<listen_host>0.0.0.0</listen_host>

<users><default>
  <password></password>
  <networks><ip>::/0</ip></networks>
</default></users>

# 위험한 모양 · 일반 예시
log.info("chat", extra={
    "user": user_id,
    "prompt": req.prompt,          # 대화 원문
    "auth": req.headers["Authorization"],  # API 키
})

문제는 세 군데입니다. DB가 모든 주소에서 접속을 받고, 기본 계정에 비밀번호가 없으며, 어느 네트워크에서 와도 허용합니다. "내부용으로 잠깐 띄운 분석 DB"가 흔히 이 모양입니다. 그리고 애플리케이션 로그는 프롬프트(사용자가 AI에 입력한 질문) 원문과 인증 헤더를 그대로 남깁니다. DB가 열리는 순간 로그 전체가 대화 기록과 키 목록이 됩니다.

<listen_host>10.0.1.5</listen_host> 
<users><default>
  <password_sha256_hex>FAKE-0000hash</password_sha256_hex>
  <networks><ip>10.0.0.0/8</ip></networks>
</default></users>

# 고친 모양 · 일반 예시
log.info("chat", extra={
    "user": user_id,
    "prompt_len": len(req.prompt),   # 원문 대신 길이
    "key_id": key_id_of(req),        # 키 대신 키 아이디
})
# 원문이 꼭 필요하면 마스킹 후 별도 저장소, 보관 기간 지정

고친 모양은 네 군데가 다릅니다.

사설 주소에만 묶기. DB는 내부 주소에서만 접속을 받습니다. 인터넷 쪽 방화벽에서도 DB 포트를 닫아 둡니다.
기본 계정 비밀번호와 접속 대역. 기본 계정에도 비밀번호를 걸고, 접속을 허용할 네트워크를 사설 대역으로 줄입니다.
로그에는 원문 대신 메타데이터. 프롬프트는 길이나 분류 값만 남기고, 키는 키 아이디만 남깁니다.
원문 저장은 목적과 기한을 정해서. 품질 분석 때문에 원문이 꼭 필요하다면 토큰·키·개인정보를 마스킹한 뒤 별도 저장소에 두고 보관 기간을 정합니다.

이미 로그에 찍힌 키는 노출된 것으로 보고 교체합니다(점검 5줄의 3번).

국내에서도 같은 일이

국내편 AI가 바꾼 공격: 2026 금융권 연쇄 해킹과 AI 활용 해커(08편)도 관리가 소홀한 외곽 시스템에서 시작했습니다. 대출모집인 조회 서비스, 영업지원 시스템, 외부 웹서버처럼 본인 인증 없이 조회되거나 알려진 취약점이 남은 곳이었습니다. 딥시크의 분석 DB도 "내부용"으로 여겨지는 외곽 도구였고, 외부 점검으로 몇 분 만에 보였다는 보도가 있습니다. 다른 점도 있습니다. 딥시크 건은 연구자가 찾아 1시간 안에 닫혔고 제3자 접근은 확인되지 않았습니다. 국내 08편은 실제 유출로 이어졌고 2026년 10월 말 기준 수사가 진행 중입니다. 08편의 교훈처럼 AI 도구는 새 취약점보다 방치된 곳을 빠르게 찾습니다. 열어 둔 분석 DB가 바로 그런 곳입니다.

막을 수 있었던 네 지점

위 흐름도의 그린 표시와 같은 번호입니다.

보조 서브도메인까지 넣은 자산 목록. dev·oauth 같은 보조 서브도메인까지 자산 목록에 넣어 관리했다면, 서비스 출시와 함께 노출 점검을 했을 것입니다.
사설망과 기본 계정 비밀번호. 로그·분석 DB를 사설망에 두고 기본 계정에 비밀번호를 걸었다면, 외부 점검 몇 분 만에 발견될 일이 없었습니다.
로그 마스킹. 로그에 프롬프트 본문과 API 키를 남기지 않거나 마스킹했다면, 노출되더라도 피해는 운영 메타데이터에 그쳤을 것입니다.
공개 신고 창구. security.txt(웹사이트에 보안 연락처를 적어 두는 표준 파일)나 버그 바운티 같은 신고 창구가 있었다면, 신고가 바로 담당자에게 닿았을 것입니다.

1·2번은 DB가 열리는 일을 막고, 3번은 열려도 남는 피해를 줄이며, 4번은 누군가 먼저 찾았을 때 닫히는 시간을 줄입니다.

같은 사고를 막는 점검 5줄

로그 파이프라인에서 토큰·키·개인정보를 마스킹하고, LLM 프롬프트·응답 원문 저장은 목적과 보관 기간을 정해 둔다.
클릭하우스·그라파나(Grafana)·키바나(Kibana)·주피터(Jupyter)처럼 "내부용"으로 띄운 분석·관측 도구에도 인증, 사설망, 접근 로그를 기본으로 적용한다.
로그에 키가 찍혔다면 노출로 보고 즉시 교체한다. 수명이 짧은 토큰을 쓴다.
인증서 투명성(CT, 발급된 인증서를 공개 기록하는 로그) 로그와 DNS 기록으로 내 서브도메인을 정기적으로 모으고, 열린 포트를 점검한다.
/.well-known/security.txt에 보안 연락처를 둔다. 연구자의 신고는 조기 경보로 받는다.

제재와 비용

DB 노출에 대한 제재: 공개된 자료로 확인되는 제재는 없습니다. 딥시크는 공식 입장을 내지 않았고, 중국 당국은 공식 확인하지 않았습니다.
한국 개인정보위 조치(별개 사안): 개인정보위는 2025년 2월 15일 딥시크 앱의 국내 신규 다운로드를 잠정 중단시켰습니다. 4월 24일 점검 결과를 발표하며, 이용자 프롬프트를 동의 없이 바이트댄스 계열사로 국외 이전한 점 등에 시정권고를 했습니다. 서비스는 4월 28일 재개됐습니다. 이 조치는 위즈가 찾은 DB 노출과 다른 사안입니다.

DB 노출 건은 연구자 공개로 끝났고, 규제 조치는 개인정보 국외 이전 문제에서 나왔습니다. 두 사안을 하나의 사고로 읽지 않도록 주의가 필요합니다. 위 내용은 공개 보고서·보도를 정리한 것이며 법률 자문이 아닙니다.

정리

딥시크의 분석용 클릭하우스 DB가 인증 없이 인터넷에 열려 있었고, 로그 100만 줄 이상에 평문 대화와 API 키가 남아 있었습니다(위즈 연구팀).
딥시크는 알림 뒤 1시간 안에 차단했지만, 노출 기간과 제3자 접근 여부, 딥시크의 공식 입장은 확인되지 않았습니다.
AI 서비스는 프롬프트라는 민감 데이터를 대량으로 쌓습니다. 가장 먼저 잠글 곳은 모델이 아니라 프롬프트가 쌓이는 로그·분석 인프라입니다. 운영 DB와 같은 수준으로 잠가야 합니다.

같은 실패, 즉 인증 없이 열린 데이터 저장소는 앞 편 상하이 경찰 데이터베이스(10편)에서도 원인이었습니다.

더 깊게

인프런 「백엔드 개발자를 위한 서버 보안 실무」 수업

5-4 개인정보보호법 관점의 개발: 최소 수집, 마스킹, 접속 기록
1-4 닫힌 포트는 공격받지 않는다: ufw와 firewalld
5-3 시크릿 관리: .env 유출, 저장소 스캔, 키 회전
6-1 취약점 점검 도구 운영

관련 velog 글

해외편 상하이 경찰 데이터베이스: 비밀번호 없는 검색 서버에 10억 명: 인증 없이 열린 검색 서버
국내편 AI가 바꾼 공격: 2026 금융권 연쇄 해킹과 AI 활용 해커: 외곽 시스템을 노린 자동화 공격

보안을 더 알고 싶다면

오늘 본 사고의 원인은 대부분 서버와 코드의 기본기에서 막을 수 있는 것들이었습니다. 직접 손으로 막아 보고 싶다면 이런 강의도 있습니다.

백엔드 개발자를 위한 서버 보안 실무: 해킹 방어부터 정보유출 방지까지

서버를 공격하는 흐름을 로그로 보고, 내 서버와 Spring·Express 코드에서 직접 막아 봅니다.
SSH 하드닝, 인젝션, 인증·인가, 시크릿과 개인정보 보호, 침해사고 첫 한 시간까지 8개 섹션 54개 수업입니다.
이 글과 이어지는 수업: 5-4 개인정보보호법 관점의 개발: 최소 수집, 마스킹, 접속 기록 · 1-4 닫힌 포트는 공격받지 않는다: ufw와 firewalld · 5-3 시크릿 관리: .env 유출, 저장소 스캔, 키 회전