25분 만에 관리자 권한이 털린 이유, 매장 보안 3단계로 막는 법

• 핵심: 도입 검토 25분 만에 관리자 토큰이 발견된 사건의 흐름 정리
• 비용: 오래된 키 하나가 제품 저장소 전체를 여는 구조라는 점
• 적용: 외주 계정과 비밀번호를 점검하는 매장 보안 3단계부터 시작

외주 개발자에게 서버 비밀번호를 통째로 넘기신 적 있으신가요

홈페이지나 예약 앱을 외주로 맡기면서 관리자 계정을 그대로 건넨 경험이 있으실 겁니다. 일이 끝나도 비밀번호를 바꾸지 않는 경우가 많습니다. AI 추론업체를 검토하던 보안팀이 겪은 일이 바로 그 연장선입니다. 도입을 앞두고 상대의 보안을 먼저 점검했는데 약 25분 만에 내부 저장소의 관리자 권한을 가진 토큰이 나왔습니다[1]. 자격도 없이, 내부 자료도 없이 찾은 결과입니다. 남의 회사 이야기 같지만 구조는 우리 가게와 같습니다. 오래된 비밀번호 하나가 금고 전체를 여는 열쇠가 됩니다.

핵심 변화 3가지

사건의 뼈대는 세 가지로 정리됩니다.

구분	이번 사건	우리 가게 교훈
열린 문	컨테이너 창고 프로젝트 하나가 공개 상태로 방치됨	쓰지 않는 계정과 공유 링크를 닫기
박힌 키	빌드 기록에 토큰 값이 그대로 남음	외주 때 준 비밀번호는 작업 뒤 바로 교체
큰 권한	읽기만 하면 될 키에 관리자와 쓰기 권한이 부여됨	필요 최소 권한만 주고 기한 정하기

점검은 인증 없이 시작됐습니다. 인증서 기록을 뒤져 가며 표면을 살피다 Harbor 컨테이너 창고 하나를 찾았습니다[1]. 프로젝트 하나가 공개라서 로그인 없이 목록을 보고 이미지를 내려받을 수 있었습니다[1]. 이미지 이름은 baseten/baseten-app이었습니다[1]. 처음 나온 단서는 AWS 키 한 쌍이었지만 읽기전용 확인 결과 이미 죽은 키였습니다[1]. 여기서 멈추지 않고 층을 더 뒤지다 이미지 설정의 history[].created_by 항목에서 GitHub 토큰을 찾았습니다[2]. 빌드 인자로 넘긴 GITHUB_TOKEN 값이 RUN 명령어에 그대로 펼쳐져 박혀 있었습니다[1]. 읽기전용 요청으로 확인하니 계정은 basetenbot이었습니다[1]. 권한 범위는 repo였고 소속은 basetenlabs였습니다[1]. 주력 제품과 GitOps 저장소, Homebrew 저장소에 관리자와 푸시 권한이 있었고 다른 비공개 저장소에도 읽기 쓰기가 가능했습니다[1]. 토큰이 든 빌드는 2023년 3월 3일에 만들어졌는데 2026년 7월에도 유효했습니다[1].

깊이 분석: 토큰이 새는 두 갈래 길

겉으로는 AI가 25분 만에 털었다는 이야기로 보입니다. 구조를 뜯어보면 새는 길은 두 갈래입니다.

빌드 기록에 박힌 토큰

첫 번째 길은 빌드 과정입니다. 개인 저장소의 부속을 가져오려 토큰을 빌드 인자로 넘겼습니다[1]. 관련 패턴은 ARG GITHUB_TOKEN 뒤에 git config --global로 인증 주소를 박는 방식이었습니다[1]. 이러면 이미지에 두 벌의 흔적이 남습니다. 빌드 기록의 명령어에 토큰 값이 남고, 깃 설정 파일에도 인증 주소가 남습니다[2]. 도커는 빌드 인자가 이미지 정보에 남을 수 있다고 문서로 경고합니다[1]. 고치는 법은 비밀 마운트로 빌드 때만 쓰고 이미지에 남기지 않는 것입니다[1]. 이미 받은 쪽이 있을 수 있으니 오래된 토큰은 먼저 폐기해야 합니다[1]. 층을 살피는 도구는 트러플호그가 대표적이며 깃릭스도 함께 쓰입니다[2]. 매장 비유로 바꾸면 공사 때 맡긴 열쇠를 회수하지 않은 꼴입니다.

공개로 열린 창고 문

두 번째 길은 창고 공개 설정입니다. Harbor는 이미지를 모아두는 창고이고 프로젝트 단위로 공개 여부를 정합니다[1]. 하나가 공개라서 익명으로도 목록과 받아가기가 가능했습니다[1]. 오래된 꼬리표까지 그대로 있었습니다[1]. 고객정보를 다루는 매장이라면 매장 CCTV 100회 추적 논란으로 배우는 고객정보 보호 3원칙에서 정리한 보관과 접근 기준을 함께 보면 맥락이 이어집니다. 신고 뒤 대응은 빨랐습니다. 7월 13일 23시 10분에 신고가 접수됐고 다음 날 오전에 창고가 비공개로 바뀌었습니다[1]. 같은 날 오후에 심각한 문제로 확정되고 토큰이 교체됐습니다[1]. 7월 17일에 남은 조치가 끝났습니다[1]. 원문엔 없지만 우리 가게 적용을 위해 추가 확인한 창고 권한 논의와 릴리스 권한 사례까지 함께 봅니다[4][5]. 창고 쪽에서는 작업 흐름 토큰을 기본 읽기전용으로 두자는 논의가 이어지고 있습니다[4]. 릴리스 흐름에서는 외부 동작을 고정 주소로 묶고 토큰을 최소 권한으로 두는 사례가 공유되고 있습니다[5].

우리 가게·업장에 어떻게 적용할까

분식집을 운영하는 사장님의 경우를 예로 들겠습니다 (가상 예시). 배달앱 메뉴판 사진을 바꿀 때마다 사장님이 직접 가게 태블릿으로 로그인해 외주 디자이너에게 화면을 보여주며 고쳤습니다. 어느 날 디자이너가 바빠서 아이디와 비밀번호를 통째로 넘겼고, 작업이 끝난 뒤에도 바꾸지 않았습니다. 1년이 지나 그 디자이너의 옛 직원이 같은 비밀번호로 포스 앱에 들어올 수 있는 상태가 됐다면 어떨까요. 실제로는 아무 일도 없었을 수 있습니다. 그러나 구조는 이번 사건과 같습니다. 오래된 열쇠가 살아 있고, 그 열쇠가 금고까지 열 수 있는 상태입니다. 적용 순서는 세 단계입니다. 첫째, 외주 때 준 계정은 작업이 끝나면 당일에 비밀번호를 바꿉니다. 둘째, 관리자 권한은 사장님 본인만 갖고 외주에는 필요한 메뉴만 여는 권한을 줍니다. 셋째, 6개월에 한 번은 쓰지 않는 계정과 공유 링크를 정리합니다. 포스 앱과 예약 앱, 배달 가게 페이지의 로그인 기록을 함께 보면 됩니다. 비용은 들지 않습니다. 시간은 30분이면 충분합니다.

세 가지 정리와 오늘 할 일 1개

• 오래된 키가 가장 위험합니다. 2023년 빌드의 토큰이 2026년 7월까지 살아 있었습니다[1].
• 권한은 작게 줍니다. 읽기로 될 일에 관리자를 주면 새는 순간 피해가 커집니다[1].
• 창고 문을 닫습니다. 공개로 둔 프로젝트와 오래된 이미지를 먼저 봅니다[1][4].

오늘 할 일: 외주 때 준 비밀번호 1개를 지금 바꾸고 관리자 권한 목록을 확인하세요.

함께 보면 좋은 글

• 소상공인 AI 거버넌스 3원칙으로 매장 고객 데이터 유출 막는 법
• 생성형 AI 저작권 2025~2026: 사장님이 알아야 할 규제와 활용법

참고 자료

• [1] We wanted to use Baseten for inference. We ended up with admin access to their GitHub, Strix Blog (https://www.strix.ai/blog/baseten-harbor-github-pat-takeover)
• [2] An AI Agent Found Admin Access to a 13B Startup in 25 Minutes, DEV Community (https://dev.to/jamilxt/an-ai-agent-found-admin-access-to-a-13b-startup-in-25-minutes-heres-the-free-tool-it-used-and-337a)
• [3] We got admin access to Baseten production GitHub in 25 minutes, Hacker News (https://news.ycombinator.com/item?id=49716476)
• [4] Set Workflow Token Permissions to Read-Only by Default, Harbor Issues (https://github.com/goharbor/harbor/issues/22760)
• [5] Pin release-workflow actions to commit SHAs and least-privilege token, Strix Pull Requests (https://github.com/usestrix/strix/pull/862)