Sqlserver
 sql >> Database >  >> RDS >> Sqlserver

SQL Server 2016:sempre crittografato

SQL Server 2016 include una funzionalità di sicurezza del database denominata Always Encrypted. Poiché abbiamo aggiunto il supporto Always Encrypted al driver ODBC di SQL Server, i nostri clienti potranno sfruttare questa funzionalità.

Always Encrypted protegge i dati di SQL Server nel punto in cui sono più suscettibili agli attacchi:quando tali dati vengono utilizzati. Ad esempio, durante transazioni e calcoli. Ciò differisce dalle funzionalità di crittografia di SQL Server esistenti in quanto richiedono la decrittografia dei dati prima di poter eseguire operazioni su di essi.

La chiave di crittografia che protegge le colonne Always Encrypted è archiviata nel computer dell'applicazione. Ciò significa che SQL Server non è in grado di decrittografare i dati Always Encrypted. Se la macchina SQL Server è compromessa, l'autore dell'attacco sarà in grado di accedere ai dati Always Encrypted solo in forma di cifratura.

Per la maggior parte degli utenti, la funzione Always Encrypted sarà trasparente, ovvero sono isolati dal funzionamento di Always Encrypted e non devono modificare ciò che stanno facendo per beneficiare della funzione.

Al termine dell'applicazione, la crittografia viene eseguita dal driver software che fornisce l'interfaccia client per SQL Server. Su Linux e UNIX, questo è un driver ODBC, che crittografa o decrittografa i dati in modo trasparente a seconda della direzione di marcia. Nel caso del driver Easysoft, Always Encrypted viene abilitato impostando un parametro di stringa di connessione.

Poiché le persone sono sempre più preoccupate che i loro dati siano al sicuro nel cloud, Always Encrypted sarà disponibile in Azure SQL, la versione con pagamento in base al consumo basata su cloud di SQL Server. Il driver ODBC di Easysoft per Azure SQL supporterà quindi anche Always Encrypted.

Procedura dettagliata:utilizzo dei dati delle colonne Always Encrypted su Linux

Il driver ODBC per SQL Server di Easysoft consente di aggiornare e interrogare i dati contenuti nelle colonne Always Encrypted.

Crea la tabella e genera le chiavi di crittografia

Questi passaggi vengono eseguiti sul computer SQL Server.

  1. In SQL Server Management Studio 2016 CTP3 o versioni successive, crea un nuovo database.
  2. Nel nuovo database, crea una tabella che contenga una o più colonne di cui desideri crittografare il contenuto. Ad esempio:
    CREATE TABLE dbo.EncryptedTable
(
  ID INT IDENTITY(1,1) PRIMARY KEY, LastName NVARCHAR(32), Salary INT NOT NULL
);
  3. Fare clic con il pulsante destro del database. Dal menu a comparsa, scegli Attività> Crittografa colonne .

    Viene avviata la procedura guidata Always Encrypted.

  4. Sulla Selezione della colonna pagina, espandi le tabelle e seleziona le colonne che desideri crittografare.
  5. Scegli un tipo di crittografia per ogni colonna.

    Deterministico - crittografa sempre lo stesso testo cifrato, consentendo l'esecuzione di ricerche di uguaglianza, join e raggruppamento per.

    Randomizzato genera un valore di testo cifrato diverso per lo stesso testo normale, che è più sicuro, ma non supporta alcuna operazione.

  6. Scegli CEK_Auto1 (New) come chiave di crittografia per ogni colonna, che è una nuova chiave generata automaticamente. Scegli Avanti .
  7. Nella pagina Configurazione chiave master, accetta le impostazioni predefinite:
    Campo Valore
    Seleziona la chiave principale della colonna Genera automaticamente la chiave principale della colonna
    Seleziona il fornitore dell'archivio chiavi Archivio certificati di Windows
    Seleziona la chiave principale della colonna Utente attuale
  8. Usa il Avanti per passare al Riepilogo pagina. Scegli Fine .
  9. Aspetta il completamento della procedura guidata, quindi scegli Chiudi .

Esportazione dei certificati

Per trasferire i certificati sulla macchina Linux, devi prima esportarli su Windows.

  1. In una finestra del prompt dei comandi, digita certmgr , per avviare lo snap-in Certificati.
  2. Il nuovo certificato Always Encrypted sarà disponibile in Certificati - Utente corrente> Personale> Certificati .
  3. Fai clic con il pulsante destro del mouse sul certificato (che verrà chiamato in modo simile a Always Encrypted Auto Certificate1 ). Dal menu a comparsa, scegli Tutte le attività> Esporta .

    Viene avviata l'Esportazione guidata certificati. Scegli Avanti .

  4. Scegli Sì, esporta la chiave privata .
  5. Accetta le impostazioni predefinite nella pagina Formato file di esportazione. Scegli Avanti .
  6. Fornire una password quando richiesto. Scegli Avanti .
  7. Nomina e salva il certificato quando richiesto. Ad esempio, CMK_Auto1.pfx .
  8. Usa il Avanti e Fine pulsanti per completare la procedura guidata.

Installazione dei certificati su Linux

Trasferisci i certificati esportati sulla macchina Linux da cui vuoi accedere alle colonne Always Encrypted:

  1. Copia il certificato che hai appena esportato in ~/ssl/private sulla macchina Linux o UNIX in cui è stato installato il driver ODBC di SQL Server.

    ~ è la home directory dell'utente che eseguirà l'applicazione che si connette a SQL Server tramite il driver Easysoft ODBC. ~/ssl/private è la posizione da cui il livello OpenSSL integrato nel driver tenterà di caricare un certificato personale. Crea la directory se non esiste. Ad esempio:

    $ mkdir -p ~/ssl/private
$ cd ~/ssl/private
$ mv /tmp/CMK_Auto1.pfx .
  2. Per utilizzare il certificato con il driver ODBC di SQL Server, è necessario rimuovere la passphrase in esso contenuta. Per fare ciò, OpenSSL deve essere installato sulla macchina. (Questo è necessario solo per rimuovere la passphrase, per altre operazioni, il driver ODBC di SQL Server utilizza un livello OpenSSL integrato.) Rimuovere la passphrase con i seguenti comandi. Quando viene richiesta la passphrase dopo il secondo comando, premere INVIO senza inserire nulla. Questo imposterà la passphrase su nulla. 
    $ openssl pkcs12 -in CMK_Auto1.pfx -nodes -out temp.pem
Enter Import Password: *******
MAC verified OK
$ openssl pkcs12 -export -in temp.pem  -out nopassphrase.p12
Enter Export Password:
Verifying - Enter Export Password:
$
  3. Per caricare il certificato, il driver ODBC di SQL Server utilizza le metainformazioni che riceve da SQL Server sulla colonna crittografata. Il nome del certificato ricevuto dal driver da SQL Server è nel formato my/thumbprint . È necessario utilizzare questa convenzione di denominazione per il certificato. Utilizzare OpenSSL per visualizzare l'identificazione personale del certificato e quindi rinominare il certificato in una sottodirectory denominata my:
    $ openssl x509 -in temp.pem -fingerprint -noout | tr -d ":"
SHA1 Fingerprint=EFC1940E545941D6C05C763361403F55A5DEF0E8
$ mkdir my
$ cp nopassphrase.p12 my/EFC1940E545941D6C05C763361403F55A5DEF0E8
$ ln -s my My

    Nota Durante i test, abbiamo notato che a volte SQL Server ha chiamato il certificato My/thumbprint . Il collegamento simbolico nell'esempio precedente risolve questa incoerenza.

Installazione del driver ODBC di SQL Server

Il driver ODBC di SQL Server non solo fornisce il livello di connettività tra l'applicazione e SQL Server, ma gestisce anche la crittografia/decodifica dei dati archiviati nelle colonne Always Encrypted.

Installare e concedere in licenza il driver ODBC di SQL Server. Per istruzioni su come eseguire questa operazione, fare riferimento alla documentazione del driver ODBC di SQL Server. Se la tua applicazione è a 64 bit, scarica la versione a 64 bit del driver ODBC. In caso contrario, utilizzare la versione a 32 bit del driver, indipendentemente dall'architettura del sistema operativo.

Un'origine dati ODBC contiene le informazioni sulla stringa di connessione che consentono al driver ODBC di SQL Server di connettersi all'istanza di destinazione di SQL Server. Sul nostro computer, le origini dati ODBC sono archiviate in /etc/odbc.ini . Questo estratto dell'origine dati mostra le impostazioni pertinenti per le colonne Always Encrypted:

[SQLSERVER_2016]
Driver=Easysoft ODBC-SQL Server SSL # Must use SSL version of driver
Server=machine\sqlserver_instance
Database=database_with_always_encrypted_data
User=user # This can be a Windows or SQL Server login.
Password=password
Trusted_Connection=Yes # Set this to No for a SQL Server login
ColumnEncryption=Enabled # To view Always Encrypted data or to
                         # insert into an Always Encrypted column set to Enabled

Nota Se la tua connessione fallisce con l'errore "Connessione SSL non riuscita in syscall", il tuo sistema non ha un "dispositivo casuale". Vedi l'Entropy attributo nel manuale del driver ODBC di SQL Server per informazioni su cosa fare al riguardo.

Inserimento di dati in una colonna sempre crittografata

Ora abbiamo creato una tabella vuota con colonne Always Encrypted e configurato la nostra macchina client Linux in modo che il driver ODBC di SQL Server possa funzionare con i dati Always Encrypted. Successivamente, dobbiamo popolare la tabella con i dati.

Per inserire dati in una colonna Always Encrypted, un'applicazione deve:

  1. Utilizzare un inserto parametrizzato, ad esempio INSERT INTO EncryptedTable VALUES (?, ?).

    Ciò consente al driver ODBC di SQL Server di distinguere tra i valori della colonna (che deve crittografare) e il testo dell'istruzione SQL (che deve rimanere in testo normale; con Always Encrypted, ricorda, SQL Server non esegue alcuna decrittografia).

  2. Descrivere in modo esplicito il tipo di dati dei parametri.

    SQL Server non fornisce le informazioni necessarie su una colonna Always Encrypted per consentire al driver ODBC di SQL Server di rilevare il tipo di dati utilizzando SQLDescribeParam .

Ecco un esempio di Perl che mostra come farlo:

# Use Perl DBI / DBD:ODBC to insert data into Always Encrypted columns.
use strict;
use warnings;
use DBI;

my $data_source = q/dbi:ODBC:SQLSERVER_2016/;

my $h = DBI->connect($data_source)
    or die "Can't connect to $data_source: $DBI::errstr";
$h->{RaiseError} = 1;

my $s = $h->prepare(q/insert into EncryptedTable values(?,?)/);
my $lastname='Smith';
my $salary=25000;

# Set the data type of the target columns.
# Cannot use SQLDescribeParam with Always Encrypted columns.
$s->bind_param(1, $lastname, DBI::SQL_WVARCHAR);
$s->bind_param(2, $salary, DBI::SQL_INTEGER);
$s->execute($lastname,$salary);
$h->disconnect;

Ecco un esempio C che mostra come farlo:

#include <stdio.h>
#include <stdlib.h>
#include <sql.h>
#include <sqlucode.h>
#include <sqlext.h>
#include <string.h>
#include <wchar.h>

#define LASTNAME_LEN 6

SQLHENV   henv  = SQL_NULL_HENV;   // Environment
SQLHDBC   hdbc  = SQL_NULL_HDBC;   // Connection handle
SQLHSTMT  hstmt = SQL_NULL_HSTMT;  // Statement handle
SQLRETURN retcode;

SQLCHAR strLastName[]="Jones";
SQLINTEGER pSalary=25000;

SQLLEN lenLastName=0;

int main () {
    // Allocate environment
    retcode = SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &henv);

    // Set ODBC Version
    retcode = SQLSetEnvAttr(henv, SQL_ATTR_ODBC_VERSION,
                            (SQLPOINTER*)SQL_OV_ODBC3, 0);

    // Allocate Connection
    retcode = SQLAllocHandle(SQL_HANDLE_DBC, henv, &hdbc);

    // Connect to DSN
    retcode = SQLConnect(hdbc, (SQLCHAR*) "MyDSN", SQL_NTS,
                         (SQLCHAR*) NULL, 0, NULL, 0);

    // Allocate Statement Handle
    retcode = SQLAllocHandle(SQL_HANDLE_STMT, hdbc, &hstmt);

    // Bind Parameters to all fields
    retcode = SQLBindParameter(hstmt, 1, SQL_PARAM_INPUT, SQL_C_CHAR,
                               SQL_WVARCHAR, LASTNAME_LEN, 0, strLastName, LASTNAME_LEN,
                    &lenLastName);

    retcode = SQLBindParameter(hstmt, 2, SQL_PARAM_INPUT, SQL_C_LONG,
                               SQL_INTEGER, 0, 0, &pSalary, 0, NULL);

    retcode = SQLPrepare(hstmt, (SQLCHAR*)"INSERT INTO [dbo].[EncryptedTable] ([LastName],[Salary]) VALUES (?,?)",
                               SQL_NTS);

    lenLastName=strlen((char*)strLastName);

    retcode = SQLExecute(hstmt);

exit:

    printf ("\nComplete.\n");

    // Free handles
    // Statement

    if (hstmt != SQL_NULL_HSTMT)
        SQLFreeHandle(SQL_HANDLE_STMT, hstmt);

    // Connection
    if (hdbc != SQL_NULL_HDBC) {
        SQLDisconnect(hdbc);
        SQLFreeHandle(SQL_HANDLE_DBC, hdbc);
    }

    // Environment
    if (henv != SQL_NULL_HENV)
        SQLFreeHandle(SQL_HANDLE_ENV, henv);

    return 0;
}

Ora le colonne sono popolate, possiamo usare isql per recuperare i dati:

$ /usr/local/easysoft/unixODBC/bin/isql.sh -v SQLSERVER_2016
SQL> select * from EncryptedTable
+----+----------+------------+
| ID | LastName | Salary     |
+----+----------+------------+
| 1  | Smith    | 25000      |
+----+----------+------------+

La registrazione del driver è stata attivata nell'origine dati. Il seguente estratto dal registro del driver mostra che:

  1. SQL Server fornisce il nome del certificato come metainformazioni sulla colonna.
  2. I dati della colonna vengono crittografati all'estremità di SQL Server e pertanto rimangono crittografati in transito. Il driver ODBC di SQL Server sul client decrittografa i valori delle colonne e quindi li restituisce in testo normale all'applicazione.
1.
M.S.S.Q.L._.C.E.
R.T.I.F.I.C.A.T.
E._.S.T.O.R.E.7.
C.u.r.r.e.n.t.U.
s.e.r./.m.y./.7.
2.8.8.1.8.C.5.F.
B.2.C.6.E.B.F.C.
2.5.3.D.B.C.1.2.
2.8.5.B.6.A.D.9.
4.8.9.0.8.3.E..R
.S.A._.O.A.E.P..
.....8.I.D......
...........@....
......L.a.s.t.N.
a.m.e........Q..
.....8....S.a.l.
a.r.y...........

2.
PKTDUMP:         Encrypted column
.);...'A..zs..I.
.N.]r..p.-..$...
.S;.].km6.....3c
r.OhR..j*.....fj
....ARN{V.F.....

DETAIL:  EVP_DecryptInit returns 1
DETAIL:  EVP_DecryptUpdate returns 1, 0
DETAIL:  EVP_DecryptUpdate returns 1, 16
DETAIL:  EVP_DecryptFinal returns 1, 0
PKTDUMP:         data

S.m.i.t.h.

Vedi anche

  • Utilizzo dei dati protetti con Azure Key Vault da Linux
  • Utilizzo dei dati protetti con un archivio chiavi personalizzato da Linux