SQL Server 2008 - Transparent Data Encryption accesso undecrypted

Question

La mia domanda è un duplicato di - Oracle Transparent Data Encryption undecrypted accesso -. ma per SQL Server 2008

---

Posso impostare un SQL Server 2008 di database in modo che tutte le seguenti affermazioni sono vere?

a) certe colonne, potenzialmente tutte le colonne sono criptati, in modo che l'accesso ai file diretto al file di database non consente a un utente malintenzionato di recuperare tutti i record

b) le colonne crittografate trasparente decifrati per utente autorizzato, dove autorizzazione accade ad esempio avendo un certo ruolo o un privilegio

c) un amministratore con privilegi suiteable per fare i compiti di amministrazione 'normali' (messa a punto, la creazione / droping oggetti dello schema, il riavvio del database, selezionando dal dizionario dei dati) può selezionare le tabelle, ma vedrà dati solo cifrati nelle colonne criptati.

Se questo è possibile, come si fa lo faccio. Se non è possibile, quali sono le opzioni che ho per ottenere almeno 'vicino' a questi requisiti?

So che a) è possibile, ma io non sono sicuro di b) ec).

Grazie.

Answer 1

No, perché non è possibile eseguire Transparent Data Encryption su colonne selezionate solo:

  

la crittografia dei dati trasparente (TDE)   esegue in tempo reale di I / O e la crittografia   decrittazione dei file di dati e di log.   La crittografia utilizza un database   chiave di crittografia (DEK), che è memorizzato   nel record di avvio del database per   disponibilità durante il recupero. il DEK   è una chiave simmetrica protetto mediante un   certificato memorizzato nel master   banca dati del server o di un   chiave asimmetrica protetta da un EKM   modulo. TDE protegge i dati "a riposo",   cioè i file di dati e di log. esso   fornisce la capacità di rispettare   molte leggi, regolamenti e linee guida   stabilito in varie industrie.   Questo consente agli sviluppatori di software per   crittografare i dati utilizzando AES e 3DES   algoritmi di crittografia senza cambiare   le applicazioni esistenti.    Rif .

Qui ci sono alcune cose che dovreste considerare circa TDE (per gentile concessione di blog di Brad McGehee):

• TDE non fa i dati Protect nella memoria, in modo dati sensibili può essere visto da chiunque abbia diritti DBO a un database, o diritti SA per l'istanza di SQL Server. In altre parole, TDE non può impedire agli amministratori di database di visualizzare tutti i dati che vogliono vedere.

• TDE non è granulare. Poi tutto il database in criptato.

• TDE non le comunicazioni protette tra le applicazioni client e SQL Server, in modo che altri metodi di crittografia devono essere utilizzati per i dati protette che scorre attraverso la rete.

• I dati FILESTREAM non è crittografato.

• Quando uno qualsiasi database su un'istanza di SQL Server è TDE acceso, quindi il database tempdb viene automaticamente crittografati, che possono contribuire a scarso rendimento per entrambi i database crittografati e non crittografati in esecuzione sulla stessa istanza.

• Anche se meno risorse sono tenuti ad attuare TDE rispetto alla crittografia a livello di colonna, che incorre ancora un po 'in testa, che può impedire che venga utilizzato su SQL Server in cui si verificano colli di bottiglia della CPU.

• Banche dati crittografati con TDE non può usufruire della nuova compressione dei backup di SQL Server 2008. Se si vuole prendere vantaggio sia la compressione dei backup e la crittografia, si dovrà utilizzare un'applicazione di terze parti, come ad esempio SQL Backup, che consente di eseguire entrambi questi compiti senza penale.

Questo potrebbe essere di interesse: Procedura: Encrypt una colonna di dati