Comportamento sempre crittografato in SQL Server 2016

Stavo facendo qualche demo in SQL Server 2016 per argomento Sempre crittografato. Ho pochi dubbi. Di seguito sono riportati i passaggi seguiti:

Nel server Database (ospitato in Microsoft Azure VM):

  1. Nella tabella MyTable , creata la chiave di crittografia della colonna (CEK) e la chiave di crittografia master (CMK)
  2. Select * from MyTable , mostra dati crittografati. (Sia da App che da server DB)
  3. Esportato il certificato dal server database
  4. Importato il certificato in App Server (il mio computer locale)
  5. Aggiunta Column Encryption Setting=Enabled alla stringa di connessione della mia applicazione.
  6. Funziona bene, ora mostra i dati in testo normale come previsto.

Dubbio:

In Database Server (in MS Azure VM), se un accesso SysAdmin (Autenticazione SQL) si collega a SSMS con parametro aggiuntivo Column Encryption Setting=Enabled , Mostra dati di testo normale (in attesa di dati crittografati). La mia comprensione è, nessun altro quindi gli utenti dell’applicazione dovrebbero vedere i dati di testo in chiaro ). Qualcuno può chiarire?

    Nel passaggio 3 si menziona che si esporta il certificato dal server database, per garantire la massima sicurezza, non archiviare mai il certificato sul server database. Il server non ha bisogno di avere accesso al certificato.

    Se un accesso SysAdmin (autenticazione SQL) si collega a SSMS con parametro aggiuntivo Impostazione crittografia colonna = Abilitato, viene visualizzato dati di testo normale (in attesa di dati crittografati). La mia comprensione è, nessun altro quindi gli utenti dell’applicazione dovrebbero vedere i dati di testo in chiaro). Qualcuno può chiarire?

    Se SysAdmin si connette a SSMS da un computer client con il certificato e se SysAdmin dispone dell’authorization per accedere al certificato, visualizzeranno i dati di solo testo.

    In parole povere, Always Encrypted fornisce la seguente garanzia di sicurezza, i dati in Plaintext saranno visibili solo alle quadro che hanno accesso a ColumnMasterKey (Certificate)


    Per elaborare, si consideri il seguente scenario.

    Considera due macchine:

    • MachineA : macchina su cui è in esecuzione SQL Server
    • MachineT : Client Machine.

    Considera due utenti

    • UserA (questo può essere tecnicamente un gruppo di utenti, ma considererò uno scenario con un singolo utente per semplicità): Chi è un amministratore su MachineA , gestisce il server SQL ed è SysAdmin su server SQL. Tuttavia, userA non ha alcun tipo di accesso a MachineT e UserA non dovrebbe essere in grado di decrittografare i dati crittografati archiviati in SQL Server sulla macchina A (dati crittografati, nel contesto di questa risposta sono i dati crittografati utilizzando la funzionalità Always Encrypted di Server SQL).

    • UserT (questo può essere tecnicamente un gruppo di utenti, ma considererò uno scenario con un singolo utente per semplicità): è un utente fidato, ha accesso a MachineT , ha accesso a tutti i dati nel database db che è ospitato su SQL Server in MacchinaA . Inoltre, poiché userT è affidabile, lui / lei dovrebbe essere in grado di decodificare i dati crittografati.

    Si consideri che SQL Server in esecuzione su MachineA ha database db e table t .

    Il nostro objective è proteggere una colonna appartenente alla tabella t , ad esempio ssnCol , in modo tale che solo userT possa essere in grado di vedere ssnCol in testo semplice.

    L’objective sopra descritto può essere raggiunto utilizzando i seguenti passaggi.

    • UserT accede a MachineT .
    • UserT apre SSMS in MachineT .
    • UserT si connette a SQL Server su MachineA
    • UserT crittografa ssnCol nella tabella t usando i passaggi indicati nella sezione Encrypt columns (configure Always Encrypted) di questo articolo
    • Dopo questo passaggio, la colonna ssnCol verrebbe crittografata.

    Quando userT crittografa ssnCol nel modo descritto sopra, vengono generate due chiavi

    • CMK : la chiave master della colonna CMK aka è la chiave utilizzata per crittografare CEK / s. Questa chiave è memorizzata nell’archivio certificati Windows di MachineT .
    • CEK : la chiave di crittografia della colonna CEK aka è la chiave utilizzata per crittografare ssnCol , questa chiave viene archiviata in forma crittografata in SQL Server su MachineA e non viene mantenuta in alcun punto del testo in chiaro.

    Quindi, per decodificare ssnCol , è richiesto CEK, tuttavia, per decrittografare CEK, è necessario CMK.

    Poiché CMK si trova nell’archivio certificati Windows di machineT , solo userT può accedere a CMK, decrittografare CEK e decrittografare ssnCol .

    userA è un amministratore su machineA e anche un SysAdmin su SQL Server, ma, poiché non ha accesso a CMK, userA non può accedere a ssnCol in testo semplice. È ansible verificarlo utilizzando SSMS da MachineA , effettuando l’accesso come utenteA e interrogando ssnCol

    Se hai altre domande per favore inseriscile nella sezione commenti e io posso risponderle.

    Una considerazione aggiuntiva e molto importante:

    L’objective principale di Always Encrypted è proteggere i dati da malware in esecuzione sulla macchina che ospita SQL Server e da utenti con privilegi elevati malevoli sulla macchina che ospita SQL Server (DBA, amministratori sys). Se questi sono i vettori di attacco che si desidera indirizzare nell’applicazione, non è mai necessario eseguire il provisioning delle chiavi per Always Encrypted su una macchina che ospita un’istanza di SQL Server che contiene un database con le colonne che si desidera proteggere. Se si esegue uno strumento di fornitura chiavi, ad esempio SSMS o PowerShell, su una macchina che ospita l’istanza e la macchina è compromise, un utente malintenzionato può rubare le chiavi, ad esempio raschiando la memoria SSMS. E, naturalmente, se si genera un certificato e si inserisce l’archivio certificati sulla macchina server, è ancora più facile per un utente malintenzionato ottenerlo.

    Fare riferimento a https://msdn.microsoft.com/en-us/library/mt708953.aspx#SecurityForKeyManagement per ulteriori dettagli e linee guida utili.