Mutual TLS

mTLS는 양쪽 인증서와 양쪽 신뢰 저장소가 모두 맞아야 열린다

일반 TLS가 서버 신원을 확인하는 데 집중한다면, mTLS는 클라이언트도 인증서를 제시해 서비스 간 호출 주체를 TLS 계층에서 확인한다.

A

Client / Service A

client.crt, client.key, trusted server CA를 가진 호출자

1. ClientHello

SNI, 지원 버전, cipher suite를 보내고 서버 인증서 선택을 유도한다.

A→B
B→A

2. Server Certificate + CertificateRequest

서버가 자신의 인증서와 클라이언트 인증서 요청을 함께 보낸다.

3. Client Certificate + CertificateVerify

클라이언트가 인증서와 개인키 소유 증명을 보내 상호 인증을 완성한다.

A→B

4. Trust Check + Policy

CA 체인과 이름을 검증한 뒤, 서비스 ID가 해당 API를 호출할 수 있는지 따로 판정한다.

allow
B

Server / Service B

server.crt, server.key, trusted client CA를 가진 수신자

Identity

CN/SAN/SPIFFE ID

인증서 주체를 서비스 ID와 매핑해야 호출자가 누구인지 알 수 있다.

Trust Anchor

공개 CA 또는 내부 CA

서버와 클라이언트가 서로의 발급 체인을 신뢰 저장소에 갖고 있어야 한다.

Rotation

짧은 수명과 자동 재발급

키 유출 영향을 줄이려면 발급, 갱신, 폐기, 재배포가 자동화되어야 한다.

Authorization

인증과 인가 분리

mTLS는 주체를 확인하지만, 권한은 게이트웨이와 애플리케이션 정책이 결정한다.

운영 난이도는 TLS가 아니라 인증서 생명주기에서 온다

cert-manager, Vault PKI, SPIFFE/SPIRE 같은 도구는 mTLS를 가능하게 해주지만, 허용 목록과 폐기 전파, 만료 알림, 키 보호가 빠지면 상호 인증은 쉽게 장애 원인이 된다.