[AWS SAA] 보안 / IAM

IAM

핵심 개념

• IAM은 AWS 리소스에 대한 인증과 권한 관리를 담당하는 서비스
• 사용자, 그룹, 역할, 정책을 통해 AWS 리소스 접근 권한을 제어
• IAM User는 사람 또는 애플리케이션에 장기 자격 증명을 부여할 때 사용
• IAM Group은 여러 사용자에게 공통 권한을 부여할 때 사용
• IAM Role은 AWS 서비스, 다른 계정, 외부 사용자 등이 임시로 맡아 사용할 수 있는 권한
• IAM Policy는 어떤 작업을 어떤 리소스에 허용하거나 거부할지 정의하는 JSON 문서
• 루트 사용자는 일상 작업에 사용하지 않고, 강력한 암호와 MFA를 적용해야 함
• EC2, Lambda 같은 AWS 서비스에는 장기 액세스 키 대신 IAM Role을 부여하는 것이 일반적

IAM 정책

IAM 정책 필수 요소

요소	설명
Effect	Allow 또는 Deny
Action	허용 또는 거부할 AWS API 작업
Resource	정책이 적용될 리소스
Condition	MFA 사용 여부, IP 조건, 태그 조건 등 추가 조건

• IAM 정책에는 명시적 허용과 명시적 거부를 작성할 수 있음
• 명시적 거부는 허용보다 우선
• 기본적으로 권한은 모두 거부 상태이고, 명시적으로 허용해야 작업 가능
• * 문자는 모든 작업 또는 모든 리소스를 의미할 수 있음
• *를 사용할 때는 최소 권한 원칙에 위배되지 않도록 주의해야 함
• 조건문을 사용하면 MFA 사용 여부, 요청 IP, 태그, VPC Endpoint 사용 여부 등을 기준으로 권한 제어 가능

자격 증명 기반 정책 vs 리소스 기반 정책

구분	설명	예시
자격 증명 기반 정책	IAM 사용자, 그룹, 역할에 연결하는 정책	IAM User Policy, IAM Role Policy
리소스 기반 정책	리소스에 직접 연결하는 정책	S3 버킷 정책, SQS 큐 정책, KMS 키 정책

• 자격 증명 기반 정책은 “이 사용자가 무엇을 할 수 있는가”를 정의
• 리소스 기반 정책은 “이 리소스에 누가 접근할 수 있는가”를 정의
• 다른 AWS 계정에 S3 버킷이나 SQS 큐 접근을 허용할 때 리소스 기반 정책을 자주 사용
• 다른 AWS 계정에 SQS 접근을 허용하려면 SQS 큐의 액세스 정책으로 권한을 부여할 수 있음

IAM Role / STS / AssumeRole

IAM Role

• Role은 AWS 서비스 또는 다른 계정/사용자가 임시로 맡을 수 있는 권한
• EC2, Lambda, ECS Task 등 AWS 서비스에는 IAM Role을 연결하여 권한을 부여
• Role을 사용하면 장기 액세스 키를 코드나 서버에 저장하지 않아도 됨
• IAM Role에는 권한 정책과 신뢰 정책이 있음
• 권한 정책은 Role을 맡은 주체가 무엇을 할 수 있는지 정의
• 신뢰 정책은 누가 이 Role을 맡을 수 있는지 정의

STS

• STS는 Security Token Service의 약자
• 임시 보안 자격 증명을 발급하는 서비스
• 임시 자격 증명은 Access Key ID, Secret Access Key, Session Token으로 구성
• 임시 자격 증명은 만료 시간이 있으므로 장기 키보다 보안상 유리

AssumeRole

• AssumeRole은 특정 IAM Role을 임시로 맡아 권한을 사용하는 방식
• Cross-account 접근이나 서비스 간 권한 위임에 자주 사용
• 교차 계정 접근은 대상 계정에서 IAM Role을 만들고, 신뢰 정책으로 다른 계정이 해당 Role을 맡도록 구성
• 예를 들어 A 계정의 Lambda가 B 계정의 리소스에 접근해야 하면, B 계정에 Role을 만들고 A 계정이 AssumeRole할 수 있도록 신뢰 정책을 설정

인스턴스 프로파일

• EC2에 IAM Role을 연결할 때는 인스턴스 프로파일을 통해 연결됨
• EC2 내부 애플리케이션은 인스턴스 메타데이터를 통해 임시 자격 증명을 가져와 AWS API를 호출할 수 있음
• 사용자가 임의로 EC2의 인스턴스 Role 권한을 사용하는 것은 아님
• 다만 EC2 내부에 접근 권한이 있는 사용자나 프로세스는 인스턴스 메타데이터를 통해 Role 자격 증명에 접근할 수 있으므로 주의 필요
• EC2에는 IMDSv2 사용을 권장

Permission Boundary

• Permission Boundary는 IAM 사용자 또는 역할이 가질 수 있는 최대 권한 범위를 제한하는 기능
• 사용자나 역할에 관리자 권한 정책이 붙어도 Permission Boundary 밖의 작업은 수행할 수 없음
• 권한 위임이 필요한 조직에서 개발자가 IAM Role을 만들 수 있게 하되, 최대 권한을 제한할 때 유용
• Permission Boundary 자체가 권한을 부여하는 것은 아님
• 실제 권한은 자격 증명 기반 정책, 리소스 기반 정책, SCP, Permission Boundary 등이 함께 평가된 결과로 결정됨

IAM Identity Center

• IAM Identity Center는 AWS 계정과 애플리케이션에 대한 중앙 집중식 SSO 서비스를 제공
• 과거 AWS SSO라고 불렸던 서비스
• 여러 AWS 계정에 대한 콘솔 접근과 CLI 접근을 중앙에서 관리 가능
• 외부 IdP와 연동하여 SAML 2.0 기반 페더레이션을 구성할 수 있음
• Microsoft Entra ID, Okta, Google Workspace 같은 외부 IdP와 연동 가능
• AWS Managed Microsoft AD 또는 자체 Active Directory와도 연동 가능
• 사용자에게 AWS 계정별 Permission Set을 할당하여 권한을 관리
• IAM 사용자를 계정마다 직접 만들기보다, 조직 단위 SSO 관리가 필요하면 IAM Identity Center를 우선 고려

IAM Access Analyzer

• IAM Access Analyzer는 권한과 리소스 공개 상태를 분석하는 서비스
• 외부 계정이나 퍼블릭에 공유된 리소스를 찾는 데 사용
• 미사용 역할, 미사용 권한, 미사용 액세스 키 등을 찾는 데도 사용할 수 있음
• IAM 정책을 검증하고, 정책 문법과 모범 사례 위반을 확인할 수 있음
• “IAM 사용자 목록을 확인하는 서비스”라기보다는 “권한 분석과 외부 공개/미사용 권한 탐지 서비스”에 가까움

IAM 주요 오답 포인트

• 루트 사용자는 일상 작업에 사용하지 않음
• 루트 사용자에는 MFA를 반드시 적용
• 액세스 키는 오래된 키 모니터링 → 새 키 생성 → 애플리케이션 전환 → 오래된 키 비활성화 → 삭제 순서로 로테이션
• EC2, Lambda, ECS Task에는 장기 액세스 키 대신 IAM Role 사용
• RunInstances는 새 EC2 인스턴스를 생성하는 API
• StartInstances는 중지된 기존 EC2 인스턴스를 시작하는 API
• 교차 계정 접근은 대상 계정의 Role과 신뢰 정책 구성이 핵심
• 암호화된 AMI를 다른 계정과 공유하려면 AMI 시작 권한뿐 아니라 스냅샷 복호화에 필요한 KMS 키 권한도 필요

KMS

핵심 개념

• KMS는 암호화 키를 생성하고 관리하는 서비스
• S3, EBS, RDS, CloudTrail 로그, Lambda 환경 변수 등 다양한 AWS 리소스의 암호화에 사용
• KMS 키는 키 정책, IAM 정책, Grant 등을 통해 사용 권한을 제어
• 암호화 키 사용 이력은 CloudTrail을 통해 감사 가능
• SSE-KMS를 사용하면 AWS KMS 키를 사용하여 서버 측 암호화를 수행
• KMS는 일반적인 AWS 관리형 암호화 키 관리에 적합
• 암호화 키를 전용 하드웨어에서 더 직접적으로 제어해야 하면 CloudHSM 또는 KMS Custom Key Store를 고려

AWS 관리형 키 vs 고객 관리형 키

항목	AWS 관리형 키	고객 관리형 키
키 생성	AWS 서비스가 자동 생성	고객이 직접 생성
키 관리	AWS가 관리	고객이 직접 관리
키 정책 제어	제한적	직접 제어 가능
키 순환	자동 순환	자동 순환 설정 가능
감사/권한 제어	제한적	더 세밀한 감사와 권한 제어 가능
비용	별도 키 관리 비용 없음	키 관리 비용 발생

• AWS 관리형 키는 사용이 간단하고 AWS가 관리
• 고객 관리형 키는 키 정책, 권한, 감사, 순환 설정을 더 직접적으로 제어 가능
• SSE-KMS에서 고객 관리형 키를 사용하면 키 사용자 권한 제어, 키 사용 감사, 키 교체 정책을 더 세밀하게 관리할 수 있음
• AWS 관리형 KMS 키는 매년 자동 순환됨
• 고객 관리형 KMS 키는 자동 순환을 활성화할 수 있으며, 기본적으로 1년 주기로 순환됨
• KMS 키 순환은 새 키 ID를 만드는 것이 아니라 같은 KMS 키 안에서 키 재료를 교체하는 방식

CloudHSM / 외부 키 관리

• CloudHSM은 고객 전용 HSM 클러스터를 제공하는 서비스
• FIPS 140-2 Level 3 검증 HSM을 사용
• 키를 AWS 관리형 KMS가 아니라 고객이 더 직접적으로 관리해야 하는 요구사항에 적합
• 암호화 키를 AWS 외부에서 직접 관리해야 하면 KMS External Key Store를 고려할 수 있음
• AWS 관리형 편의성보다 강한 키 통제권이 중요한 경우 CloudHSM 또는 External Key Store를 검토

암호화 유형

유형	설명
SSE-S3	S3에서 관리하는 키를 사용한 서버 측 암호화
SSE-KMS	AWS KMS 키를 사용한 서버 측 암호화
SSE-C	고객이 제공한 키를 사용한 서버 측 암호화
클라이언트 측 암호화	애플리케이션에서 업로드 전에 직접 암호화

• 서버 측 암호화는 데이터를 AWS 서비스에 저장할 때 AWS 측에서 암호화하는 방식
• 클라이언트 측 암호화는 애플리케이션에서 데이터를 먼저 암호화한 뒤 AWS에 저장하는 방식
• 암호화 키를 애플리케이션에서 직접 제어해야 하면 클라이언트 측 암호화 고려
• S3 저장 중 암호화 요구사항은 SSE-S3 또는 SSE-KMS로 충족 가능
• KMS 키 사용 감사와 세밀한 권한 제어가 필요하면 SSE-KMS 고려

EBS 암호화 관련

• EBS 기본 암호화를 활성화하면 새로 생성되는 EBS 볼륨을 기본적으로 암호화할 수 있음
• 암호화되지 않은 EBS 볼륨 생성을 방지하려면 IAM 정책과 EBS 기본 암호화 설정을 함께 고려
• 미암호화 EBS 볼륨을 탐지하려면 AWS Config 규칙 사용 가능
• 미암호화 EBS 볼륨 탐지 후 수정 자동화는 AWS Config와 Systems Manager Automation 조합으로 구성 가능
• 기존 비암호화 EBS 볼륨을 직접 암호화 상태로 변경할 수는 없음
• 비암호화 EBS 볼륨을 암호화하려면 스냅샷 생성 → 암호화된 스냅샷 복사 → 새 암호화 볼륨 생성 순서로 처리

Secrets Manager / Systems Manager Parameter Store

항목	Secrets Manager	Parameter Store
주요 용도	DB 비밀번호, API 키 같은 민감정보 저장	설정값, 일반 파라미터, 비밀값 저장
자동 교체	지원	기본 기능으로 자동 교체 미지원
비용	상대적으로 높음	표준 파라미터는 저렴하거나 무료 범위 활용 가능
암호화	KMS 연동	SecureString 사용 시 KMS 연동
대표 사용 사례	RDS 자격 증명 자동 교체	애플리케이션 설정값, 환경별 변수

• DB 자격 증명처럼 자동 교체가 중요하면 Secrets Manager 우선 고려
• 단순 설정값 저장이나 비용 절감이 중요하면 Parameter Store 고려
• API Key나 DB 인증 정보는 코드에 직접 저장하지 않고 Secrets Manager 또는 Parameter Store SecureString에 저장
• Parameter Store는 기본적으로 Secrets Manager 같은 자동 교체 기능을 제공하지 않음
• Parameter Store의 SecureString은 KMS로 암호화 가능

Cognito

핵심 개념

• Cognito는 웹/모바일 애플리케이션 사용자 인증과 권한 부여에 사용하는 서비스
• 회원가입, 로그인, 소셜 로그인, 토큰 발급 등에 사용
• 외부 애플리케이션 사용자 접근 관리에 적합
• AWS 계정 내부 운영자 권한 관리는 IAM 또는 IAM Identity Center가 담당
• 애플리케이션 최종 사용자 로그인은 Cognito를 고려

User Pool vs Identity Pool

유형	설명	주요 용도
User Pool	애플리케이션 사용자 회원가입 및 로그인 처리	인증
Identity Pool	인증된 사용자에게 임시 AWS 자격 증명 부여	AWS 리소스 접근 권한 부여

• User Pool은 사용자가 누구인지 인증하는 기능
• Identity Pool은 인증된 사용자에게 S3, DynamoDB 등 AWS 리소스에 접근할 수 있는 임시 권한을 부여하는 기능
• API Gateway에서 Cognito User Pool Authorizer를 사용하면 Cognito 사용자 풀 기반으로 API 접근을 제어할 수 있음
• 모바일 앱 사용자가 로그인 후 S3에 직접 업로드해야 하는 경우 Identity Pool을 함께 고려할 수 있음

WAF / Shield / Firewall Manager

WAF

• WAF는 웹 애플리케이션 방화벽
• HTTP/HTTPS 애플리케이션 계층 공격 방어에 사용
• SQL Injection, XSS, 악성 IP, 특정 URI/헤더 조건 차단 등에 사용
• ALB, API Gateway, CloudFront 등에 연결 가능
• NLB에는 WAF를 직접 연결할 수 없음
• 웹 ACL을 사용하여 요청을 허용, 차단, 카운트할 수 있음

Shield

• Shield Standard는 기본 DDoS 보호를 제공
• Shield Standard는 별도 비용 없이 기본 제공
• Shield Advanced는 고도화된 DDoS 방어, 비용 보호, DDoS 대응 지원이 필요한 경우 사용
• Shield Advanced는 CloudFront, Route 53, Global Accelerator, ELB, EC2 Elastic IP 등 인터넷 노출 리소스 보호에 사용

Firewall Manager

• Firewall Manager는 AWS Organizations 기반으로 여러 계정의 보안 정책을 중앙 관리하는 서비스
• 여러 계정의 WAF 규칙, Shield Advanced 보호, 보안 그룹 정책, Network Firewall 정책 등을 중앙에서 적용 가능
• 다중 계정 환경에서 일관된 보안 정책을 강제할 때 사용

GuardDuty

• GuardDuty는 AWS 계정과 워크로드에서 위협을 탐지하는 보안 모니터링 서비스
• 악성 IP 통신, 비정상 API 호출, 의심스러운 계정 활동 등을 탐지
• VPC Flow Logs, DNS 로그, CloudTrail 이벤트 등을 분석하여 위협을 탐지
• RDS 로그인 활동, EKS 감사 로그, S3 데이터 이벤트 등 일부 워크로드 보호 기능도 제공
• EventBridge와 연동하여 탐지 결과 기반 자동 대응 가능
• 직접 트래픽을 차단하는 방화벽 서비스는 아님
• 차단이나 격리는 EventBridge, Lambda, Security Hub, Network Firewall, WAF 등과 연계하여 구현

Inspector

• Inspector는 취약점 관리 서비스
• EC2 인스턴스, Amazon ECR 컨테이너 이미지, Lambda 함수의 취약점을 스캔
• 소프트웨어 취약점과 의도치 않은 네트워크 노출을 확인하는 데 사용
• CVE 기반 취약점 탐지와 우선순위 지정에 유용
• 런타임 행위 탐지 서비스라기보다는 취약점 스캔 서비스에 가까움
• 위협 행위 탐지는 GuardDuty가 담당

Macie

• Macie는 S3에 저장된 민감정보와 개인정보를 탐지하는 서비스
• PII, 자격 증명, 금융 정보, 민감 데이터 탐지에 사용
• S3 버킷의 공개 여부, 암호화 상태 등 보안 상태를 파악하는 데도 도움
• 탐지 결과를 운영자에게 알릴 때 EventBridge, SNS, Security Hub 등과 연동 가능
• S3 데이터 보호와 개인정보 탐지 요구사항에서 자주 사용

Organizations / SCP

AWS Organizations

• AWS Organizations는 여러 AWS 계정을 조직 단위로 관리하는 서비스
• 계정을 OU 단위로 그룹화하고 정책을 적용할 수 있음
• 통합 결제, 계정 생성, 조직 단위 정책 관리에 사용
• 다중 계정 환경에서는 Organizations와 IAM Identity Center를 함께 사용하는 경우가 많음

SCP

• SCP는 Service Control Policy의 약자
• 조직, OU, 계정 단위로 AWS 서비스 사용 범위를 제한하는 정책
• SCP는 권한을 부여하는 정책이 아니라 최대 권한 경계를 제한하는 정책
• IAM 정책에서 허용하더라도 SCP에서 막으면 해당 작업은 수행할 수 없음
• 특정 리전 사용 금지, 특정 인스턴스 타입 실행 금지, CloudTrail 비활성화 금지 등에 사용
• 조직 전체에 일관된 제한을 적용하려면 루트 OU 또는 대상 OU에 SCP 적용
• 여러 계정의 CloudTrail 중앙 관리를 위해 조직 추적을 활성화하고, SCP로 임의 비활성화를 제한할 수 있음

Active Directory 연동

AWS Directory Service

• AWS Directory Service는 AWS에서 Microsoft Active Directory 또는 AD 호환 디렉터리를 사용할 수 있게 하는 서비스
• Windows 워크로드, AD 인증, 도메인 조인, 그룹 정책 등이 필요한 경우 사용
• Amazon WorkSpaces, FSx for Windows File Server, Windows 애플리케이션 등과 함께 사용 가능

AWS Managed Microsoft AD

• AWS에서 관리하는 Microsoft Active Directory
• 다중 AZ에 디렉터리를 배포하여 가용성을 높일 수 있음
• AWS가 인프라 관리, 모니터링, 패치 등 일부 운영을 담당
• Windows 파일 공유, 도메인 조인, AD 기반 인증이 필요한 워크로드에 적합
• 온프레미스 AD와 신뢰 관계를 구성할 수 있음

AD Connector

• 온프레미스 AD에 대한 프록시 역할을 하는 디렉터리 서비스
• 사용자 정보를 AWS에 저장하지 않고 기존 온프레미스 AD를 사용해 인증
• 온프레미스 AD 사용자를 AWS 애플리케이션이나 서비스에 연동해야 할 때 고려

SAML 2.0 Federation

• 온프레미스 또는 외부 IdP 사용자를 AWS 콘솔이나 애플리케이션에 연동할 때 SAML 2.0 페더레이션 사용 가능
• 외부 IdP에서 인증한 사용자가 IAM Role을 맡아 AWS 리소스에 접근하도록 구성 가능
• 조직 단위 SSO는 IAM Identity Center를 우선 고려

기타 보안 서비스

서비스	용도
Security Hub	보안 표준과 모범 사례 기준으로 AWS 환경 평가 및 보안 결과 통합
Control Tower	다중 계정 환경의 랜딩존 구성, 가드레일 적용, 계정 프로비저닝
Security Lake	보안 데이터를 중앙 집중화하고 OCSF 형식으로 정규화
QLDB	변경 불가능하고 암호화 검증 가능한 원장 데이터베이스
ACM	SSL/TLS 인증서 발급 및 관리
AWS Config	리소스 구성 변경 추적과 규정 준수 평가
AWS Service Catalog	승인된 AWS 서비스와 구성을 중앙에서 배포 및 관리

Security Hub

• Security Hub는 여러 보안 서비스의 결과를 통합하고 보안 표준에 따라 평가하는 서비스
• CIS, AWS Foundational Security Best Practices 같은 보안 표준 평가에 사용
• GuardDuty, Inspector, Macie 등의 보안 결과를 통합해서 볼 수 있음

Control Tower

• Control Tower는 다중 계정 AWS 환경을 빠르게 구성하고 거버넌스를 적용하는 서비스
• 랜딩존, 계정 프로비저닝, 가드레일 적용에 사용
• OU 구조, 계정 설정, 정책 등에 대한 드리프트를 감지할 수 있음
• 계정 API 호출이나 로그인 감시 자체가 핵심 기능은 아니며, 계정 거버넌스와 랜딩존 관리에 초점

ACM

• ACM은 SSL/TLS 인증서를 발급하고 관리하는 서비스
• ALB, NLB, CloudFront, API Gateway 등에 인증서를 연결할 수 있음
• CloudFront에서 사용할 ACM 인증서는 us-east-1 리전에 생성해야 함
• ALB나 API Gateway 리전 엔드포인트에 사용할 인증서는 해당 리전에 생성
• S3 버킷 자체에 ACM 인증서를 직접 연결하는 구조는 아님
• EC2 인스턴스에 ACM 퍼블릭 인증서를 직접 설치해서 사용하는 것은 일반적으로 지원되지 않음
• EC2에서 인증서를 직접 사용해야 하면 외부 인증서 또는 ACM Private CA 등 별도 방식을 고려

KMS 키 삭제 보호 자동화 예시

• KMS 키 삭제는 일정 대기 기간 후 실제 삭제되는 방식
• 실수로 KMS 키 삭제가 예약되면 암호화된 데이터에 접근하지 못할 위험이 있음
• EventBridge에서 KMS 키 삭제 예약 이벤트를 탐지
• Systems Manager Automation Runbook 또는 Lambda로 삭제 예약 취소 시도
• SNS로 관리자에게 알림 전송
• 핵심은 삭제 자체를 사전에 막거나, 삭제 예약을 빠르게 탐지하고 취소하는 것

보안 서비스 선택 기준 요약

요구사항	적합한 서비스
AWS 사용자, 역할, 권한 관리	IAM
조직 단위 SSO와 계정 접근 관리	IAM Identity Center
임시 자격 증명 발급	STS
교차 계정 권한 위임	AssumeRole
최대 권한 범위 제한	Permission Boundary
조직/OU/계정 단위 서비스 사용 제한	SCP
외부 공개 리소스·미사용 권한 분석	IAM Access Analyzer
암호화 키 관리	KMS
전용 HSM 기반 키 관리	CloudHSM
AWS 외부 키 관리	KMS External Key Store
DB 비밀번호/API 키 자동 교체	Secrets Manager
설정값·비밀값 저비용 저장	Systems Manager Parameter Store
웹/모바일 앱 사용자 로그인	Cognito User Pool
앱 사용자에게 임시 AWS 권한 부여	Cognito Identity Pool
웹 공격 방어	WAF
DDoS 보호	Shield
여러 계정 보안 정책 중앙 관리	Firewall Manager
위협 탐지	GuardDuty
취약점 스캔	Inspector
S3 민감정보 탐지	Macie
보안 결과 통합과 표준 평가	Security Hub
다중 계정 랜딩존과 거버넌스	Control Tower
AD 기반 인증과 Windows 워크로드 연동	AWS Directory Service
승인된 서비스/구성 배포	AWS Service Catalog
SSL/TLS 인증서 관리	ACM
리소스 구성 변경 추적과 규정 준수 평가	AWS Config