Download to read offline
![Dynamic Data Masking – reguły maskujące
• Funkcja Custom String: maskowanie częściowe:
• Pozwala określić liczbę początkowych znaków ciągu (prefix)
• Fragment stały „pośrodku” ([padding])
• Liczba znaków odkrytych na końcu ciągu (suffix)
Przykłady:
ALTER COLUMN [PESEL]
ADD MASKED WITH (FUNCTION = 'partial(4,"####",3)')
ALTER COLUMN [Phone Number]
ADD MASKED WITH (FUNCTION = 'partial(5,"XXXXXXX",0)')
ALTER COLUMN [Social Security Number]
ADD MASKED WITH (FUNCTION = 'partial(0,"XXX-XX-",4)')](https://image.slidesharecdn.com/sql2016security-151211215716/75/Nowosci-w-zakresie-bezpieczenstwa-w-SQL-Server-2016-20-2048.jpg)
![Dynamic Data Masking – reguły maskujące
• Funkcja Random:
• Maskowanie wartości numerycznych
• Pozwala określić zakres, z którego będą losowane wartości maskujące
Przykłady:
Account_Number bigint
MASKED WITH (FUNCTION = 'random([start range], [end range])')
ALTER COLUMN [Month]
ADD MASKED WITH (FUNCTION = 'random(1, 12)')](https://image.slidesharecdn.com/sql2016security-151211215716/75/Nowosci-w-zakresie-bezpieczenstwa-w-SQL-Server-2016-21-2048.jpg)
Uploaded byKamil Nowinski
Nowości w zakresie bezpieczeństwa w SQL Server 2016
Przechowywanie wrażliwych danych w bazie często wzbudza wiele wątpliwości. Co w sytuacji kiedy użytkownik uzyska bezpośredni dostęp i będzie mógł wykonać zapytanie zwracające więcej danych niż zobaczyłby w aplikacji? Spośród zapowiedzianych nowości – SQL Server 2016 przynosi również ulepszenia w obszarze zabezpieczeń, które przedstawimy podczas naszej sesji. Row Level Security – zabezpieczanie danych na poziomie wierszy to funkcjonalność na którą czeka wielu deweloperów T-SQL. Do tej pory stali oni przed koniecznością ukrywania części danych za pomocą widoków filtrujących źródłowe dane. SQL Server 2016 pozwala na ukrycie części rekordów przed użytkownikiem nawet w sytuacji w której ma on bezpośredni dostęp do tabel. Chcesz pozwolić użytkownikom odczytywać wszystkie rekordy – ale w przypadku kolumn takich jak numer PESEL czy numer karty kredytowej chcesz aby mogli wyświetlić tylko kilka pierwszych cyfr? Umożliwi to kolejna nowa omawiana funkcjonalność – Dynamic Data Masking.
![[#3] in memory - IBM Integrated Analytics System](https://cdn.slidesharecdn.com/ss_thumbnails/3in-memory-180316003821-thumbnail.jpg?width=640&height=640&fit=bounds)
Nowości w zakresie bezpieczeństwa w SQL Server 2016
- 1. Nowości w zakresiebezpieczeństwa SQL Server 2016 Kamil Nowiński PLSSUG Wrocław kamil.nowinski@plssug.org.pl @NowinskiK Tomasz Libera PLSSUG Kraków tomasz.libera@plssug.org.pl @tomasz_libera
- 2. Kamil Nowiński TomaszLibera • DB Developer w WSZiB w Krakowie • Lider PLSSUG Kraków • Członek Zarządu Stowarzyszenia PLSSUG • Certyfikaty: • MCT • MCSE Data Platform • MCITP-DBA, MCITP-DD • Zainteresowania: • Pasjonat kolarstwa górskiego i maratonów MTB • Senior SQL/BI Developer w AlternativeNetworks (UK) • Programista > 20 lat (VB6, VB.NET, C#, .NET Framework) • Ponad 10-letnie doświadczenie jako DEV/DBA • Członek komisji rewizyjnej PLSSUG, • Certyfikaty SQL Server: MCITP, MCP, MCTS, MCSA, MCSE Data Platform • Zainteresowania: • Rower, bieganie • Fotografia cyfrowa (Nikon D-90, Adobe Lightroom)
- 3. Agenda • Row-Level Security •Dynamic Data Masking • Always Encrypted • Podsumowanie
- 4.
- 5. DEMO #1 jak radzimysobie bez SQL2016 i RLS
- 6. Row-Level Security -wprowadzenie • Zabezpieczanie danych na poziomie wiersza, realizowane poprzez • Security Predicate Filter (inline TVF) • Security Policy (Polityka bezpieczeństwa) • Praktyczne scenariusze • Możliwości dostępne wcześniej w Azure SQL Database • Inne RDBMS posiadają swoje odpowiedniki • Row Security Policies (PostgreSQL 9.5) • Oracle Label Security (Oracle 10g)
- 7. DEMO #2 Row LevelSecurity (Direct Connected Users)
- 8. Row-Level Security -predykaty • Dwa typy predykatów bezpieczeństwa: • Predykaty filtrowania podczas operacji odczytu (SELECT, UPDATE, DELETE) • Predykaty blokujące operacje zapisu naruszające predykat (AFTER INSERT, AFTER UPDATE, BEFORE UPDATE, BEFORE DELETE)
- 9. Row-Level Security –uprawnienia Zestaw uprawnień wymagany do zarządzania politykami Security Policies: • ALTER ANY SECURITY POLICY • ALTER – do schematu • Uprawnienia dla każdego dodanego predykatu: • SELECT & REFERENCES – do funkcji użytej jako predykat • REFERENCES – do tabeli docelowej powiązanej z polityką • REFERENCES – do każdej kolumny użytej jako argument funkcji
- 10. Ograniczenia • FTS bazujena niefiltrowanych danych CTP 2.4! • DBCC SHOW_STATISTICS pokazuje dane nieprzefiltrowane CTP 2.4! • Blokowanie wstawianych rekordów CTP 3! • RLS jest niekompatybilny z memory-optimized tables (In-Memory OLTP) • RLS jest niekompatybilny z CDC • Nie można tworzyć widoków indeksowanych w oparciu o tabele z RLS • Zwykle użytkownicy łączą się przy pomocy tego samego użytkownika (…)
- 11. Przechowywanie danych sesji •Zapis do sesji • SET CONTEXT_INFO – pojedyncza wartość • EXEC sp_set_session_context @key = N'x', @value = 'y', @read_only = 1; • Odczyt • CONTEXT_INFO() • SESSION_CONTEXT(`key`) • Możliwość odwołania się po zakończeniu bieżącego wsadu/procedury... • Przydatny w celu przechowywania danych zalogowanego użytkownika • Scenariusz: aplikacja nawiązuje połączenie z bazą, zapisuje do sesji identyfikator zalogowanego użytkownika, który sprawdzamy w predykacie filtrującym
- 12. DEMO #3 Row LevelSecurity (CONTEXT_INFO)
- 13. RLS - Dobrepraktyki • Zalecane jest utworzenie odrębnego schematu na Security Policy i Security Predicate Filter • ALTER ANY SECURITY POLICY to uprawnienie dla wysoko uprawnionych użytkowników zarządzających uprawnieniami. • Unikaj konwersji typów, rekursji, licznych JOINÓW oraz generalnie kosztownych ze względu na wydajność w funkcji będącej predykatem • Utwórz indeks na kolumnie, która jest filtrowana w Security Predicate • Wydajność RLS porównywana z filtrowaniem dostępu przez widoki
- 14.
- 15. Dynamic Data Masking- wprowadzenie • „Dynamiczne maskowanie danych” • Ogranicza prezentację wrażliwych danych dla osób niepowołanych • Pozwala kontrolować fragment ukrywanych wartości • Niezależne od warstwy aplikacji • Dane w bazie danych pozostają nienaruszone • Proces maskowania danych w wynikach zapytania • Możliwość zaaplikowania reguł bez zmian w istniejących aplikacjach • Reguły stosowane na wybranych kolumnach tabeli
- 16. Dynamic Data Masking- przykłady • Credit Card Number 4462 7123 9921 7612 -> #### #### #### 7612 • Social Security Number • PESEL 78100702880 -> 7810####880
- 17. Dynamic Data Masking- założenia • Ograniczenie ujawniania danych niepowołanym użytkownikom ALE • NIE zapobiega przed dostępem do tych danych użytkownikom bazy danych łączących się bezpośrednio do bazy i posiadającym stosowne uprawnienie • Uzupełnienie innych funkcjonalności SQL Server: • Auditing • Encryption • Row Level Security
- 18. Dynamic Data Masking– reguły maskujące • Funkcja Default: Pełne maskowanie zgodnie z typem danych • Zwraca XXXX dla typów tekstowych • Zwraca 0 (zero) dla typów numerycznych • Zwraca 2000-01-01 dla danych typów data • Zwraca 0 (zero) dla typów binarnych Przykład: Phone# varchar(12) MASKED WITH (FUNCTION = 'default()') NULL
- 19. Dynamic Data Masking– reguły maskujące • Funkcja Email: • Zwraca pierwszą literę prawdziwego adresu email • Na końcu ciągu zawsze pokazuje „.com” • kXXXX@XXXX.com Przykłady: Email varchar(100) MASKED WITH (FUNCTION = 'email()') NULL ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()')
- 20. Dynamic Data Masking– reguły maskujące • Funkcja Custom String: maskowanie częściowe: • Pozwala określić liczbę początkowych znaków ciągu (prefix) • Fragment stały „pośrodku” ([padding]) • Liczba znaków odkrytych na końcu ciągu (suffix) Przykłady: ALTER COLUMN [PESEL] ADD MASKED WITH (FUNCTION = 'partial(4,"####",3)') ALTER COLUMN [Phone Number] ADD MASKED WITH (FUNCTION = 'partial(5,"XXXXXXX",0)') ALTER COLUMN [Social Security Number] ADD MASKED WITH (FUNCTION = 'partial(0,"XXX-XX-",4)')
- 21. Dynamic Data Masking– reguły maskujące • Funkcja Random: • Maskowanie wartości numerycznych • Pozwala określić zakres, z którego będą losowane wartości maskujące Przykłady: Account_Number bigint MASKED WITH (FUNCTION = 'random([start range], [end range])') ALTER COLUMN [Month] ADD MASKED WITH (FUNCTION = 'random(1, 12)')
- 22. Dynamic Data Masking- uprawnienia • Zakładanie maskowania dla tabeli: • ALTER ANY MASK • ALTER • Pobieranie danych: • SELECT – dla tabeli • UNMASK – pozwoli użytkownikowi odczytać dane bez użycia maskowania
- 23. Dynamic Data Masking– przypadki użycia • DDM nie zapobiega operacji UPDATE • SELECT INTO / INSERT INTO • SQL Server Import and Export
- 24. DEMO #4 Dynamic DataMasking
- 25. Dynamic Data Masking- ograniczenia • Reguły maskowania nie mogą być zdefiniowane dla kolumn: • Zaszyfrowanych (Always Encrypted) • FILESTREAM • COLUMN_SET
- 26.
- 27. Always Encrypted • Przeznaczonedo zabezpieczania danych wrażliwych • PESEL, Numer karty kredytowej, NIN, SSN • Umożliwia podział ról pomiędzy: • Właściciela danych (z pełnymi prawami) • Administratora danych (bez prawa wglądu) • Dostępne: SQL Server 2016 (CTP 3), Azure SQL Database (Preview) • Transparentne dla aplikacji klienckiej
- 28. Always Encrypted • Szyfrowaniewybranych kolumn w tabeli • Aplikacja kliencka i SQL Server zarządzają kluczami kryptograficznymi • Aby odszyfrować dane potrzebujesz właściwy klucz • DBA również nie posiada dostępu do zaszyfrowanych danych • Dane są zawsze zaszyfrowane (Always Encrypted): • Na nośniku fizycznym (dysk) • Pamięci serwera • W trakcie transportu do Klienta (sieć)
- 29. Always Encrypted –przypadki użycia • Client and Data On-Premises • Client On-Premises with Data in Azure • Client and Data in Azure
- 30. Always Encrypted –metody szyfrowania Deterministyczne (deterministic) + Możliwe operacje: • Indeksowanie, • Grupowanie, • Filtrowanie, • Złączenia (JOIN) - Ryzyko odczytania danych Losowe (randomized) - Możliwe operacje: Żadne + Bardziej bezpieczna
- 31. Always Encrypted –klucze • Column encryption keys • Column master keys
- 32. Always Encrypted –biblioteka Kliencka • Automatyczne szyfrowanie danych przez aplikacje klienckie • Brak konieczności zmian w aplikacji klienckiej (oprócz połączenia) • Nowszy sterownik ADO.NET (SqlClient w .NET Framework 4.6) • Varbinary(max) gdy AE wyłączony po stronie Klienta
- 33.
- 34. Always Encrypted -ograniczenia • xml, • rowversion, • image, • ntext / text, • sql_variant, • hierarchyid, • geography, geometry, • typy użytkownika.
- 35. Migracja baz/tabel donowej wersji • DEMO: Import/Export • ADO.NET / .NET Framework 4.6
- 36. Always Encrypted -Widoki systemowe • sys.column_master_key_definitions • sys.column_encryption_keys • sys.column_encryption_key_values • sys.columns
- 37. Pytanie Jakie wyniki możnauzyskać stosując funkcję Custom String w Dynamic Data Masking na kolumnie PESEL (string)? a) 7810XXXX990 b) XXXX9799XXX c) #########90 d) Wszystkie powyższe
- 38. Odpowiedź Jakie wyniki możnauzyskać stosując funkcję Custom String w Dynamic Data Masking na kolumnie PESEL (string)? a) 7810XXXX990 b) XXXX9799XXX c) #########90 d) Wszystkie powyższe
- 39.
- 40. Źródła • https://msdn.microsoft.com/en-us/library/mt147923.aspx • https://msdn.microsoft.com/en-gb/library/mt163865.aspx •http://blogs.microsoft.com/next/2015/05/27/always-encrypted-sql- server-2016-includes-new-advances-that-keeps-data-safer/ • https://msdn.microsoft.com/en-us/library/dn765131.aspx
- 41. RLS - materiały •MSDN - Row-Level Security https://msdn.microsoft.com/en-us/library/dn765131.aspx • CodePlex - RLS Samples https://rlssamples.codeplex.com/ • SQL Server Security Blog http://blogs.msdn.com/b/sqlsecurity/ • Channel 9 – Data Exposed • SQL Server 2016 Row Level Security https://channel9.msdn.com/Shows/Data-Exposed/SQL-Server-2016-Row-Level-Security • Row Level Security Updates https://channel9.msdn.com/Shows/Data-Exposed/Row-Level-Security-Updates • SQL Server 2016 CTP 2 oczami MVP (Marcin Szeliga) - Nowości z zakresu bezpieczeństwa https://channel9.msdn.com/Series/SQL-Server-2016-CTP-2-oczami-MVP/Nowosci-z- zakresu-bezpieczenstwa
- 42. Always Encrypted -materiały • SQL Server Security Blog http://blogs.msdn.com/b/sqlsecurity/ • Channel 9 – Data Exposed - SQL Server 2016 Always Encrypted https://channel9.msdn.com/Shows/Data-Exposed/SQL-Server-2016- Always-Encrypted • SQL Server 2016 CTP 2 oczami MVP (Marcin Szeliga) - Nowości z zakresu bezpieczeństwa https://channel9.msdn.com/Series/SQL-Server-2016-CTP-2-oczami- MVP/Nowosci-z-zakresu-bezpieczenstwa • Overview and Roadmap for Microsoft SQL Server Security. http://channel9.msdn.com/Events/Ignite/2015/BRK2570
- 43.
Editor's Notes
- #2 SQL Server 2016 – nowości w zakresie bezpieczeństwa Przechowywanie wrażliwych danych w bazie często wzbudza wiele wątpliwości. Co w sytuacji kiedy użytkownik uzyska bezpośredni dostęp i będzie mógł wykonać zapytanie zwracające więcej danych niż zobaczyłby w aplikacji? Spośród zapowiedzianych nowości – SQL Server 2016 przynosi również ulepszenia w obszarze zabezpieczeń, które przedstawimy podczas naszej sesji. Row Level Security – zabezpieczanie danych na poziomie wierszy to funkcjonalność na którą czeka wielu deweloperów T-SQL. Do tej pory stali oni przed koniecznością ukrywania części danych za pomocą widoków filtrujących źródłowe dane. SQL Server 2016 pozwala na ukrycie części rekordów przed użytkownikiem nawet w sytuacji w której ma on bezpośredni dostęp do tabel. Chcesz pozwolić użytkownikom odczytywać wszystkie rekordy – ale w przypadku kolumn takich jak numer PESEL czy numer karty kredytowej chcesz aby mogli wyświetlić tylko kilka pierwszych cyfr? Umożliwi to kolejna nowa omawiana funkcjonalność – Dynamic Data Masking.
- #10 Creating, altering, or dropping security policies requires the ALTER ANY SECURITY POLICY permission. Creating or dropping a security policy requires ALTER permission on the schema. Additionally the following permissions are required for each predicate that is added: SELECT and REFERENCES permissions on the function being used as a predicate. REFERENCES permission on the target table being bound to the policy. REFERENCES permission on every column from the target table used as arguments. Security policies apply to all users, including dbo users in the database. Dbo users can alter or drop security policies however their changes to security policies can be audited.
- #16 Topic Status: Some information in this topic is preview and subject to change in future releases. Preview information describes new features or changes to existing features in SQL Server 2016 Community Technology Preview 3 (CTP 3.0). Dynamic data masking limits sensitive data exposure by masking it to non-privileged users. Dynamic data masking helps prevent unauthorized access to sensitive data by enabling customers to designate how much of the sensitive data to reveal with minimal impact on the application layer. It’s a data protection feature that hides the sensitive data in the result set of a query over designated database fields, while the data in the database is not changed. Dynamic data masking is easy to use with existing applications, since masking rules are applied in the query results. Many applications can mask sensitive data without modifying existing queries. For example, a call center support person may identify callers by several digits of their social security number or credit card number, but those data items should not be fully exposed to the support person. A masking rule can be defined that masks all but the last four digits of any social security number or credit card number in the result set of any query. For another example, by using the appropriate data mask to protect personally identifiable information (PII) data, a developer can query production environments for troubleshooting purposes without violating compliance regulations. The purpose of dynamic data masking is to limit exposure of sensitive data, preventing users who should not have access to the data from viewing it. Dynamic data masking does not aim to prevent database users from connecting directly to the database and running exhaustive queries that expose pieces of the sensitive data. Dynamic data masking is complementary to other SQL Server security features (auditing, encryption, row level security…) and it is highly recommended to use this feature in conjunction with them in addition in order to better protect the sensitive data in the database. Dynamic data masking is available in SQL Server 2016 Community Technology Preview 3 (CTP 3.0). For Azure SQL Database, see Get started with SQL Database Dynamic Data Masking (Azure Preview portal). https://msdn.microsoft.com/en-us/library/mt130841.aspx
- #17 For example, a call center support person may identify callers by several digits of their social security number or credit card number, but those data items should not be fully exposed to the support person. A masking rule can be defined that masks all but the last four digits of any social security number or credit card number in the result set of any query. For another example, by using the appropriate data mask to protect personally identifiable information (PII) data, a developer can query production environments for troubleshooting purposes without violating compliance regulations. https://msdn.microsoft.com/en-us/library/mt130841.aspx
- #18 The purpose of dynamic data masking is to limit exposure of sensitive data, preventing users who should not have access to the data from viewing it. Dynamic data masking does not aim to prevent database users from connecting directly to the database and running exhaustive queries that expose pieces of the sensitive data. Dynamic data masking is complementary to other SQL Server security features (auditing, encryption, row level security…) and it is highly recommended to use this feature in conjunction with them in addition in order to better protect the sensitive data in the database. https://msdn.microsoft.com/en-us/library/mt130841.aspx
- #19 Full masking according to the data types of the designated fields. [CTP2.1] For string data types, use XXXX or fewer Xs if the size of the field is less than 4 characters (char, nchar, varchar, nvarchar, text, ntext). The max size is not yet supported. [CTP2.0] String data types supported are: (nchar, nvarchar) For numeric data types use a zero value (bigint, bit, decimal, int, money, numeric, smallint,smallmoney, tinyint, float, real). For date and time data types use 01.01.2000 00:00:00.0000000 (date, datetime2, datetime,datetimeoffset, smalldatetime, time). [CTP2.1] For binary data types use a single byte of ASCII value 0 (binary, varbinary, image). Example column definition syntax: Phone# varchar(12) MASKED WITH (FUNCTION = 'default()') NULL Example alter syntax: ALTER COLUMN Gender ADD MASKED WITH (FUNCTION = 'default()')
- #20 Full masking according to the data types of the designated fields. [CTP2.1] For string data types, use XXXX or fewer Xs if the size of the field is less than 4 characters (char, nchar, varchar, nvarchar, text, ntext). The max size is not yet supported. [CTP2.0] String data types supported are: (nchar, nvarchar) For numeric data types use a zero value (bigint, bit, decimal, int, money, numeric, smallint,smallmoney, tinyint, float, real). For date and time data types use 01.01.2000 00:00:00.0000000 (date, datetime2, datetime,datetimeoffset, smalldatetime, time). [CTP2.1] For binary data types use a single byte of ASCII value 0 (binary, varbinary, image). Example column definition syntax: Phone# varchar(12) MASKED WITH (FUNCTION = 'default()') NULL Example alter syntax: ALTER COLUMN Gender ADD MASKED WITH (FUNCTION = 'default()')
- #21 Full masking according to the data types of the designated fields. [CTP2.1] For string data types, use XXXX or fewer Xs if the size of the field is less than 4 characters (char, nchar, varchar, nvarchar, text, ntext). The max size is not yet supported. [CTP2.0] String data types supported are: (nchar, nvarchar) For numeric data types use a zero value (bigint, bit, decimal, int, money, numeric, smallint,smallmoney, tinyint, float, real). For date and time data types use 01.01.2000 00:00:00.0000000 (date, datetime2, datetime,datetimeoffset, smalldatetime, time). [CTP2.1] For binary data types use a single byte of ASCII value 0 (binary, varbinary, image). Example column definition syntax: Phone# varchar(12) MASKED WITH (FUNCTION = 'default()') NULL Example alter syntax: ALTER COLUMN Gender ADD MASKED WITH (FUNCTION = 'default()')
- #22 Full masking according to the data types of the designated fields. [CTP2.1] For string data types, use XXXX or fewer Xs if the size of the field is less than 4 characters (char, nchar, varchar, nvarchar, text, ntext). The max size is not yet supported. [CTP2.0] String data types supported are: (nchar, nvarchar) For numeric data types use a zero value (bigint, bit, decimal, int, money, numeric, smallint,smallmoney, tinyint, float, real). For date and time data types use 01.01.2000 00:00:00.0000000 (date, datetime2, datetime,datetimeoffset, smalldatetime, time). [CTP2.1] For binary data types use a single byte of ASCII value 0 (binary, varbinary, image). Example column definition syntax: Phone# varchar(12) MASKED WITH (FUNCTION = 'default()') NULL Example alter syntax: ALTER COLUMN Gender ADD MASKED WITH (FUNCTION = 'default()')
- #24 Best Practices and Common Use Cases Creating a mask on a column does not prevent updates to that column. So although users receive masked data when querying the masked column, the same users can update the data if they have write permissions. A proper access control policy should still be used to limit update permissions. Using SELECT INTO or INSERT INTO to copy data from a masked column into another table results in masked data in the target table. Dynamic Data Masking is applied when running SQL Server Import and Export. A database containing masked columns will result in a backup file with masked data (assuming it is exported by a user without UNMASKprivileges), and the imported database will contain statically masked data.
- #26 Limitations and Restrictions A masking rule cannot be defined for the following column types: Encrypted columns (Always Encrypted) FILESTREAM COLUMN_SET
- #28 Pozwala zaszyfrować aplikacji Klienta dane (wrażliwe) i nigdy nie zdradzać kluczy szyfrujących silnikowi bazy danych. https://msdn.microsoft.com/en-gb/library/mt163865.aspx Always Encrypted pozwala Klientom przechowywać wrażliwe dane na zewnątrz firmy (poza bezpośrednią kontrolą) w sposób zapewniający brak dostępu jakiemukolwiek z administratorów baz danych (on-premises lub Azure), innych operatorów lub wysoko-uprzywilejowanych użytkowników. To pozwala w końcu organizacjom na szyfrowanie danych i przechowywanie w Azure, delegowanie obowiązków administratorów firmom trzecim lub redukcję wymaganych zabezpieczeń przez własnych DBA. AE jest transparentne dla aplikacji. Sterownik zainstalowany na komputerze Klienta realizuje automatycznie szyfrowanie i deszyfrowanie danych wrażliwych za pomocą aplikacji Klienta. Sterownik szyfruje wrażliwe kolumny zanim pakiety z danymi zostaną przekazane do silnika bazy danych, który automatycznie modyfikuje zapytanie tak aby semantyczna zgodność została zachowana. Analogicznie, sterownik deszyfruje dane przechowywane w szyfrowanych kolumnach gdy zawarte są w zapytaniu.
- #30 1. Client and Data On-Premises Aplikacja Klienta i SQL Server znajdują się w lokalizacji Klienta (On-Premise). Klient chce zatrudnić zewnętrzną firmą do administracji serwerem SQL. Aby zabezpieczyć wrażliwe dane Klient zastosuje AE i podział obowiązków pomiędzy administratora bazy danych i administratora aplikacji. Klient zachowa wartości kluczy AE jako czysty tekst w zaufanym repozytorium kluczy, do którego aplikacja Klienta będzie miała dostęp. Administrator bazy danych nie będzie miał dostępu do kluczy, zatem również możliwości deszyfrowania danych wrażliwych przechowywanych w bazie danych, do której ma bezpośredni dostęp. 2. Client On-Premises with Data in Azure Aplikacja Klienta w jego lokalizacji. Aplikacja wykonuje operacje na danych wrażliwych przechowywanych w chmurze lub na SQL Serwerze zainstalowanym na maszynie wirtualnej w Azure. Klient używa AE oraz przechowuje klucze kryptograficzne w zaufanym magazynie hostowanym na miejscu (on-premise) aby mieć pewność, że administatorzy chmury nie mają dostępu do danych wrażliwych. (scenariusz dla wyznawców teorii spiskowych) 3. Client and Data in Azure Klient posiada aplikację hostowaną w Microsoft Azure (worker role lub web role), która pracuje z danymi wrażliwymi również przechowywanymi w Azure. Klient używa AE aby zmniejszyć zakres przestrzeni narażonej na atak.
- #31 Selecting Deterministic or Randomized Encryption Always Encrypted supports two types of encryption: randomized encryption and deterministic encryption. Deterministic encryption uses a method which always generates the same encrypted value for any given plain text value. Using deterministic encryption allows grouping, filtering by equality, and joining tables based on encrypted values, but can also allow unauthorized users to guess information about encrypted values by examining patterns in the encrypted column. This weakness is increased when there is a small set of possible encrypted values, such as True/False, or North/South/East/West region. Deterministic encryption must use a column collation with a binary2 sort order for character columns. Randomized encryption uses a method that encrypts data in a less predictable manner. Randomized encryption is more secure, but prevents equality searches, grouping, indexing, and joining on encrypted columns. Use deterministic encryption for columns that will be used as search or grouping parameters, for example a government ID number. Use randomized encryption, for data such as confidential investigation comments, which are not grouped with other records and are not used to join tables.
- #32 Always Encrypted Keys Always Encrypted uses keys of two types: column encryption keys and column master keys. Column master keys are protecting keys used to encrypt column encryption keys. Column master keys must be stored in a trusted key store. Information about column master keys, including their location, is stored in the database in system catalog views. Column encryption keys are used to encrypt sensitive data stored in database columns. All values in a column can be encrypted using a single column encryption key. Encrypted values of column encryption keys are stored in the database in system catalog views. You should store column encryption keys in a secure/trusted location for backup.
- #33 Always Encrypted Driver An Always Encrypted enabled driver plays the critical role in Always Encrypted, as it ensures the transparency of encryption to client applications. The driver calls a server (makes a roundtrip) for each query with parameters to retrieve information on how to encrypt query parameter and whether they should be encrypted. The driver calls a key store provider to decrypt the encrypted column encryption key value. The resultant plaintext column encryption key values are cached. Query results containing data from encrypted columns are accompanied by encryption metadata to enable transparent decryption. When an Always Encrypted enabled client driver queries encrypted columns, SQL Server sends the information about encryption settings for the queried columns, including encryption type information, the encrypted value of column encryption keys used to protect data in the queried columns, and the location of the corresponding column master keys. The driver uses that information to: Contact the key store containing each column master key and decrypt column encryption keys, encrypted with the given master key. Encrypt query parameters that correspond to encrypted columns and decrypt the query results originating from encrypted columns, using the corresponding column encryption keys. A column master key store provider is a client-side software component that encapsulates a key store containing the column master key. Providers for common types of key stores are available in client side driver libraries from Microsoft or as standalone downloads. You can also implement your own provider. For more information including the list of available providers, see CREATE COLUMN MASTER KEY (Transact-SQL) and Always Encrypted (client development). .NET Framework 4.6 must be installed in the machine hosting your client application. .NET Framework 4.6 is available with SQL Server 2016 Community Technology Preview 3 (CTP 3.0) and is installed with SQL Server Management Studio. If your client application runs on a machine that does not contain SQL Server 2016 Community Technology Preview 3 (CTP 3.0) Management Studio, you need to install at least .NET Framework 4.6 (for details, see .NET Framework 4.6). .NET Framework 4.6.1 is required to use new providers and the bulk API flag. If Always Encrypted is not enabled on the client side, the driver returns encrypted values and the values have the varbinary(max) data type.