Esta página describe cómo puede usar Secure Socket Layer (SSL), ahora Transport Layer Security (TLS), desde su aplicación para cifrar conexiones a instancias de Cloud SQL.
Descripción general
Cloud SQL admite la conexión a una instancia mediante el protocolo SSL/TLS. Las conexiones SSL/TLS proporcionan una capa de seguridad al cifrar los datos en tránsito entre el cliente y la base de datos de la instancia de Cloud SQL. Opcionalmente, la conexión SSL/TLS puede realizar la verificación de identidad del servidor mediante la validación del certificado de servidor instalado en la instancia de Cloud SQL, así como la verificación de identidad del cliente mediante la validación del certificado de cliente instalado en el cliente.
Certificados de servidor
Al crear una instancia, Cloud SQL crea e instala automáticamente un certificado de servidor firmado por una autoridad de certificación (CA). Puede descargar el certificado de la CA al equipo host del cliente y usarlo para verificar la identidad de la CA y del servidor de Cloud SQL. Opcionalmente, puede elegir el tipo de CA que Cloud SQL utiliza para firmar el certificado de servidor.
Certificados de cliente
Opcionalmente, puede crear y descargar certificados de cliente junto con las claves en el equipo host del cliente para la autenticación mutua (verificación de identidad del servidor y del cliente). No puede elegir el tipo de CA que Cloud SQL utiliza para firmar el certificado de cliente.
Conectarse mediante SSL/TLS
Al conectarse a una instancia de Cloud SQL desde los clientes, puede usar SSL/TLS para conexiones directas, así como para conexiones que usan Cloud SQL Auth Proxy o Cloud SQL Language Connectors .
Para conexiones directas, Google recomienda encarecidamente aplicar el cifrado SSL/TLS mediante la configuración del modo SSL en Cloud SQL. Opcionalmente, también puede aplicar la verificación del certificado del cliente. Para obtener más información, consulte Aplicar el cifrado SSL/TLS .
Para las conexiones que usan Cloud SQL Auth Proxy o Cloud SQL Language Connectors, las conexiones se cifran automáticamente con SSL/TLS junto con la verificación de identidad del cliente y del servidor sin necesidad de descargar un certificado de CA del servidor y un certificado del cliente.
Para obtener más información sobre las opciones de conectividad de Cloud SQL, consulte Acerca de las conexiones de Cloud SQL .
Para obtener más información sobre la configuración de SSL/TLS del lado del cliente, consulte la documentación de su motor de base de datos .Jerarquías de autoridades de certificación (CA)
En esta sección se describen los tres tipos de autoridad de certificación (CA) de servidor que puede elegir para sus instancias de Cloud SQL. Tiene tres opciones:
CA por instancia : con esta opción, una CA interna dedicada a cada instancia de Cloud SQL firma el certificado de servidor para esa instancia. Cloud SQL crea y administra estas CA. Para elegir una CA por instancia, seleccione la autoridad de certificación interna administrada por Google (Google Cloud consola) o especifique
GOOGLE_MANAGED_INTERNAL_CApara la configuraciónserverCaMode(API de administración de Cloud SQL) o el indicador--server-ca-mode( CLI de gcloud ) al crear la instancia . Si no especifica la configuración ni el indicador al crear una instancia, esta opción será el valor predeterminado.CA compartida : con esta opción, se utiliza una jerarquía de CA compuesta por una CA raíz y CA de servidor subordinadas. Las CA de servidor subordinadas de una región firman los certificados de servidor y se comparten entre las instancias de la región. Cloud SQL aloja y administra la CA raíz y las CA de servidor subordinadas en Google CloudServicio de Autoridad de Certificación (Servicio CA). Cloud SQL también gestiona la rotación de la CA raíz y las CA de servidor subordinadas, y proporciona enlaces públicos a los paquetes de certificados de la CA para su descarga. Para elegir una CA compartida, especifique
GOOGLE_MANAGED_CAS_CAen la configuraciónserverCaMode(API de administración de Cloud SQL) o el indicador--server-ca-mode( CLI de gcloud ) al crear la instancia .CA administrada por el cliente : con esta opción, puede crear y administrar su propia jerarquía de CA. Elija esta opción si desea administrar sus propias CA y certificados. Para elegir una CA administrada por el cliente, debe crear un grupo de CA y una CA en CA Service. En Cloud SQL, especifique el grupo de CA y
CUSTOMER_MANAGED_CAS_CApara la configuraciónserverCaMode(API de administración de Cloud SQL) o el indicador--server-ca-mode( CLI de gcloud ) al crear la instancia .
Después de crear una instancia, puede ver qué jerarquía de CA está configurada para una instancia de Cloud SQL mediante el comando gcloud sql instances describe o en el Google Cloud consola. Para obtener más información, consulte Ver información de la instancia .
La siguiente tabla compara las tres opciones de jerarquía de CA.
| Característica | CA por instancia | CA compartida | CA administrada por el cliente |
|---|---|---|---|
| Estructura de CA | CA independiente para cada instancia | CA raíz y CA subordinadas compartidas entre instancias en la misma región | Jerarquía de CA que usted crea y administra |
| Atributos criptográficos | Clave RSA de 2048 bits con algoritmo SHA256 | Algoritmo de firma digital de curva elíptica (ECDSA) con clave de 384 bits con algoritmo SHA384 | Algoritmo de firma digital de curva elíptica (ECDSA) con clave de 384 bits con algoritmo SHA384 |
| Período de validez de CA | 10 años | 25 años para la CA raíz y 10 años para las CA subordinadas | Configurable * |
| Período de validez del certificado del servidor | 10 años | 1 año | 1 año** |
| ¿Rotación de CA iniciada por el usuario? | Sí | No. La rotación de CA está gestionada por Cloud SQL | Sí |
| ¿Rotación de certificado de servidor iniciada por el usuario? | Sí | Sí | Sí |
| Ancla de confianza de CA para conexiones TLS | La CA única por instancia es el ancla de confianza para la instancia correspondiente. | La CA raíz y las CA subordinadas son los anclajes de confianza para todas las instancias en una región determinada. | Las CA que usted crea y administra son los anclajes de confianza. |
| Verificación de identidad del servidor | Al verificar la CA se verifica la identidad del servidor ya que cada instancia tiene una CA única. | La verificación del nombre de host junto con la verificación de la CA es necesaria para la verificación de la identidad del servidor, ya que las CA del servidor se comparten entre instancias. | Aunque es posible que la CA no se comparta entre instancias, es posible que desee verificar el nombre de host junto con la CA. |
| Campo de nombre alternativo del sujeto (SAN) en los certificados de servidor | El campo SAN contiene el nombre de host (nombre DNS de la instancia) solo para instancias habilitadas con Private Service Connect . El nombre de host se puede usar para la verificación de identidad del servidor. Si se conecta a una instancia de Cloud SQL usando el nombre DNS como nombre de host, debe configurar la resolución DNS. | El campo SAN contiene el nombre de host (nombre DNS de la instancia) para todos los tipos de instancia. El nombre de host se puede usar para la verificación de identidad del servidor. Si se conecta a una instancia de Cloud SQL usando el nombre DNS como nombre de host, debe configurar la resolución DNS. | El campo SAN contiene el nombre de host (nombre DNS de la instancia) para todos los tipos de instancia. El nombre de host puede usarse para la verificación de identidad del servidor. |
* Para la opción de CA administrada por el cliente, el periodo de validez predeterminado de un certificado de CA en CA Service es de 10 años. Puede configurar un periodo de validez diferente para sus certificados de CA. Un periodo de validez más corto para la CA podría requerir rotaciones más frecuentes, y un periodo de validez inferior a un año podría afectar el periodo de validez de sus certificados de servidor. Para obtener más información, consulte "Administrar la rotación de CA" .
** Para la opción de CA administrada por el cliente, el periodo de validez predeterminado de un certificado de servidor es de un año. Sin embargo, si configura un periodo de validez inferior a un año para su certificado de CA, el periodo de validez de su certificado de servidor será menor. Para obtener más información sobre cómo configurar el periodo de validez de su certificado de CA al crearlo, consulte Configuración del certificado de CA y Crear una CA raíz .
CA por instancia alojada por Cloud SQL
La jerarquía de CA por instancia es la configuración del modo de CA del servidor predeterminada cuando crea una instancia utilizando la CLI de gcloud , la API de administración de Cloud SQL o Terraform.
Cloud SQL crea una nueva CA de servidor autofirmada para cada instancia al crearla. Para usar esta configuración, configure serverCaMode en GOOGLE_MANAGED_INTERNAL_CA al crear la instancia. Puede dejar la configuración serverCaMode sin especificar mediante la API de administración de Cloud SQL o la CLI de gcloud , o seleccionar la opción de autoridad de certificación interna de Google en el... Google Cloud consola.
El siguiente diagrama muestra la jerarquía de CA por instancia.
CA compartidas alojadas por CA Service
La jerarquía de CA compartida es la configuración del modo de CA de servidor predeterminada cuando crea una instancia mediante Google Cloud consola.
Este modo de CA de servidor consta de una CA raíz y CA de servidor subordinadas en cada región. Las CA de servidor subordinadas emiten certificados de servidor y se comparten entre las instancias de la región. Cloud SQL gestiona la rotación de las CA de servidor regionales compartidas y proporciona enlaces públicos para descargar los paquetes de certificados de CA.
Puede configurar una instancia para que utilice una jerarquía de CA de servidor donde las CA emisoras se compartan entre las instancias de la misma región. Para usar esta configuración, configure serverCaMode en GOOGLE_MANAGED_CAS_CA al crear la instancia. También puede seleccionar la Autoridad de certificación CAS administrada por Google en el... Google Cloud consola.
El siguiente diagrama muestra la jerarquía de CA compartida.
CA gestionadas por el cliente
Este modo de CA de servidor le permite configurar su propia jerarquía de CA en CA Service.
Para usar la opción de CA administrada por el cliente en Cloud SQL, cree un grupo de CA en la misma región que sus instancias de Cloud SQL. A continuación, cree al menos una CA. Al crear la instancia de Cloud SQL, especifique el ID del grupo de CA en el campo serverCaPool y configure el campo serverCaMode con el valor CUSTOMER_MANAGED_CAS_CA . El servicio de CA proporciona una CA del grupo de CA y la utiliza para emitir el certificado de servidor para la instancia.
Al crear CA en CA Service, puede crear una CA raíz o una CA subordinada, según su caso práctico. Por ejemplo, podría querer crear una CA subordinada si planea configurar una jerarquía de CA raíz o conectarla con una CA externa.
Seleccione la opción de CA administrada por el cliente solo si desea administrar sus propias CA y certificados. Para obtener más información, consulte Usar una CA administrada por el cliente .
Cómo funciona la rotación de certificados de servidor
Cloud SQL ofrece formas de rotar el certificado de su servidor, de modo que el nuevo certificado se pueda cambiar sin problemas antes de que caduque el antiguo.
En el caso de las instancias que utilizan jerarquías de CA por instancia, CA compartida o CA administrada por el cliente, aproximadamente tres meses antes de que caduque el certificado de servidor de una instancia de Cloud SQL, los propietarios del proyecto reciben un correo electrónico de Cloud SQL que indica que el proceso de rotación de certificados ha comenzado para esa instancia. El correo electrónico proporciona el nombre de la instancia e indica que Cloud SQL ha añadido un nuevo certificado de servidor al proyecto. El certificado de servidor existente sigue funcionando con normalidad. De hecho, la instancia tiene dos certificados de servidor durante este período.
El comando de rotación de certificado de servidor a utilizar depende de si está usando un certificado de servidor emitido por una CA por instancia o un certificado de servidor emitido por una CA compartida o una CA administrada por el cliente.
Antes de que caduque el certificado del servidor actual, descargue el nuevo archivo server-ca.pem , que contiene la información del certificado actual y del nuevo. Actualice sus clientes PostgreSQL para que usen el nuevo archivo; para ello, copíelo en todos los hosts de sus clientes PostgreSQL y reemplace el archivo existente.
Una vez actualizados todos sus clientes de PostgreSQL, envíe un comando de rotación (para CA por instancia) o un comando de rotación (para CA compartida o CA administrada por el cliente) a la instancia de Cloud SQL para rotar al nuevo certificado de servidor. Una vez hecho esto, el certificado de servidor anterior ya no se reconoce y solo se puede usar el nuevo.
Los certificados de cliente no se ven afectados por la rotación de certificados del servidor.Caducidad del certificado SSL
Para las instancias de Cloud SQL que usan CA por instancia ( serverCaMode está configurado en GOOGLE_MANAGED_INTERNAL_CA ), los certificados SSL tienen un período de caducidad de 10 años. Antes de que caduquen, realice la rotación de certificados de la CA del servidor .
Para las instancias que utilizan CA compartidas ( serverCaMode está configurado como GOOGLE_MANAGED_CAS_CA ), el periodo de caducidad de los certificados de servidor es de 1 año. Antes de la fecha de caducidad, realice una rotación de certificados de servidor . El certificado de la autoridad de certificación (CA) raíz tiene un periodo de caducidad de 25 años y el certificado de la CA compartida subordinada tiene un periodo de caducidad de 10 años. Cloud SQL gestiona su rotación.
Si utiliza una CA administrada por el cliente ( serverCaMode está configurado como CUSTOMER_MANAGED_CAS_CA ), puede rotar los certificados de CA en el grupo de CA que creó. El período de vencimiento de una CA suele ser de 10 años, pero puede configurar un período de validez más corto en CA Service.
Para rotar las CA, utilice el proceso de rotación de CA en CA Service. Para obtener más información, consulte "Administración de la rotación de CA" .
Si un cliente está configurado para verificar la CA o el nombre de host en el certificado del servidor, las conexiones de ese cliente a instancias de Cloud SQL con certificados de servidor caducados fallarán. Para evitar interrupciones en las conexiones del cliente, rote el certificado del servidor antes de que caduque.
Ya sea que use el modo de servidor CA por instancia, CA compartida o CA administrado por el cliente, puede restablecer la configuración SSL de su instancia de Cloud SQL en cualquier momento.
¿Qué sigue?
Configure SSL/TLS en su instancia de Cloud SQL.
Obtenga más información sobre cómo se gestiona el cifrado en Google Cloud .
- Conéctese mediante SSL/TLS a su instancia de Cloud SQL.
- Administre SSL/TLS en su instancia de Cloud SQL.
- Obtenga más información sobre cómo PostgreSQL utiliza SSL/TLS .
Esta página describe cómo puede usar Secure Socket Layer (SSL), ahora Transport Layer Security (TLS), desde su aplicación para cifrar conexiones a instancias de Cloud SQL.
Descripción general
Cloud SQL admite la conexión a una instancia mediante el protocolo SSL/TLS. Las conexiones SSL/TLS proporcionan una capa de seguridad al cifrar los datos en tránsito entre el cliente y la base de datos de la instancia de Cloud SQL. Opcionalmente, la conexión SSL/TLS puede realizar la verificación de identidad del servidor mediante la validación del certificado de servidor instalado en la instancia de Cloud SQL, así como la verificación de identidad del cliente mediante la validación del certificado de cliente instalado en el cliente.
Certificados de servidor
Al crear una instancia, Cloud SQL crea e instala automáticamente un certificado de servidor firmado por una autoridad de certificación (CA). Puede descargar el certificado de la CA al equipo host del cliente y usarlo para verificar la identidad de la CA y del servidor de Cloud SQL. Opcionalmente, puede elegir el tipo de CA que Cloud SQL utiliza para firmar el certificado de servidor.
Certificados de cliente
Opcionalmente, puede crear y descargar certificados de cliente junto con las claves en el equipo host del cliente para la autenticación mutua (verificación de identidad del servidor y del cliente). No puede elegir el tipo de CA que Cloud SQL utiliza para firmar el certificado de cliente.
Conectarse mediante SSL/TLS
Al conectarse a una instancia de Cloud SQL desde los clientes, puede usar SSL/TLS para conexiones directas, así como para conexiones que usan Cloud SQL Auth Proxy o Cloud SQL Language Connectors .
Para conexiones directas, Google recomienda encarecidamente aplicar el cifrado SSL/TLS mediante la configuración del modo SSL en Cloud SQL. Opcionalmente, también puede aplicar la verificación del certificado del cliente. Para obtener más información, consulte Aplicar el cifrado SSL/TLS .
Para las conexiones que usan Cloud SQL Auth Proxy o Cloud SQL Language Connectors, las conexiones se cifran automáticamente con SSL/TLS junto con la verificación de identidad del cliente y del servidor sin necesidad de descargar un certificado de CA del servidor y un certificado del cliente.
Para obtener más información sobre las opciones de conectividad de Cloud SQL, consulte Acerca de las conexiones de Cloud SQL .
Para obtener más información sobre la configuración de SSL/TLS del lado del cliente, consulte la documentación de su motor de base de datos .Jerarquías de autoridades de certificación (CA)
En esta sección se describen los tres tipos de autoridad de certificación (CA) de servidor que puede elegir para sus instancias de Cloud SQL. Tiene tres opciones:
CA por instancia : con esta opción, una CA interna dedicada a cada instancia de Cloud SQL firma el certificado de servidor para esa instancia. Cloud SQL crea y administra estas CA. Para elegir una CA por instancia, seleccione la autoridad de certificación interna administrada por Google (Google Cloud consola) o especifique
GOOGLE_MANAGED_INTERNAL_CApara la configuraciónserverCaMode(API de administración de Cloud SQL) o el indicador--server-ca-mode( CLI de gcloud ) al crear la instancia . Si no especifica la configuración ni el indicador al crear una instancia, esta opción será el valor predeterminado.CA compartida : con esta opción, se utiliza una jerarquía de CA compuesta por una CA raíz y CA de servidor subordinadas. Las CA de servidor subordinadas de una región firman los certificados de servidor y se comparten entre las instancias de la región. Cloud SQL aloja y administra la CA raíz y las CA de servidor subordinadas en Google CloudServicio de Autoridad de Certificación (Servicio CA). Cloud SQL también gestiona la rotación de la CA raíz y las CA de servidor subordinadas, y proporciona enlaces públicos a los paquetes de certificados de la CA para su descarga. Para elegir una CA compartida, especifique
GOOGLE_MANAGED_CAS_CAen la configuraciónserverCaMode(API de administración de Cloud SQL) o el indicador--server-ca-mode( CLI de gcloud ) al crear la instancia .CA administrada por el cliente : con esta opción, puede crear y administrar su propia jerarquía de CA. Elija esta opción si desea administrar sus propias CA y certificados. Para elegir una CA administrada por el cliente, debe crear un grupo de CA y una CA en CA Service. En Cloud SQL, especifique el grupo de CA y
CUSTOMER_MANAGED_CAS_CApara la configuraciónserverCaMode(API de administración de Cloud SQL) o el indicador--server-ca-mode( CLI de gcloud ) al crear la instancia .
Después de crear una instancia, puede ver qué jerarquía de CA está configurada para una instancia de Cloud SQL mediante el comando gcloud sql instances describe o en el Google Cloud consola. Para obtener más información, consulte Ver información de la instancia .
La siguiente tabla compara las tres opciones de jerarquía de CA.
| Característica | CA por instancia | CA compartida | CA administrada por el cliente |
|---|---|---|---|
| Estructura de CA | CA independiente para cada instancia | CA raíz y CA subordinadas compartidas entre instancias en la misma región | Jerarquía de CA que usted crea y administra |
| Atributos criptográficos | Clave RSA de 2048 bits con algoritmo SHA256 | Algoritmo de firma digital de curva elíptica (ECDSA) con clave de 384 bits con algoritmo SHA384 | Algoritmo de firma digital de curva elíptica (ECDSA) con clave de 384 bits con algoritmo SHA384 |
| Período de validez de CA | 10 años | 25 años para la CA raíz y 10 años para las CA subordinadas | Configurable * |
| Período de validez del certificado del servidor | 10 años | 1 año | 1 año** |
| ¿Rotación de CA iniciada por el usuario? | Sí | No. La rotación de CA está gestionada por Cloud SQL | Sí |
| ¿Rotación de certificado de servidor iniciada por el usuario? | Sí | Sí | Sí |
| Ancla de confianza de CA para conexiones TLS | La CA única por instancia es el ancla de confianza para la instancia correspondiente. | La CA raíz y las CA subordinadas son los anclajes de confianza para todas las instancias en una región determinada. | Las CA que usted crea y administra son los anclajes de confianza. |
| Verificación de identidad del servidor | Al verificar la CA se verifica la identidad del servidor ya que cada instancia tiene una CA única. | La verificación del nombre de host junto con la verificación de la CA es necesaria para la verificación de la identidad del servidor, ya que las CA del servidor se comparten entre instancias. | Aunque es posible que la CA no se comparta entre instancias, es posible que desee verificar el nombre de host junto con la CA. |
| Campo de nombre alternativo del sujeto (SAN) en los certificados de servidor | El campo SAN contiene el nombre de host (nombre DNS de la instancia) solo para instancias habilitadas con Private Service Connect . El nombre de host se puede usar para la verificación de identidad del servidor. Si se conecta a una instancia de Cloud SQL usando el nombre DNS como nombre de host, debe configurar la resolución DNS. | El campo SAN contiene el nombre de host (nombre DNS de la instancia) para todos los tipos de instancia. El nombre de host se puede usar para la verificación de identidad del servidor. Si se conecta a una instancia de Cloud SQL usando el nombre DNS como nombre de host, debe configurar la resolución DNS. | El campo SAN contiene el nombre de host (nombre DNS de la instancia) para todos los tipos de instancia. El nombre de host puede usarse para la verificación de identidad del servidor. |
* Para la opción de CA administrada por el cliente, el periodo de validez predeterminado de un certificado de CA en CA Service es de 10 años. Puede configurar un periodo de validez diferente para sus certificados de CA. Un periodo de validez más corto para la CA podría requerir rotaciones más frecuentes, y un periodo de validez inferior a un año podría afectar el periodo de validez de sus certificados de servidor. Para obtener más información, consulte "Administrar la rotación de CA" .
** Para la opción de CA administrada por el cliente, el periodo de validez predeterminado de un certificado de servidor es de un año. Sin embargo, si configura un periodo de validez inferior a un año para su certificado de CA, el periodo de validez de su certificado de servidor será menor. Para obtener más información sobre cómo configurar el periodo de validez de su certificado de CA al crearlo, consulte Configuración del certificado de CA y Crear una CA raíz .
CA por instancia alojada por Cloud SQL
La jerarquía de CA por instancia es la configuración del modo de CA del servidor predeterminada cuando crea una instancia utilizando la CLI de gcloud , la API de administración de Cloud SQL o Terraform.
Cloud SQL crea una nueva CA de servidor autofirmada para cada instancia al crearla. Para usar esta configuración, configure serverCaMode en GOOGLE_MANAGED_INTERNAL_CA al crear la instancia. Puede dejar la configuración serverCaMode sin especificar mediante la API de administración de Cloud SQL o la CLI de gcloud , o seleccionar la opción de autoridad de certificación interna de Google en el... Google Cloud consola.
El siguiente diagrama muestra la jerarquía de CA por instancia.
CA compartidas alojadas por CA Service
La jerarquía de CA compartida es la configuración del modo de CA de servidor predeterminada cuando crea una instancia mediante Google Cloud consola.
Este modo de CA de servidor consta de una CA raíz y CA de servidor subordinadas en cada región. Las CA de servidor subordinadas emiten certificados de servidor y se comparten entre las instancias de la región. Cloud SQL gestiona la rotación de las CA de servidor regionales compartidas y proporciona enlaces públicos para descargar los paquetes de certificados de CA.
Puede configurar una instancia para que utilice una jerarquía de CA de servidor donde las CA emisoras se compartan entre las instancias de la misma región. Para usar esta configuración, configure serverCaMode en GOOGLE_MANAGED_CAS_CA al crear la instancia. También puede seleccionar la Autoridad de certificación CAS administrada por Google en el... Google Cloud consola.
El siguiente diagrama muestra la jerarquía de CA compartida.
CA gestionadas por el cliente
Este modo de CA de servidor le permite configurar su propia jerarquía de CA en CA Service.
Para usar la opción de CA administrada por el cliente en Cloud SQL, cree un grupo de CA en la misma región que sus instancias de Cloud SQL. A continuación, cree al menos una CA. Al crear la instancia de Cloud SQL, especifique el ID del grupo de CA en el campo serverCaPool y configure el campo serverCaMode con el valor CUSTOMER_MANAGED_CAS_CA . El servicio de CA proporciona una CA del grupo de CA y la utiliza para emitir el certificado de servidor para la instancia.
Al crear CA en CA Service, puede crear una CA raíz o una CA subordinada, según su caso práctico. Por ejemplo, podría querer crear una CA subordinada si planea configurar una jerarquía de CA raíz o conectarla con una CA externa.
Seleccione la opción de CA administrada por el cliente solo si desea administrar sus propias CA y certificados. Para obtener más información, consulte Usar una CA administrada por el cliente .
Cómo funciona la rotación de certificados de servidor
Cloud SQL ofrece formas de rotar el certificado de su servidor, de modo que el nuevo certificado se pueda cambiar sin problemas antes de que caduque el antiguo.
En el caso de las instancias que utilizan jerarquías de CA por instancia, CA compartida o CA administrada por el cliente, aproximadamente tres meses antes de que caduque el certificado de servidor de una instancia de Cloud SQL, los propietarios del proyecto reciben un correo electrónico de Cloud SQL que indica que el proceso de rotación de certificados ha comenzado para esa instancia. El correo electrónico proporciona el nombre de la instancia e indica que Cloud SQL ha añadido un nuevo certificado de servidor al proyecto. El certificado de servidor existente sigue funcionando con normalidad. De hecho, la instancia tiene dos certificados de servidor durante este período.
El comando de rotación de certificado de servidor a utilizar depende de si está usando un certificado de servidor emitido por una CA por instancia o un certificado de servidor emitido por una CA compartida o una CA administrada por el cliente.
Antes de que caduque el certificado del servidor actual, descargue el nuevo archivo server-ca.pem , que contiene la información del certificado actual y del nuevo. Actualice sus clientes PostgreSQL para que usen el nuevo archivo; para ello, copíelo en todos los hosts de sus clientes PostgreSQL y reemplace el archivo existente.
Una vez actualizados todos sus clientes de PostgreSQL, envíe un comando de rotación (para CA por instancia) o un comando de rotación (para CA compartida o CA administrada por el cliente) a la instancia de Cloud SQL para rotar al nuevo certificado de servidor. Una vez hecho esto, el certificado de servidor anterior ya no se reconoce y solo se puede usar el nuevo.
Los certificados de cliente no se ven afectados por la rotación de certificados del servidor.Caducidad del certificado SSL
Para las instancias de Cloud SQL que usan CA por instancia ( serverCaMode está configurado en GOOGLE_MANAGED_INTERNAL_CA ), los certificados SSL tienen un período de caducidad de 10 años. Antes de que caduquen, realice la rotación de certificados de la CA del servidor .
Para las instancias que utilizan CA compartidas ( serverCaMode está configurado como GOOGLE_MANAGED_CAS_CA ), el periodo de caducidad de los certificados de servidor es de 1 año. Antes de la fecha de caducidad, realice una rotación de certificados de servidor . El certificado de la autoridad de certificación (CA) raíz tiene un periodo de caducidad de 25 años y el certificado de la CA compartida subordinada tiene un periodo de caducidad de 10 años. Cloud SQL gestiona su rotación.
Si utiliza una CA administrada por el cliente ( serverCaMode está configurado como CUSTOMER_MANAGED_CAS_CA ), puede rotar los certificados de CA en el grupo de CA que creó. El período de vencimiento de una CA suele ser de 10 años, pero puede configurar un período de validez más corto en CA Service.
Para rotar las CA, utilice el proceso de rotación de CA en CA Service. Para obtener más información, consulte "Administración de la rotación de CA" .
Si un cliente está configurado para verificar la CA o el nombre de host en el certificado del servidor, las conexiones de ese cliente a instancias de Cloud SQL con certificados de servidor caducados fallarán. Para evitar interrupciones en las conexiones del cliente, rote el certificado del servidor antes de que caduque.
Ya sea que use el modo de servidor CA por instancia, CA compartida o CA administrado por el cliente, puede restablecer la configuración SSL de su instancia de Cloud SQL en cualquier momento.
¿Qué sigue?
Configure SSL/TLS en su instancia de Cloud SQL.
Obtenga más información sobre cómo se gestiona el cifrado en Google Cloud .
- Conéctese mediante SSL/TLS a su instancia de Cloud SQL.
- Administre SSL/TLS en su instancia de Cloud SQL.
- Obtenga más información sobre cómo PostgreSQL utiliza SSL/TLS .
Esta página describe cómo puede usar Secure Socket Layer (SSL), ahora Transport Layer Security (TLS), desde su aplicación para cifrar conexiones a instancias de Cloud SQL.
Descripción general
Cloud SQL admite la conexión a una instancia mediante el protocolo SSL/TLS. Las conexiones SSL/TLS proporcionan una capa de seguridad al cifrar los datos en tránsito entre el cliente y la base de datos de la instancia de Cloud SQL. Opcionalmente, la conexión SSL/TLS puede realizar la verificación de identidad del servidor mediante la validación del certificado de servidor instalado en la instancia de Cloud SQL, así como la verificación de identidad del cliente mediante la validación del certificado de cliente instalado en el cliente.
Certificados de servidor
Al crear una instancia, Cloud SQL crea e instala automáticamente un certificado de servidor firmado por una autoridad de certificación (CA). Puede descargar el certificado de la CA al equipo host del cliente y usarlo para verificar la identidad de la CA y del servidor de Cloud SQL. Opcionalmente, puede elegir el tipo de CA que Cloud SQL utiliza para firmar el certificado de servidor.
Certificados de cliente
Opcionalmente, puede crear y descargar certificados de cliente junto con las claves en el equipo host del cliente para la autenticación mutua (verificación de identidad del servidor y del cliente). No puede elegir el tipo de CA que Cloud SQL utiliza para firmar el certificado de cliente.
Conectarse mediante SSL/TLS
Al conectarse a una instancia de Cloud SQL desde los clientes, puede usar SSL/TLS para conexiones directas, así como para conexiones que usan Cloud SQL Auth Proxy o Cloud SQL Language Connectors .
Para conexiones directas, Google recomienda encarecidamente aplicar el cifrado SSL/TLS mediante la configuración del modo SSL en Cloud SQL. Opcionalmente, también puede aplicar la verificación del certificado del cliente. Para obtener más información, consulte Aplicar el cifrado SSL/TLS .
Para las conexiones que usan Cloud SQL Auth Proxy o Cloud SQL Language Connectors, las conexiones se cifran automáticamente con SSL/TLS junto con la verificación de identidad del cliente y del servidor sin necesidad de descargar un certificado de CA del servidor y un certificado del cliente.
Para obtener más información sobre las opciones de conectividad de Cloud SQL, consulte Acerca de las conexiones de Cloud SQL .
Para obtener más información sobre la configuración de SSL/TLS del lado del cliente, consulte la documentación de su motor de base de datos .Jerarquías de autoridades de certificación (CA)
En esta sección se describen los tres tipos de autoridad de certificación (CA) de servidor que puede elegir para sus instancias de Cloud SQL. Tiene tres opciones:
CA por instancia : con esta opción, una CA interna dedicada a cada instancia de Cloud SQL firma el certificado de servidor para esa instancia. Cloud SQL crea y administra estas CA. Para elegir una CA por instancia, seleccione la autoridad de certificación interna administrada por Google (Google Cloud consola) o especifique
GOOGLE_MANAGED_INTERNAL_CApara la configuraciónserverCaMode(API de administración de Cloud SQL) o el indicador--server-ca-mode( CLI de gcloud ) al crear la instancia . Si no especifica la configuración ni el indicador al crear una instancia, esta opción será el valor predeterminado.CA compartida : con esta opción, se utiliza una jerarquía de CA compuesta por una CA raíz y CA de servidor subordinadas. Las CA de servidor subordinadas de una región firman los certificados de servidor y se comparten entre las instancias de la región. Cloud SQL aloja y administra la CA raíz y las CA de servidor subordinadas en Google CloudServicio de Autoridad de Certificación (Servicio CA). Cloud SQL también gestiona la rotación de la CA raíz y las CA de servidor subordinadas, y proporciona enlaces públicos a los paquetes de certificados de la CA para su descarga. Para elegir una CA compartida, especifique
GOOGLE_MANAGED_CAS_CAen la configuraciónserverCaMode(API de administración de Cloud SQL) o el indicador--server-ca-mode( CLI de gcloud ) al crear la instancia .CA administrada por el cliente : con esta opción, puede crear y administrar su propia jerarquía de CA. Elija esta opción si desea administrar sus propias CA y certificados. Para elegir una CA administrada por el cliente, debe crear un grupo de CA y una CA en CA Service. En Cloud SQL, especifique el grupo de CA y
CUSTOMER_MANAGED_CAS_CApara la configuraciónserverCaMode(API de administración de Cloud SQL) o el indicador--server-ca-mode( CLI de gcloud ) al crear la instancia .
Después de crear una instancia, puede ver qué jerarquía de CA está configurada para una instancia de Cloud SQL mediante el comando gcloud sql instances describe o en el Google Cloud consola. Para obtener más información, consulte Ver información de la instancia .
La siguiente tabla compara las tres opciones de jerarquía de CA.
| Característica | CA por instancia | CA compartida | CA administrada por el cliente |
|---|---|---|---|
| Estructura de CA | CA independiente para cada instancia | CA raíz y CA subordinadas compartidas entre instancias en la misma región | Jerarquía de CA que usted crea y administra |
| Atributos criptográficos | Clave RSA de 2048 bits con algoritmo SHA256 | Algoritmo de firma digital de curva elíptica (ECDSA) con clave de 384 bits con algoritmo SHA384 | Algoritmo de firma digital de curva elíptica (ECDSA) con clave de 384 bits con algoritmo SHA384 |
| Período de validez de CA | 10 años | 25 años para la CA raíz y 10 años para las CA subordinadas | Configurable * |
| Período de validez del certificado del servidor | 10 años | 1 año | 1 año** |
| ¿Rotación de CA iniciada por el usuario? | Sí | No. La rotación de CA está gestionada por Cloud SQL | Sí |
| ¿Rotación de certificado de servidor iniciada por el usuario? | Sí | Sí | Sí |
| Ancla de confianza de CA para conexiones TLS | La CA única por instancia es el ancla de confianza para la instancia correspondiente. | La CA raíz y las CA subordinadas son los anclajes de confianza para todas las instancias en una región determinada. | Las CA que usted crea y administra son los anclajes de confianza. |
| Verificación de identidad del servidor | Al verificar la CA se verifica la identidad del servidor ya que cada instancia tiene una CA única. | La verificación del nombre de host junto con la verificación de la CA es necesaria para la verificación de la identidad del servidor, ya que las CA del servidor se comparten entre instancias. | Aunque es posible que la CA no se comparta entre instancias, es posible que desee verificar el nombre de host junto con la CA. |
| Campo de nombre alternativo del sujeto (SAN) en los certificados de servidor | El campo SAN contiene el nombre de host (nombre DNS de la instancia) solo para instancias habilitadas con Private Service Connect . El nombre de host se puede usar para la verificación de identidad del servidor. Si se conecta a una instancia de Cloud SQL usando el nombre DNS como nombre de host, debe configurar la resolución DNS. | El campo SAN contiene el nombre de host (nombre DNS de la instancia) para todos los tipos de instancia. El nombre de host se puede usar para la verificación de identidad del servidor. Si se conecta a una instancia de Cloud SQL usando el nombre DNS como nombre de host, debe configurar la resolución DNS. | El campo SAN contiene el nombre de host (nombre DNS de la instancia) para todos los tipos de instancia. El nombre de host puede usarse para la verificación de identidad del servidor. |
* Para la opción de CA administrada por el cliente, el periodo de validez predeterminado de un certificado de CA en CA Service es de 10 años. Puede configurar un periodo de validez diferente para sus certificados de CA. Un periodo de validez más corto para la CA podría requerir rotaciones más frecuentes, y un periodo de validez inferior a un año podría afectar el periodo de validez de sus certificados de servidor. Para obtener más información, consulte "Administrar la rotación de CA" .
** Para la opción de CA administrada por el cliente, el periodo de validez predeterminado de un certificado de servidor es de un año. Sin embargo, si configura un periodo de validez inferior a un año para su certificado de CA, el periodo de validez de su certificado de servidor será menor. Para obtener más información sobre cómo configurar el periodo de validez de su certificado de CA al crearlo, consulte Configuración del certificado de CA y Crear una CA raíz .
CA por instancia alojada por Cloud SQL
La jerarquía de CA por instancia es la configuración del modo de CA del servidor predeterminada cuando crea una instancia utilizando la CLI de gcloud , la API de administración de Cloud SQL o Terraform.
Cloud SQL crea una nueva CA de servidor autofirmada para cada instancia al crearla. Para usar esta configuración, configure serverCaMode en GOOGLE_MANAGED_INTERNAL_CA al crear la instancia. Puede dejar la configuración serverCaMode sin especificar mediante la API de administración de Cloud SQL o la CLI de gcloud , o seleccionar la opción de autoridad de certificación interna de Google en el... Google Cloud consola.
El siguiente diagrama muestra la jerarquía de CA por instancia.
CA compartidas alojadas por CA Service
La jerarquía de CA compartida es la configuración del modo de CA de servidor predeterminada cuando crea una instancia mediante Google Cloud consola.
Este modo de CA de servidor consta de una CA raíz y CA de servidor subordinadas en cada región. Las CA de servidor subordinadas emiten certificados de servidor y se comparten entre las instancias de la región. Cloud SQL gestiona la rotación de las CA de servidor regionales compartidas y proporciona enlaces públicos para descargar los paquetes de certificados de CA.
Puede configurar una instancia para que utilice una jerarquía de CA de servidor donde las CA emisoras se compartan entre las instancias de la misma región. Para usar esta configuración, configure serverCaMode en GOOGLE_MANAGED_CAS_CA al crear la instancia. También puede seleccionar la Autoridad de certificación CAS administrada por Google en el... Google Cloud consola.
El siguiente diagrama muestra la jerarquía de CA compartida.
CA gestionadas por el cliente
Este modo de CA de servidor le permite configurar su propia jerarquía de CA en CA Service.
Para usar la opción de CA administrada por el cliente en Cloud SQL, cree un grupo de CA en la misma región que sus instancias de Cloud SQL. A continuación, cree al menos una CA. Al crear la instancia de Cloud SQL, especifique el ID del grupo de CA en el campo serverCaPool y configure el campo serverCaMode con el valor CUSTOMER_MANAGED_CAS_CA . El servicio de CA proporciona una CA del grupo de CA y la utiliza para emitir el certificado de servidor para la instancia.
Al crear CA en CA Service, puede crear una CA raíz o una CA subordinada, según su caso práctico. Por ejemplo, podría querer crear una CA subordinada si planea configurar una jerarquía de CA raíz o conectarla con una CA externa.
Seleccione la opción de CA administrada por el cliente solo si desea administrar sus propias CA y certificados. Para obtener más información, consulte Usar una CA administrada por el cliente .
Cómo funciona la rotación de certificados de servidor
Cloud SQL ofrece formas de rotar el certificado de su servidor, de modo que el nuevo certificado se pueda cambiar sin problemas antes de que caduque el antiguo.
En el caso de las instancias que utilizan jerarquías de CA por instancia, CA compartida o CA administrada por el cliente, aproximadamente tres meses antes de que caduque el certificado de servidor de una instancia de Cloud SQL, los propietarios del proyecto reciben un correo electrónico de Cloud SQL que indica que el proceso de rotación de certificados ha comenzado para esa instancia. El correo electrónico proporciona el nombre de la instancia e indica que Cloud SQL ha añadido un nuevo certificado de servidor al proyecto. El certificado de servidor existente sigue funcionando con normalidad. De hecho, la instancia tiene dos certificados de servidor durante este período.
El comando de rotación de certificado de servidor a utilizar depende de si está usando un certificado de servidor emitido por una CA por instancia o un certificado de servidor emitido por una CA compartida o una CA administrada por el cliente.
Antes de que caduque el certificado del servidor actual, descargue el nuevo archivo server-ca.pem , que contiene la información del certificado actual y del nuevo. Actualice sus clientes PostgreSQL para que usen el nuevo archivo; para ello, copíelo en todos los hosts de sus clientes PostgreSQL y reemplace el archivo existente.
Una vez actualizados todos sus clientes de PostgreSQL, envíe un comando de rotación (para CA por instancia) o un comando de rotación (para CA compartida o CA administrada por el cliente) a la instancia de Cloud SQL para rotar al nuevo certificado de servidor. Una vez hecho esto, el certificado de servidor anterior ya no se reconoce y solo se puede usar el nuevo.
Los certificados de cliente no se ven afectados por la rotación de certificados del servidor.Caducidad del certificado SSL
Para las instancias de Cloud SQL que usan CA por instancia ( serverCaMode está configurado en GOOGLE_MANAGED_INTERNAL_CA ), los certificados SSL tienen un período de caducidad de 10 años. Antes de que caduquen, realice la rotación de certificados de la CA del servidor .
Para las instancias que utilizan CA compartidas ( serverCaMode está configurado como GOOGLE_MANAGED_CAS_CA ), el periodo de caducidad de los certificados de servidor es de 1 año. Antes de la fecha de caducidad, realice una rotación de certificados de servidor . El certificado de la autoridad de certificación (CA) raíz tiene un periodo de caducidad de 25 años y el certificado de la CA compartida subordinada tiene un periodo de caducidad de 10 años. Cloud SQL gestiona su rotación.
Si utiliza una CA administrada por el cliente ( serverCaMode está configurado como CUSTOMER_MANAGED_CAS_CA ), puede rotar los certificados de CA en el grupo de CA que creó. El período de vencimiento de una CA suele ser de 10 años, pero puede configurar un período de validez más corto en CA Service.
Para rotar las CA, utilice el proceso de rotación de CA en CA Service. Para obtener más información, consulte "Administración de la rotación de CA" .
Si un cliente está configurado para verificar la CA o el nombre de host en el certificado del servidor, las conexiones de ese cliente a instancias de Cloud SQL con certificados de servidor caducados fallarán. Para evitar interrupciones en las conexiones del cliente, rote el certificado del servidor antes de que caduque.
Ya sea que use el modo de servidor CA por instancia, CA compartida o CA administrado por el cliente, puede restablecer la configuración SSL de su instancia de Cloud SQL en cualquier momento.
¿Qué sigue?
Configure SSL/TLS en su instancia de Cloud SQL.
Obtenga más información sobre cómo se gestiona el cifrado en Google Cloud .
- Conéctese mediante SSL/TLS a su instancia de Cloud SQL.
- Administre SSL/TLS en su instancia de Cloud SQL.
- Obtenga más información sobre cómo PostgreSQL utiliza SSL/TLS .
Esta página describe cómo puede usar Secure Socket Layer (SSL), ahora Transport Layer Security (TLS), desde su aplicación para cifrar conexiones a instancias de Cloud SQL.
Descripción general
Cloud SQL admite la conexión a una instancia mediante el protocolo SSL/TLS. Las conexiones SSL/TLS proporcionan una capa de seguridad al cifrar los datos en tránsito entre el cliente y la base de datos de la instancia de Cloud SQL. Opcionalmente, la conexión SSL/TLS puede realizar la verificación de identidad del servidor mediante la validación del certificado de servidor instalado en la instancia de Cloud SQL, así como la verificación de identidad del cliente mediante la validación del certificado de cliente instalado en el cliente.
Certificados de servidor
Al crear una instancia, Cloud SQL crea e instala automáticamente un certificado de servidor firmado por una autoridad de certificación (CA). Puede descargar el certificado de la CA al equipo host del cliente y usarlo para verificar la identidad de la CA y del servidor de Cloud SQL. Opcionalmente, puede elegir el tipo de CA que Cloud SQL utiliza para firmar el certificado de servidor.
Certificados de cliente
Opcionalmente, puede crear y descargar certificados de cliente junto con las claves en el equipo host del cliente para la autenticación mutua (verificación de identidad del servidor y del cliente). No puede elegir el tipo de CA que Cloud SQL utiliza para firmar el certificado de cliente.
Conectarse mediante SSL/TLS
Al conectarse a una instancia de Cloud SQL desde los clientes, puede usar SSL/TLS para conexiones directas, así como para conexiones que usan Cloud SQL Auth Proxy o Cloud SQL Language Connectors .
Para conexiones directas, Google recomienda encarecidamente aplicar el cifrado SSL/TLS mediante la configuración del modo SSL en Cloud SQL. Opcionalmente, también puede aplicar la verificación del certificado del cliente. Para obtener más información, consulte Aplicar el cifrado SSL/TLS .
Para las conexiones que usan Cloud SQL Auth Proxy o Cloud SQL Language Connectors, las conexiones se cifran automáticamente con SSL/TLS junto con la verificación de identidad del cliente y del servidor sin necesidad de descargar un certificado de CA del servidor y un certificado del cliente.
Para obtener más información sobre las opciones de conectividad de Cloud SQL, consulte Acerca de las conexiones de Cloud SQL .
Para obtener más información sobre la configuración de SSL/TLS del lado del cliente, consulte la documentación de su motor de base de datos .Jerarquías de autoridades de certificación (CA)
En esta sección se describen los tres tipos de autoridad de certificación (CA) de servidor que puede elegir para sus instancias de Cloud SQL. Tiene tres opciones:
CA por instancia : con esta opción, una CA interna dedicada a cada instancia de Cloud SQL firma el certificado de servidor para esa instancia. Cloud SQL crea y administra estas CA. Para elegir una CA por instancia, seleccione la autoridad de certificación interna administrada por Google (Google Cloud consola) o especifique
GOOGLE_MANAGED_INTERNAL_CApara la configuraciónserverCaMode(API de administración de Cloud SQL) o el indicador--server-ca-mode( CLI de gcloud ) al crear la instancia . Si no especifica la configuración ni el indicador al crear una instancia, esta opción será el valor predeterminado.CA compartida : con esta opción, se utiliza una jerarquía de CA compuesta por una CA raíz y CA de servidor subordinadas. Las CA de servidor subordinadas de una región firman los certificados de servidor y se comparten entre las instancias de la región. Cloud SQL aloja y administra la CA raíz y las CA de servidor subordinadas en Google CloudServicio de Autoridad de Certificación (Servicio CA). Cloud SQL también gestiona la rotación de la CA raíz y las CA de servidor subordinadas, y proporciona enlaces públicos a los paquetes de certificados de la CA para su descarga. Para elegir una CA compartida, especifique
GOOGLE_MANAGED_CAS_CAen la configuraciónserverCaMode(API de administración de Cloud SQL) o el indicador--server-ca-mode( CLI de gcloud ) al crear la instancia .CA administrada por el cliente : con esta opción, puede crear y administrar su propia jerarquía de CA. Elija esta opción si desea administrar sus propias CA y certificados. Para elegir una CA administrada por el cliente, debe crear un grupo de CA y una CA en CA Service. En Cloud SQL, especifique el grupo de CA y
CUSTOMER_MANAGED_CAS_CApara la configuraciónserverCaMode(API de administración de Cloud SQL) o el indicador--server-ca-mode( CLI de gcloud ) al crear la instancia .
Después de crear una instancia, puede ver qué jerarquía de CA está configurada para una instancia de Cloud SQL mediante el comando gcloud sql instances describe o en el Google Cloud consola. Para obtener más información, consulte Ver información de la instancia .
La siguiente tabla compara las tres opciones de jerarquía de CA.
| Característica | CA por instancia | CA compartida | CA administrada por el cliente |
|---|---|---|---|
| Estructura de CA | CA independiente para cada instancia | CA raíz y CA subordinadas compartidas entre instancias en la misma región | Jerarquía de CA que usted crea y administra |
| Atributos criptográficos | Clave RSA de 2048 bits con algoritmo SHA256 | Algoritmo de firma digital de curva elíptica (ECDSA) con clave de 384 bits con algoritmo SHA384 | Algoritmo de firma digital de curva elíptica (ECDSA) con clave de 384 bits con algoritmo SHA384 |
| Período de validez de CA | 10 años | 25 años para la CA raíz y 10 años para las CA subordinadas | Configurable * |
| Período de validez del certificado del servidor | 10 años | 1 año | 1 año** |
| ¿Rotación de CA iniciada por el usuario? | Sí | No. La rotación de CA está gestionada por Cloud SQL | Sí |
| ¿Rotación de certificado de servidor iniciada por el usuario? | Sí | Sí | Sí |
| Ancla de confianza de CA para conexiones TLS | La CA única por instancia es el ancla de confianza para la instancia correspondiente. | La CA raíz y las CA subordinadas son los anclajes de confianza para todas las instancias en una región determinada. | Las CA que usted crea y administra son los anclajes de confianza. |
| Verificación de identidad del servidor | Al verificar la CA se verifica la identidad del servidor ya que cada instancia tiene una CA única. | La verificación del nombre de host junto con la verificación de la CA es necesaria para la verificación de la identidad del servidor, ya que las CA del servidor se comparten entre instancias. | Aunque es posible que la CA no se comparta entre instancias, es posible que desee verificar el nombre de host junto con la CA. |
| Campo de nombre alternativo del sujeto (SAN) en los certificados de servidor | El campo SAN contiene el nombre de host (nombre DNS de la instancia) solo para instancias habilitadas con Private Service Connect . El nombre de host se puede usar para la verificación de identidad del servidor. Si se conecta a una instancia de Cloud SQL usando el nombre DNS como nombre de host, debe configurar la resolución DNS. | El campo SAN contiene el nombre de host (nombre DNS de la instancia) para todos los tipos de instancia. El nombre de host se puede usar para la verificación de identidad del servidor. Si se conecta a una instancia de Cloud SQL usando el nombre DNS como nombre de host, debe configurar la resolución DNS. | El campo SAN contiene el nombre de host (nombre DNS de la instancia) para todos los tipos de instancia. El nombre de host puede usarse para la verificación de identidad del servidor. |
* Para la opción de CA administrada por el cliente, el periodo de validez predeterminado de un certificado de CA en CA Service es de 10 años. Puede configurar un periodo de validez diferente para sus certificados de CA. Un periodo de validez más corto para la CA podría requerir rotaciones más frecuentes, y un periodo de validez inferior a un año podría afectar el periodo de validez de sus certificados de servidor. Para obtener más información, consulte "Administrar la rotación de CA" .
** Para la opción de CA administrada por el cliente, el periodo de validez predeterminado de un certificado de servidor es de un año. Sin embargo, si configura un periodo de validez inferior a un año para su certificado de CA, el periodo de validez de su certificado de servidor será menor. Para obtener más información sobre cómo configurar el periodo de validez de su certificado de CA al crearlo, consulte Configuración del certificado de CA y Crear una CA raíz .
CA por instancia alojada por Cloud SQL
La jerarquía de CA por instancia es la configuración del modo de CA del servidor predeterminada cuando crea una instancia utilizando la CLI de gcloud , la API de administración de Cloud SQL o Terraform.
Cloud SQL crea una nueva CA de servidor autofirmada para cada instancia al crearla. Para usar esta configuración, configure serverCaMode en GOOGLE_MANAGED_INTERNAL_CA al crear la instancia. Puede dejar la configuración serverCaMode sin especificar mediante la API de administración de Cloud SQL o la CLI de gcloud , o seleccionar la opción de autoridad de certificación interna de Google en el... Google Cloud consola.
El siguiente diagrama muestra la jerarquía de CA por instancia.
CA compartidas alojadas por CA Service
La jerarquía de CA compartida es la configuración del modo de CA de servidor predeterminada cuando crea una instancia mediante Google Cloud consola.
Este modo de CA de servidor consta de una CA raíz y CA de servidor subordinadas en cada región. Las CA de servidor subordinadas emiten certificados de servidor y se comparten entre las instancias de la región. Cloud SQL gestiona la rotación de las CA de servidor regionales compartidas y proporciona enlaces públicos para descargar los paquetes de certificados de CA.
Puede configurar una instancia para que utilice una jerarquía de CA de servidor donde las CA emisoras se compartan entre las instancias de la misma región. Para usar esta configuración, configure serverCaMode en GOOGLE_MANAGED_CAS_CA al crear la instancia. También puede seleccionar la Autoridad de certificación CAS administrada por Google en el... Google Cloud consola.
El siguiente diagrama muestra la jerarquía de CA compartida.
CA gestionadas por el cliente
Este modo de CA de servidor le permite configurar su propia jerarquía de CA en CA Service.
Para usar la opción de CA administrada por el cliente en Cloud SQL, cree un grupo de CA en la misma región que sus instancias de Cloud SQL. A continuación, cree al menos una CA. Al crear la instancia de Cloud SQL, especifique el ID del grupo de CA en el campo serverCaPool y configure el campo serverCaMode con el valor CUSTOMER_MANAGED_CAS_CA . El servicio de CA proporciona una CA del grupo de CA y la utiliza para emitir el certificado de servidor para la instancia.
Al crear CA en CA Service, puede crear una CA raíz o una CA subordinada, según su caso práctico. Por ejemplo, podría querer crear una CA subordinada si planea configurar una jerarquía de CA raíz o conectarla con una CA externa.
Seleccione la opción de CA administrada por el cliente solo si desea administrar sus propias CA y certificados. Para obtener más información, consulte Usar una CA administrada por el cliente .
Cómo funciona la rotación de certificados de servidor
Cloud SQL ofrece formas de rotar el certificado de su servidor, de modo que el nuevo certificado se pueda cambiar sin problemas antes de que caduque el antiguo.
En el caso de las instancias que utilizan jerarquías de CA por instancia, CA compartida o CA administrada por el cliente, aproximadamente tres meses antes de que caduque el certificado de servidor de una instancia de Cloud SQL, los propietarios del proyecto reciben un correo electrónico de Cloud SQL que indica que el proceso de rotación de certificados ha comenzado para esa instancia. El correo electrónico proporciona el nombre de la instancia e indica que Cloud SQL ha añadido un nuevo certificado de servidor al proyecto. El certificado de servidor existente sigue funcionando con normalidad. De hecho, la instancia tiene dos certificados de servidor durante este período.
El comando de rotación de certificado de servidor a utilizar depende de si está usando un certificado de servidor emitido por una CA por instancia o un certificado de servidor emitido por una CA compartida o una CA administrada por el cliente.
Antes de que caduque el certificado del servidor actual, descargue el nuevo archivo server-ca.pem , que contiene la información del certificado actual y del nuevo. Actualice sus clientes PostgreSQL para que usen el nuevo archivo; para ello, copíelo en todos los hosts de sus clientes PostgreSQL y reemplace el archivo existente.
Una vez actualizados todos sus clientes de PostgreSQL, envíe un comando de rotación (para CA por instancia) o un comando de rotación (para CA compartida o CA administrada por el cliente) a la instancia de Cloud SQL para rotar al nuevo certificado de servidor. Una vez hecho esto, el certificado de servidor anterior ya no se reconoce y solo se puede usar el nuevo.
Los certificados de cliente no se ven afectados por la rotación de certificados del servidor.Caducidad del certificado SSL
Para las instancias de Cloud SQL que usan CA por instancia ( serverCaMode está configurado en GOOGLE_MANAGED_INTERNAL_CA ), los certificados SSL tienen un período de caducidad de 10 años. Antes de que caduquen, realice la rotación de certificados de la CA del servidor .
Para las instancias que utilizan CA compartidas ( serverCaMode está configurado como GOOGLE_MANAGED_CAS_CA ), el periodo de caducidad de los certificados de servidor es de 1 año. Antes de la fecha de caducidad, realice una rotación de certificados de servidor . El certificado de la autoridad de certificación (CA) raíz tiene un periodo de caducidad de 25 años y el certificado de la CA compartida subordinada tiene un periodo de caducidad de 10 años. Cloud SQL gestiona su rotación.
Si utiliza una CA administrada por el cliente ( serverCaMode está configurado como CUSTOMER_MANAGED_CAS_CA ), puede rotar los certificados de CA en el grupo de CA que creó. El período de vencimiento de una CA suele ser de 10 años, pero puede configurar un período de validez más corto en CA Service.
Para rotar las CA, utilice el proceso de rotación de CA en CA Service. Para obtener más información, consulte "Administración de la rotación de CA" .
Si un cliente está configurado para verificar la CA o el nombre de host en el certificado del servidor, las conexiones de ese cliente a instancias de Cloud SQL con certificados de servidor caducados fallarán. Para evitar interrupciones en las conexiones del cliente, rote el certificado del servidor antes de que caduque.
Ya sea que use el modo de servidor CA por instancia, CA compartida o CA administrado por el cliente, puede restablecer la configuración SSL de su instancia de Cloud SQL en cualquier momento.
¿Qué sigue?
Configure SSL/TLS en su instancia de Cloud SQL.
Obtenga más información sobre cómo se gestiona el cifrado en Google Cloud .
- Conéctese mediante SSL/TLS a su instancia de Cloud SQL.
- Administre SSL/TLS en su instancia de Cloud SQL.
- Obtenga más información sobre cómo PostgreSQL utiliza SSL/TLS .