외주 개발사가 클라우드 계정을 망치는 방법: AWS 자격 증명 보안 실수

한줄 요약

외주 개발 후 남겨진 AWS 접근 키 하나가 서비스 전체를 무너뜨릴 수 있다.

본문

AWS 클라우드 보안에서 가장 흔한 취약점은 자격 증명 관리 실수이며, 특히 외주 개발 프로젝트에서 이 문제가 집중적으로 발생한다.

클라이언트가 개발사에 AWS 접근 권한을 넘기는 방식은 생각보다 단순하다. 두 줄짜리 문자열, 즉 Access Key ID와 Secret Access Key를 슬랙이나 이메일로 전달한다. 개발이 끝나면 그걸로 끝이라고 생각한다. 하지만 그 키는 어딘가에 살아있다.

외주 개발 후 AWS 접근 키는 어디에 남는가

개발사가 프로젝트를 진행하는 동안 접근 키는 여러 경로로 퍼진다. 서버 배포 스크립트에 하드코딩되거나, 팀 내부 노션이나 협업 툴에 기록되거나, 최악의 경우 코드 저장소에 그대로 커밋된다.

프로젝트가 끝나도 이 키는 삭제되지 않는다. 만료일도 없다. 개발사 담당자가 퇴사하거나 팀이 바뀌어도 키 자체는 유효하게 남는다. 발주사(클라이언트) 입장에서는 무슨 키가 어디에 퍼져 있는지조차 파악하기 어렵다.

보안 연구들이 일관되게 밝히는 사실이 있다. 코드 저장소에 클라우드 자격 증명이 노출되면 수 분 안에 자동화된 스캐너가 이를 탐지하고 악용을 시도한다. 실제 피해는 대규모 인스턴스 생성, 데이터 탈취, 심각한 경우 서비스 전체 삭제로 이어진다.

접근 키(장기 자격 증명)의 구조적 문제

접근 키는 AWS에서 말하는 '장기 자격 증명'에 해당한다. 한 번 발급되면 별도로 삭제하지 않는 한 영구적으로 작동한다. 문자열 형태이기 때문에 복사와 공유가 극도로 쉽다.

외주 개발 특성상 이 문제는 더 심각하게 작동한다.

• 프리랜서 여러 명이 하나의 키를 공유한다
• 누가 언제 어디서 접속했는지 사후에 구분하기 어렵다
• 개발 완료 후 키 회수 및 삭제 절차가 없다
• 클라이언트가 키 유출 여부를 인지할 방법이 없다

CloudTrail 같은 로그 서비스가 있어도 키 ID만 기록될 뿐, 실제로 누가 접속했는지는 특정할 수 없다. 외주 개발사인지, 외부 공격자인지 로그만으로 구분이 불가능한 구조다.

단기 자격 증명으로 전환하면 무엇이 달라지나

AWS IAM Identity Center를 활용한 임시 자격 증명 방식은 구조 자체가 다르다.

중앙에서 사용자를 발급하고, 로그인 시 다단계 인증(MFA)을 거친 뒤 임시 토큰을 발급한다. 이 토큰은 설정된 시간이 지나면 자동으로 만료된다. 누가 어느 계정에서 어떤 작업을 했는지 사용자 단위로 추적이 가능하다.

외주 개발에 이 방식을 적용하면 실질적인 변화가 생긴다.

• 개발사 담당자에게 계정 단위 임시 접근 권한을 부여하고 프로젝트 종료 시 즉시 회수한다
• 자격 증명이 유출되어도 만료 시간이 지나면 무력화된다
• 누가 무엇을 했는지 사람 단위로 감사(Audit)가 가능하다
• 루트 계정 자체에 대한 접근을 원천적으로 차단하고 관리할 수 있다

IT 에이전시가 보안 구조를 함께 설계해야 하는 이유

클라이언트 대부분은 AWS 보안 구조를 알지 못한다. 아는 것이 당연하지도 않다. 그래서 외주 개발을 맡기는 것이다.

문제는 많은 개발사도 보안 구조 설계 없이 기능 개발에만 집중한다는 점이다. IAM 사용자 생성, 접근 키 발급, 배포 완료. 이 흐름이 관행처럼 굳어있다.

결과적으로 클라이언트는 서비스를 넘겨받지만, 보안 위협이 잠재된 구조를 함께 넘겨받는다. 그 위협이 현실화되면 책임 소재는 불분명하고, 피해는 클라이언트가 고스란히 진다.

신뢰할 수 있는 IT 에이전시라면 기능 개발과 함께 아래 사항을 기본으로 다뤄야 한다.

• 루트 계정 접근 키를 생성하지 않는다
• 개발 목적의 임시 IAM 계정을 사용하고 프로젝트 종료 후 삭제한다
• 배포 환경에서 하드코딩된 자격 증명을 허용하지 않는다
• CloudTrail 로그를 장기 보관 가능한 구조로 설정한다
• 납품 전 불필요한 IAM 사용자와 접근 키 정리를 확인한다

보안은 완성된 서비스에 덧붙이는 옵션이 아니다. 개발 구조 안에 처음부터 포함되어야 한다.