상호 TLS(mTLS)는 클라이언트와 서버 간의 상호 인증을 위한 업계 표준 프로토콜입니다. mTLS는 클라이언트와 서버가 모두 신뢰할 수 있는 인증 기관 (CA)에서 발급한 유효한 인증서를 보유하고 있는지 확인하여 서로 인증할 수 있도록 합니다. 서버만 인증되는 표준 TLS와 달리 mTLS에서는 클라이언트와 서버 모두 인증서를 제시하여 통신이 설정되기 전에 양 당사자의 ID를 확인해야 합니다.
mTLS는 모든 애플리케이션 부하 분산기의 대상 HTTPS 프록시 리소스에 구성됩니다.
- 전역 외부 애플리케이션 부하 분산기
- 기본 애플리케이션 부하 분산기
- 리전 외부 애플리케이션 부하 분산기
- 리전 내부 애플리케이션 부하 분산기
- 리전 간 내부 애플리케이션 부하 분산기
mTLS는 공개 키 인프라 (PKI)를 사용하여 네트워크를 통해 통신하는 항목의 ID를 인증합니다. 인프라에는 클라이언트, 서버, 인증 기관 (CA)이라는 세 가지 구성요소가 포함됩니다. 부하 분산기용 mTLS는 다음 기능을 지원합니다.
인증서를 제시하는 클라이언트가 비공개 키를 보유하고 있는지 확인합니다.
다음 두 가지 모드 중 하나로 클라이언트 인증서를 검증합니다.
잘못된 인증서 거부: 클라이언트 인증서 체인을 검증할 수 없는 경우 요청을 거부하여 엄격한 인증을 시행합니다.
잘못되거나 누락된 인증서 허용: 클라이언트 인증서가 누락되거나 잘못된 경우에도 모든 요청을 백엔드로 전달하여 유연성을 제공합니다.
업로드된 PKI 앵커 (루트 인증서)에 대해 클라이언트 인증서를 검증합니다. 다운타임 없이 이전 PKI에서 새 PKI로 원활하게 마이그레이션할 수 있도록 여러 앵커를 별도로 추가할 수 있는 옵션이 있습니다.
지정된 PKI 앵커 (루트 인증서)에 대해 클라이언트 인증서 유효성 검사 경로를 구성하는 데 도움이 되는 추가 중간 인증서를 제공합니다. 이러한 중간 인증서를 사용하면 mTLS가 전체 인증서 체인을 제공하지 않는 클라이언트와 함께 작동할 수 있습니다.
인증서의 지문을 생성하고 맞춤 요청 헤더로 백엔드에 전달합니다.
커스텀 헤더를 사용하여 인증서에서 추출된 선택한 필드를 백엔드로 전달합니다.
맞춤 헤더를 사용하여 검증 결과와 검증 오류를 백엔드에 전달합니다.
인증서 요구사항
mTLS용 인증서를 구성할 때는 다음 요구사항을 준수해야 합니다.
- 최신 암호화 도구는 mTLS 인증의 기반을 형성합니다. 인증서는 키 교환에 RSA 또는 ECDSA 알고리즘을 사용해야 합니다. 해싱 알고리즘은 SHA-256 또는 더 강력한 암호화 해시 함수를 사용해야 합니다. MD4, MD5, SHA-1과 같은 해싱 알고리즘은 지원되지 않습니다.
- 클라이언트(리프) 인증서의 경우:
- 루트 및 중간 인증서의 경우:
mTLS 배포 아키텍처
mTLS를 사용하면 트러스트 저장소가 포함된 트러스트 구성 리소스를 구성할 수 있습니다. 트러스트 저장소는 신뢰 앵커(루트 인증서)와 하나 이상의 중간 인증서(선택사항)를 캡슐화합니다. 부하 분산기는 클라이언트 인증서를 수신하면 클라이언트 인증서에서 구성된 신뢰 앵커로 다시 신뢰 체인을 설정하여 인증합니다.
다음은 부하 분산기에 mTLS를 설정하기 위해 구성해야 하는 다양한 리소스에 관한 간략한 개요입니다.
트러스트 구성 단일 트러스트 저장소 리소스를 포함하며, 이 리소스는 차례로 신뢰 앵커(루트 인증서)와 하나 이상의 중간 인증서(선택사항)를 캡슐화합니다. 신뢰 구성은 클라이언트 인증서와 신뢰 앵커 간의 신뢰 체인을 설정하는 데 사용됩니다. 자세한 내용은 트러스트 구성을 참고하세요.
선택적으로 자체 서명되었거나, 만료되었거나, 유효하지 않은 인증서를 사용해야 하는 경우 또는 루트 및 중간 인증서에 대한 액세스 권한이 없는 경우 해당 인증서를
allowlistedCertificates필드의 트러스트 구성에 추가할 수 있습니다. 허용 목록에 인증서를 추가하기 위해 트러스트 저장소가 필요하지 않습니다.허용 목록에 인증서를 추가하면 인증서가 파싱 가능하고, 비공개 키 소유 증명이 설정되었으며, 인증서의 SAN 필드에 대한 제약조건이 충족되는 한 인증서가 항상 유효한 것으로 간주됩니다.
트러스트 저장소. 신뢰 체인을 설정하고 클라이언트 인증서를 검증하는 데 사용되는 신뢰 앵커와 중간 인증 기관 (CA) 인증서를 포함합니다. CA는 클라이언트에 대해 신뢰 인증서를 발급하는 데 사용됩니다. CA는 부하 분산기의 신뢰 앵커(루트 인증서) 또는 중간 CA 인증서로 식별됩니다.
다음 유형의 루트 및 중간 인증서를 트러스트 저장소에 업로드할 수 있습니다.
- 원하는 서드 파티 CA에서 발급한 인증서
- 비공개 CA로 상호 TLS 설정에 설명된 대로 개발자가 관리하는 비공개 CA에서 발급한 인증서
- 사용자 제공 인증서로 상호 TLS 설정에 설명된 대로 사용자 제공 인증서
클라이언트 인증 (
ServerTLSPolicy라고도 함). 클라이언트 인증서 유효성을 검사할 때 사용할 클라이언트 유효성 검사 모드와 트러스트 구성 리소스를 지정합니다. 클라이언트가 부하 분산기에 잘못된 인증서를 제공하거나 인증서를 제공하지 않으면 클라이언트 검증 모드는 클라이언트 연결이 처리되는 방식을 지정합니다. 서버 TLS 정책에서 모든 mTLS 인증 관련 매개변수를 지정할 수 있습니다. 클라이언트 인증(ServerTLSPolicy) 리소스가 대상 HTTPS 프록시 리소스에 연결됩니다.
다음 다이어그램은 전역 및 리전 애플리케이션 부하 분산기의 대상 HTTPS 프록시 리소스에 연결된 다양한 mTLS 구성요소를 보여줍니다.
전역
다음 다이어그램은 외부 애플리케이션 부하 분산기 배포의 구성요소를 보여줍니다. 이 아키텍처는 전역 구성요소를 사용하는 내부 애플리케이션 부하 분산기인 리전 간 내부 애플리케이션 부하 분산기에도 적용됩니다.
리전
다음 다이어그램은 리전별 내부 애플리케이션 부하 분산기 배포의 구성요소를 보여줍니다. 이 아키텍처는 리전 구성요소를 사용하는 외부 애플리케이션 부하 분산기인 리전 외부 애플리케이션 부하 분산기에도 적용됩니다.
클라이언트 검증 모드
클라이언트가 부하 분산기에 잘못된 인증서를 제공하거나 인증서를 제공하지 않으면 클라이언트 인증(ServerTLSPolicy) 리소스의 clientValidationMode 속성은 부하 분산기가 클라이언트 연결을 처리하는 방법을 지정합니다.
클라이언트 유효성 검사 모드의 값은 다음과 같습니다.
ALLOW_INVALID_OR_MISSING_CLIENT_CERT. 클라이언트 인증서 검증에 실패했거나 클라이언트 인증서가 제공되지 않은 경우에도 클라이언트의 연결을 허용합니다. 이 모드에서 부하 분산기는 신뢰 체인을 설정할 수 있는지와 관계없이 클라이언트의 연결을 허용하고 모든 요청을 백엔드로 전달합니다.클라이언트 인증서가 제공되면 비공개 키의 소유 증명은 항상 확인됩니다. 클라이언트가 비공개 키를 보유하고 있음을 증명할 수 없는 경우 클라이언트 유효성 검사 모드에서 잘못된 클라이언트 인증서 또는 누락된 클라이언트 인증서를 허용하더라도 TLS 핸드셰이크가 종료됩니다.
REJECT_INVALID. 클라이언트가 인증서를 제공하지 않거나 인증서 검증에 실패하면 연결을 거부합니다. 이 모드에서 부하 분산기는 클라이언트 인증서에서 신뢰 앵커로 신뢰 체인을 설정할 수 없는 경우 클라이언트의 연결을 종료합니다.
부하 분산기에서 mTLS 구성
다음은 부하 분산기에서 mTLS를 구성하기 위해 따라야 하는 주요 단계를 간략하게 설명합니다.
신뢰 앵커 (루트 인증서)와 신뢰 루트 역할을 하는 중간 인증서로 구성된 트러스트 구성 리소스를 만듭니다.
트러스트 구성을 클라이언트 인증(
ServerTLSPolicy) 리소스에 연결합니다. 이 리소스는 클라이언트 유효성 검사 모드(ALLOW_INVALID_OR_MISSING_CLIENT_CERT또는REJECT_INVALID)를 정의합니다.클라이언트 인증 (
ServerTLSPolicy) 리소스를 부하 분산기의 대상 HTTPS 프록시 리소스에 연결합니다.선택사항: 커스텀 mTLS 헤더를 사용하여 mTLS 연결에 대한 정보를 백엔드 서비스 또는 URL 맵에 전달할 수 있습니다.
이 설정에 관해 자세히 알아보려면 다음 가이드를 참고하세요.
클라이언트 인증서 검증 단계
클라이언트 인증서를 검증할 때 부하 분산기는 다음을 실행합니다.
클라이언트가 비공개 키를 보유하고 있는지 확인합니다.
클라이언트는 핸드셰이크 프로세스 중에 서명을 생성하여 인증서의 공개 키와 연결된 비공개 키를 보유하고 있음을 증명합니다. 부하 분산기는 클라이언트의 공개 키를 사용하여 이 서명을 확인합니다. 서명 확인에 실패하면 클라이언트가 인증서 소유자가 아닙니다. 이 경우 구성에서 잘못되었거나 누락된 클라이언트 인증서를 허용하더라도 TLS 핸드셰이크가 종료됩니다. 전역 외부 애플리케이션 부하 분산기에는 오류가 로깅되지 않지만 리전 외부 애플리케이션 부하 분산기 및 내부 애플리케이션 부하 분산기의
proxyStatus필드에는 TLS 오류가 로깅됩니다.신뢰 체인을 확인합니다.
부하 분산기는 클라이언트 인증서와 구성된 신뢰 구성 간의 신뢰 체인을 확인합니다. 인증 확인에는 다음이 포함됩니다.
- 클라이언트, 중간, 루트 인증서가 인증서 요구사항을 준수합니다.
- 상위 인증서의 제목 필드는 하위 인증서의 발급기관 필드와 일치합니다. 이 확인을 통해 상위 인증서의 ID (제목)가 하위 인증서의 발급자로 등록된 ID와 동일한지 확인할 수 있습니다.
- 상위 인증서의 주체 키 식별자 (SKID)는 하위 인증서의 권한 키 식별자 (AKID)와 일치합니다. 이 일치는 하위 인증서가 올바른 루트 기관에서 발급되었으며 인증서의 유효성을 확인하기 위해 AKID에서 루트의 공개 키가 참조되므로 신뢰할 수 있음을 확인합니다.
- 하위 인증서의 주체 대체 이름 (SAN)이 상위 인증서의
NameConstraints필드를 위반하지 않습니다.
요청을 백엔드로 전달합니다.
클라이언트 인증서 유효성 검사에 성공하면 커스텀 mTLS 헤더를 사용하여 요청이 백엔드로 전달됩니다.
그러나 유효성 검사에 실패하면 취해지는 조치는 클라이언트 유효성 검사 모드의 값에 따라 다릅니다.
ALLOW_INVALID_OR_MISSING_CLIENT_CERT: 요청이 검증 실패 이유를 나타내는 커스텀 mTLS 헤더와 함께 전달됩니다. 리전 간 내부 애플리케이션 부하 분산기, 리전 외부 애플리케이션 부하 분산기, 리전 내부 애플리케이션 부하 분산기의 경우 커스텀 mTLS 헤더 외에도 mTLS 선택적 필드를 구성하여 장애 원인을 확인할 수 있습니다.REJECT_INVALID: 연결이 종료되고 Cloud Logging에 오류가 로깅됩니다.
백엔드로 전달된 커스텀 mTLS 헤더
다음 표는 클라이언트 인증서가 검증을 통과하거나 실패할 때 백엔드로 전달되는 커스텀 mTLS 헤더를 보여줍니다. 클라이언트 인증서가 검증에 실패하면 클라이언트 검증 모드가 ALLOW_INVALID_OR_MISSING_CLIENT_CERT로 설정된 경우에만 커스텀 헤더가 백엔드로 전달됩니다.
| 클라이언트 인증서 상태 | 클라이언트 검증 모드 | 맞춤 헤더 |
|---|---|---|
클라이언트 인증서 체인이 너무 깁니다(클라이언트 인증서에 포함된 중간 인증서 10개 초과). |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
클라이언트 또는 중간 인증서에 잘못된 RSA 키 크기가 있습니다. 유효성 검사가 수행되지 않습니다. RSA 키는 2,048~4,096비트일 수 있습니다. |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
클라이언트 또는 중간 인증서는 지원되지 않는 타원 곡선을 사용하고 있습니다. 유효성 검사가 수행되지 않습니다. 유효한 타원 곡선은 P-256과 P-384입니다. |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
클라이언트 또는 중간 인증서가 RSA가 아니거나 ECDSA가 아닌 알고리즘을 사용합니다. 유효성 검사가 수행되지 않습니다. |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
검증에 사용되는 PKI에는 동일한 제목 및 제목 공개 키 정보를 공유하는 중간 인증서가 10개 이상 있습니다. 유효성 검사가 수행되지 않습니다. |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
검증을 위해 제공된 중간 인증서에 이름 제약조건이 10개를 초과합니다. |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
클라이언트 인증서에 |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
| 인증서 체인을 검증하는 동안 시간이 초과되었습니다. | ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
client_cert_sha256_fingerprint: <cert hash>
|
인증서 체인을 검증하는 동안 깊이 또는 반복 한도에 도달합니다. 루트 및 클라이언트 인증서를 포함하여 인증서 체인의 최대 깊이는 10입니다. 최대 반복 횟수는 100입니다(클라이언트 인증서 체인 검증을 위해 확인된 인증서). |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
검증을 수행할 수 없지만 인증서 해시가 백엔드로 전달됩니다. |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
| 클라이언트 인증서가 없습니다. | ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
클라이언트 인증서가 TrustConfig 리소스에 대한 검증에 실패합니다.
|
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
| 클라이언트 인증서는 인증서 확인자 검증을 통과합니다. | 해당 없음 |
client_cert_error: <empty>
|
오류 처리 및 로깅
애플리케이션 부하 분산기는 클라이언트 인증서 유효성 검사를 모니터링하고 잠재적 문제를 식별하며 연결 문제를 해결할 수 있는 상세한 로깅 기능을 제공합니다. 이 섹션에서는 mTLS 유효성 검사 중에 발생할 수 있는 다양한 유형의 오류와 로깅 방법을 간략하게 설명합니다.
REJECT_INVALID 모드에서 로깅된 오류
클라이언트 인증서 검증에 실패하고 클라이언트 검증 모드가 REJECT_INVALID로 설정된 경우 연결이 종료되고 오류가 Cloud Logging에 로깅됩니다. 이러한 오류는 다음 표에 설명되어 있습니다.
| 클라이언트 인증서 상태 | 기록된 오류 |
|---|---|
| 클라이언트 인증서 체인이 너무 깁니다(클라이언트 인증서에 포함된 중간 인증서 10개 초과). |
client_cert_chain_exceeded_limit
|
클라이언트 또는 중간 인증서에 잘못된 RSA 키 크기가 있습니다. 유효성 검사가 수행되지 않습니다. RSA 키는 2,048~4,096비트일 수 있습니다. |
client_cert_invalid_rsa_key_size
|
클라이언트 또는 중간 인증서는 지원되지 않는 타원 곡선을 사용하고 있습니다. 유효성 검사가 수행되지 않습니다. 유효한 곡선은 P-256과 P-384입니다. |
client_cert_unsupported_elliptic_curve_key
|
클라이언트 또는 중간 인증서가 RSA가 아니거나 ECDSA가 아닌 알고리즘을 사용합니다. 유효성 검사가 수행되지 않습니다. |
client_cert_unsupported_key_algorithm
|
검증에 사용되는 PKI에는 동일한 제목 및 제목 공개 키 정보를 공유하는 중간 인증서가 10개 이상 있습니다. 유효성 검사가 수행되지 않습니다. |
client_cert_pki_too_large
|
검증을 위해 제공된 중간 인증서에 이름 제약조건이 10개를 초과합니다. |
|
클라이언트 인증서에 |
|
| 인증서 체인을 검증하는 동안 시간이 초과되었습니다. |
client_cert_validation_timed_out
|
인증서 체인을 검증하는 동안 깊이 또는 반복 한도에 도달합니다. 루트 및 클라이언트 인증서를 포함하여 인증서 체인의 최대 깊이는 10입니다. 최대 반복 횟수는 100입니다(클라이언트 인증서 체인 검증을 위해 확인된 인증서) |
client_cert_validation_search_limit_exceeded
|
TrustConfig 리소스를 설정하지 않고 mTLS를 구성했습니다.
|
client_cert_validation_not_performed
|
| 클라이언트가 핸드셰이크 중에 요청된 인증서를 제공하지 않았습니다. |
client_cert_not_provided
|
클라이언트 인증서가 TrustConfig 리소스를 사용한 검증에 실패합니다.
|
client_cert_validation_failed
|
종료된 연결에서 로깅된 오류
클라이언트 유효성 검사 모드가 ALLOW_INVALID_OR_MISSING_CLIENT_CERT 또는 REJECT_INVALID로 설정되면 특정 오류로 인해 연결이 닫히고 Cloud Logging에 기록됩니다. 이러한 오류는 다음 표에 설명되어 있습니다.
| 클라이언트 인증서 상태 | 요청 | 기록된 오류 |
|---|---|---|
| 클라이언트 인증서가 핸드셰이크 중에 서명 일치에 실패합니다. | SSL 핸드셰이크 종료 | 없음 |
| 서비스가 인증서 체인 검증을 수행할 수 없습니다. | 연결 종료 |
client_cert_validation_unavailable
|
| 인증서 체인을 확인하는 중에 내부 오류가 발생했습니다. | 연결 종료 |
client_cert_validation_internal_error
|
일치하는 TrustConfig를 찾을 수 없습니다.
|
연결 종료 |
client_cert_trust_config_not_found
|
| 클라이언트 인증서 페이로드(중간 인증서 포함)가 너무 큽니다(16KB 초과). | 연결 종료 |
client_cert_exceeded_size_limit
|
백엔드 서비스에 로깅이 사용 설정되어 있으면 mTLS 클라이언트 인증서 유효성 검사 중에 닫힌 연결에 대한 로깅된 오류를 확인할 수 있습니다.
제한사항
부하 분산기는 클라이언트 인증서에 대한 취소 확인을 수행하지 않습니다.
애플리케이션 부하 분산기를 사용하면 신뢰 앵커 최대 100개, 중간 인증서 100개, 허용 목록에 추가된 인증서 500개가 포함된 단일 트러스트 저장소가 있는 트러스트 구성을 업로드할 수 있습니다. 모든 중간 인증서에는 동일한 주제 및 주제 공개 키 정보를 공유하는 인증서가 3개를 초과하면 안 됩니다. 자세한 내용은 할당량 및 한도를 참조하세요.
루트 및 클라이언트 인증서를 포함하여 인증서 체인의 최대 깊이는 10입니다. 신뢰 체인을 구축하려고 시도할 때 중간 인증서를 평가할 수 있는 최대 시도 횟수는 100입니다. 자세한 내용은 할당량 및 제한을 참조하세요.
클라이언트에서 업로드 및 전달된 인증서의 키는 다음으로 제한됩니다.
- RSA 키는 2,048~4,096비트일 수 있습니다. 자세한 내용은 할당량 및 제한을 참조하세요.
- ECDSA 키는 P-256 또는 P-384 곡선을 사용할 수 있습니다.
클라이언트에서 수신된 허용되는 인증서 체인은 최대 16KB 및 10개의 인증서로 제한됩니다. 자세한 내용은 할당량 및 한도를 참조하세요.
검증에 사용되는 루트 인증서는 10개를 초과하는 이름 제약조건을 포함할 수 없습니다. 자세한 내용은 할당량 및 한도를 참조하세요.