Esta página descreve como você pode usar o Secure Socket Layer (SSL), agora Transport Layer Security (TLS), no seu 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 seu cliente e o banco de dados na sua 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 de servidor
Ao criar uma instância, o Cloud SQL cria e instala automaticamente um certificado de servidor assinado por uma autoridade de certificação (CA). Você pode baixar o 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. Opcionalmente, você pode escolher o tipo de CA que o Cloud SQL usa para assinar o certificado do servidor.
Certificados de cliente
Opcionalmente, 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 usando SSL/TLS
Ao se conectar a uma instância do Cloud SQL a partir de clientes, você pode usar SSL/TLS para conexões diretas, bem como para conexões que usam o Cloud SQL Auth Proxy ou o Cloud SQL Language Connectors .
Para conexões diretas, o Google recomenda fortemente aplicar a criptografia SSL/TLS usando a configuração do modo SSL no Cloud SQL. Opcionalmente, você também pode aplicar a verificação do certificado do cliente. Para mais informações, consulte Aplicar criptografia SSL/TLS .
Para conexões que usam o Cloud SQL Auth Proxy ou o Cloud SQL Language Connectors, as conexões são criptografadas automaticamente com SSL/TLS, juntamente com a verificação de identidade do cliente e do servidor, sem exigir que você baixe um certificado de CA do servidor e um certificado de cliente.
Para obter mais informações sobre as opções de conectividade do Cloud SQL, consulte Sobre as conexões do Cloud SQL .
Para obter mais informações sobre a configuração SSL/TLS do lado do cliente, consulte a documentação do seu mecanismo de banco de dados .Hierarquias de autoridade certificadora (CA)
Esta seção descreve os três tipos de autoridade de certificação (CA) de servidor que você pode escolher para suas instâncias do Cloud SQL. Você tem três opções:
CA por instância : com esta opção, uma CA 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 CAs. Para escolher a CA por instância, selecione a Autoridade de Certificação Interna Gerenciada pelo Google (Google Cloud console) ou especifique
GOOGLE_MANAGED_INTERNAL_CApara a configuraçãoserverCaMode(API de administração do Cloud SQL) ou o sinalizador--server-ca-mode( CLI do gcloud ) ao criar a instância . Se você deixar a configuração ou o sinalizador sem especificar ao criar uma instância, esta opção será o valor padrão para a instância.CA compartilhada : com esta opção, é utilizada uma hierarquia de CAs composta por uma CA raiz e CAs 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. O Cloud SQL hospeda e gerencia a CA raiz e as CAs de servidor subordinadas em Google CloudServiço de Autoridade Certificadora (Serviço de CA). O Cloud SQL também gerencia a rotação da CA raiz e das CAs de servidor subordinadas, além de fornecer links públicos para os pacotes de certificados de CA para download. Para escolher uma CA compartilhada, especifique
GOOGLE_MANAGED_CAS_CApara a configuraçãoserverCaMode(API de administração do Cloud SQL) ou o sinalizador--server-ca-mode( CLI do gcloud ) ao criar a instância .CA gerenciada pelo cliente : com esta opção, você cria e gerencia sua própria hierarquia de CA. Escolha esta opção se desejar gerenciar suas próprias CAs e certificados. Para escolher a CA gerenciada pelo cliente, você precisa criar um pool de CAs e uma CA no Serviço de CA. No Cloud SQL, especifique o pool de CAs e
CUSTOMER_MANAGED_CAS_CApara a configuraçãoserverCaMode(API de administração do Cloud SQL) ou o sinalizador--server-ca-mode( CLI do gcloud ) ao criar a instância .
Depois de criar uma instância, você pode visualizar qual hierarquia de CA está configurada para uma instância do Cloud SQL usando o comando gcloud sql instances describe ou no Google Cloud console. Para obter mais informações, consulte Exibir 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 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 com algoritmo SHA384 | Algoritmo de Assinatura Digital de Curva Elíptica (ECDSA) com chave de 384 bits com algoritmo SHA384 |
| Período de validade da CA | 10 anos | 25 anos para CA raiz e 10 anos para 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 da CA é gerenciada pelo Cloud SQL | Sim |
| Rotação do certificado do servidor 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 para a instância correspondente. | A CA raiz e as CAs subordinadas são as âncoras de confiança para todas as instâncias em uma determinada região. | As CAs que você cria e gerencia são as âncoras de confiança. |
| Verificação de identidade do servidor | A verificação da CA verifica a identidade do servidor, pois cada instância tem uma CA exclusiva. | A verificação do nome do host junto com a verificação da CA é necessária para a verificação da identidade do servidor, pois as CAs do servidor são compartilhadas entre as instâncias. | Embora a CA possa não ser compartilhada entre instâncias, talvez você queira verificar o nome do host junto com a verificação da 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 habilitadas 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, precisará 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ância. 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, precisará 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ância. O nome do host pode ser usado para verificação de identidade do servidor. |
* Para a opção de CA gerenciada pelo cliente, o período de validade padrão de um certificado de CA no Serviço de CA é de 10 anos. Você tem a opção de 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 de CA mais frequentes, e um período de validade inferior a um ano pode afetar o período de validade dos certificados do seu servidor. Para obter mais informações, consulte Gerenciando a rotação de CAs .
** 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 inferior a um ano para o seu certificado de CA, o seu certificado de servidor terá um período de validade menor. Para obter mais informações sobre como configurar o período de validade do seu 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 o gcloud CLI , a API de administração do Cloud SQL ou o Terraform.
O Cloud SQL cria uma nova CA 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 sem especificar usando a API de Administração do Cloud SQL ou a CLI gcloud ou selecionar a opção Autoridade de Certificação Interna do Google em Google Cloud console.
O diagrama a seguir mostra a hierarquia de CA por instância.
CAs compartilhadas hospedadas pelo CA Service
A hierarquia de CA compartilhada é a configuração padrão do modo de CA do servidor quando você cria uma instância usando o Google Cloud console.
Este modo de CA de servidor consiste em uma CA raiz e CAs de servidor subordinadas em cada região. As CAs de servidor subordinadas emitem certificados de servidor e são compartilhadas entre instâncias na região. O Cloud SQL gerencia a rotação das CAs de servidor regionais compartilhadas e fornece links públicos para baixar os pacotes de certificados de CA.
Você pode configurar uma instância para usar uma hierarquia de CA de servidor onde 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. Você também pode selecionar Autoridade de Certificação CAS Gerenciada pelo Google em Google Cloud console.
O diagrama a seguir mostra a hierarquia de CA compartilhada.
CAs gerenciadas pelo cliente
Este modo de CA do servidor permite que você configure sua própria hierarquia de CA no Serviço de CA.
Para usar a opção de CA gerenciada pelo cliente no Cloud SQL, crie um pool de CAs na mesma região das suas 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 CAs no campo serverCaPool e configure o campo serverCaMode com o valor CUSTOMER_MANAGED_CAS_CA . O Serviço de CA fornece uma CA do pool de CAs e a utiliza para emitir o certificado de servidor para a instância.
Ao criar CAs no Serviço CA, você pode criar uma CA raiz ou uma CA subordinada, dependendo do seu caso de uso. Por exemplo, você pode querer criar uma CA subordinada se planeja configurar uma hierarquia de CA raiz ou encadear para uma CA externa.
Selecione a opção CA gerenciada pelo cliente somente se desejar gerenciar suas próprias CAs e certificados. Para obter 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 rotacionar seu certificado de servidor, para que o novo certificado possa ser facilmente trocado antes que o antigo expire.
Para instâncias que usam hierarquias de CA por instância, CA compartilhada ou CA gerenciada pelo cliente, cerca de três meses antes do certificado de servidor expirar para uma instância do Cloud SQL, os proprietários do projeto recebem um e-mail do Cloud SQL informando que o processo de rotação de certificados foi iniciado para essa instância. O e-mail fornece o nome da instância e informa que o Cloud SQL adicionou um novo certificado de servidor ao projeto. O certificado de servidor existente continua funcionando normalmente. Na prática, a instância tem dois certificados de servidor durante esse período.
O comando de rotação de certificado de servidor a ser usado depende se você está usando um certificado de servidor emitido por uma CA por instância ou um certificado de servidor emitido pela CA compartilhada ou pela CA gerenciada pelo cliente.
Antes que o certificado do servidor atual expire, baixe o novo arquivo server-ca.pem , que contém as informações do certificado do servidor atual e do novo. Atualize seus clientes PostgreSQL para usar o novo arquivo, copiando-o para todas as suas máquinas host do cliente PostgreSQL, substituindo o arquivo existente.
Após a atualização de todos os seus clientes PostgreSQL, envie um comando de rotação (para CA por instância) ou um comando de rotação (para CA compartilhada ou CA gerenciada pelo cliente) para a instância do Cloud SQL para alternar para o novo certificado do servidor. Após isso, o certificado do servidor antigo não será mais reconhecido e somente o novo certificado do servidor poderá ser usado.
Os certificados do cliente não são afetados pela rotação do certificado do servidor.Expiração 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 expiração de 10 anos. Antes que esses certificados expirem, execute a rotação de certificados de CA do servidor .
Para instâncias que usam CAs compartilhadas ( serverCaMode definido como GOOGLE_MANAGED_CAS_CA ), o período de expiração dos certificados do servidor é de 1 ano. Antes da expiração, execute uma rotação de certificados do servidor . O certificado da autoridade de certificação (CA) raiz tem um período de expiração de 25 anos, enquanto o certificado da CA compartilhada subordinada tem um período de expiração de 10 anos. O Cloud SQL cuida dessa rotação.
Se estiver usando uma CA gerenciada pelo cliente ( serverCaMode definido como CUSTOMER_MANAGED_CAS_CA ), você poderá realizar a rotação de certificados de CA rotacionando as CAs no pool de CAs criado. O período de expiração de uma CA normalmente é de 10 anos, mas você pode configurar um período de validade menor para sua CA no Serviço de CA.
Para rotacionar as ACs, use o processo de rotação de ACs no Serviço de AC. Para obter mais informações, consulte Gerenciando a rotação de ACs .
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 falharão. Para evitar interrupções nas conexões do cliente, gire o certificado do servidor antes que ele expire.
Independentemente de usar o modo de servidor de CA por instância, a CA compartilhada ou a CA gerenciada pelo cliente, você pode redefinir a configuração SSL da sua instância do Cloud SQL a qualquer momento.
O que vem a seguir
Configure SSL/TLS na sua instância do Cloud SQL.
Saiba mais sobre como a criptografia é tratada no Google Cloud .
- Conecte-se usando SSL/TLS à sua instância do Cloud SQL.
- Gerencie SSL/TLS na sua instância do Cloud SQL.
- Saiba mais sobre como o PostgreSQL usa SSL/TLS .
Esta página descreve como você pode usar o Secure Socket Layer (SSL), agora Transport Layer Security (TLS), no seu 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 seu cliente e o banco de dados na sua 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 de servidor
Ao criar uma instância, o Cloud SQL cria e instala automaticamente um certificado de servidor assinado por uma autoridade de certificação (CA). Você pode baixar o 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. Opcionalmente, você pode escolher o tipo de CA que o Cloud SQL usa para assinar o certificado do servidor.
Certificados de cliente
Opcionalmente, 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 usando SSL/TLS
Ao se conectar a uma instância do Cloud SQL a partir de clientes, você pode usar SSL/TLS para conexões diretas, bem como para conexões que usam o Cloud SQL Auth Proxy ou o Cloud SQL Language Connectors .
Para conexões diretas, o Google recomenda fortemente aplicar a criptografia SSL/TLS usando a configuração do modo SSL no Cloud SQL. Opcionalmente, você também pode aplicar a verificação do certificado do cliente. Para mais informações, consulte Aplicar criptografia SSL/TLS .
Para conexões que usam o Cloud SQL Auth Proxy ou o Cloud SQL Language Connectors, as conexões são criptografadas automaticamente com SSL/TLS, juntamente com a verificação de identidade do cliente e do servidor, sem exigir que você baixe um certificado de CA do servidor e um certificado de cliente.
Para obter mais informações sobre as opções de conectividade do Cloud SQL, consulte Sobre as conexões do Cloud SQL .
Para obter mais informações sobre a configuração SSL/TLS do lado do cliente, consulte a documentação do seu mecanismo de banco de dados .Hierarquias de autoridade certificadora (CA)
Esta seção descreve os três tipos de autoridade de certificação (CA) de servidor que você pode escolher para suas instâncias do Cloud SQL. Você tem três opções:
CA por instância : com esta opção, uma CA 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 CAs. Para escolher a CA por instância, selecione a Autoridade de Certificação Interna Gerenciada pelo Google (Google Cloud console) ou especifique
GOOGLE_MANAGED_INTERNAL_CApara a configuraçãoserverCaMode(API de administração do Cloud SQL) ou o sinalizador--server-ca-mode( CLI do gcloud ) ao criar a instância . Se você deixar a configuração ou o sinalizador sem especificar ao criar uma instância, esta opção será o valor padrão para a instância.CA compartilhada : com esta opção, é utilizada uma hierarquia de CAs composta por uma CA raiz e CAs 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. O Cloud SQL hospeda e gerencia a CA raiz e as CAs de servidor subordinadas em Google CloudServiço de Autoridade Certificadora (Serviço de CA). O Cloud SQL também gerencia a rotação da CA raiz e das CAs de servidor subordinadas, além de fornecer links públicos para os pacotes de certificados de CA para download. Para escolher uma CA compartilhada, especifique
GOOGLE_MANAGED_CAS_CApara a configuraçãoserverCaMode(API de administração do Cloud SQL) ou o sinalizador--server-ca-mode( CLI do gcloud ) ao criar a instância .CA gerenciada pelo cliente : com esta opção, você cria e gerencia sua própria hierarquia de CA. Escolha esta opção se desejar gerenciar suas próprias CAs e certificados. Para escolher a CA gerenciada pelo cliente, você precisa criar um pool de CAs e uma CA no Serviço de CA. No Cloud SQL, especifique o pool de CAs e
CUSTOMER_MANAGED_CAS_CApara a configuraçãoserverCaMode(API de administração do Cloud SQL) ou o sinalizador--server-ca-mode( CLI do gcloud ) ao criar a instância .
Depois de criar uma instância, você pode visualizar qual hierarquia de CA está configurada para uma instância do Cloud SQL usando o comando gcloud sql instances describe ou no Google Cloud console. Para obter mais informações, consulte Exibir 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 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 com algoritmo SHA384 | Algoritmo de Assinatura Digital de Curva Elíptica (ECDSA) com chave de 384 bits com algoritmo SHA384 |
| Período de validade da CA | 10 anos | 25 anos para CA raiz e 10 anos para 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 da CA é gerenciada pelo Cloud SQL | Sim |
| Rotação do certificado do servidor 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 para a instância correspondente. | A CA raiz e as CAs subordinadas são as âncoras de confiança para todas as instâncias em uma determinada região. | As CAs que você cria e gerencia são as âncoras de confiança. |
| Verificação de identidade do servidor | A verificação da CA verifica a identidade do servidor, pois cada instância tem uma CA exclusiva. | A verificação do nome do host junto com a verificação da CA é necessária para a verificação da identidade do servidor, pois as CAs do servidor são compartilhadas entre as instâncias. | Embora a CA possa não ser compartilhada entre instâncias, talvez você queira verificar o nome do host junto com a verificação da 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 habilitadas 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, precisará 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ância. 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, precisará 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ância. O nome do host pode ser usado para verificação de identidade do servidor. |
* Para a opção de CA gerenciada pelo cliente, o período de validade padrão de um certificado de CA no Serviço de CA é de 10 anos. Você tem a opção de 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 de CA mais frequentes, e um período de validade inferior a um ano pode afetar o período de validade dos certificados do seu servidor. Para obter mais informações, consulte Gerenciando a rotação de CAs .
** 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 inferior a um ano para o seu certificado de CA, o seu certificado de servidor terá um período de validade menor. Para obter mais informações sobre como configurar o período de validade do seu 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 o gcloud CLI , a API de administração do Cloud SQL ou o Terraform.
O Cloud SQL cria uma nova CA 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 sem especificar usando a API de Administração do Cloud SQL ou a CLI gcloud ou selecionar a opção Autoridade de Certificação Interna do Google em Google Cloud console.
O diagrama a seguir mostra a hierarquia de CA por instância.
CAs compartilhadas hospedadas pelo CA Service
A hierarquia de CA compartilhada é a configuração padrão do modo de CA do servidor quando você cria uma instância usando o Google Cloud console.
Este modo de CA de servidor consiste em uma CA raiz e CAs de servidor subordinadas em cada região. As CAs de servidor subordinadas emitem certificados de servidor e são compartilhadas entre instâncias na região. O Cloud SQL gerencia a rotação das CAs de servidor regionais compartilhadas e fornece links públicos para baixar os pacotes de certificados de CA.
Você pode configurar uma instância para usar uma hierarquia de CA de servidor onde 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. Você também pode selecionar Autoridade de Certificação CAS Gerenciada pelo Google em Google Cloud console.
O diagrama a seguir mostra a hierarquia de CA compartilhada.
CAs gerenciadas pelo cliente
Este modo de CA do servidor permite que você configure sua própria hierarquia de CA no Serviço de CA.
Para usar a opção de CA gerenciada pelo cliente no Cloud SQL, crie um pool de CAs na mesma região das suas 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 CAs no campo serverCaPool e configure o campo serverCaMode com o valor CUSTOMER_MANAGED_CAS_CA . O Serviço de CA fornece uma CA do pool de CAs e a utiliza para emitir o certificado de servidor para a instância.
Ao criar CAs no Serviço CA, você pode criar uma CA raiz ou uma CA subordinada, dependendo do seu caso de uso. Por exemplo, você pode querer criar uma CA subordinada se planeja configurar uma hierarquia de CA raiz ou encadear para uma CA externa.
Selecione a opção CA gerenciada pelo cliente somente se desejar gerenciar suas próprias CAs e certificados. Para obter 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 rotacionar seu certificado de servidor, para que o novo certificado possa ser facilmente trocado antes que o antigo expire.
Para instâncias que usam hierarquias de CA por instância, CA compartilhada ou CA gerenciada pelo cliente, cerca de três meses antes do certificado de servidor expirar para uma instância do Cloud SQL, os proprietários do projeto recebem um e-mail do Cloud SQL informando que o processo de rotação de certificados foi iniciado para essa instância. O e-mail fornece o nome da instância e informa que o Cloud SQL adicionou um novo certificado de servidor ao projeto. O certificado de servidor existente continua funcionando normalmente. Na prática, a instância tem dois certificados de servidor durante esse período.
O comando de rotação de certificado de servidor a ser usado depende se você está usando um certificado de servidor emitido por uma CA por instância ou um certificado de servidor emitido pela CA compartilhada ou pela CA gerenciada pelo cliente.
Antes que o certificado do servidor atual expire, baixe o novo arquivo server-ca.pem , que contém as informações do certificado do servidor atual e do novo. Atualize seus clientes PostgreSQL para usar o novo arquivo, copiando-o para todas as suas máquinas host do cliente PostgreSQL, substituindo o arquivo existente.
Após a atualização de todos os seus clientes PostgreSQL, envie um comando de rotação (para CA por instância) ou um comando de rotação (para CA compartilhada ou CA gerenciada pelo cliente) para a instância do Cloud SQL para alternar para o novo certificado do servidor. Após isso, o certificado do servidor antigo não será mais reconhecido e somente o novo certificado do servidor poderá ser usado.
Os certificados do cliente não são afetados pela rotação do certificado do servidor.Expiração 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 expiração de 10 anos. Antes que esses certificados expirem, execute a rotação de certificados de CA do servidor .
Para instâncias que usam CAs compartilhadas ( serverCaMode definido como GOOGLE_MANAGED_CAS_CA ), o período de expiração dos certificados do servidor é de 1 ano. Antes da expiração, execute uma rotação de certificados do servidor . O certificado da autoridade de certificação (CA) raiz tem um período de expiração de 25 anos, enquanto o certificado da CA compartilhada subordinada tem um período de expiração de 10 anos. O Cloud SQL cuida dessa rotação.
Se estiver usando uma CA gerenciada pelo cliente ( serverCaMode definido como CUSTOMER_MANAGED_CAS_CA ), você poderá realizar a rotação de certificados de CA rotacionando as CAs no pool de CAs criado. O período de expiração de uma CA normalmente é de 10 anos, mas você pode configurar um período de validade menor para sua CA no Serviço de CA.
Para rotacionar as ACs, use o processo de rotação de ACs no Serviço de AC. Para obter mais informações, consulte Gerenciando a rotação de ACs .
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 falharão. Para evitar interrupções nas conexões do cliente, gire o certificado do servidor antes que ele expire.
Independentemente de usar o modo de servidor de CA por instância, a CA compartilhada ou a CA gerenciada pelo cliente, você pode redefinir a configuração SSL da sua instância do Cloud SQL a qualquer momento.
O que vem a seguir
Configure SSL/TLS na sua instância do Cloud SQL.
Saiba mais sobre como a criptografia é tratada no Google Cloud .
- Conecte-se usando SSL/TLS à sua instância do Cloud SQL.
- Gerencie SSL/TLS na sua instância do Cloud SQL.
- Saiba mais sobre como o PostgreSQL usa SSL/TLS .
Esta página descreve como você pode usar o Secure Socket Layer (SSL), agora Transport Layer Security (TLS), no seu 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 seu cliente e o banco de dados na sua 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 de servidor
Ao criar uma instância, o Cloud SQL cria e instala automaticamente um certificado de servidor assinado por uma autoridade de certificação (CA). Você pode baixar o 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. Opcionalmente, você pode escolher o tipo de CA que o Cloud SQL usa para assinar o certificado do servidor.
Certificados de cliente
Opcionalmente, 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 usando SSL/TLS
Ao se conectar a uma instância do Cloud SQL a partir de clientes, você pode usar SSL/TLS para conexões diretas, bem como para conexões que usam o Cloud SQL Auth Proxy ou o Cloud SQL Language Connectors .
Para conexões diretas, o Google recomenda fortemente aplicar a criptografia SSL/TLS usando a configuração do modo SSL no Cloud SQL. Opcionalmente, você também pode aplicar a verificação do certificado do cliente. Para mais informações, consulte Aplicar criptografia SSL/TLS .
Para conexões que usam o Cloud SQL Auth Proxy ou o Cloud SQL Language Connectors, as conexões são criptografadas automaticamente com SSL/TLS, juntamente com a verificação de identidade do cliente e do servidor, sem exigir que você baixe um certificado de CA do servidor e um certificado de cliente.
Para obter mais informações sobre as opções de conectividade do Cloud SQL, consulte Sobre as conexões do Cloud SQL .
Para obter mais informações sobre a configuração SSL/TLS do lado do cliente, consulte a documentação do seu mecanismo de banco de dados .Hierarquias de autoridade certificadora (CA)
Esta seção descreve os três tipos de autoridade de certificação (CA) de servidor que você pode escolher para suas instâncias do Cloud SQL. Você tem três opções:
CA por instância : com esta opção, uma CA 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 CAs. Para escolher a CA por instância, selecione a Autoridade de Certificação Interna Gerenciada pelo Google (Google Cloud console) ou especifique
GOOGLE_MANAGED_INTERNAL_CApara a configuraçãoserverCaMode(API de administração do Cloud SQL) ou o sinalizador--server-ca-mode( CLI do gcloud ) ao criar a instância . Se você deixar a configuração ou o sinalizador sem especificar ao criar uma instância, esta opção será o valor padrão para a instância.CA compartilhada : com esta opção, é utilizada uma hierarquia de CAs composta por uma CA raiz e CAs 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. O Cloud SQL hospeda e gerencia a CA raiz e as CAs de servidor subordinadas em Google CloudServiço de Autoridade Certificadora (Serviço de CA). O Cloud SQL também gerencia a rotação da CA raiz e das CAs de servidor subordinadas, além de fornecer links públicos para os pacotes de certificados de CA para download. Para escolher uma CA compartilhada, especifique
GOOGLE_MANAGED_CAS_CApara a configuraçãoserverCaMode(API de administração do Cloud SQL) ou o sinalizador--server-ca-mode( CLI do gcloud ) ao criar a instância .CA gerenciado pelo cliente : com esta opção, você cria e gerencia sua própria hierarquia de CA. Escolha esta opção se desejar gerenciar seu próprio CAS e certificados. Para escolher a CA gerenciada pelo cliente, você precisa criar um pool de CA e um serviço de CA no CA. No Cloud SQL, especifique o Pool da CA e
CUSTOMER_MANAGED_CAS_CApara a configuraçãoserverCaMode(API do Cloud SQL Admin) ou do sinalizador--server-ca-mode( GCLOUD CLI ) ao criar a instância .
Depois de criar uma instância, você pode visualizar qual hierarquia CA está configurada para uma instância de SQL em nuvem usando as gcloud sql instances describe o comando ou no Google Cloud console. Para obter mais informações, consulte as informações da View Instância .
A tabela a seguir compara as três opções de hierarquia CA.
| Recurso | Por Instance CA | CA compartilhado | CA gerenciado pelo cliente |
|---|---|---|---|
| Estrutura da CA. | Separe CA para cada instância | Root ca e sub -encordado CAS compartilhado em instâncias na mesma região | Hierarquia CA que você cria e gerencia |
| Atributos criptográficos | Chave RSA de 2048 bits com o algoritmo SHA256 | Algoritmo de assinatura digital da curva elípica (ECDSA) com chave de 384 bits com o algoritmo SHA384 | Algoritmo de assinatura digital da curva elípica (ECDSA) com chave de 384 bits com o algoritmo SHA384 |
| Período de validade do CA. | 10 anos | 25 anos para raiz CA e 10 anos para CAS subordinado | Configurável * |
| Período de validade do certificado de servidor | 10 anos | 1 ano | 1 ano ** |
| Rotação iniciada pelo usuário de CA? | Sim | Não. A rotação da CA é gerenciada pela Cloud SQL | Sim |
| Rotação iniciada pelo usuário do certificado do servidor? | Sim | Sim | Sim |
| CA Trust Anchor para conexões TLS | A CA exclusiva por Instance é a âncora de confiança para a instância correspondente. | Raiz CA e CAS subordinada são as âncoras de confiança de todas as instâncias em uma determinada região. | O CAS que você cria e gerencia são as âncoras de confiança. |
| Verificação de identidade do servidor | Verificar a CA verifica a identidade do servidor, pois cada instância possui uma ca. | Verificar o nome do host, juntamente com a verificação da CA, é necessário para a verificação da identidade do servidor, pois o CAS do servidor é compartilhado nas instâncias. | Embora a CA possa não ser compartilhada nas instâncias, convém verificar o nome do host, além de verificar a ca. |
| Assunto Nome alternativo (SAN) Campo 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 serviço privado Connect . 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 o nome do host, precisará configurar a resolução DNS. | O campo SAN contém o nome do host (nome DNS da instância) para todos os tipos de instâncias. 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 o nome do host, precisará configurar a resolução DNS. | O campo SAN contém o nome do host (nome DNS da instância) para todos os tipos de instâncias. Nome do host pode ser usado para verificação de identidade do servidor. |
* Para a opção CA gerenciada pelo cliente, o período de validade padrão de um certificado de CA no serviço CA é de 10 anos. Você tem a opção de 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 de CA mais frequentes e um período de validade menor que um ano pode afetar o período de validade dos seus certificados de servidor. Para mais informações, consulte Gerenciando a rotação da CA.
** Para a opção 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 mais curto. Para obter mais informações sobre como definir o período de validade do seu certificado de CA após a criação, consulte Configurações de certificado da CA e crie uma CA root .
Per-Instance CA hospedado por Cloud SQL
A hierarquia CA por instância é a configuração do modo CA do servidor padrão quando você cria uma instância usando a API GCLOUD CLI , Cloud SQL Admin ou Terraform.
O Cloud SQL cria um novo servidor autoassinado para cada instância quando você cria a instância. Para usar essa configuração, configure serverCaMode para GOOGLE_MANAGED_INTERNAL_CA quando você criar a instância. Você pode deixar a configuração serverCaMode não especificada usando a API de Admin em nuvem SQL ou GCLOUD CLI ou selecionar a opção Autoridade de Certificado Interno do Google no Google Cloud console.
O diagrama a seguir mostra a hierarquia de CA por instância.
CAS compartilhada hospedada pela CA Service
A hierarquia compartilhada de CA é a configuração do modo CA do servidor padrão quando você cria uma instância usando o Google Cloud console.
Esse modo CA do servidor consiste em um CA root e CAS do servidor subordinado em cada região. O servidor subordinado CAS CER certificados de servidor e é compartilhado em instâncias na região. O Cloud SQL lida com a rotação do servidor regional compartilhado CAS e fornece links disponíveis ao público para baixar os pacotes de certificados da CA.
Você pode configurar uma instância para usar uma hierarquia do servidor CA, onde o CAS emissor é compartilhado nas instâncias na mesma região. Para usar essa configuração, configure serverCaMode para GOOGLE_MANAGED_CAS_CA quando você criar a instância. Você também pode selecionar a autoridade de certificação CAS gerenciada do Google no Google Cloud console.
O diagrama a seguir mostra a hierarquia compartilhada da CA.
CAS gerenciada pelo cliente
Este modo CA de servidor permite configurar sua própria hierarquia de CA no serviço CA.
Para usar a opção CA gerenciada pelo cliente no Cloud SQL, você cria um pool de CA na mesma região que suas instâncias SQL em nuvem. Então você cria pelo menos um ca. Ao criar a instância do Cloud SQL, especifique o ID do pool da CA no campo serverCaPool e configure o campo serverCaMode com o valor do CUSTOMER_MANAGED_CAS_CA . O serviço CA fornece uma CA do pool da CA e usa esse CA para emitir o certificado do servidor para a instância.
Ao criar CAS no serviço CA, você pode criar uma CA root ou uma CA subordinada, dependendo do seu caso de uso. Por exemplo, convém criar uma CA subordinada se planeja configurar uma hierarquia de raiz ca ou corrente até uma ca.
Selecione a opção CA gerenciada pelo cliente somente se desejar gerenciar seu próprio CAS e certificados. Para mais informações, consulte Use uma CA gerenciada pelo cliente .
Como funciona a rotação do certificado do servidor
O Cloud SQL fornece maneiras de girar o certificado do servidor, para que o novo certificado possa ser trocado sem problemas antes que o certificado antigo expire.
Para instâncias que usam as hierarquias CA por Instance CA, compartilhado ou administrado pelo cliente, cerca de três meses antes do certificado do servidor expirar para uma instância de SQL em nuvem, os proprietários do projeto recebem um email do Cloud SQL, afirmando que o processo de rotação do certificado começou para essa instância. O email fornece o nome da instância e diz que o Cloud SQL adicionou um novo certificado de servidor ao projeto. O certificado de servidor existente continua a funcionar normalmente. Com efeito, a instância possui dois certificados de servidor durante esse período.
O comando de rotação do certificado do servidor a ser usado depende se você está usando um certificado de servidor emitido por uma CA por instance ou um certificado de servidor emitido pela CA compartilhada ou pela CA 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 de certificado para os certificados atuais e novos do servidor. Atualize seus clientes PostGresql para usar o novo arquivo, copiando -o para todas as suas máquinas host do cliente PostGresql, substituindo o arquivo existente.
Depois que todos os seus clientes PostgreSQL foram atualizados, envie um comando girlate (para o comando por instância) ou gire (para CA compartilhado ou CA gerenciado pelo cliente) para a instância do Cloud SQL para girar para o novo certificado do servidor. Depois disso, o certificado de servidor antigo não é mais reconhecido e apenas o novo certificado do servidor pode ser usado.
Os certificados de clientes não são afetados pela rotação do certificado do servidor.Expiração do certificado SSL
Para instâncias SQL em nuvem que usam CAS por instância ( serverCaMode está definido como GOOGLE_MANAGED_INTERNAL_CA ), os certificados SSL vêm com um período de vencimento de 10 anos. Antes que esses certificados expirem, execute a rotação do certificado CA do servidor .
Para instâncias que usam CAS compartilhada ( serverCaMode está definido como GOOGLE_MANAGED_CAS_CA ), o período de expiração dos certificados do servidor é de 1 ano. Antes da expiração, execute uma rotação de certificado de servidor . O certificado da Autoridade de Certificação Raiz (CA) tem um período de validade de 25 anos e o certificado de CA compartilhado subordinado tem um período de validade de 10 anos. A nuvem SQL lida com sua rotação.
Se você estiver usando um CA gerenciado pelo cliente ( serverCaMode estiver definido como CUSTOMER_MANAGED_CAS_CA ), poderá executar a rotação do certificado CA girando o CAS no pool CA que você criou. O período de validade de uma CA é tipicamente 10 anos, mas você pode configurar um período de validade mais curto para o seu serviço de CA no CA.
Para girar o CAS, use o processo de rotação da CA no serviço CA. Para mais informações, consulte Gerenciando a rotação da CA.
Se um cliente estiver configurado para verificar a CA ou verificar o nome do host no certificado do servidor, as conexões desse cliente com as instâncias do Cloud SQL com certificados de servidor expirado falharão. Para evitar interrupções nas conexões do cliente, gire o certificado do servidor antes que o certificado expire.
Se você usa a CA PER-Instance, a CA compartilhada ou o modo de servidor CA gerenciado pelo cliente, você pode redefinir a configuração SSL da sua instância SQL em nuvem a qualquer momento.
O que vem a seguir
Configure SSL/TLS em sua instância SQL em nuvem.
Saiba mais sobre como a criptografia é tratada no Google Cloud .
- Conecte -se usando SSL/TLS à sua instância SQL em nuvem.
- Gerencie SSL/TLS na sua instância SQL em nuvem.
- Saiba mais sobre como o PostgreSQL usa SSL/TLS .
Esta página descreve como você pode usar a camada de soquete segura (SSL), agora a segurança da camada de transporte (TLS), desde o seu aplicativo até criptografar conexões para as instâncias do Cloud SQL.
Visão geral
O Cloud SQL suporta conectar -se a uma instância usando o protocolo SSL/TLS. As conexões SSL/TLS fornecem uma camada de segurança criptografando dados em trânsito entre o seu cliente e o banco de dados na sua instância SQL em nuvem. Opcionalmente, sua conexão SSL/TLS pode executar a verificação da identidade do servidor, validando o certificado do servidor instalado na instância do SQL em nuvem e na verificação da identidade do cliente, validando o certificado do cliente instalado no cliente.
Certificados de servidor
Quando você cria uma instância, o Cloud SQL cria e instala automaticamente um certificado de servidor assinado por uma autoridade de certificação (CA). Você pode fazer o download do certificado da CA na máquina host do cliente e usá -lo para verificar a identidade do SQL da CA e do servidor em nuvem. Opcionalmente, você pode escolher o tipo de CA que o Cloud SQL usa para assinar o certificado do servidor.
Certificados de cliente
Opcionalmente, você pode criar e baixar certificados de cliente, juntamente com as teclas da máquina host do cliente para obter autenticação mútua (verificação de identidade do servidor e do cliente). Você não pode escolher o tipo de CA que o Cloud SQL usa para assinar o certificado do cliente.
Conecte usando SSL/TLS
Ao conectar -se a uma instância do Cloud SQL dos clientes, você pode usar o SSL/TLS para conexões diretas, bem como para conexões que usam o Proxy de autenticação SQL em nuvem ou os conectores de linguagem SQL em nuvem .
Para conexões diretas, o Google recomenda fortemente a aplicação da criptografia SSL/TLS usando a configuração do modo SSL no Cloud SQL. Opcionalmente, você também pode aplicar a verificação do certificado de cliente. Para obter mais informações, consulte a aplicação da aplicação de SSL/TLS .
Para conexões que usam os conectores de linguagem SQL de autenticação SQL ou nuvem SQL, as conexões são criptografadas automaticamente com SSL/TLS, juntamente com a verificação de identidade do cliente e do servidor, sem exigir que você baixe um certificado de CA do servidor e certificado de cliente.
Para obter mais informações sobre as opções de conectividade em nuvem SQL, consulte sobre as conexões SQL em nuvem .
Para obter mais informações sobre a configuração SSL/TLS do lado do cliente, consulte a documentação para o seu mecanismo de banco de dados .Hierarquias da Autoridade de Certificação (CA)
Esta seção descreve os três tipos de autoridade de certificado de servidor (CA) que você pode escolher para suas instâncias SQL em nuvem. Você tem três opções:
PER-Instance CA : Com esta opção, uma CA interna dedicada a cada instância do SQL em nuvem assina o certificado do servidor para essa instância. O Cloud SQL cria e gerencia esses CAS. Para escolher a CA por instância, selecione Autoridade de certificação interna gerenciada do Google (Google Cloud console) ou especifique
GOOGLE_MANAGED_INTERNAL_CApara a configuraçãoserverCaMode(API de Admin em Cloud SQL) ou o sinalizador--server-ca-mode( GCLOUD CLI ) quando você criar a instância . Se você deixar a configuração ou o sinalizador não especificado ao criar uma instância, essa opção será o valor padrão da instância.CA compartilhado : Com esta opção, é usada uma hierarquia de CA que consiste em uma CA da raiz e o CAS do servidor subordinado. O CAS do servidor subordinado em uma região assina os certificados do servidor e é compartilhado nas instâncias da região. O Cloud SQL hospeda e gerencia o CA root e o servidor subordinado CAS no Google CloudServiço de Autoridade de Certificação (Serviço da CA). O Cloud SQL também lida com a rotação do CA root e do Subordinate Server CAS e fornece links disponíveis ao público para os feixes de certificados CA para download. Para escolher a CA compartilhada, especifique
GOOGLE_MANAGED_CAS_CApara a configuraçãoserverCaMode(API de Admin em Cloud SQL) ou o sinalizador--server-ca-mode( GCLOUD CLI ) quando você criar a instância .CA gerenciado pelo cliente : com esta opção, você cria e gerencia sua própria hierarquia de CA. Escolha esta opção se desejar gerenciar seu próprio CAS e certificados. Para escolher a CA gerenciada pelo cliente, você precisa criar um pool de CA e um serviço de CA no CA. No Cloud SQL, especifique o Pool da CA e
CUSTOMER_MANAGED_CAS_CApara a configuraçãoserverCaMode(API do Cloud SQL Admin) ou do sinalizador--server-ca-mode( GCLOUD CLI ) ao criar a instância .
Depois de criar uma instância, você pode visualizar qual hierarquia CA está configurada para uma instância de SQL em nuvem usando as gcloud sql instances describe o comando ou no Google Cloud console. Para obter mais informações, consulte as informações da View Instância .
A tabela a seguir compara as três opções de hierarquia CA.
| Recurso | Por Instance CA | CA compartilhado | CA gerenciado pelo cliente |
|---|---|---|---|
| Estrutura da CA. | Separe CA para cada instância | Root ca e sub -encordado CAS compartilhado em instâncias na mesma região | Hierarquia CA que você cria e gerencia |
| Atributos criptográficos | Chave RSA de 2048 bits com o algoritmo SHA256 | Algoritmo de assinatura digital da curva elípica (ECDSA) com chave de 384 bits com o algoritmo SHA384 | Algoritmo de assinatura digital da curva elípica (ECDSA) com chave de 384 bits com o algoritmo SHA384 |
| Período de validade do CA. | 10 anos | 25 anos para raiz CA e 10 anos para CAS subordinado | Configurável * |
| Período de validade do certificado de servidor | 10 anos | 1 ano | 1 ano ** |
| Rotação iniciada pelo usuário de CA? | Sim | Não. A rotação da CA é gerenciada pela Cloud SQL | Sim |
| Rotação iniciada pelo usuário do certificado do servidor? | Sim | Sim | Sim |
| CA Trust Anchor para conexões TLS | A CA exclusiva por Instance é a âncora de confiança para a instância correspondente. | Raiz CA e CAS subordinada são as âncoras de confiança de todas as instâncias em uma determinada região. | O CAS que você cria e gerencia são as âncoras de confiança. |
| Verificação de identidade do servidor | Verificar a CA verifica a identidade do servidor, pois cada instância possui uma ca. | Verificar o nome do host, juntamente com a verificação da CA, é necessário para a verificação da identidade do servidor, pois o CAS do servidor é compartilhado nas instâncias. | Embora a CA possa não ser compartilhada nas instâncias, convém verificar o nome do host, além de verificar a ca. |
| Assunto Nome alternativo (SAN) Campo 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 serviço privado Connect . 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 o nome do host, precisará configurar a resolução DNS. | O campo SAN contém o nome do host (nome DNS da instância) para todos os tipos de instâncias. 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 o nome do host, precisará configurar a resolução DNS. | O campo SAN contém o nome do host (nome DNS da instância) para todos os tipos de instâncias. Nome do host pode ser usado para verificação de identidade do servidor. |
* Para a opção CA gerenciada pelo cliente, o período de validade padrão de um certificado de CA no serviço CA é de 10 anos. Você tem a opção de 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 de CA mais frequentes e um período de validade menor que um ano pode afetar o período de validade dos seus certificados de servidor. Para mais informações, consulte Gerenciando a rotação da CA.
** Para a opção 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 mais curto. Para obter mais informações sobre como definir o período de validade do seu certificado de CA após a criação, consulte Configurações de certificado da CA e crie uma CA root .
Per-Instance CA hospedado por Cloud SQL
A hierarquia CA por instância é a configuração do modo CA do servidor padrão quando você cria uma instância usando a API GCLOUD CLI , Cloud SQL Admin ou Terraform.
O Cloud SQL cria um novo servidor autoassinado para cada instância quando você cria a instância. Para usar essa configuração, configure serverCaMode para GOOGLE_MANAGED_INTERNAL_CA quando você criar a instância. Você pode deixar a configuração serverCaMode não especificada usando a API de Admin em nuvem SQL ou GCLOUD CLI ou selecionar a opção Autoridade de Certificado Interno do Google no Google Cloud console.
O diagrama a seguir mostra a hierarquia de CA por instância.
CAS compartilhada hospedada pela CA Service
A hierarquia compartilhada de CA é a configuração do modo CA do servidor padrão quando você cria uma instância usando o Google Cloud console.
Esse modo CA do servidor consiste em um CA root e CAS do servidor subordinado em cada região. O servidor subordinado CAS CER certificados de servidor e é compartilhado em instâncias na região. O Cloud SQL lida com a rotação do servidor regional compartilhado CAS e fornece links disponíveis ao público para baixar os pacotes de certificados da CA.
Você pode configurar uma instância para usar uma hierarquia do servidor CA, onde o CAS emissor é compartilhado nas instâncias na mesma região. Para usar essa configuração, configure serverCaMode para GOOGLE_MANAGED_CAS_CA quando você criar a instância. Você também pode selecionar a autoridade de certificação CAS gerenciada do Google no Google Cloud console.
O diagrama a seguir mostra a hierarquia compartilhada da CA.
CAS gerenciada pelo cliente
Este modo CA de servidor permite configurar sua própria hierarquia de CA no serviço CA.
Para usar a opção CA gerenciada pelo cliente no Cloud SQL, você cria um pool de CA na mesma região que suas instâncias SQL em nuvem. Então você cria pelo menos um ca. Ao criar a instância do Cloud SQL, especifique o ID do pool da CA no campo serverCaPool e configure o campo serverCaMode com o valor do CUSTOMER_MANAGED_CAS_CA . O serviço CA fornece uma CA do pool da CA e usa esse CA para emitir o certificado do servidor para a instância.
Ao criar CAS no serviço CA, você pode criar uma CA root ou uma CA subordinada, dependendo do seu caso de uso. Por exemplo, convém criar uma CA subordinada se planeja configurar uma hierarquia de raiz ca ou corrente até uma ca.
Selecione a opção CA gerenciada pelo cliente somente se desejar gerenciar seu próprio CAS e certificados. Para mais informações, consulte Use uma CA gerenciada pelo cliente .
Como funciona a rotação do certificado do servidor
O Cloud SQL fornece maneiras de girar o certificado do servidor, para que o novo certificado possa ser trocado sem problemas antes que o certificado antigo expire.
Para instâncias que usam as hierarquias CA por Instance CA, compartilhado ou administrado pelo cliente, cerca de três meses antes do certificado do servidor expirar para uma instância de SQL em nuvem, os proprietários do projeto recebem um email do Cloud SQL, afirmando que o processo de rotação do certificado começou para essa instância. O email fornece o nome da instância e diz que o Cloud SQL adicionou um novo certificado de servidor ao projeto. O certificado de servidor existente continua a funcionar normalmente. Com efeito, a instância possui dois certificados de servidor durante esse período.
O comando de rotação do certificado do servidor a ser usado depende se você está usando um certificado de servidor emitido por uma CA por instance ou um certificado de servidor emitido pela CA compartilhada ou pela CA 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 de certificado para os certificados atuais e novos do servidor. Atualize seus clientes PostGresql para usar o novo arquivo, copiando -o para todas as suas máquinas host do cliente PostGresql, substituindo o arquivo existente.
Depois que todos os seus clientes PostgreSQL foram atualizados, envie um comando girlate (para o comando por instância) ou gire (para CA compartilhado ou CA gerenciado pelo cliente) para a instância do Cloud SQL para girar para o novo certificado do servidor. Depois disso, o certificado de servidor antigo não é mais reconhecido e apenas o novo certificado do servidor pode ser usado.
Os certificados de clientes não são afetados pela rotação do certificado do servidor.Expiração do certificado SSL
Para instâncias SQL em nuvem que usam CAS por instância ( serverCaMode está definido como GOOGLE_MANAGED_INTERNAL_CA ), os certificados SSL vêm com um período de vencimento de 10 anos. Antes que esses certificados expirem, execute a rotação do certificado CA do servidor .
Para instâncias que usam CAS compartilhada ( serverCaMode está definido como GOOGLE_MANAGED_CAS_CA ), o período de expiração dos certificados do servidor é de 1 ano. Antes da expiração, execute uma rotação de certificado de servidor . O certificado da Autoridade de Certificação Raiz (CA) tem um período de validade de 25 anos e o certificado de CA compartilhado subordinado tem um período de validade de 10 anos. A nuvem SQL lida com sua rotação.
Se você estiver usando um CA gerenciado pelo cliente ( serverCaMode estiver definido como CUSTOMER_MANAGED_CAS_CA ), poderá executar a rotação do certificado CA girando o CAS no pool CA que você criou. O período de validade de uma CA é tipicamente 10 anos, mas você pode configurar um período de validade mais curto para o seu serviço de CA no CA.
Para girar o CAS, use o processo de rotação da CA no serviço CA. Para mais informações, consulte Gerenciando a rotação da CA.
Se um cliente estiver configurado para verificar a CA ou verificar o nome do host no certificado do servidor, as conexões desse cliente com as instâncias do Cloud SQL com certificados de servidor expirado falharão. Para evitar interrupções nas conexões do cliente, gire o certificado do servidor antes que o certificado expire.
Se você usa a CA PER-Instance, a CA compartilhada ou o modo de servidor CA gerenciado pelo cliente, você pode redefinir a configuração SSL da sua instância SQL em nuvem a qualquer momento.
O que vem a seguir
Configure SSL/TLS em sua instância SQL em nuvem.
Saiba mais sobre como a criptografia é tratada no Google Cloud .
- Conecte -se usando SSL/TLS à sua instância SQL em nuvem.
- Gerencie SSL/TLS na sua instância SQL em nuvem.
- Saiba mais sobre como o PostgreSQL usa SSL/TLS .