부하 분산기가 Google Cloud내의 백엔드에 연결할 때, 부하 분산기는 백엔드에서 제시하는 모든 인증서를 수락합니다. 이 경우 부하 분산기는 인증서 유효성 검사를 수행하지 않습니다.
백엔드 인증 TLS 또는 백엔드 인증을 사용하면 부하 분산기가 연결되는 백엔드의 ID를 확인할 수 있습니다. 또한 백엔드 mTLS를 사용하면 부하 분산기가 클라이언트 TLS 인증서를 사용하여 백엔드에 ID를 추가로 증명할 수 있습니다.
다음 다이어그램은 각 경우의 부하 분산기 역할에 중점을 두어 프런트엔드와 백엔드 mTLS의 차이점을 보여줍니다. 프런트엔드 mTLS에서 부하 분산기는 서버 역할을 하여 클라이언트의 ID를 확인합니다. 백엔드 mTLS에서 부하 분산기는 클라이언트 역할을 하여 백엔드에 ID를 증명합니다.
mTLS는 프런트엔드와 백엔드에서 독립적으로 작동합니다. 프런트엔드, 백엔드 또는 프런트엔드와 백엔드 모두에서 mTLS를 구성할 수 있습니다.
이 문서에서는 백엔드 mTLS와 함께 백엔드 인증 TLS를 간략하게 설명합니다. 프런트엔드 mTLS에 관한 자세한 내용은 상호 TLS 개요를 참고하세요.
백엔드 인증 TLS 및 백엔드 mTLS는 전역 외부 애플리케이션 부하 분산기의 백엔드 서비스 리소스에서 구성할 수 있습니다.
기능
mTLS는 공개 키 인프라 (PKI)를 사용하여 네트워크를 통해 통신하는 항목의 ID를 인증합니다. 인프라에는 클라이언트, 서버, 인증 기관 (CA)의 세 가지 구성요소가 포함됩니다. 백엔드 인증 TLS 및 백엔드 mTLS는 애플리케이션 부하 분산기에 다음 기능을 추가합니다.
부하 분산기는 백엔드에서 제공하는 인증서를 자체 신뢰 앵커와 비교하여 유효성을 검사할 수 있습니다. 여러 신뢰 앵커를 업로드하여 다운타임 없이 이전 PKI에서 새 PKI로 원활하게 이전할 수 있습니다.
부하 분산기는 공개 신뢰 루트 (웹 PKI)를 기준으로 백엔드의 TLS 인증서를 확인할 수 있습니다.
백엔드 인증서 검증 경로를 구성하는 데 도움이 되도록 신뢰 앵커 외에도 중간 인증서를 구성할 수 있습니다. 중간 인증서를 사용하면 백엔드 서버에서 전체 인증서 체인을 제공할 필요가 없습니다.
백엔드 서비스의 TLS 서버 이름 표시 (SNI) 호스트 이름을 구성할 수 있습니다. TLS 핸드셰이크 중에 부하 분산기는 백엔드로 전송하는
ClientHello
메시지에 이 SNI 호스트 이름을 포함합니다. 그러면 백엔드가 TLS 인증서로 응답하고 부하 분산기는 이 인증서의 주체 대체 이름(SAN) 필드 중 하나 이상이 백엔드 서비스에 구성된 호스트 이름 또는 SAN 필드와 일치하는지 확인합니다.부하 분산기가 백엔드에 ID를 증명할 수 있도록 mTLS를 사용하도록 부하 분산기의 백엔드 서비스를 구성할 수 있습니다. 이 인증은 부하 분산기가 백엔드에 제공하는 클라이언트 (부하 분산기) 인증서를 사용하여 실행됩니다.
인증서 요구사항
백엔드 인증 TLS 및 백엔드 mTLS용 인증서를 구성할 때 다음 요구사항을 준수하는지 확인합니다.
최신 암호화 도구는 mTLS 인증의 기반을 형성합니다. 인증서는 키 교환에 RSA 또는 ECDSA 알고리즘을 사용해야 합니다. 해싱 알고리즘은 SHA-256 또는 더 강력한 암호화 해시 함수를 사용해야 합니다. MD4, MD5, SHA-1과 같은 해싱 알고리즘은 지원되지 않습니다.
백엔드에서 제공하는 리프 서버 인증서에는 다음과 같은 요구사항이 있습니다.
백엔드 mTLS에 사용되는 리프 클라이언트 (부하 분산기) 인증서의 경우 인증서가 인증서 관리자 인증서 리소스여야 합니다. 이 인증서의 범위는
client-auth
여야 합니다. 이는 이 인증서가 백엔드 mTLS에서 클라이언트 인증서로 사용됨을 나타냅니다.백엔드 인증 TLS와 함께 사용되는 루트 및 중간 인증서에는 다음과 같은 요구사항이 있습니다.
백엔드 인증 TLS 및 백엔드 mTLS의 주요 구성요소
백엔드 인증 TLS를 사용하면 부하 분산기가 연결되는 백엔드의 ID를 확인할 수 있습니다. HTTPS 또는 HTTP/2를 백엔드 서비스 프로토콜로 사용하는 HTTP(S) 부하 분산기에서 백엔드 인증 TLS를 구성할 수 있습니다. 백엔드 인증 TLS를 구성하지 않으면 부하 분산기는 백엔드의 모든 인증서를 허용합니다. 백엔드 mTLS를 사용하면 백엔드에 자체 클라이언트 인증서를 제공하도록 부하 분산기를 추가로 구성할 수 있습니다. 백엔드는 이 인증서를 사용하여 부하 분산기를 인증할 수 있습니다.
백엔드 인증 TLS를 구성하려면 다음을 실행해야 합니다.
- 트러스트 구성 리소스를 만듭니다.
- 백엔드 인증 구성 리소스를 만듭니다.
- 백엔드 서비스의 TLS 설정 속성을 백엔드 인증 구성 리소스로 업데이트합니다.
백엔드 mTLS를 구성하려면 클라이언트 인증서를 만들고 클라이언트 인증서를 백엔드 인증 구성 리소스에 연결해야 합니다. 백엔드 인증 구성 리소스가 생성된 후에는 클라이언트 인증서를 연결할 수 없습니다.
다음 다이어그램은 애플리케이션 부하 분산기의 백엔드 서비스에 연결되어 백엔드 인증 TLS 및 백엔드 mTLS를 사용 설정하는 다양한 구성요소를 보여줍니다.
다음 정보에서는 백엔드 인증 TLS 및 백엔드 mTLS를 구성하는 데 사용되는 다양한 구성요소에 관한 개요를 제공합니다.
트러스트 구성
백엔드가 부하 분산기에 제공하는 서버 인증서를 인증하려면 부하 분산기를 백엔드 인증서 발급자에 대한 신뢰 체인을 설정하는 X.509 인증서로 구성해야 합니다. 전체 트러스트 구성을 표현하고 단일 트러스트 저장소를 포함하는 TrustConfig
리소스를 사용하여 트러스트 구성을 구성합니다.
트러스트 저장소는 신뢰 앵커(루트 인증서)와 하나 이상의 중간 인증서(선택사항)를 캡슐화합니다. 신뢰 앵커는 신뢰할 수 있는 루트를 나타내는 인증서입니다. 유효한 서버 인증서는 신뢰 저장소의 일부 신뢰 앵커로 돌아가는 신뢰 체인을 보여야 합니다.
중간 인증서는 트러스트 저장소의 신뢰 앵커로 다시 연결되는 신뢰 체인의 일부인 인증서입니다. 리프 인증서에 포함된 추가 중간 CA와 함께 검증 프로세스 중에 신뢰 체인을 빌드하는 데 사용됩니다. 중간 인증서를 만드는 것은 선택사항입니다.
자체 서명되었거나, 만료되었거나, 지정된 신뢰 루트에 체이닝되지 않았거나, 유효성 검사에 실패한 인증서를 사용해야 하는 경우 이러한 인증서를 트러스트 구성의 허용 목록에 추가할 수 있습니다. 허용 목록에 추가할 수 있는 자체 서명 인증서를 만드는 것도 선택사항입니다.
신뢰 체인을 확인하는 데 인증서만 필요하므로 트러스트 저장소에는 비공개 키가 포함되어 있지 않습니다.
백엔드 인증 구성 리소스
부하 분산기의 백엔드 서비스에 연결된 백엔드 인증 구성 (BackendAuthenticationConfig
) 리소스를 사용하면 다음을 사용할 수 있습니다.
- 백엔드 인증 TLS (신뢰 구성 및 공개 신뢰 루트 사용)
- 백엔드 mTLS (클라이언트 인증서 사용)
백엔드 인증 TLS 및 백엔드 mTLS를 사용 설정하기 위해 백엔드 인증 구성 리소스는 다음 리소스를 가리킵니다.
신뢰 구성 (
trustConfig
): 백엔드에서 제공하는 서버 인증서를 확인하는 데 사용되는 연결된 신뢰 구성입니다.공개 신뢰 루트 (
wellKnownRoots
): 부하 분산기가 신뢰 구성에서 신뢰하는 인증서 외에도 공개 CA에서 발급한 백엔드 서버 인증서를 신뢰하는지 나타냅니다. 자세한 내용은 공개 신뢰 루트 사용을 참고하세요.클라이언트 인증서 (
clientCertificate
): 백엔드 연결에서 mTLS를 사용하는 경우 부하 분산기가 백엔드에 ID를 표현하는 데 사용하는 클라이언트 인증서입니다. 백엔드 인증 TLS (백엔드 인증)의 경우 이 필드는 비어 있을 수 있습니다. 이 경우 부하 분산기는 백엔드에 대해서만 인증하고 백엔드에 대해서는 인증하지 않습니다.
백엔드 서비스
백엔드 서비스 내에서 tlsSettings
속성은 백엔드 인증서를 검증하기 위해 다음 리소스를 가리킵니다.
- 백엔드 인증 구성 (
authenticationConfig
) - SNI 호스트 이름 (
sni
) - 허용되는 SAN (
subjectAltNames
)
tlsSettings
속성의 SNI (sni
) 및 SAN (subjectAltNames
) 필드는 부하 분산기가 인증서의 SAN 값을 기반으로 백엔드의 인증서를 확인하는 방식을 제어합니다. 이러한 필드는 백엔드 인증 TLS가 구성되었는지와 관계없이 유효성 검사 프로세스에 영향을 미칩니다.
SNI 필드가 설정된 경우 (tlsSettings.sni
) 부하 분산기는 다음을 실행합니다.
- TLS 핸드셰이크 중에 SNI 호스트 이름을 백엔드 서버로 전송합니다.
- 백엔드의 TLS 인증서에 SNI 호스트 이름과 일치하는 SAN이 포함되어 있는지 확인합니다.
기본적으로 부하 분산기는 백엔드의 TLS 인증서에 SNI 호스트 이름과 일치하는 SAN이 포함되어 있는지 확인합니다. 그러나 백엔드 서비스 (tlsSettings.subjectAltNames
)에 SAN이 구성된 경우 부하 분산기는 다음을 실행합니다.
- SAN 확인을 위해 SNI 호스트 이름을 무시합니다.
- 백엔드의 TLS 인증서에 백엔드 서비스에 구성된 허용된 SAN (
subjectAltNames
) 중 하나와 일치하는 SAN이 포함되어 있는지 확인합니다.
클라이언트 인증서
백엔드 인증 TLS (백엔드 인증) 외에도 부하 분산기가 백엔드에 ID를 증명할 수 있도록 mTLS를 사용하도록 부하 분산기의 백엔드 서비스를 구성할 수 있습니다. 이 인증은 부하 분산기가 백엔드에 제공하는 클라이언트 (부하 분산기) 인증서를 사용합니다.
백엔드 mTLS를 구성하려면 다음을 실행해야 합니다.
- 클라이언트 (부하 분산기) 인증서와 비공개 키가 포함된 클라이언트 인증서 리소스를 만듭니다.
- 클라이언트 인증서를 백엔드 인증 구성 리소스에 연결합니다.
백엔드 mTLS는 인증서 관리자를 통해 관리형 인증서를 구성할 때 Compute Engine 관리형 워크로드 아이덴티티와도 호환됩니다. 공개 PKI 관리형 인증서는 지원되지 않으며 모든 클라이언트 인증서는 client-auth
범위를 갖고 인증서 요구사항을 준수해야 합니다.
백엔드에서 클라이언트 인증서를 요청하는 경우 클라이언트 인증서를 수락하도록 구성해야 합니다. 백엔드가 부하 분산기의 연결을 거부하면 부하 분산기는 프록시하는 요청에 대해 HTTP 502
상태 코드를 반환하고 Cloud Logging에 일반 상태를 로깅합니다.
부하 분산기에서 백엔드 인증 TLS 및 백엔드 mTLS 구성
비공개 PKI 또는 공개 신뢰 루트를 사용하여 부하 분산기에서 백엔드 인증 TLS 및 백엔드 mTLS를 구성할 수 있습니다.
비공개 PKI 사용
다음은 비공개 PKI에서 발급된 인증서를 사용하여 부하 분산기에서 백엔드 인증 TLS 및 백엔드 mTLS를 구성하기 위해 따라야 하는 주요 단계를 간략히 설명한 것입니다. 비공개 PKI는 완전히 관리할 수 있고 공개 인터넷의 PKI 시스템과 격리된다는 이점이 있습니다.
신뢰 앵커 (루트 인증서)와 신뢰 루트 역할을 하는 중간 인증서로 구성된 트러스트 구성 리소스를 만듭니다.
백엔드 mTLS를 구성하려면 클라이언트 (부하 분산기) 인증서와 비공개 키가 포함된 클라이언트 인증서를 만듭니다.
트러스트 구성을 참조하는 백엔드 인증 구성 리소스를 만듭니다. 백엔드 mTLS를 구성하려면 백엔드 인증 구성 리소스가 트러스트 구성과 클라이언트 인증서를 모두 참조합니다.
백엔드 인증 구성 리소스를 부하 분산기의 백엔드 서비스에 연결합니다.
이 설정에 관해 자세히 알아보려면 다음 가이드를 참고하세요.
공개 신뢰할 수 있는 루트 사용
비공개 PKI에서 발급된 인증서를 사용하여 백엔드 인증 TLS를 사용 설정하는 것 외에도 공개 신뢰 루트를 사용하여 백엔드 인증서를 검증할 수도 있습니다.
공개 신뢰 루트를 사용하려면 트러스트 구성을 만들어 백엔드 인증 구성 리소스에 연결할 필요가 없습니다. 대신 백엔드 인증 구성 리소스의 wellKnownRoots
필드에 PUBLIC_ROOTS
를 값으로 설정해야 합니다. 하지만 트러스트 구성에서 신뢰하는 인증서 외에도 공개적으로 발급된 인증서의 루트를 명시적으로 포함하는 트러스트 구성을 만들 수도 있습니다.
PUBLIC_ROOTS
설정은 브라우저에서 신뢰하는 루트 CA 세트와 유사한 루트 CA 세트를 사용하며, 이 세트는 Google에서 관리하며 시간이 지남에 따라 변경될 수 있습니다. 이렇게 하면 이러한 루트가 변경될 때 백엔드 인증서가 유효하지 않게 될 위험이 있습니다. 공개적으로 발급된 인증서를 확인해야 하는 경우 잘 알려진 신뢰할 수 있는 CA를 선택하고 백엔드 인증서를 발급할 때 중간 교차 서명을 사용하여 루트 인증서가 만료되거나 취소될 위험을 완화하는 것이 좋습니다.
서버 인증서 검증 단계
백엔드 인증 TLS 또는 백엔드 인증 중에 서버 인증서를 확인할 때 부하 분산기는 다음을 실행합니다.
서버에 인증서의 비공개 키가 있는지 확인합니다.
서버는 비공개 키를 사용하여 정보에 서명하고 이를
CertificateVerify
메시지의 일부로 부하 분산기에 전송하여 부하 분산기에 표시하는 인증서와 연결된 비공개 키를 보유하고 있음을 증명합니다. 그러면 부하 분산기는 서버 인증서의 공개 키를 사용하여 이 서명을 확인합니다. 서명 확인에 실패하면 백엔드 서버에 인증서에 해당하는 비공개 키가 없음을 나타냅니다. 이 경우 부하 분산기는 오류를 기록하지 않고 TLS 핸드셰이크를 종료합니다.신뢰 체인을 확인합니다.
신뢰 구성에 신뢰 앵커가 하나 이상 포함되어 있거나
wellKnownRoots
속성이PUBLIC_ROOTS
로 설정된 경우 부하 분산기는 서버 인증서와 구성된 신뢰 앵커 간의 신뢰 체인을 확인하려고 시도합니다. 인증 확인에는 다음이 포함됩니다.- 백엔드의 서버 인증서, 중간 인증서 (제공된 경우), 구성된 루트 인증서가 인증서 요구사항을 준수합니다.
- 신뢰 체인의 모든 인증서에서 상위 인증서의 제목 필드는 하위 인증서의 발급자 필드와 일치합니다. 이 확인은 상위 인증서의 ID (주체)가 하위 인증서의 발급자로 등록된 ID와 동일한지 확인하는 데 도움이 됩니다.
- 신뢰 체인의 모든 인증서에서 상위 인증서의 주체 키 식별자 (SKID)는 하위 인증서의 권한 키 식별자 (AKID)와 일치합니다. 이 일치는 하위 인증서가 올바른 루트 기관에서 발급되었으며 인증서의 유효성을 확인하기 위해 AKID에서 루트의 공개 키가 참조되므로 신뢰할 수 있음을 확인합니다.
백엔드와 연결을 설정합니다.
인증서 유효성 검사에 성공하면 부하 분산기가 백엔드에 대한 연결을 진행합니다.
그러나 인증서 유효성 검사에 실패하면 부하 분산기는 백엔드 연결을 종료하고 HTTP
502
상태 코드를 클라이언트로 전송하며 종료 이유를 Cloud Logging에 로깅합니다. 인증서 유효성 검사 오류가 발생하면 후속 수신 요청이 부하 분산기를 트리거하여 백엔드 연결을 다시 시작합니다.백엔드 서버에서 연결을 거부하면 백엔드 연결이 실패할 수도 있습니다. 백엔드 mTLS의 경우 클라이언트 인증서가 잘못된 것으로 확인되어 이 문제가 발생할 수 있습니다. 백엔드에 대한 연결이 실패하면 부하 분산기는 프록시된 요청에 HTTP
502
상태 코드로 응답하고 Cloud Logging에 일반 오류 이유를 로깅합니다.
제한사항
백엔드 인증 TLS 및 백엔드 mTLS는 전역 외부 애플리케이션 부하 분산기에서만 구성할 수 있습니다. 기존 애플리케이션 부하 분산기는 백엔드 인증 TLS 및 백엔드 mTLS를 지원하지 않습니다.
백엔드 인증 TLS 및 백엔드 mTLS는 다음 백엔드 유형에 지원되지 않습니다.
전역 인터넷 NEG 백엔드
App Engine 백엔드
백엔드 mTLS를 사용 설정하려면 백엔드 인증 TLS도 구성해야 합니다.
백엔드 mTLS를 사용 설정하려면 백엔드 인증 구성 리소스를 구성하기 전에 클라이언트 인증서를 만들어야 합니다.
백엔드에서 사용하는 상태 점검은 TLS 인증 또는 mTLS 기능을 구현하지 않습니다. HTTP 또는 HTTPS 요청에 응답할 수 있는 상태 점검 엔드포인트로 백엔드를 구성해야 합니다.
부하 분산기가 백엔드에 연결할 때 프런트엔드 TLS 연결에서 클라이언트의 SNI 호스트 이름을 전달하지 않습니다. 그러나 백엔드는 커스텀 요청 헤더를 사용하여 클라이언트의 SNI 호스트 이름에 액세스할 수 있습니다.
백엔드 mTLS의 경우 클라이언트 인증서 키가 다음으로 제한됩니다.
- RSA 키는 2,048~4,096비트일 수 있습니다.
- ECDSA 키는 P-256 또는 P-384 곡선을 사용할 수 있습니다.
백엔드 인증 TLS는 인증서 취소 확인을 지원하지 않습니다.
할당량 및 한도
단일 트러스트 저장소는 최대 200개의 신뢰 앵커와 중간 인증서를 보유할 수 있으며, 중간 인증서의 경우 별도의 한도가 100개입니다. 중간 인증서는 최대 3개까지 동일한 제목 및 제목 공개 키 정보를 공유할 수 있습니다.
인증서 체인의 최대 깊이는 루트 및 리프 인증서를 포함하여 10개입니다. 신뢰 체인을 구축하려고 시도할 때 평가할 수 있는 중간 인증서의 최대 개수는 100개입니다.
백엔드 인증 TLS는 백엔드에서 수신한 인증서 체인을 16KB 이하 및 10개 인증서로 제한합니다.
검증에 사용되는 루트 인증서는 10개를 초과하는 이름 제약조건을 포함할 수 없습니다.
tlsSettings.subjectAltNames[]
필드에 허용되는 최대 주체 대체 이름 수는 5개입니다.