Qualcuno potrebbe aiutarmi a capire la crittografia del database SQL TDE?

Hai ragione, il punto di crittografia del database non è quello di proteggere i dati dagli utenti del database - questo è il compito dei livelli di accesso e privilegio basati sui ruoli.

La crittografia protegge da chi ruba fisicamente il server dal suo rack, estraendo il disco rigido e quindi leggendo i dati riservati dal file system. È un po 'più complicato di così - ovviamente non si può semplicemente tenere la chiave di decifrazione in giro, in particolare non sullo stesso disco in cui si archivia il DB crittografato, altrimenti il ladro potrebbe solo decrittografare i dati - ma fatto bene, può aggiungi un livello funzionale di sicurezza dei dati e la sicurezza è tutta una questione di difesa in profondità.

Sì, puoi ancora interrogare select * from x

Ho poca esperienza con Transparent Data Encryption, ma come afferma lo stesso articolo:

TDE works at the file level, which is similar to two Windows® features: the Encrypting File System (EFS) and BitLocker™ Drive Encryption, the new volume-level encryption introduced in Windows Vista®

Nota che:

TDE does not replace cell-level encryption, EFS, or BitLocker.

Inoltre afferma:

TDE operates at the I/O level through the buffer pool. Thus, any data that is written into the database file (*.mdf) is encrypted.

Per darti un'idea dell'estensione:

Encrypting at the I/O level also allows the snapshots and backups to be encrypted, thus all snapshots and backups created by the database will be encrypted by TDE.

Come per la crittografia delle celle:

Cell-level encryption is implemented as a series of built-ins and a key management hierarchy.

Si richiama essenzialmente una funzione aggiuntiva en / decifratura per ogni cella di accesso, e richiede lo schema di modifica della cella 'varbinary' e ri-colata nel tipo di dati appropriato alla lettura.

Vedi anche:

• 4 modi per crittografare i dati in Microsoft SQL Server
• Quali sono gli impatti di TDE consentono sulle prestazioni del database?