Come impostare un backup customizzato su SQL Azure Managed Instance

Configurare Long Term Retention (LTR) in una Managed Instance

In questo articolo andremo ad affrontare come configurare su una Managed Instance la Long Term Retention, non nativamente prevista sulla piattaforma Azure ma molto richiesta dai clienti.

Queste indicazioni possono essere utili in diverse realtà aziendali: del settore bancario, a quello sanitario e tutte quelle che hanno la necessità di conservare i dati del backup per un tempo maggiore dei 35 giorni, previste dalle attuali politiche di retention esistenti.

Può, altre sì, essere utile per agevolare la migrazione da ambienti “classici” on premise che osservano regole di conservazione rigide al mondo cloud senza che ci sia assoluta differenza tra i due ecosistemi.

La prima cosa che andremo a modificare lato managed instance è la gestione del TDE (Transparent Data Encryption), ovvero la crittografia dei file dei databases, backups e logs.

Esistono due tipi di TDE: la service-managed key gestita AS IS da Azure, che automaticamente gestisce l’encrypt e la rotation e la customer-managed key gestita dall’utente, che è responsabile del ciclo di vita della Key.

Configurare una customer-managed key

Per implementare LTR customizzata è necessario configurare una customer-managed key

Possiamo ipotizzare di scegliere una key all’interno del tenant oppure scegliere una key tramite il suo identifier, questo nel caso in cui per questioni di sicurezza non abbiamo accesso alla key.

Andiamo a creare la nostra Key:

I requisiti per la key sono I seguenti:

• Deve essere asimmetrica di tipo RSA 2048 o RSA HSR 2048
• Deve essere in enable state
• In caso di import può essere nei seguenti formati: .pfx, .yok o .backup
• Prima di usarla è consigliato fare un backup della key

Dopo aver creato la Key, ci spostiamo nel blade “Access Policies” e dare i seguenti accessi sulla Managed Instance:

GET: Serve per recuperare la parte pubblica e proprietà della Key per poi unirla nell’insieme delle credenziali della chiave

WRAP: Serve per crittografare

UNWRAP: server per decrittografare.

Possiamo infine tornare nelle impostazioni della Managed Instance e applicare la key appena creata:

A questo punto dobbiamo tenere a mente queste best practices:

• Flaggare “Make the selected Key the default TDE Protector” questo perché se creiamo nuovi database sotto la Managed Instance non ci dobbiamo ricordare ogni volta di scegliere la Key
• Il cambio di Key non cambierà automaticamente i backup fatti fino ad ora, quindi se passiamo dalla customer-key alla service-key ricordarsi di conservare, in base al ciclo dei backup dei database (da 7 a 35 giorni) la chiave altrimenti sarà impossibile fare un restore.

Ora non ci resta che creare un JOB di Backup da SQL Server Management Studio, come nell’esempio cui sotto:

DECLARE @SQLStatement VARCHAR(2000) SET @SQLStatement = ‘https://mistorageaccount2.blob.core.windows.net/nebulami/testmi_’ + CONVERT(nvarchar(30), GETDATE(),  120) +’.bak’ BACKUP DATABASE [testmi] TO  URL = @SQLStatement WITH COPY_ONLY

Il Job deve essere eseguito, ed è mandatory, con il parametro “COPY_ONLY” questo perché come detto all’inizio i backup nativi della piattaforma non si possono disattivare, quindi il copy_only è necessario per non interrompere la catena dei backup.

In conclusione, possiamo dire che questa breve guida potrà garantire al cliente che ha applicazioni vincolate a normative quali GDPR o di conformità, gli strumenti per potersi mettere in linea e garantire ai propri clienti e fornitori una struttura e il dato stesso fruibile per lungo tempo.

Fonti e approfondimenti:

Microsoft Azure – Transparent Data Encryption (TDE) with customer managed keys for Managed Instance

Microsoft Azure – Azure SQL Transparent Data Encryption with customer-managed key

Microsoft Azure – What is Azure SQL Database managed instance?