Autorizar com certificados SSL/TLS

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

Visão geral

O Cloud SQL é compatível com a conexão a uma instância usando o protocolo SSL/TLS. As conexões SSL/TLS fornecem uma camada de segurança ao criptografar dados em trânsito entre o cliente e o banco de dados na instância do Cloud SQL. Como opção, sua conexão SSL/TLS pode realizar a confirmação de identidade do servidor validando o certificado do servidor instalado na instância do Cloud SQL e a confirmaçã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 (CA). É possível baixar o certificado de CA na máquina host do cliente e usá-lo para verificar a identidade da CA e do servidor do Cloud SQL. Se quiser, escolha o tipo de AC que o Cloud SQL usa para assinar o certificado do servidor.

Hierarquias de autoridade certificadora (AC)

Nesta seção, descrevemos os três tipos de autoridade certificadora (AC) de servidor que podem ser escolhidos para as instâncias do Cloud SQL. Você tem três 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 CA por instância, selecione Autoridade de certificação interna gerenciada pelo Google (Google Cloud console) ou especifique GOOGLE_MANAGED_INTERNAL_CA para a configuração serverCaMode (API Cloud SQL Admin) ou a flag --server-ca-mode (CLI gcloud) ao criar a instância. Se você não especificar a configuração ou a flag ao criar uma instância, essa opção será o valor padrão para a instância. Não é possível atualizar uma instância para usar a opção de AC por instância se ela estiver configurada para usar uma AC compartilhada ou gerenciada pelo cliente.

  • AC compartilhada: com essa opção, é usada uma hierarquia de ACs que consiste em uma AC raiz e ACs de servidor subordinadas. As CAs de servidor subordinadas em uma região assinam os certificados de servidor e são compartilhadas entre as instâncias na região. Usar uma hierarquia de AC compartilhada é útil quando você aumenta o número de instâncias em uma região, porque não precisa gerenciar ACs exclusivas para instâncias individuais. Ao mudar para uma AC compartilhada (GOOGLE_MANAGED_CAS_CA), é possível usar um único pacote de AC regional para todas as instâncias na região, o que pode simplificar a configuração do lado do cliente. O Cloud SQL hospeda e gerencia a CA raiz e as CAs de servidor subordinadas no Google Cloud Certificate Authority Service (CA Service). O Cloud SQL também lida com a rotação da CA raiz e das CAs de servidor subordinadas e fornece links disponíveis publicamente para os pacotes de certificados de CA para download. Para escolher a CA compartilhada, selecione Autoridade certificadora do CAS gerenciada pelo Google no console do Google Cloud ou especifique GOOGLE_MANAGED_CAS_CA para a configuração serverCaMode (API Cloud SQL Admin) ou a flag --server-ca-mode (gcloud CLI) ao criar ou editar a instância. É possível atualizar uma instância para usar uma hierarquia de AC compartilhada se você estiver usando a opção de AC por instância ou a opção de AC gerenciada pelo cliente.

  • AC gerenciada pelo cliente: com essa opção, você cria e gerencia sua própria hierarquia de ACs. Escolha essa opção se quiser gerenciar suas próprias ACs e certificados. Ao usar uma CA gerenciada pelo cliente (CUSTOMER_MANAGED_CAS_CA), é possível gerenciar sua própria hierarquia de CA e políticas de rotação com o serviço de CA. Essa configuração oferece mais controle e ajuda a atender aos requisitos de conformidade. Para escolher a AC gerenciada pelo cliente, é preciso criar um pool de CAs e uma CA no serviço de CA. No Cloud SQL, especifique o pool de CAs e a autoridade de certificação de CA gerenciada pelo cliente (Google Cloud console), CUSTOMER_MANAGED_CAS_CA para a configuração serverCaMode (API Cloud SQL Admin) ou a --server-ca-mode flag (CLI gcloud) ao criar ou editar a instância. É possível atualizar uma instância para usar uma hierarquia de AC gerenciada pelo cliente se você estiver usando a opção de AC por instância ou de AC compartilhada.

Depois de criar ou atualizar a instância, use o comando gcloud sql instances describe ou o console do Google Cloud para conferir qual hierarquia de AC está configurada para uma instância do Cloud SQL. Para mais informações, consulte Acessar informações da instância.

A tabela a seguir compara as três opções de hierarquia de CA.

Recurso AC por instância AC compartilhada AC gerenciada pelo cliente
Estrutura da CA AC separada para cada instância CA raiz e CAs subordinadas compartilhadas entre instâncias na mesma região Hierarquia de ACs que você cria e gerencia
Atributos criptográficos Chave RSA de 2.048 bits com algoritmo SHA256 Algoritmo de assinatura digital de curva elíptica (ECDSA) com chave de 256 bits com algoritmo SHA384 Algoritmo de assinatura digital de curva elíptica (ECDSA) com chave de 256 bits e algoritmo SHA384
Período de validade da CA 10 anos 25 anos para a CA raiz e 10 anos para as CAs subordinadas Configurável *
Período de validade do certificado do servidor 10 anos 1 ano 1 ano**
Rotação de CA iniciada pelo usuário? Sim Não. A rotação de CA é gerenciada pelo Cloud SQL. Sim
Rotação iniciada pelo usuário do certificado do servidor? Sim Sim Sim
Rotação automática do certificado do servidor? Não Sim Sim
Âncora de confiança da CA para conexões TLS A AC exclusiva por instância é a âncora de confiança da instância correspondente. A CA raiz e as CAs subordinadas são as âncoras de confiança de todas as instâncias em uma determinada região. As CAs que você cria e gerencia são as âncoras de confiança.
Confirmação de identidade do servidor A verificação da CA verifica a identidade do servidor, já que cada instância tem uma CA exclusiva. A verificação do nome do host e da CA é necessária para confirmar a identidade do servidor, já que as CAs do servidor são compartilhadas entre as instâncias. Embora a CA possa não ser compartilhada entre as instâncias, talvez você queira verificar o nome do host e a CA.
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 do 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 confirmação de identidade do servidor. Se você estiver se conectando a uma instância do Cloud SQL usando o nome DNS como nome do 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 confirmação de identidade do servidor.
Suporte à versão do proxy de autenticação do Cloud SQL Oferece suporte a todas as versões do proxy de autenticação do Cloud SQL, v1 e posteriores. Requer o proxy de autenticação do Cloud SQL versão 2.13.0 ou mais recente. Requer o proxy de autenticação do Cloud SQL versão 2.14.3 ou mais recente.
Limitações da conexão de serviço Nenhum Não é compatível com conexões dos seguintes Google Cloud serviços: Não é compatível com conexões dos seguintes Google Cloud serviços:
  • Ambiente padrão do App Engine
  • Ambiente flexível do App Engine
  • Serviços do Cloud Run executados em um ambiente de execução de primeira geração

* Para a opção de AC gerenciada pelo cliente, o período de validade padrão de um certificado de AC no serviço de AC é de 10 anos. É possível configurar um período de validade diferente para os certificados de CA. Um período de validade mais curto para a CA pode exigir rotações mais frequentes e um período de validade menor que um ano pode afetar o período de validade dos certificados do servidor. Para mais informações, consulte Como gerenciar a rotação de AC.

** Para a opção de CA gerenciada pelo cliente, o período de validade padrão de um certificado de servidor é de um ano. No entanto, se você configurar um período de validade menor que um ano para o certificado de CA, o certificado do servidor terá um período de validade menor. Para mais informações sobre como configurar o período de validade do certificado de CA na criação, consulte Configurações do certificado de CA e Criar uma CA raiz.

CA por instância hospedada pelo Cloud SQL

A hierarquia de CA por instância é a configuração padrão do modo de CA do servidor quando você cria uma instância usando a CLI gcloud, a API Cloud SQL Admin ou o Terraform.

O Cloud SQL cria uma nova CA de servidor autoassinada para cada instância quando você cria a instância. Para usar essa configuração, defina serverCaMode como GOOGLE_MANAGED_INTERNAL_CA ao criar a instância. É possível deixar a configuração serverCaMode não especificada usando a API Cloud SQL Admin ou a CLI gcloud, ou selecionar a opção Autoridade certificadora interna do Google no console do Google Cloud .

Não é possível atualizar o serverCaMode de uma instância que usa uma hierarquia de CA compartilhada ou gerenciada pelo cliente para usar a hierarquia de CA por instância.

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

Diagrama da hierarquia de CA interna por instância.

ACs compartilhadas hospedadas pelo CA Service

Esse modo de AC do servidor consiste em uma AC raiz e ACs de servidor subordinadas em cada região. As CAs de servidor subordinadas emitem certificados de servidor e são compartilhadas entre as instâncias na região. O Cloud SQL lida com a rotação das CAs de servidor regionais compartilhadas e fornece links disponíveis publicamente para baixar os pacotes de certificados de CA.

Quando você usa o modo de CA compartilhada, os clientes do banco de dados precisam confiar na CA raiz e na CA subordinada que emite os certificados de servidor para sua instância.

Para confiar na CA raiz e na CA subordinada da sua instância, escolha uma das seguintes opções:

  • Faça o download do pacote global.pem para confiar na CA raiz e em todas as CAs subordinadas dela.
  • Faça o download do pacote regional para o local regional da sua instância para confiar na CA raiz e nas CAs subordinadas dessa região. Por exemplo, se a instância estiver localizada na região asia-east1, faça o download do pacote asia-east1.pem.
  • Faça o download do server-ca.pem para que sua instância confie na CA raiz e na CA subordinada que emite o certificado do servidor para sua instância.

É possível configurar uma instância para usar uma hierarquia de ACs de servidor em que as ACs emissoras são compartilhadas entre as instâncias na mesma região. Para usar essa configuração, defina serverCaMode como GOOGLE_MANAGED_CAS_CA ao criar ou editar a instância. Também é possível selecionar a autoridade certificadora CAS gerenciada pelo Google no console do Google Cloud .

O diagrama a seguir mostra a hierarquia de CA compartilhada.

Diagrama de uma hierarquia de AC compartilhada

ACs gerenciadas pelo cliente

Esse modo de CA do servidor permite configurar sua própria hierarquia de CA no CA Service.

Para usar a opção de CA gerenciada pelo cliente no Cloud SQL, crie um pool de CAs na mesma região das instâncias do Cloud SQL. Em seguida, crie pelo menos uma AC. Ao criar a instância do Cloud SQL, especifique o ID do pool de CAs no campo serverCaPool e configure o campo serverCaMode com o valor CUSTOMER_MANAGED_CAS_CA. O CA Service fornece uma CA do pool de CAs e a usa para emitir o certificado do servidor para a instância.

Ao criar CAs no CA Service, é possível criar uma CA raiz ou uma CA subordinada, dependendo do seu caso de uso. Por exemplo, talvez você queira criar uma CA subordinada se planeja configurar uma hierarquia de CA raiz ou encadear até uma CA externa.

Selecione a opção de AC gerenciada pelo cliente somente se você quiser gerenciar suas próprias ACs e certificados. Para mais informações, consulte Usar uma CA gerenciada pelo cliente.

Como funciona a rotação de certificados do servidor

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

As instâncias que usam a hierarquia de CA compartilhada ou gerenciada pelo cliente podem ativar a rotação automática de certificados do servidor para serem executadas durante as atualizações de manutenção até 180 dias antes da expiração.

Para instâncias que usam as hierarquias de AC por instância, AC compartilhada ou AC gerenciada pelo cliente, 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 rotação 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.

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

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 SQL Server usem o novo arquivo, ele deve ser copiado em todas as máquinas host do cliente SQL Server, substituindo o arquivo atual.

Depois que todos os clientes do SQL Server forem atualizados, envie um comando de rotação (para CA por instância) ou comando de rotação (para CA compartilhada ou CA gerenciada pelo cliente) para que a instância do Cloud SQL use somente o novo certificado do servidor. Depois disso, o certificado antigo não será mais reconhecido e somente o novo poderá ser usado.

Vencimento 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 que esses certificados expirem, faça a rotação do certificado de CA do servidor.

Para instâncias que usam CAs compartilhadas (serverCaMode está definido como GOOGLE_MANAGED_CAS_CA), o período de validade dos certificados do servidor é de 1 ano. Antes da expiração, faça uma rotação de certificados do servidor ou ative a rotação automática de certificados do servidor. O certificado da autoridade certificadora (CA) raiz tem um período de validade de 25 anos, e o certificado da CA compartilhada subordinada tem um período de validade de 10 anos. O Cloud SQL lida com a rotação deles.

Se você estiver usando uma CA gerenciada pelo cliente (serverCaMode está definido como CUSTOMER_MANAGED_CAS_CA), poderá realizar a rotação de certificados de CA alternando as CAs no pool de CAs que você criou. O período de validade de uma CA geralmente é de 10 anos, mas é possível configurar um período de validade mais curto para sua CA no CA Service.

Para alternar as CAs, use o processo de rotação de CA no CA Service. Para mais informações, consulte Como gerenciar a rotação de AC.

Se um cliente estiver configurado para verificar a CA 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, faça a rotação do certificado do servidor antes que ele expire.

Seja usando o modo de servidor de AC por instância, AC compartilhada ou AC gerenciada pelo cliente, é possível redefinir a configuração de SSL da instância do Cloud SQL a qualquer momento.

Limitações

Nesta seção, abordamos as limitações da configuração de certificados SSL/TLS e do Cloud SQL.

Limitações da conexão de serviço

A seguir