SSL 인증서 개요

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

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

인증서 구성 방법

대상 HTTPS 프록시를 사용하는 애플리케이션 부하 분산기의 경우 부하 분산기의 대상 프록시가 1~15개의 Compute Engine SSL 인증서를 참조해야 합니다. 각 Compute Engine SSL 인증서 리소스에는 비공개 키, 해당 인증서, CA 인증서(선택사항)가 포함됩니다.

부하 분산기 지원

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

부하 분산기 인증서 구성 방법: 대상 프록시 참조...
Compute Engine SSL 인증서 Certificate Manager 인증서 맵 Certificate Manager 인증서로 직접
애플리케이션 부하 분산기(대상 HTTPS 프록시)
리전 외부 애플리케이션 부하 분산기 리전 인증서
자체 관리형
Google 관리형 지원 		자체 관리형
Google 관리형
리전 내부 애플리케이션 부하 분산기 리전 인증서
자체 관리형
Google 관리형 지원 		자체 관리형
Google 관리형

인증서 유형

부하 분산기에 자체 관리형 SSL 인증서를 만들 수 있습니다.

자체 관리형 SSL 인증서

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

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

Compute Engine SSL 인증서 리소스를 사용하여 자체 관리형 SSL 인증서를 만들 수 있습니다. 자세한 내용은 자체 관리형 SSL 인증서 사용을 참조하세요.

지원되는 키 유형

리전 자체 관리형 Compute Engine SSL 인증서에 지원되는 키 유형은 다음과 같습니다.

  • RSA-2048
  • RSA-3072
  • RSA-4096
  • ECDSA P-256
  • ECDSA P-384

ECDSA 키와 함께 인증서 사용

이 섹션에서는 인증서 서명 키의 권장사항으로 RSA보다 ECDSA를 권장하는 이유를 살펴봅니다.

사용할 키 유형

ECDSA P-256은 대부분의 TLS 인증서에 권장되는 키 유형으로, 강력한 암호화 보안과 함께 서명 작업의 뛰어난 성능 및 효율적인 네트워크 대역폭 사용을 제공합니다.

다른 인증서 키 유형을 사용해야 하는 몇 가지 이유는 다음과 같습니다.

  • ECDSA 인증서를 지원하지 않는 기존 클라이언트를 지원해야 하는 경우 ECDSA P-256 인증서 외에 RSA-2048 인증서를 제공할 수 있습니다.
  • 더 큰 키 크기 또는 특정 키 유형을 사용해야 하는 특정 규정 준수 요구사항이 있는 경우 ECDSA P-384, RSA-2048, RSA-3072, RSA-4096 키를 사용할 수 있습니다.

RSA 대신 ECDSA를 선택해야 하는 이유

ECDSA의 주요 장점은 RSA에 비해 훨씬 작은 키로 동등한 암호화 보안 수준을 제공할 수 있다는 점입니다. 이러한 효율성은 실질적인 성능 및 리소스 이점으로 이어집니다. 키가 작다고 보안이 약하다는 의미는 아닙니다. ECDSA는 타원 곡선 이산 로그 문제에 기반하며, 키 단위당 더 강력한 보안을 제공하고 경우에 따라 RSA보다 더 나은 계산 효율성을 제공합니다.

예를 들면 다음과 같습니다.

  • 256비트 ECDSA 키는 RSA-3072 키와 유사한 보안 수준을 제공합니다.
  • 384비트 ECDSA 키는 널리 지원되는 모든 RSA 키 크기보다 높은 보안 수준을 제공합니다.

ECDSA의 주요 이점은 다음과 같습니다.

  • 성능: ECDSA 서명 작업은 동등한 보안 수준을 제공하는 RSA 작업보다 계산 집약도가 훨씬 낮습니다. 이렇게 하면 CPU 부하와 지연 시간이 줄어들어 처리량이 높거나 지연 시간에 민감한 시스템에 매우 중요합니다.

  • 효율성: 키와 서명이 작을수록 대역폭과 저장공간이 적게 필요하므로 모바일 및 IoT 기기와 같이 리소스가 제한된 환경에 특히 유용합니다.

여러 SSL 인증서

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

자세한 내용은 부하 분산 문서의 대상 프록시 및 SSL 인증서를 참조하세요.

인증서 선택 프로세스

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

클라이언트가 부하 분산기에 연결하면 클라이언트와 부하 분산기가 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 협상이 실패합니다.

다음 단계