Cloud/Amazon Web Service

AWS 계정 보안 설정 가이드 — MFA, 루트 계정 관리, IAM 정책

Zerocok 2026. 4. 11. 21:32
반응형

AWS 계정 보안 설정 가이드 — MFA, 루트 계정 관리, IAM 정책

AWS 계정을 만들고 가장 먼저 해야 할 일은 "보안 설정"이다.

들어가며

AWS 계정을 생성하면 기본적으로 루트 사용자가 모든 권한을 갖게 된다. 이 상태로 서비스를 운영하는 것은 관리자 비밀번호가 적힌 포스트잇을 모니터에 붙여두는 것과 같다.

이 글에서는 AWS에서 공식적으로 권장하는 AWS Startup Security Baseline(SSB)의 계정 보안 항목(ACCT.01~ACCT.12)을 기반으로, 계정을 안전하게 구성하는 방법을 단계별로 정리한다.

1. 계정 연락처 설정 (ACCT.01)

왜 중요한가?

AWS에서 보안 이슈가 발생하면 등록된 연락처로 알림을 보낸다. 연락처가 더 이상 사용하지 않는 개인 이메일이라면 중요한 보안 알림을 놓칠 수 있다.

실천 방법:

  • 계정 수준 연락처를 유효한 이메일 배포 목록으로 설정
  • 보안, 운영, 결제 각각에 대체 연락처 지정
  • 퇴사자 이메일이 등록되어 있지 않은지 정기 점검

2. 루트 사용자 보호 (ACCT.02)

루트 사용자는 AWS 계정의 "슈퍼 관리자"다. 절대로 일상 업무에 사용하면 안 된다.

루트 사용자 보안 체크리스트

  • 루트 사용자에 MFA 활성화 (하드웨어 MFA 권장)
  • 루트 사용자의 액세스 키 삭제 (프로그래밍 방식 접근 차단)
  • 루트 사용자 사용은 계정 설정 변경 등 불가피한 경우만 허용
  • 루트 사용자 로그인 시 즉시 알림 설정 (CloudWatch Events → SNS)

루트 사용자만 가능한 작업 (예시)

  • 계정 설정 변경 (이름, 이메일, 비밀번호)
  • IAM 사용자 권한 복원
  • 결제 정보 변경
  • 계정 해지

이 작업들을 제외하면 루트 사용자를 사용할 이유가 없다.

3. IAM 사용자 및 콘솔 액세스 구성 (ACCT.03)

각 사용자에게 개별 IAM 계정을 생성하고 콘솔 액세스를 구성한다.

핵심 원칙:

  • 공용 계정 사용 금지 — 누가 어떤 작업을 했는지 추적 불가
  • 각 사용자에게 고유한 자격 증명 부여
  • 콘솔 로그인이 필요 없는 서비스 계정은 프로그래밍 방식 접근만 허용

4. IAM 사용자 그룹으로 권한 관리 (ACCT.04)

개별 사용자에게 직접 정책을 붙이면 관리가 금방 복잡해진다. 그룹 기반 권한 관리가 정답이다.

그룹 구성 예시

Admins 그룹       → AdministratorAccess
Developers 그룹   → PowerUserAccess (IAM 제외)
ReadOnly 그룹     → ReadOnlyAccess
SecurityAudit 그룹 → SecurityAudit

운영 팁:

  • 신규 입사자는 해당 팀의 그룹에 추가만 하면 됨
  • 퇴사 시 그룹에서 제거 + IAM 사용자 비활성화
  • 정기적으로 그룹별 정책 검토

5. MFA 적용 (ACCT.05)

MFA는 계정 탈취를 막는 가장 효과적이면서 무료인 보안 수단이다. 2024년 Snowflake 침해사고에서 165개 기업이 피해를 입은 핵심 원인이 바로 MFA 미적용이었다.

MFA 유형별 비교

MFA 유형 장점 단점
가상 MFA (Authenticator 앱) 무료, 간편 기기 분실 시 복구 복잡
하드웨어 MFA (YubiKey 등) 가장 안전 비용 발생, 물리적 관리 필요
SMS MFA 익숙함 SIM 스와핑 공격에 취약, AWS 비권장

권장 구성:

  • 루트 사용자: 하드웨어 MFA
  • 관리자급 IAM 사용자: 하드웨어 MFA 또는 가상 MFA
  • 일반 IAM 사용자: 가상 MFA

MFA 미설정 사용자 접근 차단 정책

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllExceptMFASetup",
      "Effect": "Deny",
      "NotAction": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:ListMFADevices",
        "iam:ResyncMFADevice",
        "sts:GetSessionToken"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

이 정책을 적용하면 MFA를 설정하지 않은 사용자는 MFA 관련 작업만 가능하다.

6. 비밀번호 정책 시행 (ACCT.06)

IAM 콘솔에서 비밀번호 정책을 설정할 수 있다.

권장 설정:

  • 최소 길이: 14자 이상
  • 대문자, 소문자, 숫자, 특수문자 포함 필수
  • 비밀번호 만료: 90일
  • 최근 사용한 비밀번호 재사용 방지: 최소 24개

7. CloudTrail 로그 보호 (ACCT.07)

CloudTrail은 AWS 계정의 모든 API 호출을 기록하는 서비스로, 보안 사고 분석의 핵심 데이터 소스다.

로그 보호 체크리스트

  • 모든 리전에서 CloudTrail 활성화
  • 로그를 전용 S3 버킷에 저장
  • S3 버킷에 MFA Delete 활성화 (실수로 삭제 방지)
  • S3 Object Lock 설정 (변조 방지)
  • 로그 파일 무결성 검증 활성화
  • Organization 레벨 Trail 구성 (멀티 계정 환경)

8. S3 퍼블릭 액세스 차단 (ACCT.08)

S3 버킷이 실수로 공개되어 데이터가 유출된 사례는 매우 많다.

즉시 적용:

  • 계정 수준에서 S3 Block Public Access(BPA) 활성화
  • VPC BPA도 함께 적용 권장
  • 외부 공개가 필요한 경우 별도의 전용 계정에서만 운영

9. 미사용 리소스 정리 (ACCT.09)

사용하지 않는 VPC, 서브넷, 보안 그룹은 공격 표면을 넓힌다.

정기 점검 항목:

  • 기본 VPC의 불필요한 리소스 삭제
  • 사용하지 않는 보안 그룹 삭제
  • 미사용 IAM 사용자/역할 비활성화
  • 미사용 리전 Opt-out

10. 비용 모니터링 (ACCT.10)

비정상적인 비용 증가는 보안 침해의 신호일 수 있다. 공격자가 탈취한 계정으로 암호화폐 채굴용 EC2 인스턴스를 대량 생성하는 사례가 실제로 빈번하다.

  • AWS Budgets으로 예산 알림 설정
  • 일별/월별 비용 임계값 초과 시 즉시 알림
  • Cost Explorer로 비용 이상 패턴 분석

11. GuardDuty 활성화 (ACCT.11)

GuardDuty는 AWS의 관리형 위협 탐지 서비스다. 활성화만 하면 별도 구성 없이 동작한다.

분석하는 데이터 소스:

  • CloudTrail 관리/데이터 이벤트
  • VPC Flow Logs
  • DNS 쿼리 로그
  • S3 데이터 이벤트
  • EKS 감사 로그

탐지 유형 예시:

  • 비정상적인 API 호출 패턴
  • 알려진 악성 IP로부터의 접근
  • EC2 인스턴스의 암호화폐 채굴 활동
  • IAM 자격 증명 유출 징후

12. Trusted Advisor로 모니터링 (ACCT.12)

Trusted Advisor는 보안, 성능, 비용, 안정성 관점에서 AWS 인프라를 점검하는 서비스다. (자세한 내용은 시리즈 4편에서 다룬다.)

정리 — 계정 생성 직후 보안 설정 순서

  1. 루트 사용자 MFA 설정 + 액세스 키 삭제
  2. 연락처 정보 최신화
  3. IAM 사용자/그룹 생성
  4. 비밀번호 정책 설정
  5. 전체 사용자 MFA 필수화
  6. CloudTrail 활성화 + S3 로그 보호
  7. S3 BPA 활성화
  8. GuardDuty 활성화
  9. 비용 알림 설정
  10. Trusted Advisor 초기 점검

이 10단계를 완료하면 AWS 계정의 기본적인 보안 체계가 갖추어진다.

추가: AWS IAM Identity Center를 활용한 계정 접근 관리

멀티 계정 환경에서는 개별 IAM 사용자를 계정마다 만드는 대신 IAM Identity Center를 사용하는 것이 권장된다.

장점:

  • 하나의 자격 증명으로 여러 AWS 계정에 SSO 접근
  • 권한 세트(Permission Set)로 계정별 권한을 중앙 관리
  • MFA를 한 곳에서 일괄 적용
  • 장기 액세스 키 없이 임시 자격 증명으로 CLI/SDK 접근 가능

2025~2026년 주요 업데이트:

  • 멀티 리전 복제 (2026.02) — DR 지원, 기본 리전 장애 시에도 접근 유지
  • 고객 관리형 KMS 키 (2025.09) — 저장 중 암호화에 자체 키 사용 가능

팁: re:Invent 2025에서 발표된 Login for AWS local development를 사용하면, 콘솔 자격 증명으로 로컬 개발 환경에 접근할 수 있다. 더 이상 .aws/credentials에 장기 액세스 키를 저장할 필요가 없다.

이 글은 AWS Startup Security Baseline(SSB) 공식 가이드를 기반으로 실무 경험을 더하여 작성되었습니다.
클라우드 보안 시리즈 [2/10]

저작자표시 비영리 동일조건 (새창열림)