Le è mai capitato quel momento da batticuore in cui si accorge di aver cancellato per errore dati importanti dal database o di aver eseguito un drop in produzione invece che in ambiente di sviluppo? E, a peggiorare l'incubo, scopre che i backup non erano attivi? È uno scenario fin troppo familiare per molti di noi: in DoiT riceviamo ticket con storie di questo tipo praticamente ogni settimana. In questo articolo le spieghiamo come evitare che si ripeta.
Partiamo dalle Organization Policy.
Le Organization Policy
Come suggerisce il nome, le Organization Policy sono strumenti che aiutano gli amministratori a gestire e controllare il comportamento delle risorse all'interno dell'organizzazione e dei progetti GCP. Si tratta di regole impostate a livello di organizzazione, cartella o progetto che definiscono quali azioni si possono o non si possono eseguire sulle risorse a quei livelli. Servono ad applicare linee guida di sicurezza, conformità e operatività e, nel nostro caso specifico, possono essere usate per rendere obbligatori i backup di CloudSQL.
Come si fa? Purtroppo la documentazione e le guide ufficiali di GCP non sono molto d'aiuto: gli esempi non funzionano oppure risultano poco chiari a chi non conosce già il Common Expression Language. Ho scoperto questa soluzione per caso, aiutando un cliente a risolvere proprio questo problema. Vediamola insieme. Useremo i Custom Constraint per bloccare la creazione o la modifica di qualsiasi database CloudSQL privo di point-in-time recovery (PITR) abilitato. Il PITR è una tecnica di recupero che consente di ripristinare il database a un istante preciso, di solito antecedente a un evento di perdita o corruzione dei dati.
Procedura passo passo
Passo 1: creare il Custom Constraint
Il primo obiettivo è creare un constraint che neghi qualsiasi tentativo di avviare o modificare un database CloudSQL senza PITR abilitato. Attenzione: se prova a modificare un database CloudSQL esistente senza PITR, la modifica verrà bloccata a meno che non abiliti contemporaneamente il PITR.
- Acceda alla console delle Organization Policy
Vada alla Google Cloud Console e selezioni la sua organizzazione.
2. Crei un Custom Constraint
- Faccia clic su CUSTOM CONSTRAINT
- Indichi un nome e una descrizione per il constraint: le saranno utili per identificarlo e capirne lo scopo in futuro.
- In Enforcement Type, selezioni `sqladmin.googleapis.com/instance`.
- Scelga di applicare il constraint sulle azioni Create e Update.
- Faccia clic sull'icona della matita accanto a [define condition] per inserire la condizione.
3. Definisca la condizione
- Inserisca questa condizione per imporre i backup PITR:
resource.settings.backupConfiguration.pointInTimeRecoveryEnabled == false
- Imposti l'Action su `deny`.
Passo 2: applicare il constraint
Una volta creato il custom constraint, il passo successivo è applicarlo all'interno della sua organizzazione:
1. Apra il constraint:
Se non è già nella schermata giusta, torni al constraint appena creato nella console delle Organization Policy.
2. Gestisca la policy:
- Faccia clic su MANAGE POLICY in alto nella pagina del constraint.
- Selezioni Override parent's policy se esiste già una policy.
- Imposti la regola di applicazione su On.
- Il risultato dovrebbe essere questo:
Se vuole applicare il requisito PITR solo ad alcuni database Cloud SQL, può sfruttare le Condition per filtrare le risorse coinvolte.
- Faccia clic su ADD CONDITION.
- Inserisca i criteri di filtro, ad esempio il Tag, e scelga il Value path richiesto:
Per non causare problemi alle risorse esistenti (vedi sopra: i database CloudSQL già attivi non si possono modificare senza prima abilitare il PITR), le consigliamo di testare la policy:
- Faccia clic su Test Policy e attenda che la validazione si concluda.
- Apra la pagina SIMULATION HISTORY per verificare che il risultato corrisponda alle sue aspettative.
- Se l'esito la convince, torni al custom constraint e selezioni MANAGE POLICY.
- Se le modifiche non risultano applicate, imposti di nuovo la policy come illustrato sopra. Faccia clic su SET POLICY e confermi gli eventuali avvisi.
Passo 3: verificare l'applicazione della policy
Testare e verificare che la policy funzioni come previsto è fondamentale. Ecco come procedere:
- Testi la policy:
I tentativi di creare o aggiornare un'istanza Cloud SQL senza abilitare il point-in-time recovery dovrebbero essere bloccati dall'Organization Policy.
- Esegua questo comando:
gcloud sql instances create test-instance --region=us-central1 --no-backup
- Dovrebbe ricevere un errore che segnala l'obbligo di abilitare il point-in-time recovery.
2. Crei un'istanza Cloud SQL conforme:
Ora crei un'istanza Cloud SQL con il point-in-time recovery abilitato, in modo che sia conforme alla policy.
- Esegua questo comando:
gcloud sql instances create compliant-instance — region=us-central1 — backup-start-time=23:00 — enable-point-in-time-recovery
Questa volta l'operazione dovrebbe andare a buon fine.
Seguendo questi passaggi ha creato e attivato un custom constraint nelle policy della sua organizzazione che garantisce il backup point-in-time recovery su tutte le istanze Cloud SQL. Una scelta in linea con le best practice di protezione dei dati, che assicura la conformità di tutte le risorse cloud aziendali. E le risparmia un grattacapo enorme quando qualcuno, di nuovo, cancellerà dati critici.
Niente panico!
Se ha perso dei dati, non è il solo. DoiT International è qui per aiutarla a recuperarli e a impostare l'enforcement dei backup di Cloud SQL così da evitare che il problema si ripresenti. Con oltre 180 senior cloud expert specializzati nella progettazione di soluzioni cloud su misura, il nostro team è pronto ad accompagnarla nel processo e a ottimizzare la sua infrastruttura per garantire la conformità e rispondere con efficienza alle esigenze future.
Ci contatti oggi stesso per affidare la gestione delle sue policy di backup Cloud SQL a professionisti, senza intoppi. Siamo qui per aiutarla a prendere decisioni consapevoli e a implementare le soluzioni più adatte alle sue esigenze. E non solo per Cloud SQL: possiamo passare in rassegna tutte le sue policy su AWS, GCP e Azure per garantire conformità e sicurezza a 360 gradi.
I nostri esperti sono pronti a offrirle guida strategica e competenza tecnica in ogni fase del percorso. Valutiamo insieme la strategia più adatta alla sua azienda in questa fase di policy enforcement, per assicurare un'infrastruttura cloud solida, conforme e pronta a sostenere la crescita.