보안 서비스
GuardDuty → 이상한 행동 탐지 (위협 감지)
Inspector → 취약점 스캔 (소프트웨어 보안)
Macie → 민감 데이터 탐지 (S3 개인정보)
Security Hub → 모든 보안 결과 통합 (중앙 관제)
Amazon GuardDuty
GuardDuty는 AWS 계정, 워크로드, 런타임 활동, 데이터에서 악성 활동을 지속적으로 모니터링한다. 위협 인텔리전스 피드, 악성 IP/도메인 목록, ML 모델을 사용해 의심스럽고 잠재적으로 악의적인 활동을 식별한다.
•
분석 소스:
◦
CloudTrail 관리 이벤트
→ 의심스러운 API 호출, 권한 상승 시도 탐지
◦
VPC Flow Logs
→ 비정상적 네트워크 트래픽, 데이터 유출 시도
◦
DNS Logs
→ 악성 도메인 쿼리, C&C 서버 통신 탐지
◦
EKS Audit Logs, RDS 로그인 활동 (추가 활성화)
•
탐지 예시
◦
비정상적 리전에서 EC2 인스턴스 대량 생성
◦
IAM 자격증명 유출 후 권한 남용
◦
암호화폐 채굴 (Cryptomining) 활동
◦
S3 버킷 대용량 다운로드 (데이터 유출)
◦
루트 계정 비정상 사용
•
자동화 패턴
◦
GuardDuty Finding → EventBridge → Lambda (자동 격리)
◦
GuardDuty Finding → Security Hub (중앙 집계)
◦
Finding 보존: 90일 (장기 보존 → S3 + EventBridge)
계정 침해 탐지, 비정상 API 호출 감지 → GuardDuty
Agent 설치 불필요, 활성화만 하면 즉시 동작
Amazon Inspector
AWS 워크로드의 소프트웨어 취약점과 의도하지 않은 네트워크 노출을 자동으로 스캔
•
스캔 대상
◦
EC2 인스턴스 (OS 취약점, CVE)
◦
ECR 컨테이너 이미지 (Docker 이미지 취약점)
◦
Lambda 함수 (코드 취약점)
•
특징
◦
자동 지속 스캔 (새 인스턴스 시작 시 자동)
◦
CVE(Common Vulnerabilities and Exposures) 데이터베이스 기반
◦
네트워크 도달성 분석 (퍼블릭 접근 가능 여부)
◦
Finding → Security Hub 전달
•
Inspector vs GuardDuty
◦
Inspector → “이 EC2에 패치되지 않은 취약점이 있다”
◦
GuardDuty → “이 EC2가 악성 행동을 하고 있다”
EC2/컨테이너 CVE 취약점 자동 탐지 → Inspector
CI/CD 파이프라인에서 컨테이너 이미지 배포 전 스캔에 활용
Amazon Macie
S3 버킷에서 민감한 데이터를 자동 탐지
ML + 패턴 매칭 사용
•
탐지 데이터 유형
◦
PII (개인식별정보): 이름, 주민번호, 신용카드
◦
PHI (의료정보): 환자 데이터
◦
AWS 자격증명: API 키, 시크릿 키
◦
재무 데이터: 계좌번호
•
Finding 유형
◦
Policy Finding
▪
S3 버킷 설정 문제 탐지
▪
예: 퍼블릭 접근 활성화, 암호화 비활성화
◦
Sensitive Data Finding
▪
실제 민감 데이터 포함 여부 탐지
•
활용 패턴
◦
Macie Finding → EventBridge → Lambda → S3 버킷 격리
◦
Macie Finding → Security Hub 통합
S3 버킷에 개인정보가 있는지 자동 탐지 → Macie
GuardDuty와 혼동 주의: GuardDuty는 행동 이상 탐지, Macie는 데이터 내용 탐지
AWS Security Hub
Security Hub는 GuardDuty, Inspector, Macie, Config, Firewall Manager 등 여러 AWS 보안 서비스의 보안 결과를 집계•우선순위화하는 통합 보안 관제 서비스이다.
Security Hub = 보안 결과의 “단일 창구”
•
통합 소스
◦
GuardDuty, Inspector, Macie, Config
◦
Firewall Manager, IAM Access Analyzer
◦
서드파티 파트너 솔루션
•
핵심 기능
◦
AWS Security Findings Format (ASFF)
▪
모든 서비스 결과를 표준 형식으로 정규화
◦
규정 준수 체크
▪
CIS AWS Foundations Benchmark
▪
PCI DSS, HIPAA, NIST 표준 자동 점검
◦
크로스 계정/리전 집계
▪
Organizations와 통합 → 전체 계정 보안 현황 통합 뷰
◦
자동 대응
▪
Security Hub Finding → EventBridge → Lambda
•
Organizations 연동:
◦
Management Account에서 전체 계정 Security Hub 활성화
→ Delegated Administrator 계정 지정 (보안 전용 계정)
서비스 | 역할 | 대상 | 에이전트 |
GuardDuty | 위협 탐지 (행동 이상) | 계정·네트워크·데이터 | 불필요 |
Inspector | 취약점 스캔 (CVE) | EC2·ECR·Lambda | 불필요 (자동) |
Macie | 민감 데이터 탐지 | S3 버킷 | 불필요 |
Security Hub | 보안 결과 통합 집계 | 모든 AWS 계정 | 불필요 |
Amazon Detective
•
GuardDuty Finding 발생 후 “왜 발생했는지” 근본 원인 조사
Security Hub → Finding 감지
Detective → 근본 원인 분석 (포렌식)
•
데이터 소스:
◦
VPC Flow Logs, CloudTrail, GuardDuty Findings
◦
자동 수집 후 그래프 모델로 시각화
•
활용 예시
◦
“어떤 IP에서 어떤 경로로 침입했나”
◦
“이 IAM 사용자가 최근 어떤 행동을 했나”
GuardDuty Finding의 근본 원인 조사 → Detective
GuardDuty가 “발견”하면 Detective가 “조사”한다
Well-Architected Framework 6 Pillars
SAP에서 Well-Architected 원칙에 기반한 문제가 자주 출제됨
6 Pillars (암기)
1.
Operational Excellence (운영 우수성)
•
핵심: 운영을 코드로 (IaC), 자동화, 지속적 개선
•
도구: CloudFormation, Systems Manager, CodePipeline
2.
Security (보안)
•
핵심: 최소 권한, 전송•저장 암호화, 추적성
•
도구: IAM, KMS, CloudTrail, GuardDuty, Security Hub
3.
Reliability (신뢰성)
•
핵심: 장애 자동 복구, 수평 확장, 변경 관리
•
도구: Auto Scaling, Multi-AZ, Route 53 Failover
4.
Performance Efficiency (성능 효율성)
a.
핵심: 적합한 리소스 선택, 글로벌 배포, 서버리스
•
도구: CloudFront, Lambda, ElastiCache, DAX
5.
Cost Optimization (비용 최적화)
a.
핵심: 사용한 만큼 지불, 불필요 리소스 제거
•
도구: Cost Explorer, Trusted Advisor, Compute Optimizer
6.
Sustainability (지속 가능성)
a.
핵심: 환경 영향 최소화, 리소스 효율화
•
도구: Graviton Instance, Serverless, 최적화된 코드
다음 중 Well-Architecte 보안 기둥(pillar) 원칙에 맞는 것은? → 최소 권한, 계층적 방어, 암호화, 추적성 중 선택
위와 같은 문제의 패턴이 출제됨
SCP 고급 패턴
자주 출제되는 SCP 패턴
1.
특정 리전 외 리소스 생성 금지
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": ["ap-northeast-2"]
}
}
}
JSON
복사
→ 예외: 글로벌 서비스(IAM, CloudFront, Route 53)는 aws:RequestedRegion 조건에서 제외 필요
2.
루트 계정 사용 금지
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": {
"aws:PrincipalArn": "arn:aws:iam::*:root"
}
}
}
JSON
복사
3.
태그 없는 리소스 생성 금지
•
aws:RequestTag 조건으로 필수 태그 강제
4.
MFA 없이 중요 작업 금지
•
aws:MultiFactorAuthPresent: false → Deny
SCP Deny List vs Allow List 전략
•
Deny List (기본 전략):
◦
FullAWSAccess 유지 + 특정 작업만 Deny 추가
→ 새 서비스 자동 허용
→ 운영 편의성 ↑
•
Allow List 전략
◦
FullAWSAccess 제거 + 허용 서비스만 명시
→ 새 서비스 자동 차단
→ 보안 강도 ↑, 운영 복잡도 ↑
→ 엄격한 규정 환경에 적합
ABAC (Attribute-Based Access Control)
ABAC
•
기존 RBAC (역할 기반)
◦
팀마다 별도 IAM 정책 생성
▪
개발팀 정책, 운영팀 정책, 보안팀 정책, …
→ 팀/서비스 증가 시 정책 폭발적 증가
•
ABAC (속성 기반)
◦
태그 기반으로 권한 자동 매핑
◦
예시
▪
IAM 사용자 태그: team=backend
▪
리소스 태그: team=backend
▪
정책: “리소스 태그 = 사용자 태그인 경우만 허용”
•
핵심 조건
◦
aws:ResourceTag/team: ${aws:PrincipalTag/team}
→ “리소스의 team 태그 = 요청자의 team 태그”
팀 수 증가에 따른 IAM 정책 관리 복잡도 감소 → ABAC + 태그 기반 접근 제어
AWS Trusted Advisor
•
점검 영역
1.
비용 최적화(Cost optimization) → 미사용 리소스, RI 최적화
2.
성능(Performance) → 과부화 인스턴스, CloudFront 설정
3.
보안(Security) → MFA 미설정, 퍼블릭 S3 버킷
4.
내결함성(Fault tolerance) → RDS Multi-AZ, EBS 스냅샷
5.
서비스 한도(Service limits) → 한도 근접 리소스 경고
6.
운영 우수성(Operational Exellence) → 운영 모범사례, 자동화 권고
•
플랜별 접근
◦
Basic/Developer → 핵심 보안•한도 점검만
◦
Business/Enterprise → 전체 점검 + API 접근
•
Organizations 연동
◦
Management Account → 전체 조직 Trusted Advisor 통합 뷰
Summary
개념 | 한 줄 요약 |
GuardDuty | 행동 이상 탐지. CloudTrail+VPC+DNS 분석. 에이전트 불필요 |
Inspector | EC2·ECR·Lambda CVE 취약점 자동 스캔 |
Macie | S3 민감 데이터(PII) 탐지. ML 기반 |
Security Hub | 모든 보안 결과 통합. CIS/PCI 준수 체크 |
Detective | GuardDuty Finding 근본 원인 조사 (포렌식) |
GuardDuty → Detective | "탐지" → "조사" 순서 |
SCP Deny List | FullAWSAccess + 특정 Deny. 기본 전략 |
SCP Allow List | 허용 서비스만 명시. 엄격한 보안 |
ABAC | 태그 기반 접근 제어. 정책 수 최소화 |
Well-Architected 6기둥 | 운영·보안·안정성·성능·비용·지속가능성 |
다음 게시물