서비스 메시 아키텍처에서의 상호 TLS 인증을 이용한 구간 암호화 원칙

작성일: 1월 28, 2026 | 카테고리: 스마트 인터페이스

취약한 연결로 인해 분절된 마이크로서비스 네트워크와, 각 서비스 노드 간 암호화된 데이터 채널이 안전하게 구축된 버전을 대비하여 보여주는 개념도입니다.

서비스 메시 아키텍처의 보안 취약점과 구간 암호화의 필요성

서비스 메시(Service Mesh)는 마이크로서비스 간의 통신을 관리하는 전용 인프라 계층으로, 트래픽 제어, 관찰 가능성, 보안 기능을 제공합니다. 전통적인 네트워크 보안은 주로 경계(Perimeter) 방어에 집중했으나, 마이크로서비스 환경에서는 서비스 간 모든 통신이 내부 네트워크를 통해 이루어지더라도 신뢰할 수 없는 영역으로 간주해야 합니다. 이는 ‘제로 트러스트(Zero Trust)’ 보안 모델의 핵심 원칙입니다. 특히, 다중 테넌트 클라우드 환경이나 컨테이너 기반 배포에서는 한 컴퓨팅 노드 내에서도 다른 서비스의 트래픽이 스니핑될 수 있는 위험이 상존합니다. 따라서 종단 간 암호화(End-to-End Encryption)가 아닌, 서비스 간 각 홉(Hop)을 암호화하는 구간 암호화(Segment Encryption)가 필수적입니다. 이를 구현하지 않을 경우, 민감한 사용자 데이터나 내부 API 키가 평문으로 노출되어 데이터 유출 및 규정 위반(예: GDPR, PCI-DSS)으로 인한 막대한 과징금 리스크에 직면할 수 있습니다.

상호 TLS 인증의 작동 메커니즘: 인증서 기반 신원 확인 및 암호화 채널 구축

상호 TLS(Mutual TLS, mTLS)는 표준 TLS(Transport Layer Security) 프로토콜을 확장한 것으로, 클라이언트와 서버 양측 모두가 상대방을 신뢰할 수 있는지 확인하는 프로세스를 추가합니다. 이는 서비스 메시에서 각 서비스를 클라이언트이자 서버로 만들어, 모든 통신에 대해 강력한 상호 인증과 암호화를 보장합니다.

인증서 발급 및 생명주기 관리

서비스 메시(예: Istio, Linkerd)는 일반적으로 내장된 CA(Certificate Authority) 또는 외부 CA(예: Vault, Cert-Manager)와 통합하여 인증서 생명주기를 자동화합니다. 각 서비스 프록시(사이드카)가 시작될 때, 메시 제어 평면은 해당 서비스의 신원(서비스 계정, 워크로드 ID)을 확인하고 개인 키와 X.509 디지털 인증서를 동적으로 발급합니다. 이 인증서는 SPIFFE(SPIFFE: Secure Production Identity Framework For Everyone) 표준을 따르는 경우가 많으며, 인증서의 주체 대체 이름(Subject Alternative Name, SAN) 필드에 서비스의 고유한 신원(예: spiffe://cluster.local/ns/default/sa/service-a)을 포함합니다. 인증서의 유효 기간은 보안 정책에 따라 짧게(예: 24시간) 설정되어. 인증서가 유출되더라도 피해 범위를 제한합니다. 자동 순환(Rotation) 메커니즘은 만료되기 전에 새 인증서를 투명하게 제공하여 서비스 중단을 방지합니다.

TLS 핸드셰이크 과정에서의 상호 검증

서비스 A가 서비스 B를 호출할 때, 다음과 같은 상호 TLS 핸드셰이크가 발생합니다.

ClientHello & ServerHello: 서비스 A(클라이언트)가 암호화 가능한 방법 목록을 보내면, 서비스 B(서버)가 선택한 방법으로 응답합니다.
서버 인증서 전송 및 검증: 서비스 B는 자신의 서버 인증서를 서비스 A에게 전송합니다, 서비스 a는 이 인증서가 메시의 신뢰할 수 있는 루트 ca에 의해 서명되었는지, 그리고 인증서 내의 san 필드가 호출하려는 서비스 b의 신원과 일치하는지 검증합니다.
클라이언트 인증서 요청 및 검증 (mtls 핵심 단계): 표준 tls와 달리, 서비스 b는 서비스 a에게 클라이언트 인증서를 요청합니다. 서비스 A는 자신의 클라이언트 인증서를 전송하고, 서비스 B는 동일한 방식으로 이 인증서의 유효성과 신원을 검증합니다.
세션 키 생성 및 암호화 채널 수립: 양측 인증이 완료되면, 마스터 세션 키를 협상하고 이를 기반으로 대칭 키를 생성합니다. 이후 모든 애플리케이션 계층 데이터는 이 키로 암호화되어 전송됩니다.

이 과정을 통해 서비스는 단순히 IP 주소가 아닌, 암호학적으로 검증된 신원을 기반으로 상대방을 신뢰하게 됩니다.

주요 서비스 메시 구현체별 상호 TLS 방식 비교

Istio와 Linkerd는 상호 TLS를 구현하는 방식에서 설계 철학과 운영 복잡도에 차이가 있습니다. 이는 수수료나 속도가 아닌, 보안 강도, 호환성, 관리 부하 측면에서 중요한 선택 기준이 됩니다.

비교 항목	Istio	Linkerd
기본 암호화 방식	PERMISSIVE 모드에서 평문과 mTLS 트래픽을 동시에 허용하여 점진적 도입 가능. STRICT 모드에서는 mTLS만 허용.	기본적으로 모든 메시 내 TCP 트래픽에 대해 자동으로 mTLS를 적용. 비암호화 옵션이 명시적으로 제공되지 않음.
인증서 관리 및 발급자	Istiod(제어 평면)가 내장 CA 역할을 하거나, 외부 CA(예: 구글 CA, Vault)와 통합 가능. 인증서 서명 요청(CSR) API를 통해 동작.	자체 개발한 ‘링커드-러스트(linkerd-identity)’ 컨트롤러가 CA 역할. 더 가볍고 단순한 인증서 발급 체인을 지향.
성능 오버헤드 (지연 시간)	Envoy 프록시 기반으로, 기능이 풍부한 대신 상대적으로 높은 리소스 사용량과 지연 시간 증가(약 2~10ms)를 초래할 수 있음.	자체 개발한 Ultra-Light 프록시(링커드2-proxy) 사용. mTLS 핸드셰이크 최적화로 인한 오버헤드가 매우 낮음(약 1~3ms).
애플리케이션 변경 필요성	사이드카 주입 시 애플리케이션 코드 변경 불필요. 하지만 PERMISSIVE 모드에서 STRICT 모드로 전환 시 레거시 서비스의 호환성 문제 발생 가능.	애플리케이션 코드 변경 불필요. 모든 것이 투명하게 처리되지만, 메시 외부 서비스와 통신 시 명시적인 설정 필요.
보안 정책 세분화	세분화된 권한 부여 정책(AuthorizationPolicy)과 PeerAuthentication 정책을 통해 네임스페이스, 워크로드, 포트별로 mTLS 요구사항을 설정 가능.	기본적으로 메시 전체에 mTLS 적용. 네트워크 수준의 정책은 메시 외부의 Kubernetes NetworkPolicy 등에 의존.

선택은 조직의 요구사항에 따라 달라집니다. 최대한의 유연성과 세분화된 제어가 필요하다면 Istio가, 단순성과 최소한의 성능 오버헤드, ‘기본 보안(Secure by Default)’을 우선시한다면 Linkerd가 통계적으로 더 유리한 선택지가 될 수 있습니다.

상호 TLS 구간 암호화의 실전 구성 가이드 (Istio 기준)

이 가이드는 Istio 환경에서 STRICT mTLS 모드를 안전하게 적용하는 단계를 설명합니다. 각 단계는 운영 중단을 최소화하는 점진적 롤아웃 전략을 따릅니다.

1단계: 준비 작업 및 현재 상태 진단

먼저, 클러스터에 Istio가 설치되어 있고 사이드카 주입이 활성화되어 있어야 합니다. 현재 메시 내 트래픽의 암호화 상태를 확인하여 기준선을 설정합니다.

istioctl experimental authz check [pod-name] -n [namespace]

이 명령어는 특정 포드로 들어오고 나가는 트래픽이 mTLS로 보호받고 있는지 여부를 출력합니다. 초기에는 대부분의 트래픽이 ‘PERMISSIVE’ 모드 하에서 평문일 가능성이 높습니다.

2단계: 네임스페이스 단위 STRICT 모드 적용 (점진적 도입)

전체 클러스터에 한 번에 STRICT 모드를 적용하면 mTLS를 지원하지 않는 레거시 서비스가 장애를 일으킬 수 있습니다. 따라서 낮은 위험도의 네임스페이스부터 시작합니다.

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: target-namespace # 적용할 특정 네임스페이스
spec:
  mtls:
    mode: STRICT

이 PeerAuthentication 정책을 ‘default’라는 이름으로 특정 네임스페이스에 배포하면, 해당 네임스페이스 내의 모든 서비스는 들어오는 연결에 대해 mTLS를 강제합니다. 적용 후에는 1단계의 진단 명령어와 애플리케이션 모니터링 지표를 통해 장애 여부를 면밀히 관찰해야 합니다.

3단계: 메시 전체 STRICT 모드 적용 및 예외 구성

모든 주요 네임스페이스에 성공적으로 적용했다면, 메시 전체 기본 정책을 STRICT로 업그레이드할 수 있습니다. 이는 루트 네임스페이스(일반적으로 istio-system)에 배포된 정책으로, 명시적 정책이 없는 모든 워크로드에 적용됩니다.

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system # 루트 네임스페이스
spec:
  mtls:
    mode: STRICT

이 상태에서 mTLS를 지원하지 못하는 특정 서비스(예: 메시 외부의 데이터베이스 또는 레거시 시스템)와의 통신이 필요하다면, 대상 워크로드에 대해 예외 정책을 작성하여 PERMISSIVE 모드 또는 DISABLED 모드를 적용해야 합니다. 이는 보안 태세를 의도적으로 낮추는 것이므로, 예외 목록을 최소화하고 정기 검토해야 합니다.

구현 시 주요 리스크 요소 및 관리 방안

상호 TLS 구간 암호화는 강력한 보안을 제공하지만, 잘못된 구성은 심각한 운영 장애로 이어질 수 있습니다. 다음 리스크를 인지하고 관리해야 합니다.

인증서 순환 실패로 인한 서비스 중단: CA 서비스 장애 또는 프록시와 제어 평면 간 네트워크 문제로 인해 인증서가 만료되었을 때 새 인증서를 받지 못하면, 해당 서비스의 모든 아웃바운드 호출이 실패합니다. 위험 완화책: 인증서 만료 임계값에 대한 경고 알림을 설정하고, CA 서비스의 가용성을 모니터링하며, 인증서 순환 프로세스를 정기적인 장애 복구 훈련에 포함시켜야 합니다.
정책 오버라이드 충돌: 서로 다른 범위(전체, 네임스페이스, 워크로드)의 PeerAuthentication 정책이 충돌할 경우, 가장 구체적인 정책이 우선 적용됩니다. 복잡한 정책 집합은 관리가 어렵고 의도하지 않은 허점(예: 특정 포드가 평문 트래픽을 받도록 설정)을 만들어낼 수 있습니다. 위험 완화책: 정책을 적용하기 전에 ‘istioctl analyze’ 명령어로 구성을 검증하고, 정책 변경을 체계적인 버전 관리 및 코드 검토 프로세스 하에 두어야 합니다.
성능 병목 현상: 고빈도/저지연 트래픽을 처리하는 서비스에 mTLS를 적용하면 CPU 사용률 증가와 지연 시간 추가가 성능 SLA를 위반할 수 있습니다. 위험 완화책: 프로덕션 적용 전 부하 테스트 환경에서 성능 베이스라인을 측정하고, 프록시 리소스 요청/제한을 적절히 설정하며, 필요 시 더 성능 효율적인 프록시(링커드2-proxy)나 하드웨어 가속(예: Intel QAT) 옵션을 평가해야 합니다.
외부 서비스 통신 장애: 메시 내부 서비스가 메시 외부의 서비스(예: 공공 API, 타사 웹훅)를 호출할 때, STRICT mTLS 정책은 해당 아웃바운드 트래픽에도 영향을 미칠 수 있습니다. 외부 서버는 클라이언트 인증서를 요구하지 않으므로 연결이 실패합니다. 위험 완화책: 이를 해결하기 위해 ‘ServiceEntry’ 리소스를 생성하고, 해당 호스트에 대한 트래픽 모드를 ‘DISABLE’로 설정하거나, 외부 서비스로의 트래픽을 라우팅하는 egress 게이트웨이를 구성해야 합니다.

최종 리스크 관리 요약: 상호 TLS는 네트워크 계층의 보안을 강화하지만, 애플리케이션 수준의 인증/인가, 취약한 종속성, 잘못된 구성 관리 프로세스 등 다른 공격 벡터를 대체하지 않습니다. mTLS 구성을 ‘설정 후 잊어버리는’ 것이 아니라. 인증서 만료 경고, 정책 변경 로그, 암호화 트래픽 비율 모니터링을 지속적인 운영의 일환으로 삼아야 합니다. 보안 강화로 인한 간접적 이득(규정 준수 요건 충족으로 인한 감사 비용 절감, 데이터 유출 사고 방지를 통한 평판 손실 및 법적 벌금 회피)은 막연한 기대치가 아니라, 명확한 위험 관리 프레임워크 하에서 실현 가능한 목표입니다.