[SAA-C03] AWS IAM, CLI, SDK, Cloudshell, 보안도구 총정리

IAM = Identity and Access Management

특징

• Root 계정은 default로 생성 (user 생성 외엔 이용하지 않는 것이 보안상 좋음)
• Users 조직내 존재하는 계정들, 그룹화할 수 있음
• Groups 내에는 User만 존재할 수 있음. Group 내 Group X
• User는 꼭 그룹 안에 속할 필요 X, 여러 Groups에 속할 수 있음
• Global Service → 리전을 선택할 필요 없이 어디서나 사용할 수 있음

Permissions

User 또는 Group은 Policies (정책)이라고 불리는 JSON document에 배정될 수 있음
AWS 리소스에 대한 접근 권한을 정의한 정책 문서를 JSON 형식으로 작성한 것

• 누가(AWS 사용자나 역할), 무엇을(Action), 어디에(Resource)
• least privilege principle (최소 권한 원칙)
• user가 원하는 것보다 더 많은 권한을 주지 말 것

IAM Users and Groups

root 계정은 보안 문제로 관리자 계정 등 users를 따로 생성해 줌.
 

• 콘솔 액세스 권한 제공
  • "AWS Management Console에 대한 사용자 액세스 권한 제공"을 체크하지 않으면, 그 사용자는 웹 브라우저에서 로그인할 수 없음
  • 웹 브라우저 콘솔(https://console.aws.amazon.com)로 로그인 불가
  • 대신 프로그래밍 방식 액세스만 가능하게 됨 (Access Key ID / Secret Access Key를 이용한 CLI, SDK, API 접근만 가능)
• 사용자 유형
  • (1) Identity Center에서 사용자 지정 - 권장
    • 조직 내 여러 사용자에게 계정과 콘솔 접근을 중앙에서 통합 관리할 때 사용
    • 일종의 싱글 사인온(SSO) 서비스
    • 사용자는 개인 계정을 만들지 않고도 관리자가 지정한 포털에서 로그인
    • SAML, Active Directory, Google Workspace 등 연동 가능
    • 권장 이유:
      • 사용자 수가 많을 때 중앙 집중 관리에 유리
      • 사용자별로 어떤 AWS 계정, 어떤 서비스에 접근 가능한지를 세밀하게 조정 가능
      • AWS Organizations와 함께 쓰면 여러 계정에 대한 접근 관리도 쉬워짐
• •  
  • (2) IAM 사용자 생성 (기존 방식)
    • 개별적으로 AWS 리소스에 접근할 수 있는 고유한 사용자 계정을 생성
    • 콘솔 로그인용 ID, 암호, 액세스 키 발급
    • 주로 다음과 같은 경우 사용:
      • 프로그래밍 방식 접근(API/CLI) 을 위한 액세스 키 필요
      • 외부 앱이 AWS 리소스에 자동으로 접근해야 할 때
      • 비상 계정 (예: SSO 장애 시 대비용 관리자 계정)

• • • 개인 AWS 계정에서는 보통 이걸로 작업 많이 함
    • 단점: 사용자 수 많아지면 관리 복잡

권한 설정 전, 그룹 생성 진행
 

Policy name이 administratorAccess인 admin 그룹을 하나 생성해 줌
 

태그는 리소스에 메타데이터를 입력할 수 있게 함.
 

User에 사용자가 생성된 것을 확인함

 
여기 있는 권한은 직접 부여된 게 아니라 admin 그룹을 통해 부여됨.
즉, admin 그룹이 가지고 있는 모든 권한이 mark에게 할당된다는 뜻. 이런식으로 권한을 관리하는 것이 더 쉬움
 

대시보드에서 AWS계정을 보면 Account ID, 그리고 이 계정의 IAM 사용자를 위한 로그인 URL이 있음. 해당 URL은 내가 직접 설정 가능 (간소화)
 

🌟 root 계정과 IAM 계정의 차이

Root는 프로필 정보에 Account ID만, IAM은 IAM user:mark까지 뜸.
그리고 오른쪽 상단에 IAM username @ alias 정보로 표출됨
 

IAM 정책

하나의 그룹에 속한 사용자들은 그 그룹의 권한을 얻으며 정책의 상속이 가능함.
그리고 아무 그룹에 속하지 않을 수도 있는데, 각각의 사용자에게는 inline 정책이라는 걸 생성할 수도 있음
 

IAM 정책 구조

• Version: 정책 언어 버전으로 일반적으로 2012-10-17
• Id: 정책을 식별함 (선택)
• Statement(문장): 하나일 수도, 여러 개일 수도 있음.
  • Sid: 문장 식별자 (선택)
  • Effect: 문장이 특정 API에 접근하는 걸 허용할 지 거부할 지 (Allow, Deny)
  • Principle: 특정 정책이 적용될 사용자, 계정, 혹은 역할 (해당 캡처에선 AWS의 root 계정에 적용)
  • Action: effect에 기반해 허용, 거부되는 API 호출의 목록
  • Resource: 적용될 Action의 리소스 목록
  • Condition: statement가 언제 적용될지 결정( 선택)

→ 시험에는 Effect, Principal, Action, Resource가 많이 나옴
 
리소스(Resource) = AWS에서 생성되거나 사용하는 개별 대상이나 객체
예를 들어서..

• 이 IAM 정책은 특정 S3 리소스에 대한 읽기 권한을 부여합니다
• 우리는 EC2 리소스를 자동으로 스케일링합니다

S3 기준으로는 버킷 같은거
 

아까처럼 그룹에 사용자 추가하려면 첫번째 걸 선택, 지금은 ‘직접 정책 연결’로 시도
 

IAMReadOnlyAccess 권한: IAM에 있는 어떤 것이든 읽을 수 있음
 

 
그룹에 권한 부여하기
developers 그룹을 생성해 mark를 추가하고, 아무 정책이나 하나 연결함.
그리고 admin에도 다시 추가해 줌

mark에게 부여된 권한을 보니 첨부된 방식에 따라 다른 3개의 권한을 부여 받은 것을 확인함
 

JSON 코드로 보면 다음과 같음.
여기서는 어느 리소스에서 어느 액션이든지 허용함. = 관리자 액세스
 

IAM MFA 개요

비밀번호 정책 (Password Policy)

AWS에서는 보안을 강화하기 위해 비밀번호 정책을 설정함.

주요 설정 항목:

• 최소 비밀번호 길이 설정
• 다음과 같은 문자 유형 요구:
  • 대문자 (Uppercase)
  • 소문자 (Lowercase)
  • 숫자 (Numbers)
  • 특수문자 (Non-alphanumeric)
• IAM 사용자 스스로 비밀번호 변경 허용하거나 허용하지 않을 수 있음
• 주기적인 비밀번호 변경 요구 (Password Expiration)
• 이전 비밀번호 재사용 금지

즉, 비밀번호 복잡도와 관리 정책을 통해 계정 보안을 강화함

---

MFA (Multi-Factor Authentication)

• 비밀번호(기억) + 인증기기(소지) 를 결합한 이중 인증 방식
• 비밀번호가 유출되더라도 계정 보호 가능
• 루트 계정과 IAM 사용자가 AWS 리소스를 삭제하거나 변경할 수 있는 권한이 있으니 MFA를 통해 추가 보호함.

---

AWS MFA 디바이스 옵션

Virtual MFA Device	Google Authenticator, Authy	스마트폰 앱 기반 (하나의 기기에서 여러 Token)
Universal 2nd Factor (U2F) Security Key	YubiKey (U2F 방식)	하나의 키로 여러 계정 보호 가능
Hardware Key Fob Device	Gemalto, SurePassID (GovCloud)	실물 기기 기반 MFA

 
 
계정 설정(Account Settings)에서 암호 정책 설정 가능

 
 

 
내 보안자격증명에서 MFA 디바이스 할당 가능
 

 
MFA 디바이스 옵션

1. 패스키 또는 보안키
2. 인증 관리자 앱
3. 하드웨어 TOTP 토큰

 

AWS 액세스 키, CLI, SDK

AWS에 액세스하는 방법은 3가지가 있음

1. AWS Management Console (protected by password + MFA)
2. AWS Command Line Interface (CLI): protected by access keys
3. AWS Software Developer Kit (SDK) - for code: protected by access keys

SDK는 AWS로부터 애플리케이션 코드 내에서 API를 호출하고자 할 때 사용되는 방식

Access Key

자격 증명, 터미널에서의 AWS 액세스를 가능하게 해줌 → AWS Console에서 발급하고 키 관리는 사용자가 직접 함 → 공유 금지 • Access Key ID는 username • Secret Access Key는 password라고 생각

AWS CLI

명령줄 셸에서 명령어를 사용해 AWS 서비스들과 상호작용할 수 있게 돕는 도구
모든 명령어가 aws로 시작함
AWS 서비스의 공용 API로 직접 액세스가 가능함
CLI로 리소스를 관리하는 스크립트를 개발해 일부 작업을 자동화할 수 있음 (어떤 사람들은 관리콘솔은 아예 사용안하고 CLI만 쓰기도 함)

AWS SDK

소프트웨어 개발 키트로 특정 언어로 된 라이브러리의 집합
프로그래밍 언어에 따라 개별 SDK가 존재
BUT 터미널에서 사용하는 게 아니라 코딩을 통해 애플리케이션 내에 심는 것
→ 즉 애플리케이션 내에 자체적으로 AWS SDK가 있는 것
자바스크립트, 파이썬, PHP, NET, Ruby, Java, Go, Node.js, C++ 등이 해당
모바일 SDK, IoT SDK도 가능
해당 강의에서 사용하게 될 AWS CLI는 Boto라는 Pyhton용 AWS SDK에 구축되어 있음
 

AWS CloudShell

aws 클라우드에서 무료로 사용 가능한 터미널 같은 개념

상단에 있는 >_ 모양이 CloudShell
특이점

1. 특정 리전에서만 사용 가능
2. Cloudshell말고 Terminal에서 Configure 해놓은 대로 사용해도 상관 없음
3. Download, Upload 기능이 용이

CLI 기능을 사용하기 위해 터미널이든 Cloudshell이든 아무거나 사용하면 됨
 

AWS 서비스에 대한 IAM Role

IAM Role: 사용자와 같지만 실제 사람이 사용하게 만들어진 것이 아닌 AWS 서비스에 의해 사용되도록 만들어짐
 
예를 들어 EC2 인스턴스(가상 서버)를 만들었음. AWS에서 어떤 작업을 수행하려고 하는데 그러기 위해선 EC2 인스턴스에 권한을 부여해야 함. 이때 IAM Role을 만들어 하나의 개체로 만들어 줌.
EC2 인스턴스가 AWS에 있는 어떤 정보에 접근하려고 할 때 IAM Role을 사용할 것임. 권한이 올바르게 부여됐다면 하려고 하는 호출에 정상적으로 접근.

Policy(정책)와 뭐가 다른가?

왼: IAM Role, 오: Policy

존재 타입	신원(Identity)	문서(Document)
자격증명	없음 (Assume 시 임시 키 발급)	해당 없음
목적	누가 이 역할을 맡아(Assume) AWS 작업을 하게 할지 정의	어떤 액션을 어떤 리소스에 허용/거부할지 규칙 정의
연결 방식	정책을 “붙여서” 권한을 얻음 (+ 신뢰 정책 필수)	사용자/그룹/역할 등에 첨부되어 권한 부여
대표 사례	EC2 인스턴스 역할, Lambda 실행 역할, 크로스계정 접근 역할	AWS 관리형 정책, 고객 관리형 정책, 인라인 정책

IAM 보안 도구

1. IAM 자격 증명 보고서를 만들 수 있음 (IAM Credentials Report, Account-level)
보고서에는 계정에 있는 사용자와 다양한 자격 증명의 상태를 포함함.
2. IAM 액세스 관리자 (IAM Access Advisor, User-level)
사용자에게 부여된 서비스의 권한, 해당 서비스에 마지막으로 액세스한 시간
어떤 권한이 사용되지 않는지 볼 수 있음, 사용자 권한을 줄이면서 최소권한의 원칙을 지킬 수 있음
 
자격 증명 보고서

 
IAM 액세스 관리자

 
IAM - Users → Mark → 마지막 액세스 날짜
내 사용자가 언제, 어떤 서비스에 액세스 했는지 보여줌.
Organizations, Health, Identity and Access Management, IAM Service, EC2 등 그리고 접근하지 않은 서비스까지도 확인 가능함.
→ 사용자가 올바른 권한을 가지고 있는지 확인 가능. 사용자가 전체가 아닌 일부 서비스에만 접근할 필요가 있을 수 있는데, EC2 같은 특정 서비스에 액세스하는 경우 이 서비스에 대한 관리적 액세스 권한이 부여(AdministratorAccess)되었다고 표시됨
즉, Access 관리자는 AWS에서 세부적인 사용자 액세스 권한을 수행해야 할 때 유용하다