Scenariusze zabezpieczeń klastra usługi Service Fabric

Artykuł
10/18/2023

Klaster usługi Azure Service Fabric to zasób, którego jesteś właścicielem. Twoim zadaniem jest zabezpieczenie klastrów, aby uniemożliwić nieautoryzowanym użytkownikom łączenie się z nimi. Bezpieczny klaster jest szczególnie ważny w przypadku uruchamiania obciążeń produkcyjnych w klastrze. Istnieje możliwość utworzenia niezabezpieczonego klastra, jednak jeśli klaster uwidacznia punkty końcowe zarządzania publicznym Internetem, anonimowi użytkownicy mogą się z nim łączyć. Niezabezpieczone klastry nie są obsługiwane w przypadku obciążeń produkcyjnych.

Ten artykuł zawiera omówienie scenariuszy zabezpieczeń dla klastrów platformy Azure i klastrów autonomicznych oraz różnych technologii, których można użyć do ich zaimplementowania:

Zabezpieczenia węzła-węzła
Zabezpieczenia klient-węzeł
Kontrola dostępu oparta na rolach usługi Service Fabric

Zabezpieczenia węzła-węzła

Zabezpieczenia między węzłami ułatwiają bezpieczną komunikację między maszynami wirtualnymi lub komputerami w klastrze. Ten scenariusz zabezpieczeń gwarantuje, że tylko komputery, które są autoryzowane do dołączenia do klastra, mogą uczestniczyć w hostowanie aplikacji i usług w klastrze.

Diagram of node-to-node communication

Klastry działające na platformie Azure i klastry autonomiczne działające w systemie Windows mogą używać zabezpieczeń certyfikatów lub zabezpieczeń systemu Windows dla komputerów z systemem Windows Server.

Zabezpieczenia certyfikatów typu węzeł-węzeł

Usługa Service Fabric używa certyfikatów serwera X.509 określonych w ramach konfiguracji typu węzła podczas tworzenia klastra. Zabezpieczenia certyfikatów można skonfigurować w witrynie Azure Portal przy użyciu szablonu usługi Azure Resource Manager lub autonomicznego szablonu JSON. Na końcu tego artykułu możesz zapoznać się z krótkim omówieniem tego, czym są te certyfikaty i jak można je uzyskać lub utworzyć.

Domyślne zachowanie zestawu SDK usługi Service Fabric polega na wdrożeniu i zainstalowaniu certyfikatu z najdalej w przyszłej dacie wygaśnięcia. Ten certyfikat podstawowy powinien być inny niż certyfikat klienta administratora i certyfikaty klienta tylko do odczytu ustawione dla zabezpieczeń klient-węzeł. Klasyczne zachowanie zestawu SDK zezwalało na definiowanie certyfikatów podstawowych i pomocniczych w celu umożliwienia ręcznego inicjowania przerzucania; nie zaleca się używania jej w przypadku nowych funkcji.

Aby dowiedzieć się, jak skonfigurować zabezpieczenia certyfikatów w klastrze dla platformy Azure, zobacz Konfigurowanie klastra przy użyciu szablonu usługi Azure Resource Manager.

Aby dowiedzieć się, jak skonfigurować zabezpieczenia certyfikatów w klastrze dla autonomicznego klastra systemu Windows Server, zobacz Zabezpieczanie autonomicznego klastra w systemie Windows przy użyciu certyfikatów X.509.

Zabezpieczenia systemu Windows z węzłem do węzła

Uwaga

Uwierzytelnianie systemu Windows jest oparte na protokole Kerberos. Protokół NTLM nie jest obsługiwany jako typ uwierzytelniania.

Jeśli to możliwe, użyj uwierzytelniania certyfikatu X.509 dla klastrów usługi Service Fabric.

Aby dowiedzieć się, jak skonfigurować zabezpieczenia systemu Windows dla autonomicznego klastra systemu Windows Server, zobacz Zabezpieczanie autonomicznego klastra w systemie Windows przy użyciu zabezpieczeń systemu Windows.

Zabezpieczenia klient-węzeł

Zabezpieczenia klient-węzeł uwierzytelniają klientów i pomagają zabezpieczyć komunikację między klientem a poszczególnymi węzłami w klastrze. Ten typ zabezpieczeń pomaga zagwarantować, że tylko autoryzowani użytkownicy będą mogli uzyskiwać dostęp do klastra i aplikacji wdrożonych w klastrze. Klienci są jednoznacznie identyfikowani za pomocą poświadczeń zabezpieczeń systemu Windows lub poświadczeń zabezpieczeń certyfikatu.

Diagram of client-to-node communication

Klastry działające na platformie Azure i autonomicznych klastrach działających w systemie Windows mogą używać zabezpieczeń certyfikatów lub zabezpieczeń systemu Windows, chociaż zaleceniem jest użycie uwierzytelniania certyfikatu X.509, jeśli jest to możliwe.

Zabezpieczenia certyfikatu klient-węzeł

Skonfiguruj zabezpieczenia certyfikatu klient-węzeł podczas tworzenia klastra w witrynie Azure Portal przy użyciu szablonu usługi Resource Manager lub przy użyciu autonomicznego szablonu JSON. Aby utworzyć certyfikat, określ certyfikat klienta administratora lub certyfikat klienta użytkownika. Najlepszym rozwiązaniem jest to, że określone certyfikaty klienta administratora i klienta użytkownika powinny być inne niż certyfikaty podstawowe i pomocnicze określone dla zabezpieczeń typu node-to-node. Certyfikaty klastra mają takie same uprawnienia jak certyfikaty administratora klienta. Jednak powinny one być używane tylko przez klaster, a nie przez użytkowników administracyjnych jako najlepsze rozwiązanie w zakresie zabezpieczeń.

Klienci łączący się z klastrem przy użyciu certyfikatu administratora mają pełny dostęp do funkcji zarządzania. Klienci łączący się z klastrem przy użyciu certyfikatu klienta użytkownika tylko do odczytu mają dostęp tylko do odczytu do funkcji zarządzania. Te certyfikaty są używane dla kontroli dostępu opartej na rolach usługi Service Fabric opisanej w dalszej części tego artykułu.

Aby dowiedzieć się, jak skonfigurować zabezpieczenia certyfikatów w klastrze dla platformy Azure, zobacz Konfigurowanie klastra przy użyciu szablonu usługi Azure Resource Manager.

Zabezpieczenia typu klient-węzeł firmy Microsoft na platformie Azure

Microsoft Entra ID umożliwia organizacjom (znanym jako dzierżawy) zarządzanie dostępem użytkowników do aplikacji. Aplikacje są podzielone na aplikacje z internetowym interfejsem użytkownika logowania i aplikacjami z natywnym środowiskiem klienta. Jeśli nie masz jeszcze utworzonej dzierżawy, zacznij od zapoznania się z artykułem Jak uzyskać dzierżawę firmy Microsoft Entra.

W przypadku klastrów działających na platformie Azure można również użyć identyfikatora Entra firmy Microsoft, aby zabezpieczyć dostęp do punktów końcowych zarządzania. Klaster usługi Service Fabric udostępnia kilka punktów wejścia dla swoich funkcji zarządzania, w tym internetowe narzędzie Service Fabric Explorer i program Visual Studio. W związku z tym, aby kontrolować dostęp do klastra, należy utworzyć dwie aplikacje firmy Microsoft Entra: jedną aplikację internetową i jedną aplikację natywną. Aby dowiedzieć się, jak utworzyć wymagane artefakty entra firmy Microsoft i jak je wypełnić podczas tworzenia klastra, zobacz Konfigurowanie identyfikatora Entra firmy Microsoft w celu uwierzytelniania klientów.

Zalecenia dotyczące zabezpieczeń

W przypadku klastrów usługi Service Fabric wdrożonych w sieci publicznej hostowanej na platformie Azure zalecenia dla wzajemnego uwierzytelniania klienta i węzła są następujące:

Używanie identyfikatora Entra firmy Microsoft dla tożsamości klienta
Certyfikat tożsamości serwera i szyfrowania TLS komunikacji http

W przypadku klastrów usługi Service Fabric wdrożonych w sieci publicznej hostowanej na platformie Azure zaleca się użycie certyfikatu klastra do uwierzytelniania węzłów.

W przypadku autonomicznych klastrów systemu Windows Server, jeśli masz systemy Windows Server 2012 R2 i Windows Active Directory, zalecamy używanie zabezpieczeń systemu Windows z kontami usług zarządzanymi przez grupę. W przeciwnym razie użyj zabezpieczeń systemu Windows z kontami systemu Windows.

Kontrola dostępu oparta na rolach usługi Service Fabric

Możesz użyć kontroli dostępu, aby ograniczyć dostęp do niektórych operacji klastra dla różnych grup użytkowników. Pomaga to zwiększyć bezpieczeństwo klastra. W przypadku klientów łączących się z klastrem są obsługiwane dwa typy kontroli dostępu: rola Administracja istratora i rola użytkownika.

Użytkownicy, którym przypisano rolę Administracja istrator, mają pełny dostęp do funkcji zarządzania, w tym możliwości odczytu i zapisu. Użytkownicy, którym przypisano rolę Użytkownik, domyślnie mają dostęp tylko do odczytu do funkcji zarządzania (na przykład możliwości zapytań). Mogą również rozwiązywać problemy z aplikacjami i usługami.

Podczas tworzenia klastra ustaw role Administracja istratora i klienta użytkownika. Przypisz role, udostępniając oddzielne tożsamości (na przykład przy użyciu certyfikatów lub identyfikatora Entra firmy Microsoft) dla każdego typu roli. Aby uzyskać więcej informacji na temat domyślnych ustawień kontroli dostępu i sposobu zmiany ustawień domyślnych, zobacz Kontrola dostępu oparta na rolach usługi Service Fabric dla klientów usługi Service Fabric.

Certyfikaty X.509 i usługa Service Fabric

Certyfikaty cyfrowe X.509 są często używane do uwierzytelniania klientów i serwerów. Są one również używane do szyfrowania i cyfrowego podpisywania wiadomości. Usługa Service Fabric używa certyfikatów X.509 do zabezpieczania klastra i zapewniania funkcji zabezpieczeń aplikacji. Aby uzyskać więcej informacji na temat certyfikatów cyfrowych X.509, zobacz Praca z certyfikatami. Usługa Key Vault służy do zarządzania certyfikatami dla klastrów usługi Service Fabric na platformie Azure.

Należy wziąć pod uwagę kilka ważnych kwestii:

Aby utworzyć certyfikaty dla klastrów z uruchomionymi obciążeniami produkcyjnymi, użyj poprawnie skonfigurowanej usługi certyfikatów systemu Windows Server lub certyfikatu z zatwierdzonego urzędu certyfikacji.
Nigdy nie używaj żadnych tymczasowych lub testowych certyfikatów tworzonych przy użyciu narzędzi, takich jak MakeCert.exe w środowisku produkcyjnym.
Możesz użyć certyfikatu z podpisem własnym, ale tylko w klastrze testowym. Nie używaj certyfikatu z podpisem własnym w środowisku produkcyjnym.
Podczas generowania odcisku palca certyfikatu pamiętaj, aby wygenerować odcisk palca SHA1. Algorytm SHA1 jest używany podczas konfigurowania odcisków palca certyfikatu klienta i klastra.

Certyfikat klastra i serwera (wymagany)

Te certyfikaty (jeden podstawowy i opcjonalnie pomocniczy) są wymagane do zabezpieczenia klastra i zapobiegania nieautoryzowanemu dostępowi do niego. Te certyfikaty zapewniają uwierzytelnianie klastra i serwera.

Uwierzytelnianie klastra uwierzytelnia komunikację między węzłami na potrzeby federacji klastra. Tylko węzły, które mogą udowodnić swoją tożsamość za pomocą tego certyfikatu, mogą dołączyć do klastra. Uwierzytelnianie serwera uwierzytelnia punkty końcowe zarządzania klastrem do klienta zarządzania, dzięki czemu klient zarządzania wie, że rozmawia z rzeczywistym klastrem, a nie z "człowiekiem w środku". Ten certyfikat udostępnia również protokół TLS dla interfejsu API zarządzania HTTPS i dla narzędzia Service Fabric Explorer za pośrednictwem protokołu HTTPS. Gdy klient lub węzeł uwierzytelnia węzeł, jednym z początkowych testów jest wartość nazwy pospolitej w polu Podmiot . Ta nazwa pospolita lub jedna z alternatywnych nazw podmiotów certyfikatów (SAN) musi znajdować się na liście dozwolonych nazw pospolitych.

Certyfikat musi spełniać następujące wymagania:

Certyfikat musi zawierać klucz prywatny. Te certyfikaty zwykle mają rozszerzenia pfx lub pem
Certyfikat należy utworzyć na potrzeby wymiany kluczy, który można wyeksportować do pliku wymiany informacji osobistych (pfx).
Nazwa podmiotu certyfikatu musi być zgodna z domeną używaną do uzyskiwania dostępu do klastra usługi Service Fabric. To dopasowanie jest wymagane do zapewnienia protokołu TLS dla punktu końcowego zarządzania HTTPS klastra i narzędzia Service Fabric Explorer. Nie można uzyskać certyfikatu TLS/SSL z urzędu certyfikacji dla domeny *.cloudapp.azure.com. Musisz uzyskać niestandardową nazwę domeny dla klastra. W przypadku żądania certyfikatu od urzędu certyfikacji nazwa podmiotu certyfikatu musi być zgodna z niestandardową nazwą domeny używaną dla danego klastra.

Kilka innych kwestii, które należy wziąć pod uwagę:

Pole Temat może mieć wiele wartości. Każda wartość jest poprzedzona inicjacją, aby wskazać typ wartości. Zazwyczaj inicjowanie to CN (nazwa pospolita), na przykład CN = www.contoso.com.
Pole Temat może być puste.
Jeśli pole opcjonalnej alternatywnej nazwy podmiotu jest wypełnione, musi mieć zarówno nazwę pospolitą certyfikatu, jak i jeden wpis dla sieci SAN. Są one wprowadzane jako wartości nazwy DNS. Aby dowiedzieć się, jak wygenerować certyfikaty z sieciami SAN, zobacz Jak dodać alternatywną nazwę podmiotu do bezpiecznego certyfikatu LDAP.
Wartość pola Zamierzone cele certyfikatu powinna zawierać odpowiednią wartość, taką jak uwierzytelnianie serwera lub uwierzytelnianie klienta.

Certyfikaty aplikacji (opcjonalnie)

W klastrze można zainstalować dowolną liczbę dodatkowych certyfikatów na potrzeby zabezpieczeń aplikacji. Przed utworzeniem klastra należy wziąć pod uwagę scenariusze zabezpieczeń aplikacji, które wymagają zainstalowania certyfikatu w węzłach, takich jak:

Szyfrowanie i odszyfrowywanie wartości konfiguracji aplikacji.
Szyfrowanie danych między węzłami podczas replikacji.

Koncepcja tworzenia bezpiecznych klastrów jest taka sama, niezależnie od tego, czy są to klastry systemu Linux, czy Windows.

Certyfikaty uwierzytelniania klienta (opcjonalnie)

Dla operacji administratora lub klienta użytkownika można określić dowolną liczbę dodatkowych certyfikatów. Klient może używać tych certyfikatów, gdy wymagane jest wzajemne uwierzytelnianie. Certyfikaty klienta zazwyczaj nie są wystawiane przez urząd certyfikacji innej firmy. Zamiast tego magazyn osobisty bieżącej lokalizacji użytkownika zwykle zawiera certyfikaty klienta umieszczone tam przez urząd główny. Certyfikat powinien mieć wartość Zamierzone cele uwierzytelniania klienta.

Domyślnie certyfikat klastra ma uprawnienia klienta administratora. Te dodatkowe certyfikaty klienta nie powinny być instalowane w klastrze, ale są określane jako dozwolone w konfiguracji klastra. Jednak certyfikaty klienta muszą być zainstalowane na maszynach klienckich, aby nawiązać połączenie z klastrem i wykonywać wszelkie operacje.