클라우드 환경변수가 유출된 뒤, 새 키를 채팅창에 다시 보내면 안 되는 이유

2026년 8월 하순, 클라우드 배포 플랫폼 Zeabur가 환경변수가 무단으로 읽힌 사고를 공개했습니다. 공식 상태 페이지에 따르면 공격자는 내부 서비스 자격 증명 하나로 프로젝트 Variables를 조회·내보냈고, 목표는 바로 쓸 수 있는 AI 서비스 API 키와 기타 자격 증명이었습니다. 상태 페이지에 적힌 키 이름에는 OPENAI_API_KEY, ANTHROPIC_API_KEY, OPENROUTER_API_KEY, DATABASE_URL, AWS_ACCESS_KEY_ID, 그리고 JWT·Stripe·GitHub처럼 흔한 형식이 포함됩니다. 사용자 지정 변수 이름이라도 값이 이런 자격 증명처럼 보이면 노출 범위에 들어갔습니다. 대조는 Zeabur 상태 페이지 사고 설명에서 할 수 있습니다.

iThome 2026년 8월 31일 보도는 시간선을 보충합니다. 회사는 8월 26일 이상을 알아차렸고, 다음 날 사용자에게 즉시 로테이션과 청구·사용량 확인을 요청했습니다. 같은 주 테크뉴스는 창업자 설명을 전합니다. 조회 로그상 공격자는 AI API 키를 겨냥해 내보냈습니다. 이후 다크웹 포럼에 「전체 데이터 패키지」를 파는 스크린샷이 돌았지만, 당시 공식은 확보한 증거가 그 자료의 진위를 뒷받침하지 않는다고 밝혔습니다. 이 글도 그 자료를 확정 사실로 쓰지 않습니다.

이런 사고의 처리 목록은 거의 고정입니다. 옛 키를 폐기하고, 사용량을 확인하고, 새 키로 바꿉니다. 첫 번째 유출은 이미 호스팅 쪽에서 일어났습니다. 상대가 읽은 문자열을 그 손에서 거둬들일 수는 없습니다. 건너뛰기 쉬운 것은 두 번째입니다. 새 키를 만든 뒤에도 동료에게 넘기고, 다른 기기 환경에 붙이고, 임시 티켓에 적어야 합니다. 이 단계를 채팅창으로 하면, 「방금 로테이션한 평문」을 검색되고, 동기화되고, 관리자가 내보낼 수 있는 기록에 다시 쓰는 셈입니다.

여기서 플랫폼 이름은 시점과 공개 사실을 고정할 뿐입니다. 결론은 「먼저 로테이션하고, 그다음 전달하는」 모든 장면에 그대로 적용됩니다. 데이터베이스 비밀번호, CI 토큰, 임시 SSH 비밀번호도 같습니다. 위험한 것은 「상대가 본다」가 아니라, 「중간 한 칸마다 완전한 평문 사본이 남을 수 있다」는 점입니다. 이 글은 특정 클라우드를 어떻게 강화해야 하는지 재구성하지 않으며, UsePwd를 호스팅 쪽 읽기를 막는 금고로 쓰지도 않습니다.

sk-로 시작하는 문자열을 채널에 붙이면, 사본은 한 곳이 아닙니다. 메시지 본문은 워크스페이스 기록에 들어가고, 데스크톱과 휴대폰이 각각 캐시를 남기며, 어떤 제품은 세 달 뒤 「openai」 두 글자로 다시 꺼낼 수 있게 서버 검색 인덱스에 넣습니다. 관리자 내보내기, 법적 증거 보전, 퇴사 인수인계 때의 「채팅 기록 묶음」은 그 순간의 평문을 함께 가져갑니다. 메시지 하나를 지워도, 상대가 이미 읽은 푸시, 내려받은 클라이언트 보관함, 캡처 도구가 남긴 한 프레임까지 지워지지는 않는 경우가 많습니다.

이것은 「동료를 믿느냐」와 다른 문제입니다. 동료는 새 키가 있어야 서비스를 다시 돌릴 수 있습니다. 문제는 채팅 채널이 기본값으로 「검색 가능한 업무 기록」을 남기고, 「보고 끝나는 일회용 비밀」을 남기지 않는다는 점입니다. 채널에 「새 키는 아래」라고 쓰면, 그 채널을 검색할 수 있는 사람 모두에게 동시에 알리는 것과 같습니다. 나중에 초대된 사람, 감사 내보내기 권한이 있는 사람, 앞으로 백업에 접근할 수 있는 사람까지 포함합니다.

흔한 비상 절차를 펼치면, 위험한 지점은 「공급사 콘솔에 들어가 새 키를 만드는 순간」이 아닙니다. 그 앞뒤입니다. 어떤 사람은 옛 키 스크린샷을 동료에게 보내 「이 키 맞냐」고 확인하고, 어떤 사람은 콘솔 전체 화면을 찍어 주소창·다른 프로젝트 이름·청구 숫자까지 앨범에 넣으며, 어떤 사람은 새 키를 만든 뒤 「자리에 없으니까」 단톡에 「일단 올려」라고 던집니다. 세 단계 모두 평문을 오래 남을 수 있는 객체로 만듭니다.

더 잘 빠지는 경로는 클라우드 드라이브와 저장소입니다. .env를 공유 폴더에 그대로 넣거나, 키가 들어 있는 예제를 임시 코드 브랜치에 올리는 경우가 있습니다. 클라우드 동기화는 로그인한 기기마다 사본을 하나 더 떨어뜨리고, Git 히스토리는 나중에 파일을 고쳐도 옛 커밋의 문자열이 남습니다. 파일 하나 5 GB 이하인 로컬 백업은, 평문 .env를 일반 문서처럼 올리지 말고 현재 탭에서 먼저 암호문으로 만든 뒤 저장해야 합니다. UsePwd의 파일 암호화는 AES-256-GCM으로 스트리밍 로컬 암호화를 하며, 출력은 .lock / .enc이고 파일은 기본으로 업로드되지 않습니다. 그것은 「암호문 파일을 내가 남겨 두는 일」이지, 「키를 채팅에 넣는 일」이 아닙니다.

채팅창이 넘기는 것은 평문입니다. 받는 쪽도 편하고 보내는 쪽도 편합니다. 대가는 워크스페이스, 검색, 백업이 각각 한 부를 갖는 것입니다. 메일 첨부도 같습니다. .env나 메모장이 첨부가 되는 순간, 메일 서버와 양쪽 클라이언트에 완전한 파일이 있습니다.

일회용 암호화 링크가 넘기는 것은 「암호문 번호 + 이 기기에만 있는 복호화 재료」입니다. UsePwd 일회용 링크는 현재 탭에서 Web Crypto로 텍스트를 AES-256-GCM 암호화한 뒤 암호문만 서버에 맡깁니다. 복호화 키는 주소 s.html?id={id}#{key}의 # 뒤에 붙습니다. 만들기 페이지와 읽기 페이지 모두 가입 없이 바로 쓰며, 양쪽 모두 등록이 필요 없습니다. 서버가 잠시 보관하는 것은 암호문, 유효 시간, 읽기 횟수뿐입니다. 평문은 보이지 않고, 「사용자별로 찾아 주는」 계정 체계도 없습니다.

키를 # 뒤에 두는 것은 「호스팅 쪽 접속 로그와 HTTP 요청 라인」 한 층을 푸는 일입니다. 브라우저는 프래그먼트를 요청의 일부로 보내지 않습니다. 원리 분해는 기존 글 URL의 # 이후가 서버 로그에 안 남는 이유에 있습니다. 이 글이 보태는 것은 다른 층입니다. 키가 UsePwd 요청 라인에 안 들어가더라도, 완전한 링크를 채팅에 붙이면 채팅 앱은 주소 전체를 저장합니다. 완전한 링크를 가진 사람은 횟수가 끝나기 전에 읽기 페이지를 열어 복호화할 수 있습니다. 일회용 링크가 제한하는 것은 서버 위 암호문의 수명과 횟수이지, 수신자가 캡처하거나 전달하느냐가 아닙니다.

비밀을 오래 보관하고, 여러 기기 사이에 맞추거나, 나중에 반드시 되찾아야 한다면 일회용 링크를 쓰지 말고, 채팅 기록을 금고로 여기지도 마세요. 그것은 비밀번호 관리자의 일입니다. UsePwd는 계정과 비밀번호 보관함을 제공하지 않으며, 횟수가 끝나거나 링크를 잃으면 대신 복구해 주지 않습니다.

비밀이 고가치 마스터 키, 루트 인증서, 자금을 옮길 수 있는 지갑 니모닉이라면 링크도 채팅도 부족합니다. 대면 구술, 오프라인 매체, 또는 이미 양쪽이 세운 종단 간 채널만 쓰세요. 프래그먼트 방식은 이 기기가 이미 장악된 상태, 현재 페이지를 읽는 브라우저 확장, 완전한 주소를 회의실 벽에 띄우는 일을 막지 못합니다.

파일 백업은 다른 경로입니다. 평문 .env를 이 기기에서 먼저 .lock / .enc로 만든 뒤 드라이브에 넣고, 잠금 비밀번호는 파일 자체와 다른 채널로 넘기세요. 두 도구를 같은 약속으로 섞지 마세요. 일회용 링크는 짧은 비밀의 횟수를 다루고, 파일 암호화는 당신이 남겨 두는 암호문 파일을 다룹니다.

이 글의 질문으로 돌아갑니다. 클라우드 환경변수가 유출된 뒤 옛 키는 반드시 폐기해야 하고, 지름길은 없습니다. 새 키를 채팅창에 다시 보내면 안 되는 이유는, 채팅이 기본으로 검색 가능한 평문을 남기고, 로테이션의 의미가 옛 문자열을 즉시 무효로 만드는 데 있기 때문입니다. 같은 분에 더 오래 사는 사본을 또 만들면 안 됩니다. 동료에게 한 번만 넘길 때는 이 기기에서 암호화하고 가입 없이 바로 쓰는 일회용 링크를, 내가 백업을 남길 때는 파일 암호화를 쓰세요. 두 페이지와 이 글은 모두, 상단 바 오른쪽에 언어 전환만 있고 로그인 입구는 없습니다.