Autorizar com certificados SSL/TLS

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

Visão geral

O Cloud SQL oferece suporte à conexão com uma instância usando o protocolo SSL/TLS. As conexões SSL/TLS fornecem uma camada de segurança criptografando os dados em trânsito entre o cliente e o banco de dados na instância do Cloud SQL. Opcionalmente, a 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

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

Hierarquias de autoridade certificadora (CA)

Esta seção descreve os três tipos de autoridade certificadora (CA) do servidor que podem ser escolhidos para as instâncias do Cloud SQL. Há 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 AC por instância, selecione Autoridade certificadora 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ê deixar a configuração ou a flag não especificada ao criar uma instância, essa opção será o valor padrão da 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, uma hierarquia de AC que consiste em uma AC raiz e ACs de servidor subordinadas é usada. As ACs de servidor subordinadas em uma região assinam os certificados do servidor e são compartilhadas entre instâncias na região. O uso de uma hierarquia de AC compartilhada é útil à medida que você aumenta o número de instâncias em uma região, porque não é necessário 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 AC raiz e as ACs de servidor subordinadas no Google CloudCertificate Authority Service (serviço de AC). O Cloud SQL também processa a rotação da AC raiz e das ACs de servidor subordinadas e fornece links disponíveis publicamente para fazer o download dos pacotes de certificados de CA. Para escolher a AC compartilhada, especifique GOOGLE_MANAGED_CAS_CA para a configuração serverCaMode (API Cloud SQL Admin) ou a flag --server-ca-mode (CLI gcloud) ao criar ou editar a instância. É possível atualizar uma instância atual para usar uma hierarquia de AC compartilhada se você estiver usando a 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 AC. Escolha essa opção se quiser gerenciar suas próprias ACs e certificados. Ao usar uma AC gerenciada pelo cliente (CUSTOMER_MANAGED_CAS_CA), é possível gerenciar sua própria hierarquia de AC e políticas de rotação com o serviço de AC. Essa configuração oferece maior controle e ajuda a atender aos requisitos de conformidade. Para escolher a AC gerenciada pelo cliente, é necessário criar um pool de ACs e uma AC no serviço de AC. No Cloud SQL, especifique o pool de ACs e CUSTOMER_MANAGED_CAS_CA para a configuração serverCaMode (API Cloud SQL Admin) ou a flag --server-ca-mode (CLI gcloud) ao criar ou editar a instância. É possível atualizar uma instância atual para usar uma hierarquia de AC gerenciada pelo cliente se você estiver usando a AC por instância ou a opção de AC compartilhada.

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

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

Recurso AC por instância AC compartilhada AC gerenciada pelo cliente
Estrutura da AC AC separada para cada instância AC raiz e ACs subordinadas compartilhadas entre instâncias na mesma região Hierarquia de AC que você cria e gerencia
Atributos criptográficos Chave RSA de 2048 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 com algoritmo SHA384
Período de validade da AC 10 anos 25 anos para AC raiz e 10 anos para ACs subordinadas Configurável *
Período de validade do certificado do servidor 10 anos 1 ano 1 ano**
Rotação de AC iniciada pelo usuário? Sim Não. A rotação de AC é gerenciada pelo Cloud SQL Sim
Rotação de certificado do servidor iniciada pelo usuário? Sim Sim Sim
Rotação automática do certificado do servidor? Não 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. As ACs que você cria e gerencia são as âncoras de confiança.
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 instâncias. Embora a AC não seja compartilhada entre instâncias, talvez seja necessário verificar o nome do host e a AC.
Campo "Nome alternativo do assunto" (SAN, na sigla em inglês) em certificados do servidor O campo SAN contém o nome do host (nome DNS da instância) apenas para instâncias ativadas com 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 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 verificaçã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 mais recentes. Requer a versão 2.13.0 ou mais recente do proxy de autenticação do Cloud SQL. Requer a versão 2.14.3 ou mais recente do proxy de autenticação do Cloud SQL.
Limitações de conexão de serviço Nenhum Não oferece suporte a conexões dos seguintes Google Cloud serviços: Não oferece suporte a 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 AC. Um período de validade mais curto para a AC 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 Gerenciar a rotação de AC.

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

AC por instância hospedada pelo Cloud SQL

A hierarquia de AC por instância é a configuração de modo de AC do servidor padrão ao criar uma instância usando a CLI gcloud, a API Cloud SQL Admin ou o Terraform.

O Cloud SQL cria uma nova AC de servidor autoassinada para cada instância quando você a cria. Para usar essa configuração, configure 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. Google Cloud

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

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

Diagrama da hierarquia de AC interna 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 subordinadas emitem certificados do servidor e são compartilhadas entre instâncias na região. O Cloud SQL processa a rotação das ACs de servidor regionais compartilhadas e fornece links disponíveis publicamente para fazer o download dos pacotes de certificados de CA.

Ao usar o modo de AC compartilhada, os clientes do banco de dados precisam confiar na AC raiz e na AC subordinada que emite os certificados do servidor para a instância.

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

  • Faça o download do pacote global.pem para confiar na AC raiz e em todas as ACs subordinadas.
  • Faça o download do pacote regional para o local regional da instância para confiar na AC raiz e nas ACs 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 a instância confie na AC raiz e na AC subordinada que emite o certificado do servidor para a instância.

É 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 ou editar a instância. Também é possível selecionar Autoridade certificadora do CAS gerenciada pelo Google no Google Cloud console.

O diagrama a seguir mostra a hierarquia de AC compartilhada.

Diagrama de uma hierarquia de AC compartilhada

ACs gerenciadas pelo cliente

Esse modo de AC do servidor permite configurar sua própria hierarquia de AC no serviço de AC.

Para usar a opção de AC gerenciada pelo cliente no Cloud SQL, crie um pool de ACs 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 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 pool de ACs e a usa para emitir o certificado do servidor da instância.

Ao criar ACs no serviço de AC, é possível criar uma AC raiz ou uma AC subordinada, dependendo do seu caso de uso. Por exemplo, talvez você queira criar uma AC subordinada se planeja configurar uma hierarquia de AC raiz ou encadear uma AC externa.

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

Como funciona a rotação de certificados do servidor

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

As instâncias que usam a hierarquia de AC 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 do vencimento.

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 AC por instância ou um certificado do servidor emitido pela AC compartilhada ou gerenciada pelo cliente.

Antes que o certificado do servidor 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 AC por instância) ou comando de rotação (para AC compartilhada ou 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, execute a rotação do certificado de AC do servidor.

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 1 ano. Antes do vencimento, execute uma rotação de certificado do servidor ou ative a rotação automática de certificados do servidor. O certificado de autoridade certificadora (CA) raiz tem um período de validade de 25 anos, e o certificado de AC compartilhada subordinada tem um período de validade de 10 anos. O Cloud SQL processa a rotação deles.

Se você estiver usando uma AC gerenciada pelo cliente (serverCaMode está definido como CUSTOMER_MANAGED_CAS_CA), será possível executar a rotação do certificado de AC girando as ACs no pool de ACs que você criou. O período de validade de uma AC é normalmente de 10 anos, mas é possível configurar um período de validade mais curto para a AC no serviço de AC.

Para girar as ACs, use o processo de rotação de AC no serviço de AC. Para mais informações, consulte Gerenciar a rotação de AC.

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 do servidor expirados vão falhar. Para evitar interrupções nas conexões do cliente, gire o certificado do servidor antes que ele expire.

Se você usar a AC por instância, a AC compartilhada ou o modo de servidor de AC gerenciada pelo cliente , será possível redefinir a configuração SSL da instância do Cloud SQL a qualquer momento.

Limitações

Esta seção aborda as limitações da configuração de certificado SSL/TLS e do Cloud SQL.

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

A seguir