- 전제 : 회사가 AWS에 여러 서비스(웹, API등)을 올려서 쓰고 있다.
- 문제 : 하나의 AWS 계정에 다 때려 넣으면 보안 사고 나면 전체 계정이 털리고 로그·권한·네트워크가 뒤엉켜서 관리가 안 된다.
- 해결 :
1. 계정을 여러 개로 쪼갠다.
2. 비슷한 역할 계정들을 OU(Organizational Unit)으로 묶는다.
3. 보안 도구/로그는 중앙화애서 한 곳에 관리한다. - 그림은 그 중에서도 퍼리미터(외곽) 보안 + 중앙 집중형 보안 운영 구조 예시이다.
Organization / OU / Account 개념
Organization
- 가장 바깥 파란 박스 = AWS Orgaization
- 회사 전체 aws 계정 묶음.
여기서 scp(서비스 제어 정책) 같은 걸로 “이 조직 안 계정들은 루트 계정이라도 이런 건 못한다” 같은 상위 룰을 건다.
OU (Organizational Unit)
- OU – Security
- OU – Infrastructure
- OU – Workloads
OU는 비슷한 성격의 계정들을 묶어놓은 폴더.
Account (계정)
각 OU 안에는 구체적인 account가 있다.
- security OU
1.Security Tooling account
2.Log Archive account
- Infrastructure OU
1. Network account
- Workloads OU
1. Application account (여러 개일 수도 있는데 그림에는 1개 예시)
OU – Security : 보안·로그 전담 영역
Security Tooling account
"보안 도구 통합 관제 계정"
- Amazon GuardDuty
이상행위 탐지 서비스 (CloudTrail, VPC Flow, DNS 로그 등 분석해서 침해 징후 찾음)
- AWS Security Hub (CSPM)
여러 보안 결과를 모아서 “보안 점수”와 컴플라이언스(CIS, PCI 등) 상태를 보여주는 대시보드
- AWS Firewall Manager
여러 계정에 있는 Security Group, WAF, Shield 설정을 중앙에서 관리·배포
Log Archive account
"로그만 모아두는 금고 계정"
-
가운데 초록색 버킷 = Central logs (S3 버킷)
-
화살표로 들어오는 것들:
CloudFront access logs
AWS WAF logs
Global Accelerator flow logs 등
-
이 계정의 특징
- 여기에 모이는 로그는 길게, 안전하게 보관 (버전관리, MFA Delete, 별도 권한)
-실무에서는 “로그는 건들지 말고 읽기만 해라” 수준으로 권한을 쪼갬.
-
아래 줄에 있는 서비스들
- Amazon GuardDuty
- Amazon Macie (S3 안 민감정보 탐지)
- AWS Config (리소스 설정 변경 이력 추적)
- AWS IAM Access Analyzer (잘못 공유된 리소스 탐지)
- Organization trail (조직 전체 CloudTrail 추적)
- Security Hub CSPM
⇒ 요약:
Security Tooling account 가 “보는/분석하는 뇌”라면,
Log Archive account 는 “모든 증거를 모아두는 창고” 역할.
OU – Infrastructure : 공용 네트워크·퍼리미터 보안 계층
이건 “회사 공용 외곽망”이라고 보면 된다.
Network account 안에 CDN/DNS/WAF 같은 것들이 모여 있다.
-
점선 박스 안
-
Amazon Route 53
- DNS 서비스. www.example.com → CloudFront 도메인으로 연결.
-
Amazon CloudFront
-
CDN(콘텐츠 전송 네트워크).
-
전 세계 엣지 로케이션에서 캐싱해서 빠르게 전달, WAF와 연동하기 좋음
-
-
AWS WAF
- 웹 방화벽
- SQL Injection, XSS, 봇 L7 필터링
-
AWS Shield Advanced
- DDoS 방어 고급 기능. CloudFront, ALB, Route 53, Global Accelerator 보호.
-
AWS Certificate Manager (ACM)
- HTTPS용 TLS 인증서 관리 & 자동 갱신
-
-
아래 줄
-
Security Hub CSPM
-
GuardDuty
-
EventBridge (이상 탐지 시 알림/자동대응 연결)
-
Config
-
IAM Access Analyzer
-
Organization trail
-
⇒ 이 계정은 “밖에서 들어오는 모든 HTTP/HTTPS 트래픽이 처음 찍고 가는 곳”
보안 이벤트/로그를 중앙 보안 OU로 넘기는 역할.
OU – Workloads : 실제 서비스(앱) 계정
- 여기가 진짜 서비스가 돌아가는 계정
그림에는 application account가 하나만 그려져 있음
VPC 내부 구조
-
VPC
회사 전용 가상 네트워크
-
Private subnet
- 외부에서 직접 접근 불가.
- 여기에 EC2 인스턴스(웹 서버, API 서버 등)가 들어감.
-
Application Load Balancer (ALB)
- CloudFront → ALB → EC2 로 트래픽 분산.
- 보통 Public subnet 쪽에 위치.
-
Dynamic origins
- ALB 뒤에 있는 EC2 같은, 동적으로 응답하는 서버들을 말함. -
Static origins
- 정적 콘텐츠(S3 버킷 등). CloudFront가 직접 S3에서 가져갈 수도 있음.
=> 이 계정에서 나오는 보안·로그 정보가
Security OU의 Security Tooling + Log Archive 계정으로 모여서 분석되는 구조
전체 흐름
- 사용자 요청이 들어와서 탐지 및 로깅까지 한번에 따라가기
- 사용자 브라우저
- Route 53 (network account)
- 도메인 -> cloudFront 배포의 도메인으로 맵핑
- CloudFront(Network account)
-
가까운 엣지에서 캐시된 정적 파일 있으면 바로 응답
-
아니면 origin으로 요청 전달
-
이 과정에서
- CloudFront access logs 생성 -> Log Archive account S3로 전송
- AWS WAF + Shield Advanced (Network account)
- CloudFront/ALB 앞단에서
- SQLi, XSS, 봇 트래픽 등 필터링 → 차단된 요청도 로그로 남김
- WAF logs → Log Archive account S3
- Application Load Balancer (Workloads – Application account)
- 정상 요청만 EC2 인스턴스로 전달
- ALB 로그도 필요하면 S3로 남길 수 있음
- EC2 인스턴스 / 애플리케이션 (Workloads)
- 실제 서비스 로직 처리
- 애플리케이션 로그, 시스템 로그 → CloudWatch Logs or S3
- 보안 관제
- 각 계정의 로그 & 이벤트:
- CloudTrail, VPC Flow Logs, DNS logs 등 → GuardDuty가 분석
- S3에 쌓이는 민감정보 → Macie가 스캔
- 리소스 설정 변화 → Config가 추적
- 외부에 잘못 공유된 리소스 → IAM Access Analyzer 탐지
- 이 결과들이 전부 Security Hub로 모여서
- 계정·리전 전체 보안 상태, 컴플라이언스 점수 확인 - Firewall Manager가 여러 계정 WAF/SG 정책을 중앙에서 일괄 배포
- 로그 보존
- 여기서 중요한 로그는 전부 Log Archive account S3에 보아서 장기 보관 및 삭제/변조 방지
