Autorizar com certificados SSL/TLS

Nesta página, você verá como o Cloud SQL usa certificados autogerenciados do Secure Socket Layer (SSL)/Transport Layer Security(TLS) para se conectar com segurança às instâncias do Cloud SQL.

Informações gerais

O Cloud SQL aceita conexão a uma instância usando o protocolo Transport Layer Security (SSL/TLS). Os dados em trânsito dentro de um limite físico controlado pelo Google ou em nome dele costumam ser autenticados, mas não necessariamente criptografados por padrão. Se você se conectar a uma instância usando o endereço IP público dela, será necessário aplicar certificados SSL/TLS para que os dados estejam seguros durante a transmissão. O SSL/TLS é o protocolo padrão de criptografia dos dados enviados pela Internet. Se os dados não estiverem criptografados, qualquer pessoa poderá examinar os pacotes e ler informações confidenciais.

O método mais seguro é a criptografia assimétrica. Ela requer duas chaves criptográficas, sendo uma pública e outra privada. Basicamente, você usa a chave pública para criptografar os dados e a chave privada para descriptografá-los. O servidor e as máquinas cliente têm o mesmo conjunto de chaves do cliente.

No Cloud SQL, as chaves pública e privada são chamadas de client-cert.pem e client-key.pem, respectivamente. O servidor também gera o próprio certificado chamado server-ca.pem.

O aplicativo requer que todas as três chaves se conectem com êxito. Armazene essas chaves com segurança: qualquer pessoa com acesso a elas poderá se conectar ou interceptar seus dados. Não é possível recuperar a chave privada do servidor depois. Se você perder a chave, precisará criar novos certificados de cliente para substituir os que estavam em uso anteriormente. Da mesma forma, quando o servidor gera um novo arquivo server-ca.pem, você precisa fazer o download dele e armazená-lo na máquina host do cliente PostgreSQL, substituindo o arquivo atual.

Certificados SSL/TLS

O certificado de Autoridade de certificação (CA) do servidor é obrigatório em conexões SSL. O Cloud SQL cria um certificado de servidor automaticamente quando você cria a instância. Desde que o certificado do servidor seja válido, não será necessário gerenciá-lo ativamente. No entanto, o certificado tem uma data de validade de 10 anos. Após esse período, ele não será mais válido, e os clientes não poderão usá-lo para estabelecer uma conexão segura com a instância. Também é possível criar um novo manualmente.

Você mesmo cria os certificados do cliente. Há um limite de 10 certificados de cliente por instância do Cloud SQL.

Como funciona a rotação de certificados do servidor

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

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 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.

Aplicar criptografia SSL/TLS

Ao configurar a instância do Cloud SQL para aceitar conexões SSL/TLS, você permite conexões SSL/TLS na instância, mas conexões não criptografadas e não seguras ainda são aceitas. Se você não exigir SSL/TLS para todas as conexões, ainda serão permitidas conexões não criptografadas. Por isso, se você estiver acessando sua instância usando um IP público, é altamente recomendável aplicar SSL a todas as conexões.

Usar redes autorizadas

Se a instância do Cloud SQL estiver usando um endereço IP público, será necessário adicionar os endereços IP dos clientes do PostgreSQL como redes autorizadas ao configurar o SSL/TLS.

Nesse caso, os clientes do PostgreSQL só terão autorização para se conectar se os endereços IP deles estiverem nessa lista. Os endereços IP podem ser limitados a apenas um endpoint ou compor um intervalo no formato CIDR. Por exemplo, 10.50.51.3 ou 10.50.51.0/26.

Vencimento do certificado SSL

Os certificados SSL associados às instâncias do Cloud SQL têm um prazo de validade de 10 anos. Após o vencimento, será preciso rotacionar o certificado SSL. Também é possível redefinir a configuração SSL da instância do Cloud SQL a qualquer momento.

A seguir

  • Saiba mais sobre como o PostgreSQL usa SSL/TLS.