흠뻑 젖은 채로 리조트 방 앞에 서서야 깨달았습니다. “아, 방에서 키 안 가지고 나왔다….” 수영장에 다녀오며 카드키를 방에서 안 가지고 나왔던 겁니다. 결국 수영복 차림으로 떨며, 멀리 떨어진 프론트 데스크까지 걸어가서 새 키를 받으러 갔습니다. 지난 겨울 휴가 때 제 이야기입니다.

호텔이나 리조트에 놀러 다니다 보면 쉽게 이런 상황을 마주하기도 합니다. 평소 결제와 신분증 확인을 모두 휴대폰으로 해결하다 보니, 지갑 없이 폰 하나로 다니는 데 익숙하기 때문입니다. 호텔 카드키를 따로 챙기는 일은 꽤 번거롭게 느껴졌고, 때로는 방에 두고 나오거나 심지어 밖에서 잃어버리고 오는 일도 있었습니다.

밖에서 놀다가 호텔 키를 잃어버리면 어떻게 될까요? 카드키를 받을 때는 호텔 측에서 작은 종이 케이스에 방 번호를 적어 주기도 하는데요, 이 경우 누구나 제 호텔 방에 들어올 수 있게 됩니다. 만약 그 열쇠를 잃어버린 사실조차 모른 채 방을 방치해 둔다면 어떨까요? 방에 있던 짐은 그대로 도난당하고, 파손된 가구나 전자제품에 대해 호텔 측에 변상해야 할 수도 있습니다.

그런데 만약 잃어버린 것이 호텔 키가 아니라 개인이나 회사의 클라우드 인프라 열쇠였다면 어떨까요? 마찬가지로 누군가 내 클라우드 계정에 접근해 고객들의 개인정보를 탈취하고, 심지어 서비스까지 중단시킬 수도 있습니다. 실제로 2014년, 한 기업은 클라우드 열쇠를 탈취당해 모든 데이터와 백업이 삭제되었고, 회사는 영구 폐업했다고 합니다.

위시켓 클라우드팀에서 업무상 수많은 AWS 계정을 관리하는 제게, 이러한 사건은 남의 이야기가 아닙니다. 그런 경험을 바탕으로 클라우드 보안에서 가장 흔하면서도 가장 위험한 실수 하나에 관해 설명해 보려고 합니다.

클라우드의 두 가지 자격 증명

요즘 메리어트나 IHG 같은 호텔 체인에서는 모바일 키를 지원합니다. 이런 모바일 키가 있었다면 카드키를 두고 나와도 당황하는 일은 없었을 것입니다. 또, 카드키를 잃어버리더라도 제 얼굴 인증 없이는 모바일 키를 사용할 수 없을 겁니다. (실제로 메리어트 본보이 앱은 모바일 카드키 사용 시 페이스 아이디를 요구합니다.)

클라우드에서도 이처럼 전통적인 키와 모바일 키처럼 두 가지 인증 방식이 존재합니다.

첫 번째 증명: 카드 키 방식

우리는 호텔에 도착하면 보통 프론트 데스크에서 카드키를 받습니다. 서울의 호텔, 도쿄의 호텔, 뉴욕의 호텔 모두 호텔마다 프론트에서 각각 다른 카드키를 받아야 합니다. 만약 잃어버린다면 어떨까요? 누군가 주워 제 방에 들어갈 수도 있습니다.

AWS의 인증 열쇠를 잃어버리면, 호텔 열쇠와는 비교할 수 없을 만큼 심각한 문제가 발생할 수 있습니다. 특히, 호텔의 카드키는 최소한 체크아웃 날짜가 지나면 만료됩니다. (그래서 일부 호텔에서는 카드키를 기념으로 가져가게 해주기도 합니다.) 반면 AWS의 장기 자격 증명인 IAM 접근 키는 마치 쇠로 된 열쇠와 같습니다. 누군가 직접 문에 달린 자물쇠를 바꾸지 않는 한 꾸준히 작동합니다. 게다가 쇠 열쇠보다 복제하기도 쉽습니다. 두 줄의 문자열을 복사해 붙여넣기만 하면 되기 때문입니다.

두 번째 증명: 모바일 키 방식

반면 모바일 키는 조금 다릅니다. 예를 들어 메리어트 호텔의 모바일 키는 본사에서 중앙 관리됩니다. 하나의 메리어트 계정만 있으면 호텔 지점과 관계없이 어디서든 체크인하고 모바일 키로 객실 문을 열 수 있도록요. 심지어 동시에 예약한 호텔이 두 곳이라면, 하나의 휴대폰으로 두 객실을 모두 열 수도 있습니다. 또, 제 휴대폰이기 때문에 얼굴과 같은 생체 정보 없이는 사용할 수 없습니다. 여기에 체크아웃 이후에는 별도의 관리가 필요하지 않습니다.

AWS에서도 마찬가지입니다. 저는 하루에도 여러 번 AWS 계정을 오가며 작업하는데, 로그인할 때마다 각 계정의 아이디와 비밀번호를 모두 알아야 한다면 매우 번거로운 일이 될 것입니다. 그래서 모바일 키 방식을 적극 사용합니다.

장기 기억 증명 vs. 단기 자격 증명

AWS에서는 이 두 가지를 다음과 같이 구분합니다. 카드키, 마치 호텔의 쇠 열쇠 같은 방식은 장기 자격 증명(long-term credential)이라고 부릅니다. 반면 모바일 키와 같은 방식은 단기 자격 증명(short-term credential)이라고 합니다. 한 번 만들어지면 열쇠구멍이 바뀌지 않는 한 쓸 수 있는 쇠 열쇠와 달리, 모바일 키는 사용할 때마다 제 생체 인증이 필요하기 때문입니다.

장기 자격 증명의 대표적인 예는 AWS IAM(Identity and Access Management)의 접근 키(Access Key)입니다. 이 접근 키는 두 줄의 문자열로 이루어져 있습니다. 한 번 생성되면 그 자체로는 만료되지 않는 특징도 가집니다. 또한 문자열 형태이기 때문에 누구에게나 복사해 전달할 수 있습니다. 카카오톡으로 주고받거나, 코드에 들어간 채 클라우드나 깃허브와 같은 원격 저장소에 업로드될 수도 있습니다. 이처럼 발급된 키를 삭제하려면 해당 계정에서 직접 삭제해야 합니다. 호텔마다 프론트 데스크에서 카드키를 따로 발급하듯, 각 AWS 계정에서 개별적으로 생성하고 관리합니다.

반면 단기 자격 증명은 IAM 자격 증명 센터(IAM Identity Center)를 통해 발급됩니다. 호텔 체인 본사가 앱을 통해 키를 관리하듯, AWS 조직(AWS Organization, 여러 계정을 하나로 묶어 관리하는 단위)의 관리 계정에서 중앙으로 관리됩니다. 하나의 사용자로 여러 AWS 계정에 접근할 수 있다는 점도 특징입니다. 로그인할 때는 다단계 인증(Multi-Factor Authentication, MFA)을 거쳐야 하며, 인증이 완료되면 임시 토큰이 발급됩니다. 이 토큰은 사전에 설정된 일정 시간이 지나면 만료되고, 로그인할 때마다 새로 발급됩니다. 만료 이후에는 별도로 신경 쓸 필요가 없습니다. 알아서 사라지니까요.

AWS 접근 키를 잃어버리면, 어떤 사고가 날까요?

AWS 접근 키를 잃어버리면 어떻게 될까요?

이 열쇠에는 만료일이 없고, 복제도 매우 쉽습니다. 사실 키 값이 그리 길지도 않아 마음만 먹으면 외울 수도 있는 수준입니다. 누가 복사했는지, 복사본이 몇 개나 존재하는지도 알 수 없습니다. 누군가 자물쇠를 바꾸기 전까지 그 열쇠의 복사본을 가진 누구든 언제든 문을 열 수 있습니다.

키 유출이 악용으로 이어진 시간

이에 대한 실험이 있습니다. 보안 연구팀 Comparitech는 AWS 자격 증명을 공개 깃허브 리포지토리에 일부러 올려두었습니다. 결과는 충격적이었습니다. 첫 번째 악용이 1분 이내에 발생했습니다. 1분입니다. 음료수 한 모금 마시기도 전에, 누군가 그 열쇠로 문을 열고 들어온 셈입니다.

이건 우연이 아닙니다. 팔로알토 네트워크의 Unit 42 팀이 추적한 EleKtra-Leak 캠페인에 따르면, 공격자들은 깃허브에 노출된 AWS 자격 증명을 자동으로 스캔하고 있었습니다. 키가 노출되면 평균 5분 이내에 악용이 시작됐고, 탈취한 키로 수백 대의 EC2 인스턴스를 생성해 암호화폐를 채굴했습니다. 이 캠페인은 2020년부터 최소 3년간 지속되었습니다.

우버 역시 비슷한 사례를 겪었습니다. 2013년에 생성된 다음, 한 번도 교체되지 않은 접근 키가 깃허브 리포지토리에서 발견됐고, 곧바로 5,700만 건의 고객 데이터가 유출되었습니다. 이어 1억 4,800만 달러의 벌금이 부과되었고, 보안 책임자(CISO)는 형사 유죄 판결을 받았습니다.

키 유출을 알아챌 때까지 걸리는 시간

그렇다면 규모는 어느 정도일까요? 깃가디언의 2025년 보고서에 따르면, 2024년 한 해 동안 공개 깃허브에서 유출된 암호 키는 2,380만 개에 달합니다. 이는 전년 대비 25% 증가한 수치입니다. 더 무서운 점은, 2022년에 유출된 키의 70%가 2025년에도 여전히 유효하다는 사실입니다.

그러니까 이들은 열쇠가 탈취되었는데도 자물쇠를 바꾸지 않은 것입니다. 무려 3년 동안이나요.

왜 바꾸지 않았을까요? 정확히는, 바꾸지 못했을 겁니다. 유출 사실을 몰라 바꾸지 않았을 수도 있고, 혹은 그 과정에서 기존에 정상적으로 작동하던 서비스에 영향을 줄까 걱정했을 수도 있습니다. 호텔에 비유하면, 객실 문고리를 전부 교체하는 바람에 기존 열쇠를 가진 직원들이 객실 청소를 못하게 되는 상황과 비슷합니다.

그렇다면 모바일 키, 즉 단기 자격 증명이 유출된다면 어떨까요? 애초에 임시 토큰은 복사나 공유를 전제로 만들어진 값이 아닙니다. 또한 다단계 인증을 거쳐 발급되기 때문에 이를 굳이 복사해 전달할 상황 자체가 많지 않습니다. 즉, 유출 경로 자체가 상대적으로 적습니다. 설령 유출되더라도 이 키는 수 시간 내에 자동으로 만료됩니다. 체크아웃 이후의 키카드처럼, 만료된 토큰은 의미 없는 문자열에 불과합니다.

그래도 감시 카메라(CloudTrail)가 있지 않나요?

호텔에 CCTV가 있듯, AWS에는 클라우드트레일(CloudTrail)이라는 서비스가 있습니다. 누가 언제 어떤 작업을 했는지, 모든 API 호출을 기록하는 서비스입니다. 장기 자격 증명이든 단기 자격 증명이든, 예외 없이 모두 기록됩니다.

문제는 기록이 남는 것과 범인을 특정하는 것은 별개의 문제라는 점입니다. 모바일 키 방식, 즉 IAM 자격 증명 센터를 통한 접근은 기록이 비교적 명확합니다. “김승빈이 오후 2시 13분에 서울 호텔 503호에 들어갔다”처럼, 사용자 누구가 무슨 계정에서 어떤 작업을 했는지 신원을 특정할 수 있습니다.

반면 접근 키를 사용하면 기록에는 키 ID만 남습니다. 해당 키를 원래 주인이 사용한 것인지, 복사본을 가진 누군가가 사용한 것인지 구분할 수 없다는 뜻입니다. CCTV에 정문으로 자연스럽게 들어오는 사람이 찍혔지만, 그 사람이 실제 투숙객인지 열쇠를 주운 사람인지 알 수 없는 상황과 같습니다.

즉, 감시 카메라가 존재하더라도 범인이 정당한 열쇠를 들고 정문으로 들어온다면 이를 의심하기는 어렵습니다.

게다가 클라우드트레일에는 또 하나의 치명적인 한계가 있습니다. 기본 설정에서는 녹화 기록이 90일만 보관되며, 기간이 지나면 로그는 자동으로 삭제된다는 겁니다. 더 오래 보관하려면 별도의 저장소를 직접 설정해야 합니다. 클라우드트레일의 존재 자체를 모르는 경우도 적지 않고, 알고 있더라도 사건이 발생한 이후에야 CCTV를 돌려보듯 로그를 확인하는 경우가 비일비재합니다. 심지어 필요한 로그를 제대로 찾지 못하는 상황도 흔하죠.

따라서 실시간으로 이상 징후를 탐지하는 체계가 무엇보다 중요합니다. AWS에는 이러한 감지기 역할을 하는 다양한 서비스가 있기 때문에, 상황에 맞게 활용하면 보다 선제적으로 계정을 보호할 수 있습니다. (더 자세한 내용은, 글이 호응을 얻는다면 후속 편에서 준비해 보겠습니다.)

마스터 키인 루트 사용자(Root User) 관리하기

지금까지 이야기한 접근 키는 호텔 객실 하나를 열어주는 열쇠에 비유할 수 있습니다. 그런데 이 호텔에는 마스터 키가 존재한다면 어떨까요?

AWS 계정에는 루트 계정 사용자(Root Account User)라는 특별한 사용자가 있습니다. 계정을 처음 생성할 때 만들어지는 이 사용자는 해당 계정 내 모든 리소스에 접근할 수 있습니다. 서버를 생성하거나 삭제하는 것은 물론이고, 다른 IAM 사용자를 만들고 권한을 변경하거나, 심지어 계정 자체를 폐쇄하는 것까지 합니다. 호텔 체인 전체를 열 수 있는 마스터 키와 같은 존재입니다. 어떤 객실이든, 어떤 금고든 열 수 있는 열쇠입니다.

일반 사용자(IAM User)의 권한을 아무리 잘 설정해두더라도, 루트 계정 사용자가 탈취되면 모든 보안은 무력화됩니다. 공격자가 이 마스터 키를 손에 넣는 순간, 다른 열쇠로는 대응할 방법이 사실상 사라집니다.

Root User의 두 가지 자격 증명

이 루트 계정 사용자 역시 IAM 사용자와 마찬가지로 두 가지 자격 증명을 가집니다. 하나는 이메일 주소와 비밀번호로, AWS 콘솔(웹사이트)에 로그인할 때 사용합니다. 다른 하나는 접근 키로, 앞서 설명한 것과 동일한 두 줄의 문자열입니다.

AWS 공식 문서는 이 두 가지 모두에 대해 강하게 경고합니다. 콘솔 로그인에 대해서는 “루트 계정 사용자가 필요한 작업이 아니면 사용하지 마세요”라고 안내하며, 접근 키에 대해서는 아예 “생성하지 마세요”라고 명시합니다. 그러나 아이러니하게도 접근 키를 생성하는 버튼은 콘솔에 버젓이 존재합니다.

부주의하게 만약 이 마스터 키를 유출했다면 어떻게 될까요? 글의 서두에서 잠깐 언급했던 코드 스페이스 사건이 바로 그 사례입니다. 2014년, 공격자는 루트 계정을 얻어 코드 스페이스의 AWS 콘솔 접근 권한을 탈취했습니다. 회사가 대응을 시도하자 공격자는 서버와 저장소, 백업 등 복구 가능한 모든 리소스를 삭제해버렸습니다. 결국 코드 스페이스는 영구적으로 폐업했습니다.

모바일 키로 바꿔라

지금까지의 이야기를 정리하면 이렇습니다. 쇠 열쇠(IAM 접근 키)는 만료되지 않고, 복제가 쉽고, 누가 사용하는지 구별하기 어렵습니다. 한 번 유출되면 회수도 거의 불가능합니다. 여기에 마스터 키(루트 계정 사용자)까지 유출된다면, 사실상 대응 자체가 불가능해집니다.

물론 열쇠를 잃어버려 나오는 이 머리 아픈 상황에 대한 해법은 이미 정해져 있습니다. 모바일 키로 바꾸는 겁니다.

AWS도 권장하는 해법

IAM 자격 증명 센터는 AWS가 제공하는 모바일 키 시스템입니다. 이 시스템은 AWS 조직 관리 계정에서 모든 멤버 계정의 사용자와 권한을 통합 관리합니다. 로그인할 때마다 MFA를 거쳐야 하고, 인증이 완료되면 임시 토큰이 발급됩니다. 이 토큰은 일정 시간이 지나면 자동으로 만료됩니다. 또, 그렇기에 누가 어떤 계정에서 어떤 작업을 했는지 기록도 명확하게 남습니다.

사실 이 개념은 새로 등장한 규정은 아닙니다. AWS는 2017년 AWS SSO라는 이름으로 이 서비스를 처음 출시했고, 2022년 IAM 자격 증명 센터로 이름을 변경하며 공식 권장 방식으로 자리 잡았습니다. 이어 2025년에는 공식 블로그에서 “장기 IAM 접근 키를 넘어서라”는 제목의 글까지 발행했습니다.

그럼에도 불구하고 많은 개발자가 여러 이유로 IAM 사용자와 접근 키를 씁니다. 아주 큰 글씨로 경고가 적힌 공식 문서를 충분히 읽지 못했을 수도 있고, 코딩 에이전트가 생성한 설정을 의심없이 신뢰했을 수도 있습니다. 또는 문제를 알면서도 관성적으로 기존 방식을 고수했을 지도 모릅니다.

그래서일까요? 접근 키를 코드에 포함한 채 깃허브에 올렸다는 이야기를 개발자라면 한 번쯤은 들어봤을 겁니다. 그렇게 여전히 2024년 한 해에만 2,380만 개의 암호 키가 유출되었습니다.

보안 시스템을 직접 구축하기 어렵다면?

문제는 현실은 녹록지 않다는 겁니다. AWS 조직을 구성하고, IAM 자격 증명 센터를 설정하며, 사용자와 권한을 관리하고, 클라우드트레일 로그를 별도 저장소에 백업하는 일까지, 이 모든 과정을 직접 수행하려면 AWS 보안에 대한 전문 지식이 필요합니다. “개발자라면 이런 것쯤은 다 알지 않을까?”라고 생각할 수도 있습니다. 하지만 병원에서 수술을 받을 때도 외과 의사와 마취과 의사가 각자의 역할을 맡듯, DevSecOps나 클라우드 전문가 없이 이를 구축하는 일은 쉽지 않습니다. 중요한 보안 관련 일을 AI 모두에게 맡기는 것도 찝찝하고요.

특히 직접 개발을 하지 않고 외주 개발사에 맡기는 경우도 마찬가지입니다. 개발 과정에서 외주 개발사가 접근 키를 실수로라도 유출하지 않았다고 확신할 수 있을까요? 임시 자격 증명 운용이 번거롭다는 이유로, 두 줄짜리 문자열을 복사해 여러 곳에서 사용하고 있을 가능성도 있습니다. 또한 AWS에 대한 기초 지식이 부족하다면, 외주 개발이 끝난 다음 불필요한 사용자나 접근 키가 모두 정리되었는지 확인하기도 어렵습니다.

사실 그래서 저는 위시켓에서 이런 일을 대신합니다. 안심 호스팅 서비스라는 것을 운영하며 AWS 계정 생성부터 IAM 자격 증명 센터 사용자 생성, 권한 관리를 고객을 대신해 설정하고 운영합니다. 불필요한 리전에서의 서버 생성을 차단하고, 클라우드트레일 로그를 삭제하는 행위도 막습니다. 또한 보안에 취약한 IAM 사용자나 접근 키 생성 자체를 원천적으로 제한합니다. 정책은 누구든 예외 없이 적용됩니다.

마치며

물론 서비스 홍보도 홍보지만, 저희한테 맡기지 않더라도 모바일 키로의 전환은 꼭 검토했으면 합니다. 위시켓 클라우드팀에서 근무하다 보니, 탈취된 자격 증명으로 뭄바이나 스톡홀름과 같은 예상치 못한 리전에 서버가 만들어지고, 암호화폐 채굴에 악용되는 사례를 직접 목격한 적도 있습니다. 보안 규칙을 매일 고민하고 다루는 입장에서 가장 쉬운 일을 두고 큰 피해를 입는 고객사를 보며, 그 지식을 전하고 싶었습니다.

그래서 다시 한 번 강조하려고 합니다. 애초에 열쇠를 만들지 않는다면 잃어버릴 열쇠도 존재하지 않습니다. AWS 스스로가 말하듯 쇠 열쇠를 내려놓고, 모바일 키로 바꿔야 합니다.

기회가 된다면, IAM 자격 증명 센터의 기술적인 부분을 더 깊이 다뤄볼 예정입니다. 실제로 모바일 키를 어떻게 설정하고, 어떤 구조로 동작할지, 그 내부 구조를 열어보겠습니다.