Rozwiązanie dla scenariusza 2 — aplikacja o znaczeniu krytycznym
W poprzedniej lekcji omówiono scenariusz obejmujący wysoką dostępność dla systemu numeru 112. W tej lekcji przejrzysz jedno potencjalne rozwiązanie i zwrócisz uwagę na kilka innych istotnych elementów.
Podczas przeglądu należy porównać udostępnione rozwiązanie z tym, które utworzono w poprzedniej lekcji. Często istnieje więcej niż jedno poprawne rozwiązanie problemu, ale zawsze należy brać pod uwagę wszelkie plusy i minusy. Które elementy Twojego rozwiązania różnią się od elementów proponowanych? Czy w Twoim rozwiązaniu istnieje coś, co można jeszcze przemyśleć? Czy według Ciebie w Twoim rozwiązaniu istnieją elementy bardziej uniwersalne niż w rozwiązaniu udostępnionym?
Opcja wdrażania i konfiguracja
Jedną z pierwszych decyzji, jakie należy podjąć, jest często określenie potencjalnie najlepszej opcji wdrażania usługi Azure SQL. Jeśli rozważasz tylko umowę dotyczącą poziomu usług (SLA), wymagana jest umowa SLA na 99,995%, którą może zapewnić tylko usługa Azure SQL Database. Aby uzyskać tę umowę SLA, musisz wdrożyć warstwę usługi krytycznej dla działania firmy i włączyć korzystanie ze stref dostępności.
Następne decyzje są związane ze sposobem włączania nadmiarowości geograficznej i zapewnienia wysokiej dostępności w przypadku awarii. Chociaż w tym przypadku można skorzystać zarówno z opcji replikacji geograficznej, jak i grup automatycznego trybu failover, skorzystanie z grup automatycznego trybu failover umożliwi klientowi przejście w tryb failover, jeśli będzie to wymagane, bez konieczności zmiany jakichkolwiek parametrów połączenia. Taka konfiguracja może pomóc w skróceniu czasu przestoju spowodowanego koniecznością zaktualizowania parametrów połączenia aplikacji, ponieważ nie będzie to konieczne. Możesz również skonfigurować zapytania monitorowania, aby sprawdzić stan. Dzięki temu, jeśli coś pójdzie nie tak, możesz nawet wymusić przejście w tryb failover.
W tej konfiguracji ważne jest również, aby wziąć pod uwagę rolę, jaką odgrywa kolokacja. Aby zapewnić wysoką dostępność, aplikacja musi znajdować się jak najbliżej bazy danych, najlepiej w tym samym regionie. Upewnij się, że aplikacja jest wdrożona w obu regionach grupy automatycznego trybu failover, a w konsekwencji, że istnieje nadmiarowa kopia aplikacji (na przykład aplikacji internetowej). W przypadku konieczności przejścia w tryb failover można przekierować ruch do aplikacji w regionie pomocniczym za pomocą usługi Azure Traffic Manager.
Administratorzy baz danych i dane poufne
Koordynatorzy systemu wysyłania powiadomień na numer 911 obawiają się o bezpieczeństwo poufnych danych (takich jak historia stanu zdrowotnego czy inne informacje osobiste), jeśli zezwolą administratorom baz danych na wykonywanie swoich zadań.
Aby zagwarantować, że DBA nie będą mieli wglądu w poufne dane przechowywane w konkretnych kolumnach, oraz aby zapewnić pełne monitorowanie całego dostępu do tabel zawierających poufne dane, można skorzystać z kilku technologii Azure SQL. Usługa SQL Audit to najlepsze rozwiązanie do monitorowania dostępu, ale nie ograniczy ona możliwości wglądu w dane przez administratorów baz danych. W tej sytuacji może pomóc klasyfikowanie poufnych danych przy użyciu usługi Data Classification, ponieważ poufne dane będą oznaczane etykietami, dzięki czemu będzie można je śledzić za pomocą usługi SQL Audit. Jednak nawet po zaimplementowaniu tych środków administratorzy baz danych nadal będą mieli wgląd w poufne dane. Do maskowania poufnych danych można wykorzystać funkcję dynamicznego maskowania danych, ale nie zapobiegnie to możliwości przeglądania danych użytkowników przez użytkownika z uprawnieniami db_owner.
Jeśli w bazie danych znajdują się wysoce poufne dane, funkcja Always Encrypted może w bezpieczny sposób uniemożliwić ich wyświetlanie nawet przez właścicieli baz danych. Kluczami funkcji Always Encrypted można zarządzać, korzystając z separacji ról, dzięki czemu administrator zabezpieczeń nie będzie mógł uzyskać dostępu do bazy danych, a administrator baz danych nie będzie miał dostępu do kluczy fizycznych przechowywanych w postaci zwykłego tekstu. Stosując taką strategię w połączeniu z monitorowaniem za pośrednictwem usługi SQL Audit, można monitorować, maskować i śledzić dostęp do poufnych danych uzyskiwany nawet przez administratorów baz danych z uprawnieniami db_owner.
Analitycy DBA muszą mieć zamaskowane poufne dane, ale nadal muszą mieć możliwość rozwiązywania problemów z wydajnością przy użyciu witryny Azure Portal, usługi SQL Server Management Studio lub Azure Data Studio. Ponadto muszą mieć możliwość tworzenia nowych użytkowników zawartej bazy danych, którzy muszą być mapowane na podmioty zabezpieczeń firmy Microsoft.
Jednym z rozwiązań jest utworzenie grupy firmy Microsoft Entra o nazwie SQL DBA dla administratorów baz danych w każdym wystąpieniu. Następnie należy przypisać grupę do roli kontroli dostępu opartej na rolach (RBAC) na platformie Azure dla współautora programu SQL Server. Na koniec możesz ustawić grupę jako administratora firmy Microsoft Entra na serwerze logicznym.