[도서] Amazon VPC - 4장: 나의 AWS 전용 공간, 계정

루트 사용자와 AWS 계정은 사실 다른 개념이다

AWS에 처음 가입하면 이메일과 비밀번호로 로그인하게 되는데, 이때 쓰는 계정이 루트 사용자(Root Account)다. 그런데 이 루트 사용자와 AWS 계정 자체를 같은 것으로 혼동하기 쉽다. 엄밀히 말하면 AWS 계정은 모든 서비스와 리소스가 존재하는 공간 그 자체고, 루트 사용자는 그 공간에 접근하는 신분 중 하나다.

구분이 중요한 이유가 있다. 루트 사용자는 해당 계정 안에서 무제한에 가까운 권한을 가진다. 결제 및 비용 관리, IAM 사용자 생성과 권한 복원처럼 다른 어떤 사용자도 대신할 수 없는 영역이 있다. 그러니 루트 사용자를 일상적인 운영에 쓰는 건 처음부터 좋지 않다. 계정이 생성되는 순간부터 IAM 사용자를 따로 만들어서 실제 작업은 거기서 하는 게 맞다.

그리고 계정 생성 시 부여되는 12자리 계정 ID(Account ID)는 IAM 엔티티를 포함한 계정 내 모든 리소스의 도메인 역할을 한다. IAM 사용자가 어디서 무엇을 하든 이 계정 ID가 항상 따라다닌다.

루트 사용자에게 MFA를 걸어야 하는 이유

루트 사용자는 암호 기반으로 인증한다. 암호는 유출 가능성이 있고, 유출됐을 때 피해가 가장 크다. 해커가 루트 사용자 계정을 탈취하면 고비용 서비스를 대량으로 생성하거나 IAM 권한 구조 전체를 뒤집어 놓을 수 있다. 보안 사고를 수습하는 것도 힘든데, 클라우드에서는 비용 문제까지 같이 따라온다.

그래서 MFA(Multi Factor Authentication)를 계정 생성 직후에 바로 적용해야 한다. MFA 디바이스는 세 가지 형태를 선택할 수 있는데, 보안 키나 하드웨어 TOTP 토큰은 별도 장비가 필요하니 모바일 앱 기반의 인증 관리자 앱을 쓰는 게 현실적이다. Google Authenticator 앱으로 QR 코드를 스캔하면 설정이 끝난다.

MFA를 적용하고 나면 루트 사용자 로그인 단계에서 OTP 코드를 추가로 입력해야 하므로 암호만 유출돼도 로그인이 불가능해진다. 루트 사용자뿐만 아니라 IAM 사용자에게도 MFA 적용은 필수로 가져가야 한다.

IAM 권한은 정책으로 연결되고, 그룹 단위로 관리된다

IAM은 AWS 서비스에 접근하는 보안 주체(Identity)와 인증, 그리고 그 주체의 서비스 접근 권한을 관리하는 서비스다. 권한은 JSON 형태의 정책(Policy)으로 만들고, 이걸 IAM 엔티티에 연결해야만 서비스 접근이 가능해진다. 정책이 연결되지 않은 IAM 엔티티는 아무것도 할 수 없다.

루트 사용자의 권한을 대행하는 SuperUser에게 AdminstratorAccess 정책을 연결해도 루트 사용자 권한의 부분집합일 뿐이다. 이 지점에서 루트 사용자를 평소에 쓰지 않는 게 더 확고해진다. IAM 사용자를 통해 업무 영역별로 그룹을 나누고 각 그룹에 필요한 최소 권한만 부여하는 구조가 실제 운영에서 맞다.

예를 들어 Admins 그룹에는 운영상 필요한 권한을 넓게, Security Managers 그룹에는 보안 업무에 필요한 최소 권한만, Developers 그룹에는 개발에 필요한 서비스 접근 권한을 따로 부여하는 식이다. 한 IAM 사용자에게 정책을 직접 연결하거나, 그룹에 정책을 연결하고 사용자를 편입시키는 두 방식 모두 가능하다. 담당 업무 수행자가 2명 이상이라면 그룹 단위 관리가 훨씬 효율적이다.

권한이 너무 넓으면 어떤 권한이 실제로 쓰이고 있는지 파악 자체가 어려워진다. EC2 서비스 하나만 해도 변경 권한 종류가 수십 가지인데, 업무와 무관하게 AdministratorAccess를 남발하면 나중에 정책 관리가 손에 잡히지 않는다. IAM Access Analyzer로 실제 사용된 권한만 추출해서 최소 권한으로 점진적으로 좁혀나가는 습관을 들이는 게 좋다.