한줄 요약
외주 개발사가 연동한 OAuth 앱 하나로 고객의 환경 변수 전체가 노출될 수 있다.
본문
OAuth 공급망 공격은 외부 서드파티 애플리케이션에 부여된 접근 권한을 탈취해 그 권한이 연결된 내부 시스템까지 침투하는 방식의 사이버 공격이다. 최근 글로벌 배포 플랫폼에서 발생한 실제 침해 사고는 이 공격 방식이 얼마나 조용하고, 빠르고, 넓게 퍼질 수 있는지를 명확하게 보여줬다. IT 개발 에이전시 입장에서 이 사건은 남의 일이 아니다.
에이전시가 OAuth를 위험하게 다루는 이유는?
개발 에이전시는 프로젝트마다 수십 개의 외부 툴과 연동한다. 분석 툴, 협업 플랫폼, CI/CD 도구, AI API, 모니터링 서비스까지. 이 연동 대부분이 OAuth 기반이다.
문제는 OAuth 토큰의 특성에 있다. 한 번 발급된 OAuth 토큰은 비밀번호를 바꿔도 무효화되지 않는다. 접근 범위(scope)는 처음 설정된 채로 유지된다. 로그인 이력도 남지 않는 경우가 많다. 개발팀이 온보딩 때 연결하고 잊어버린 그 앱이, 수개월 뒤에도 여전히 내부 시스템에 접근 권한을 가지고 있다는 뜻이다.
에이전시 환경에서 더 위험한 건 권한의 '이전성'이다. 에이전시 계정에 연결된 OAuth 앱이 침해되면, 그 앱을 신뢰하는 모든 클라이언트 프로젝트로 피해가 번진다. 침해된 건 에이전시인데 피해는 고객이 입는 구조다.
환경 변수는 왜 공격자의 최종 목표가 되나?
배포 플랫폼에 올라간 프로젝트에는 거의 예외 없이 환경 변수가 존재한다. DB 접속 정보, 결제 API 키, AI 서비스 토큰, 이메일 발송 자격증명. 민감하다고 표시하지 않은 변수는 내부 접근 권한만 있으면 평문으로 읽힌다.
공격자 입장에서 환경 변수는 이상적인 전리품이다. 한 프로젝트의 환경 변수에서 얻은 API 키 하나로 해당 서비스 전체를 제어할 수 있고, 이를 악용하면 과금 폭탄부터 데이터 유출까지 연쇄 피해가 발생한다. 실제 침해 사례에서도 배포 플랫폼 내부 접근에 성공한 공격자가 고객 프로젝트의 환경 변수를 열람하고, 그 안에 담긴 서드파티 API 키가 며칠 뒤 외부에서 사용된 것이 감지됐다.
더 심각한 문제는 감지 시점이다. API 키가 외부에서 사용됐다는 알림을 서드파티 서비스(예: 결제사, AI API 제공사)로부터 받은 시점이, 플랫폼이 공식 공지를 낸 시점보다 며칠 먼저였다는 패턴이 반복된다. 고객이 공식 통보보다 먼저 피해 신호를 받는 상황은 에이전시 입장에서 가장 난감한 시나리오다.
에이전시가 당장 바꿔야 할 구조적 관행 3가지
1. OAuth 앱을 외부 벤더로 취급하라
내부 팀원이 사용하는 툴이라도, 그 툴이 OAuth로 연동된 순간 '외부 벤더'와 동일한 보안 기준을 적용해야 한다. 분기마다 연동된 OAuth 앱 목록을 감사하고, 더 이상 사용하지 않는 앱의 권한은 즉시 철회한다. 이 작업을 프로젝트 종료 체크리스트에 포함시키는 것이 가장 현실적이다.
2. 환경 변수의 민감도를 명시적으로 분류하라
배포 플랫폼에 올리는 모든 환경 변수에 대해 "이게 노출되면 어떤 피해가 발생하는가"를 기준으로 민감/비민감을 명시적으로 분류한다. 민감 변수는 플랫폼의 암호화 저장 옵션을 반드시 활성화하고, 접근 가능한 팀원 범위를 최소화한다. 분류 자체를 안 하는 것이 가장 흔한 실수다.
3. 장기 자격증명을 단기 토큰으로 교체하라
API 키나 서비스 계정 토큰처럼 만료 없이 사용하는 장기 자격증명은 탈취되면 그 피해가 무기한 이어진다. 가능한 한 단기 발급·자동 갱신 방식의 자격증명 체계로 전환하고, 주요 API 키의 유효 기간을 설정한다. 클라우드 환경이라면 IAM 역할 기반의 임시 자격증명을 활용하는 것이 모범 사례다.
