https://superhardcoding.tistory.com/64
프로젝트에 적용 할 보안 아키텍처 구상 [2]
https://superhardcoding.tistory.com/63 프로젝트에 적용 할 보안 아키텍처 구상 [1]보안이란 무엇일까? 사전적 의미에서는 안전을 유지하며 사회의 안녕과 질서를 유지함, 불법적이고 악의적인 위험으로
superhardcoding.tistory.com
이전에 TailScale에 대해 알아보았습니다.
다시 돌아와서 앞으로 구상할 프로젝트의 보안입니다.

그럼 '구상'에서 Tailscale만 하는게 보안일까요..? 저는 다른 보안이없나 생각하다가
거대 플랫폼인 AWS, 오라클, 마이크로소프트, 구글 4대 업체의 클라우드를 떠올렸고
그 업체들은 어떤 아키텍처로 보안을 구성했을까? 궁금점을 가지고 조금 알아보았습니다.
AWS VPC 보안 아키텍처

- Layer 1:DDoS · WAF (외부 방어)
- AWS Shield Standard (무료) / Advanced (유료) ▶ 대용량 트래픽 공격 흡수.
AWS WAF ▶ HTTP 레벨 악성 요청 차단 (SQL Injection, XSS 등). CloudFront와 연계해 엣지에서 필터링합니다.
- AWS Shield Standard (무료) / Advanced (유료) ▶ 대용량 트래픽 공격 흡수.
- Layer 2: Internet Gateway (VPC 진입점)
- Public Subnet에만 연결 - Private Subnet은 공인 IP 없음 ▶ 인터넷에서 존재 자체 모름. NAT Gateway로 Private → 외부 단방향 통신만 허용 (패키지 설치 등).
- Layer 3:Network ACL (서브넷 레벨 방화벽)
- Stateless ▶ 인바운드/아웃바운드 규칙 별도 설정 필요. 서브넷 단위로 적용. 번호 순서대로 평가 (낮은 번호 우선). 기본값: 모두 허용.
- Layer 4:Security Group (인스턴스 레벨 방화벽)
- Stateful ▶ 허용된 인바운드 응답 패킷은 자동 허용. EC2 인스턴스 단위 적용. 허용 규칙만 존재 (거부 규칙 없음, 기본 거부). 여러 인스턴스에 동일 SG 적용 가능.
- Stateful ▶ 허용된 인바운드 응답 패킷은 자동 허용. EC2 인스턴스 단위 적용. 허용 규칙만 존재 (거부 규칙 없음, 기본 거부). 여러 인스턴스에 동일 SG 적용 가능.
- Layer 5:모니터링 · 감사
- VPC Flow Logs ▶ 모든 네트워크 트래픽 기록.
CloudTrail ▶ API 호출 감사 로그.
GuardDuty ▶ 머신러닝 기반 이상 탐지.
CloudWatch ▶ 메트릭 알림.
- VPC Flow Logs ▶ 모든 네트워크 트래픽 기록.
AWS VPC는 정리하면 5개의 레이어로 이루어졌으며 위와 같은 형태로 되어있습니다.
그렇다며 구글은 어떨까요?

- Layer 1: Cloud Armor (엣지 DDoS + WAF)
- Google 엣지에서 동작 ▶ 트래픽이 VPC 진입 전에 필터링.
- L3/L4 DDoS 항상 자동 방어.
- L7 WAF 정책으로 XSS·SQLi·CSRF 차단. Cloud Load Balancer와 연동 필수 ▶ LB 없이 단독 사용 불가.
- 허용된 요청만 Load Balancer로 전달.
- Layer 2: Cloud Load Balancing / GFE (단일 진입점)
- GFE(Google Front End)가 모든 외부 요청 수신 ▶ 인터넷에서 VM 직접 접근 불가.
- 글로벌 Anycast IP ▶ 전 세계 동일 IP로 가장 가까운 구글 엣지 노드 자동 연결.
- TLS 종단 처리 (HTTPS → 내부는 HTTP 가능). HTTP(S) / TCP / UDP 로드밸런서 선택.
- Layer 3: VPC Network (전역 가상 네트워크)
- AWS VPC와 다름 ▶ GCP VPC는 Global 리소스. 리전을 넘어 단일 VPC 내 서브넷 배치 가능.
- 기본 규칙: 모든 인바운드 차단 / 모든 아웃바운드 허용. 인스턴스에 외부 IP 없으면 인터넷에서 존재 자체 모름.
- 프로젝트마다 default VPC 자동 생성 (운영에선 커스텀 VPC 권장).
- Layer 4: Subnets (리전별 서브넷)
- 서브넷은 리전 단위 (AWS처럼 AZ 단위 아님).
- 외부 IP 없는 인스턴스 → Private Subnet 역할.
- Private Google Access 활성화 시 외부 IP 없이도 Cloud Storage·BigQuery 등 구글 API 접근 가능.
- 서브넷 간 통신은 VPC 방화벽 룰로 제어.
- Layer 5: VPC Firewall Rules (분산 방화벽)
- Stateful ▶ 허용된 인바운드 응답은 자동 허용. 인스턴스 단위 적용 (네트워크 태그 또는 서비스 계정 기반).
- AWS Security Group과 유사하나 태그 기반이 핵심 차이.
- 허용 룰만 작성 (기본 Deny). 우선순위(0~65535) 숫자로 룰 순서 제어.
- Layer 6: Cloud NAT (아웃바운드 전용)
- 외부 IP 없는 VM이 패키지 설치·API 호출 등 아웃바운드 통신 필요할 때 사용.
- NAT Gateway가 대신 외부 IP로 요청 → 인바운드 연결은 절대 허용 안 함.
- AWS NAT Gateway와 동일한 역할. Cloud Router와 함께 동작.
- Layer 7: 모니터링 (VPC Flow Logs · Security Command Center)
- VPC Flow Logs ▶ 서브넷 단위 네트워크 트래픽 기록 (AWS Flow Logs와 동일).
- Cloud Audit Logs ▶ 모든 API 호출 감사 로그.
- Security Command Center ▶ 전체 프로젝트 보안 상태 통합 뷰 + 위협 탐지.
- Cloud Monitoring + Alerting — 메트릭 기반 알림.
위의 7가지 방식으로 되어있는걸 확인 할 수 있습니다.
Azure 보안 아키텍처

OCI 보안 아키텍처

그럼 공통적인 패턴을 모아보면 6가지 항목으로 볼 수 있다.
- 단일 진입점:
- 외부 트래픽은 반드시 하나의 게이트웨이만 통과.
- VM · 서버에 인터넷 직접 접근 불가.
| 기능 | AWS | OCI | Azuer | GCP |
| 서비스명 | Internet Gateway | Load Balancer + Public Edge | Application Gateway | GFE / Cloud LB |
| TLS 종단 | ALB (별도 구성) | LB에서 처리 | App GW 자체 | GFE 자체 |
| 범위 | Regional | Regional | Regional | Global Anycast |
| VM 직접 접근 | ✗ 차단 | ✗ 차단 | ✗ 차단 | ✗ 차단 |
| 로드밸런싱 | ALB / NLB | LBaaS | App GW / Front Door | HTTP(S) / TCP LB |
- DDoS + WAF 이중 방어:
- VPC 진입 전 두 레이어.
- L3/L4 대역폭 공격 자동 차단 + L7 XSS·SQLi 필터링.
| 기능 | AWS | OCI | Azuer | GCP |
| 서비스명 | AWS Shield | DDoS Protection | DDoS Standard | Cloud Armor |
| 무료 기본 제공 | ✓ Standard 무료 | ✓ 기본 포함 | ✓ Basic 무료 | △ 별도 설정 필요 |
| L3/L4 자동 차단 | ✓ 자동 | ✓ 자동 | ✓ 자동 | ✓ 자동 |
| WAF 서비스 | AWS WAF | OCI WAF | App GW WAF | Cloud Armor 정책 |
| 관리형 룰셋 | ✓ 유료 관리형 | ✓ 제공 | ✓ OWASP 내장 | ✓ OWASP 내장 |
- Public / Private 서브넷 분리:
- 외부 접근 가능 영역과 완전 격리 영역을 분리.
- Private은 인터넷에서 존재 자체가 보이지 않음.
| 기능 | AWS | OCI | Azuer | GCP |
| 서비스명 | VPC Subnet | VPC Subnet | VPC Subnet | VPC Subnet |
| VPC 범위 | Regional | Regional | Regional | Global (전역) |
| Private 정의 | 공인 IP 없음 | Public 서브넷 아님 | 공인 IP 없음 | 외부 IP 없음 |
| 가용 영역 | AZ 단위 서브넷 | AD / Fault Domain | Availability Zone | Region 단위 서브넷 |
| 내부 DNS | ✓ Route 53 | ✓ Private DNS | ✓ Private DNS Zone | ✓ Cloud DNS |
- 기본 인바운드 차단 (Default Deny)
- 명시적 허용 룰 없으면 인바운드 자동 차단.
- 허용만 작성하는 화이트리스트 방식.
| 기능 | AWS | OCI | Azuer | GCP |
| 서비스명 | Security Group | Security List | NSG | VPC Firewall Rules |
| Stateful | ✓ Stateful | Stateless + Stateful 선택 | ✓ Stateful | ✓ Stateful |
| 적용 단위 | 인스턴스 | 서브넷 | 서브넷 / NIC | 인스턴스 (태그 기반) |
| 룰 방식 | 허용만 작성 | 허용 + 거부 가능 | 허용 + 거부 가능 | 허용만 작성 |
| 기본 인바운드 | ✗ 전체 차단 | ✗ 전체 차단 | ✗ 전체 차단 | ✗ 전체 차단 |
- NAT: 아웃바운드 전용
- Private 서버의 아웃바운드(패키지·API)만 허용.
- 외부 → 내부 인바운드는 절대 불가.
| 기능 | AWS | OCI | Azuer | GCP |
| 서비스명 | NAT Gateway | NAT Gateway | NAT Gateway | Cloud NAT |
| 관리형 | ✓ 관리형 | S ✓ 관리형 | ✓ 관리형 | ✓ 관리형 |
| 고가용성 | ✓ AZ당 자동 | ✓ 자동 | ✓ 자동 | ✓ Cloud Router 연동 |
| 연동 필요 | Route Table 수정 | Route Rule 추가 | 서브넷 연결 | Cloud Router 필요 |
| 인바운드 허용 | ✗ 불가 | ✗ 불가 | ✗ 불가 | ✗ 불가 |
- Bastion:관리자 직접 접근 불가
- 운영자 SSH · RDP도 직접 연결 금지.
- Bastion / 전용 채널 경유 필수.
| 기능 | AWS | OCI | Azuer | GCP |
| 서비스명 | Systems Manager (SSM) | OCI Bastion | Azure Bastion | IAP Tunnel |
| 브라우저 기반 | ✓ SSM 웹 콘솔 | △ 포털 경유 | ✓ 브라우저 SSH/RDP | ✓ Cloud Shell |
| 공인 IP 불필요 | ✓ SSM 사용 시 | ✓ 지원 | ✓ VM 공인 IP 불필요 | ✓ IAP 경유 |
| 프로토콜 | SSH / RDP / 포트포워딩 | SSH / RDP | SSH / RDP | SSH |
| 접근 감사 로그 | ✓ CloudTrail | ✓ Audit Log | ✓ Monitor | ✓ Cloud Audit |
그림으로 만들어보면

4편에서는 프로젝트에 적용할 보안에대해서 말해보자
'보안' 카테고리의 다른 글
| 프로젝트에 적용 할 보안 아키텍처 구상 [2] (0) | 2026.06.06 |
|---|---|
| 프로젝트에 적용 할 보안 아키텍처 구상 [1] (0) | 2026.06.05 |