Esistono procedure consigliate durante la configurazione di TDE in SQL Server 2008? Su SQLMag, l'articolo "Domande frequenti sulla crittografia dei dati trasparenti" afferma che la CPU potrebbe avere un aumento dell'utilizzo fino al 30%?
Oltre all'aggiunta della potenza del server, c'è qualcos'altro che i DBA in genere fanno quando si accende TDE?
Risposte:
Alcuni punti aggiuntivi che ho notato è che nel caso in cui si stia utilizzando la funzione di compressione del backup, questa funzione insieme a TDE non va così bene. Abbiamo notato un tasso di compressione molto minimo, quasi trascurabile. Pertanto, considerare questo punto di compressione del backup se ne si utilizza uno.
Sono sicuro che lo sapresti, ma solo per aggiungere, TDE è disponibile per l'edizione Enterprise, quindi considera questo anche durante l'impostazione di SQL Server per TDE.
TDE non fornisce lo stesso controllo granulare, specifico per un ruolo utente o database, come viene offerto dalla crittografia a livello di cella.
Assicurarsi che le chiavi di crittografia siano archiviate in modo sicuro in un luogo sicuro a cui è possibile accedere in caso di scenario di ripristino. Acquisire familiarità con il ripristino di un database che è stato crittografato su un nuovo server. (originariamente un commento di Jonathan Fite ).
Innanzitutto, prima di crittografare un database, eseguire un backup della chiave principale e del certificato e archiviarlo offline. Non aspettare fino a dopo aver applicato TDE per farlo. Conservare anche le password in un deposito password e chiarire quali password sono correlate a quale oggetto; non vuoi davvero perdere traccia di questi.
L'impatto che TDE ha sul database dipende interamente dal carico di lavoro coinvolto: di recente ho applicato TDE a un data warehouse e l'impatto sulle prestazioni sul carico notturno non è stato nulla, il che suggerisce che il processo non era associato alla CPU. Tuttavia, ciò potrebbe non essere vero per il tuo database. Quindi, se è possibile testare prima il carico di lavoro in un ambiente di sviluppo, quindi farlo.
Non sono solo i dati nei file che sono crittografati: TDE crittograferà anche tempDB, quindi se si dispone di altri database che utilizzano pesantemente TempDB, è possibile che si verifichi un calo delle prestazioni. Anche i backup e le istantanee sono anche crittografati.
Considera anche se questo database deve essere ripristinato in altri ambienti (ad esempio test o UAT). Sarà necessario ripristinare il certificato utilizzato per crittografare il database su questi altri server. Questo potrebbe non sembrare un problema eccessivo, ma se non si dispone di aziende o sviluppatori in nessuno di questi ambienti, ciò può diventare costoso. Un'alternativa all'applicazione di TDE in tutto l'ambiente è ripristinare il database in un'istanza intermedia tra impresa / sviluppatore e o mescolare i dati sensibili, oppure eliminare la crittografia e creare un nuovo backup da ripristinare in altri ambienti. Questa seconda scelta non è probabilmente la più sensata, ma è sempre un'opzione ...
Quando si attiva TDE, esistono due blocchi applicati al database: un blocco condiviso e un blocco degli aggiornamenti. TechNet lo afferma pienamente:
Quando TDE è abilitato (o disabilitato), il database è contrassegnato come crittografato nella vista del catalogo sys.d Database e lo stato DEK è impostato su Crittografia in corso. Il server avvia un thread in background (chiamato scan o scan di crittografia) che esegue la scansione di tutti i file di database e li crittografa (o li decodifica se si disabilita TDE). Durante l'esecuzione del DDL, viene eseguito un blocco degli aggiornamenti nel database. La scansione della crittografia, che viene eseguita in modo asincrono sul DDL, accetta un blocco condiviso. Tutte le normali operazioni che non sono in conflitto con questi blocchi possono procedere. Le operazioni escluse includono la modifica della struttura del file e il distacco del database. Mentre le normali scritture di database su disco dal pool buffer sono crittografate, le scritture dei file di registro potrebbero non esserlo. La scansione impone inoltre un rollover per il file di registro virtuale (VLF) per garantire che le scritture future nel registro siano crittografate.
La mia esperienza è stata in data warehouse che sono stati a malapena utilizzati durante il giorno e pesantemente utilizzati durante la notte, quindi sono stato in grado di applicare TDE con interruzioni minime durante il giorno. Se si sta crittografando un OLTP in produzione, è consigliabile pianificarlo durante una finestra di manutenzione per ridurre al minimo i problemi.
Modifica: anche sul punto di compressione; mentre è vero che TDE influenza la compressione del backup, non influisce sulla compressione riga / pagina / columnstore. Quindi, se si desidera bilanciare la perdita di compressione dai backup, è possibile comprimere gli oggetti nel database. Ancora una volta, a seconda del carico di lavoro, potresti non voler implementare la compressione sul tuo database perché stresserà ulteriormente la CPU. Esiste un eccellente articolo TechNet sull'implementazione della compressione: https://technet.microsoft.com/en-us/library/dd894051%28v=sql.100%29.aspx