제로 트러스트 아키텍처와 mTLS의 역할·경계

NIST SP 800-207은 제로 트러스트 아키텍처(ZTA)의 개념과 논리 구성요소를 설명하는 지침입니다. 내부 네트워크에 있다는 이유만으로 사용자나 장치를 신뢰하지 않고, 보호 대상 리소스에 대한 접근을 명시적 정책 판단으로 제어하는 접근을 제시합니다. 정책 엔진·관리 지점과 시행 지점 등은 아키텍처 역할이며, 모든 요청이 단일 제품이나 하나의 인증 방식으로 처리되어야 한다는 뜻은 아닙니다. 신원, 장치 상태, 리소스 민감도, 환경 신호에 따라 정책을 구성합니다.

전문가 관점: Google BeyondCorp 전환 경험

Google Research의 Guilherme Gonçalves, Kyle O’Malley, Betsy Beyer, Max Saltonstall은 BeyondCorp 전환의 마지막 구간에서 표준 HTTPS 접근 흐름으로 옮기기 어려운 특수 사례가 많은 비용을 요구했다고 분석합니다. 이는 Google의 대규모 사내 시스템 전환에서 얻은 경험이며, 모든 조직에 같은 도구나 설계가 맞는다는 처방은 아닙니다. 기존 장치, 비대화형 서비스, 레거시 프로토콜, 사용자 경험과 운영 책임을 함께 조사해야 한다는 실무적 교훈을 줍니다. 제로 트러스트를 mTLS 도입과 동일시하지 말고, 자산 목록과 접근 경로부터 검증해야 합니다.

mTLS가 제공하는 것과 제공하지 않는 것

Mutual TLS는 TLS 연결에서 양쪽 peer의 인증을 구성할 수 있게 합니다. 일반적인 서버 인증 TLS와 달리 서버가 클라이언트 인증서를 요구하고 인증서 체인 및 정책을 검증할 수 있습니다. 성공한 인증은 해당 연결의 peer 신원에 대한 입력이지, 사용자의 의도나 애플리케이션 권한, 장치의 현재 무결성까지 자동 보장하지 않습니다. 서비스 메시나 API gateway에서 TLS를 종료하면 그 뒤 구간에서 별도 보호·인증이 필요할 수 있습니다. TLS 버전과 인증서 용도, SAN 이름 검사, trust store, 폐기·회전 정책을 실제 라이브러리와 제품에 맞춰 확인하세요.

인증서 수명주기와 배포 단계

짧은 수명의 인증서는 탈취된 자격 증명의 노출 기간을 줄이는 데 도움이 될 수 있지만, 발급·갱신·폐기·시계 동기화·장애 대응을 자동화해야 합니다. 인증 기관 장애나 갱신 실패는 서비스 통신을 끊을 수 있고, 지나치게 넓은 trust root는 신원 경계를 약화시킬 수 있습니다. 처음부터 모든 연결을 강제 전환하기보다 관찰 모드로 실제 peer 식별자를 수집하고, 정책 위반을 분류한 뒤 단계별 차단을 적용합니다. 인증서 갱신, 중간자 프록시, 장애 시 fail-closed 여부를 포함해 복구를 훈련하세요. ZTA 성공 여부는 mTLS 유무가 아니라 정의된 접근 정책과 검증 가능한 운영 결과로 판단해야 합니다.

가상 상황: 인증서는 유효하지만 장치 상태가 오래된 경우

관리형 노트북이 유효한 mTLS 인증서를 제시했지만, 최근 보안 상태 확인이 누락된 채 내부 배포 서비스에 접근한다고 가정해 보세요. 인증서 검증은 연결 상대의 신원을 확인하는 입력으로만 사용하고, 배포 권한은 사용자 신원·장치 상태·요청한 리소스를 함께 평가하는 정책으로 결정합니다. 정책이 장치 상태 미확인을 거부하도록 정했다면 기대 결과는 게이트웨이가 요청을 차단하고 그 이유를 기록하는 것입니다. 이는 정책 판단을 설명하는 가상 사례이며 실제 제품의 동작을 주장하지 않습니다. (NIST SP 800-207)

참고 자료