보안

프로젝트에 적용 할 보안 아키텍처 구상 [3]

어렵지만 2026. 6. 8. 20:04

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와 연계해 엣지에서 필터링합니다.
  • 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 적용 가능.
  • Layer 5:모니터링 · 감사
    • VPC Flow Logs ▶ 모든 네트워크 트래픽 기록.
      CloudTrail ▶ API 호출 감사 로그.
      GuardDuty ▶ 머신러닝 기반 이상 탐지.
      CloudWatch ▶ 메트릭 알림.

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편에서는 프로젝트에 적용할 보안에대해서 말해보자