SSL 인증서 개요

SSL/TLS는 인터넷에서 가장 널리 사용되는 암호화 프로토콜입니다. 기술적으로 TLS는 SSL의 후속 버전이지만 이 문서에서와 같이 두 용어가 같은 의미로 사용되는 경우도 있습니다.

전송 계층 보안(TLS)은 네트워크를 통해 정보가 전송되는 동안 암호화하는 데 사용되며 클라이언트와 서버 또는 부하 분산기 간의 개인정보 보호를 제공합니다. SSL을 사용하는 애플리케이션 부하 분산기 또는 프록시 네트워크 부하 분산기에는 비공개 키와 SSL 인증서가 하나 이상 필요합니다.

참고: 이 페이지에서는 SSL을 사용하는 애플리케이션 부하 분산기 또는 프록시 네트워크 부하 분산기와 클라이언트 간에 전송 중인 SSL 인증서 및 암호화를 설명합니다. Google Cloud 부하 분산기와 백엔드 간에 전송 중인 데이터 암호화에 대한 자세한 내용은 백엔드 암호화를 참고하세요.

인증서 구성 방법

Google Cloud 는 대상 HTTPS 프록시를 사용하는 애플리케이션 부하 분산기와 대상 SSL 프록시를 사용하는 프록시 네트워크 부하 분산기에 세 가지 인증서 구성 방법을 제공합니다.

• 대상 프록시가 Compute Engine SSL 인증서 참조: 이 메서드를 사용하면 부하 분산기의 대상 프록시가 최대 15개의 Compute Engine SSL 인증서 리소스를 참조할 수 있습니다. 각 Compute Engine SSL 인증서 리소스에는 비공개 키, 해당 인증서, CA 인증서(선택사항)가 포함됩니다.

• 대상 프록시가 인증서 관리자 인증서 맵을 참조: 이 방법을 사용하면 부하 분산기의 대상 프록시가 단일 인증서 맵을 참조합니다. 인증서 맵은 기본적으로 수천 개의 항목을 지원하며 수백만 개의 항목으로 확장할 수 있습니다. 각 항목에는 비공개 키와 인증서 데이터가 포함됩니다.

• 대상 프록시가 인증서 관리자 인증서를 직접 참조: 이 방법을 사용하면 부하 분산기의 대상 프록시가 최대 100개의 인증서 관리자 인증서를 참조할 수 있습니다.

부하 분산기 지원

다음 표에는 각 부하 분산기에서 지원하는 인증서 구성 방법이 나와 있습니다.

부하 분산기	인증서 구성 방법: 대상 프록시 참조...
	Compute Engine SSL 인증서	인증서 관리자 인증서 맵	인증서 관리자 인증서 직접
애플리케이션 부하 분산기 (타겟 HTTPS 프록시)
전역 외부 애플리케이션 부하 분산기	전역 인증서 자체 관리형 Google 관리형을 지원합니다.	자체 관리형 Google 관리형
기본 애플리케이션 부하 분산기	전역 인증서 자체 관리형 Google 관리형을 지원합니다.	자체 관리형 Google 관리형
리전 외부 애플리케이션 부하 분산기	지역 인증서 자체 관리형 Google 관리형을 지원합니다.		자체 관리형 Google 관리형
리전 내부 애플리케이션 부하 분산기	지역 인증서 자체 관리형 Google 관리형을 지원합니다.		자체 관리형 Google 관리형
리전 간 내부 애플리케이션 부하 분산기			자체 관리형 Google 관리형
프록시 네트워크 부하 분산기 (타겟 SSL 프록시)
전역 외부 프록시 네트워크 부하 분산기	전역 인증서 자체 관리형 Google 관리형을 지원합니다.	자체 관리형 Google 관리형
기존 프록시 네트워크 부하 분산기	전역 인증서 자체 관리형 Google 관리형을 지원합니다.	자체 관리형 Google 관리형

구성 방법 규칙

Google Cloud 는 다음과 같은 인증서 구성 방법 규칙을 적용합니다.

• Compute Engine SSL 인증서와 Certificate Manager 인증서 맵을 모두 지원하는 부하 분산기: 부하 분산기의 대상 프록시는 인증서 맵과 하나 이상의 Compute Engine SSL 인증서를 동시에 참조할 수 있습니다. 그러나 이 경우 모든 Compute Engine SSL 인증서는 무시되고 인증서 맵의 인증서만 부하 분산기에서 사용됩니다.

• Compute Engine SSL 인증서와 직접 연결된 Certificate Manager 인증서를 모두 지원하는 부하 분산기의 경우: 부하 분산기의 대상 프록시는 최대 15개의 Compute Engine SSL 인증서 또는 최대 100개의 Certificate Manager 인증서를 참조하도록 구성할 수 있으며 둘 다를 조합하여 참조할 수는 없습니다.

인증서 유형

Google Cloud 는 자체 관리형 인증서와 Google 관리형 인증서를 모두 지원합니다.

자체 관리형 SSL 인증서

자체 관리형 SSL 인증서는 사용자가 직접 가져와 프로비저닝하고 갱신하는 인증서입니다. 자체 관리형 인증서는 다음 공개키 인증서 유형 중 하나일 수 있습니다.

• 도메인 유효성 검사(DV)
• 조직 유효성 검사(OV)
• 확장 유효성 검사(EV) 인증서

다음을 사용하여 자체 관리형 SSL 인증서를 만들 수 있습니다.

• Compute Engine SSL 인증서 리소스: 자세한 내용은 자체 관리형 SSL 인증서 사용을 참고하세요.

• 인증서 관리자: 자세한 내용은 다음을 참고하세요.

  • 전역 자체 관리형 인증서 배포

  • 리전별 자체 관리형 인증서 배포

Google 관리 SSL 인증서

Google 관리형 SSL 인증서는 Google에서 자동으로 가져오고 관리하며 갱신하는 인증서입니다. Google CloudGoogle 관리형 인증서는 항상 도메인 유효성 검사(DV) 인증서입니다. 인증서와 연결된 조직이나 개인의 ID를 보여주지 않습니다.

와일드 카드를 사용하는 Google 관리형 인증서는 DNS 승인을 사용하는 경우에만 Certificate Manager에서 지원됩니다.

다음을 사용하여 Google 관리형 SSL 인증서를 만들 수 있습니다.

• Compute Engine SSL 인증서 리소스: 글로벌 Compute Engine sslCertificates 리소스만 Google 관리형 SSL 인증서를 지원합니다. regionSslCertificates는 지원하지 않습니다. 자세한 내용은 Google 관리형 SSL 인증서 사용을 참고하세요.
• 인증서 관리자: 자세한 내용은 배포 개요를 참고하세요.

여러 SSL 인증서

애플리케이션 부하 분산기 또는 프록시 네트워크 부하 분산기는 대상 프록시가 지원되는 인증서 구성 방법을 사용하여 구성된 경우 두 개 이상의 SSL 인증서를 동시에 호스팅할 수 있습니다. 여러 SSL 인증서가 필요한 경우 Certificate Manager를 사용하는 것이 좋습니다.

• Compute Engine SSL 인증서를 지원하는 부하 분산기: 부하 분산기의 대상 프록시는 최대 15개의 Compute Engine SSL 인증서를 참조할 수 있습니다. 첫 번째로 참조된 Compute Engine SSL 인증서 리소스는 대상 프록시의 기본 (주요) 인증서입니다.

• 인증서 관리자 인증서 맵을 지원하는 부하 분산기의 경우: 부하 분산기의 대상 프록시는 단일 인증서 맵을 참조합니다. 인증서 맵은 수천 개의 인증서 맵 항목을 지원합니다. 인증서 맵의 기본 (주요) 인증서인 인증서 항목을 구성할 수 있습니다.

• 인증서 관리자 인증서 직접 참조를 지원하는 부하 분산기의 경우: 부하 분산기의 대상 프록시는 최대 100개의 인증서 관리자 인증서를 참조할 수 있습니다. 참조된 첫 번째 인증서 관리자 SSL 인증서 리소스는 대상 프록시의 기본 (주요) 인증서입니다.

자세한 내용은 다음을 참고하세요.

• 부하 분산 문서의 대상 프록시 및 SSL 인증서를 참고하세요.

• Certificate Manager 문서의 리소스 할당량 및 한도를 참고하세요.

인증서 선택 절차

다음 인증서 선택 프로세스는 대상 프록시가 여러 Compute Engine SSL 인증서 또는 여러 Certificate Manager 인증서를 참조하는 부하 분산기에 적용됩니다.

부하 분산기의 대상 프록시가 인증서 관리자 인증서 맵을 참조하는 경우 인증서 선택 프로세스가 다릅니다. 인증서 맵의 인증서 선택 프로세스에 관한 자세한 내용은 Certificate Manager 문서의 인증서 선택 로직을 참고하세요.

중요: 인증서 선택 프로세스는 notValidBefore 및 notValidAfter 속성을 고려하지 않습니다. 만료된 인증서가 구성된 경우 부하 분산기가 만료된 인증서를 제공할 수 있습니다. Google 관리형 인증서를 사용하면 이러한 상황을 방지할 수 있습니다.

클라이언트가 부하 분산기에 연결하면 클라이언트와 부하 분산기가 TLS 세션을 협상합니다. TLS 세션 협상 중에 클라이언트는 ClientHello에서 지원하는 TLS 암호화 목록을 부하 분산기에 전송합니다. 부하 분산기는 공개 키 알고리즘이 클라이언트와 호환되는 인증서를 선택합니다. 클라이언트는 이 협상의 일부로 서버 이름 표시 (SNI) 호스트 이름을 부하 분산기에 보낼 수도 있습니다. SNI 호스트 이름 데이터는 부하 분산기가 클라이언트에 보낼 인증서를 선택하는 데 도움이 되는 경우가 있습니다.

• 부하 분산기의 대상 프록시가 인증서를 하나만 참조하는 경우 해당 인증서가 사용되며 클라이언트에서 전송한 SNI 호스트 이름 값은 관련이 없습니다.

• 부하 분산기의 대상 프록시가 두 개 이상의 인증서를 참조하는 경우 부하 분산기는 다음 프로세스를 사용하여 단일 인증서를 선택합니다.

  • 클라이언트가 ClientHello에서 SNI 호스트 이름을 보내지 않으면 부하 분산기는 인증서 목록의 첫 번째 인증서를 사용합니다.

  • 클라이언트가 인증서 일반 이름 (CN)과 일치하지 않고 인증서 주체 대체 이름 (SAN)과 일치하지 않는 SNI 호스트 이름을 보내는 경우 부하 분산기는 인증서 목록의 첫 번째 인증서를 사용합니다.

  • 그 외의 모든 상황: 부하 분산기는 다음과 같은 일치 프로세스를 사용하여 인증서를 선택합니다.

    • 일치는 RSA 인증서보다 ECDSA 인증서를 선호하며 일반 이름 (CN)과 주체 대체 이름 (SAN) 인증서 속성 모두에 대해 가장 긴 접미사를 사용하여 수행됩니다.

    • 일치하는 방법을 설명하기 위해 다음 두 인증서를 참조하는 대상 프록시를 살펴보겠습니다.

      • 인증서 A

        • CN: cats.pets.example.com
        • SAN: cats.pets.example.com, *.pets.example.com, *.example.com

      • 인증서 B

        • CN: dogs.pets.example.com
        • SAN: dogs.pets.example.com, *.pets.example.com, *.example.com

    • 이제 다음 시나리오를 고려해 보세요.

      • 클라이언트에서 전송한 SNI 호스트 이름이 cats.pets.example.com인 경우 부하 분산기는 인증서 A를 사용합니다.
      • 클라이언트에서 전송한 SNI 호스트 이름이 ferrets.pets.example.com인 경우 정확한 일치가 없으므로 부하 분산기는 인증서 A 또는 인증서 B 중 하나를 선택합니다. 두 인증서 모두 SAN 목록에 *.pets.example.com이 포함되어 있기 때문입니다. 이 경우 선택되는 인증서를 제어할 수 없습니다.

• 인증서가 선택된 후 부하 분산기는 선택된 인증서가 클라이언트가 ClientHello에서 전송한 암호화와 호환되는 공개 키 알고리즘을 사용하는 경우에만 클라이언트에 해당 인증서를 전송합니다. 클라이언트가 부하 분산기가 선택한 인증서의 공개 키 알고리즘 (ECDSA 또는 RSA)을 포함하는 암호화 스위트를 지원하지 않으면 TLS 협상이 실패합니다.

가격 책정

부하 분산기를 사용할 때 네트워킹 요금이 발생합니다. Google Cloud 자세한 내용은 모든 네트워킹 가격 책정을 참고하세요. Certificate Manager 가격 책정에 대해서는 Certificate Manager 문서의 가격 책정을 참고하세요. Compute Engine SSL 인증서 리소스 사용에는 추가 요금이 발생하지 않습니다.

다음 단계

• 인증서 관리자 개요

• 백엔드 암호화

• 전송 중인 데이터 암호화 Google Cloud 백서

직접 사용해 보기

Google Cloud를 처음 사용하는 경우 계정을 만들어 Google 제품의 실제 성능을 평가해 보세요. 신규 고객에게는 워크로드를 실행, 테스트, 배포하는 데 사용할 수 있는 $300의 무료 크레딧이 제공됩니다.

무료로 시작하기