Autorize com certificados SSL/TLS

Esta página descreve como pode usar a camada de ligação segura (SSL), agora Transport Layer Security (TLS), a partir da sua aplicação para encriptar as ligações a instâncias do Cloud SQL.

Vista geral

O Cloud SQL suporta a ligação a uma instância através do protocolo SSL/TLS. As ligações SSL/TLS oferecem uma camada de segurança encriptando os dados em trânsito entre o cliente e a base de dados na instância do Cloud SQL. Opcionalmente, a sua ligação SSL/TLS pode efetuar a validação da identidade do servidor através da validação do certificado do servidor instalado na instância do Cloud SQL e a validação da identidade do cliente através da validação do certificado do cliente instalado no cliente.

Certificados de servidor

Quando cria uma instância, o Cloud SQL cria e instala automaticamente um certificado de servidor assinado por uma autoridade de certificação (AC). Pode transferir o certificado da AC para a máquina anfitriã do cliente e usá-lo para validar a identidade da AC e do servidor do Cloud SQL. Opcionalmente, pode escolher o tipo de AC que o Cloud SQL usa para assinar o certificado do servidor.

Certificados de cliente

Opcionalmente, pode criar e transferir certificados de cliente, juntamente com chaves para o computador anfitrião do cliente para autenticação mútua (validação de identidade do servidor e do cliente). Não pode escolher o tipo de AC que o Cloud SQL usa para assinar o certificado de cliente.

Ligue através de SSL/TLS

Quando se liga a uma instância do Cloud SQL a partir de clientes, pode usar SSL/TLS para ligações diretas, bem como para ligações que usam o proxy Auth do Cloud SQL ou os conetores de linguagem do Cloud SQL.

  • Para ligações diretas, a Google recomenda vivamente a aplicação da encriptação SSL/TLS através da definição do modo SSL no Cloud SQL. Opcionalmente, também pode aplicar a validação de certificados de cliente. Para mais informações, consulte o artigo Aplique a encriptação SSL/TLS.

  • Para ligações que usam o proxy Auth do Cloud SQL ou os conectores de linguagem do Cloud SQL, as ligações são encriptadas automaticamente com SSL/TLS, juntamente com a validação da identidade do cliente e do servidor, sem que tenha de transferir um certificado da AC do servidor e um certificado de cliente.

Para mais informações sobre as opções de conetividade do Cloud SQL, consulte o artigo Acerca das ligações do Cloud SQL.

Para mais informações acerca da configuração SSL/TLS do lado do cliente, consulte a documentação do seu motor de base de dados.

Hierarquias da autoridade de certificação (AC)

Esta secção descreve os três tipos de autoridade de certificação (AC) do servidor que pode escolher para as suas instâncias do Cloud SQL. Tem três opções:

  • AC por instância: com esta opção, uma AC interna dedicada a cada instância do Cloud SQL assina o certificado do servidor dessa instância. O Cloud SQL cria e gere estas ACs. Para escolher a AC por instância, selecione Autoridade de certificação interna gerida pela Google (Google Cloud consola) ou especifique GOOGLE_MANAGED_INTERNAL_CA para a definição serverCaMode (API Cloud SQL Admin) ou a flag --server-ca-mode (gcloud CLI) quando criar a instância. Se deixar a definição ou o sinalizador não especificado quando cria uma instância, esta opção é o valor predefinido para a instância.

  • AC partilhada: com esta opção, é usada uma hierarquia de AC que consiste numa AC raiz e em ACs de servidor subordinadas. As ACs (autoridades de certificação) do servidor subordinadas numa região assinam os certificados do servidor e são partilhadas entre instâncias na região. O Cloud SQL aloja e gere a AC de raiz e as ACs de servidor subordinadas no Google Cloud Certificate Authority Service (CA Service). O Cloud SQL também processa a rotação da AC de raiz e das ACs de servidor subordinadas e fornece links disponíveis publicamente para os pacotes de certificados de AC para transferência. Para escolher uma AC partilhada, especifique GOOGLE_MANAGED_CAS_CA para a definição serverCaMode (API Cloud SQL Admin) ou a flag --server-ca-mode (gcloud CLI) quando criar a instância.

  • AC gerida pelo cliente: com esta opção, cria e gere a sua própria hierarquia de AC. Escolha esta opção se quiser gerir as suas próprias ACs e certificados. Para escolher uma AC gerida pelo cliente, tem de criar um conjunto de ACs e uma AC no serviço de AC. No Cloud SQL, especifique o conjunto de ACs e CUSTOMER_MANAGED_CAS_CA para a definição serverCaMode (API Admin do Cloud SQL) ou a flag --server-ca-mode (CLI gcloud) quando criar a instância.

Depois de criar uma instância, pode ver que hierarquia de AC está configurada para uma instância do Cloud SQL através do comando gcloud sql instances describe ou na consola Google Cloud . Para mais informações, consulte o artigo Veja informações da instância.

A tabela seguinte compara as três opções de hierarquia de AC.

Funcionalidade CA por instância CA partilhado AC gerida pelo cliente
Estrutura de CA AC separada para cada instância CA de raiz e CAs subordinadas partilhadas entre instâncias na mesma região Hierarquia de CA que cria e gere
Atributos criptográficos Chave RSA de 2048 bits com algoritmo SHA256 Algoritmo de assinatura digital de curvas elípticas (ECDSA) com chave de 384 bits com algoritmo SHA384 Algoritmo de assinatura digital de curvas elípticas (ECDSA) com chave de 384 bits com algoritmo SHA384
Período de validade da CA 10 anos 25 anos para a AC de raiz e 10 anos para as ACs subordinadas Configurável *
Período de validade do certificado do servidor 10 anos 1 ano 1 ano**
Rotação iniciada pelo utilizador da AC? Sim Não. A rotação da AC é gerida pelo Cloud SQL Sim
Rotação iniciada pelo utilizador do certificado do servidor? Sim Sim Sim
Âncora de fidedignidade da CA para ligações TLS A AC exclusiva por instância é a âncora de confiança da instância correspondente. A CA de raiz e as CAs subordinadas são as âncoras de confiança para todas as instâncias numa determinada região. As ACs que cria e gere são as âncoras de confiança.
Validação da identidade do servidor A validação da AC valida a identidade do servidor, uma vez que cada instância tem uma AC exclusiva. A validação do nome de anfitrião, juntamente com a validação da AC, é necessária para a validação de identidade do servidor, uma vez que as ACs do servidor são partilhadas entre instâncias. Embora a AC possa não ser partilhada entre instâncias, é recomendável validar o nome de anfitrião juntamente com a AC.
Campo de nome alternativo do requerente (SAN) nos certificados do servidor O campo SAN contém o nome do anfitrião (nome DNS da instância) apenas para instâncias ativadas com o Private Service Connect. O nome do anfitrião pode ser usado para a validação da identidade do servidor. Se estiver a estabelecer ligação a uma instância do Cloud SQL através do nome DNS como nome do anfitrião, tem de configurar a resolução de DNS. O campo SAN contém o nome do anfitrião (nome DNS da instância) para todos os tipos de instâncias. O nome do anfitrião pode ser usado para a validação da identidade do servidor. Se estiver a estabelecer ligação a uma instância do Cloud SQL através do nome DNS como nome do anfitrião, tem de configurar a resolução de DNS. O campo SAN contém o nome do anfitrião (nome DNS da instância) para todos os tipos de instâncias. O nome do anfitrião pode ser usado para a validação da identidade do servidor.
Apoio técnico da versão do proxy Auth do Cloud SQL Suporta todas as versões do proxy Auth do Cloud SQL, v1 e posteriores. Requer a versão 2.13.0 ou posterior do Proxy Auth do Cloud SQL. Requer a versão 2.14.3 ou posterior do Proxy Auth do Cloud SQL.
Limitações de ligação ao serviço Nenhum Não suporta associações dos seguintes Google Cloud serviços: Não suporta associações dos seguintes Google Cloud serviços:
  • Ambiente padrão do App Engine
  • Ambiente flexível do App Engine
  • Serviços do Cloud Run que são executados num ambiente de execução de primeira geração

* Para a opção de AC gerida pelo cliente, o período de validade predefinido de um certificado da AC no serviço de AC é de 10 anos. Tem a opção de configurar um período de validade diferente para os seus certificados de AC. Um período de validade mais curto para a AC pode exigir rotações da AC mais frequentes e um período de validade inferior a um ano pode afetar o período de validade dos seus certificados de servidor. Para mais informações, consulte o artigo Gerir a rotação de ACs.

** Para a opção de AC gerida pelo cliente, o período de validade predefinido de um certificado do servidor é de um ano. No entanto, se configurar um período de validade inferior a um ano para o certificado da AC, o certificado do servidor tem um período de validade mais curto. Para mais informações sobre como configurar o período de validade do certificado da AC aquando da criação, consulte as definições do certificado da AC e crie uma CA de raiz.

AC por instância alojada pelo Cloud SQL

A hierarquia de AC por instância é a configuração predefinida do modo de AC do servidor quando cria uma instância através da CLI gcloud, da API Cloud SQL Admin ou do Terraform.

O Cloud SQL cria uma nova CA do servidor autoassinada para cada instância quando cria a instância. Para usar esta definição, configure serverCaMode como GOOGLE_MANAGED_INTERNAL_CA quando criar a instância. Pode deixar a definição de configuração não especificada através da API Cloud SQL Admin ou da CLI gcloud, ou selecionar a opção Autoridade de certificação interna da Google na Google Cloud consola.serverCaMode

O diagrama seguinte mostra a hierarquia de AC por instância.

Diagrama da hierarquia de AC interna por instância.

ACs partilhadas alojadas pelo serviço de AC

A hierarquia de CA partilhada é a configuração predefinida do modo de CA do servidor quando cria uma instância através da Google Cloud consola.

Este modo de AC do servidor consiste numa AC de raiz e ACs do servidor subordinadas em cada região. As ACs do servidor subordinadas emitem certificados de servidor e são partilhadas entre instâncias na região. O Cloud SQL processa a rotação das CAs do servidor regionais partilhadas e fornece links disponíveis publicamente para transferir os pacotes de certificados da CA.

Pode configurar uma instância para usar uma hierarquia de ACs de servidor em que as ACs de emissão são partilhadas entre as instâncias na mesma região. Para usar esta definição, configure serverCaMode como GOOGLE_MANAGED_CAS_CA quando criar a instância. Também pode selecionar Autoridade de certificação de CAS gerida pela Google na Google Cloud consola.

O diagrama seguinte mostra a hierarquia de AC partilhada.

Diagrama de uma hierarquia de AC partilhada

ACs geridas pelo cliente

Este modo de AC do servidor permite-lhe configurar a sua própria hierarquia de AC no serviço de AC.

Para usar a opção de AC gerida pelo cliente no Cloud SQL, crie um conjunto de ACs na mesma região que as suas instâncias do Cloud SQL. Em seguida, crie, pelo menos, uma CA. Quando criar a instância do Cloud SQL, especifique o ID do conjunto de ACs no campo serverCaPool e configure o campo serverCaMode com o valor CUSTOMER_MANAGED_CAS_CA. O serviço de AC fornece uma AC do conjunto de ACs e usa essa AC para emitir o certificado do servidor para a instância.

Quando cria ACs no serviço de ACs, pode criar uma AC raiz ou uma AC subordinada, consoante o seu exemplo de utilização. Por exemplo, pode querer criar uma CA subordinada se planear configurar uma hierarquia de CAs de raiz ou uma cadeia até uma CA externa.

Selecione a opção de CA gerida pelo cliente apenas se quiser gerir as suas próprias CAs e certificados. Para mais informações, consulte o artigo Use uma AC gerida pelo cliente.

Como funciona a rotação de certificados do servidor

O Cloud SQL oferece formas de rodar o certificado do servidor, para que o novo certificado possa ser trocado sem problemas antes de o certificado antigo expirar.

Para instâncias que usam as hierarquias de AC por instância, AC partilhada ou AC gerida pelo cliente, cerca de três meses antes da expiração do certificado do servidor de uma instância do Cloud SQL, os proprietários do projeto recebem um email do Cloud SQL a indicar que o processo de rotação de certificados começou para essa instância. O email indica o nome da instância e informa que o Cloud SQL adicionou um novo certificado de servidor ao projeto. O certificado do servidor existente continua a funcionar normalmente. Na prática, a instância tem dois certificados de servidor durante este período.

O comando de rotação do certificado de servidor a usar depende de estar a usar um certificado de servidor emitido por uma CA por instância ou um certificado de servidor emitido pela CA partilhada ou pela CA gerida pelo cliente.

Antes de o certificado do servidor atual expirar, transfira o novo ficheiro server-ca.pem, que contém as informações do certificado para os certificados do servidor atual e novo. Atualize os seus clientes PostgreSQL para usarem o novo ficheiro, copiando-o para todas as máquinas anfitriãs do cliente PostgreSQL e substituindo o ficheiro existente.

Depois de todos os clientes do PostgreSQL terem sido atualizados, envie um comando rotate (para a AC por instância) ou um comando rotate (para a AC partilhada ou gerida pelo cliente) para a instância do Cloud SQL para fazer a rotação para o novo certificado do servidor. Depois de concluir este processo, o certificado de servidor antigo deixa de ser reconhecido e só pode ser usado o novo certificado de servidor.

Os certificados de cliente não são afetados pela rotação de certificados de servidor.

Expiração do certificado SSL

Para instâncias do Cloud SQL que usam ACs por instância (serverCaMode está definido como GOOGLE_MANAGED_INTERNAL_CA), os certificados SSL têm um período de validade de 10 anos. Antes de estes certificados expirarem, faça a rotação do certificado da AC do servidor.

Para instâncias que usam ACs partilhadas (serverCaMode está definido como GOOGLE_MANAGED_CAS_CA), o período de validade dos certificados de servidor é de 1 ano. Antes da expiração, faça uma rotação do certificado do servidor. O certificado da autoridade de certificação (AC) de raiz tem um período de validade de 25 anos e o certificado da AC partilhada subordinada tem um período de validade de 10 anos. O Cloud SQL processa a respetiva rotação.

Se estiver a usar uma AC gerida pelo cliente (serverCaMode está definida como CUSTOMER_MANAGED_CAS_CA), pode fazer a rotação do certificado da AC rodando as ACs no conjunto de ACs que criou. O período de validade de uma AC é normalmente de 10 anos, mas pode configurar um período de validade mais curto para a sua AC no serviço de AC.

Para rodar as ACs, use o processo de rotação de ACs no serviço de ACs. Para mais informações, consulte o artigo Gerir a rotação de ACs.

Se um cliente estiver configurado para validar a AC ou o nome do anfitrião no certificado do servidor, as ligações desse cliente a instâncias do Cloud SQL com certificados do servidor expirados vão falhar. Para evitar a interrupção das ligações de cliente, faça a rotação do certificado do servidor antes de este expirar.

Quer use a AC por instância, a AC partilhada ou o modo de servidor da AC gerida pelo cliente, pode repor a configuração SSL da sua instância do Cloud SQL em qualquer altura.

O que se segue?