AWS Certified CloudOps Engineer - Associate (SOA-C03) #12 Domain 5-1 보안: IAM,Organizations,멀티계정 운영

인프라 AWS 자격증
5 분 소요

#11까지 네트워킹 도메인을 마쳤습니다. 마지막 도메인은 보안과 컴플라이언스(16%)입니다. 첫 글은 신원과 권한, 그리고 여러 계정을 표준으로 다스리는 멀티계정 거버넌스를 다룹니다. SAA,DVA에서 본 IAM을 여기서는 운영자가 권한을 점검,강제,감사하는 관점으로 봅니다.

IAM 권한 운영 #

IAM의 정의는 이전 시리즈에서 다뤘으니, 운영에서 자주 묻는 점에 집중하겠습니다.

개념운영 포인트
최소 권한필요한 만큼만 부여. 과한 권한을 줄이는 것이 상시 과제
Role사람,서비스에 장기 키 대신 임시 자격 증명. EC2,Lambda,태스크 역할
정책 평가기본 거부, 명시적 Allow로 허용, 명시적 Deny가 최우선

자격 증명 보고서와 마지막 사용 정보 #

운영자가 권한을 점검하는 두 도구입니다.

  • Credential Report: 모든 IAM 사용자의 비밀번호,액세스 키,MFA 상태를 CSV로 일괄 조회. “오래된 키, MFA 없는 계정을 찾아라"의 답
  • Access Advisor(마지막 사용 정보): 역할,사용자가 실제로 사용한 서비스를 보여 줌. 안 쓰는 권한을 회수해 최소 권한으로 좁히는 근거

“미사용 자격 증명과 권한을 식별해 정리하라"는 답이 이 둘입니다.

IAM Access Analyzer #

리소스 정책을 분석해 계정 밖(외부)에 의도치 않게 공유된 자원을 찾아냅니다. S3 버킷,IAM 역할,KMS 키 등이 외부에 노출됐는지 점검합니다. “외부에 잘못 공개된 리소스를 탐지하라"의 답이 Access Analyzer입니다.

MFA 강제 #

운영 보안의 기본은 MFA입니다. 시험은 “MFA를 어떻게 강제하는가"를 묻습니다.

  • 루트 계정 MFA: 가장 먼저 켜야 할 것. 루트는 일상 사용 금지
  • 정책으로 강제: IAM 정책의 Condition에 aws:MultiFactorAuthPresent를 걸어, MFA 없이는 민감 작업을 거부
  • SCP로 조직 차원 강제: 아래 Organizations에서

“MFA를 안 쓰면 특정 작업을 막아라"의 답이 조건 키 aws:MultiFactorAuthPresent를 쓴 정책입니다.

AWS Organizations: 멀티계정의 토대 #

계정이 늘면 계정마다 따로 관리하는 것은 불가능합니다. Organizations는 여러 계정을 한 조직으로 묶어 다스립니다.

개념역할
Management 계정조직의 루트. 결제,정책 관리
OU(Organizational Unit)계정을 용도별로 묶는 그룹(예: prod,dev)
SCP(Service Control Policy)OU,계정에 적용하는 권한 상한
통합 결제전 계정 사용량을 합산해 볼륨 할인

SCP의 핵심 성질 #

SCP는 시험 단골이며 오해도 많습니다.

  • SCP는 권한을 부여하지 않습니다. 오직 상한을 정해 제한합니다.
  • 실제 권한 = SCP 허용 범위 ∩ IAM 정책 허용 범위. 둘 다 허용해야 됩니다.
  • Management 계정에는 SCP가 적용되지 않습니다.

“조직의 모든 계정에서 특정 리전 사용을 금지하라”, “지정한 서비스 외 사용을 막아라"의 답이 SCP입니다. 반대로 “SCP로 권한을 줘라"는 표현이 보기에 있으면 그건 오답입니다.

멀티계정 표준화 #

도구역할
Organizations + SCP권한 상한,가드레일
StackSets#7에서 본 표준 스택 일괄 배포
Control Tower멀티계정 환경을 모범 사례로 자동 구성(랜딩 존)
IAM Identity Center여러 계정 SSO 접근(과거 AWS SSO)

“새 계정에 자동으로 보안 기준선을 적용하고 SSO로 접근을 통합하라"는 답이 Control Tower + Identity Center입니다. 운영자가 계정마다 IAM 사용자를 만드는 대신, Identity Center로 한 번 로그인해 여러 계정,역할에 접근하는 것이 권장 패턴입니다.

시험 출제 패턴 #

  • 오래된 키,MFA 미설정 사용자 탐지 → Credential Report
  • 미사용 권한 회수 → Access Advisor(마지막 사용 정보)
  • 외부에 잘못 공개된 리소스 탐지 → IAM Access Analyzer
  • MFA 없이는 작업 거부 → 정책 Condition aws:MultiFactorAuthPresent
  • 전 계정에 리전,서비스 가드레일 → SCP
  • 새 계정 자동 표준화 + SSO → Control Tower + IAM Identity Center
  • 전 계정에 표준 스택 → StackSets

자주 만나는 함정 #

1) SCP가 권한을 부여한다고 생각 #

SCP는 상한입니다. 권한은 IAM 정책이 줍니다. 둘의 교집합이 실제 권한입니다.

2) Management 계정도 SCP로 막힌다고 오해 #

SCP는 Management 계정에 적용되지 않습니다. 그래서 일상 작업은 멤버 계정에서 합니다.

3) 계정마다 IAM 사용자를 만든다 #

멀티계정 접근의 정석은 IAM Identity Center(SSO)입니다. 계정마다 사용자 복제는 운영 부담이 큽니다.

4) 루트 계정으로 일상 작업 #

루트는 MFA를 켜고 봉인합니다. 일상은 역할,Identity Center로 합니다.

정리 #

이번 글에서 잡은 것:

  • IAM 운영은 최소 권한 유지가 상시 과제. Credential Report,Access Advisor로 점검
  • IAM Access Analyzer로 외부 노출 리소스 탐지
  • MFA 강제는 정책 aws:MultiFactorAuthPresent 조건. 루트는 MFA + 봉인
  • Organizations + SCP로 멀티계정 가드레일. SCP는 부여가 아니라 상한, Management 계정 미적용
  • Control Tower(랜딩 존),IAM Identity Center(SSO),StackSets로 멀티계정 표준화

다음: Domain 5-2 탐지와 감사 #

신원과 거버넌스를 잡았으니, 다음은 무슨 일이 있었는지 추적,탐지하는 도구입니다.

#13 Domain 5-2 보안: Config,CloudTrail,GuardDuty,Security Hub,KMS에서는 CloudTrail로 API를 감사하는 법, Config로 구성 준수를 평가하는 법, GuardDuty의 위협 탐지, Security Hub의 통합 점수, 그리고 KMS 암호화 운영까지 정리하겠습니다.

X