Nesta página, descrevemos como usar o Secure Socket Layer (SSL), agora Transport Layer Security (TLS), do 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 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, 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 (CA). É possível fazer o download do certificado da CA para a 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.
Certificados do cliente
Você pode criar e baixar certificados de cliente junto 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 CA que o Cloud SQL usa para assinar o certificado do cliente.
Conectar-se 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 aplicar a criptografia SSL/TLS usando a configuração do modo SSL no Cloud SQL. Como opção, também é possível aplicar a verificação do 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, elas são criptografadas automaticamente com SSL/TLS, além da verificação de identidade do cliente e do servidor, sem exigir o download de um certificado de CA do servidor e de cliente.
Para mais informações sobre as opções de conectividade do Cloud SQL, consulte Sobre 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 autoridade de certificação (CA)
Nesta seção, descrevemos os três tipos de autoridade certificadora (CA) de certificado do servidor que você pode escolher para suas instâncias do Cloud SQL. Você tem três opções:
CA por instância: com essa opção, uma CA interna dedicada a cada instância do Cloud SQL assina o certificado do servidor dessa instância. O Cloud SQL cria e gerencia essas CAs. Para escolher a CA por instância, selecione Autoridade de certificação interna gerenciada pelo Google (consoleGoogle Cloud ) ou especifique
GOOGLE_MANAGED_INTERNAL_CApara a configuraçãoserverCaMode(API Cloud SQL Admin) ou a flag--server-ca-mode(gcloud CLI) ao criar a instância. Se você deixar a configuração ou flag não especificada ao criar uma instância, essa opção será o valor padrão para a instância.CA compartilhada: com essa opção, é usada uma hierarquia de CA que consiste em uma CA raiz e CAs de servidor subordinadas. As ACs subordinadas do servidor em uma região assinam os certificados do servidor e são compartilhadas entre as instâncias na região. O Cloud SQL hospeda e gerencia a CA raiz e as CAs de servidor subordinadas no Certificate Authority Service (CA Service) do Google Cloud. O Cloud SQL também processa a rotação da CA raiz e das CAs do servidor subordinadas e fornece links disponíveis publicamente para os pacotes de certificados de CA para download. Para escolher uma CA compartilhada, especifique
GOOGLE_MANAGED_CAS_CAna configuraçãoserverCaMode(API Cloud SQL Admin) ou na flag--server-ca-mode(CLI gcloud) ao criar a instância.CA gerenciada pelo cliente: com essa opção, você cria e gerencia sua própria hierarquia de CA. Escolha essa opção se quiser gerenciar suas próprias ACs e certificados. Para escolher uma CA gerenciada pelo cliente, crie um pool de CAs e uma CA no serviço de CA. No Cloud SQL, especifique o pool de CA e
CUSTOMER_MANAGED_CAS_CApara a configuraçãoserverCaMode(API Cloud SQL Admin) ou a flag--server-ca-mode(CLI gcloud) ao criar a instância.
Depois de criar uma instância, use o comando gcloud sql instances describe ou o console Google Cloud para conferir qual hierarquia de CA 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 | CA por instância | CA compartilhada | CA gerenciada pelo cliente |
|---|---|---|---|
| Estrutura de CA | CA separada para cada instância | CA raiz e CAs subordinadas compartilhadas entre instâncias na mesma região | Hierarquia de CA 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 384 bits e algoritmo SHA384 | Algoritmo de assinatura digital de curva elíptica (ECDSA) com chave de 384 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 |
| A rotação do certificado do servidor foi iniciada pelo usuário? | Sim | Sim | Sim |
| Âncora de confiança da CA para conexões TLS | A CA 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 ACs que você cria e gerencia são as âncoras de confiança. |
| Verificação da identidade do servidor | A verificação da CA confirma a identidade do servidor, já que cada instância tem uma CA exclusiva. | É necessário verificar o nome do host e a AC para verificar a identidade do servidor, já que as CAs do servidor são compartilhadas entre instâncias. | Embora a CA não seja compartilhada entre instâncias, talvez seja necessário verificar o nome do host e a CA. |
| Campo "Nome alternativo do assunto" (SAN) 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 da identidade do servidor. Se você estiver se conectando a uma instância do Cloud SQL usando o nome DNS como nome do host, configure 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 verificar a identidade do servidor. Se você estiver se conectando a uma instância do Cloud SQL usando o nome DNS como nome do host, configure 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 verificar a identidade do servidor. |
| Suporte a versões do proxy de autenticação do Cloud SQL | Compatível com todas as versões do proxy de autenticação do Cloud SQL, v1 e mais recentes. | 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 serviços Google Cloud:
|
Não é compatível com conexões dos seguintes serviços Google Cloud:
|
* Para a opção de CA gerenciada pelo cliente, o período de validade padrão de um certificado de CA no CA Service é de 10 anos. Você pode configurar um período de validade diferente para seus 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 inferior a um ano pode afetar a validade dos certificados do servidor. Para mais informações, consulte Gerenciar a rotação de CA.
** 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 da 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.
Autoridade certificadora 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 gcloud CLI, 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.
Você pode deixar a configuração serverCaMode
não especificada usando a API Cloud SQL Admin ou a gcloud CLI,
ou selecionar a opção Autoridade de certificação interna do Google no
console Google Cloud .
O diagrama a seguir mostra a hierarquia de CA por instância.
CAs compartilhadas hospedadas pelo serviço de CA
A hierarquia de AC compartilhada é a configuração padrão do modo de AC do servidor ao criar uma instância usando o console Google Cloud .
Esse modo de CA do servidor consiste em uma CA raiz e CAs de servidor subordinadas em cada região. As CAs subordinadas do servidor emitem certificados de servidor e são compartilhadas entre instâncias na região. O Cloud SQL processa a rotação das CAs regionais compartilhadas do servidor e fornece links disponíveis publicamente para baixar os pacotes de certificados de CA.
É possível configurar uma instância para usar uma hierarquia de CA do servidor em que as CAs 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.
Também é possível selecionar Autoridade certificadora CAS gerenciada pelo Google no console Google Cloud .
O diagrama a seguir mostra a hierarquia de CA compartilhada.
CAs gerenciadas pelo cliente
Com esse modo, é possível 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 CA.
Ao criar a instância do Cloud SQL, especifique o ID do pool de
autoridades certificadoras no campo serverCaPool e configure o campo serverCaMode
com o valor CUSTOMER_MANAGED_CAS_CA.
O CA Service fornece uma CA do pool e a usa para emitir o certificado do servidor para a instância.
Ao criar CAs no CA Service, você pode criar uma CA raiz ou subordinada, dependendo do seu caso de uso. Por exemplo, crie uma CA subordinada se você planeja configurar uma hierarquia de CA raiz ou encadeamento até uma CA externa.
Selecione a opção de CA gerenciada pelo cliente somente se quiser gerenciar suas próprias CAs 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 oferece maneiras de alternar o certificado do servidor, para que o novo certificado possa ser trocado sem problemas antes que o antigo expire.
Para instâncias que usam as hierarquias de AC por instância, compartilhada ou 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 mudança do certificado foi iniciado para essa 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 de você estar usando um certificado emitido por uma CA por instância ou um certificado emitido pela CA compartilhada ou gerenciada pelo cliente.
Antes que o certificado de 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 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 ICA por instância) ou comando de rotação (para ICA 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.
Os certificados do cliente não são impactados pela mudança do certificado do servidor.Vencimento do certificado SSL
Para instâncias do Cloud SQL que usam CAs por instância (serverCaMode 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 um ano.
Antes do vencimento, faça uma rotação do certificado 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 processa a rotação delas.
Se você estiver usando uma CA gerenciada pelo cliente (serverCaMode definido como CUSTOMER_MANAGED_CAS_CA),
poderá fazer a rotação do certificado da CA alternando as CAs no
pool de CAs criado. O período de validade de uma AC é normalmente de 10 anos, mas é possível configurar um período mais curto no CA Service.
Para fazer a rotação das CAs, use o processo de rotação de CA no CA Service. Para mais informações, consulte Gerenciar a rotação de CA.
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 de clientes, faça a rotação do certificado do servidor antes que ele expire.
Se você usa o modo de servidor de CA por instância, CA compartilhada ou CA gerenciada pelo cliente, é possível redefinir a configuração SSL da instância do Cloud SQL a qualquer momento.
A seguir
Configure o SSL/TLS na instância do Cloud SQL.
Saiba mais sobre como a criptografia é gerenciada no Google Cloud.
- Use o SSL/TLS para se conectar à instância do Cloud SQL.
- Gerencie o SSL/TLS na instância do Cloud SQL.
- Saiba mais sobre como o PostgreSQL usa SSL/TLS.