Esta página descreve como aplicar a criptografia SSL/TLS a uma instância para garantir que todas as conexões sejam criptografadas. Você também pode saber mais sobre como o Cloud SQL usa certificados SSL/TLS autogerenciados para se conectar a instâncias do Cloud SQL com segurança.
Visão geral
O Cloud SQL cria um certificado de servidor automaticamente quando você cria sua instância. Recomendamos que você imponha que todas as conexões usem SSL/TLS .
O SQL Server só realiza a verificação de certificado quando a solicitação do cliente especifica explicitamente que requer uma conexão criptografada. Nesse caso, o certificado do servidor deve estar instalado na máquina cliente. Caso contrário, os clientes poderão se conectar livremente sem alterações adicionais em suas strings de conexão ou certificados, mesmo se você configurar a instância comsslMode
definido como ENCRYPTED_ONLY
.Para obter mais informações, consulte a seção Habilitar conexões criptografadas com o Mecanismo de Banco de Dados na documentação do SQL Server.
Se você aplicar SSL a uma instância, ela precisará ser reiniciada. Uma reinicialização também pode ser necessária após a alteração dos certificados SSL/TLS. Quando uma reinicialização é necessária, o Cloud SQL reinicia a instância automaticamente. A reinicialização de uma instância pode causar tempo de inatividade.Aplicar criptografia SSL/TLS
Você pode usar a configuração do modo SSL para impor a criptografia SSL das seguintes maneiras:
Permitir conexões não SSL/não TLS e SSL/TLS. Este é o padrão.
Permitir somente conexões criptografadas com SSL/TLS.
Se você selecionar Permitir conexões não SSL/não TLS e SSL/TLS para sua instância do Cloud SQL, conexões SSL/TLS serão aceitas, bem como conexões não criptografadas e não seguras. Se você não exigir SSL/TLS para todas as conexões, as conexões não criptografadas ainda serão permitidas. Por esse motivo, se você estiver acessando sua instância usando um IP público, recomendamos fortemente que você aplique o SSL para todas as conexões.
Você pode se conectar diretamente às instâncias usando certificados SSL/TLS ou usando o Cloud SQL Auth Proxy ou os Cloud SQL Connectors . Se você se conectar usando o Cloud SQL Auth Proxy ou os Cloud SQL Connectors, as conexões serão criptografadas automaticamente com SSL/TLS. Com o Cloud SQL Auth Proxy e os Cloud SQL Connectors, as identidades do cliente e do servidor também são verificadas automaticamente, independentemente da configuração do modo SSL.
A aplicação do SSL garante que todas as conexões sejam criptografadas.Para habilitar a exigência de SSL/TLS, faça o seguinte:
Console
No Google Cloud console, acesse a página Instâncias do Cloud SQL .
- Para abrir a página Visão geral de uma instância, clique no nome da instância.
- Clique em Conexões no menu de navegação SQL.
- Selecione a aba Segurança .
- Selecione uma das seguintes opções:
- Permitir tráfego de rede não criptografado (não recomendado)
- Permitir apenas conexões SSL. Esta opção permite apenas conexões que utilizam criptografia SSL/TLS.
gcloud
gcloud sql instances patch INSTANCE_NAME \ --ssl-mode=SSL_ENFORCEMENT_MODE
Substitua SSL_ENFORCEMENT_MODE por uma das seguintes opções:
-
ALLOW_UNENCRYPTED_AND_ENCRYPTED
permite conexões não SSL/não TLS e SSL/TLS. Este é o valor padrão. -
ENCRYPTED_ONLY
permite apenas conexões criptografadas com SSL/TLS.
Terraform
Para impor a criptografia SSL/TLS, use um recurso do Terraform :
Aplicar as alterações
Para aplicar sua configuração do Terraform em um Google Cloud projeto, conclua as etapas nas seções a seguir.
Preparar o Cloud Shell
- Inicie o Cloud Shell .
Defina o padrão Google Cloud projeto onde você deseja aplicar suas configurações do Terraform.
Você só precisa executar este comando uma vez por projeto e pode executá-lo em qualquer diretório.
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
Variáveis de ambiente serão substituídas se você definir valores explícitos no arquivo de configuração do Terraform.
Preparar o diretório
Cada arquivo de configuração do Terraform deve ter seu próprio diretório (também chamado de módulo raiz ).
- No Cloud Shell , crie um diretório e um novo arquivo dentro dele. O nome do arquivo deve ter a extensão
.tf
— por exemplo,main.tf
Neste tutorial, o arquivo será chamado demain.tf
mkdir DIRECTORY && cd DIRECTORY && touch main.tf
Se estiver seguindo um tutorial, você pode copiar o código de exemplo em cada seção ou etapa.
Copie o código de exemplo no
main.tf
recém-criado.Opcionalmente, copie o código do GitHub. Isso é recomendado quando o snippet do Terraform faz parte de uma solução completa.
- Revise e modifique os parâmetros de amostra para aplicar ao seu ambiente.
- Salve suas alterações.
- Inicialize o Terraform. Você só precisa fazer isso uma vez por diretório.
terraform init
Opcionalmente, para usar a versão mais recente do provedor do Google, inclua a opção
-upgrade
:terraform init -upgrade
Aplicar as alterações
- Revise a configuração e verifique se os recursos que o Terraform irá criar ou atualizar correspondem às suas expectativas:
terraform plan
Faça correções na configuração conforme necessário.
- Aplique a configuração do Terraform executando o seguinte comando e digitando
yes
no prompt:terraform apply
Aguarde até que o Terraform exiba a mensagem "Aplicação concluída!".
- Abra seu Google Cloud projeto para visualizar os resultados. No Google Cloud console, navegue até seus recursos na interface do usuário para garantir que o Terraform os criou ou atualizou.
Excluir as alterações
Para excluir suas alterações, faça o seguinte:
- Para desabilitar a proteção contra exclusão, no seu arquivo de configuração do Terraform defina o argumento
deletion_protection
comofalse
.deletion_protection = "false"
- Aplique a configuração atualizada do Terraform executando o seguinte comando e digitando
yes
no prompt:terraform apply
Remova os recursos aplicados anteriormente com sua configuração do Terraform executando o seguinte comando e digitando
yes
no prompt:terraform destroy
REST v1
Antes de usar qualquer um dos dados solicitados, faça as seguintes substituições:
- PROJECT_ID : O ID do projeto
- SSL_ENFORCEMENT_MODE : Use uma das seguintes opções:
-
ALLOW_UNENCRYPTED_AND_ENCRYPTED
: permite conexões não SSL/não TLS e SSL/TLS. -
ENCRYPTED_ONLY
: permite somente conexões criptografadas com SSL/TLS.
-
- INSTANCE_ID : O ID da instância
Método HTTP e URL:
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID
Corpo JSON da solicitação:
{ "settings": { "ipConfiguration": {"sslMode": "SSL_ENFORCEMENT_MODE"} } }
Para enviar sua solicitação, expanda uma destas opções:
Você deve receber uma resposta JSON semelhante à seguinte:
REST v1beta4
Antes de usar qualquer um dos dados solicitados, faça as seguintes substituições:
- PROJECT_ID : O ID do projeto
- SSL_ENFORCEMENT_MODE : Use uma das seguintes opções:
-
ALLOW_UNENCRYPTED_AND_ENCRYPTED
: permite conexões não SSL/não TLS e SSL/TLS. -
ENCRYPTED_ONLY
: permite somente conexões criptografadas com SSL/TLS.
-
- INSTANCE_ID : O ID da instância
Método HTTP e URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID
Corpo JSON da solicitação:
{ "settings": { "ipConfiguration": {"sslMode": "SSL_ENFORCEMENT_MODE"} } }
Para enviar sua solicitação, expanda uma destas opções:
Você deve receber uma resposta JSON semelhante à seguinte:
Certificados de servidor
O Cloud SQL cria um certificado de servidor automaticamente quando você cria sua instância. Desde que o certificado de servidor seja válido, você não precisa gerenciá-lo ativamente. O Cloud SQL permite selecionar entre três hierarquias diferentes de autoridade de certificação (CA) . A hierarquia de CA selecionada se torna o modo de CA de servidor da instância. Se você estiver usando CA por instância como o modo de CA de servidor para sua instância, os certificados de servidor terão uma data de expiração de 10 anos. Se você estiver usando CA compartilhada ou CA gerenciada pelo cliente como o modo de CA de servidor da sua instância, o certificado de servidor terá uma data de expiração de 1 ano * . Após a data de expiração, o certificado de servidor não será mais válido e os clientes não poderão mais estabelecer uma conexão segura com sua instância usando esse certificado. Se um cliente estiver configurado para verificar a CA ou verificar o nome do host no certificado de servidor, as conexões desse cliente com instâncias do Cloud SQL com certificados de servidor expirados falharão. Para evitar a interrupção das conexões do cliente, gire o certificado de servidor antes que ele expire. Você será notificado periodicamente de que o certificado de servidor está próximo da expiração. As notificações são enviadas com o seguinte número de dias antes da data de expiração: 90, 30, 10, 2 e 1.
* Para CA gerenciada pelo cliente, a data de expiração do seu certificado de servidor pode ser menor que 1 ano se você selecionar uma data de expiração mais curta para o período de validade da sua CA.
Listar e criar certificados de servidor
Para visualizar os detalhes dos certificados do seu servidor no Google Cloud console, vá para a página Conexões e clique na aba Segurança .
Na tabela de certificados, você pode ver os seguintes detalhes:
- Status do certificado : próximo, ativo ou anterior
- Próximo : O certificado está disponível para uso, mas não está ativo. Para ativá-lo, use o procedimento de rotação.
- Ativo : O certificado está em uso.
- Anterior : O certificado não está mais em uso. Para ativá-lo, use o procedimento de reversão.
- Criado : data e hora em que o certificado foi criado
- Expira : a data e a hora em que o certificado expira
Antes que o certificado ativo expire, você pode criar um novo certificado manualmente.
Console
Para instâncias que usam certificados de servidor autoassinados (CA por instância) :
No Google Cloud console, acesse a página Instâncias do Cloud SQL .
- Para abrir a página Visão geral de uma instância, clique no nome da instância.
- Clique em Conexões no menu de navegação SQL.
- Selecione a aba Segurança .
- Vá para a seção Gerenciar certificados de CA do servidor .
- Clique para expandir Gerenciar certificados .
- Clique em Criar novo certificado CA.
O novo certificado da CA do servidor aparece no slot "Próximos" . Se você quiser alternar para o novo certificado da CA do servidor imediatamente, prossiga com a rotação do certificado da CA do servidor atualizando seus clientes e concluindo a rotação.
Para instâncias que usam certificados de servidor emitidos por uma CA compartilhada :
No Google Cloud console, acesse a página Instâncias do Cloud SQL .
- Para abrir a página Visão geral de uma instância, clique no nome da instância.
- Clique em Conexões no menu de navegação SQL.
- Selecione a aba Segurança .
- Vá para a seção Gerenciar certificados do servidor .
- Clique para expandir Gerenciar certificados .
- Clique em Criar certificado de servidor .
O novo certificado de servidor aparece no slot "Próximos" . Se você quiser usar o novo certificado de servidor imediatamente, prossiga com a rotação do certificado de servidor atualizando seus clientes e concluindo a rotação.
gcloud
Para instâncias que usam certificados de servidor autoassinados (CA por instância) :
- Para obter informações sobre o certificado do servidor, use o comando sql ssl server-ca-certs list :
gcloud sql ssl server-ca-certs list \ --instance=INSTANCE_NAME
- Para criar um certificado de servidor, use o comando sql ssl server-ca-certs create :
gcloud sql ssl server-ca-certs create \ --instance=INSTANCE_NAME
- Baixe as informações do certificado para um arquivo PEM local:
gcloud sql ssl server-ca-certs list \ --format="value(cert)" \ --instance=INSTANCE_NAME > \ FILE_PATH/FILE_NAME.pem
- Atualize todos os seus clientes para usar as novas informações copiando o arquivo baixado para as máquinas host do cliente, substituindo os arquivos
server-ca.pem
existentes.
Para instâncias que usam certificados de servidor emitidos por uma CA compartilhada :
- Para obter informações sobre o certificado do servidor, use o comando sql ssl server-certs list :
gcloud sql ssl server-certs list \ --instance=INSTANCE_NAME
- Para criar um certificado de servidor, use o comando sql ssl server-certs create :
gcloud sql ssl server-certs create \ --instance=INSTANCE_NAME
- Baixe as informações do certificado para um arquivo PEM local:
gcloud sql ssl server-certs list \ --format="value(ca_cert.cert)" \ --instance=INSTANCE_NAME > \ FILE_PATH/FILE_NAME.pem
- Atualize todos os seus clientes para usar as novas informações copiando o arquivo baixado para as máquinas host do cliente, substituindo os arquivos
server-ca.pem
existentes.
Terraform
Para fornecer informações de certificado de servidor como uma saída, use uma fonte de dados do Terraform :
- Adicione o seguinte ao seu arquivo de configuração do Terraform:
data "google_sql_ca_certs" "ca_certs" { instance = google_sql_database_instance.default.name } locals { furthest_expiration_time = reverse(sort([for k, v in data.google_sql_ca_certs.ca_certs.certs : v.expiration_time]))[0] latest_ca_cert = [for v in data.google_sql_ca_certs.ca_certs.certs : v.cert if v.expiration_time == local.furthest_expiration_time] } output "db_latest_ca_cert" { description = "Latest CA certificate used by the primary database server" value = local.latest_ca_cert sensitive = true }
- Para criar o arquivo
server-ca.pem
, execute o seguinte comando:terraform output db_latest_ca_cert > server-ca.pem
Use conexões criptografadas
Saiba mais sobre como o SQL Server usa conexões criptografadas .
Verificação de identidade do servidor
A verificação de identidade do servidor depende da configuração da hierarquia da autoridade de certificação (CA) do servidor da sua instância do Cloud SQL.
Para instâncias que usam uma CA por instância, a verificação da CA também verifica a identidade do servidor, já que cada instância possui uma CA exclusiva. Para instâncias que usam uma CA compartilhada, a verificação do nome do host, juntamente com a verificação da CA, é necessária para a verificação da identidade do servidor, já que as CAs do servidor são compartilhadas entre as instâncias.
Se você tiver uma CA por instância, poderá executar a verificação de identidade do servidor baseada em nome DNS apenas para instâncias configuradas com o Private Service Connect. Se você tiver uma CA compartilhada, poderá executar a verificação de identidade do servidor baseada em nome DNS para todos os tipos de instâncias, ou seja, Private Service Connect , Private Service Access e instâncias com IP público.
Se estiver usando uma CA gerenciada pelo cliente, você poderá verificar a cadeia de confiança da CA e executar a verificação de identidade do servidor baseada em nome DNS para qualquer tipo de instância que use uma CA gerenciada pelo cliente para seu serverCAmode
.
Ao selecionar a opção de CA gerenciada pelo cliente para sua instância, você pode inserir nomes DNS personalizados no campo SAN do certificado do servidor. Para obter mais informações, consulte Editar um campo SAN personalizado .
Você pode visualizar qual hierarquia de CA está configurada para uma instância do Cloud SQL visualizando os detalhes da instância. Para obter mais informações, consulte Exibir informações da instância .
Habilitar verificação de identidade do servidor
Se você selecionar CA compartilhada como o modo de CA do servidor da sua instância do Cloud SQL ou se configurar nomes DNS personalizados usando valores SAN personalizados , recomendamos que você também habilite a verificação de identidade do servidor.
Instâncias que usam CA compartilhada como modo de CA do servidor contêm o nome DNS da instância no campo Nome Alternativo da Entidade (SAN) do certificado do servidor. Você pode obter esse nome DNS usando a API de pesquisa de instância e a resposta como um nome de host para verificação de identidade do servidor. Você precisa configurar a resolução DNS para o nome DNS.
Para habilitar a verificação de identidade do servidor para uma instância que usa uma CA compartilhada, conclua as seguintes etapas:
Recupere o nome DNS.
Para visualizar informações resumidas sobre uma instância do Cloud SQL, incluindo o nome DNS da instância, use o comando
gcloud sql instances describe
:gcloud sql instances describe INSTANCE_NAME \ --project=PROJECT_ID
Faça as seguintes substituições:
- INSTANCE_NAME : o nome da instância do Cloud SQL
- PROJECT_ID : o ID ou número do projeto do Google Cloud projeto que contém a instância
Na resposta, procure o campo
dnsNames:
Este campo pode retornar vários nomes DNS, que têm os seguintes formatos:Configuração de rede Formato de nome DNS Nível de nome Conexão de serviço privado ou endereço IP público INSTANCE_UID . PROJECT_DNS_LABEL . REGION_NAME .sql.goog.
Exemplo :
1a23b4cd5e67.1a2b345c6d27.us-central1.sql.goog.
Exemplo Acesso a serviços privados INSTANCE_UID . PROJECT_DNS_LABEL . REGION_NAME .sql-psa.goog.
Exemplo :1a23b4cd5e67.1a2b345c6d27.us-central1.sql-psa.goog.
Exemplo
Crie o registro DNS em uma zona DNS . Se você estiver se conectando de forma privada, crie o registro DNS em uma zona DNS privada na rede de Nuvem Privada Virtual (VPC) correspondente.
Ao se conectar à instância do Cloud SQL para SQL Server, configure o nome DNS ou o endereço IP como nome do host. Em seguida, habilite a verificação de identidade do servidor especificando o sinalizador
-N
parasqlcmd
ou selecionando a opção Criptografar Conexão/Criptografia do SSMS.Outros drivers do SQL Server têm sinalizadores ou configurações semelhantes.
O que vem a seguir
- Gerencie certificados SSL/TLS na sua instância do Cloud SQL.
- Saiba mais sobre como a criptografia é tratada em Google Cloud .