Cómo forzar los backups en Google CloudSQL

Como su nombre lo indica, las Organizational Policies son herramientas que ayudan a los administradores a gestionar y controlar el comportamiento de los recursos dentro de su organización y proyectos en GCP. Son reglas definidas a nivel de organización, carpeta o proyecto que determinan qué acciones se pueden o no realizar sobre los recursos en esos niveles. Estas políticas permiten aplicar lineamientos de seguridad, compliance y operación. Y, específicamente para nuestro caso, ¡sirven para forzar los backups de CloudSQL!

¿Cómo se hace? Lamentablemente, la documentación y las guías de GCP no son demasiado útiles, y los ejemplos o no funcionan o no quedan claros a menos que ya conozcas Common Expression Language. Lo descubrí de casualidad ayudando a un cliente a resolver este problema. Vamos paso a paso. Vamos a usar Custom Constraints para bloquear la creación o modificación de cualquier base de datos CloudSQL que no tenga habilitado point-in-time recovery (PITR). PITR es una técnica de recuperación de bases de datos que te permite restaurar una base de datos a un punto específico en el tiempo, normalmente antes de que ocurra una pérdida o corrupción de datos.

Paso 1: Crear la Custom Constraint

La primera tarea es crear una constraint que deniegue cualquier intento de lanzar o modificar una base de datos CloudSQL sin PITR habilitado. Ten en cuenta que, si intentas modificar una base de datos CloudSQL existente que no tenga PITR habilitado, esa modificación se bloqueará a menos que también habilites PITR:

1. Ir a la consola de Organizational Policies

Entra a la Google Cloud Console y selecciona tu organización.

2. Crear una Custom Constraint

• Haz clic en CUSTOM CONSTRAINT

• Asígnale un nombre y una descripción a tu constraint. Esto facilita identificarla y entenderla más adelante.
• En Enforcement Type, selecciona `sqladmin.googleapis.com/instance`.
• Elige aplicar la constraint en las acciones Create y Update.
• Haz clic en el ícono del lápiz junto a [define condition] para ingresar la condición.

3. Definir la condición

• Ingresa la siguiente condición para forzar los backups con PITR:

resource.settings.backupConfiguration.pointInTimeRecoveryEnabled == false

• Configura la Action en `deny`.

Paso 2: Aplicar la constraint

Una vez creada la custom constraint, el siguiente paso es aplicarla dentro de tu organización:

1. Abrir la constraint:

Si aún no estás ahí, ve a la constraint que creaste en la consola de Organizational Policies.

2. Manage Policy:

• Haz clic en MANAGE POLICY en la parte superior de la página de la constraint.

• Selecciona Override parent's policy si ya existe una política.
• Activa la regla en On.
• Debería verse así:

Si solo quieres que algunas de tus bases de datos Cloud SQL tengan el requisito de PITR, puedes usar Conditions para filtrar qué recursos entran en el alcance.

• Haz clic en ADD CONDITION.
• Ingresa tus criterios de filtro, como el Tag, y elige el Value path que necesites:

Para no causar problemas con recursos existentes (recuerda lo dicho antes sobre la imposibilidad de modificar bases de datos CloudSQL existentes sin habilitar PITR), te recomiendo probar primero la política:

• Haz clic en Test Policy y espera a que termine la validación.
• Ve a la página SIMULATION HISTORY para verificar que el resultado coincida con lo esperado.

• Si todo está bien, regresa a la custom constraint y selecciona MANAGE POLICY.
• Si los cambios no se aplicaron, configura la política como antes (ver arriba). Haz clic en SET POLICY y acepta las advertencias que aparezcan.

Paso 3: Verificar la aplicación de la política

Probar y verificar que la política funciona como debe es fundamental. Sigue estos pasos para confirmarlo:

1. Probar la política:

Cualquier intento de crear o actualizar una instancia de Cloud SQL sin habilitar point-in-time recovery debería ser denegado por la Organizational Policy.

• Ejecuta el siguiente comando:

gcloud sql instances create test-instance --region=us-central1 --no-backup

• Deberías recibir un error indicando que point-in-time recovery debe estar habilitado.

2. Crear una instancia de Cloud SQL que cumpla con la política:

Ahora crea una instancia de Cloud SQL con point-in-time recovery habilitado para confirmar que cumple con la política.

• Ejecuta el siguiente comando:

gcloud sql instances create compliant-instance — region=us-central1 — backup-start-time=23:00 — enable-point-in-time-recovery

Esta acción debería permitirse.

Con estos pasos ya creaste y aplicaste una custom constraint en las políticas de tu organización para garantizar que todas las instancias de Cloud SQL tengan backups con point-in-time recovery. Esto no solo se alinea con las mejores prácticas de protección de datos, sino que además asegura el compliance en todos los recursos cloud de tu organización. Y te ahorra un enorme dolor de cabeza cuando alguien vuelva a borrar datos críticos. Otra vez.

Si perdiste datos, no eres el único. En DoiT International estamos para ayudarte a recuperarlos y a aplicar políticas de backup en Cloud SQL para que no vuelva a pasar. Con más de 180 expertos cloud senior especializados en diseñar soluciones cloud a medida, nuestro equipo está listo para acompañarte en este proceso y optimizar tu infraestructura, asegurando el compliance y respondiendo de forma eficiente a las necesidades futuras.

Contáctanos hoy mismo para gestionar tus políticas de backup en Cloud SQL de manera profesional y sin fricción. Estamos para ayudarte a tomar decisiones informadas e implementar las mejores soluciones según tus necesidades específicas. Más allá de Cloud SQL, podemos revisar todas tus políticas en AWS, GCP y Azure para garantizar un compliance y una seguridad integrales.

Nuestros expertos están listos para brindarte orientación estratégica y experiencia técnica en cada paso del camino. Conversemos sobre lo que tiene más sentido para tu empresa en esta fase de aplicación de políticas, para que tu infraestructura cloud sea robusta, conforme y esté optimizada para el éxito.