AWS Root User & 계정 초기 보안

 

AWS를 처음 만들고 나서 많은 분들이 그냥 Root 계정으로 모든 작업을 하거나 혹은 IAM User 하나 만들어서 AdministratorAccess 붙이고 쓰는 경우가 많습니다. 

해당 글에서는 AWS 계정을 처음 만들었을 때 반드시 해야 하는 보안 설정과 Root User가 실제로 무엇인지를 정확하게 짚고 넘어갑니다.

1. Root User

AWS 계정을 처음 생성하면 계정의 모든 AWS 서비스 및 리소스에 대한 완전한 액세스 권한이 있는 단일 자격 증명이 자동으로 생성됩니다. 이것이 바로 AWS 계정 루트 사용자(Root User)입니다. 계정을 만들 때 사용한 이메일 주소와 암호가 루트 사용자의 로그인 자격 증명입니다.

루트 사용자가 일반 IAM 사용자와 가장 크게 다른 점은 다음과 같습니다.

• 어떠한 제한도 없습니다. IAM 사용자에게 AdministratorAccess 권한을 부여해도 Explicit Deny 또는 Policy Condition으로 특정 IP에서만 접근하도록 제한하는 등의 접근 관리가 가능합니다. 하지만 Root 계정은 이러한 제한이 통하지 않습니다.
• 결제 정보를 포함한 모든 것에 접근할 수 있습니다.
• SCP(Service Control Policy)도 Root User를 완전히 막지 못합니다. (일부 제한은 가능하지만 기본적으로 Root는 별도의 레이어에 있습니다.)

Linux 서버의 root 계정과 개념이 같습니다. Linux에서도 root는 제한 없이 모든 걸 할 수 있지만, 일상 작업에서는 일반 사용자 계정 + sudo를 사용하는 것처럼, AWS도 동일한 철학을 따릅니다.

 

 

2. Root User만 할 수 있는 작업

AWS 공식 문서에 따르면 아래 작업들은 반드시 Root User로만 수행해야 합니다. IAM User나 Role로는 불가능합니다.

작업	설명
계정 이메일 주소 / 암호 변경	계정 기본 정보 수정
결제/비용에 대한 IAM 액세스 활성화	IAM 사용자가 Billing 콘솔에 접근할 수 있게 허용
AWS Support 플랜 변경/취소	Basic/Developer/Business/Enterprise 등 플랜 관리
예약 인스턴스 마켓플레이스 판매자 등록	RI 마켓플레이스 판매 기능
AWS GovCloud 가입	정부/공공 클라우드 환경
S3 버킷 정책이 모든 접근을 막은 경우 해제	잘못 설정된 S3 버킷 정책 복구
계정 해지	AWS 계정 영구 삭제
KMS 키 복구 (특정 케이스)	관리 불능 상태의 KMS 키 복구

결론: Root User는 "비상 열쇠"처럼 다루어야 합니다. 금고에 잠가두고 꼭 필요할 때만 꺼내세요.

 

 

3. 계정 초기 보안 설정 - 반드시 해야 할 것들

3-1. Root Access Key 삭제! 최우선

Root User로 처음 로그인하면 가장 먼저 해야 할 일은 Root Access Key가 존재하는지 확인하고 즉시 삭제하는 것입니다.

Access Key는 CLI/SDK/API로 AWS에 접근할 때 사용하는 키입니다. Root의 Access Key가 유출되면 Root 계정의ID/Password가 유출된 것과 동일합니다. 그리고 Root는 제한이 없기 때문에 공격자가 계정 전체를 장악할 수 있습니다.

커뮤니티에서 자주 올라오는 "AWS 해킹당해서 한달 치 월급만큼 과금됐어요" 사례의 대다수가 GitHub에 Access Key를 실수로 커밋한 경우입니다.

 

확인 및 삭제 방법:

1. 콘솔 우측 상단 계정 이름 -> 보안 자격 증명(Security credentials)
2. 액세스 키(Access keys) 섹션 확인
3. 키가 존재한다면 -> 즉시 비활성화 후 삭제

루트 사용자 Access Key가 아예 없어야 정상입니다.

 

3-2. Root User MFA 활성화

MFA(Multi-Factor Authentication)는 계정 보안에서 가장 효과적인 방어 수단입니다. 비밀번호가 유출되더라도 MFA 없이는 로그인이 불가능합니다.

AWS는 현재 Root User에 대해 MFA 미설정 시 콘솔 첫 로그인 후 35일 이내에 설정을 강제합니다.

MFA 디바이스 종류:

종류 설명 권장 여부

종류	설명	권장 여부
가상 MFA (TOTP)	Google Authenticator, Authy 등 앱 사용	개인/소규모 팀
하드웨어 TOTP	물리적 OTP 토큰 기기	기업 환경 권장
FIDO2 보안 키	YubiKey 등 하드웨어 보안 키	기업 환경 권장

기업 환경에서는 Hardware MFA를 권장합니다. Hardware MFA는 물리적 디바이스이므로 특정 위치에 보관하여 Location-based 접근 관리가 가능합니다. 예를 들어 다음과 같이 역할을 분리할 수 있습니다.

• Root 비밀번호 -> Sys Admin이 관리
• Hardware MFA 디바이스 ->  Security Manager가 보관
• 접근 승인 -> CTO 결재

Root 계정에 로그인하려면 세 사람이 협력해야 하는 구조입니다. 보안에서 이런 분리된 책임 구조가 중요합니다.

참고: 루트 사용자 하나에 최대 8개의 MFA 디바이스를 등록할 수 있습니다. 비상용 백업 디바이스를 등록해두는 것을 권장합니다.

 

가상 MFA 설정 방법:

1. 콘솔 우측 상단 계정 이름 → 보안 자격 증명
2. 멀티 팩터 인증(MFA) → MFA 디바이스 할당
3. 인증 관리자 앱 선택 → QR 코드 스캔 (Google Authenticator / Authy)
4. OTP 코드 2회 입력 → 활성화 완료

 

3-3. 관리용 IAM User 생성 (또는 IAM Identity Center 사용)

Root 계정 설정이 끝나면 이제부터는 Root를 쓰지 않습니다. 일상적인 AWS 관리 작업을 위한 별도 계정을 만들어야 합니다.

AWS는 두 가지 방법을 권장합니다

방법 1 : IAM User 생성

• AdministratorAccess 권한을 부여한 IAM User를 생성
• 해당 IAM User로 일상 작업 수행
• 이 방법도 좋지만 다수의 계정이 있다면 관리가 복잡해집니다

방법 2 (권장) : IAM Identity Center 사용

• AWS Organizations + IAM Identity Center 조합
• Single Sign-On 형태로 여러 계정 접근

IAM User를 생성할 때는 다음을 지켜합니다.

• 그룹(Group)에 정책(Policy)을 연결하고 사용자를 그룹에 추가하는 방식 사용
• 직접 User에 Policy를 붙이는 방식보다 관리가 용이
• IAM User에도 MFA 설정 필수

루트 계정과 IAM 사용자를 구분하는 이유: 루트 계정만 사용하면 CloudTrail 로그가 전부 루트로 기록되어 어떤 사람이 어떤 작업을 했는지 추적이 불가능합니다. IAM User를 구분하면 "홍길동이 EC2를 삭제했다"처럼 행위자 추적이 가능합니다.

 

3-4. 비용 알림(Budget Alert) 설정

초기 계정 설정에서 꼭 빠뜨리는 것 중 하나가 비용 알림입니다. 리소스를 잘못 만들거나 Access Key가 유출되어 악의적인 사용이 발생했을 때 빠르게 알아채야 합니다.

AWS Budgets 설정 방법:

1. AWS Management Console -> Billing and Cost Management
2. 좌측 메뉴 -> Budgets -> 예산 생성
3. 비용 예산 선택 → 월 예산 금액 설정 (예: $10)
4. 알림 설정: 실제 비용이 예산의 80%, 100% 도달 시 이메일 발송
5. SNS 토픽을 연결하면 더 유연한 알림 가능

개인 계정이라면 $1~$5 정도의 낮은 금액으로 설정해두면 예상치 못한 과금을 빠르게 감지할 수 있습니다.

 

 

3-5. CloudTrail 활성화 (감사 로그)

CloudTrail은 AWS 계정의 CCTV입니다. 누가, 언제, 어떤 API를 호출했는지 모두 기록합니다.

AWS는 기본적으로 CloudTrail 이벤트 기록을 자동으로 활성화합니다. 최근 90일간의 관리 이벤트를 무료로 확인할 수 있습니다.

그러나 장기 보관과 모든 리전 통합 추적을 위해서는 Trail을 직접 생성해야 합니다.

 

Trail 생성 방법:

1. CloudTrail 콘솔 -> 추적 생성(Create trail)
2. 추적 이름 입력
3. S3 버킷 지정 (로그 저장소)
4. 모든 리전에 적용 옵션 활성화 (기본값)
5. CloudWatch Logs 연동 (선택 사항, 알람 설정을 위해 권장)
6. KMS 암호화 적용 (보안 강화)

비용 참고: 계정당 첫 번째 Trail의 관리 이벤트 전달은 무료입니다. S3 저장 비용은 별도로 발생하지만 소규모 계정 기준 매우 저렴합니다.

 

3-6. Root User 로그인 알림 설정

Root 계정이 콘솔에 로그인할 경우 즉시 알림을 받도록 설정하면 비인가 접속을 빠르게 탐지할 수 있습니다.

구성 방식: CloudTrail -> EventBridge -> SNS

Root 콘솔 로그인 이벤트 발생
       ↓
CloudTrail이 ConsoleLogin 이벤트 기록
       ↓
EventBridge 규칙이 이벤트 감지
       ↓
SNS 토픽을 통해 이메일/SMS 발송

주의: ConsoleLogin 이벤트는 us-east-1 (버지니아 북부) 리전의 CloudTrail에만 기록됩니다. EventBridge 규칙도 us-east-1에서 생성해야 합니다.

CloudTrail 외에도 AWS Config 서비스를 통해 다음을 모니터링할 수 있습니다:

• Root 계정에 Access Key가 생성되었는지
• Root 계정의 MFA가 비활성화되었는지

이를 AWS Config 관리형 규칙으로 설정하면, 조건에 맞는 경우 SNS로 이메일 알림을 자동 발송합니다.

 

4. 계정 초기 보안 체크리스트

[ ] Root Access Key 삭제 완료
[ ] Root MFA 활성화 완료
[ ] 관리용 IAM User 생성 (MFA 포함)
[ ] IAM User에 AdminAccess 부여 (그룹을 통해)
[ ] 결제 정보 IAM 접근 활성화 (Billing Access)
[ ] AWS Budgets 비용 알림 설정
[ ] CloudTrail Trail 생성 (멀티 리전)
[ ] Root 로그인 알림 설정 (EventBridge + SNS)

 

 

5. 실습: Root 계정 보안 설정 직접 해보기

이 실습은 CloudTrail + EventBridge 알림 구성을 직접 따라하는 실습입니다.

 

실습 1: CloudTrail Trail 생성

AWS 콘솔 상단 검색창에 CloudTrail을 입력 후 Trails 생성으로 들어갑니다.

 

Trail name 입력란에 manage-trail을 입력합니다.

Storage location 섹션에서 새 S3 버킷 생성을 선택하고

버킷 이름을 지정합니다. S3 버킷 이름은 전 세계에서 유일해야 하기 때문에 계정 ID를 붙여줍니다.

KMS 암호화를 설정합니다.

CloudWatch Logs에 연결합니다. 실시간으로 로그를 검색하고 이상 행동 발생 시 알림을 보낼 수 있습니다. -> EventBridge 연동

API activity 항목의 Read와 Write를 체크합니다. 리소스 조회와 변경을 감사할 수 있게됩니다.

 

실습 2: Root 로그인 알림 설정

Step 1: SNS 토픽 생성 (us-east-1 리전에서 진행)

1. 리전을 us-east-1 (버지니아 북부)로 변경
2. SNS 콘솔 → [Topics] → [Create topic]
3. Type: Standard
4. Name: "root-login-alert"
5. [Create topic]
6. [Create subscription] → Protocol: Email → 본인 이메일 입력
7. 이메일 수신함에서 확인 링크 클릭 (구독 확인)

 

Step 2: EventBridge 규칙 생성 (us-east-1 리전)

1. EventBridge 콘솔 → [Rules] → [Create rule]
2. Name: "root-login-detection"
3. Event source: "AWS events or EventBridge partner events"
4. Custom patterns (JSON editor)선택

{
  "detail-type": ["AWS Console Sign In via CloudTrail"],
  "detail": {
    "userIdentity": {
      "type": ["Root"]
    }
  }
}

5. Target types: "AWS service" 선택
6. Target: SNS topic → [root-login-alert] 선택
7. [Create rule]
8. tag 건너뛰기

테스트: Root 계정으로 콘솔 로그인 시 이메일 알림이 도착하면 성공입니다.

 

 

6. 흔한 실수들

실수 1: Root 계정으로 평소에 모든 작업

• 문제: 로그 추적 불가, 보안 위험 극대화
• 해결: IAM User 또는 IAM Identity Center 사용

실수 2: Root MFA 설정 안 함

• 문제: 비밀번호 유출 시 계정 전체 탈취 가능
• 해결: 지금 당장 설정 (5분이면 완료)

실수 3: Access Key를 코드에 하드코딩 후 GitHub Push

• 문제: GitHub 봇이 수초~수분 내에 키를 발견하고 악용
• 해결: 코드에 Key 절대 금지, IAM Role 사용, Secret Manager 활용

실수 4: 비용 알림 없이 사용

• 문제: 예상치 못한 고액 청구서
• 해결: Budgets + Zero spend alert 즉시 설정

실수 5: CloudTrail 없이 운영

• 문제: 보안 사고 발생 시 원인 추적 불가
• 해결: Trail 생성 (관리 이벤트 첫 번째 전달은 무료)

 

7. 마치며

이번 글에서는 AWS 계정을 처음 만들었을 때 Root User가 무엇인지, 왜 위험한지, 그리고 초기 보안 설정을 어떻게 해야 하는지 살펴봤습니다.

정리하면

• Root User는 비상 열쇠 - 금고에 잠가두고 꼭 필요할 때만 사용
• Access Key 삭제, MFA 설정은 계정 생성 직후 반드시 완료
• 일상 작업은 IAM User (또는 IAM Identity Center)로
• CloudTrail + Budget Alert로 모니터링 체계 구축

 

참고자료

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/root-user-best-practices.html

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_root-user.html

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/enable-mfa-for-root.html

https://docs.aws.amazon.com/ko_kr/awscloudtrail/latest/userguide/cloudtrail-trails.html

https://www.44bits.io/ko/post/first_actions_for_setting_secure_account

https://medium.com/saltware/aws-root-%EA%B3%84%EC%A0%95-%EB%B3%B4%EC%95%88-%EA%B0%95%ED%99%94%ED%95%98%EB%8A%94%EB%B2%95-197b9a7017c9