En esta página, se describe cómo Cloud SQL usa certificados de capa de conexión segura (SSL)/capa de transporte (TLS) autoadministrados para conectarse de forma segura a las instancias de Cloud SQL.
Descripción general
Cloud SQL admite la conexión a una instancia mediante el protocolo de seguridad de la capa de transporte (SSL/TLS). Por lo general, se autentican los datos en tránsito dentro de un límite físico controlado por Google o en su nombre, pero puede que no se encripten según la configuración predeterminada. Si te conectas a una instancia mediante su dirección IP pública, debes aplicar certificados SSL/TLS para que los datos estén protegidos durante la transmisión. SSL/TLS es el protocolo estándar para la encriptación de datos que se envían a través de Internet. Si los datos no están encriptados, cualquier persona puede examinar los paquetes y leer información confidencial.
El método de encriptación más seguro se llama criptografía asimétrica. Este método requiere dos claves criptográficas, una pública y una privada. En principio, se usa la clave pública a fin de encriptar los datos y la clave privada para desencriptarlos. El servidor y las máquinas cliente tienen el mismo conjunto de claves de cliente.
En Cloud SQL, la clave pública se llama client-cert.pem y la clave privada se llama client-key.pem. El servidor también genera su propio certificado, llamado server-ca.pem.
Se requieren las tres claves para que tu aplicación pueda conectarse de forma correcta.
Almacena estas claves de manera segura, ya que cualquier persona con acceso a ellas puede conectar o interceptar los datos. No puedes recuperar la clave privada del servidor más adelante, por lo que, si la pierdes, debes crear nuevos certificados de cliente para reemplazar los que estaban en uso. Del mismo modo, cuando el servidor genera un archivo server-ca.pem nuevo, debes descargarlo y almacenarlo en la máquina anfitrión del cliente PostgreSQL, de modo que se reemplace el archivo existente.
Certificados SSL/TLS
En las conexiones SSL, es obligatorio contar con un certificado de autoridad certificada (CA) de servidor. Cloud SQL crea un certificado de servidor de forma automática cuando se crea la instancia. Siempre que el certificado de servidor sea válido, no es necesario que lo administres de forma activa. Sin embargo, el certificado tiene una fecha de vencimiento de 10 años. Después de esa fecha, deja de ser válido, y los clientes no pueden establecer una conexión segura con la instancia mediante él. También puedes crear un certificado nuevo de forma manual.
Puedes crear tus propios certificados de cliente. Existe un límite de 10 certificados de cliente por instancia de Cloud SQL.Cómo funciona la rotación del certificado de servidor
Cloud SQL proporciona una forma de rotar el certificado de servidor para que un certificado nuevo se pueda intercambiar sin problemas antes del vencimiento del certificado anterior.
Alrededor de tres meses antes de que el certificado de servidor de una instancia de Cloud SQL se venza, los propietarios del proyecto reciben un correo electrónico de Cloud SQL en el que se indica que comenzó el proceso de rotación de certificados en esa instancia. En el correo electrónico, se proporciona el nombre de la instancia y se indica que Cloud SQL agregó un nuevo certificado de servidor al proyecto. El certificado de servidor existente seguirá funcionando con normalidad. De hecho, la instancia tiene dos certificados de servidor durante este período.
Antes de que venza el certificado actual, descarga el archivo server-ca.pem nuevo, que contiene la información del certificado de servidor actual y del nuevo. Actualiza tus clientes PostgreSQL a fin de que usen el archivo nuevo. Para ello, copia el archivo en todas tus máquinas anfitrión de clientes PostgreSQL y reemplaza el archivo existente.
Después de actualizar todos los clientes PostgreSQL, envía un comando a la instancia de Cloud SQL para rotar al nuevo certificado de servidor. Una vez hecho esto, ya no se reconoce el certificado de servidor anterior y solo se puede usar el nuevo.
Los certificados de cliente no se ven afectados por la rotación de certificados de servidor.Aplica la encriptación SSL/TLS
Cuando configuras la instancia de Cloud SQL para que acepte conexiones SSL/TLS, se habilitan las conexiones SSL/TLS en ella, pero se siguen aceptando conexiones inseguras y no encriptadas. Si no necesitas SSL/TLS para todas las conexiones, se permiten las conexiones sin encriptar. Por este motivo, si accedes a la instancia mediante una IP pública, se recomienda que apliques certificados SSL para todas las conexiones.Usa redes autorizadas
Si la instancia de Cloud SQL usa una dirección IP pública, debes agregar las direcciones IP de los clientes PostgreSQL como redes autorizadas cuando configuras SSL/TLS.
En este caso, los clientes PostgreSQL solo están autorizados para conectarse si sus direcciones IP están agregadas a esta lista. Las direcciones IP pueden limitarse a un solo extremo o consistir en un rango en formato CIDR. Por ejemplo, 10.50.51.3 o 10.50.51.0/26.
Vencimiento del certificado SSL
Los certificados SSL asociados con instancias de Cloud SQL tienen un período de vencimiento de 10 años. Cuando se vence un certificado, debes realizar la rotación de certificados de SSL. También puedes restablecer la configuración de SSL de la instancia de Cloud SQL en cualquier momento.
Próximos pasos
Configura SSL/TLS en la instancia de Cloud SQL.
Obtén más información sobre cómo se maneja la encriptación en Google Cloud.
- Conéctate mediante SSL/TLS a la instancia de Cloud SQL.
- Administra SSL/TLS en la instancia de Cloud SQL.
Obtén más información sobre cómo PostgreSQL usa SSL/TLS.