Sqlserver
 sql >> база данни >  >> RDS >> Sqlserver

SQL Server 2016:Винаги криптиран

SQL Server 2016 включва функция за защита на базата данни, наречена Винаги криптирана. Тъй като добавихме винаги криптирана поддръжка към драйвера на SQL Server ODBC, нашите клиенти ще могат да се възползват от тази функция.

Always Encrypted защитава данните на SQL Server в точката, в която те са най-податливи на атака:когато тези данни се използват. Например по време на транзакции и изчисления. Това се различава от съществуващите функции за криптиране на SQL Server, тъй като изискват декриптиране на данни, преди да могат да се извършват операции върху тях.

Ключът за криптиране, който защитава винаги криптирани колони, се съхранява на машината за приложение. Това означава, че SQL Server не може да декриптира винаги шифрованите данни. Ако машината на SQL Server е компрометирана, нападателят ще има достъп само до винаги криптирани данни под формата на шифр.

За повечето потребители функцията Always Encrypted ще бъде прозрачна, т.е. те са изолирани от работата на Always Encrypted и не трябва да променят това, което правят, за да се възползват от функцията.

В края на приложението криптирането се извършва от софтуерния драйвер, който осигурява клиентския интерфейс за SQL Server. В Linux и UNIX това е ODBC драйвер, който прозрачно криптира или декриптира данни в зависимост от посоката на движение. В случай на драйвера на Easysoft, Always Encrypted се активира чрез задаване на параметър на низ за връзка.

Тъй като хората са все по-загрижени, че техните данни са безопасни в облака, Always Encrypted ще бъде наличен в Azure SQL, базираната в облак версия на SQL Server с плащане при пускане. Следователно ODBC драйверът на Easysoft за Azure SQL също ще поддържа винаги криптиран.

Показване:Работа с винаги шифровани колони данни в Linux

ODBC драйверът на Easysoft SQL Server ви позволява да актуализирате и да заявявате данни, съхранявани във винаги криптирани колони.

Създайте таблицата и генерирайте ключовете за криптиране

Тези стъпки се извършват на машината на SQL Server.

  1. В SQL Server Management Studio 2016 CTP3 или по-нова версия създайте нова база данни.
  2. В новата база данни създайте таблица, която съдържа една или повече колони, чието съдържание искате да шифровате. Например:
    CREATE TABLE dbo.EncryptedTable( ID INT IDENTITY(1,1) PRIMARY KEY, Lastname NVARCHAR(32), Salary INT NOT NULL);
  3. Щракнете с десния бутон върху базата данни. От изскачащото меню изберете Задачи> Шифроване на колони .

    Стартира съветникът за винаги криптиран.

  4. В Избор на колона страница, разгънете таблиците и изберете колоните, които искате да шифровате.
  5. Изберете тип криптиране за всяка колона.

    Детерминистично - винаги криптира към един и същ шифрован текст, позволявайки да се извършват търсене на равенство, присъединяване и групиране по.

    Произволно генерира различна стойност на шифрован текст за същия обикновен текст, който е по-сигурен, но не поддържа никакви операции.

  6. Изберете CEK_Auto1 (New) като ключ за криптиране за всяка колона, който е нов автоматично генериран ключ. Изберете Напред .
  7. В страницата за конфигуриране на главния ключ приемете настройките по подразбиране:
    Поле Стойност
    Изберете главен ключ на колона Автоматично генериране на главен ключ на колона
    Изберете доставчика на хранилище на ключове Съхранение за сертификати на Windows
    Изберете главен ключ на колона Текущ потребител
  8. Използвайте Напред бутон, за да продължите към Резюме страница. Изберете Край .
  9. Изчакайте съветникът да завърши и след това изберете Затвори .

Експортиране на сертификатите

За да прехвърлите сертификатите на машината с Linux, първо трябва да ги експортирате в Windows.

  1. В прозорец на командния ред въведете certmgr , за да стартирате приставката за сертификати.
  2. Новият винаги шифрован сертификат ще бъде наличен под Сертификати - Текущ потребител> Лични> Сертификати .
  3. Щракнете с десния бутон върху сертификата (който ще се нарича нещо като Always Encrypted Auto Certificate1 ). От изскачащото меню изберете Всички задачи> Експортиране .

    Стартира съветникът за експортиране на сертификати. Изберете Напред .

  4. Изберете Да, експортирайте частния ключ .
  5. Приемете настройките по подразбиране на страницата Формат за експортиране на файл. Изберете Напред .
  6. Посочете парола, когато бъдете подканени. Изберете Напред .
  7. Наименувайте и запазете сертификата, когато бъдете подканени. Например, CMK_Auto1.pfx .
  8. Използвайте Напред и Край бутони, за да завършите съветника.

Инсталиране на сертификатите на Linux

Прехвърлете експортираните сертификати на Linux машината, от която искате да получите достъп до винаги шифрованите колони:

  1. Копирайте сертификата, който току-що експортирате в ~/ssl/private на Linux или UNIX машината, където сте инсталирали ODBC драйвера на SQL Server.

    ~ е началната директория на потребителя, който ще стартира приложението, което се свързва към SQL Server чрез драйвера на Easysoft ODBC. ~/ssl/private е мястото, от което слоят OpenSSL, вграден в драйвера, ще се опита да зареди личен сертификат. Създайте директорията, ако тя не съществува. Например:

    $ mkdir -p ~/ssl/private$ cd ~/ssl/private$ mv /tmp/CMK_Auto1.pfx .
  2. За да използвате сертификата с ODBC драйвера на SQL Server, трябва да премахнете съдържащата се в него фраза. За да направите това, OpenSSL трябва да бъде инсталиран на машината. (Това е необходимо само за премахване на паролата, за други операции ODBC драйверът на SQL Server използва вграден OpenSSL слой.) Премахнете паролата със следните команди. Когато бъдете подканени за паролата след втората командата, натиснете RETURN, без да въвеждате нищо. Това ще зададе паролата на нищо.
    $ openssl pkcs12 -in CMK_Auto1.pfx -nodes -out temp.pemEnter Парола за импортиране:*******MAC проверен OK$ openssl pkcs12 -export -in temp.pem -out nopassphrase.p12Въведете парола за експортиране:Проверка - Въведете парола за експортиране:$
  3. За да зареди сертификата, ODBC драйверът на SQL Server използва мета информация, която получава от SQL Server за криптираната колона. Името на сертификата, което драйверът получава от SQL Server, е във формата my/thumbprint . Трябва да използвате тази конвенция за именуване за сертификата. Използвайте OpenSSL, за да покажете отпечатъка на сертификата и след това преименувайте сертификата в поддиректория с име my:
    $ openssl x509 -in temp.pem -fingerprint -noout | tr -d ":"SHA1 Fingerprint=EFC1940E545941D6C05C763361403F55A5DEF0E8$ mkdir my$ cp nopassphrase.p12 my/EFC1940E545941D6C05C7633561D6C05C7633561My$033561D6C05C7633561My$03Es58D 

    Забележка По време на тестването забелязахме, че SQL Server понякога наименува сертификата My/thumbprint . Символичната връзка в горния пример работи около това несъответствие.

Инсталиране на ODBC драйвера на SQL Server

ODBC драйверът на SQL Server не само осигурява слоя за свързване между приложението и SQL Server, но също така обработва криптирането/декриптирането на данни, съхранявани във винаги криптирани колони.

Инсталирайте и лицензирайте ODBC драйвера на SQL Server. За инструкции как да направите това, вижте документацията на SQL Server ODBC драйвер. Ако приложението ви е 64-битово, изтеглете 64-битовата версия на ODBC драйвера. В противен случай използвайте 32-битовата версия на драйвера, независимо от архитектурата на операционната система.

Източникът на ODBC данни съдържа информацията за низа за свързване, която позволява на драйвера на ODBC на SQL Server да се свърже с целевия екземпляр на SQL Server. На нашата машина източниците на ODBC данни се съхраняват в /etc/odbc.ini . Този извлечен от източника на данни показва съответните настройки за винаги криптирани колони:

[SQLSERVER_2016]Драйвер=Easysoft ODBC-SQL сървър SSL # Трябва да се използва SSL версия на driverServer=machine\sqlserver_instanceDatabase=database_with_always_encrypted_dataUser=user # Това може да бъде вход в Windows или SQL Server.Password=passwordTrusted_Connection=Yes # Задайте това на Не за изглед на данни в SQLE или изглед на данни за SQLE или EncryptndColum to # вмъкнете в колона Always Encrypted, зададена на Enabled

Забележка Ако връзката ви е неуспешна с грешката „SSL връзката е неуспешна при системно повикване“, в системата ви липсва „устройство за произволна произволност“. Вижте Entropy атрибут в ръководството на драйвера на SQL Server ODBC за информация какво да правите по въпроса.

Вмъкване на данни във винаги криптирана колона

Вече създадохме празна таблица с винаги криптирани колони и настроихме нашата клиентска машина за Linux, така че ODBC драйверът на SQL Server да може да работи с винаги криптирани данни. След това трябва да попълним таблицата с данни.

За да вмъкне данни в колона за винаги шифровани, едно приложение трябва:

  1. Използвайте параметризирано вмъкване, т.е. INSERT INTO EncryptedTable VALUES (?, ?).

    Това позволява на драйвера на ODBC на SQL Server да прави разлика между стойностите на колоните (които трябва да криптира) и текста на SQL израза (който трябва да остане в обикновен текст; с Always Encrypted, не забравяйте, че SQL Server не извършва никакво декриптиране).

  2. Опишете изрично типа данни на параметрите.

    SQL Server не предоставя необходимата информация за Always Encrypted колона за SQL Server ODBC драйвер за откриване на типа данни чрез SQLDescribeParam .

Ето пример на Perl, който показва как да направите това:

# Използвайте Perl DBI / DBD:ODBC за вмъкване на данни във винаги криптирани колони.използвайте strict;използвайте предупреждения;използвайте DBI;my $data_source =q/dbi:ODBC:SQLSERVER_2016/;my $h =DBI->connect( $data_source) или умре "Не мога да се свържа с $data_source:$DBI::errstr";$h->{RaiseError} =1;my $s =$h->prepare(q/insert into EncryptedTable values(?, ?)/);my $lastname='Smith';my $salary=25000;# Задайте типа данни на целевите колони.# Не може да използва SQLDescribeParam с винаги криптирани колони.$s->bind_param(1, $lastname, DBI ::SQL_WVARCHAR);$s->bind_param(2, $salary, DBI::SQL_INTEGER);$s->execute($lastname,$salary);$h->disconnect;

Ето примерна C, която показва как да направите това:

#include #include #include #include #include #include #include #define LASTNAME_LEN 6SQLHENV henv =SQL_NULL_HENV; // EnvironmentSQLHDBC hdbc =SQL_NULL_HDBC; // Манипулатор на връзкатаSQLHSTMT hstmt =SQL_NULL_HSTMT; // Инструкция handleSQLRETURN retcode;SQLCHAR strLastName[]="Jones";SQLINTEGER pSalary=25000;SQLLEN lenLastName=0;int main () { // Разпределяне на среда retcode =SQLAllocHandle(SQL_HANDLE_ENV,SQL_HANDLE_ENV,SQL_NULL_ENV,SQL_NULL_ENV,SQL_NULL_ENV, // Задаване на версия на ODBC retcode =SQLSetEnvAttr(henv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER*)SQL_OV_ODBC3, 0); // Разпределяне на връзката retcode =SQLAllocHandle(SQL_HANDLE_DBC, henv, &hdbc); // Свързване към DSN retcode =SQLConnect(hdbc, (SQLCHAR*) "MyDSN", SQL_NTS, (SQLCHAR*) NULL, 0, NULL, 0); // Разпределяне на манипулатор на изявление retcode =SQLAllocHandle(SQL_HANDLE_STMT, hdbc, &hstmt); // Свързване на параметри към всички полета 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"); // Безплатни манипулатори // Инструкция if (hstmt !=SQL_NULL_HSTMT) SQLFreeHandle(SQL_HANDLE_STMT, hstmt); // Връзка if (hdbc !=SQL_NULL_HDBC) { SQLDisconnect(hdbc); SQLFreeHandle(SQL_HANDLE_DBC, hdbc); } // Среда if (henv !=SQL_NULL_HENV) SQLFreeHandle(SQL_HANDLE_ENV, henv); върнете 0;} 

Сега колоните са попълнени, можем да използваме isql, за да извлечем данните:

$ /usr/local/easysoft/unixODBC/bin/isql.sh -v SQLSERVER_2016SQL> изберете * от EncryptedTable+----+----------+-------- ----+| ID | Фамилия | Заплата |+----+-----------+-----------+| 1 | Смит | 25000 |+----+----------+-----------+

Имахме включено регистриране на драйвери в нашия източник на данни. Следното извлечение от регистрационния файл на драйвера показва, че:

  1. SQL Server предоставя името на сертификата като мета информация за колоната.
  2. Данните в колоната са криптирани в края на SQL Server и следователно остават криптирани при предаване. ODBC драйверът на SQL Server на клиента декриптира стойностите на колоните и след това ги връща в обикновен текст на приложението.
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.C.B.B.6..C.2.F.6..C.B.B.2. .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:Шифрована колона.);...'A..zs..I..N.]r..p.-..$....S;.].km6.....3cr.OhR ..j*.....fj....ARN{V.F.....DETAIL:EVP_DecryptInit връща 1DETAIL:EVP_DecryptUpdate връща 1, 0DETAIL:EVP_DecryptUpdate връща 1, 16DETAIL:EVP_DecryptFinal връща 1, 0PKT.mDUMP:data. предварително> 

Вижте също

  • Използване на данни, защитени с Azure Key Vault от Linux
  • Използване на данни, защитени с персонализирано хранилище за ключове от Linux

  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Съпоставяне в SQL Server

  2. Вземете знака между първите 2 специални знака в SQL

  3. SQL Server:Вземете първичен ключ на таблицата с помощта на sql заявка

  4. Всички ли мигрират към облака?

  5. Как да използвам UTF-8 Collation в база данни на SQL Server?