이번 주차는 위협 유형 → 실제 사고 사례 → AWS Config 자동 탐지 데모 순서로 진행했다.
1. 클라우드 보안 위협 유형
온프레미스는 물리적 보안·망 분리로 기본 격리가 된다. 반면 클라우드는 논리적 격리 기반이라 설정 오류나 서비스 취약점이 곧바로 위협이 된다. 멀티 테넌트 환경이라 hypervisor 취약점이나 container 격리 실패가 다른 고객 정보까지 영향을 줄 수 있는 구조다.
Cloud Security Alliance 보고서 기준 클라우드 보안 사고의 60% 이상이 misconfiguration에서 기인한다. 주요 원인은 크게 두 가지다.
Misconfiguration — S3 버킷 공개, 과도한 IAM 권한 부여
Credential Compromise — Access Key 유출, 약한 비밀번호
대표 위협 6종
유형
핵심
주요 대응
Account Hijacking
정상 계정 탈취 후 리소스 악용
MFA, 최소 권한, Access Key rotation
Misconfiguration
잘못된 설정으로 취약점 발생 (1위 위협)
AWS Config, Security Hub
Data Leakage/Breach
민감 데이터 외부 유출
S3 Block Public Access, 암호화
Malicious Insiders
내부자의 의도적/비의도적 권한 남용
CloudTrail, GuardDuty, EventBridge
DoS/DDoS
대규모 트래픽으로 서비스 불가
AWS Shield, WAF Rate-based Rule, ALB
Unsafe Interfaces/API
인증·검증 없는 API
IAM 최소 권한, WAF, Throttling
Unsafe Interfaces/API가 특히 와닿았다. 클라우드 서비스는 콘솔·CLI·SDK 전부 결국 API 호출로 동작한다. API가 리소스의 "문"이자 "열쇠"인 셈이라, 인증 우회(API 키 노출)·권한 오용·Injection·평문 전송·Rate Limit 미비 같은 시나리오가 그대로 사고로 이어진다.
대표 사례가 2019년 Capital One 사고다. 잘못된 API 권한 설정 + SSRF 취약점이 겹쳐 1억 명 이상의 개인정보가 유출됐다.
💡 개념 정리 중 느낀 점
온프레미스 사고는 "뚫렸다"가 많은데, 클라우드 사고는 "열어놨다"가 많다. 공격자가 침투한 게 아니라 설정으로 문을 활짝 열어둔 상태가 대부분이라는 게 핵심 차이다.
misconfiguration이 1위 위협이라는 건, 보안의 무게추가 침입 차단보다 설정 검증 자동화로 옮겨갔다는 뜻이다. 사람이 매번 체크하는 구조로는 못 막는다.
Capital One 사례에서 SSRF 단독이 아니라 "과도한 IAM 권한"이 피해를 키웠다는 점이 중요하다. 취약점은 trigger고, 권한 설계가 blast radius를 결정한다.
2. 기본 보안 대응 전략
보안은 한 번의 설정이 아니라 지속적인 프로세스다. 3대 원칙으로 정리된다.
Prevent — 설정 오류 방지, 취약점 제거
Detect — 비정상 행위·위협 조기 발견
Respond — 자동화된 조치 및 복구
접근 제어 & 최소 권한
IAM Root User는 액세스 키를 삭제하고 일상 작업에 쓰지 않는다. MFA 필수.
사용자·그룹·역할(Role) 구조로 권한을 관리한다.
최소 권한 원칙(Least Privilege): 업무에 필요한 최소 권한만 부여. IAM 정책은 허용(Allow) 중심이 아니라 기본 거부(Deny) 기반.
Access Key는 불필요한 것 삭제 + 주기적 rotation.
로깅 & 모니터링
CloudTrail — API 호출 이력 추적
CloudWatch — 지표·로그 모니터링
GuardDuty — ML 기반 위협 탐지
로그는 중앙화 저장 + 장기 보관
보안 자동화
AWS Config — 리소스 변경 추적 및 규정 준수 검사
Security Hub — 보안 현황 중앙 관리
EventBridge + Lambda — 자동 대응 (예: 비정상 접근 시 보안 그룹 수정)
💡 대응 전략 정리 중 느낀 점
Prevent에만 의존하면 한 번 뚫렸을 때 무방비다. Detect와 Respond까지 묶여야 실제로 막힌다. 3대 원칙이 별개가 아니라 파이프라인이라는 관점이 맞다.
"Root User로 일상 작업 금지"가 교과서 문구처럼 보이지만, 뒤에 나올 Code Spaces 사례를 보면 이게 회사 폐업까지 가는 분기점이었다.
Deny 기반 정책이 운영상 더 안전하다. Allow를 빠뜨리면 기능이 안 되니 바로 발견되지만, Deny를 빠뜨리면 조용히 권한이 새는 쪽이라 발견이 늦다.
3. 실무 보안 사고 사례 분석
사례 A — S3 버킷 공개로 인한 데이터 유출
실제로 2022년 콜롬비아·페루 공항 4곳의 민감 정보 3TB가 S3 설정 오류로 유출됐고, 2017년엔 미 육군·NSA 기밀 문서가 안전하지 않은 S3 버킷에서 노출된 적이 있다.
가상 시나리오: 리테일 기업이 마케팅 자료와 고객 개인정보를 S3에 저장하면서, 개발 과정에서 퍼블릭 접근 허용을 체크한 상태로 운영에 그대로 반영했다.
사고 원인: S3 Block Public Access 비활성화, 버킷 Public Read 허용, 접근 로그 미수집으로 유출 시점 파악 지연
영향: 고객 이름·이메일·결제 내역 수십만 건 노출, 개인정보보호법 위반 제재 + 브랜드 신뢰 하락
대응: 즉시 비공개 전환 → 유출 범위 확인 및 고객 통지 → CloudTrail 로그로 유출 경로 조사
예방: S3 Block Public Access 기본 활성화, IAM 정책으로 접근 최소화, S3 Access Analyzer로 퍼블릭 리소스 사전 탐지, 저장 데이터 암호화(SSE)
사례 B — 루트 계정 탈취
Code Spaces (2014): 공격자가 Access Key로 AWS 콘솔에 로그인해 S3·EC2·AMI·EBS 스냅샷을 무차별 삭제했다. 서비스가 즉시 중단됐고 회사는 결국 폐쇄됐다.
Uber (2014): S3에 저장된 데이터 분석 스크립트에 AWS 자격 증명이 포함돼 있었고, 이게 유출되며 약 5만 건의 민감 정보가 공개됐다.
사고 원인: 루트 유저 MFA 미적용, 루트 유저로 일상 작업 수행, Access Key를 GitHub에 실수로 업로드, 루트 자격 증명을 공유 계정처럼 사용하는 잘못된 문화
영향: 신규 EC2 대량 생성 → 암호화폐 채굴, 수천 달러 요금 발생, 일부 S3 데이터 삭제
대응: 루트 비밀번호 변경 + Access Key 회수, 보안 그룹 차단 및 인스턴스 종료
예방: 루트 계정은 최초 설정·결제 관리에만 사용 + MFA 필수, Access Key 절대 공유 금지, AWS Organizations로 계정 분리 운영, 정기 점검과 모니터링
사례 C — 과도한 IAM 권한으로 인한 내부 위협
Capital One (2019): 외부 공격자가 AWS 권한을 이용해 1억 건 이상의 고객 정보에 접근. 과도한 권한이 피해를 키웠다. 내부자가 아니어도 계정 탈취 상황에서 과도한 권한이 심각한 피해의 기반이 된다는 걸 보여준다.
Mandiant/Tesla (2018, 2020): 해고된 내부 직원이 AWS 자격 증명으로 CI/CD 서버에 접근해 신규 사용자를 만들고 프로덕션 DB를 삭제한 사례. 단순 오용이 아니라 내부자 권한이 악의적으로 핵심 시스템에 쓰인 전형적 케이스다.
가상 시나리오: SaaS 기업 운영팀 직원이 IAM Admin 권한을 받았고, 퇴사 직전 개인적 불만으로 S3 데이터를 삭제
사고 원인: 최소 권한 원칙 미적용, Role 기반이 아닌 IAM 사용자에 직접 Admin 권한 부여, CloudTrail 알림 규칙 미설정
대응: CloudTrail로 삭제 리소스·시점·호출 계정 추적 → 백업 데이터 복원 → IAM 정책 재검토 및 불필요 권한 즉시 비활성화 → EventBridge+SNS로 고위험 이벤트(DeleteBucket, DeleteDB 등) 알림 활성화
예방: Role 기반 권한 설계, 필요 권한만 최소 부여, 퇴직·이동 시 계정 비활성화 즉시 실행, CloudTrail+SNS 실시간 모니터링, 백업의 물리적/논리적 분리(다른 계정·다른 리전 저장)
💡 사례 분석 중 느낀 점
세 사례 전부 "권한"과 "백업"으로 수렴한다. Code Spaces가 죽은 건 백업까지 같은 계정에 있어서였다. 백업을 다른 계정·다른 리전에 두는 게 단순 권장이 아니라 생존 조건이다.
Access Key를 코드/스크립트에 하드코딩하다 GitHub에 올라가는 패턴이 Uber·루트 탈취 사례에 공통으로 나온다. 실무에선 git-secrets, gitleaks 같은 pre-commit 훅으로 커밋 단계에서 막는 게 현실적이다. 사람이 조심하는 걸로는 반복된다.
내부자 위협(사례 C)은 외부 침입과 달리 "정상 권한의 오용"이라 차단이 어렵다. 결국 탐지(CloudTrail) + 퇴사 프로세스 자동화(권한 즉시 회수)로 풀어야 한다. 방화벽으로 막는 문제가 아니다.
DeleteBucket·DeleteDB 같은 파괴적 API에만 SNS 알림을 거는 접근이 실용적이다. 모든 API에 알림 걸면 노이즈에 묻혀서 정작 중요한 이벤트를 놓친다.
4. AWS 기본 보안 서비스
데모 전에 이번 주차에서 다룬 보안 서비스들을 한 번 정리했다.
서비스
역할
IAM
리소스 접근 권한 제어(인증·권한). JSON 정책 기반
GuardDuty
ML 기반 위협 탐지. VPC Flow Logs/CloudTrail/DNS Logs 분석
CloudTrail
모든 API 호출 로그 기록(콘솔·CLI·SDK). S3 저장, CloudWatch 연동
WAF
웹 공격(SQLi, XSS, HTTP Flood) 룰 기반 차단
Shield
DDoS 방어. Standard 기본 제공, Advanced는 24/7 대응
Config
리소스 구성 변경 기록 + 규정 준수 검사
Security Hub
보안 상태 통합 대시보드. GuardDuty/Inspector/Macie 연계
AWS Config 규칙 동작 방식
Config는 리소스의 현재 상태 + 변경 이력을 추적하고, 규칙(Rule)으로 자동 준수 여부를 판단한다. 평가 트리거가 두 종류다.
Change-triggered — 리소스 설정이 바뀔 때마다 평가 (예: 보안그룹 수정 시 즉시 점검)
Periodic — 주기적 평가 (예: 24시간 간격)
규칙은 Managed Rules와 Custom Rules로 나뉜다.
Managed Rules (AWS가 미리 만든 규칙, 매개변수로 커스터마이즈 가능)
s3-bucket-public-read-prohibited — 버킷 정책/ACL/Block Public Access까지 종합 점검
s3-account-level-public-access-blocks — 계정 단위 Block Public Access 설정 확인
iam-password-policy — IAM 패스워드 복잡도/길이/만료 점검
cloudtrail-s3-dataevents-enabled — S3 데이터 이벤트 로깅 여부 확인
Config 위반 발생 → EventBridge 감지 → SNS 알림 발송
└→ Lambda 실행 → 퍼블릭 권한 자동 차단
S3 버킷이 퍼블릭으로 바뀌면 EventBridge가 감지 → SNS로 보안팀 알림 + 동시에 Lambda가 퍼블릭 권한을 자동 차단하는 흐름이다.
5. 정책 위반 탐지 자동화 데모 (AWS Config)
데모 목적은 명확하다. S3 버킷을 일부러 퍼블릭으로 만들어 Config가 Noncompliant로 잡아내는지, 다시 차단했을 때 Compliant로 돌아오는지 확인하는 것.
Step 1. AWS Config 활성화
AWS 관리 콘솔 → AWS Config → 활성화. 기록 대상 리소스와 S3 저장 버킷, IAM Role을 설정한다.
📸 [스크린샷: AWS Config 활성화 설정 화면 - 기록 대상 리소스 및 전송 위치 지정]
Step 2. Managed Rule 추가
Rules 메뉴 → Add Rule → s3-bucket-public-read-prohibited 선택 → 저장 후 규칙 실행.
📸 [스크린샷: 규칙 추가 완료 후 Rules 목록에 등록된 화면]
Step 3. 테스트 리소스 생성 (퍼블릭 S3 버킷)
S3 버킷을 새로 생성하고, 권한 설정에서 Block Public Access를 해제 → 퍼블릭 엑세스를 허용한다.
📸 [스크린샷: 버킷 권한 탭 - 퍼블릭 액세스 허용 상태]
Step 4. 규정 위반 확인
Config 대시보드에서 상태를 확인한다. 해당 버킷이 Noncompliant로 표시되는지 본다. Change-triggered 규칙이라 설정 변경 직후 평가가 돈다.
📸 [스크린샷: Config 대시보드에서 해당 버킷이 Noncompliant로 표시된 화면]
Step 5. 위반 해소 → 재평가
S3 버킷의 퍼블릭 엑세스 정책을 삭제하고 Block Public Access를 다시 활성화한다.
📸 [스크린샷: Block Public Access 재활성화 화면]
Step 6. Compliant 전환 확인
Config 콘솔에서 상태가 Compliant로 변경되는지 확인한다.
📸 [스크린샷: Config에서 동일 버킷이 Compliant로 전환된 화면]
💡 Config 데모 중 느낀 점
Config의 핵심은 "현재 상태"가 아니라 "변경 이력 + 규칙 평가"라는 점이다. 버킷을 퍼블릭으로 바꾼 순간을 잡아내는 거지, 단순 스냅샷 점검이 아니다. CloudTrail이 "누가 호출했나"라면 Config는 "지금 규정을 지키나"를 본다.
Change-triggered와 Periodic의 차이가 실무에서 중요하다. 즉시 탐지가 필요한 보안 규칙은 Change-triggered, 비용 많이 드는 전수 점검은 Periodic으로 거는 식으로 나눠야 한다. 무조건 즉시 평가가 좋은 게 아니다.
Noncompliant 표시까지 약간의 지연이 있었다. 평가가 이벤트 직후 바로 끝나는 게 아니라 큐에 들어갔다 도는 구조로 보인다. 데모 중에 "왜 아직 안 바뀌지" 하고 새로고침을 반복하게 되는데, 잠깐 기다리면 전환된다.
데모는 탐지까지만 보지만, 실무에선 여기에 EventBridge+Lambda를 붙여 자동 차단(remediation)까지 가야 의미가 있다. Config 단독은 "위반했다"고 알려줄 뿐 막아주진 않는다. s3-bucket-public-read-prohibited 같은 규칙엔 AWS가 제공하는 자동 remediation 액션을 연결할 수 있다.
s3-bucket-public-read-prohibited가 버킷 정책·ACL·Block Public Access를 종합 점검한다는 점이 좋다. Block Public Access만 켜도 통과될 것 같지만, ACL이나 버킷 정책 어느 한 쪽이라도 퍼블릭이면 잡힌다.
학습 정리
클라우드 보안 책임은 사용자와 AWS가 나눠 갖는 shared responsibility 모델이다. 규정 준수와 설정은 고객 책임 영역이다.
보안 사고의 60% 이상은 misconfiguration에서 발생한다. 침입 차단보다 설정 검증 자동화가 핵심이다.
대표 위협 6종(Account Hijacking, Misconfiguration, Data Leakage, Malicious Insiders, DoS/DDoS, Unsafe API)은 결국 권한 설계와 자격 증명 관리로 수렴한다.
실무 사례 3종의 공통 교훈: ① 최소 권한 ② Access Key 하드코딩 금지 ③ 백업을 다른 계정·리전에 분리.
보안은 Prevent-Detect-Respond 파이프라인이다. 한 단계만으로는 막지 못한다.
AWS Config는 Managed/Custom Rule로 규정 준수를 자동 평가하고, EventBridge+Lambda 연계로 탐지-알림-자동 대응까지 확장된다.
Config 단독은 탐지만 한다. 실무 가치는 remediation 자동화를 붙였을 때 나온다.
