금융권과 공공기관 프로젝트를 진행하면서 가장 자주 요구받는 보안 요건 중 하나가 바로 mTLS(Mutual TLS, 양방향 TLS 인증)입니다. 일반 HTTPS는 클라이언트가 서버 신원만 검증하지만, mTLS는 서버도 클라이언트를 검증합니다. 이 글에서는 mTLS의 개념부터 Azure 환경에서의 실전 구성까지 정리합니다.
TLS와 mTLS의 차이
일반 TLS (단방향)
- 클라이언트가 서버 인증서 검증
- 서버는 클라이언트를 검증하지 않음 (누구든 접속 가능)
- 일반 웹사이트 HTTPS가 여기에 해당
mTLS (양방향)
- 클라이언트와 서버가 서로 인증서를 교환하고 검증
- 허가된 클라이언트만 서버에 접근 가능
- API 간 통신, B2B 연동, Zero Trust 아키텍처에서 필수
mTLS가 필요한 실제 상황
- B2B API 연동: 파트너사만 API를 호출할 수 있도록 제한
- 마이크로서비스 간 통신: 서비스 메시(Istio, Linkerd) 내부 통신
- IoT 디바이스 인증: 허가된 디바이스만 데이터 전송 허용
- 금융권 내부 시스템: 감독 당국의 보안 요건 충족
mTLS 인증서 구성 요소
- CA(Certificate Authority) 인증서: 루트 CA 또는 중간 CA 인증서
- 서버 인증서: 서버가 제시하는 인증서
- 클라이언트 인증서: 각 클라이언트가 제시하는 인증서
- 개인 키(Private Key): 서버와 클라이언트 각각 보관
Azure에서의 mTLS 구성 옵션
옵션 1: Application Gateway v2
Application Gateway v2는 mTLS를 기본 지원합니다. 리스너 설정에서 클라이언트 인증서 검증을 활성화하면 됩니다.
구성 절차:
- Key Vault에 CA 인증서 업로드
- Application Gateway → SSL Settings → Client Authentication 추가
- 리스너에 Client Authentication 설정 연결
- 백엔드 풀에 인증서 체인 설정
옵션 2: Azure API Management
APIM은 inbound 정책에서 validate-client-certificate 정책을 통해 클라이언트 인증서를 검증합니다. 세밀한 검증 조건(Subject CN, Thumbprint 등)을 지정할 수 있어 유연합니다.
옵션 3: Front Door Premium + Private Link
Front Door 자체는 아직 완전한 mTLS를 지원하지 않지만, 2024년부터 Preview로 클라이언트 인증서 검증 기능이 추가되었습니다. Preview 단계이므로 프로덕션 사용은 신중하게 검토하세요.
실전 구성 예시: Application Gateway + mTLS
1단계: CA 인증서 준비
파트너사별로 별도의 중간 CA를 두고, 그 CA로 발급한 클라이언트 인증서만 신뢰하는 구조를 설계합니다. Key Vault에 PEM 또는 CER 형식으로 업로드합니다.
2단계: Application Gateway SSL Profile 설정
SSL Profile에서 다음을 설정합니다.
- Client Authentication: Enabled
- Trusted Client CA Certificate Chains: 업로드한 CA 인증서 선택
- Verify Client Certificate Issuer DN: 선택적 활성화
3단계: 리스너에 SSL Profile 연결
기존 HTTPS 리스너를 편집해 SSL Profile을 연결합니다. 이 순간부터 클라이언트가 유효한 인증서를 제시하지 않으면 TLS 핸드쉐이크 단계에서 연결이 거부됩니다.
4단계: 백엔드로 인증서 정보 전달
Application Gateway가 받은 클라이언트 인증서 정보를 HTTP 헤더로 백엔드에 전달할 수 있습니다. Rewrite Rule을 사용해 Subject CN, Thumbprint 등을 헤더에 추가하세요.
실전 트러블슈팅
문제 1: “400 Bad Request – No required SSL certificate was sent”
클라이언트가 인증서를 제시하지 않고 접근했을 때 발생합니다. 원인은 주로 다음과 같습니다.
- 클라이언트 설정에서 인증서 파일 경로 오류
- 인증서 포맷 불일치 (PEM vs PFX vs DER)
- 개인 키 파일 접근 권한 문제
문제 2: “SSL Certificate Verification Failed”
CA 체인이 올바르게 설정되지 않은 경우입니다. 다음을 확인하세요.
- 루트 CA와 중간 CA가 모두 Trusted CA에 등록되어 있는지
- 클라이언트 인증서가 해당 CA로 발급되었는지
- 인증서 만료일 확인 (openssl x509 -in cert.pem -noout -dates)
문제 3: 주기적인 핸드쉐이크 실패
CRL(Certificate Revocation List) 확인 단계에서 타임아웃이 발생하는 경우가 있습니다. 운영 환경에서는 OCSP Stapling을 활성화하거나, CRL Distribution Point를 빠르게 응답하는 엔드포인트로 변경하세요.
mTLS 운영 시 고려사항
인증서 순환(Rotation) 전략
- 클라이언트 인증서는 보통 1~2년 유효기간
- 만료 30일 전 알림 시스템 구축 필수
- Key Vault의 인증서 자동 갱신 기능 활용 권장
인증서 폐기(Revocation) 대응
- CRL 또는 OCSP 엔드포인트 운영
- 긴급 폐기 시 신속 반영 프로세스 구축
성능 영향
mTLS는 추가 TLS 핸드쉐이크로 인해 미미한 지연을 발생시킵니다. 일반적으로 초기 연결 시 20~50ms 추가되지만, Keep-Alive와 세션 재사용을 활용하면 반복 요청에서는 체감할 수 없는 수준입니다.
마무리
mTLS는 “누가 접근하는지”까지 통제하는 강력한 인증 메커니즘입니다. 단순 API 키보다 훨씬 안전하지만, 인증서 관리 부담이 존재합니다. 운영 부담을 줄이려면 Key Vault 자동 갱신과 모니터링 시스템을 함께 구축하는 것이 필수입니다.