보안 서비스

IAM 접근 제어와 KMS·비밀 관리, 위협 탐지와 거버넌스로 이어지는 AWS 보안 계층

보안 설계에서는 권한을 예방적으로 제한하는 일과 위협을 탐지해 대응하는 일을 분리해 생각한다. IAM·SCP·KMS는 접근과 데이터 보호 경계를 만들고, GuardDuty·Security Hub·Inspector는 위협이나 설정 문제를 찾는다. 각 서비스의 책임 범위를 혼동하지 않는 것이 시작점이다.

1. IAM 심화

IAM 정책 평가 순서

AWS는 요청이 들어오면 아래 순서로 정책을 평가한다.

1. 명시적 Deny (어디서든 Deny가 있으면 즉시 거부)
2. SCP (Organizations 레벨)
3. Resource-based Policy
4. IAM Permission Boundary
5. Session Policy (임시 자격증명)
6. Identity-based Policy (IAM 사용자/역할 정책)

핵심 규칙: 명시적 Deny > 모든 Allow. 기본값은 암묵적 Deny(Implicit Deny).

SCP (Service Control Policy)

SCP는 AWS Organizations에서 계정 또는 OU 전체에 적용하는 최대 권한 경계다.

Root
 └── OU: 운영
       └── 계정 A (SCP: EC2만 허용)
             └── IAM 사용자 (AdministratorAccess)
                   → EC2만 사용 가능 (IAM이 아무리 넓어도 SCP가 상한선)
  • SCP는 Allow 목록 또는 Deny 목록 방식으로 작성
  • 관리 계정(Management Account)에는 SCP가 적용되지 않음
  • SCP 자체는 권한을 부여하지 않음 — IAM 정책도 함께 있어야 함

SAP 핵심 시나리오

특정 리전 외 리소스 생성 차단, 특정 서비스 사용 금지 → SCP Deny

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["ap-northeast-2", "us-east-1"]
    }
  }
}

Permission Boundary

IAM 사용자/역할에 설정하는 최대 권한 상한선이다. 실제 권한 = IAM 정책 ∩ Permission Boundary (교집합).

IAM 정책: S3 전체 + EC2 전체
Permission Boundary: S3 전체
→ 실제 권한: S3 전체만 (EC2는 불가)

활용 사례

  • 개발팀에게 IAM 역할 생성 권한 위임 — 단, 그들이 만드는 역할도 Boundary 적용 강제
  • 팀별로 사용 가능한 서비스 제한

Cross-Account 역할 (Role Assumption)

A 계정의 사용자가 B 계정의 리소스에 접근하는 패턴이다.

계정 A (사용자)
  └── sts:AssumeRole 호출
        ↓
계정 B (신뢰 정책에 계정 A 허용)
  └── 역할 획득 → B 계정 리소스 접근

신뢰 정책 (Trust Policy)

{
  "Principal": {
    "AWS": "arn:aws:iam::계정A_ID:root"
  },
  "Action": "sts:AssumeRole"
}

ExternalId

  • 제3자(파트너사, SaaS)가 역할을 맡을 때 추가 검증값
  • Confused Deputy 공격 방지

IAM Access Analyzer

  • IAM 정책에서 외부 공유된 리소스 탐지
  • 의도치 않게 외부에 노출된 S3 버킷, IAM 역할, KMS 키 등 식별
  • 정책 검증(Policy Validation): 오타, 문법 오류, 보안 경고 제공

2. KMS (Key Management Service)

핵심 개념

KMS는 암호화 키의 생성, 저장, 관리, 교체를 완전 관리형으로 제공한다. AWS 서비스의 거의 모든 암호화는 KMS 위에서 동작한다.

키 유형

유형 관리 주체 교체 비용
AWS Managed Key AWS 자동 3년마다 자동 무료
Customer Managed Key (CMK) 고객 직접 설정 가능 (연간 자동 교체) 월 $1/키 + API 호출
Customer Provided Key (SSE-C) 고객 (S3 한정) 고객 책임 별도

SAP 핵심: 감사 로그 + 키 교체 제어 필요 = CMK, 간단한 암호화 = AWS Managed Key

봉투 암호화 (Envelope Encryption)

KMS는 대용량 데이터를 직접 암호화하지 않는다.

1. KMS CMK로 데이터 키(DEK) 생성
2. DEK로 실제 데이터 암호화 (로컬, 빠름)
3. CMK로 DEK 암호화 (봉투에 봉인)
4. 암호화된 DEK + 암호화된 데이터 함께 저장

복호화:
1. 암호화된 DEK를 KMS로 전송 → CMK로 복호화
2. 복호화된 DEK로 데이터 복호화

KMS 키 정책

KMS 키 접근은 IAM 정책만으로 부족하다 — 키 정책(Key Policy)이 필수다.

  • 키 정책에 계정 루트가 없으면 IAM으로 접근 불가
  • Cross-Account 키 공유: 키 정책에 외부 계정 추가

Multi-Region Keys

  • 동일 키 머티리얼을 여러 리전에 복제
  • 리전 간 이동하는 데이터를 재암호화 없이 복호화 가능
  • 글로벌 DynamoDB, Aurora Global, S3 복제와 함께 사용

CloudHSM

  • AWS가 관리하는 전용 하드웨어 보안 모듈
  • KMS보다 높은 수준의 키 통제 (AWS도 키에 접근 불가)
  • FIPS 140-2 Level 3 인증
  • 비용이 매우 높음

KMS → 일반적인 암호화, CloudHSM → 키를 절대 AWS에 맡길 수 없는 규정 준수 환경

3. Secrets Manager vs Parameter Store

Secrets Manager

  • DB 비밀번호, API 키, OAuth 토큰 등 민감한 자격증명 저장
  • 자동 교체(Rotation): Lambda 함수로 주기적 자동 변경
  • RDS, Redshift, DocumentDB 기본 교체 통합
  • KMS로 자동 암호화
  • 비용: 시크릿당 월 $0.40
앱 → Secrets Manager API → 최신 비밀번호 반환
                ↓ (자동 교체 스케줄)
           Lambda 실행 → RDS 비밀번호 변경 → Secrets Manager 업데이트

SSM Parameter Store

  • 설정값, 환경 변수, 비밀번호 저장
  • Standard (무료) vs Advanced (비용 발생)
  • SecureString 타입: KMS로 암호화
항목 Secrets Manager Parameter Store
자동 교체 O (기본 제공) X (직접 구현)
비용 유료 (시크릿당) Standard 무료
버전 관리 O O
계층 구조 X O (/app/db/password)
주 용도 DB 비밀번호, API 키 앱 설정, 환경 변수

SAP 핵심: 자동 교체 필요 = Secrets Manager, 설정값 + 비용 절감 = Parameter Store

4. 위협 탐지 및 모니터링

GuardDuty

완전 관리형 위협 탐지 서비스. 로그를 분석해 악의적 활동을 자동으로 식별한다.

분석 소스

소스 탐지 내용
CloudTrail 비정상 API 호출, 루트 계정 사용
VPC Flow Logs 비정상 네트워크 트래픽, 포트 스캔
DNS 로그 악성 도메인 쿼리
EKS 감사 로그 컨테이너 위협
S3 데이터 이벤트 비정상 S3 접근

GuardDuty 위협 예시

  • EC2가 비트코인 마이닝 서버에 연결
  • 자격증명이 다른 국가 IP에서 사용됨
  • IAM 사용자가 비정상적으로 많은 API 호출
  • 포트 스캔 감지

EventBridge + Lambda 자동 대응

GuardDuty 위협 발견
  → EventBridge 규칙
    → Lambda (자동 대응)
      → EC2 격리 / IAM 키 비활성화 / SNS 알림

GuardDuty는 활성화만 하면 됨 — 에이전트 설치 불필요, 로그 직접 설정 불필요

Amazon Inspector

  • EC2, Lambda, 컨테이너 이미지의 취약점(CVE) 자동 스캔
  • OS 패키지, 애플리케이션 종속성 취약점 탐지
  • ECR 이미지 푸시 시 자동 스캔
항목 GuardDuty Inspector
목적 런타임 위협 탐지 취약점 스캔
대상 계정 전체 활동 EC2, Lambda, 컨테이너
실시간 O 지속적 스캔

Macie

  • S3 버킷에서 개인정보(PII) 자동 탐지
  • 신용카드 번호, 주민번호, 여권 번호 등 식별
  • GDPR, HIPAA 규정 준수에 활용

Security Hub

여러 보안 서비스의 결과를 중앙 대시보드에서 통합 관리한다.

GuardDuty ─┐
Inspector  ─┤→ Security Hub → 통합 대시보드 + 우선순위 알림
Macie      ─┤
Config     ─┘
  • CIS AWS Foundations Benchmark 등 표준 컴플라이언스 체크
  • 멀티 계정 집계 (Organizations 연동)
  • EventBridge로 자동 대응 연결 가능

AWS Config

  • 리소스 설정 변경 이력 기록
  • Config Rules: 규칙 위반 시 알림 또는 자동 수정
  • 규정 준수 감사에 핵심

Config Rule 예시

규칙: S3 버킷 퍼블릭 접근 차단 여부
  → 위반 탐지 → SNS 알림 or Auto-Remediation (Lambda)

5. 멀티 계정 보안 거버넌스

AWS Organizations 구조

Management Account (관리 계정)
  └── Root
        ├── OU: 보안
        │     ├── Log Archive 계정 (모든 로그 중앙 수집)
        │     └── Security Tooling 계정 (GuardDuty, Security Hub 위임)
        ├── OU: 운영
        │     ├── Production 계정
        │     └── Staging 계정
        └── OU: 개발
              └── Dev 계정들

AWS Control Tower

  • Organizations 기반 멀티 계정 환경 자동 설정
  • 보안, 로깅, 감사 계정 자동 생성
  • Guardrails: 필수(Mandatory) / 강력 권장(Strongly Recommended) 규칙
  • Landing Zone: 모범 사례 기반 계정 구조 자동 구성

중앙 집중형 로깅

모든 계정 CloudTrail
  → S3 (Log Archive 계정)
    → S3 Object Lock (위변조 방지)
      → Athena로 분석
  • CloudTrail 조직 추적(Organization Trail): 모든 계정 로그를 단일 S3에 수집
  • Log Archive 계정의 S3는 다른 계정에서 삭제 불가 (SCP로 보호)

GuardDuty 위임 관리자

Security Tooling 계정 → GuardDuty 위임 관리자
  → 전체 조직의 GuardDuty 결과 중앙 수집
  → 새 계정 자동 GuardDuty 활성화

6. SAP 시나리오별 보안 선택 가이드

패턴 1: 특정 리전 외 서비스 사용 차단

Organizations SCP → 특정 리전 외 모든 액션 Deny

패턴 2: 개발팀에게 IAM 역할 생성 위임, 단 과도한 권한 방지

Permission Boundary 설정 후 IAM 위임

패턴 3: 타 계정의 EC2가 우리 S3에 접근

Cross-Account IAM Role (AssumeRole) + S3 버킷 정책

패턴 4: DB 비밀번호 90일마다 자동 변경

Secrets Manager 자동 교체

패턴 5: 애플리케이션 설정값 + 비용 최소화

SSM Parameter Store Standard (무료)

패턴 6: EC2에서 비트코인 마이닝 의심 트래픽 탐지

GuardDuty → EventBridge → Lambda (EC2 격리)

패턴 7: S3에 개인정보 저장 여부 자동 감사

Amazon Macie

패턴 8: 전체 계정 보안 컴플라이언스 대시보드

Security Hub + Organizations 연동

패턴 9: 온프레미스 AD로 AWS 콘솔 로그인

IAM Identity Center (SSO) + AD Connector 또는 AWS Managed Microsoft AD

패턴 10: FIPS 140-2 Level 3 키 관리

CloudHSM

7. 핵심 암기 포인트

키워드 선택
계정 전체 권한 상한 SCP (Organizations)
IAM 사용자/역할 권한 상한 Permission Boundary
명시적 Deny 우선순위 항상 최우선 (SCP, IAM 무관)
타 계정 리소스 접근 Cross-Account IAM Role
타 계정 역할 신뢰 추가 검증 ExternalId
봉투 암호화 KMS CMK → DEK 생성 → DEK로 데이터 암호화
키를 AWS에 맡길 수 없음 CloudHSM
DB 비밀번호 자동 교체 Secrets Manager
앱 설정, 비용 절감 Parameter Store
런타임 위협 탐지 GuardDuty
CVE 취약점 스캔 Inspector
PII 탐지 Macie
보안 결과 통합 대시보드 Security Hub
리소스 설정 변경 감사 AWS Config
멀티 계정 자동 구성 Control Tower
전체 계정 로그 중앙 수집 CloudTrail Organization Trail

핵심 내용을 다시 정리하면

  • IAM 정책 평가: Deny > SCP > Permission Boundary > IAM 정책 순
  • SCP: 계정/OU 전체 권한 상한 (관리 계정에는 미적용)
  • KMS: 봉투 암호화, CMK로 감사·교체 제어
  • Secrets Manager: DB 비밀번호 자동 교체 / Parameter Store: 설정값 무료 저장
  • GuardDuty: 위협 탐지 / Inspector: 취약점 / Macie: PII / Security Hub: 통합
  • Control Tower + SCP + Organization Trail: 멀티 계정 거버넌스 3종 세트

이어 읽기: 10. 관측·감사·운영 자동화