Jak działa Always Encrypted i Secure Enclaves w Azure SQL Database?

Always Encrypted to zaawansowana funkcja zabezpieczająca dane w bazie danych, która umożliwia szyfrowanie wybranych kolumn na poziomie klienta. Administratorzy mają do wyboru dwa podstawowe typy szyfrowania: szyfrowanie losowe (randomized encryption) oraz deterministyczne (deterministic encryption). Szyfrowanie losowe jest bardziej bezpieczne, ponieważ każdorazowo szyfruje tę samą wartość w inny sposób, co uniemożliwia porównywanie zaszyfrowanych danych bez specjalnych mechanizmów. Z kolei szyfrowanie deterministyczne zawsze generuje ten sam zaszyfrowany ciąg dla danej wartości, co pozwala aplikacjom na wykonywanie porównań i operacji na tych danych, ale kosztem obniżenia poziomu bezpieczeństwa.

Always Encrypted wykorzystuje klucz główny (master key), którym generuje unikalny klucz szyfrowania kolumn (column encryption key) dla każdej chronionej kolumny. Klucz główny może być przechowywany w magazynie certyfikatów Windows lub w Azure Key Vault, co daje elastyczność i wysoki poziom ochrony.

Jednym z istotnych wyzwań Always Encrypted jest fakt, że dane pozostają zaszyfrowane nawet podczas przetwarzania ich przez serwer SQL. To ogranicza możliwość wykonywania niektórych zapytań na zaszyfrowanych kolumnach, zwłaszcza gdy stosowane jest szyfrowanie losowe. Rozwiązaniem tego problemu są Secure Enclaves – izolowane, chronione obszary pamięci i procesora, które mogą przetwarzać odszyfrowane dane bez ujawniania ich silnikowi bazy danych ani innym procesom zewnętrznym. Dzięki temu możliwe jest wykonywanie operacji na danych Always Encrypted bez utraty ich bezpieczeństwa.

W Azure SQL Database Secure Enclaves realizowane są za pomocą technologii wirtualizacji opartej na bezpieczeństwie (Virtualization-Based Security, VBS), czyli całkowicie programowego rozwiązania, które tworzy izolowane środowisko wewnątrz przestrzeni adresowej serwera SQL. Alternatywnie, dostępne są też Secure Enclaves bazujące na sprzętowych rozszerzeniach Intel SGX, oferujących jeszcze wyższy poziom ochrony, ale wymagających określonych procesorów serwerowych.

Włączenie Secure Enclaves jest domyślnie wyłączone w Azure SQL Database i musi zostać aktywowane przez administratora, co można zrobić zarówno podczas tworzenia bazy danych, jak i w już istniejącej bazie przy użyciu odpowiednich poleceń T-SQL.

Ochrona dostępu do bazy danych nie kończy się jednak na szyfrowaniu. W Azure SQL Database można skonfigurować prywatne łącza (private links), które umożliwiają bezpieczne połączenia klientów z bazą danych przez prywatną sieć wirtualną, eliminując konieczność korzystania z publicznych adresów IP i ograniczając narażenie na ataki z Internetu. Utworzenie prywatnego punktu końcowego (private endpoint) wymaga współpracy administratora sieci i administratora SQL, którzy zatwierdzają lub odrzucają połączenie.

Dodatkowo, aby zabezpieczyć przesyłanie danych między klientem a serwerem, Azure SQL Database korzysta z protokołu Transport Layer Security (TLS). Pozwala to na szyfrowanie ruchu sieciowego, podobnie jak w przypadku HTTPS w przeglądarkach internetowych. Administratorzy mogą ustawić minimalną wersję TLS obsługiwaną przez serwer, co wpływa na poziom bezpieczeństwa połączeń. Zalecane jest stosowanie najnowszych wersji protokołu, takich jak TLS 1.2 lub 1.3, aby uniknąć luk znanych z wcześniejszych wersji.

Jak monitorować wydajność i działanie baz danych w środowisku Azure SQL?

W środowisku Azure SQL skuteczne monitorowanie wydajności baz danych oraz diagnozowanie potencjalnych problemów wymaga wykorzystania dedykowanych narzędzi i metod, które umożliwiają precyzyjne śledzenie zapytań, analizę zasobów oraz reagowanie na niepożądane zachowania. Współczesna architektura chmurowa Azure oferuje administratorom szereg zintegrowanych rozwiązań, które służą nie tylko do bieżącego nadzoru, ale także do długoterminowej optymalizacji środowiska.

Połączenie z bazą danych Azure SQL realizowane jest za pośrednictwem standardowego łącza TCP z użyciem portu 1433, przy czym dane uwierzytelniające – takie jak identyfikator użytkownika i hasło – mogą być bezpiecznie przechowywane w Azure Key Vault. Konfiguracja obejmuje m.in. określenie serwera, nazwy bazy danych oraz tajnego hasła. Warto zadbać, by środowisko wirtualnej maszyny miało odpowiednie reguły zapory i przynależność do grup zabezpieczeń umożliwiające nawiązywanie połączeń z usługą SQL – w przeciwnym razie monitoring będzie niemożliwy.

Wraz z wycofaniem usługi SQL Insights, Microsoft rekomenduje stosowanie narzędzia database watcher jako głównego rozwiązania do monitoringu wydajności w chmurze. Database watcher działa jako centralny kolektor danych telemetrycznych pochodzących z wybranych baz danych, instancji zarządzanych oraz pul elastycznych. Administrator tworzy zasób watcher, wskazuje źródła danych SQL do monitorowania oraz wybiera docelową lokalizację magazynowania danych, taką jak Azure Data Explorer. Dostęp do zebranych informacji odbywa się poprzez pulpity nawigacyjne Azure, umożliwiając kompleksową analizę trendów i anomalii.

Alternatywne podejście do monitorowania stanowią zdarzenia rozszerzone (extended events), które pozwalają na bardzo szczegółowy wgląd w działanie silnika SQL. W SQL Server Management Studio możliwe jest utworzenie sesji, w której administrator określa konkretne zdarzenia do obserwacji. Zdarzenia te mogą dotyczyć problemów z czasem wykonania zapytań, niskiej wydajności operacji wejścia/wyjścia, czy nieefektywnego wykorzystania pamięci. Konfiguracja sesji obejmuje m.in. wybór szablonu zdarzeń, określenie globalnych pól do przechwycenia oraz zastosowanie filtrów sesji. Dane mogą być zapisywane w buforze pierścieniowym (tylko w pamięci) lub w pliku w Azure Storage.

Z perspektywy analizy i optymalizacji zapytań szczególną rolę odgrywa Query Store – funkcjonalność wbudowana w każdą bazę danych SQL w Azure, odpowiedzialna za gromadzenie informacji o wykonywanych zapytaniach, planach wykonania i statystykach ich działania. Dane przechowywane są w trzech segmentach: plan store, runtime stats store oraz wait stats store. Dzięki temu możliwa jest dogłębna analiza historii zapytań, identyfikacja regresji wydajności oraz optymalizacja planów wykonania.

Query Store jest domyślnie aktywowany w nowych instalacjach Azure SQL Database i Azure SQL Managed Instance oraz w SQL Server 2022. W starszych wersjach jego uruchomienie wymaga interwencji administratora oraz zastosowania odpowiednich poprawek. Konfiguracja polega na ustawieniu trybu działania jako Read write, co pozwala serwerowi na dynamiczne dodawanie nowych zapytań do magazynu. Kluczowe jest, aby konfiguracja była realizowana na właściwej bazie danych użytkownika, a nie na bazach systemowych jak master czy tempdb.

W analizie wydajności zapytań nie do przecenienia są również dynamiczne widoki zarządzania (DMV), które pozwalają zidentyfikować sesje powodujące blokowanie, oszacować zużycie zasobów przez konkretne zapytania, a także rozpoznać możliwości zastosowania dodatkowych indeksów. Połączenie danych z DMV z informacjami z Query Store umożliwia wszechstronną ocenę działania środowiska bazodanowego oraz formułowanie precyzyjnych rekomendacji optymalizacyjnych.

Microsoft oferuje również rozwiązanie Intelligent Insights – narzędzie wykorzystujące sztuczną inteligencję do wykrywania anomalii wydajnościowych i proponowania działań naprawczych. W połączeniu z bazowymi funkcjami monitoringu oraz narzędziami analitycznymi stanowi ono istotne uzupełnienie strategii zarządzania wydajnością.