루트 사용자와 MFA, 계정 주인의 로그인을 잠가 두는 이유

AWS에 가입하고 콘솔에 처음 들어갈 때는 가입하면서 넣은 이메일과 비밀번호를 쓴다.
들어가자마자 MFA 장치를 등록하라는 안내가 뜬다.

당장 서버부터 띄워 보고 싶다면 넘기고 싶은 화면이다.
그런데 이 로그인은 앞으로 만들 어떤 로그인과도 무게가 다르다.
그 이유부터 정리한다.

가입에 쓴 이메일이 루트 사용자가 된다

AWS 계정은 서버와 데이터 같은 자원, 그리고 그 요금 청구가 한데 묶이는 단위다.
계정을 만들 때 쓴 이메일과 비밀번호로 들어오는 신원을 루트 사용자라고 한다.

루트 사용자는 계정 안의 모든 서비스와 자원에 제한 없이 닿는다.
결제 정보도 예외가 아니다.
클라우드 컴퓨팅 글에서 본, 클라우드를 써도 사용자에게 남는 설정과 데이터가 모두 이 로그인 하나 아래에 있다.

루트만 할 수 있는 일도 있다.
조직에 묶이지 않은 계정이라면 루트 이메일과 비밀번호를 바꾸는 일과 계정을 해지하는 일은 루트로만 한다.

하나뿐인 관리자가 실수로 자기 권한을 지웠을 때 정책을 고쳐 되살리는 일도 루트 몫이다.
모든 사용자를 거부하도록 잘못 쓴 S3 버킷 정책을 지우는 일도 마찬가지다.

그래서 루트는 없앨 수 없다.
평소에는 쓰지 않고 잠가 두었다가 이런 일이 생길 때만 꺼낸다.
AWS도 일상 작업에는 루트 대신 따로 만든 관리자 신원을 쓰라고 강하게 권한다.

여러 계정을 AWS Organizations로 묶어 쓰면 관리 계정이 다른 계정의 루트 자격 증명을 아예 지울 수도 있다.
여기서는 처음 만든 계정 하나, 조직에 묶이지 않은 계정을 기준으로 설명한다.

조직에 묶이지 않은 계정에서 루트를 지우지 않고 잠가 두는 이유는 무엇일까?⁠답 보기답 접기

루트만 할 수 있는 일이 남아 있어서다. 루트 이메일과 비밀번호를 바꾸는 일, 계정을 해지하는 일, 권한을 모두 잃은 관리자를 되살리는 일이 그렇다.

비밀번호 말고 하나를 더 확인한다

MFA(다요소 인증)⁠는 로그인할 때 비밀번호 말고 다른 종류의 증명을 하나 더 요구하는 방식이다.
비밀번호가 아는 것이라면, 두 번째 요소는 보안 키나 휴대폰처럼 가진 것이거나 지문처럼 몸에 속한 것이다.

AWS는 모든 계정의 루트 사용자에게 MFA를 요구한다.
아직 등록하지 않았다면 콘솔 로그인을 처음 시도한 때부터 35일 안에 등록해야 한다.
첫 로그인에서 뜨는 안내가 이것이다.

루트에 등록할 수 있는 MFA는 세 종류다.
패스키와 보안 키, 휴대폰의 인증 앱, 6자리 숫자를 띄우는 하드웨어 토큰이다.
문자 메시지로 코드를 받는 방식은 새로 켤 수 없다.

패스키는 기기에 저장한 개인 키로 서명해 본인임을 증명한다.
그 키를 USB 장치에 담은 것이 보안 키이고, 휴대폰이나 비밀번호 관리자에 저장해 여러 기기에서 쓰는 패스키도 있다.
AWS에서는 비밀번호를 넣은 뒤 두 번째 요소로 쓴다.

Assign MFA device

• Passkey or Security Key(선택됨)⁠기기나 USB 보안 키에 둔 개인 키로 서명한다
• Authenticator app⁠휴대폰 앱이 6자리 코드를 만든다
• Hardware TOTP token⁠실물 장치가 6자리 코드를 띄운다

아직 등록하지 않았다면 첫 콘솔 로그인 시도부터 35일 안에 마쳐야 한다.

가짜 로그인 페이지 앞에서 생기는 차이

MFA가 있으면 비밀번호가 새도 바로 뚫리지는 않는다.
다른 사이트에서 샌 비밀번호를 루트에도 쓰고 있었더라도, 공격자에게는 두 번째 요소가 없다.

피싱은 사정이 다르다.
진짜와 똑같이 꾸민 가짜 로그인 페이지가 본인에게서 비밀번호와 6자리 코드를 받아, 그 자리에서 진짜 페이지에 그대로 넣는다.

인증 앱의 코드는 앱과 서버가 나눠 가진 비밀 값과 현재 시각만으로 계산한다.
계산에 사이트 주소가 들어가지 않으니, 코드가 유효한 짧은 동안이라면 어느 페이지에 넣었든 진짜 로그인에 쓰인다.

패스키는 등록한 사이트에 묶인다.
서명하는 값에 사이트 주소가 함께 들어가고, 브라우저와 인증기는 다른 주소의 페이지에 그 사이트용 서명을 내주지 않는다.
가짜 페이지는 넘겨줄 서명을 얻지 못한다.

AWS가 가능하면 패스키나 보안 키를 쓰라고 하고, 인증 앱은 그것을 갖추기 전까지 쓰는 임시 수단으로 소개하는 이유가 여기 있다.

공격자가 루트 비밀번호를 손에 넣었다. 콘솔에 들어갈 수 있는지는 루트에 등록한 MFA와 비밀번호가 샌 길에 따라 달라진다.

1. 공격자가 가진 것샌 비밀번호
2. 진짜 로그인 페이지비밀번호 맞음
3. MFA 확인등록 안 함 · 묻지 않음
4. 콘솔공격자가 들어감

MFA를 등록하지 않은 루트는 샌 비밀번호만으로 공격자에게 열린다. 인증 앱은 비밀번호만 가진 공격자를 막지만, 가짜 로그인 페이지가 6자리 코드까지 받아 진짜 페이지에 넣으면 뚫린다. 패스키는 등록한 사이트에서만 서명해서 두 경우를 모두 막는다.

MFA를 등록하지 않았으면 비밀번호가 맞는 것으로 로그인이 끝난다. 다른 사이트에서 샌 비밀번호를 루트에도 쓰고 있었다면 공격자가 계정 전체를 쥔다.

본인이 가짜 페이지에 넣은 비밀번호가 곧바로 진짜 페이지로 넘어간다. 묻는 MFA가 없으니 공격자가 들어간다.

비밀번호는 맞았지만 6자리 코드는 본인 휴대폰의 인증 앱에서만 나온다. 비밀번호만 가진 공격자는 여기서 멈춘다.

가짜 페이지는 비밀번호에 이어 6자리 코드까지 받아 진짜 페이지에 바로 넣는다. 코드는 어느 사이트에 넣는지 따지지 않아서 공격자가 들어간다.

비밀번호는 맞았지만 패스키는 본인 기기에 있다. 비밀번호만 가진 공격자는 여기서 멈춘다.

패스키는 등록한 사이트에서만 서명한다. 가짜 주소에서는 서명이 나오지 않으니, 비밀번호를 넘겨받은 공격자도 MFA를 통과하지 못한다.

‘등록 안 함’은 MFA 등록을 미뤄 둔 동안의 루트다. 가짜 페이지 주소는 예시다. 휴대폰이나 패스키를 둔 기기를 통째로 빼앗기는 경우와 복구 절차를 노리는 공격은 다루지 않는다.

장치를 모두 잃었을 때 돌아오는 길

MFA를 하나만 등록해 두면 그 휴대폰을 바꾸거나 잃는 날 바로 막힌다.
루트에는 종류를 섞어 MFA를 8개까지 등록할 수 있고, 로그인할 때는 그중 하나만 있으면 된다.

모두 잃었다면 대체 인증으로 들어간다.
계정에 등록된 이메일과 기본 연락처 전화번호로 각각 본인 확인을 거친다.
둘 중 하나라도 쓸 수 없으면 AWS Support에 MFA를 꺼 달라고 요청해야 한다.

그 이메일은 비밀번호 재설정 링크가 가는 곳이기도 하다.
메일함을 가진 사람이 루트 비밀번호를 바꿀 수 있으니, 메일함의 보안도 루트의 보안에 들어간다.

AWS가 먼저 재설정을 요구하기도 한다.
계정에서 이상한 로그인 활동이나 인터넷에 공개된 자격 증명을 발견하면, 로그인할 때 루트 비밀번호를 다시 정하라는 화면을 띄우고 이유를 계정 이메일로 알린다.

MFA 장치를 도난당했다면 새 MFA를 설정한 뒤 루트 비밀번호도 바꾼다.
장치를 가져간 사람이 비밀번호까지 알고 있을 수 있어서다.

루트에는 액세스 키를 만들지 않는다

액세스 키는 프로그램이 AWS에 요청을 보낼 때 그 요청에 서명하는 데 쓰는 장기 비밀 키다.
만료 시각이 없어서 지우기 전까지 계속 쓰인다.

콘솔 로그인

계정 주인

루트 이메일이랑 비밀번호 넣었어

AWS 로그인

비밀번호는 맞아. 그래도 MFA로 한 번 더 확인할게

루트 액세스 키로 서명한 요청

남의 스크립트

저장소에서 찾은 루트 액세스 키로 서명했어

AWS API

서명 맞네. 바로 처리할게

MFA는 묻지 않는다

루트의 액세스 키가 코드나 설정 파일에 남으면, 그 파일을 손에 넣은 사람은 콘솔 로그인도 MFA도 거치지 않고 계정 전체에 요청을 보낼 수 있다.
AWS의 보안 점검 서비스도 루트에 액세스 키가 남아 있으면 가장 높은 심각도로 표시한다.

AWS는 루트 액세스 키를 만들지 말라고 강하게 권한다.
루트 권한으로 명령줄 도구를 써야 하는 드문 경우에는 aws login 명령으로 루트 로그인을 거쳐 임시 자격 증명을 받는다.
이 자격 증명은 15분마다 저절로 바뀌고, 길어도 12시간이면 끝난다.

새 가입 방식에는 루트가 없다

AWS는 지금까지와 다른 새 가입 방식을 일부 고객에게 차례로 열고 있다.
가입 방식을 비교한 문서는 새 방식을 Sign up for AWS (new), 지금까지의 방식을 Sign up for AWS (advanced)⁠라고 부른다.

새 방식은 가입할 때 루트 사용자를 만들지 않는다.
이메일로 가입하거나 Google, Apple, GitHub, Amazon 계정으로 들어오고, 어느 쪽이든 AWS Builder ID라는 개인 프로필이 생겨 로그인에 쓰인다.

루트에게만 맡기던 일 가운데 일부는 가입한 소유자가 넘겨받는다.
모든 사용자를 거부하도록 잘못 쓴 S3 버킷 정책을 지우는 일은 소유자가 IAM 콘솔에서 따로 한다.

루트가 없다고 지킬 것이 사라지지는 않는다.
Google이나 GitHub 계정으로 들어왔다면 그 계정의 보안이 곧 AWS 계정의 보안이다.
새 방식에서 MFA는 강하게 권장될 뿐 필수가 아니고, 장치를 모두 잃었을 때 스스로 되찾으려면 복구 이메일을 미리 등록해 두어야 한다.

새 방식은 자원을 프로젝트라는 단위에 담는다.
프로젝트는 연락처 국가로 정해진 리전(자원이 실제로 놓이는 지역) 하나에 묶이고, 나중에 바꿀 수 없다.
한국은 시드니 리전이라서 서울 리전을 쓰려면 지금까지의 방식으로 가입하거나 고급 기능을 켜야 한다.

고급 기능을 켜면 AWS가 대신 관리하던 계정 묶음과 관리 계정을 사용자가 넘겨받는다.
먼저 유료 플랜으로 바꿔야 하고, 켠 뒤에는 되돌릴 수 없으며, 지출 한도도 사라진다.
이때 관리 계정의 루트 이메일과 비밀번호를 정하게 되니, 그때부터는 앞의 내용이 그대로 적용된다.

실무에서 루트를 다루는 방식

실무에서는 루트에 패스키나 보안 키를 포함해 MFA를 둘 이상 등록한다.
하나는 평소 쓰는 기기에, 하나는 따로 보관한 보안 키에 두는 식이다.
루트 액세스 키는 만들지 않고, 루트로는 루트만 할 수 있는 일만 한다.

팀이 쓰는 계정이라면 루트 이메일을 여러 사람이 함께 받는 그룹 주소로 둔다.
담당자가 자리를 비워도 AWS의 연락을 놓치지 않는다.
이메일과 전화번호는 둘 다 복구에 쓰이니, 한 사람이 둘 다 쥐지 않게 나눠 맡긴다.

루트 비밀번호를 같은 AWS 계정의 서비스 위에서 돌아가는 도구에 보관하지 않는다.
비밀번호를 잃으면 그 도구에도 들어갈 수 없다.
이 밖의 권장 사항은 루트 사용자 모범 사례에 모여 있다.

계정에 등록된 이메일과 전화번호가 지금도 받을 수 있는 것인지는 가끔 확인해 둔다.
MFA를 모두 잃은 날 돌아올 길이 이 둘에 걸려 있다.