상호 TLS (mTLS) 구현 패턴

표준 TLS에서는 인증서를 통해 서버만 클라이언트에 인증합니다. 상호 TLS(mTLS)는 이를 확장하여 양쪽 당사자가 인증서를 제시하고 검증하도록 합니다. 서버가 TLS 핸드셰이크에서 CertificateRequest를 통해 요청하면 클라이언트가 클라이언트 인증서를 제시합니다. 서버는 신뢰할 수 있는 CA를 기준으로 클라이언트 인증서를 검증합니다. mTLS는 제로 트러스트 네트워킹의 기반입니다. 네트워크 경계 보안에 의존하는 대신 서비스가 모든 연결에서 암호학적으로 서로를 인증하도록 합니다. Istio, Linkerd 및 Consul Connect와 같은 서비스 메시가 마이크로서비스 간에 mTLS를 투명하게 구현합니다.

mTLS 핸드셰이크는 다음과 같이 TLS 1.3을 확장합니다. ServerHello와 서버 인증서 및 완료 메시지를 보낸 후 서버는 허용 가능한 인증 기관과 서명 알고리즘을 지정하는 CertificateRequest 메시지를 보냅니다. 클라이언트는 자체 Certificate(클라이언트 인증서 체인)와 CertificateVerify(클라이언트의 개인 키를 사용하여 전사에 서명한 값)로 응답합니다. 서버는 신뢰할 수 있는 CA 저장소를 기준으로 클라이언트 인증서 체인을 검증하고 CertificateVerify 서명을 확인합니다. 두 검증이 모두 통과하면 연결은 상호 인증됩니다. 인증서에 대응하는 개인 키가 없으면 클라이언트는 CertificateVerify를 위조할 수 없습니다.

서비스 메시 환경에서 클라이언트 인증서는 일반적으로 내부 CA에서 발급합니다. Istio는 SPIFFE(Secure Production Identity Framework for Everyone) SVID를 사용합니다. 각 워크로드는 spiffe://cluster.local/ns/default/sa/payment-service와 같은 SPIFFE URI SAN(주체 대체 이름)이 포함된 인증서를 받습니다. 이러한 인증서는 수명이 짧고(24시간) 메시 제어 평면(istiod)에 의해 자동으로 교체됩니다. 사용자 대상 mTLS(예: 기업 VPN, API 클라이언트)에서는 기업 CA가 더 긴 수명의 인증서를 발급하고 MDM(Mobile Device Management)을 통해 직원 기기에 전달할 수 있습니다.

서버 측 mTLS 검증에는 여러 단계가 포함됩니다. (1) 체인 검증 — 클라이언트 인증서가 서버의 클라이언트 CA 저장소에 있는 신뢰할 수 있는 루트 CA로 이어지는지 확인합니다. (2) 유효 기간 확인 — 인증서가 만료되지 않았으며 아직 유효하지 않은 상태도 아닌지 확인합니다. (3) 폐기 확인 — OCSP 또는 CRL을 통해 인증서가 폐기되지 않았는지 확인합니다. (4) SAN/CN 일치 확인 — 인증서 SAN에서 신원 정보를 추출합니다(SPIFFE URI, DNS 이름 또는 이메일 주소). (5) 권한 부여 — 인증된 신원이 요청된 자원에 액세스할 권한이 있는지 확인합니다. 4단계와 5단계에는 기본 TLS 구성 이상의 애플리케이션 수준 논리가 필요합니다.

수명이 짧은 인증서를 사용하면 명시적인 폐기가 필요하지 않습니다. 인증서가 24시간 후에 만료된다면 손상으로 인한 영향 범위가 제한되기 때문입니다. 교체에는 다음이 필요합니다. (1) 사전 교체 — 기존 인증서가 만료되기 전에 새 인증서를 발급합니다(수명의 80% 시점에 교체). (2) 무중단 교체 — 전환 기간 동안 서비스가 이전 인증서와 새 인증서를 모두 수락해야 합니다. (3) 정상적인 다시 로드 — TLS 스택이 기존 연결을 끊지 않고 자격 증명을 다시 로드해야 합니다(nginx: nginx -s reload; Envoy: 동적 xDS 인증서 업데이트). SPIFFE Workload API(SPIRE에서 구현)는 유닉스 도메인 소켓 API를 통해 인증서 전달과 교체를 자동화합니다.

Istio는 각 파드에 주입되는 Envoy 사이드카 프록시를 통해 mTLS를 투명하게 구현합니다. 제어 평면(istiod)은 메시 루트 CA가 서명한 중간 인증서를 사용하는 CA 역할을 합니다. 각 파드의 사이드카는 SDS(Secret Discovery Service) API를 통해 SPIFFE SVID를 받습니다. PeerAuthentication 정책은 mTLS 모드를 구성합니다. STRICT(mTLS 필수), PERMISSIVE(mTLS와 일반 텍스트를 모두 허용하며 마이그레이션에 사용), DISABLE 중 하나를 선택할 수 있습니다. AuthorizationPolicy 리소스는 어떤 서비스가 통신할 수 있는지 정의하며, 클라이언트 인증서의 SPIFFE ID를 기준으로 확인됩니다. 이를 통해 애플리케이션 코드를 변경하지 않고도 클러스터 내부에 제로 트러스트를 구현할 수 있습니다.

외부 API 클라이언트의 경우 mTLS는 API 키나 OAuth 토큰보다 강력한 인증을 제공합니다. 클라이언트는 보안 저장소(HSM, OS 키 저장소 또는 암호로 보호되는 소프트웨어 키)에 개인 키를 보관합니다. 클라이언트 인증서는 API 엔드포인트가 예상하는 CA에 고정됩니다. 각 API 요청은 TLS 계층에서 인증되므로 별도의 Authorization 헤더가 필요하지 않습니다. Cloudflare의 API Shield, AWS API Gateway 클라이언트 인증서, Google Cloud의 서비스 계정 mTLS가 모두 이 모델을 구현합니다. 탈취된 API 키는 어디서든 사용할 수 있지만, 탈취된 mTLS 개인 키를 악용하려면 클라이언트를 실행하는 기기도 훔쳐야 합니다.

mTLS 배포에는 여러 운영상의 과제가 있습니다. (1) 인증서 배포 — 특히 파드가 동적으로 늘어나고 줄어드는 환경에서 모든 서비스에 클라이언트 인증서를 안전하게 전달해야 합니다. (2) CA 침해 — 내부 CA는 가치가 높은 공격 대상이며, 침해되면 모든 서비스 인증서를 무효화해야 합니다. HSM을 사용하는 CA와 오프라인 루트 CA로 위험을 줄일 수 있습니다. (3) 디버깅 — 암호화된 mTLS 트래픽은 표준 디버깅 도구로 확인하기 어렵기 때문에 서비스 메시 관찰 가능성 도구(Jaeger, Kiali)가 필요합니다. (4) 중간 장비 호환성 — TLS 검사 프록시는 클라이언트 인증서를 통과시키도록 명시적으로 구성하지 않으면 mTLS를 중단시킵니다. (5) 인증서 만료 사고 — 갱신에 실패하면 전체 서비스가 중단될 수 있습니다.

SPIFFE(Secure Production Identity Framework for Everyone)는 X.509 SVID를 사용한 워크로드 ID 표준을 정의합니다. SPIRE(SPIFFE Runtime Environment)는 참조 구현입니다. SPIRE Server는 등록 기관이자 CA 역할을 합니다. SPIRE Agents는 각 노드에서 실행되며, 노드 증명자(AWS 인스턴스 ID, Kubernetes 서비스 계정 JWT, TPM)와 워크로드 증명자(Unix PID, 컨테이너 런타임 메타데이터)를 사용해 워크로드 ID를 증명합니다. Workload API는 간단한 gRPC API를 사용하여 Unix 도메인 소켓을 통해 워크로드에 SVID를 전달합니다. SPIRE는 Envoy, Nginx 및 주요 서비스 메시와 인증서 공급원으로 통합됩니다.

높은 보안 수준이 필요한 mTLS 배포에서는 개인 키를 소프트웨어 키 저장소가 아니라 하드웨어 보안 모듈(HSM)에 보관해야 합니다. TLS 라이브러리(OpenSSL, BoringSSL)는 PKCS#11 인터페이스를 통해 개인 키를 불러오며, 이 인터페이스는 서명 작업을 HSM으로 전달합니다. 개인 키는 평문 상태로 HSM 경계를 벗어나지 않습니다. 클라우드 HSM 옵션으로는 AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM이 있습니다. 기기 수준의 mTLS(IoT, 기업용 노트북)에서는 TPM 2.0이 비슷한 기능을 제공합니다. TLS 클라이언트 키가 TPM에 바인딩되고 서명에 TPM 권한 부여가 필요하므로, 침해된 기기에서 키를 추출하기가 매우 어려워집니다.

mTLS를 테스트하려면 클라이언트 인증서 제시를 지원하는 도구가 필요합니다. OpenSSL s_client: openssl s_client -connect host:443 -cert client.pem -key client.key -CAfile server-ca.pem. curl: curl --cert client.pem --key client.key --cacert server-ca.pem https://host. 서비스 메시를 테스트할 때는 istioctl proxy-config secret pod/name으로 현재 인증서와 만료 시점을 확인할 수 있습니다. kubectl exec로 파드에 접속한 다음 curl로 사이드카 관리 엔드포인트(localhost:15000)를 호출하면 활성 수신기와 mTLS 구성을 확인할 수 있습니다. 자동 갱신 테스트에서는 인증서 갱신이 진행되는 동안 연결이 안정적으로 유지되는지 확인해야 합니다.

표준 TLS와 비교할 때 mTLS가 추가하는 단계는 무엇입니까?

mTLS는 TLS에 클라이언트 인증서 인증을 추가하므로 양쪽 당사자가 서로의 인증서를 확인합니다. SPIFFE SVID는 인증서 SAN의 SPIFFE URI를 통해 표준화된 워크로드 ID를 제공합니다. Istio는 STRICT/PERMISSIVE 모드를 지원하는 Envoy 사이드카를 통해 mTLS를 투명하게 구현합니다. 수명이 짧은 인증서(24시간)를 사용하면 폐기가 필요하지 않고 침해가 발생할 수 있는 기간도 제한됩니다. SPIRE는 Workload API를 통해 인증서 발급과 갱신을 자동화합니다. 높은 보안 수준이 필요한 배포에서는 mTLS 개인 키를 HSM 또는 TPM에 보관해야 합니다. 운영상의 과제로는 CA 키 보호, 중간 장비 호환성, 무중단 갱신이 있습니다.