🔐 AWS 접근 키, 지금 당장 버려야 하는 이유 3가지

 

"AWS 쓰면 알아서 안전하지 않나요?"

스타트업 개발자분들 사이에서 가장 많이 듣는 말 중 하나예요. 클라우드를 처음 시작할 때 누구나 이런 생각을 한 번쯤 해봤을 거예요. 하지만 이 착각이 생각보다 훨씬 비싼 대가를 치르게 합니다.

실제로 2025년 기준, 한국에서 데이터 유출 사고 한 건당 평균 비용은 약 488만 달러, 우리 돈으로 65억 원에 달한다는 통계가 나왔어요. 2024년 한 해 동안 국내 사이버 침해사고 신고 건수는 1,887건으로 전년보다 약 48%나 증가했고요. 그리고 이런 사고들의 출발점, 의외로 단순한 데서 시작합니다. 바로 AWS 접근 키(Access Key) 관리 실수입니다.

오늘은 개발자라면 반드시 알아야 할 AWS 보안 핵심 원칙 하나를 아주 쉽게 풀어드릴게요.

호텔 열쇠에 비유하면 딱 이해됩니다

AWS 자격 증명 방식을 호텔 열쇠로 비유해보면 금방 감이 오실 거예요.

오래된 쇠 카드 키를 상상해 보세요. 한 번 만들면 복제가 쉽고, 잃어버려도 자동으로 비활성화되지 않아요. 누군가 주워서 쓰면 그냥 방에 들어올 수 있죠. 반면 스마트폰 기반의 디지털 키는 다릅니다. 인증을 거쳐 임시로 발급되고, 체크아웃하면 자동으로 사라져요.

AWS의 접근 키(Access Key)가 바로 쇠 카드 키입니다. 생성하면 만료가 없고, 두 줄짜리 문자열이라 복사도 너무 쉬워요. 반면 IAM 자격 증명 센터를 통한 임시 자격 증명은 디지털 키예요. 로그인 시 MFA를 거쳐 임시 토큰을 발급받고, 세션이 끝나면 자동 만료됩니다.

위험한 이유 첫 번째: 만료가 없습니다

접근 키는 직접 삭제하거나 비활성화하지 않으면 영구적으로 유효해요. 보안 기업 오르카(Orca)에 따르면 조직의 무려 49%가 민감한 AWS 키를 가상머신 파일 시스템에 그냥 저장하고 있고, 이를 탈취한 공격자는 모든 AWS 리소스에 접근할 수 있다고 해요.

1년 전에 만들어 놓고 잊어버린 접근 키가 오늘도 살아있을 수 있다는 뜻이에요. 팀원이 퇴사했는데 그 직원 키를 삭제하지 않은 경우, 개발 테스트용으로 만들어뒀다가 방치한 경우, 전부 해당됩니다.

위험한 이유 두 번째: 깃허브에 올라가는 순간 끝납니다

개발하다 보면 실수로 접근 키를 코드에 하드코딩하거나 깃허브 저장소에 올리는 경우가 생겨요. 이때가 진짜 문제입니다.

보안 기업 시스디그(Sysdig)가 밝힌 수치가 충격적인데요. 공격자가 클라우드에서 공개된 자격 증명을 찾는 데 걸리는 시간이 2분, 탈취한 자격 증명으로 공격을 시작하기까지 단 21분이면 충분하다고 해요. 사람이 미처 알아채기도 전에 공격자는 이미 내 서버 안에 들어와 있는 거예요.

실수로 슬랙이나 노션에 키를 공유하는 사례, 퇴사자 키를 방치하는 사례도 여기에 해당됩니다. 협업 도구에 자격 증명을 공유하는 순간, 관리 범위를 완전히 잃어버리게 됩니다.

위험한 이유 세 번째: 누가 썼는지 추적이 안 됩니다

AWS CloudTrail에 로그가 남기는 하지만, 접근 키 방식은 키 ID만 기록될 뿐 실제 어떤 사람이 사용했는지 특정하기 어려워요. 내부 직원인지, 외부 공격자인지 판단하는 데 시간이 걸리고, 그 사이 피해는 이미 벌어지고 있습니다.

반면 IAM 자격 증명 센터 방식은 로그에 실제 사용자 정보가 기록돼요. 이상 접근이 발생했을 때 즉각적으로 누가 무엇을 했는지 파악할 수 있다는 게 결정적인 차이입니다.

실제 사고 사례를 보면 더 실감납니다

이론이 아니라 실제 사례가 더 와닿잖아요.

2014년 코드 스페이스(Code Spaces) 사건이 클라우드 보안 역사에서 가장 충격적인 케이스 중 하나예요. 공격자가 루트 계정을 탈취한 뒤 회사의 모든 인프라와 데이터를 그냥 삭제해버렸어요. 회사는 결국 영구 폐업했습니다. 계정 탈취 하나로 기업이 소멸한 거예요.

더 가까운 사례도 있어요. 2025년 초 국내 이슈를 보면, 쿠팡에서 퇴사한 직원이 접근 키를 반납하지 않아 3,370만 명의 고객 정보 유출로 이어진 사례가 있었어요. 퇴사 후에도 접근 키가 살아있었기 때문에 생긴 사고입니다. 최대 1.2조 원의 벌금이 예상될 만큼 결코 작은 문제가 아니에요.

클라우드 보안 사고의 99%는 사용 기업의 실수와 구성 오류에서 비롯된다는 통계가 있어요. AWS가 잘못된 게 아니라, 관리하는 사람이 실수한 경우가 대부분이라는 뜻입니다.

루트 계정, 절대 건드리지 마세요

AWS에서 가장 위험한 계정이 루트 사용자(Root User)예요. 모든 리소스에 접근 가능하고, 계정 자체를 폐쇄할 수도 있는 최고 권한 계정이에요. 호텔 마스터 키 수준이 아니라 건물 전체를 통제하는 키라고 보면 됩니다.

AWS 공식 문서는 루트 계정에 대해 접근 키를 절대 생성하지 말 것을 명시하고 있어요. 처음 계정 생성 시 설정하고 이후엔 완전히 잠가두는 방식이 올바른 운영입니다. 일상 작업에 루트 계정을 쓰는 건 명백한 보안 사고 원인이에요.

그래서 대안은? IAM 자격 증명 센터로 전환하세요

AWS가 공식 권장하는 대안이 IAM 자격 증명 센터(IAM Identity Center)입니다. 운영 방식은 이렇습니다.

AWS 조직 관리 계정으로 사용자와 권한을 중앙에서 관리하고, 로그인마다 MFA를 거쳐 임시 토큰을 발급받아요. 토큰은 세션 종료와 함께 자동 만료되기 때문에, 설령 누군가 이 토큰을 훔쳐도 이미 쓸 수 없는 상태가 됩니다. 처음 설정이 조금 번거롭게 느껴질 수 있지만, 그 한 번이 나중에 생길 수 있는 엄청난 손실을 막아줍니다.

스타트업이 특히 더 조심해야 합니다

스타트업 환경은 개발 속도가 빠르다 보니, 보안 설정을 대충 넘어가는 경우가 많아요. 팀원이 늘어나면서 접근 키를 슬랙이나 노션에 공유하는 것, 퇴사 직원 키를 삭제하지 않는 것, 개발 편의를 위해 루트 계정을 그냥 쓰는 것. 이런 습관들이 쌓이면 어느 순간 반드시 사고로 이어져요.

예방이 사후 처리보다 100배 저렴합니다. 이미 팀이 어느 정도 커진 상황이라면 지금이 정비 타이밍입니다.

지금 당장 콘솔 열어서 확인해 보세요

세 가지만 기억하면 됩니다.

첫째, 접근 키를 새로 만들지 않는다. 둘째, 이미 있는 키는 즉시 비활성화하거나 삭제한다. 셋째, IAM 자격 증명 센터로 전환한다.

보안은 거창한 솔루션이 아니라 올바른 습관에서 시작됩니다. 열쇠를 애초에 만들지 않는다면, 잃어버릴 열쇠도 존재하지 않아요. 지금 AWS 콘솔을 열어서 사용하지 않는 접근 키가 살아있지는 않은지 딱 5분만 확인해 보세요. 그 작은 점검 하나가 서비스 전체를 지키는 첫걸음입니다.