Udostępnij za pośrednictwem


Nowa baza danych w chmurze — zarządzanie usługą Azure SQL Database po migracji

Dotyczy: Azure SQL Database

Przejście z tradycyjnego samozarządzanego, samokontrolowego środowiska do środowiska PaaS może wydawać się nieco przytłaczające na początku. Jako deweloper aplikacji lub administrator bazy danych warto znać podstawowe możliwości platformy, które pomogą Ci zapewnić dostępność aplikacji, wydajną, bezpieczną i odporną — zawsze. Ten artykuł ma na celu zrobienie tego dokładnie. Artykuł zwięźle organizuje zasoby i zawiera wskazówki dotyczące najlepszego wykorzystania kluczowych możliwości usługi Azure SQL Database z pojedynczymi bazami danych i bazami danych w puli w celu wydajnego działania aplikacji i uzyskania optymalnych wyników w chmurze. Typowymi odbiorcami tego artykułu są osoby, które:

  • Oceniają migrację swoich aplikacji do usługi Azure SQL Database — modernizowanie aplikacji.
  • Czy trwa migrowanie aplikacji — scenariusz migracji w toku.
  • Niedawno zakończono migrację do usługi Azure SQL Database — nowa baza danych w chmurze.

W tym artykule omówiono niektóre podstawowe cechy usługi Azure SQL Database jako platformę, której można łatwo używać podczas pracy z pojedynczymi bazami danych i bazami danych w puli w elastycznych pulach. Są one następujące:

  • Monitorowanie baz danych za pomocą witryny Azure Portal
  • Ciągłość biznesowa i odzyskiwanie po awarii (BCDR)
  • Zabezpieczenia i zgodność
  • Inteligentne monitorowanie i konserwacja bazy danych
  • Przenoszenie danych

Uwaga

Microsoft Entra ID był wcześniej znany jako Azure Active Directory (Azure AD).

Monitorowanie baz danych za pomocą witryny Azure Portal

Aby zapoznać się z metrykami i alertami usługi Azure Monitor, w tym zalecanymi regułami alertów, zobacz Monitorowanie usługi Azure SQL Database za pomocą metryk i alertów. Aby uzyskać więcej informacji na temat warstw usług, zobacz artykuły dotyczące modelu zakupów opartego na jednostkach DTU i modelu zakupów opartych na rdzeniach wirtualnych.

Alerty dotyczące metryk wydajności można skonfigurować. Wybierz przycisk Dodaj alert w oknie Metryka. Użyj kreatora, aby skonfigurować alert. Istnieje możliwość ustawienia alertu, który będzie wysyłany, gdy metryki przekroczą określony próg lub spadną poniżej określonego progu.

Jeśli na przykład spodziewasz się, że obciążenie bazy danych wzrośnie, możesz skonfigurować alert polegający na wysłaniu wiadomości e-mail, gdy dowolna z metryk wydajności osiągnie 80%. Możesz użyć tego jako wczesnego ostrzeżenia, aby ustalić, kiedy może być konieczne przełączenie się do następnego najwyższego rozmiaru obliczeniowego.

Metryki wydajności mogą również pomóc w ustaleniu, czy można obniżyć poziom do niższego rozmiaru obliczeniowego. Należy jednak pamiętać o obciążeniach, które wzrosły lub wahały się przed podjęciem decyzji o przejściu do niższego rozmiaru obliczeniowego.

Ciągłość biznesowa i odzyskiwanie po awarii (BCDR)

Możliwości zapewniania ciągłości działania i odzyskiwania po awarii umożliwiają kontynuowanie działalności w zwykły sposób w przypadku awarii. Awaria może być zdarzeniem na poziomie bazy danych (na przykład ktoś błędnie popadnie w kluczową tabelę) lub zdarzeniem na poziomie centrum danych (katastrofa regionalna, na przykład tsunami).

Jak mogę tworzenie kopii zapasowych w usłudze SQL Database i zarządzanie nimi

Nie tworzysz kopii zapasowych w usłudze Azure SQL Database i nie musisz tego robić. Usługa SQL Database automatycznie wykonuje kopie zapasowe baz danych, więc nie musisz już martwić się o planowanie, wykonywanie kopii zapasowych i zarządzanie nimi. Platforma wykonuje pełną kopię zapasową co tydzień, różnicową kopię zapasową co kilka godzin, a kopia zapasowa dziennika co 5 minut w celu zapewnienia wydajności odzyskiwania po awarii i minimalnej utraty danych. Pierwsza pełna kopia zapasowa jest wykonywana zaraz po utworzeniu bazy danych. Te kopie zapasowe są dostępne przez określony okres o nazwie "Okres przechowywania" i różnią się w zależności od wybranej warstwy usługi. Usługa SQL Database umożliwia przywracanie do dowolnego punktu w czasie w tym okresie przechowywania przy użyciu punktu w czasie odzyskiwania (PITR).

Ponadto funkcja długoterminowego przechowywania (LTR) umożliwia przechowywanie plików kopii zapasowych przez znacznie dłuższy okres przez maksymalnie 10 lat i przywracanie danych z tych kopii zapasowych w dowolnym momencie w tym okresie. Ponadto kopie zapasowe bazy danych są przechowywane w magazynie replikowanym geograficznie, aby zapewnić odporność na awarię regionalną. Możesz również przywrócić te kopie zapasowe w dowolnym regionie świadczenia usługi Azure w dowolnym momencie w okresie przechowywania. Aby dowiedzieć się więcej, zobacz Omówienie ciągłości działalności biznesowej.

Jak mogę zapewnić ciągłość działania w przypadku awarii na poziomie centrum danych lub katastrofy regionalnej

Kopie zapasowe bazy danych są przechowywane w magazynie replikowanym geograficznie, aby upewnić się, że podczas awarii regionalnej można przywrócić kopię zapasową do innego regionu świadczenia usługi Azure. Jest to nazywane przywracaniem geograficznym. Cel punktu odzyskiwania (cel punktu odzyskiwania) dla przywracania geograficznego wynosi zazwyczaj < 1 godzinę, a czas ERT (szacowany czas odzyskiwania) — kilka minut do godzin.

W przypadku baz danych o krytycznym znaczeniu usługa Azure SQL Database oferuje aktywną replikację geograficzną, która tworzy pomocniczą kopię replikowanej geograficznie oryginalnej bazy danych w innym regionie. Jeśli na przykład baza danych jest początkowo hostowana w regionie Zachodnie stany USA platformy Azure i chcesz mieć regionalną odporność na awarie, utwórz aktywną replikę geograficzną bazy danych w regionie Zachodnie stany USA do wschodnich stanów USA. Gdy nieszczęście uderza w Zachodnie stany USA, możesz przejść w tryb failover w regionie Wschodnie stany USA.

Oprócz aktywnej replikacji geograficznej grupy trybu failover zapewniają wygodny sposób zarządzania replikacją i trybem failover grupy baz danych. Możesz utworzyć grupę trybu failover zawierającą wiele baz danych w tych samych lub różnych regionach. Następnie można zainicjować tryb failover wszystkich baz danych w grupie trybu failover do regionu pomocniczego. Aby uzyskać więcej informacji, zobacz Grupy trybu failover.

Aby zapewnić odporność na awarie centrum danych lub strefy dostępności, upewnij się, że dla bazy danych lub elastycznej puli włączono nadmiarowość strefy.

Aktywnie monitoruj aplikację pod kątem awarii i inicjuj przejście w tryb failover do pomocniczej wersji. W różnych regionach świadczenia usługi Azure można utworzyć maksymalnie cztery takie aktywne repliki geograficzne. Staje się jeszcze lepiej. Dostęp do tych pomocniczych aktywnych replik geograficznych można również uzyskać w celu uzyskania dostępu tylko do odczytu. Jest to bardzo przydatne, aby zmniejszyć opóźnienie scenariusza aplikacji rozproszonej geograficznie.

Jak wygląda odzyskiwanie po awarii w usłudze SQL Database

Konfigurację i zarządzanie odzyskiwaniem po awarii można wykonać za pomocą kilku kroków w usłudze Azure SQL Database, gdy używasz aktywnej replikacji geograficznej lub grup trybu failover. Nadal musisz monitorować aplikację i jej bazę danych pod kątem awarii regionalnej i przejść w tryb failover do regionu pomocniczego w celu przywrócenia ciągłości działania.

Aby dowiedzieć się więcej, zobacz Odzyskiwanie po awarii usługi Azure SQL Database 101.

Zabezpieczenia i zgodność

Usługa SQL Database bardzo poważnie traktuje zabezpieczenia i prywatność. Zabezpieczenia w usłudze SQL Database są dostępne na poziomie bazy danych i na poziomie platformy i najlepiej rozumie się je po kategoryzowaniu na kilka warstw. W każdej warstwie uzyskasz kontrolę i zapewnisz optymalne zabezpieczenia aplikacji. Warstwy to:

Microsoft Defender dla Chmury oferuje scentralizowane zarządzanie zabezpieczeniami między obciążeniami działającymi na platformie Azure, lokalnie i w innych chmurach. Możesz sprawdzić, czy podstawowa ochrona bazy danych SQL, taka jak inspekcja i funkcja Transparent Data Encryption [TDE] są konfigurowane na wszystkich zasobach, i tworzyć zasady na podstawie własnych wymagań.

Jakie metody uwierzytelniania użytkowników są oferowane w usłudze SQL Database

Istnieją dwie metody uwierzytelniania oferowane w usłudze SQL Database:

Uwierzytelnianie systemu Windows nie jest obsługiwane. Microsoft Entra ID to scentralizowana usługa zarządzania tożsamościami i dostępem. Dzięki temu możesz bardzo wygodnie zapewnić dostęp do logowania jednokrotnego do personelu w organizacji. Oznacza to, że poświadczenia są współużytkowane przez usługi platformy Azure w celu prostszego uwierzytelniania.

Microsoft Entra ID obsługuje uwierzytelnianie wieloskładnikowe i można je łatwo zintegrować z usługą Active Directory systemu Windows Server. Dzięki temu usługi SQL Database i Azure Synapse Analytics mogą oferować uwierzytelnianie wieloskładnikowe i konta użytkowników-gości w domenie firmy Microsoft Entra. Jeśli używasz już lokalnej usługi Active Directory, możesz sfederować ją z identyfikatorem Microsoft Entra ID, aby rozszerzyć katalog na platformę Azure.

Uwierzytelnianie SQL obsługuje tylko nazwę użytkownika i hasło do uwierzytelniania użytkowników w dowolnej bazie danych na danym serwerze.

Jeśli... SQL Database / Azure Synapse Analytics
Używane usługi AD w środowisku lokalnym programu SQL Server Federuj usługę AD z identyfikatorem Entra firmy Microsoft i użyj uwierzytelniania Microsoft Entra. Federacja umożliwia korzystanie z logowania jednokrotnego.
Należy wymusić uwierzytelnianie wieloskładnikowe Wymagaj uwierzytelniania wieloskładnikowego jako zasad za pośrednictwem dostępu warunkowego firmy Microsoft i używaj uwierzytelniania wieloskładnikowego firmy Microsoft.
Loguje się do systemu Windows przy użyciu poświadczeń usługi Microsoft Entra z domeny federacyjnej Użyj zintegrowanego uwierzytelniania firmy Microsoft Entra.
Loguje się do systemu Windows przy użyciu poświadczeń z domeny, która nie jest federacyjna z platformą Azure Użyj zintegrowanego uwierzytelniania firmy Microsoft Entra.
Posiadanie usług warstwy środkowej, które muszą łączyć się z usługą SQL Database lub Azure Synapse Analytics Użyj zintegrowanego uwierzytelniania firmy Microsoft Entra.
Wymaganie techniczne dotyczące korzystania z uwierzytelniania SQL Korzystanie z uwierzytelniania SQL

Jak mogę ograniczyć lub kontrolować dostęp do łączności z moją bazą danych

Istnieje wiele technik, których można użyć do uzyskania optymalnej organizacji łączności dla aplikacji.

  • Reguły zapory
  • Punkty końcowe usługi sieci wirtualnej
  • Zastrzeżone adresy IP

Firewall

Zapora uniemożliwia dostęp do serwera z jednostki zewnętrznej, zezwalając tylko określonym jednostkom na dostęp do serwera. Domyślnie wszystkie połączenia z bazami danych na serwerze są niedozwolone, z wyjątkiem (opcjonalnie7) połączeń przychodzących z innych usług platformy Azure. Za pomocą reguły zapory można otworzyć dostęp do serwera tylko do jednostek (na przykład maszyny deweloperskiej), które zatwierdzisz, zezwalając na adres IP tego komputera przez zaporę. Umożliwia również określenie zakresu adresów IP, które chcesz zezwolić na dostęp do serwera. Na przykład adresy IP maszyny deweloperów w organizacji można dodać jednocześnie, określając zakres na stronie Ustawienia zapory.

Reguły zapory można tworzyć na poziomie serwera lub na poziomie bazy danych. Reguły zapory adresów IP na poziomie serwera można utworzyć przy użyciu witryny Azure Portal lub programu SSMS. Aby dowiedzieć się więcej na temat ustawiania reguły zapory na poziomie serwera i na poziomie bazy danych, zobacz Tworzenie reguł zapory adresów IP w usłudze SQL Database.

Punkty końcowe usługi

Domyślnie baza danych jest skonfigurowana do ustawienia "Zezwalaj usługom i zasobom platformy Azure na dostęp do tego serwera" — co oznacza, że każda maszyna wirtualna na platformie Azure może próbować nawiązać połączenie z bazą danych. Te próby nadal muszą być uwierzytelnione. Jeśli nie chcesz, aby baza danych była dostępna dla żadnych adresów IP platformy Azure, możesz wyłączyć opcję "Zezwalaj usługom i zasobom platformy Azure na dostęp do tego serwera". Ponadto można skonfigurować punkty końcowe usługi sieci wirtualnej.

Punkty końcowe usługi (SE) umożliwiają uwidacznienie krytycznych zasobów platformy Azure tylko dla własnej prywatnej sieci wirtualnej na platformie Azure. W ten sposób zasadniczo eliminujesz publiczny dostęp do zasobów. Ruch między siecią wirtualną a platformą Azure pozostaje w sieci szkieletowej platformy Azure. Bez protokołu SE uzyskujesz routing pakietów wymuszonego tunelowania. Sieć wirtualna wymusza ruch internetowy do organizacji, a ruch usługi platformy Azure przechodzi przez tę samą trasę. Za pomocą punktów końcowych usługi można to zoptymalizować, ponieważ pakiety przepływają bezpośrednio z sieci wirtualnej do usługi w sieci szkieletowej platformy Azure.

Zastrzeżone adresy IP

Inną opcją jest aprowizacja zarezerwowanych adresów IP dla maszyn wirtualnych i dodanie tych określonych adresów IP maszyn wirtualnych w ustawieniach zapory serwera. Przypisując zastrzeżone adresy IP, możesz zaoszczędzić problemy z koniecznością zaktualizowania reguł zapory przy użyciu zmieniających się adresów IP.

Jaki port mam nawiązać połączenie z usługą SQL Database w usłudze

Port 1433. Usługa SQL Database komunikuje się za pośrednictwem tego portu. Aby nawiązać połączenie z sieci firmowej, musisz dodać regułę ruchu wychodzącego w ustawieniach zapory organizacji. Zgodnie z wytycznymi unikaj uwidaczniania portu 1433 poza granicą platformy Azure.

Jak monitorować i regulować aktywność na serwerze i bazie danych w usłudze SQL Database

Inspekcja bazy danych SQL

Usługa SQL Database umożliwia włączenie inspekcji w celu śledzenia zdarzeń bazy danych. Inspekcja usługi SQL Database rejestruje zdarzenia bazy danych i zapisuje je w pliku dziennika inspekcji na koncie usługi Azure Storage. Inspekcja jest szczególnie przydatna, jeśli zamierzasz uzyskać wgląd w potencjalne naruszenia zabezpieczeń i zasad, zachować zgodność z przepisami itp. Umożliwia definiowanie i konfigurowanie określonych kategorii zdarzeń, które uważasz za potrzebne inspekcje i na podstawie tego, że można uzyskać wstępnie skonfigurowane raporty i pulpit nawigacyjny, aby uzyskać przegląd zdarzeń występujących w bazie danych. Te zasady inspekcji można stosować na poziomie bazy danych lub na poziomie serwera. Przewodnik dotyczący włączania inspekcji dla serwera/bazy danych, zobacz: Włączanie inspekcji usługi SQL Database.

Wykrywanie zagrożeń

Dzięki wykrywaniu zagrożeń można bardzo łatwo reagować na naruszenia zabezpieczeń lub zasad wykryte przez inspekcję. Nie musisz być ekspertem ds. zabezpieczeń, aby rozwiązać potencjalne zagrożenia lub naruszenia w systemie. Wykrywanie zagrożeń ma również pewne wbudowane funkcje, takie jak wykrywanie iniekcji SQL. Iniekcja SQL to próba zmiany lub naruszenia zabezpieczeń danych oraz dość powszechny sposób ataku na aplikację bazy danych. Wykrywanie zagrożeń uruchamia wiele zestawów algorytmów, które wykrywają potencjalne luki w zabezpieczeniach i ataki polegających na wstrzyknięciu kodu SQL, a także nietypowe wzorce dostępu do bazy danych (takie jak dostęp z nietypowej lokalizacji lub nieznanego podmiotu zabezpieczeń). Funkcjonariusze zabezpieczeń lub inni wyznaczeni administratorzy otrzymają powiadomienie e-mail, jeśli w bazie danych zostanie wykryte zagrożenie. Każde powiadomienie zawiera szczegółowe informacje o podejrzanych działaniach i zaleceniach dotyczących dalszego badania i ograniczania zagrożenia. Aby dowiedzieć się, jak włączyć wykrywanie zagrożeń, zobacz: Włączanie wykrywania zagrożeń.

Jak mogę chronić moje dane ogólnie w usłudze SQL Database

Szyfrowanie zapewnia silny mechanizm ochrony i zabezpieczania poufnych danych przed intruzami. Zaszyfrowane dane nie są używane do intruza bez klucza odszyfrowywania. W związku z tym dodaje dodatkową warstwę ochrony na podstawie istniejących warstw zabezpieczeń wbudowanych w usługę SQL Database. Istnieją dwa aspekty ochrony danych w usłudze SQL Database:

  • Dane przechowywane w plikach danych i dziennika
  • Dane, które są w locie

W usłudze SQL Database dane przechowywane w plikach danych i dziennika w podsystemie magazynowania są domyślnie całkowicie i zawsze szyfrowane za pośrednictwem funkcji Transparent Data Encryption [TDE]. Kopie zapasowe są również szyfrowane. W przypadku funkcji TDE nie są wymagane żadne zmiany po stronie aplikacji, które uzyskują dostęp do tych danych. Szyfrowanie i odszyfrowywanie jest wykonywane w sposób niewidoczny; stąd nazwa. W celu ochrony poufnych danych w locie i spoczynku usługa SQL Database udostępnia funkcję o nazwie Always Encrypted (AE). AE to forma szyfrowania po stronie klienta, która szyfruje poufne kolumny w bazie danych (więc są w postaci szyfrowania dla administratorów bazy danych i nieautoryzowanych użytkowników). Serwer odbiera zaszyfrowane dane na początek. Klucz funkcji Always Encrypted jest również przechowywany po stronie klienta, więc tylko autoryzowani klienci mogą odszyfrować poufne kolumny. Administratorzy serwerów i danych nie widzą poufnych danych, ponieważ klucze szyfrowania są przechowywane na kliencie. Usługa AE szyfruje poufne kolumny w tabeli na końcu, od nieautoryzowanych klientów do dysku fizycznego. Obecnie usługa AE obsługuje porównania równości, więc administratorzy baz danych mogą nadal wykonywać zapytania dotyczące zaszyfrowanych kolumn w ramach poleceń SQL. Funkcja Always Encrypted może być używana z różnymi opcjami magazynu kluczy, takimi jak usługa Azure Key Vault, magazyn certyfikatów systemu Windows i lokalne moduły zabezpieczeń sprzętu.

Charakterystyka Zawsze szyfrowane Transparent Data Encryption
Zakres szyfrowania Kompleksowe Dane magazynowane
Serwer może uzyskiwać dostęp do poufnych danych Nie. Tak, ponieważ szyfrowanie dotyczy danych magazynowanych
Dozwolone operacje T-SQL Porównanie równości Dostępny jest cały obszar powierzchni języka T-SQL
Zmiany aplikacji wymagane do korzystania z funkcji Minimalny Bardzo minimalny
Stopień szczegółowości szyfrowania Poziom kolumny Poziom bazy danych

Jak ograniczyć dostęp do poufnych danych w mojej bazie danych

Każda aplikacja ma pewien kawałek poufnych danych w bazie danych, które muszą być chronione przed widocznością dla wszystkich. Niektórzy pracownicy w organizacji muszą wyświetlać te dane, jednak inni nie powinni mieć możliwości wyświetlania tych danych. Przykładem są płace pracowników. Menedżer musi mieć dostęp do informacji o płacach dla swoich bezpośrednich raportów, jednak członkowie poszczególnych zespołów nie powinni mieć dostępu do informacji o płacach swoich rówieśników. Innym scenariuszem są deweloperzy danych, którzy mogą korzystać z poufnych danych podczas etapów programowania lub testowania, na przykład sieci SSN klientów. Te informacje nie muszą być ponownie udostępniane deweloperowi. W takich przypadkach poufne dane muszą być maskowane lub nie są w ogóle widoczne. Usługa SQL Database oferuje dwa takie podejścia, aby uniemożliwić nieautoryzowanym użytkownikom wyświetlanie poufnych danych:

Dynamiczne maskowanie danych to funkcja maskowania danych, która umożliwia ograniczenie ujawnienia poufnych danych przez maskowanie ich do użytkowników niebędących uprzywilejowanymi w warstwie aplikacji. Należy zdefiniować regułę maskowania, która może utworzyć wzorzec maskowania (na przykład, aby pokazywać tylko cztery ostatnie cyfry narodowego identyfikatora SSN: XXX-XX-0000 i oznaczyć większość z nich jako Xs) i określić, którzy użytkownicy mają zostać wykluczeni z reguły maskowania. Maskowanie odbywa się na bieżąco i istnieją różne funkcje maskowania dostępne dla różnych kategorii danych. Dynamiczne maskowanie danych umożliwia automatyczne wykrywanie poufnych danych w bazie danych i stosowanie do niej maskowania.

Zabezpieczenia na poziomie wiersza umożliwiają kontrolowanie dostępu na poziomie wiersza. Oznacza to, że niektóre wiersze w tabeli bazy danych na podstawie użytkownika wykonującego zapytanie (członkostwo w grupie lub kontekst wykonywania) są ukryte. Ograniczenie dostępu odbywa się w warstwie bazy danych zamiast w warstwie aplikacji, aby uprościć logikę aplikacji. Zacznij od utworzenia predykatu filtru, odfiltrowania wierszy, które nie są uwidocznione, a następnie zasady zabezpieczeń definiujące, kto ma dostęp do tych wierszy. Na koniec użytkownik końcowy uruchamia zapytanie, a w zależności od uprawnień użytkownika wyświetla te wiersze z ograniczeniami lub w ogóle nie może ich wyświetlić.

Jak mogę zarządzanie kluczami szyfrowania w chmurze

Istnieją opcje zarządzania kluczami dla funkcji Always Encrypted (szyfrowanie po stronie klienta) i Transparent Data Encryption (szyfrowanie magazynowane). Zaleca się regularne obracanie kluczy szyfrowania. Częstotliwość rotacji powinna być zgodna zarówno z wewnętrznymi przepisami organizacji, jak i wymaganiami dotyczącymi zgodności.

Transparent Data Encryption (TDE)

W funkcji TDE istnieje hierarchia dwóch kluczy — dane w każdej bazie danych użytkownika są szyfrowane za pomocą symetrycznego klucza szyfrowania bazy danych AES-256 (DEK), który z kolei jest szyfrowany przez unikatowy asymetryczny klucz główny RSA 2048 serwera. Klucz główny można zarządzać:

  • Automatycznie według platformy — SQL Database.
  • Możesz też użyć usługi Azure Key Vault jako magazynu kluczy.

Domyślnie klucz główny funkcji Transparent Data Encryption jest zarządzany przez usługę SQL Database dla wygody. Jeśli Twoja organizacja chce kontrolować klucz główny, istnieje możliwość użycia usługi Azure Key Vault jako magazynu kluczy. Za pomocą usługi Azure Key Vault organizacja przejmuje kontrolę nad kluczowymi kontrolkami aprowizacji, rotacji i uprawnień. Rotacja lub przełączanie typu klucza głównego TDE jest szybkie, ponieważ tylko ponownie szyfruje klucz szyfrowania danych. W przypadku organizacji z separacją ról między zabezpieczeniami i zarządzaniem danymi administrator zabezpieczeń może aprowizować materiał klucza głównego TDE w usłudze Azure Key Vault i udostępnić administratorowi bazy danych identyfikator klucza usługi Azure Key Vault do szyfrowania magazynowanych na serwerze. Usługa Key Vault została zaprojektowana tak, aby firma Microsoft nie widziała ani nie wyodrębniła żadnych kluczy szyfrowania. Uzyskujesz również scentralizowane zarządzanie kluczami dla organizacji.

Zawsze szyfrowane

Istnieje również hierarchia dwóch kluczy w funkcji Always Encrypted — kolumna poufnych danych jest szyfrowana za pomocą klucza szyfrowania 256-kolumnowego AES (CEK), który z kolei jest szyfrowany za pomocą klucza głównego kolumny (CMK). Sterowniki klienta podane dla funkcji Always Encrypted nie mają ograniczeń dotyczących długości kluczy cmks. Zaszyfrowana wartość klucza CEK jest przechowywana w bazie danych, a klucz zarządzania kluczami jest przechowywany w zaufanym magazynie kluczy, takim jak magazyn certyfikatów systemu Windows, usługa Azure Key Vault lub sprzętowy moduł zabezpieczeń.

  • Można obracać zarówno klucz CEK, jak i cmK .
  • Rotacja klucza CEK jest rozmiarem operacji danych i może być czasochłonna w zależności od rozmiaru tabel zawierających zaszyfrowane kolumny. W związku z tym rozsądne jest odpowiednio zaplanowanie rotacji CEK.
  • Rotacja cmK nie zakłóca jednak wydajności bazy danych i może być wykonywana z oddzielnymi rolami.

Na poniższym diagramie przedstawiono opcje magazynu kluczy dla kluczy głównych kluczy w funkcji Always Encrypted

Diagram zawsze zaszyfrowanych dostawców magazynu cmK.

Jak mogę zoptymalizować i zabezpieczyć ruch między organizacją a usługą SQL Database

Ruch sieciowy między organizacją a usługą SQL Database zwykle jest kierowany przez sieć publiczną. Jeśli jednak zdecydujesz się zoptymalizować tę ścieżkę i zwiększyć jej bezpieczeństwo, możesz przyjrzeć się usłudze Azure ExpressRoute. Usługa ExpressRoute zasadniczo umożliwia rozszerzenie sieci firmowej na platformę Azure za pośrednictwem połączenia prywatnego. W ten sposób nie przechodzisz przez publiczny Internet. Uzyskujesz również wyższe zabezpieczenia, niezawodność i optymalizację routingu, która przekłada się na mniejsze opóźnienia sieci i znacznie szybsze niż zwykle w przypadku korzystania z publicznego Internetu. Jeśli planujesz przeniesienie znacznego fragmentu danych między organizacją a platformą Azure, korzystanie z usługi ExpressRoute może przynieść korzyści kosztowe. Możesz wybrać spośród trzech różnych modeli łączności dla połączenia między organizacją a platformą Azure:

Usługa ExpressRoute umożliwia również przekroczenie limitu przepustowości do 2 razy większej niż w przypadku zakupu dodatkowej opłaty. Istnieje również możliwość skonfigurowania łączności między regionami przy użyciu usługi ExpressRoute. Aby wyświetlić listę dostawców połączeń usługi ExpressRoute, zobacz: Partnerzy usługi ExpressRoute i lokalizacje komunikacji równorzędnej. W poniższych artykułach opisano usługę Express Route bardziej szczegółowo:

Czy usługa SQL Database jest zgodna z wszelkimi wymaganiami prawnymi i w jaki sposób pomaga to we zgodności mojej organizacji

Usługa SQL Database jest zgodna z szeregiem zgodności z przepisami. Aby wyświetlić najnowszy zestaw współzależności, które zostały spełnione przez usługę SQL Database, odwiedź Centrum zaufania Microsoft i przejdź do szczegółów dotyczących współzależności, które są ważne dla Twojej organizacji, aby sprawdzić, czy usługa SQL Database jest uwzględniona w zgodnych usługach platformy Azure. Należy pamiętać, że chociaż usługa SQL Database jest certyfikowana jako zgodna usługa, pomaga ona w zgodności usługi organizacji, ale nie gwarantuje jej automatycznie.

Inteligentne monitorowanie i konserwacja bazy danych po migracji

Po przeprowadzeniu migracji bazy danych do usługi SQL Database chcesz monitorować bazę danych (na przykład sprawdzić, jak jest to użycie zasobów lub sprawdzanie kontroli DBCC) i przeprowadzić regularną konserwację (na przykład ponownie skompilować lub zreorganizować indeksy, statystyki itp.). Na szczęście usługa SQL Database jest inteligentna w tym sensie, że używa historycznych trendów i zarejestrowanych metryk i statystyk, aby aktywnie ułatwić monitorowanie i konserwowanie bazy danych, dzięki czemu aplikacja działa optymalnie zawsze. W niektórych przypadkach usługa Azure SQL Database może automatycznie wykonywać zadania konserwacji w zależności od konfiguracji. Istnieją trzy aspekty monitorowania bazy danych w usłudze SQL Database:

  • Monitorowanie i optymalizacja wydajności.
  • Optymalizacja zabezpieczeń.
  • Optymalizacja kosztów.

Monitorowanie i optymalizacja wydajności

Korzystając ze szczegółowych informacji o wydajności zapytań, możesz uzyskać dostosowane zalecenia dotyczące obciążenia bazy danych, aby aplikacje mogły działać na optymalnym poziomie — zawsze. Można go również skonfigurować tak, aby te rekomendacje były stosowane automatycznie i nie trzeba przejmować się wykonywaniem zadań konserwacji. Usługa SQL Database Advisor umożliwia automatyczne implementowanie zaleceń dotyczących indeksów na podstawie obciążenia — jest to nazywane dostrajaniem automatycznym. Zalecenia ewoluują wraz ze zmianami obciążenia aplikacji, aby zapewnić najbardziej odpowiednie sugestie. Możesz również ręcznie przejrzeć te zalecenia i zastosować je według własnego uznania.

Optymalizacja zabezpieczeń

Usługa SQL Database udostępnia zalecenia dotyczące zabezpieczeń, które ułatwiają zabezpieczanie danych i wykrywania zagrożeń w celu identyfikowania i badania podejrzanych działań bazy danych, które mogą stanowić potencjalny wątek dla bazy danych. Ocena luk w zabezpieczeniach to usługa skanowania i raportowania bazy danych, która umożliwia monitorowanie stanu zabezpieczeń baz danych na dużą skalę oraz identyfikowanie zagrożeń bezpieczeństwa i dryfowanie od punktu odniesienia zabezpieczeń zdefiniowanego przez Użytkownika. Po każdym skanowaniu zostanie udostępniona niestandardowa lista kroków możliwych do wykonania i skryptów korygowania, a także raport oceny, który może służyć do spełnienia wymagań dotyczących zgodności.

Dzięki Microsoft Defender dla Chmury można zidentyfikować zalecenia dotyczące zabezpieczeń w całej tablicy i szybko je zastosować.

Optymalizacja kosztów

Platforma Azure SQL analizuje historię wykorzystania w bazach danych na serwerze, aby ocenić i zalecić opcje optymalizacji kosztów. Ta analiza zwykle trwa kilka tygodni, aby analizować i tworzyć zalecenia umożliwiające podejmowanie działań.

Jak mogę monitorować wydajność i wykorzystanie zasobów w usłudze SQL Database

Wydajność i wykorzystanie zasobów w usłudze SQL Database można monitorować przy użyciu następujących metod:

Obserwator bazy danych

Obserwator bazy danych zbiera szczegółowe dane monitorowania obciążenia, aby uzyskać szczegółowy widok wydajności, konfiguracji i kondycji bazy danych. Pulpity nawigacyjne w witrynie Azure Portal zapewniają widok z jednym okienkiem szkła dla majątku usługi Azure SQL i szczegółowy widok każdego monitorowanego zasobu. Dane są zbierane w centralnym magazynie danych w ramach subskrypcji platformy Azure. Możesz wykonywać zapytania, analizować, eksportować, wizualizować zebrane dane i integrować je z systemami podrzędnymi.

Aby uzyskać więcej informacji na temat obserwatora bazy danych, zobacz następujące artykuły:

Azure Portal

W witrynie Azure Portal przedstawiono wykorzystanie bazy danych, wybierając bazę danych i wybierając wykres w okienku Przegląd. Możesz zmodyfikować wykres, aby wyświetlić wiele metryk, w tym procent procesora CPU, procent jednostek DTU, procent operacji we/wy danych, procent sesji i procent rozmiaru bazy danych.

Zrzut ekranu przedstawiający witrynę Azure Portal przedstawiający wykres monitorowania jednostek DTU bazy danych.

Na tym wykresie można również skonfigurować alerty według zasobu. Te alerty umożliwiają reagowanie na warunki zasobów za pomocą wiadomości e-mail, zapisywanie w punkcie końcowym HTTPS/HTTP lub wykonywanie akcji. Aby uzyskać więcej informacji, zobacz Tworzenie alertów.

Dynamiczne widoki zarządzania

Możesz wykonać zapytanie dotyczące dynamicznego widoku zarządzania sys.dm_db_resource_stats , aby zwrócić historię statystyk użycia zasobów z ostatniej godziny i widoku wykazu systemu sys.resource_stats w celu zwrócenia historii z ostatnich 14 dni.

Szczegółowe informacje o wydajności zapytań

Szczegółowe informacje o wydajności zapytań umożliwiają wyświetlenie historii zapytań zużywających najwięcej zasobów i długotrwałych zapytań dotyczących określonej bazy danych. Możesz szybko zidentyfikować zapytania TOP według wykorzystania zasobów, czasu trwania i częstotliwości wykonywania. Możesz śledzić zapytania i wykrywać regresję. Ta funkcja wymaga włączenia i aktywowania magazynu zapytań dla bazy danych.

Zrzut ekranu z witryny Azure Portal szczegółowych informacji o wydajności zapytań.

Występują problemy z wydajnością: jak moja metodologia rozwiązywania problemów z usługą SQL Database różni się od programu SQL Server

Główna część technik rozwiązywania problemów, których można użyć do diagnozowania problemów z zapytaniami i wydajnością bazy danych, pozostają takie same. Po tym, jak cały aparat bazy danych obsługuje chmurę. Jednak platforma — usługa Azure SQL Database ma wbudowaną funkcję "analizy". Ułatwia rozwiązywanie i diagnozowanie problemów z wydajnością. Może również wykonać niektóre z tych akcji naprawczych w Twoim imieniu, a w niektórych przypadkach proaktywnie je naprawić — automatycznie.

Podejście do rozwiązywania problemów z wydajnością może znacznie przynieść korzyści dzięki użyciu inteligentnych funkcji, takich jak szczegółowe informacje o wydajności zapytań (QPI) i doradca bazy danych w połączeniu, a więc różnica w metodologii różni się w tym zakresie — nie trzeba już wykonywać ręcznej pracy w celu zmielenia podstawowych szczegółów, które mogą pomóc w rozwiązaniu problemu. Platforma wykonuje ci ciężką pracę. Jednym z przykładów jest QPI. Za pomocą interfejsu QPI możesz przejść do szczegółów aż do poziomu zapytania i przyjrzeć się trendom historycznym i ustalić, kiedy dokładnie zapytanie ma regresję. Usługa Database Advisor udostępnia rekomendacje dotyczące elementów, które mogą pomóc w zwiększeniu ogólnej wydajności, na przykład — brak indeksów, upuszczanie indeksów, parametryzacja zapytań itp.

W przypadku rozwiązywania problemów z wydajnością ważne jest określenie, czy jest to tylko aplikacja, czy baza danych, która ma wpływ na wydajność aplikacji. Często problem z wydajnością leży w warstwie aplikacji. Może to być architektura lub wzorzec dostępu do danych. Rozważmy na przykład, że masz aplikację gadającą, która jest wrażliwa na opóźnienie sieci. W takim przypadku aplikacja cierpi, ponieważ między aplikacją a serwerem a serwerem i w sieci zatłoczonej będzie wiele krótkich żądań, które szybko się sumuje. Aby zwiększyć wydajność w tym przypadku, możesz użyć zapytań usługi Batch. Korzystanie z partii pomaga bardzo, ponieważ teraz żądania są przetwarzane w partii; w ten sposób pomaga zmniejszyć opóźnienie w obie strony i zwiększyć wydajność aplikacji.

Ponadto, jeśli zauważysz spadek ogólnej wydajności bazy danych, możesz monitorować sys.dm_db_resource_stats i sys.resource_stats dynamicznych widoków zarządzania, aby zrozumieć użycie procesora CPU, operacji we/wy i pamięci. Może to mieć wpływ na wydajność, ponieważ baza danych jest zagęszczone zasobami. Może być konieczne zmianę rozmiaru zasobów obliczeniowych i/lub warstwy usług na podstawie rosnących i zmniejszających się wymagań dotyczących obciążeń.

Aby uzyskać kompleksowy zestaw zaleceń dotyczących dostrajania problemów z wydajnością, zobacz: Dostrajanie bazy danych.

Jak mogę upewnij się, że używam odpowiedniej warstwy usług i rozmiaru zasobów obliczeniowych

Usługa SQL Database oferuje dwa różne modele zakupów: starszy model jednostek DTU i bardziej dostosowany model zakupów rdzeni wirtualnych. Aby uzyskać różnice między nimi, zobacz Porównanie modeli zakupów opartych na rdzeniach wirtualnych i jednostkach DTU w usłudze Azure SQL Database.

Aby upewnić się, że masz odpowiedni rozmiar obliczeniowy, możesz monitorować użycie zapytań i zasobów bazy danych w obu modelach zakupów. Aby uzyskać więcej informacji, zobacz Monitorowanie i dostrajanie wydajności. Jeśli okaże się, że zapytania/bazy danych stale działają na gorąco, możesz rozważyć skalowanie w górę do wyższego rozmiaru obliczeniowego. Podobnie, jeśli zauważysz, że nawet w godzinach szczytu, nie wydaje się używać zasobów tak samo; rozważ skalowanie w dół z bieżącego rozmiaru obliczeniowego. Możesz rozważyć użycie usługi Azure Automation do skalowania baz danych SQL zgodnie z harmonogramem.

Jeśli masz wzorzec aplikacji SaaS lub scenariusz konsolidacji bazy danych, rozważ użycie elastycznej puli na potrzeby optymalizacji kosztów. Elastyczna pula to doskonały sposób na osiągnięcie konsolidacji bazy danych i optymalizacji kosztów. Aby dowiedzieć się więcej na temat zarządzania wieloma bazami danych przy użyciu elastycznej puli, zobacz Zarządzanie pulami i bazami danych.

Jak często muszę uruchomić sprawdzanie integralności bazy danych dla mojej bazy danych

Usługa SQL Database używa niektórych inteligentnych technik, które umożliwiają automatyczne obsługę niektórych klas uszkodzenia danych i bez utraty danych. Te techniki są wbudowane w usługę i są używane przez usługę w razie potrzeby. W regularnych odstępach czasu kopie zapasowe bazy danych w usłudze są testowane przez ich przywrócenie i uruchomienie na niej bazy danych DBCC CHECKDB. Jeśli występują problemy, usługa SQL Database aktywnie je rozwiązuje. Automatyczna naprawa strony służy do naprawiania stron, które są uszkodzone lub mają problemy z integralnością danych. Strony bazy danych są zawsze weryfikowane przy użyciu domyślnego ustawienia SUMY KONTROLNEJ, które weryfikuje integralność strony. Usługa SQL Database aktywnie monitoruje i przegląda integralność danych bazy danych oraz, jeśli wystąpią problemy, rozwiązuje je z najwyższym priorytetem. Oprócz tych opcji możesz opcjonalnie uruchomić własne kontrole integralności. Aby uzyskać więcej informacji, zobacz Integralność danych w usłudze SQL Database

Przenoszenie danych po migracji

Jak mogę eksportowanie i importowanie danych jako plików BACPAC z usługi SQL Database przy użyciu witryny Azure Portal

  • Eksportowanie: bazę danych można wyeksportować w usłudze Azure SQL Database jako plik BACPAC z witryny Azure Portal

Zrzut ekranu z witryny Azure Portal przycisku Eksportuj bazę danych w bazie danych Azure SQL Database.

  • Importowanie: możesz również zaimportować dane jako plik BACPAC do bazy danych w usłudze Azure SQL Database przy użyciu witryny Azure Portal.

Zrzut ekranu z witryny Azure Portal przycisku Importuj bazę danych na serwerze Azure SQL.

Jak mogę synchronizować dane między usługą SQL Database i programem SQL Server

Istnieje kilka sposobów, aby to osiągnąć:

  • Data Sync — ta funkcja ułatwia synchronizowanie danych dwukierunkowo między wieloma bazami danych programu SQL Server i usługą SQL Database. Aby przeprowadzić synchronizację z bazami danych programu SQL Server, należy zainstalować i skonfigurować agenta synchronizacji na komputerze lokalnym lub maszynie wirtualnej i otworzyć wychodzący port TCP 1433.
  • Replikacja transakcji — dzięki replikacji transakcji można synchronizować dane z bazy danych programu SQL Server do usługi Azure SQL Database z wystąpieniem programu SQL Server, które jest wydawcą, a usługa Azure SQL Database jest subskrybentem. Na razie obsługiwana jest tylko ta konfiguracja. Aby uzyskać więcej informacji na temat migrowania danych z bazy danych programu SQL Server do usługi Azure SQL z minimalnym przestojem, zobacz: Korzystanie z replikacji transakcji