노스플랭크 고객 AI 키 무단 사용 보고…비밀값 교체 요청

노스플랭크(Northflank)가 보안 사고 뒤 고객의 AI API 키가 무단으로 사용됐다는 보고를 공개하고, 저장된 비밀값 전체를 교체하도록 요청했다. 회사는 10월 30일 공지에서 키 발급 업체에서 기존 인증 정보를 폐기한 뒤 새 값을 노스플랭크에 반영하도록 안내했다.

10월 31일에는 MySQL·Redis 비밀번호 교체 기능을 모든 고객에게 열었다. 무료 계정에도 감사 로그를 제공한다. 회사는 AI 제공 업체의 사용량·청구 기록도 확인하도록 요청했다.

교체 대상이 들어 있는 환경 변수는 앱 실행에 필요한 설정값을 컨테이너에 전달하는 수단이다. 노스플랭크 공식 문서에 따르면 서비스·작업별로 값을 저장하거나, 여러 실행 자원이 비밀값 그룹을 함께 물려받도록 구성할 수 있다. 같은 이름의 값이 서비스나 작업에 직접 등록돼 있으면 그룹에서 받은 값보다 우선한다. 따라서 그룹과 개별 자원이 각기 다른 키를 사용할 수 있는 구조다.

데이터베이스마다 다른 교체 절차

새로 열린 데이터베이스 교체 기능도 종류에 따라 동작이 다르다. 공식 API 문서는 MySQL의 기본 모드가 이용자용 비밀번호를 바꾸며 사용자 이름은 유지한다고 설명한다. 전체 교체 모드에서는 내부 비밀번호도 바꾸고 데이터베이스를 재시작한다. 두 모드 모두 최종 확정 전까지 이전 비밀번호를 유지한다. Redis는 재시작을 거쳐 한 번에 교체를 끝내고 이전 인증 정보를 폐기한다. 연결된 앱은 새 비밀번호로 다시 접속해야 한다.

교체를 확정하는 별도 API는 진행 중인 교체를 끝내고 기존 인증 정보를 영구 삭제한다. MySQL 기본 모드에서 확정하면 교체 대상 사용자의 연결이 끊기며, 전체 모드는 다시 재시작한다. Redis는 자동으로 끝나므로 이 확정 API를 지원하지 않는다. Redis의 교체 기능에는 데이터 영속화가 필요하고, Sentinel 구성은 복제본이 최소 세 개여야 한다는 조건도 붙어 있다.

비밀값을 저장한 뒤 실행 중인 앱이 새 값을 쓰기까지도 단계가 있다. 공식 비밀값 그룹 안내는 설정 저장만으로 실행 자원이 재시작되지는 않는다고 설명한다. 서비스 재시작이나 새 작업 실행으로 변경한 실행 변수를 적용한다. ‘restart dependents’ 기능은 그룹을 상속받는 서비스와 작업을 새 값으로 다시 배포한다. 그룹은 빌드 시점과 실행 시점, 또는 양쪽 모두에 값을 공급하도록 설정할 수 있어 적용 범위도 함께 정해진다.

대량 교체를 자동화할 때는 API의 갱신 방식이 영향을 준다. 노스플랭크의 현재 API 안내에 따르면 비밀값 변수·실행 환경 변수 같은 묶음을 보내면 전달한 내용이 해당 묶음 전체를 대체한다. 일부 값만 보낸 PATCH 요청도 기존 목록에 항목 하나를 추가하는 식으로 합쳐지지 않는다. 문서는 기존 목록을 읽어 변경분을 합친 뒤 전체를 보내고, 저장 후 키 목록을 다시 대조하는 절차를 제시한다. 문서는 대량 갱신 전에 기존 값을 안전하게 보관하도록 안내한다. 요청에서 생략한 다른 필드는 기존 상태를 유지한다. 지워진 변수는 노스플랭크에서 복원할 수 없다고 명시한다.

감사 로그에는 사건 종류, 실행 사용자, 발생 경로, 시각과 상위 사건이 남는다. 자원 설정이 바뀌면 이전 상태와 새 상태의 차이도 표시한다. 팀·프로젝트·개별 서비스 등 범위를 나눠 볼 수 있으며, 사용자 조작과 시스템 작업, 버전 관리 서비스의 연동으로 발생한 변경을 추적한다. 이번에 무료 계정으로도 열린 로그에서 플랫폼 내부 변경 기록을 볼 수 있고, AI 업체의 사용량·청구 기록에서는 해당 업체가 처리한 호출 내역을 확인하는 방식이다. 날짜·사건 종류·발생 경로를 기준으로 기록을 좁힐 수 있어, 키 교체 전후의 자원 변경을 시간 순서로 살펴볼 수 있다.

보안 업체 위즈(Wiz)는 10월 30일 ‘Black October’ 보고서에서 AI 개발 플랫폼 아홉 곳의 사고를 모았다. 위즈가 분석한 기업 인증 정보 악용 사례 두 건에서는 약 80만 회와 170만 회의 Bedrock 호출이 발생했다. 위즈는 이 둘의 사용량을 정가 기준 10만 달러 이상으로 추정했다. 보고서는 해당 두 건의 플랫폼 이름을 특정하지 않았으며, 실제 청구·지급된 피해액을 제시한 것도 아니다. 여러 사고를 하나의 취약점이나 동일 공격자로 단정할 근거도 공개하지 않았다.