PingCAP 침해는 고객이 지원 티켓에 남긴 AWS 키까지 닿았습니다

PingCAP에 무슨 일이 있었나요?

분산 데이터베이스 TiDB와 관리형 서비스 TiDB Cloud를 운영하는 PingCAP이 2026년 10월 19일 보안 사고를 공개했습니다. 무단 접근은 9월 9일부터 10월 7일까지 약 4주 동안 이어졌습니다. PingCAP은 10월 7일에 침입을 알아차리고 그날부터 관련 자격증명을 비활성화했습니다. 10월 14일까지는 확인된 자격증명을 모두 무효화했습니다.

PingCAP의 의뢰로 조사한 NebuSec은 10월 21일 보고서에서 공격 경로를 밝혔습니다. 공격자는 탈취한 GitHub 계정으로 비공개 레포를 열었습니다. 그 안의 키와 토큰으로 Google Cloud와 Jira에 들어갔습니다. 그리고 Jira 지원 티켓에서 고객이 지원을 받으면서 공유한 AWS 키를 모은 뒤 그 키로 고객의 TiDB 진단 데이터가 든 S3 버킷에 접근했습니다.

이 글에서 가장 중요한 사실은 이것입니다. 공급업체가 뚫리자 고객이 지원을 받으려고 건넨 키가 고객 자신의 클라우드로 들어오는 입구가 됐습니다. 고객 TiDB 클러스터의 데이터에 접근한 증거는 없지만, 진단 데이터가 든 고객 S3 버킷은 열렸습니다. PingCAP CEO는 10월 23일 노트에서 "그 정보를 제대로 보호하지 못했다"고 썼습니다.

확인된 사실과 공격자 주장

PingCAP과 NebuSec이 확인한 사실:

• 접근 기간은 9월 9일~10월 7일입니다. 진입에 쓰인 GitHub 계정의 탈취 방법은 공개되지 않았습니다.
• 비공개 레포의 Git 기록과 평문 Terraform state 파일에 Google Cloud 서비스 계정 개인키가 있었습니다. 평문 Jira API 토큰과 내부 알림 봇 키도 있었습니다.
• 공격자는 Jira 지원 티켓에서 고객이 공유한 AWS 키 등 자격증명을 수집했습니다. 이 키로 고객 TiDB 진단 데이터가 든 S3 버킷에 닿았습니다.
• 9월 23~24일, 탈취된 Google Cloud 서비스 계정 8개를 써서 BigQuery 표 6,458개를 Cloud Storage로 내보냈습니다. 10월 2~5일에 rclone으로 내려받았습니다.
• 복사된 데이터에는 사용자 이름, 이메일 주소, 조직·프로젝트 소속, SQL 에디터에 입력한 텍스트와 오류, 계약·청구 정보, 소스코드가 들어 있었습니다.
• 내보낸 표에 TiDB Cloud API 키 값도 있었습니다. 다만 암호화돼 있었고 암호화 키는 노출되지 않았습니다. PingCAP은 이 판단이 지원 자료로 공유된 자격증명에는 해당하지 않는다고 따로 밝혔습니다.
• 고객 TiDB 클러스터 데이터에 접근한 증거, 명령을 실행하거나 지속 접근을 남긴 증거는 없습니다. 조사 중 찾은 취약점 4개는 수정·재시험을 마쳤고 악용된 증거는 없습니다.

공격자 그룹 FULCRUMSEC의 주장(독립 검증되지 않음):

• 10.6TB를 가져갔고 그중 약 200GB를 1차로 공개했다고 주장합니다.
• 콘솔 API 키 11만 5천여 개를 평문으로 확보했다고 주장합니다. PingCAP과 NebuSec이 밝힌 "암호화돼 있었다"는 조사 결과와 맞지 않습니다.
• 약 2개월간 머물렀다고 주장합니다. PingCAP이 밝힌 기간은 약 4주입니다.
• 고객 마이그레이션 작업의 외부 데이터베이스 엔드포인트 약 1,800개를 확보했으며 관리자 계정 정보도 포함돼 있다고 주장합니다.

아래에서는 확인된 접근 경로와 대응 권고를 중심으로 살펴봅니다. 공격자가 제시한 규모와 체류 기간은 피해 범위를 판단하는 근거로 쓰지 않습니다.

GitHub 계정 하나에서 고객 S3까지

비공개 레포에서 확보한 자격증명은 두 갈래로 쓰였습니다.

• Google Cloud: Git 기록과 Terraform state에서 얻은 서비스 계정 키로 BigQuery 표 6,458개를 Cloud Storage에 내보낸 뒤 내려받았습니다.
• Jira와 고객 AWS: 레포의 Jira API 토큰으로 지원 티켓을 열고 고객이 남긴 AWS 키를 수집했습니다. 그 키로 고객 진단 데이터가 든 S3 버킷에 접근했습니다.

두 갈래 모두 탈취된 GitHub 계정과 레포 속 평문 키에서 시작했습니다. 조사에서 찾은 취약점 4개가 악용된 증거는 없습니다. 공격자가 쓴 것은 취약점 대신 자격증명이었습니다. 레포는 비공개였고 Terraform state와 지원 티켓은 내부 시스템이었습니다. 계정 하나가 탈취되자 비공개라는 사실만으로는 아무것도 막을 수 없었습니다.

6,458개 표를 내보낸 9월 23~24일부터 침입을 알아차린 10월 7일까지는 약 2주가 걸렸습니다. 다운로드는 그 사이인 10월 2~5일에 이뤄졌습니다. PingCAP은 사고 뒤 저장소 접근 기록을 추가로 켰고, CEO 노트에서 "비정상 접근과 대량 데이터 이동은 탐지되고 대응돼야 한다"고 약속했습니다.

암호화된 API 키와 지원 자료의 키

NebuSec 보고서에 따르면 내보낸 표의 TiDB Cloud API 키 값은 암호화돼 있었고 암호화 키는 노출되지 않았습니다. 이 암호화된 값은 공격자가 그대로 사용할 수 없었습니다. PingCAP은 지원 자료로 공유된 자격증명에는 이 판단이 적용되지 않는다고 따로 밝혔습니다.

지원 티켓의 고객 AWS 키는 실제 S3 접근에 쓰였습니다. 따라서 API 키 값의 암호화 여부만으로 지원 자료에 남긴 키까지 안전하다고 판단해서는 안 됩니다. PingCAP의 교체 권고는 관리 API 키와 지원팀에 공유한 자격증명을 모두 포함합니다.

지원 티켓은 시크릿 저장소로 설계된 곳이 아닙니다. 그런데 고객은 문제를 빨리 해결하려고 접속 정보와 키를 붙여 넣습니다. 엔지니어는 문제를 재현하려고 로그를 첨부합니다. Dark Reading은 Sysdig 소속 Crystal Morin이 지적한 내용을 전했습니다. 고객이 편의 기능을 통해 공급업체에 시크릿을 넘기는 일이 잦으며 쿼리 기록이나 오류 출력처럼 자격증명 저장소로 여기지 않는 곳에 시크릿이 쌓인다는 내용입니다. PingCAP에서 복사된 데이터에도 SQL 에디터 텍스트와 오류가 있었습니다. 그 안에 자격증명이 있었는지는 확인되지 않았습니다.

이런 곳의 키는 암호화되지 않고 담당자도 없으며 사고가 나도 교체 목록에 잘 오르지 않습니다.

TiDB Cloud 사용자라면 지금 할 일

PingCAP은 개별 통지를 기다리지 말고 바로 조치하라고 권고합니다.

1. 활성 TiDB Cloud 관리 API 키를 교체하세요. 새 키로 애플리케이션을 전환하고 동작을 확인한 뒤 기존 키를 삭제하세요.
2. PingCAP 지원팀과 공유한 키와 연결 문자열 등 자격증명을 모두 교체하세요. 로그에 포함해 전달한 자격증명도 확인하세요. 티켓에 붙여 넣은 AWS 키가 있다면 가장 먼저 처리할 대상입니다.
3. 해당 AWS 키의 CloudTrail 기록에서 9월 9일 이후 낯선 IP·User-Agent에서 온 S3 읽기와 목록 조회가 있었는지 확인하세요.
4. 마이그레이션 작업에 데이터베이스 계정을 넘긴 적이 있다면 해당 계정의 비밀번호도 교체하세요. 이 접속 정보의 유출은 공격자 주장입니다. 지원팀에 실제로 공유한 자격증명이라면 PingCAP의 교체 권고에 포함됩니다.
5. 비밀번호, 인증 코드, 결제 정보 변경을 요구하는 연락은 공식 채널로 다시 확인하세요. 실제 고객 정보가 담긴 표적 피싱이 올 수 있습니다.

TiDB Cloud를 쓰지 않아도 점검할 것

아래는 이번 사고를 바탕으로 우리 환경에서 점검할 항목입니다. 위키 등 추가 점검 대상에서 이번 사고의 키 노출이 확인됐다는 뜻은 아닙니다.

• 지원 티켓, 이슈 트래커, 위키에 붙여 넣은 키. Jira와 Confluence에서 액세스 키 형식의 문자열을 찾아본 적이 있나요?
• 공급업체 지원팀에 건넨 자격증명. 언제, 누구에게, 무엇을 줬는지 기록이 있나요? 지원이 끝난 뒤 폐기했나요?
• Git 기록과 Terraform state에 남은 클라우드 키. 현재 코드에서 지운 키가 Git 기록이나 별도 state에 남아 있지 않은지 확인하세요.
• 비공개 레포 접근 권한. 계정 하나가 탈취됐을 때 그 계정이 열 수 있는 레포와 그 안의 키 범위를 확인하세요.
• 서비스 계정의 대량 내보내기. BigQuery EXTRACT, 대량 S3 GET 같은 작업에 경보가 걸려 있나요?
• 고객이 우리에게 보낸 키. 우리도 누군가의 공급업체라면 우리 지원 채널에 고객 키가 쌓여 있을 수 있습니다.

Cremit으로 확인할 수 있는 것

PingCAP 내부의 Jira나 Google Cloud는 저희가 볼 수 없습니다. 티켓 속 키의 열람 여부는 PingCAP의 통지·조사 결과로, 실제 사용 여부는 발급처 기록으로 확인해야 합니다.

Cremit Platform은 우리 회사 쪽을 확인합니다. PingCAP 사고의 경로를 그대로 따라가 보면 단계마다 Cremit이 먼저 볼 수 있는 키가 있습니다.

• 코드와 Git 기록: 연결한 GitHub·GitLab·Bitbucket 저장소에서 클라우드 서비스 계정 키, API 토큰 등 1,000가지 이상 유형의 자격증명을 찾습니다. 레포가 비공개라도 그 안의 키는 인벤토리에 올라옵니다.
• 지원 티켓과 문서: Jira 이슈와 Confluence 페이지, Slack, Notion, Google Drive에 붙여 넣은 키를 같은 기준으로 찾습니다. 이번 사고에서 공격자가 고객 키를 가져간 바로 그 자리입니다.
• 살아 있는지: 지원하는 유형의 키가 지금도 발급처에서 인증되는지 자동으로 검증합니다. 살아 있는 키는 약 6시간마다 다시 확인합니다. 수천 건의 탐지 결과 중에서 지금 당장 교체할 키만 추려냅니다.
• 무엇을 열 수 있는지: AWS 액세스 키로 무엇을 할 수 있는지 권한 범위를 보여줍니다. 티켓 속 AWS 키가 아직 살아 있고 S3 버킷을 읽을 수 있다면 그 키가 목록 맨 위에 올라옵니다.
• 누구의 키인지: 탐지된 키마다 담당자를 지정하고 처리 과정을 기록합니다. SSO·SCIM과 연결하면 퇴사자가 만든 키도 표시합니다. "만든 사람이 없는 키"가 사고 뒤 교체 목록에서 빠지는 일을 막습니다.
• 바로 알리는지: 새로 노출된 키는 Slack, 웹훅, Telegram, 이메일로 알리고 탐지부터 조치까지 걸린 시간(MTTD/MTTR)을 기록합니다.
• 볼트와 비교: AWS Secrets Manager에 저장된 시크릿 중 살아 있는 것, 쓰이지 않는 것, 코드에도 함께 노출된 것을 구분합니다. 정식 저장소의 키가 레포에 복사돼 있다면 그것도 드러납니다.

공급업체가 언제 뚫릴지는 우리가 정할 수 없습니다. 그 순간 우리 키가 어디에 몇 개나 살아 있는지는 미리 알 수 있습니다. 무료 플랜으로 지금 바로 연결해 보세요.

지원 티켓도 시크릿 저장소입니다

내보낸 표의 API 키 값은 암호화돼 있어 공격자가 쓸 수 없었습니다. 실제로 쓰인 고객 키는 아무도 시크릿 저장소로 여기지 않던 지원 티켓에 있었습니다.

키가 저장되는 곳은 시크릿 저장소 하나가 아닙니다. 붙여 넣은 곳은 모두 저장소입니다. 그런 곳의 키를 찾아 교체·폐기하는 일까지 시크릿 관리에 포함하세요. 우리 지원 채널에 고객이 남긴 키도 마찬가지입니다.

함께 읽기

• Zeabur 두 번째 침해: 교체에서 빠진 관리자 키
• LiteLLM 공급망 공격: 지웠지만 폐기 안 한 키
• 같은 API 키가 저장소 세 곳에서 발견됐다면
• 버그바운티는 왜 자격증명 노출을 뺄까