[security] AWS Config

One-Line Summary

AWS Config는 AWS 리소스의 구성(설정)을 지속적으로 기록하고, 그 설정이 규칙(rule)을 지키는지 평가하는 서비스다. "지금 이 리소스가 규정을 지키나?"와 "이 설정이 언제·무엇에서·무엇으로 바뀌었나?"에 답한다. 위반 시 알림·자동 교정(remediation)까지 이어붙일 수 있다. 시험에서는 구성 준수(compliance)·변경 이력 = Config / CloudTrail과의 차이 / 자동 remediation / 조직·멀티리전 집계(Aggregator·Conformance Pack) 가 핵심이다.

뭔지 (What / Why)

클라우드는 설정이 수시로 바뀐다 — 누군가 S3 버킷을 퍼블릭으로 바꾸거나, SG에 0.0.0.0/0 SSH를 열거나, EBS 암호화를 끈다. 사고는 대부분 잘못된 구성에서 온다. 규정(감사)도 "모든 볼륨은 암호화" 같은 상태 유지를 요구한다.

AWS Config는 리소스의 구성 스냅샷을 시간순으로 기록하고, 정의한 규칙에 맞는지 계속 평가한다. 그래서 세 가지를 준다: ① 현재 준수 상태 ② 변경 이력(누가·언제·어떻게) ③ 위반 시 자동 대응.

리소스 설정 변경 발생
   │  (Config가 구성 항목=Configuration Item 기록)
   ▼
[AWS Config]  ── 규칙 평가 ──▶ COMPLIANT / NONCOMPLIANT
   │                                │
   ▼                                ▼
변경 이력·타임라인          EventBridge/SNS 알림 · SSM Automation 자동 교정

핵심 구성 요소

요소	의미
Configuration Recorder	리소스 구성 변경을 감지·기록하는 엔진(리전별로 켬)
Configuration Item (CI)	특정 시점의 리소스 구성 스냅샷(관계·메타 포함)
Config Rule	준수 여부 판단 기준. AWS managed 또는 custom(Lambda)
Remediation	위반 리소스를 SSM Automation으로 자동 교정
Conformance Pack	규칙 + remediation을 묶음(팩)으로 배포(규정 템플릿)
Aggregator	여러 계정·리전의 Config 데이터를 한 곳에 집계

Config Rule 예시 (managed)

s3-bucket-public-read-prohibited — 퍼블릭 읽기 금지
encrypted-volumes — EBS 볼륨 암호화 여부
restricted-ssh — SG가 SSH를 전 세계에 열었는지
rds-storage-encrypted, iam-password-policy 등

자동 교정 (Remediation) — 빈출

규칙 위반을 감지에서 끝내지 않고 자동으로 고친다. Remediation은 SSM Automation 문서로 실행된다.

NONCOMPLIANT 감지
   → 자동 remediation: SSM Automation 실행
      예) 퍼블릭 S3 → 퍼블릭 액세스 차단
          암호화 안 된 리소스 → 태그·격리·교정
   또는 EventBridge → Lambda/SNS로 커스텀 대응·알림

시험 트리거: "비준수 리소스를 자동으로 교정" → Config Rule + SSM Automation remediation.

CloudTrail vs Config (반드시 구분 — 단골)

둘 다 "기록"이라 헷갈리지만 보는 관점이 다르다.

	AWS Config	CloudTrail
답하는 질문	"리소스 상태(설정)가 지금 어떻고, 규정을 지키나?"	"누가 언제 어떤 API를 호출했나?"
관점	리소스의 구성·준수	계정의 행위(활동) 감사
예	"이 SG 설정이 규칙 위반인가"	"누가 이 SG를 바꿨나"
시간축	구성의 상태 변화 타임라인	API 이벤트 로그

함께 쓰면 강력: Config가 "설정이 위반됐다"를 잡고, CloudTrail이 "누가 그렇게 바꿨는지"를 짚는다. "설정 준수/변경 상태" = Config, "누가 무엇을 했나" = CloudTrail.

조직·멀티리전 집계

도구	용도
Aggregator	여러 계정·리전의 준수 상태를 단일 뷰로 집계(Organizations 연동)
Conformance Pack	규칙+remediation 묶음을 조직 전반에 일괄 배포(예: PCI, 보안 기준선)

대규모 환경: "모든 계정·리전에서 암호화·퍼블릭 금지 기준을 강제·집계" → Conformance Pack + Aggregator.

실무 활용 사례

사례 1. 규정 준수 상시 감사

encrypted-volumes, s3-bucket-public-read-prohibited 등으로 준수 상태를 지속 평가 → 감사 증빙.

사례 2. 위험 설정 자동 교정

퍼블릭 S3·개방 SSH 감지 → SSM Automation으로 자동 차단.

사례 3. 변경 원인 추적

장애·사고 시 Config 타임라인으로 "언제 이 설정이 바뀌었나" 확인 + CloudTrail로 "누가" 확인.

사례 4. 조직 기준선 강제

Conformance Pack을 전 계정에 배포, Aggregator로 비준수 계정 한눈에.

Common Wrong Directions

오답 방향	왜 부족한가
"누가 API를 호출했나"에 Config	그건 CloudTrail
Config가 위협·악성 활동을 탐지한다고 봄	그건 GuardDuty (Config는 구성 준수)
위반을 감지만 하고 못 고친다고 봄	SSM Automation remediation으로 자동 교정
계정·리전마다 따로 확인	Aggregator로 집계
규칙을 하나씩 수동 배포	Conformance Pack으로 묶음 배포
취약점(CVE) 점검에 Config	그건 Inspector

Exam Triggers

문제에서 이런 표현이 나오면	떠올릴 것
"assess resource configuration compliance"	AWS Config
"track configuration changes over time"	AWS Config
"automatically remediate noncompliant resources"	Config Rule + SSM Automation
"detect S3 made public / SSH open to world"	Config managed rule
"who made this API call / change"	CloudTrail (Config 아님)
"enforce & aggregate compliance across accounts/regions"	Conformance Pack + Aggregator

Memory Sentence

Config는 리소스 구성을 기록하고 규칙으로 준수 여부를 평가한다(상태 관점). 위반은 SSM Automation으로 자동 교정하고, 조직 전반은 Conformance Pack+Aggregator로 강제·집계한다. "설정 준수/변경 상태"는 Config, "누가 무엇을 했나"는 CloudTrail, 위협 탐지는 GuardDuty, 취약점은 Inspector.