기존 서버 보안 방식은 내부 네트워크를 신뢰하는 구조였습니다.
기존 방식:
Internet
↓
Firewall
↓
Internal Network
↓
Service
한 번 내부 네트워크에 들어오면 대부분의 시스템 접근이 허용되었습니다.
하지만 최근 서버 환경은 변화하고 있습니다.
구성:
Cloud
↓
Container
↓
Microservice
↓
Multiple Network
서비스가 분산되면서 내부 접근도 위험 요소가 되었습니다.
이 문제를 해결하기 위해 등장한 보안 모델이 Zero Trust입니다.
Zero Trust 핵심 원칙:
아무것도 신뢰하지 않는다
↓
모든 요청 검증
↓
최소 권한 접근
이번 글에서는 Docker Compose 환경에서 Zero Trust 개념부터 Network 분리, Service 인증, Container 접근 제어, Production 보안 구조까지 알아보겠습니다.
Zero Trust란 무엇인가?
Zero Trust는 “내부든 외부든 기본적으로 신뢰하지 않는다”는 보안 모델입니다.
기존 보안:
외부
↓
차단
↓
내부
↓
신뢰
Zero Trust:
모든 요청
↓
검증
↓
허용
검증 요소:
- 사용자 인증
- Service 인증
- 권한 확인
- Network 정책
- 보안 상태
기존 Network 보안의 한계
기존 구조:
User
↓
Firewall
↓
Private Network
↓
Application
문제:
내부 침입 발생 시:
공격자
↓
내부 이동
↓
다른 Service 접근
이를 Lateral Movement라고 합니다.
Zero Trust:
Service A
↓
인증
↓
Service B 접근
내부에서도 계속 검증합니다.
Docker Compose Zero Trust 기본 구조
구조:
User
↓
WAF
↓
API Gateway
↓
Authentication
↓
Microservice
↓
Database
각 단계마다 검증합니다.
Docker Compose Network Isolation
Zero Trust의 기본은 Network 분리입니다.
잘못된 구조:
모든 Container
↓
하나의 Network
문제:
하나의 Container 침해 시 전체 접근 가능
권장:
Frontend Network
↓
Backend Network
↓
Database Network
구조:
User
↓
Frontend
↓
Backend
↓
Database
Docker Compose Private Network 구성
예:
networks:
frontend:
backend:
database:
Service 연결:
services:
web:
networks:
- frontend
api:
networks:
- frontend
- backend
db:
networks:
- database
결과:
Web
↓
API
↓
Database
직접 접근 차단
Docker Compose 최소 권한 원칙
Zero Trust에서는 최소 권한이 중요합니다.
잘못된 방식:
root 권한 Container
권장:
일반 User 실행
↓
필요 권한만 제공
확인:
- Container User
- File Permission
- Capability
Docker Compose Service 인증
Microservice 환경에서는 Service 간 인증이 필요합니다.
기존:
Service A
↓
Service B
Zero Trust:
Service A
↓
Identity 확인
↓
Service B
사용:
- mTLS
- JWT
- API Key
Docker Compose mTLS 보안 구조
mTLS는 Service 간 암호화 인증 방식입니다.
구조:
Service A
↓
Certificate 검증
↓
Service B
효과:
- 위조 Service 차단
- 통신 암호화
Docker Compose Secret 관리
Zero Trust에서는 Secret 보호가 중요합니다.
위험:
password: admin123
권장:
Secret Store
↓
Container
관리 대상:
- Database Password
- API Token
- Certificate
Docker Compose Access Control
모든 접근은 확인해야 합니다.
예:
Developer
↓
권한 확인
↓
Server 접근
관리:
- Role Based Access Control
- User Permission
- Audit Log
Docker Compose Zero Trust와 API Gateway
외부 접근은 Gateway에서 통제합니다.
구조:
User
↓
WAF
↓
API Gateway
↓
Authentication
↓
Service
Gateway 역할:
- 인증
- Rate Limit
- Access Control
- Logging
Docker Compose Zero Trust와 Service Mesh
Microservice에서는 Service Mesh와 함께 사용합니다.
구조:
Service
↓
Sidecar Proxy
↓
Authentication
↓
Service
관리:
- mTLS
- Traffic Policy
- Service Identity
Docker Compose 보안 Logging
Zero Trust에서는 모든 접근 기록이 중요합니다.
수집:
- 로그인 기록
- API 요청
- 권한 변경
- Network 접근
구조:
Event
↓
Logging System
↓
Analysis
↓
Alert
Docker Compose Zero Trust Monitoring
보안 상태를 지속적으로 확인합니다.
확인:
- 이상 접근
- 권한 변경
- 비정상 Traffic
- Container 상태
구조:
Security Event
↓
Monitoring
↓
Alert
Docker Compose Production Zero Trust 구조
기업 환경:
Internet
↓
CDN
↓
WAF
↓
Load Balancer
↓
API Gateway
↓
Authentication
↓
Microservice
↓
Database
↓
Security Monitoring
Zero Trust 운영 Best Practice
추천:
모든 접근 검증
내부 Service도 인증
Network 분리
불필요한 연결 차단
Secret 보호
평문 저장 금지
최소 권한
필요한 권한만 제공
Log 기록
모든 접근 추적
자주 묻는 질문
Zero Trust는 Firewall을 대체하나요?
아닙니다.
Firewall과 함께 사용하는 보안 모델입니다.
Docker Compose에서도 Zero Trust 적용 가능한가요?
가능합니다.
Network 분리, Secret 관리, 인증 구조부터 적용할 수 있습니다.
Zero Trust가 필요한 규모는 어느 정도인가요?
외부 서비스 운영, Microservice 환경부터 효과가 커집니다.
내부 Network도 위험한가요?
네.
내부 침해 이후 확산 방지가 중요합니다.
마무리
Docker Compose Zero Trust 보안 아키텍처는 Container 기반 서버 환경에서 내부와 외부 모두를 보호하기 위한 현대적인 보안 방식입니다.
최종 구조:
Request
↓
Authentication
↓
Authorization
↓
Network Policy
↓
Service Access
↓
Monitoring
Production 서버는 단순히 외부 공격만 막는 것이 아니라 모든 접근을 검증하고 최소 권한으로 운영하는 구조가 필요합니다.
다음 글에서는 배포 전 Container 취약점을 자동으로 확인하는 Docker Compose Container Security Scan 구축 방법을 알아보겠습니다.