AWS Certified CloudOps Engineer - Associate (SOA-C03) #13 Domain 5-2 보안: Config,CloudTrail,GuardDuty,Security Hub,KMS
#12에서 신원과 거버넌스를 잡았다면, 이 글은 무슨 일이 있었는지 추적하고(감사), 잘못된 상태를 탐지,교정하고, 데이터를 암호화하는 운영 도구를 다룹니다. 보안 도메인의 핵심 서비스가 여기 모여 있고, 이름이 비슷해 헷갈리기 쉬우므로 각자 무엇을 보는지로 구분하는 것이 시험 포인트입니다.
네 서비스의 역할 구분 #
먼저 큰 그림부터 잡겠습니다. 헷갈림의 절반은 이 넷의 경계를 흐릿하게 알아서 생깁니다.
| 서비스 | 보는 것 | 한 줄로 |
|---|---|---|
| CloudTrail | 누가 어떤 API를 호출했는가 | 행위 기록(감사 로그) |
| Config | 자원이 어떤 구성이고 규칙을 지키는가 | 구성 상태,준수 |
| GuardDuty | 악성,이상 행위가 있는가 | 위협 탐지 |
| Security Hub | 위 결과를 모은 보안 점수 | 통합 대시보드 |
CloudTrail: API 감사 #
계정에서 일어나는 모든 API 호출을 기록합니다. 누가(주체), 언제, 무엇을(액션), 어디서(소스 IP) 했는지 남깁니다.
- 관리 이벤트: 리소스 생성,삭제,설정 변경 등. 기본 기록
- 데이터 이벤트: S3 객체 읽기,쓰기, Lambda 실행 등 고볼륨. 기본 비활성(별도 설정)
- 조직 추적(Organization Trail): 전 계정의 이벤트를 한 곳에 수집
- 로그 무결성: 로그 파일 검증(integrity validation)으로 변조 탐지
- CloudTrail 로그를 CloudWatch Logs로 보내 지표 필터,알람(#3)을 걸어 실시간 경보
“누가 이 리소스를 지웠는지 추적하라"는 답이 CloudTrail입니다. “루트 로그인,권한 변경 시 즉시 알림"은 CloudTrail → CloudWatch Logs → 알람입니다.
AWS Config: 구성 준수 #
Config는 자원의 구성을 시간에 따라 기록하고, 규칙(Rule)으로 준수 여부를 평가합니다.
| 기능 | 설명 |
|---|---|
| Configuration Recorder | 자원 구성 변경을 지속 기록(타임라인) |
| Config Rule | “S3는 암호화돼야 한다” 같은 규칙으로 준수 평가 |
| Remediation | 위반을 SSM Automation으로 자동 교정 |
| Conformance Pack | 규칙 묶음을 표준으로 일괄 배포 |
CloudTrail과의 차이가 핵심입니다. CloudTrail은 행위(누가 호출했나), Config는 상태(지금 구성이 규칙에 맞나)를 봅니다. “암호화 안 된 볼륨을 찾아 자동으로 교정하라"는 답이 Config Rule + 자동 교정입니다. “구성이 언제 어떻게 바뀌었는지 이력을 보라"도 Config입니다.
GuardDuty: 위협 탐지 #
GuardDuty는 CloudTrail,VPC Flow Logs,DNS 로그를 머신러닝으로 분석해 위협을 탐지합니다. 로그를 직접 켜거나 관리할 필요 없이, 켜기만 하면 동작합니다.
- 비정상 API 호출, 알려진 악성 IP와의 통신, 암호화폐 채굴, 자격 증명 유출 징후 등 탐지
- 결과(Finding)를 EventBridge로 받아 자동 대응(격리,알림) 연결
- 멀티계정은 위임 관리자로 전 계정 통합
“침해 징후,악성 활동을 자동 탐지하라"의 답이 GuardDuty입니다. Config(준수),CloudTrail(기록)과 달리 능동적 위협 탐지라는 점이 구분선입니다.
Security Hub: 통합 보안 관리 #
여러 보안 서비스(GuardDuty,Inspector,Macie,Config)의 결과를 한 곳에 모아 표준화하고 점수화합니다.
- CIS,AWS 모범 사례 같은 보안 기준(standard)에 대한 준수 점수
- 전 계정의 보안 결과를 통합 대시보드로
- 결과를 EventBridge로 받아 자동 대응
“여러 보안 서비스 결과를 한 화면에서 보고 모범 사례 준수를 점검하라"의 답이 Security Hub입니다.
함께 묶이는 보조 도구 #
| 서비스 | 탐지 대상 |
|---|---|
| Inspector | EC2,컨테이너,Lambda의 소프트웨어 취약점(CVE) 자동 스캔 |
| Macie | S3의 민감 데이터(개인정보) 탐지 |
“S3에 개인정보가 있는지 탐지"는 Macie, “인스턴스,이미지의 취약점 스캔"은 Inspector입니다. #9의 ECR 스캔과 함께 취약점 운영의 축입니다.
KMS: 암호화 운영 #
데이터 암호화의 중심입니다. 운영 포인트만 정리하겠습니다.
| 키 종류 | 관리 주체 |
|---|---|
| AWS 관리형 키 | AWS가 관리. 자동 교체 |
| 고객 관리형 키(CMK) | 사용자가 정책,교체,삭제 통제 |
- 키 정책(Key Policy): 키에 누가 접근하는지 정의. 교차 계정 키 공유의 핵심
- 자동 교체: 고객 관리형 키도 연 1회 자동 교체 설정 가능
- 봉투 암호화: 데이터 키로 데이터를, KMS 키로 데이터 키를 암호화
- S3,EBS,RDS 등은 저장 시 암호화(at rest)에 KMS 키 지정
“암호화 키를 직접 통제하고 교차 계정으로 공유하라"는 답이 고객 관리형 키 + 키 정책입니다.
시험 출제 패턴 #
- 누가 리소스를 지웠나 → CloudTrail
- 구성이 규칙에 맞나 / 자동 교정 → Config Rule + Remediation(SSM)
- 악성,이상 행위 자동 탐지 → GuardDuty
- 여러 보안 결과 통합,점수 → Security Hub
- EC2,이미지 취약점 스캔 → Inspector
- S3 민감 데이터 탐지 → Macie
- 암호화 키 직접 통제,교차 계정 → KMS 고객 관리형 키 + 키 정책
자주 만나는 함정 #
1) CloudTrail과 Config를 혼동 #
CloudTrail은 행위(API 호출), Config는 상태(구성 준수)입니다. “누가 바꿨나"는 CloudTrail, “지금 규칙에 맞나"는 Config입니다.
2) GuardDuty가 로그 설정을 요구한다고 생각 #
GuardDuty는 소스 로그를 직접 켤 필요 없이 분석합니다. 활성화만 하면 됩니다.
3) S3 데이터 이벤트가 기본 기록된다고 가정 #
CloudTrail은 기본적으로 관리 이벤트만 기록합니다. S3 객체 수준 데이터 이벤트는 별도로 켜야 합니다.
4) Security Hub가 직접 탐지한다고 오해 #
Security Hub는 탐지기가 아니라 취합,표준화,점수화입니다. 실제 탐지는 GuardDuty,Inspector,Config 등이 합니다.
정리 #
이번 글에서 잡은 것:
- 네 서비스의 경계: CloudTrail(행위 기록),Config(구성 준수),GuardDuty(위협 탐지),Security Hub(통합 점수)
- CloudTrail은 관리/데이터 이벤트, 조직 추적, 무결성 검증. CloudWatch Logs 연동으로 실시간 알람
- Config는 구성 타임라인 + 규칙 + SSM 자동 교정 + Conformance Pack
- GuardDuty는 로그 설정 없이 능동 위협 탐지, EventBridge로 자동 대응
- Inspector(취약점),Macie(S3 민감 데이터)가 보조 축
- KMS 고객 관리형 키 + 키 정책으로 암호화 통제,교차 계정 공유
다음: 시험 팁과 자주 틀리는 패턴 #
다섯 도메인을 모두 마쳤습니다. 다음은 시험 직전 정리입니다.
#14 시험 팁과 자주 틀리는 운영 시나리오 패턴에서는 도메인을 가로지르는 단골 함정, 비슷한 서비스를 가르는 키워드, 시간 배분과 문항 읽는 법, 그리고 마지막 점검 목록까지 정리하겠습니다.