반응형

왜 “Verified Access + SSM” 인가?
| 항목 | 기존 방식 | 무VPN 제로 트러스트 |
| 사용자 접근 | VPN 접속 | Verified Access |
| 서버 관리 | SSH + Bastion | SSM Session Manager |
| 네트워크 신뢰 | 내부망 신뢰 | Identity 기반 |
| 감사 로그 | 제한적 | 전면 수집 |
👉 네트워크 접근 자체를 제거하고
👉 ID + 역할(Role)로만 접근
전체 아키텍처 개요
[User / Admin / Dev]
│
▼
[External IdP (SSO + MFA)]
│
▼
[ AWS Verified Access ]
│
▼
[ Application Load Balancer ]
│
▼
[ Private App (EC2 / ECS / EKS) ]
---------------------------------
[ Admin / Dev ]
│
▼
[ AWS IAM (Role 기반)]
│
▼
[ AWS SSM Session Manager ]
│
▼
[ EC2 (No SSH, No Public IP) ]
│
▼
[External IdP (SSO + MFA)]
│
▼
[ AWS Verified Access ]
│
▼
[ Application Load Balancer ]
│
▼
[ Private App (EC2 / ECS / EKS) ]
---------------------------------
[ Admin / Dev ]
│
▼
[ AWS IAM (Role 기반)]
│
▼
[ AWS SSM Session Manager ]
│
▼
[ EC2 (No SSH, No Public IP) ]
핵심 원칙
- VPN ❌
- Bastion ❌
- SSH Port 22 ❌
- Public IP ❌
구성 요소 역할 정리
1️⃣ AWS Verified Access
- 사용자·디바이스 인증
- 애플리케이션 단위 접근 제어
- 외부 접근 경계 역할
2️⃣ AWS SSM Session Manager
- 서버 관리 접근
- SSH 대체
- 명령·세션 로그 자동 저장
3️⃣ IAM Role
- 사용자 접근 권한 제어
- 서버 접근 제어
- 최소 권한 원칙 적용
1️⃣ 사용자(업무 시스템) 접근 흐름
접근 시나리오
- 사용자가 사내 웹 서비스 접속
- IdP에서 SSO + MFA 인증
- Verified Access 정책 평가
- ALB로 트래픽 전달
- Private Subnet App 접근
✔ VPN 없음
✔ IP 허용 없음
✔ 사용자 단위 정책 적용
2️⃣ 관리자 / 개발자 서버 접근 흐름 (SSM)
접근 시나리오
- 관리자가 AWS Console 또는 CLI 접속
- IAM Role Assume
- SSM Session Manager 연결
- EC2 Shell 접속
aws ssm start-session \
--target i-0abc12345
--target i-0abc12345
✔ SSH 키 관리 불필요
✔ 22번 포트 차단
✔ 접속 기록 자동 저장
3️⃣ EC2 서버 보안 구성 (필수)
🔐 네트워크
- Public IP 제거
- Security Group
- Inbound: ❌ 없음
- Outbound: SSM Endpoint 허용
🔐 시스템 설정
- SSH 데몬 비활성화
- Password Login 비활성화
- SSM Agent 실행 확인
4️⃣ IAM Role 설계 예시
EC2용 Role
- AmazonSSMManagedInstanceCore
- CloudWatch Logs 권한
관리자 Role
- ssm:StartSession
- ssm:TerminateSession
- ec2:DescribeInstances
📌 관리자별 Role 분리 필수
5️⃣ 접근 정책 예시
Verified Access 정책
permit(
principal.groups.contains("ops-team") &&
context.device.trusted == true &&
context.time.hour >= 9 &&
context.time.hour <= 18
)
principal.groups.contains("ops-team") &&
context.device.trusted == true &&
context.time.hour >= 9 &&
context.time.hour <= 18
)
SSM 접근 제한 예시
- 특정 태그 서버만 접근 허용
- 운영/개발 서버 분리
6️⃣ 로그 & 감사 체계 (CSAP 대응 핵심)
✔ SSM 로그
- 세션 기록
- 명령 이력
- CloudWatch / S3 저장
✔ Verified Access 로그
- 사용자
- 접속 시간
- 접근 애플리케이션
✔ CloudTrail
- Role Assume 기록
- 정책 변경 이력
7️⃣ 무VPN 아키텍처의 보안 효과
| 보안 항목 | 효과 |
| 계정 탈취 | MFA + 조건부 접근 |
| 내부 확산 | 네트워크 미노출 |
| 키 유출 | SSH 키 제거 |
| 감사 대응 | 100% 로그 |
8️⃣ 실전 운영 Best Practice
✔ 운영자
- MFA 필수
- 접근 시간 제한
- SSM 세션 자동 종료
✔ 개발자
- 개발 서버만 접근
- Production 접근 분리
- 읽기 전용 Role 제공
✔ 협력사
- 기간 제한 Role
- 특정 태그 서버만 접근
9️⃣ 기존 VPN 환경 → 무VPN 전환 전략
단계별 전환
- SSM 도입 (SSH 병행)
- SSH 완전 차단
- Verified Access 적용
- VPN 종료
👉 장애 없이 점진적 전환 가능
결론: AWS에서 가장 강력한 제로 트러스트 조합
✔ 외부 접근: Verified Access
✔ 서버 관리: SSM Session Manager
✔ 인증: SSO + MFA + IAM Role
✔ 네트워크: Private Only
AWS에서는 VPN 없이도 더 안전한 운영이 가능합니다.
반응형
'[TOP] > 정보보호' 카테고리의 다른 글
| [AWS / NCP] 기반 제로 트러스트 아키텍처 예시!! (0) | 2025.12.28 |
|---|---|
| [제로 트러스트(Zero Trust)] “아무도 믿지 말고, 항상 검증하라” (1) | 2025.12.28 |
| [차세대 방화벽 NGFW] Next Generation Firewall 이란!! (0) | 2025.12.28 |
| [중요][ISMS-P] 인증 완전 가이드 !! (0) | 2025.11.19 |
| [중요2][ISMS] 정보보호 기본정책 템플릿 & 내부감사 체크리스트 !! (0) | 2025.11.19 |
| [ISMS] 초도가이드 - 정보보호 인증 / 왜 인증을 받나? (주요 효과) (1) | 2025.11.19 |
| [ISMS-P] 정보보호 통합 인증제도 !! (0) | 2025.11.16 |
댓글