Udostępnij za pośrednictwem

Funkcja Always Encrypted z użyciem bezpiecznych enklaw

  • Artykuł

Dotyczy: SQL Server 2019 (15.x) i późniejszych wersji – tylko Windows Azure SQL Database

Funkcja Always Encrypted z bezpiecznymi enklawami rozszerza możliwości obliczeń poufnych Always Encrypted przez umożliwienie szyfrowania danych na miejscu i tworzenie bardziej zaawansowanych poufnych zapytań. Funkcja Always Encrypted z bezpiecznymi enklawami jest dostępna w programie SQL Server 2019 (15.x) i nowszych wersjach, a także w usłudze Azure SQL Database.

Wprowadzona w usłudze Azure SQL Database w 2015 r. i w programie SQL Server 2016 (13.x) funkcja Always Encrypted chroni poufność poufnych danych przed złośliwym oprogramowaniem i wysoce uprzywilejowanymi nieautoryzowanymi użytkownikami: Administratorzy bazy danych (DBA), administratorzy komputerów, Administratorzy chmury lub każdy inny, kto legalny dostęp do wystąpień serwera, sprzętu itp., ale nie powinien mieć dostępu do niektórych lub wszystkich rzeczywistych danych.

Bez ulepszeń omówionych w tym artykule funkcja Always Encrypted chroni dane, szyfrując je po stronie klienta i nigdy nie zezwalać na pojawienie się danych lub odpowiednich kluczy kryptograficznych w postaci zwykłego tekstu wewnątrz aparatu bazy danych. W związku z tym funkcjonalność zaszyfrowanych kolumn wewnątrz bazy danych jest poważnie ograniczona. Jedynymi operacjami, które aparat bazy danych może wykonywać na zaszyfrowanych danych, są porównania równości (dostępne tylko w przypadku deterministycznego szyfrowania). Wszystkie inne operacje, w tym operacje kryptograficzne (początkowe szyfrowanie danych lub rotacja kluczy) i bogatsze zapytania (na przykład dopasowywanie wzorca) nie są obsługiwane w bazie danych. Użytkownicy muszą przenieść swoje dane poza bazę danych, aby wykonać te operacje po stronie klienta.

Funkcja Always Encrypted z bezpiecznymi enklawami rozwiązuje te ograniczenia, zezwalając na niektóre obliczenia na danych w postaci zwykłego tekstu wewnątrz bezpiecznej enklawy po stronie serwera. Bezpieczna enklawa to chroniony region pamięci w procesie silnika bazy danych. Bezpieczna enklawa jest wyświetlana jako nieprzezroczyste pole dla pozostałej części mechanizmu bazy danych oraz innych procesów na maszynie hostingowej. Nie ma możliwości wyświetlania żadnych danych ani kodu wewnątrz enklawy z zewnątrz, nawet przy użyciu debugera. Te właściwości sprawiają, że bezpieczna enklawa jest zaufanym środowiskiem wykonywania, które może bezpiecznie mieć dostęp do kluczy kryptograficznych i poufnych danych w postaci jawnej, bez naruszania poufności danych.

Funkcja Always Encrypted używa bezpiecznych enklaw, jak pokazano na poniższym diagramie:

Diagram przepływu danych dla funkcji Always Encrypted.

Podczas analizowania instrukcji Transact-SQL przesłanej przez aplikację aparat bazy danych określa, czy instrukcja zawiera jakiekolwiek operacje na zaszyfrowanych danych, które wymagają użycia bezpiecznej enklawy. Dla takich oświadczeń:

  • Sterownik klienta wysyła klucze szyfrowania kolumn wymagane dla operacji do bezpiecznej enklawy (za pośrednictwem bezpiecznego kanału) i przesyła instrukcję do wykonania.

  • Podczas przetwarzania instrukcji aparat bazy danych deleguje operacje kryptograficzne lub obliczenia w zaszyfrowanych kolumnach do bezpiecznej enklawy. W razie potrzeby enklawa odszyfrowuje dane i wykonuje obliczenia w postaci zwykłego tekstu.

Podczas przetwarzania instrukcji, zarówno dane, jak i klucze szyfrowania kolumn, nie są ujawniane w formacie tekstu jawnego w aparacie bazy danych poza bezpieczną enklawą.

Obsługiwane sterowniki klienta

Aby używać funkcji Always Encrypted z bezpiecznymi enklawami, aplikacja musi używać sterownika klienta obsługującego tę funkcję. Skonfiguruj aplikację i sterownik klienta, aby włączyć obliczenia enklawy i atestację enklawy (zobacz sekcję Secure enclave attestation poniżej). Aby uzyskać szczegółowe informacje, w tym listę obsługiwanych sterowników klientów, zobacz Develop Applications Using Always Encrypted.

Obsługiwane technologie enklawy

Funkcja Always Encrypted obsługuje następujące technologie enklawy (lub typy enklawy):

Typ enklawy dostępnej dla bazy danych zależy od produktu SQL hostowania go (Azure SQL Database vs. SQL Server) i (w przypadku usługi Azure SQL Database) konfiguracji bazy danych.

  • W programie SQL Server 2019 (15.x) i nowszych funkcja Always Encrypted obsługuje enklawy VBS. (Enklawy Intel SGX nie są obsługiwane).

  • W usłudze Azure SQL Database baza danych może używać enklawy Intel SGX lub enklawy VBS, w zależności od sprzętu skonfigurowanego do uruchamiania bazy danych:

    • Bazy danych korzystające z konfiguracji sprzętowej serii DC (dostępnej w modelu zakupów wirtualnych rdzeni ) używają enklaw Intel SGX.
    • Bazy danych korzystające z konfiguracji innej niż seria DC z modelem zakupowym opartym na rdzeniach wirtualnych oraz bazy danych korzystające z modelu zakupowego jednostek DTU można skonfigurować do używania enklaw VBS.

    Nota

    Enklawy VBS są obecnie dostępne we wszystkich regionach usługi Azure SQL Database z wyjątkiem: Jio India Central.

Zobacz sekcję Zagadnienia dotyczące zabezpieczeń, aby uzyskać ważne informacje na temat ochrony na poziomie zapewnianych przez każdy typ enklawy.

Zabezpieczone potwierdzenie enklawy

Zaświadczanie enklawy to mechanizm ochrony w głębi systemu, który może pomóc wykrywać ataki, które obejmują manipulowanie kodem enklawy lub jego środowiskiem przez złośliwych administratorów.

Zaświadczenie enklawy umożliwia aplikacji klienckiej ustanowienie zaufania z bezpieczną enklawą dla bazy danych, z którą jest połączona, zanim zacznie używać enklawy do przetwarzania poufnych danych. Przepływ pracy potwierdzania sprawdza, czy enklawa jest prawdziwą enklawą VBS lub Intel SGX, a kod uruchomiony wewnątrz niej jest prawdziwą biblioteką enklawy podpisaną przez Microsoft dla funkcji Always Encrypted. Podczas zaświadczania zarówno sterownik klienta w aplikacji, jak i aparat bazy danych komunikują się z zewnętrzną usługą zaświadczania przy użyciu punktu końcowego określonego przez klienta.

Funkcja Always Encrypted może używać jednej z dwóch usług zaświadczania:

Aby włączyć funkcję Always Encrypted z bezpiecznymi enklawami dla aplikacji, należy ustawić protokół zaświadczania w konfiguracji sterownika klienta w aplikacji. Wartość protokołu zaświadczania określa, czy 1) aplikacja kliencka będzie używać zaświadczania, a jeśli tak, 2) określa typ usługi zaświadczania, która będzie używana. W poniższej tabeli przedstawiono obsługiwane protokoły zaświadczania dla prawidłowych kombinacji typu produktu SQL i enklawy:

Produkt hostingowy Typ enklawy Obsługiwane protokoły zaświadczania
SQL Server 2019 (15.x) i nowsze Enklawy VBS HGS, brak zaświadczania
Azure SQL Database Enklawy SGX (bazy danych serii DC) Zaświadczenie platformy Microsoft Azure
Azure SQL Database Enklawy VBS Brak zaświadczania

Kilka ważnych kwestii, które należy podkreślić:

  • Zaświadczanie enklaw VBS w programie SQL Server 2019 (15.x) i nowszych wymaga usługi HGS. Można również używać enklaw VBS bez atestacji (wymagane są najnowsze sterowniki klienckie).
  • W przypadku enklaw Intel SGX (w bazach danych serii DC) w usłudze Azure SQL Database atestacja jest obowiązkowa i wymaga usługi Microsoft Azure Attestation.
  • Enklawy VBS w usłudze Azure SQL Database nie obsługują zaświadczania.

Aby uzyskać więcej informacji, zobacz:

Terminologia

Klucze z obsługą enklawy

Funkcja Always Encrypted z bezpiecznymi enklawami wprowadza koncepcję kluczy obsługujących enklawy.

  • klucz główny kolumny z funkcją enklawy — klucz master kolumny, który ma właściwość ENCLAVE_COMPUTATIONS określoną w obiekcie metadanych klucza kolumny master wewnątrz bazy danych. Obiekt metadanych klucza kolumny master musi również zawierać prawidłowy podpis właściwości metadanych. Aby uzyskać więcej informacji, zobacz CREATE COLUMN MASTER KEY (Transact-SQL)
  • klucz szyfrowania kolumny obsługiwany przez enklawę — klucz szyfrowania kolumny zaszyfrowany przy użyciu klucza kolumny z obsługą enklawy master. Tylko klucze szyfrowania kolumn z obsługą enklawy mogą być używane do obliczeń wewnątrz bezpiecznej enklawy.

Aby uzyskać więcej informacji, zobacz Zarządzanie kluczami dla funkcji Always Encrypted z bezpiecznymi enklawami.

Kolumny z obsługą enklawy

Kolumna z obsługą enklawy to kolumna bazy danych zaszyfrowana przy użyciu klucza szyfrowania dla kolumn z obsługą enklawy.

Funkcje przetwarzania poufnego dla kolumn obsługiwanych przez enklawy

Dwie kluczowe zalety funkcji Always Encrypted z bezpiecznymi enklawami to szyfrowanie w miejscu i zaawansowane poufne zapytania.

Szyfrowanie w miejscu

Szyfrowanie w miejscu umożliwia wykonywanie operacji kryptograficznych w kolumnach bazy danych wewnątrz bezpiecznej enklawy bez przenoszenia danych poza bazą danych. Szyfrowanie w miejscu zwiększa wydajność i niezawodność operacji kryptograficznych. Szyfrowanie na miejscu można wykonać przy użyciu instrukcji ALTER TABLE (Transact-SQL).

Operacje kryptograficzne obsługiwane w miejscu to:

  • Szyfrowanie kolumny tekstowej przy użyciu klucza szyfrowania kolumn obsługującego enklawę.
  • Ponowne szyfrowanie zaszyfrowanej kolumny z włączoną enklawą w celu:
    • Obracanie klucza szyfrowania kolumny — ponownie szyfruj kolumnę przy użyciu nowego klucza szyfrowania kolumn z obsługą enklawy.
    • Zmień typ szyfrowania kolumny z obsługą enklawy, na przykład z deterministycznej na losową.
  • Odszyfrowywanie danych przechowywanych w kolumnie obsługiwanej przez enklawę (przekształcanie kolumny na kolumnę w formie tekstu jawnego).

Szyfrowanie na miejscu jest dozwolone zarówno przy użyciu szyfrowania deterministycznego, jak i losowego, o ile klucze szyfrowania kolumn używane w operacji kryptograficznej są aktywowane w enklawie.

Zapytania poufne

Notatka

Program SQL Server 2022 (16.x) dodaje dodatkową obsługę zapytań poufnych przy użyciu operacji JOIN, GROUP BY i ORDER BY w zaszyfrowanych kolumnach.

Zapytania poufne to zapytania DML, które obejmują operacje na kolumnach obsługiwanych przez enklawę, wykonywane w bezpiecznej enklawie.

Operacje obsługiwane wewnątrz bezpiecznych enklaw są następujące:

Operacja Azure SQL Database SQL Server 2022 (16.x) SQL Server 2019 (15.x)
Operatory porównań Obsługiwane Obsługiwane Obsługiwane
BETWEEN (Transact-SQL) Obsługiwane Obsługiwane Wsparcie
IN (Transact-SQL) Obsługiwane Obsługiwane Obsługiwane
LIKE (Transact-SQL) Obsługiwane Wspierane Wspierane
DISTINCT Wspierane Wspierane Wspierane
łączy się z Obsługiwane Obsługiwane Obsługiwane są tylko łączenia zagnieżdżonych pętli
SELECT — klauzula ORDER BY (Transact-SQL) Obsługiwane Obsługiwane Nieobsługiwane
SELECT — GROUP BY — Transact-SQL Wspierane Obsługiwane Nieobsługiwane

Notatka

Powyższe operacje wewnątrz bezpiecznych enklaw wymagają losowego szyfrowania. Szyfrowanie deterministyczne nie jest obsługiwane. Porównanie równości pozostaje operacją dostępną dla kolumn korzystających z szyfrowania deterministycznego.

Poziom zgodności bazy danych powinien być ustawiony na program SQL Server 2022 (160) lub nowszy.

W usłudze Azure SQL Database i w programie SQL Server 2022 (16.x) poufne zapytania korzystające z enklaw w kolumnie ciągu znaków (char, nchar) wymagają użycia sortowania punktu kodu binarnego (_BIN2) lub sortowania UTF-8. W programie SQL Server 2019 (15.x) wymagane jest sortowanie a_BIN2.

Aby uzyskać więcej informacji, zobacz instrukcje Uruchamianie Transact-SQL instrukcji z wykorzystaniem bezpiecznych enklaw.

Indeksy w kolumnach z obsługą enklawy

Indeksy nieklastrowane można tworzyć w kolumnach z obsługą enklawy przy użyciu szyfrowania losowego w celu szybszego uruchamiania poufnych zapytań DML przy użyciu bezpiecznej enklawy.

Aby zapewnić, że indeks w kolumnie zaszyfrowanej przy użyciu szyfrowania losowego nie wycieknie poufnych danych, wartości kluczy w strukturze danych indeksu (B-tree) są szyfrowane i sortowane na podstawie ich wartości w postaci zwykłego tekstu. Sortowanie według wartości zwykłego tekstu jest również przydatne do przetwarzania zapytań wewnątrz enklawy. Gdy wykonawca zapytania w aparacie bazy danych używa indeksu na zaszyfrowanej kolumnie do obliczeń wewnątrz enklawy, przeszukuje ten indeks w poszukiwaniu określonych wartości przechowywanych w kolumnie. Każde wyszukiwanie może obejmować wiele porównań. Funkcja wykonawcza zapytania deleguje każde porównanie do enklawy, która odszyfrowuje zarówno wartość przechowywaną w kolumnie, jak i zaszyfrowaną wartość klucza indeksu, aby je porównać. Enklawa wykonuje porównanie w postaci zwykłego tekstu i zwraca wynik porównania do funkcji wykonawczej.

Tworzenie indeksów w kolumnach, które używają szyfrowania losowego i nie są obsługiwane przez enklawę, pozostaje nieobsługiwane.

Indeks w kolumnie używającej szyfrowania deterministycznego jest sortowany na podstawie szyfrowania (nie zwykłego tekstu), niezależnie od tego, czy kolumna jest włączona w enklawie, czy nie.

Aby uzyskać więcej informacji, zobacz Tworzenie i używanie indeksów na kolumnach przy użyciu funkcji Zawsze Szyfrowane z bezpiecznymi enklawami. Aby uzyskać ogólne informacje na temat działania indeksowania w silniku bazy danych, zobacz artykuł Indeksy klastrowane i nieklastrowane opisane.

Odzyskiwanie bazy danych

Jeśli wystąpienie programu SQL Server ulegnie awarii, jego bazy danych mogą pozostać w stanie, w którym pliki danych mogą zawierać zmiany wynikające z niekompletnych transakcji. Po uruchomieniu wystąpienia inicjowany jest proces o nazwie przywracania bazy danych, który polega na wycofywaniu każdej niekompletnej transakcji znalezionej w dzienniku transakcji, co zapewnia zachowanie integralności bazy danych. Jeśli niekompletna transakcja dokonała jakichkolwiek zmian w indeksie, te zmiany również muszą zostać cofnięte. Na przykład niektóre wartości klucza w indeksie mogą wymagać usunięcia lub ponownego umieszczenia.

Ważny

Microsoft zdecydowanie zaleca włączenie przyspieszonego odzyskiwania bazy danych (ADR) dla bazy danych, przed utworzeniem pierwszego indeksu w kolumnie z włączoną obsługą enklawy, zaszyfrowanej szyfrowaniem losowym. Reguła ADR jest domyślnie włączona w usługach Azure SQL Database i Azure SQL Managed Instance. Reguła ADR jest dostępna, ale nie jest domyślnie włączona w programie SQL Server 2019 (15.x) i nowszych wersjach.

W przypadku tradycyjnego procesu odzyskiwania bazy danych (który opiera się na modelu odzyskiwania ARIES), aby cofnąć zmianę indeksu, silnik bazy danych musi poczekać, aż aplikacja udostępni klucz szyfrowania kolumny do enklawy, co może zająć dużo czasu. Przyspieszone odzyskiwanie bazy danych znacznie zmniejsza liczbę operacji cofania, które należy odroczyć, ponieważ klucz szyfrowania kolumny nie jest dostępny w pamięci podręcznej wewnątrz enklawy. W związku z tym znacznie zwiększa dostępność bazy danych, minimalizując szansę na zablokowanie nowej transakcji. Po włączeniu ADR, Silnik bazy danych może nadal potrzebować klucza szyfrowania kolumny, aby ukończyć czyszczenie starych wersji danych, jednak odbywa się to w postaci zadania w tle, które nie wpływa na dostępność bazy danych ani transakcji użytkownika. W dzienniku błędów mogą pojawić się komunikaty o błędach wskazujące, że operacje czyszczenia zakończyły się niepowodzeniem z powodu braku klucza szyfrowania kolumny.

Zagadnienia dotyczące zabezpieczeń

Następujące kwestie związane z zabezpieczeniami odnoszą się do funkcji Always Encrypted z bezpiecznymi enklawami.

  • Enklawy VBS pomagają chronić dane przed atakami wewnątrz maszyny wirtualnej. Nie zapewniają one jednak żadnej ochrony przed atakami przy użyciu uprzywilejowanych kont systemowych pochodzących z hosta. Enklawy Intel SGX chronią dane przed atakami pochodzącymi zarówno z systemu operacyjnego gościa, jak i systemu operacyjnego hosta.
  • Korzystanie z poświadczenia enklawy jest zalecane, jeśli jest dostępne dla Twojego środowiska i jeśli martwisz się o ochronę danych przed atakami użytkowników z dostępem administracyjnym na poziomie systemu operacyjnego do maszyny, na której działa Twoja baza danych. Jeśli używasz zaświadczania, musisz upewnić się, że usługa zaświadczania i jej konfiguracja są zarządzane przez zaufanego administratora. Ponadto obie obsługiwane usługi zaświadczania oferują różne zasady i tryby zaświadczania, z których niektóre wykonują minimalną weryfikację enklawy i jej środowiska oraz są przeznaczone do testowania i programowania. Dokładnie postępuj zgodnie z wytycznymi specyficznymi dla usługi zaświadczania, aby upewnić się, że używasz zalecanych konfiguracji i zasad dla wdrożeń produkcyjnych.
  • Szyfrowanie kolumny z wykorzystaniem losowego szyfrowania i klucza szyfrowania kolumn z obsługą enklawy może prowadzić do ujawnienia kolejności danych przechowywanych w kolumnie, ponieważ takie kolumny umożliwiają porównania zakresowe. Na przykład jeśli zaszyfrowana kolumna zawierająca wynagrodzenia pracowników ma indeks, złośliwy administrator danych może przeskanować indeks, aby znaleźć maksymalną zaszyfrowaną wartość wynagrodzenia i zidentyfikować osobę z maksymalnym wynagrodzeniem (przy założeniu, że nazwisko osoby nie jest zaszyfrowane).
  • Jeśli używasz funkcji Always Encrypted do ochrony poufnych danych przed nieautoryzowanym dostępem przez administratorów baz danych, nie udostępniaj kluczy kolumny master ani kluczy szyfrowania kolumn z administratorami baz danych. Administrator bazy danych może zarządzać indeksami w zaszyfrowanych kolumnach bez bezpośredniego dostępu do kluczy przy użyciu pamięci podręcznej kluczy szyfrowania kolumn wewnątrz enklawy.

Zagadnienia dotyczące ciągłości działania, odzyskiwania po awarii i migracji danych

Podczas konfigurowania rozwiązania wysokiej dostępności lub odzyskiwania po awarii dla bazy danych przy użyciu funkcji Always Encrypted z bezpiecznymi enklawami upewnij się, że wszystkie repliki bazy danych mogą używać bezpiecznej enklawy. Jeśli enklawa jest dostępna dla repliki podstawowej, ale nie dla repliki pomocniczej, każda instrukcja, która próbuje użyć funkcji Funkcji Always Encrypted z bezpiecznymi enklawami, zakończy się niepowodzeniem po przejściu w tryb failover.

Podczas kopiowania lub migrowania bazy danych przy użyciu funkcji Always Encrypted z bezpiecznymi enklawami upewnij się, że środowisko docelowe zawsze obsługuje enklawy. W przeciwnym razie zapytania używające enklaw nie będą działać ani na kopii, ani na migrowanej bazie danych.

Poniżej przedstawiono konkretne zagadnienia, które należy wziąć pod uwagę:

  • programu SQL Server

    • Podczas konfigurowania grupy dostępności Always On, upewnij się, że każde wystąpienie SQL Server hostujące bazę danych w grupie dostępności obsługuje Always Encrypted z bezpiecznymi enklawami oraz że enklawa i poświadczanie są skonfigurowane.
    • Podczas przywracania z pliku kopii zapasowej bazy danych korzystającej z funkcji Always Encrypted z bezpiecznymi enklawami na wystąpieniu programu SQL Server, które nie ma skonfigurowanej enklawy, operacja przywracania zakończy się powodzeniem i wszystkie funkcje, które nie opierają się na enklawie, będą dostępne. Jednak każda kolejna instrukcja korzystająca z funkcji enklawy zakończy się niepowodzeniem, a indeksy w kolumnach z obsługą enklawy przy użyciu szyfrowania losowego staną się nieprawidłowe. To samo dotyczy dołączania bazy danych przy użyciu funkcji Always Encrypted z bezpiecznymi enklawami w wystąpieniu, które nie ma skonfigurowanej enklawy.
    • Jeśli baza danych zawiera indeksy w kolumnach z obsługą enklawy przy użyciu szyfrowania losowego, przed utworzeniem kopii zapasowej bazy danych upewnij się, że w bazie danych jest włączone przyspieszone odzyskiwanie bazy danych (ADR). Adr zapewni, że baza danych, w tym indeksy, jest dostępna natychmiast po przywróceniu bazy danych. Aby uzyskać więcej informacji, zobacz Database Recovery.

  • Azure SQL Database

    • Podczas konfigurowania aktywnej replikacji geograficznejupewnij się, że pomocnicza baza danych obsługuje bezpieczne enklawy, jeśli jest to podstawowa baza danych.

W SQL Server i Azure SQL Database, gdy migrujesz bazę danych za pomocą pliku bacpac, musisz upewnić się, że przed utworzeniem pliku bacpac usunięto wszystkie indeksy z kolumn obsługujących enklawę przy użyciu losowego szyfrowania.

Znane ograniczenia

Funkcja Always Encrypted z bezpiecznymi enklawami rozwiązuje pewne ograniczenia funkcji Always Encrypted, wspierając szyfrowanie bezpośrednie i bardziej zaawansowane poufne zapytania z indeksami, co zostało wyjaśnione w możliwości poufnego przetwarzania dla kolumn z obsługą enklawy.

Wszystkie inne ograniczenia dotyczące funkcji Always Encrypted wymienione w Ograniczenia mają zastosowanie również do funkcji Always Encrypted z bezpiecznymi enklawami.

Następujące ograniczenia dotyczą funkcji Always Encrypted z bezpiecznymi enklawami:

  • Nie można utworzyć indeksów klastrowanych w kolumnach z obsługą enklawy przy użyciu szyfrowania losowego.
  • Kolumny z obsługą enklawy korzystające z szyfrowania losowego nie mogą być kolumnami klucza podstawowego i nie mogą być przywoływane przez ograniczenia klucza obcego ani ograniczenia unikalnego klucza.
  • W programie SQL Server 2019 (15.x) (to ograniczenie nie ma zastosowania do usługi Azure SQL Database lub SQL Server 2022 (16.x)) obsługiwane są tylko sprzężenia pętli zagnieżdżonej (przy użyciu indeksów, jeśli są dostępne) w kolumnach z obsługą enklawy z wykorzystaniem szyfrowania losowego. Aby uzyskać informacje o innych różnicach między różnymi produktami, zobacz Poufne zapytania.
  • Operacje kryptograficzne w miejscu przetwarzania nie mogą być łączone z innymi zmianami metadanych kolumn, z wyjątkiem zmiany sortowania w obrębie tej samej strony kodu i możliwości przyjmowania wartości null. Na przykład nie można zaszyfrować, ponownie zaszyfrować ani odszyfrować kolumny ORAZ zmienić typu danych kolumny w jednej instrukcji ALTER TABLE/ALTER COLUMN Transact-SQL. Użyj dwóch oddzielnych stwierdzeń.
  • Używanie kluczy obsługujących enklawy dla kolumn w tabelach pamięciowych nie jest wspierane.
  • Wyrażenia definiujące kolumny obliczeniowe nie mogą wykonywać żadnych obliczeń w kolumnach z obsługą enklawy przy użyciu szyfrowania losowego (nawet jeśli obliczenia należą do obsługiwanych operacji wymienionych w Zapytania poufne).
  • Znaki ucieczki nie są obsługiwane w parametrach operatora LIKE w kolumnach z obsługą enklawy przy użyciu szyfrowania losowego.
  • Zapytania z operatorem LIKE lub operatorem porównania, który ma parametr zapytania przy użyciu jednego z następujących typów danych (które stają się dużymi obiektami po szyfrowaniu), ignorują indeksy i wykonują skanowania tabel.
    • nchar[n] i nvarchar[n], jeśli n jest większe niż 3967.
    • char[n], varchar[n], binary[n], varbinary[n], jeśli n jest większa niż 7935.
  • Ograniczenia narzędzi:
    • Jedynymi obsługiwanymi magazynami kluczy do przechowywania kluczy kolumn z obsługą enklawy master są magazyny certyfikatów systemu Windows oraz usługa Azure Key Vault.
    • Aby uruchomić operację kryptograficzną na miejscu za pośrednictwem ALTER TABLE/ALTER COLUMN, musisz wydać instrukcję za pomocą okna zapytania w SSMS lub Azure Data Studio, albo napisać własny program, który to zrobi. Obecnie polecenie cmdlet Set-SqlColumnEncryption w module SqlServer PowerShell oraz kreator Always Encrypted w programie SQL Server Management Studio nie obsługują szyfrowania bezpośredniego na miejscu. Przenieś dane z bazy danych na potrzeby operacji kryptograficznych, nawet jeśli klucze szyfrowania kolumn używane do tych operacji są obsługiwane przez enklawę.
  • Po przywróceniu bazy danych z obsługą enklawy VBS konieczne jest ponowne skonfigurowanie ustawienia enklawy VBS.

Powiązana zawartość