Autorizar com certificados SSL/TLS

Nesta página, descrevemos como usar a Secure Socket Layer (SSL), agora Transport Layer Security (TLS), no seu aplicativo para criptografar conexões com instâncias do Cloud SQL.

Visão geral

O Cloud SQL aceita conexão a uma instância usando o protocolo SSL/TLS. As conexões SSL/TLS oferecem uma camada de segurança criptografando dados em trânsito entre o cliente e o banco de dados na instância do Cloud SQL. Opcionalmente, sua conexão SSL/TLS pode realizar a verificação de identidade do servidor validando o certificado do servidor instalado na instância do Cloud SQL e a verificação de identidade do cliente validando o certificado do cliente instalado no cliente.

Certificados do servidor

Quando você cria uma instância, o Cloud SQL cria e instala automaticamente um certificado de servidor assinado por uma autoridade certificadora (AC). É possível fazer o download do certificado da AC na máquina host do cliente e usá-lo para verificar a identidade da AC e do servidor do Cloud SQL. Opcionalmente, você pode escolher o tipo de AC que o Cloud SQL usa para assinar o certificado do servidor.

Certificados do cliente

Você pode criar e fazer o download de certificados do cliente com chaves para a máquina host do cliente para autenticação mútua (verificação de identidade do servidor e do cliente). Não é possível escolher o tipo de AC usado pelo Cloud SQL para assinar o certificado do cliente.

Conectar usando SSL/TLS

Ao se conectar a uma instância do Cloud SQL de clientes, é possível usar SSL/TLS para conexões diretas e para conexões que usam o proxy de autenticação do Cloud SQL ou os conectores de linguagem do Cloud SQL.

  • Para conexões diretas, o Google recomenda fortemente aplicar a criptografia SSL/TLS usando a configuração do modo SSL no Cloud SQL. Também é possível aplicar a verificação de certificado do cliente. Para mais informações, consulte Aplicar criptografia SSL/TLS.

  • Para conexões que usam o proxy de autenticação do Cloud SQL ou os conectores de linguagem do Cloud SQL, as conexões são criptografadas automaticamente com SSL/TLS e verificação de identidade do cliente e do servidor, sem a necessidade de fazer o download de um certificado de AC do servidor e do cliente.

Para mais informações sobre as opções de conectividade do Cloud SQL, consulte Sobre as conexões do Cloud SQL.

Para mais informações sobre a configuração SSL/TLS do lado do cliente, consulte a documentação do mecanismo de banco de dados.

Hierarquias de autoridades certificadoras (ACs)

Esta seção descreve os dois tipos de autoridade certificadora (CA) do servidor que você pode escolher para suas instâncias do Cloud SQL. Você tem duas opções:

  • AC por instância: com essa opção, uma AC interna dedicada a cada instância do Cloud SQL assina o certificado do servidor para essa instância. O Cloud SQL cria e gerencia essas ACs. Para escolher a AC por instância, especifique GOOGLE_MANAGED_INTERNAL_CA para a configuração serverCaMode (API Cloud SQL Admin) ou a flag --server-ca-mode (gcloud CLI) ao criar a instância. Se você não especificar a configuração ou a flag, essa opção será o valor padrão da instância.

  • AC compartilhada: com essa opção, é usada uma hierarquia de ACs que consiste em uma AC raiz e ACs de servidor subordinadas. As ACs de servidor subordinado em uma região assinam os certificados do servidor e são compartilhadas entre as instâncias da região. O Cloud SQL hospeda e gerencia as ACs raiz e subordinadas do servidor no Certificate Authority Service do Google Cloud. O Cloud SQL também processa a rotação de ACs raiz e ACs de servidores subordinados e disponibiliza links disponíveis publicamente para os pacotes de certificados de AC para download. Para escolher uma AC compartilhada, especifique GOOGLE_MANAGED_CAS_CA para a configuração serverCaMode (API Cloud SQL Admin) ou a flag --server-ca-mode (gcloud CLI) ao criar a instância.

Depois de criar uma instância, é possível conferir qual hierarquia de AC está configurada para uma instância do Cloud SQL usando o comando gcloud sql instances describe. Para mais informações, consulte Acessar informações da instância.

A tabela a seguir compara as duas opções de hierarquia de AC.

Recurso AC por instância AC compartilhada
Estrutura de AC Autoridade certificadora separada para cada instância CA raiz e CAs subordinadas compartilhadas entre instâncias na mesma região
Atributos criptográficos Chave RSA de 2048 bits com algoritmo SHA256 Algoritmo de assinatura digital de curva elíptica (ECDSA) com chave de 384 bits e algoritmo SHA384
Período de validade do certificado digital 10 anos 25 anos para a AC raiz e 10 anos para as ACs subordinadas
Período de validade do certificado do servidor 10 anos 1 ano
Rotação de AC iniciada pelo usuário? Sim Não. A rotação de CA é gerenciada pelo Cloud SQL.
Rotação de certificado do servidor iniciada pelo usuário? Sim Sim
Âncora de confiança da AC para conexões TLS A AC exclusiva por instância é a âncora de confiança da instância correspondente. A AC raiz e as ACs subordinadas são as âncoras de confiança de todas as instâncias em uma determinada região.
Verificação de identidade do servidor A verificação da AC verifica a identidade do servidor, já que cada instância tem uma AC exclusiva. A verificação do nome do host e da AC é necessária para a verificação de identidade do servidor, já que as ACs do servidor são compartilhadas entre as instâncias.
Campo "Nome alternativo do assunto" (SAN, na sigla em inglês) em certificados de servidor O campo SAN contém o nome do host (nome DNS da instância) apenas para instâncias ativadas com o Private Service Connect. O nome do host pode ser usado para verificação de identidade do servidor. Se você estiver se conectando a uma instância do Cloud SQL usando o nome DNS como nome de host, será necessário configurar a resolução de DNS. O campo SAN contém o nome do host (nome DNS da instância) para todos os tipos de instâncias. O nome do host pode ser usado para a verificação de identidade do servidor. Se você estiver se conectando a uma instância do Cloud SQL usando o nome DNS como nome de host, será necessário configurar a resolução de DNS.

AC por instância hospedado pelo Cloud SQL

Essa hierarquia é a configuração padrão do modo de AC do servidor.

O Cloud SQL cria uma nova AC de servidor autoassinada para cada instância quando você cria a instância. Para usar essa configuração, configure serverCaMode como GOOGLE_MANAGED_INTERNAL_CA ou deixe a configuração indefinida ao criar a instância.

O diagrama a seguir mostra a hierarquia de ACs por instância.

Diagrama da hierarquia de ACs internas por instância.

ACs compartilhadas hospedadas pelo serviço de AC

Esse modo de AC do servidor consiste em uma AC raiz e ACs de servidor subordinadas em cada região. As ACs de servidor subordinado emitem certificados de servidor e são compartilhadas entre as instâncias na região. O Cloud SQL processa a rotação das ACs de servidor regionais compartilhadas e disponibiliza links para download dos pacotes de certificados de AC.

É possível configurar uma instância para usar uma hierarquia de AC do servidor em que as ACs emissoras são compartilhadas entre as instâncias na mesma região. Para usar essa configuração, configure serverCaMode como GOOGLE_MANAGED_CAS_CA ao criar a instância.

O diagrama a seguir mostra a hierarquia da AC compartilhada.

Diagrama de uma hierarquia de ACs compartilhada

Como funciona a rotação de certificados do servidor

O Cloud SQL oferece maneiras de alternar o certificado do servidor para que um novo seja criado antes que o antigo expire.

O comando de rotação a ser usado depende se você está usando um certificado do servidor emitido por uma AC por instância ou um certificado do servidor emitido pela AC compartilhada.

Cerca de três meses antes do vencimento do certificado do servidor em uma instância do Cloud SQL, os proprietários do projeto recebem um e-mail informando que o processo de mudança do certificado foi iniciado para aquela instância. O e-mail inclui o nome da instância e informa que o Cloud SQL adicionou um novo certificado do servidor ao projeto. O certificado do servidor continua funcionando normalmente. Na verdade, a instância tem dois certificados do servidor durante esse período.

Antes que o atual expire, faça o download do novo arquivo server-ca.pem, que contém as informações do certificado de servidor atual e do novo. Para que seus clientes do PostgreSQL usem o novo arquivo, ele deve ser copiado em todas as máquinas host do cliente do PostgreSQL, substituindo o arquivo atual.

Depois que todos os clientes do PostgreSQL forem atualizados, envie um comando de rotação (para ACs por instância) ou comando de rotação (para ACs compartilhadas) para a instância do Cloud SQL para alternar para o novo certificado do servidor. Depois disso, o certificado antigo não será mais reconhecido e somente o novo poderá ser usado.

Os certificados do cliente não são impactados pela mudança do certificado do servidor.

Vencimento do certificado SSL

Por padrão, as instâncias do Cloud SQL usam a configuração padrão de GOOGLE_MANAGED_INTERNAL_CA como serverCaMode. Os certificados SSL têm um período de validade de 10 anos. Antes que esses certificados venham a expirar, faça a rotação de AC.

Para instâncias que usam ACs compartilhadas (serverCaMode está definido como GOOGLE_MANAGED_CAS_CA), o período de validade dos certificados do servidor é de um ano. Antes do vencimento, faça a rotação do certificado SSL. O certificado da autoridade certificadora (AC) raiz tem um período de validade de 25 anos, e o certificado de AC compartilhado subordinado tem um período de validade de 10 anos. O Cloud SQL lida com a rotação delas.

Se um cliente estiver configurado para verificar a AC ou o nome do host no certificado do servidor, as conexões desse cliente com instâncias do Cloud SQL com certificados de servidor expirados vão falhar. Para evitar interrupções nas conexões do cliente, alterne o certificado do servidor antes que ele expire.

Seja no modo de CA por instância ou no modo de servidor de CA compartilhado, é possível redefinir a configuração SSL da sua instância do Cloud SQL a qualquer momento.

A seguir