Rozwiązanie dla scenariusza 1 — tworzenie architektury na skalę globalną z bezpiecznym dostępem
W poprzedniej lekcji prześledzono scenariusz dotyczący sieci dostarczania zawartości działającej w skali globalnej. W tej lekcji przejrzysz jedno potencjalne rozwiązanie i zwrócisz uwagę na kilka 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
Pierwszą decyzją, którą należy podjąć, jest to, którą opcję wdrażania usługi Azure SQL należy wybrać. Chociaż program SQL Server działający na maszynie wirtualnej (VM) platformy Azure spełnia podstawowe zadania, oferta platformy jako usługi (PaaS) może zapewnić lepszą wydajność przy mniejszym nakładzie pracy związanym z zarządzaniem.
Klient korzysta ze środowiska uruchomieniowego języka wspólnego (CLR), które jest funkcją o zakresie wystąpienia. Usługa Azure SQL Managed Instance to jedyna opcja wdrożenia PaaS, która obsługuje funkcje działające w zakresie wystąpienia, takie jak CLR, Service Broker i Poczta bazy danych. Z tego powodu usługa Azure SQL Managed Instance może umożliwiać klientowi przejście do oferty PaaS bez konieczności ponownego pisania aplikacji CLR w rozwiązaniu zgodnym z usługą Azure SQL Database (na przykład elastycznych zadań bazy danych).
Następna decyzja dotyczy warstwy usługi. Ponieważ klient wymaga odizolowania obciążeń odczytu i zapisu, użycie warstwy usługi krytycznej dla działania firmy będzie najprostszym sposobem osiągnięcia tego celu. Warstwa usługi krytycznej dla działania firmy ma zawsze włączoną grupę dostępności działającą w tle. Jedna z tych replik pomocniczych może być używana do obciążeń tylko do odczytu.
Wybranie warstwy krytycznej dla działania firmy to dopiero połowa konfiguracji mającej na celu oddzielenie obciążeń odczytu i zapisu. W scenariuszu klient zapisał wymaganie możliwości przeprowadzenia skalowania w wielu regionach z wieloma zapytaniami obsługiwanymi w tym samym czasie z jednoczesną izolacją obciążeń odczytu i zapisu.
Dwie opcje, które mogą potencjalnie spełnić te wymagania, to replikacja geograficzna i grupy automatycznego trybu failover. Replikacja geograficzna nie jest jednak obecnie obsługiwana w usłudze Azure SQL Managed Instance. Z tego powodu użycie grupy automatycznego trybu failover jest jedyną opcją, która może spełnić wymagania odczytu na globalną skalę dla tego scenariusza.
Ponieważ klient korzysta z grup automatycznego trybu failover to, czy konieczna jest warstwa usługi krytycznej dla działania firmy, czy też nie, będzie uzależnione od liczby punktów końcowych tylko do odczytu wymaganych przez obciążenie analityczne. Dzięki grupie automatycznego trybu failover w warstwie usługi krytycznej dla działania firmy klient uzyska trzy umożliwiające odczyt punkty końcowe:
- Jedna replika pomocnicza z grupy dostępności regionu podstawowego
- Pomocnicza grupa trybu failover (będąca podstawową repliką bazy danych w regionie pomocniczym)
- Replika pomocnicza z grupy dostępności regionu pomocniczego
Jeśli obciążenie analityczne nie wymaga wszystkich tych możliwych do odczytania replik, użycie warstwy ogólnego przeznaczenia może być bardziej opłacalne.
Wybieranie najbardziej odpowiednich metod uwierzytelniania
Ważnym elementem tego scenariusza jest określenie najlepszego dla poszczególnych aplikacji lub osób sposobu nawiązywania połączenia z rozwiązaniem przy uwzględnieniu użycia technologii zapewniających jak największe bezpieczeństwo. Scenariusz obejmuje konieczność uzyskiwania dostępu do usługi Azure SQL Managed Instance przez czterech oddzielnych klientów:
- Aplikacja działająca na maszynie wirtualnej platformy Azure
- Aplikacja na maszynie spoza platformy Azure przyłączonej do domeny
- Analitycy bazy danych lub inni użytkownicy narzędzi administracyjnych SQL (SQL Server Management Studio, Azure Data Studio, PowerShell) z maszyny spoza platformy Azure nieprzyłączonej do domeny
- Starsze aplikacje działające na maszynie spoza platformy Azure, w przypadku których nie można zmienić sterownika lub parametrów połączenia
Przyjrzyjmy się tym klientom pod kątem sposobu wyboru metody uwierzytelniania oraz pewnych dodatkowych zagadnień i ograniczeń.
Aplikacja działająca na maszynie wirtualnej platformy Azure
W przypadku aplikacji działających na maszynach wirtualnych platformy Azure zalecaną formą uwierzytelniania bez hasła są tożsamości zarządzane dla zasobów platformy Azure.
Aplikacja na maszynie spoza platformy Azure przyłączonej do domeny
W przypadku maszyn spoza platformy Azure używanie tożsamości zarządzanych nie jest możliwe. Zintegrowane uwierzytelnianie za pośrednictwem identyfikatora Entra firmy Microsoft to zalecana metoda uwierzytelniania dla aplikacji działających na maszynach przyłączonych do domeny poza platformą Azure przy założeniu, że domena została sfederowana z identyfikatorem Entra firmy Microsoft.
Jeśli maszyna spoza platformy Azure nie jest przyłączona do domeny, możesz:
- Utwórz tożsamość aplikacji dla aplikacji w identyfikatorze Entra firmy Microsoft.
- Skojarzyć certyfikat z tożsamością aplikacji.
- Zmodyfikować swoją aplikację, aby uzyskać token dla usługi Azure SQL Database, podając identyfikator klienta i certyfikat.
Pomimo że certyfikat musi zawierać klucz prywatny i musi zostać wdrożony na komputerze hostującym aplikację, unika się przynajmniej kodowania wpisu tajnego aplikacji w kodzie aplikacji lub plikach konfiguracji. (Wystarczy skonfigurować aplikację przy użyciu odcisku palca certyfikatu).
Analitycy DBA lub inni użytkownicy narzędzi administracyjnych SQL z maszyny spoza platformy Azure nieprzyłączonej do domeny
W przypadku użytkowników spoza platformy Azure wszędzie tam, gdzie jest to możliwe, najlepiej jest unikać korzystania z haseł. Używanie haseł za pomocą narzędzi SQL można wyeliminować przy użyciu zintegrowanego uwierzytelniania firmy Microsoft Entra. Jednak narzędzia muszą działać na maszynie przyłączonej do domeny, a domena musi być sfederowana z identyfikatorem Microsoft Entra ID, co nie jest możliwe w tym scenariuszu.
Ponieważ środowisko nie spełnia wymagań wstępnych dotyczących zintegrowanego uwierzytelniania, zalecamy użycie uwierzytelniania interakcyjnego firmy Microsoft Entra z uwierzytelnianiem wieloskładnikowym, które obsługuje większość narzędzi SQL.
Starsze aplikacje działające na maszynie spoza platformy Azure, w przypadku których nie można zmienić sterownika lub parametrów połączenia
W scenariuszach, w których nie można zmienić sterownika lub parametrów połączenia, opcja eliminowania haseł dzisiaj nie istnieje. Te starsze aplikacje muszą nadal korzystać z uwierzytelniania SQL. Możesz rozważyć dokładniejsze poznanie ograniczeń i sposobu ich wycofania w celu użycia bezpieczniejszego i chronionego podejścia do uwierzytelniania aplikacji.