인증서 톺아보기 시리즈 3: 제로 트러스트와 mTLS

들어가며

인증서 톺아보기 두 번째 시리즈, 유효기간 감소와 발급/갱신 자동화에서 우리는 서버가 클라이언트에게 "저는 진짜 example.com입니다"라고 증명하는 일반적인 단방향 TLS에 대해 알아봤습니다.

그런데 서버만 신원을 증명하면 충분할까요? 클라이언트는 굳이 자신이 누구인지 증명하지 않아도 되는 걸까요? 일상적인 웹 브라우징이라면 그래도 괜찮습니다. 하지만 기업 내부의 서비스끼리 통신하는 환경에서는 이야기가 다릅니다.

오늘은 클라이언트도 인증서로 자신의 신원을 증명하는 mTLS에 대해 알아보겠습니다.

mTLS란?

mTLS(Mutual TLS, 상호 TLS)는 서버와 클라이언트가 서로의 신원을 인증서로 증명하는 양방향 인증 방식입니다.

일반 TLS vs mTLS

은행 창구에 비유해 보겠습니다.

일반 TLS는 고객이 은행 창구에 가서 "여기가 진짜 OO은행 맞나요?"하고 확인하는 것과 같습니다. 은행은 사업자 등록증(인증서)을 보여주며 자신의 신원을 증명합니다. 하지만 은행은 고객이 누구인지 따로 확인하지 않습니다. 누구든 창구에 올 수 있죠.

mTLS는 여기서 한 단계 더 나아갑니다. 은행이 신원을 증명한 뒤, 고객에게도 "신분증 보여주세요"라고 요청합니다. 양쪽 모두가 신원을 확인해야만 거래가 시작됩니다.

mTLS의 필요성

왜 클라이언트도 증명해야 할까?

일반적인 웹 서비스에서는 단방향 TLS로 충분합니다. 우리가 네이버 포털에 접속할 때, 네이버는 우리의 인증서를 요구하지 않습니다. 대신 ID와 비밀번호로 로그인하죠.

그런데 서비스와 서비스가 직접 통신하는 경우는 어떨까요? 예를 들어 결제 서비스가 재고 서비스에 "이 상품 재고 있어?"라고 물어보는 상황에서, 재고 서비스는 이 요청이 정말 우리 회사의 결제 서비스에서 온 것인지 어떻게 확인할 수 있을까요?

ID/비밀번호를 코드에 넣어 두면 유출 위험이 있고, IP 주소로 확인하자니 클라우드 환경에서는 IP가 수시로 바뀝니다. 바로 이런 상황에서 인증서 기반의 상호 인증, 즉 mTLS가 필요합니다.

제로 트러스트 아키텍처

mTLS를 이해하려면 제로 트러스트(Zero Trust)라는 보안 철학을 먼저 알아야 합니다.

• 전통적인 보안 모델: 성벽 모델

중세 성을 떠올려보세요. 높은 성벽이 외부의 적을 막아 주고, 성벽 안에 들어온 사람은 자유롭게 돌아다닐 수 있었습니다. 전통적인 네트워크 보안도 이와 같았습니다. 방화벽이라는 성벽 바깥은 위험하지만, 안쪽은 안전하다고 가정했죠.

성벽 모델 (Perimeter Security)
────────────────────────────
외부: 신뢰할 수 없음 (모두 차단)
내부: 신뢰함 (자유롭게 통신)

문제점: 성벽을 뚫고 내부에 침투하면 끝!

하지만 현실에서는 내부자에 의한 유출, 해커의 내부 침투 등이 빈번하게 발생합니다. 성벽 안에 들어온 침입자는 아무런 제약 없이 내부를 돌아다닐 수 있으니까요.

• 제로 트러스트 모델: "절대 신뢰하지 말고, 항상 검증하라"

제로 트러스트는 위치에 관계없이 모든 연결을 의심하는 보안 철학입니다. 같은 사무실 안에 있더라도, 같은 네트워크에 있더라도, 매 연결마다 "당신이 누구인지" 증명해야 합니다.

Zero Trust
"절대 신뢰하지 말고, 항상 검증하라"
(Never Trust, Always Verify)
────────────────────────────
위치와 관계없이 모든 연결에 대해
- 인증 (Authentication): 너 누구야?
- 인가 (Authorization): 이 작업을 할 권한이 있어?
- 암호화 (Encryption): 통신 내용을 보호하자

마치 회사 건물에 들어올 때 출입증을 찍더라도, 서버실에 들어가려면 또다시 별도의 인증을 받아야 하는 것과 같습니다.

이러한 제로 트러스트를 달성하기 위한 핵심 기술이 바로 mTLS입니다. 모든 서비스 간 통신에서 상대방의 신원을 인증서로 검증하니까요.

mTLS의 주요 사용 사례

• 마이크로서비스 간 통신

  • 결제 서비스 ↔ 재고 서비스처럼, 내부 서비스끼리 서로 신원을 확인하며 통신합니다.
  • Istio, Linkerd 같은 Service Mesh에서 자동으로 적용할 수 있습니다.

• API 보안

  • API Gateway와 백엔드 서비스 사이의 통신을 보호합니다.
  • 토큰(비밀번호) 방식보다 더 강력한 보안을 제공합니다.

• IoT 디바이스 인증

  • 스마트홈 기기나 센서 같은 IoT 디바이스가 클라우드 서버와 통신할 때, 각 디바이스의 신원을 인증서로 확인합니다.

• 관리자 접근

  • VPN을 대체하여 특정 관리 인터페이스의 접근을 제어합니다.

• 파트너사 연동

  • B2B API 통신에서 상대 회사의 시스템이 진짜 해당 회사인지 인증서로 확인합니다.
  • IP 화이트리스트보다 더 안전합니다.

mTLS 동작 원리

핸드 셰이크 과정

인증서 톺아보기 시리즈 1: 인증서란? 디지털 신뢰의 시작에서 다뤘던 TLS 핸드셰이크(TLS Handshake)를 기억하시나요? 일반 TLS에서는 서버만 인증서를 보여줬지만, mTLS에서는 클라이언트도 인증서를 보여주는 단계가 추가됩니다.

은행 창구 비유로 전체 과정을 살펴보겠습니다.

1. 고객이 창구에 도착(Client Hello)
   클라이언트 → 서버
   "안녕하세요, 이런 암호화 방식들을 사용할 수 있습니다."

2. 은행이 사업자등록증을 보여주며 고객에게도 신분증을 요청(Server Hello + Certificate + Certificate Request)
   서버 → 클라이언트
   "제 인증서입니다. 확인해보세요."
   "당신의 인증서도 보여주세요!"              ← mTLS에서 추가됨
   "이런 기관이 발급한 인증서를 신뢰합니다."

3. 고객이 신분증을 제시(Client Certificate + Certificate Verify)
   클라이언트 → 서버
   "제 인증서입니다."                      ← mTLS에서 추가됨
   "이 인증서가 진짜 제 것이라는 서명입니다."    ← mTLS에서 추가됨

4. 은행이 고객의 신분증을 검증(Server Verification)
   서버에서 확인하는 내용:
   ✓ 이 인증서를 발급한 기관(CA)을 신뢰할 수 있는가?
   ✓ 인증서의 유효 기간이 지나지 않았는가?
   ✓ 인증서가 폐기(취소)되지 않았는가?
   ✓ 클라이언트가 보낸 서명이 유효한가?(인증서 도용 방지)

5. 거래 시작(Secure Communication)
   양방향 신원 확인 완료! 암호화된 통신을 시작합니다.

💡 위 과정은 TLS 1.2를 기준으로 설명했습니다. 최신 버전인 TLS 1.3에서는 과정이 더 간결해졌지만, mTLS의 핵심 개념을 이해하는 데는 위 설명으로 충분합니다.

핵심 포인트

일반 TLS와 비교했을 때 mTLS에서 추가되는 것은 크게 세 가지입니다.

• 서버가 클라이언트에게 인증서를 요청합니다(Certificate Request)
• 클라이언트가 자신의 인증서를 전송합니다(Client Certificate)
• 클라이언트가 "이 인증서가 진짜 내 것"임을 개인 키로 서명하여 증명합니다(Certificate Verify)

이렇게 양방향 인증이 완료되면, 서버와 클라이언트 모두 상대방이 누구인지 확신한 상태에서 안전하게 통신할 수 있습니다.

mTLS 인증서 관리

mTLS를 실무에 적용할 때 가장 큰 과제는 바로 인증서 관리입니다.

일반 TLS에서는 서버 인증서만 관리하면 됐습니다. 하지만 mTLS에서는 모든 서비스가 각자의 인증서를 가지고 있어야 합니다. 서비스가 10개면 인증서도 10개 이상, 100개면 100개 이상이 필요하죠. 이 인증서들을 발급하고, 배포하고, 만료 전에 갱신해야 합니다.

인증서 라이프사이클

이 과정에서 가장 골치 아픈 것은 배포 와 갱신입니다.

배포: 새로 발급한 인증서를 각 서비스에 전달해야 합니다. 서비스가 몇 개뿐이면 수동으로 해도 되지만, 수십, 수백 개라면 자동화 없이는 불가능합니다.

갱신 : 인증서에는 유효기간이 있습니다. 인증서 톺아보기 시리즈 2: 유효기간 감소와 발급/갱신 자동화에서 살펴봤듯이 유효기간은 점점 짧아지는 추세이고, 만료되면 서비스 간 통신이 끊어지므로 미리미리 갱신해야 합니다.

자동화가 필수인 이유

인증서 하나가 만료되면 어떤 일이 벌어질까요? 해당 서비스와 통신하는 모든 서비스에 장애가 발생합니다. 마이크로서비스 환경에서는 연쇄적인 장애로 이어질 수 있죠.

이런 위험을 줄이기 위해 다양한 자동화 방법이 존재합니다.

방법	특징	적합한 경우
수동 관리	가장 단순하지만 확장성이 낮음	소규모, 정적 환경
Configuration Management(Ansible 등)	스크립트로 자동 배포	중규모 인프라
Certificate Manager(Vault 등)	중앙에서 인증서를 관리하고 감사 가능	엔터프라이즈 환경
Service Mesh(Istio, Linkerd)	인증서 발급부터 갱신까지 완전 자동화	마이크로서비스 환경

특히 Service Mesh는 애플리케이션 코드를 전혀 수정하지 않고도 mTLS를 자동 적용할 수 있어서, 마이크로서비스 환경에서 가장 많이 활용됩니다. 각 서비스 옆에 붙는 Sidecar Proxy가 인증서 발급, 갱신, mTLS 통신을 모두 대신 처리해 주기 때문입니다.

직접 구축해 보기: OpenSSL로 인증서 신뢰 체인 만들기

mTLS에 필요한 인증서들을 직접 만들어보면 구조를 더 잘 이해할 수 있습니다. OpenSSL을 사용해 Root CA → 서버 인증서, 클라이언트 인증서로 이어지는 신뢰 체인을 구축해 보겠습니다.

💡 참고: 이해를 돕기 위한 기초 예제입니다. 실무에서는 SAN(subject alternative name) 설정, 적절한 키 길이, 보안 저장소 등 추가적으로 고려해야 할 사항이 있습니다.

# 1. Root CA 개인 키 및 인증서 생성
#    모든 인증서의 신뢰 출발점이 되는 Root CA를 만듭니다.
openssl genrsa -out ca.key 2048

openssl req -new -x509 -days 3650 -key ca.key -out ca.crt \
  -subj "/C=KR/O=NHN Cloud/CN=My Root CA"

# 2. 서버 인증서 생성
#    서버가 "나는 진짜 이 서버야"라고 증명할 때 사용합니다.
openssl genrsa -out server.key 2048

openssl req -new -key server.key -out server.csr \
  -subj "/C=KR/O=NHN Cloud/CN=api-internal.example.com"

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -out server.crt -days 365

# 3. 클라이언트 인증서 생성
#    클라이언트가 "나는 인가된 서비스야"라고 증명할 때 사용합니다.
openssl genrsa -out client.key 2048

openssl req -new -key client.key -out client.csr \
  -subj "/C=KR/O=NHN Cloud/CN=service-a"

openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -out client.crt -days 365

이렇게 만들어진 인증서들은 다음과 같은 신뢰 체인을 형성합니다.

ca.crt (Root CA) ─ 모든 인증서의 신뢰 출발점
├── server.crt (서버 인증서) ─ "나는 진짜 이 서버야"
└── client.crt (클라이언트 인증서) ─ "나는 인가된 서비스야"

서버와 클라이언트 모두 같은 Root CA가 발급한 인증서를 가지고 있기 때문에, 서로의 인증서를 검증할 수 있습니다. 이것이 mTLS의 신뢰 기반입니다.

직접 관리의 현실적인 어려움

위의 예제에서는 인증서 3개만 만들었지만, 실제 운영 환경을 생각해보면 이야기가 달라집니다.

• 서비스가 50개면? → 인증서 50개를 발급하고, 50개 서비스에 각각 배포해야 합니다.
• 인증서가 만료되면? → 50개를 모두 갱신하고 다시 배포해야 합니다.
• 특정 서비스가 폐기되면? → 해당 인증서를 폐기 목록(CRL)에 등록하고 다른 서비스에 알려야 합니다.
• Root CA 개인 키가 유출되면? → 모든 인증서를 재발급해야 하는 재앙이 발생합니다.

OpenSSL 명령어를 하나하나 치면서 이 모든 것을 관리하는 것은 소규모 환경에서는 가능하지만, 서비스가 늘어날수록 운영 부담이 기하급수적으로 커집니다. 만료일을 깜빡하는 순간, 서비스 장애로 이어지죠.

NHN Cloud Private CA 활용

이러한 인증서 관리의 복잡성을 해결하기 위해, NHN Cloud에서 지난 해 출시한 Private CA 서비스를 활용할 수 있습니다.

👉 NHN Cloud Private CA 서비스 살펴보기

Private CA는 조직 내·외부에서 사용하는 사설 인증서를 발급부터 폐기까지 자동화 및 표준화하는 서비스로, 앞서 OpenSSL로 직접 해봤던 모든 작업을 콘솔에서 간편하게 처리할 수 있습니다.

주요 기능

• 손쉬운 발급: Root CA와 하위 CA를 클릭 몇 번으로 구축 (OpenSSL 명령어 불필요)
• 자동화된 인증서 발급: 인증서 템플릿, ACME를 이용한 대량 발급 및 자동 갱신
• 중앙 집중식 관리: 모든 인증서의 현황과 만료일을 하나의 콘솔에서 한눈에 확인
• 폐기 관리: CRL(Certificate Revocation List) 및 OCSP 자동 지원

방금 해 본 OpenSSL 방식과 비교해보면

OpenSSL 직접 관리
────────────────────────
1. OpenSSL로 Root CA 생성 및 보안 저장소 구축
2. 각 서비스별 인증서 수동 발급 (명령어 반복)
3. 배포 스크립트 작성 및 관리
4. 만료 추적 시스템 별도 구축
5. 폐기 목록(CRL) 관리 인프라 별도 구축
→ 서비스가 늘어날수록 운영 부담 증가

Private CA 활용
───────────────
1. 콘솔에서 Private CA 생성
2. 콘솔 또는 API로 인증서 발급
3. ACME를 통한 자동 갱신 (2부에서 알아봤던 바로 그것!)
4. CRL/OCSP 자동 제공
→ 서비스가 늘어나도 동일한 운영 부담

💡Service Mesh와의 통합 Istio나 Linkerd 같은 Service Mesh는 자체 CA를 제공하지만, Private CA를 External CA로 연동하면 조직 전체의 인증서 정책을 중앙에서 관리할 수 있습니다.

마치며

mTLS, 처음 접하면 '관리할 인증서가 너무 많은데 어떻게 하지?'하는 걱정이 앞설 수 있습니다. 하지만 요즘처럼 마이크로서비스가 서로 끊임없이 통신하는 환경에서는 "누구와 통신하는지 확실히 알아야 한다"는 제로 트러스트 원칙은 선택이 아닌 필수입니다.

다행히 Kubernetes 환경이라면 Service Mesh(Istio, Linkerd) 를 통해 코드 수정 없이 자동화할 수 있고, 일반 인프라 환경이라면 NHN Cloud의 Private CA 같은 관리형 PKI 서비스로 인증서 발급부터 갱신까지 중앙에서 관리할 수 있습니다.

핵심 정리

✅ mTLS는 서버와 클라이언트가 서로를 인증하는 양방향 인증 방식 으로, 제로 트러스트의 핵심 기술입니다. ✅ Handshake 시 클라이언트 인증서 검증 단계 가 추가되어, 인증서가 있는 클라이언트만 접속할 수 있습니다. ✅ 마이크로서비스, API 보안, IoT 디바이스 인증 등 내부 통신 보안에 필수적입니다. ✅ Service Mesh를 사용하면 코드 수정 없이 자동 적용 이 가능하며, 인증서도 자동으로 갱신됩니다. ✅ 인증서 관리가 핵심 과제이며, NHN Cloud Private CA와 ACME를 활용한 자동화로 운영 부담을 줄일 수 있습니다.

인증서 톺아보기 시리즈 3부작을 읽으시느라 정말 고생 많으셨습니다! 조금은 어려운 내용이지만, 이제 여러분은 인증서가 왜 필요한지, 어떻게 자동화하는지, 그리고 서비스들이 서로를 어떻게 신뢰하는지 이해하게 되었습니다.

앞으로 마이크로서비스 환경을 구축하거나 제로 트러스트 보안을 고민하게 될 때 지금까지 읽었던 내용이 든든한 밑바탕이 되기를 기대하며 이만 줄입니다.

읽어주셔서 감사합니다. 🙂

인증서 톺아보기 시리즈 1, 2편은 아래 경로에서 다시 읽어 보실 수 있습니다.

• 🔎인증서 톺아보기 시리즈 1: 인증서란? 디지털 신뢰의 시작
• 🔎인증서 톺아보기 시리즈 2: 유효기간 감소와 발급/갱신 자동화

참고 자료

표준 및 규격

• RFC 5246 - TLS 1.2
• NIST Zero Trust Architecture

공식 문서

• Cloudflare - What is mTLS?

NHN Cloud 인증서 관리 서비스 살펴보기

• Certificate Manager: 인증서, 도메인 등 만료 기한이 있는 자산을 관리하고 만료일 알림을 제공하는 서비스
• Private CA: 인증서, 도메인 등 만료 기한이 있는 자산을 관리하고 만료일 알림을 제공하는 서비스