서비스 메쉬 기반 네트워크 보안 강화 전략

— MSA의 보안은 트래픽 안에 있다

“보안은 더 이상 경계선이 아니다.
MSA의 시대에는 트래픽 자체가 경계다.”

---

📌 1. 왜 서비스 메쉬가 보안에 중요한가?

기존 모놀리식 시스템에서 보안은 대부분 **경계 방어(Perimeter Security)**에 의존했습니다.
방화벽, DMZ, VPN, IDS/IPS와 같은 외부 접속 제한 중심의 방식이죠.

하지만 마이크로서비스는…

• 수십 개 이상의 서비스가 내부에서 통신
• 네트워크 경로가 예측 불가능
• 쿠버네티스와 클라우드 환경에서는 IP가 동적으로 바뀜
• 외부뿐 아니라 내부 통신도 위협의 대상

👉 따라서, **”모든 트래픽은 불신(Zero Trust)”**이라는 전제하에 내부 통신까지 보안이 적용되어야 합니다.
그 중심이 바로 서비스 메쉬입니다.

---

🌐 2. 서비스 메쉬란?

서비스 메쉬(Service Mesh)는 서비스 간의 통신을 제어, 보안, 관측하는 인프라 계층입니다.
기능은 다음과 같습니다:

기능	설명
트래픽 제어	서비스 간 요청 라우팅, A/B 테스트, Rate Limiting
보안	mTLS, 인증, 인가, 서비스 간 접근 통제
관측성	로그, 메트릭, 트레이싱 자동 수집

대표 솔루션: Istio, Linkerd, Kuma, Consul Connect, AWS App Mesh

---

🔐 3. 서비스 메쉬 기반 네트워크 보안 구성 전략

✅ 1) mTLS (Mutual TLS) – 기본 중의 기본

• 모든 서비스 간 통신을 자동으로 암호화
• 트래픽 도청, 위조, 중간자 공격 방지
• 양방향 인증 → 서비스 A ↔ B 간 서로의 신원 검증

💡 Istio에서는 자동으로 Envoy Sidecar가 TLS 핸들링을 수행함
→ 개발자는 TLS 인증서를 직접 관리할 필요 없음

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
spec:
  mtls:
    mode: STRICT

---

✅ 2) RBAC (Role-Based Access Control)

서비스 간 통신을 허용할지 말지를 정책으로 정의할 수 있음.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: only-allow-order-to-payment
spec:
  selector:
    matchLabels:
      app: payment-service
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/order-sa"]

위 예시는 order-service만이 payment-service에 접근할 수 있도록 허용합니다.

---

✅ 3) 서비스 ID 기반 보안 (SPIFFE/SPIRE)

• 서비스 간 인증을 IP가 아닌 ID 기반으로 수행
• 각 서비스는 X.509 인증서를 발급받고, spiffe:// 형식의 ID를 가짐
• IP가 변동돼도 인증이 유효하며, 위조가 어려움

서비스 메쉬는 이를 기반으로 **Zero Trust Architecture(제로 트러스트 보안 모델)**을 구현합니다.

---

✅ 4) Rate Limiting + DoS 방어

• 특정 서비스에 대한 과도한 요청 → 차단
• Envoy Sidecar에서 트래픽 속도를 조절

apiVersion: config.istio.io/v1alpha2
kind: QuotaSpec
metadata:
  name: rate-limit
spec:
  rules:
  - quotas:
    - charge: 1
      quota: requestcount

또는 Redis 기반 외부 Rate Limiter와 연동 가능

---

✅ 5) 암호화 키와 인증서의 자동 교체

• Istio는 Citadel 또는 Istiod를 통해 인증서 자동 갱신 지원
• 수동 관리 불필요 → 보안 인프라 유지 비용 감소
• 기본 유효기간: 90일 → 24시간 주기 자동 갱신 가능

---

🧩 4. 실전 구성도 예시

[User] 
  ↓ HTTPS
[Ingress Gateway (TLS Termination)]
  ↓
[Service A] --mTLS--> [Service B]
      │                  ↑
      ↓                  │
[Audit + Authz] <----- [Service C]

• 모든 통신은 mTLS 암호화
• 서비스 간 접근 권한은 AuthorizationPolicy로 제어
• 중앙 감사 시스템으로 로그 전달

---

📊 5. 운영 시 주의사항

항목	체크포인트
성능	Sidecar 추가로 CPU/메모리 증가 → 리소스 할당 재조정
장애	인증서 갱신 실패 → 통신 끊김 가능성
관찰성	mTLS 적용 후 트래픽 분석이 어려움 → Telemetry 연동 필수
테스트	정책 변경 전 반드시 Canary/Stage 환경에서 시뮬레이션

---

🧠 6. Zero Trust Architecture 연계

서비스 메쉬는 ZTA(Zero Trust Architecture)의 핵심 요소입니다:

Zero Trust 구성요소	서비스 메쉬 연계
지속적 인증	mTLS + SPIFFE ID
최소 권한	RBAC Policy
마이크로 세분화	서비스 단위 접근제어
가시성	Envoy + Prometheus + Jaeger

---

✅ 결론: “보안은 트래픽 위에서 완성된다”

서비스 메쉬는 보안 제어의 통로를 분산된 서비스 안으로 끌어들이는 도구입니다.
이제는 내부 네트워크라 해도 신뢰하지 않고, 모든 요청이 보안의 대상이 됩니다.

mTLS + 인증정책 + 감사 + 자동화
이것이 클라우드 네이티브 보안의 새로운 표준입니다.