월말에 날아온 클라우드 청구서가 평소의 몇십 배로 찍혀 있습니다. 사용 내역을 열어 보면 우리 회사가 쓴 적 없는 AI 호출과 문자 발송이 새벽 시간대에 몰려 있습니다. 원인을 따라가 보면 대단한 해킹보다는, 외주 개발 때 코드에 적어 둔 API 키 한 줄이 공개 저장소나 앱 설치 파일에 그대로 남아 있던 경우가 대부분입니다.
이 글에서 확인할 것
- 회사가 가진 API 키를 위험도에 따라 세 종류로 나누는 기준
- 청구서가 터지기 전에 걸어 둘 여섯 가지 설정
- 유출이 의심될 때 한 시간 안에 할 일의 순서
API 키는 세 종류로 나눠 관리한다
첫째는 돈이 나가는 키입니다. AI 서비스, 지도, 문자 발송, 클라우드 서버처럼 호출할 때마다 요금이 쌓이는 서비스의 키가 여기 속합니다. 이 키가 새면 피해가 곧바로 청구서로 옵니다. 누군가 우리 키로 대량 호출을 돌려도 서비스 회사 입장에서는 정상 사용과 구분하기 어렵습니다.
둘째는 데이터에 닿는 키입니다. 데이터베이스 접속 정보, 결제대행사의 비밀 키, 관리자 권한 토큰, 쇼핑몰 주문 조회 키가 이 묶음입니다. 요금은 안 나와도 고객 정보가 빠져나가거나 주문 내역이 조작될 수 있어 사고의 무게가 더 큽니다.
셋째는 공개를 전제로 만든 키입니다. 웹페이지에 지도를 띄우거나 앱에서 로그인 창을 여는 데 쓰는 키는 어차피 이용자 기기로 내려갑니다. 숨길 수 없는 대신 어느 도메인, 어느 앱에서만 쓰이게 묶어 두는 제한이 반드시 걸려 있어야 합니다. 제한 없이 공개된 키는 첫째 묶음과 똑같이 위험합니다.
키가 새는 흔한 경로
가장 흔한 자리는 코드 저장소입니다. 개발자가 테스트하느라 키를 코드에 직접 적고 저장소에 올린 뒤, 나중에 지웠다고 해도 변경 이력에는 그대로 남습니다. 저장소가 한 번이라도 공개 상태였다면 이미 자동 수집 프로그램이 긁어 갔다고 보는 편이 안전합니다.
두 번째는 앱 설치 파일과 웹페이지 소스입니다. 앱 안에 돈이 나가는 키를 넣어 두면 설치 파일을 풀어 누구나 꺼낼 수 있습니다. 웹페이지도 브라우저에서 소스 보기만 누르면 자바스크립트 안의 키가 보입니다. 비용이 붙는 호출은 반드시 회사 서버를 거치게 만들어야 하는 이유입니다.
세 번째는 사람을 거친 경로입니다. 메신저 단체방에 키를 붙여 넣어 전달하거나, 메일로 설정 파일을 주고받거나, 퇴사한 개발자의 개인 노트북에 키가 남아 있는 경우입니다. 오류가 났을 때 화면에 설정값이 통째로 찍히는 페이지도 실제 현장에서 자주 발견됩니다.
요금 폭탄을 막는 여섯 가지 설정
아래 여섯 가지는 대부분의 AI, 지도, 클라우드 서비스 관리 화면에 비슷한 이름으로 들어 있습니다. 메뉴 위치는 서비스마다 다르니 결제나 보안, 사용량 항목부터 찾아보면 됩니다.
| 설정 | 찾는 곳 | 막아 주는 것 | 자주 놓치는 점 |
|---|---|---|---|
| 월 사용 한도 | 결제·사용량 메뉴 | 한 달 청구 금액 상한 | 한도를 넘으면 서비스가 멈추므로 여유 있게 잡기 |
| 사용량 알림 | 결제 알림·예산 메뉴 | 평소보다 빠르게 쌓이는 호출 | 알림 메일이 퇴사자 주소로 가 있는 경우 |
| 호출 출처 제한 | 키 상세 설정 | 다른 도메인·앱·IP에서의 사용 | 테스트 때 풀어 둔 제한을 운영에서 그대로 둠 |
| 권한 범위 축소 | 키 생성 화면의 권한 선택 | 한 키로 모든 기능을 쓰는 상황 | 편하다고 관리자 권한 키 하나로 통일 |
| 개발용·운영용 분리 | 프로젝트 또는 환경 구분 | 테스트 코드 유출이 운영 사고로 번지는 것 | 외주사가 운영 키로 개발을 진행 |
| 정기 교체와 폐기 | 키 목록 화면 | 오래전에 샌 키의 재사용 | 안 쓰는 키를 지우지 않고 쌓아 둠 |
여섯 가지 중 당장 하나만 한다면 월 사용 한도입니다. 키가 새더라도 피해 금액의 천장이 생기기 때문입니다. 그다음은 호출 출처 제한으로, 이것이 걸려 있으면 키 문자열을 가져가도 다른 곳에서는 쓸 수 없습니다. 권한 축소와 개발용 분리는 외주 개발이 시작되기 전에 정해 두어야 나중에 고치는 품이 들지 않습니다.
유출이 의심될 때 할 일의 순서
먼저 해당 키를 폐기하고 새 키를 발급합니다. 코드를 고치거나 저장소 기록을 지우는 일보다 이것이 앞입니다. 키가 살아 있는 동안에는 몇 분마다 요금이 쌓이고, 폐기하는 순간 피해가 멈춥니다. 서비스가 잠시 끊기는 것은 감수하는 편이 낫습니다.
그다음 새 키를 회사 서버의 설정 파일이나 비밀값 저장 기능에만 넣고, 코드와 앱에는 넣지 않습니다. 이때 누가 새 키를 볼 수 있는지 명단을 적어 둡니다. 보는 사람이 적을수록 다음 사고의 확률도 줄어듭니다.
세 번째로 사용 내역 화면을 내려받아 보관합니다. 비정상 호출이 시작된 시각, 호출 출처, 늘어난 금액이 찍힌 화면이 있어야 서비스 회사 고객센터에 청구 조정을 문의할 수 있습니다. 조정 여부와 기준은 회사마다 다르므로 문의하면서 필요한 자료를 그쪽 안내대로 맞춰 냅니다.
마지막으로 새어 나간 경로를 막습니다. 저장소를 비공개로 돌리고, 앱이라면 키를 서버 호출 방식으로 바꾼 새 버전을 배포하고, 메신저에 붙여 넣은 기록을 정리합니다. 경로를 막지 않으면 새 키도 같은 자리에서 다시 샙니다.
외주 개발을 맡길 때 정해 둘 것
키는 처음부터 회사 계정으로 발급받아야 합니다. 개발자 개인 계정으로 만든 키는 계약이 끝나면 회사가 관리 화면에 들어갈 방법이 없고, 요금 알림도 회사로 오지 않습니다. 결제 카드 역시 회사 명의로 등록해 두어야 청구 내역을 회사가 직접 볼 수 있습니다.
계약서에는 사용한 외부 서비스 목록과 키 보관 위치를 인수인계 항목으로 넣어 둡니다. 외주 앱개발 업체와 일을 시작할 때 이 목록을 먼저 요구하면, 앱 안에 비용이 붙는 키를 넣지 않는 설계로 가는지도 초기에 확인할 수 있습니다. 홈페이지나 관리자 화면을 함께 맡긴다면 웹개발 범위에서 오류 화면에 설정값이 노출되지 않는지, 관리자 페이지 주소가 막혀 있는지도 검수 항목에 넣습니다.
사내 시스템이 문자, 결제, 택배 조회처럼 외부 서비스를 여러 개 물고 있다면 키가 시스템마다 흩어지기 쉽습니다. ERP와 외부 서비스를 잇는 연동 개발을 할 때 키를 한곳에서 보관하고 교체하는 구조로 잡아 두면, 담당자가 바뀌어도 어떤 키가 어디서 쓰이는지 한 화면에서 확인됩니다.
점검 목록과 정리
아래 일곱 줄에 예와 아니오로 답해 봅니다. 아니오가 하나라도 첫째 묶음, 즉 돈이 나가는 키와 관련돼 있다면 이번 주 안에 손보는 편이 좋습니다.
- 회사가 쓰는 API 키 목록과 담당자를 한 장으로 적어 두었는가
- 돈이 나가는 서비스마다 월 사용 한도가 걸려 있는가
- 사용량 알림이 지금 근무하는 사람의 메일로 가는가
- 공개용 키에 도메인이나 앱 제한이 걸려 있는가
- 앱 설치 파일과 웹페이지 소스에 비용이 붙는 키가 들어 있지 않은가
- 외주 개발자가 개인 계정이 아닌 회사 계정의 키를 쓰는가
- 안 쓰는 키와 퇴사자가 만든 키를 폐기했는가
API 키 관리는 보안 장비를 사는 일이 아니라 관리 화면에서 설정 몇 개를 켜는 일입니다. 한도와 알림이 먼저, 출처 제한이 그다음, 목록과 교체 습관이 마지막입니다. 이 셋이 자리를 잡으면 키 한 줄이 새더라도 청구서가 회사를 흔드는 일은 막을 수 있습니다.
키가 새는 것은 막기 어렵지만, 샌 키가 쓸 수 있는 금액과 장소는 오늘 바로 묶어 둘 수 있습니다.
