Udostępnij za pośrednictwem

Uwierzytelnianie oparte na certyfikatach X.509 w klastrach usługi Service Fabric

  • Artykuł

Ten artykuł uzupełnia wprowadzenie do zabezpieczeń klastra usługi Service Fabric i zawiera szczegółowe informacje na temat uwierzytelniania opartego na certyfikatach w klastrach usługi Service Fabric. Zakładamy, że czytelnik zna podstawowe pojęcia związane z zabezpieczeniami, a także kontrolki udostępniane przez usługę Service Fabric w celu kontrolowania zabezpieczeń klastra.

Tematy omówione w tym tytule:

  • Podstawy uwierzytelniania opartego na certyfikatach
  • Tożsamości i ich odpowiednie role
  • Reguły konfiguracji certyfikatu
  • Rozwiązywanie problemów i często zadawane pytania

Podstawy uwierzytelniania opartego na certyfikatach

Jako krótki moduł odświeżania, w zabezpieczeniach, certyfikat jest instrumentem służącym do powiązania informacji dotyczących jednostki (podmiotu) z posiadaniem pary kluczy kryptograficznych asymetrycznych, a więc stanowi podstawową konstrukcję kryptografii klucza publicznego. Klucze reprezentowane przez certyfikat mogą być używane do ochrony danych lub do potwierdzania tożsamości posiadaczy kluczy; w połączeniu z systemem infrastruktury kluczy publicznych (PKI) certyfikat może reprezentować dodatkowe cechy jego podmiotu, takie jak własność domeny internetowej lub pewne uprawnienia przyznane przez wystawcę certyfikatu (nazywanego urzędem certyfikacji lub urzędem certyfikacji). Typowym zastosowaniem certyfikatów jest obsługa protokołu kryptograficznego Transport Layer Security (TLS), co umożliwia bezpieczną komunikację za pośrednictwem sieci komputerowej. W szczególności klient i serwer używają certyfikatów w celu zapewnienia prywatności i integralności komunikacji, a także do przeprowadzania wzajemnego uwierzytelniania.

W usłudze Service Fabric podstawowa warstwa klastra (federacji) opiera się również na protokole TLS (między innymi protokołami), aby uzyskać niezawodną, bezpieczną sieć uczestniczących węzłów. Połączenia z klastrem za pośrednictwem interfejsów API klienta usługi Service Fabric używają protokołu TLS, a także do ochrony ruchu, a także do ustanawiania tożsamości stron. W szczególności, jeśli jest używany do uwierzytelniania w usłudze Service Fabric, certyfikat może służyć do udowodnienia następujących oświadczeń: a) prezenter poświadczenia certyfikatu ma posiadanie klucza prywatnego certyfikatu b) skrót SHA-1 certyfikatu ('odcisk palca') pasuje do deklaracji zawartej w definicji klastra lub c) wyróżniającej podmiotu certyfikatu pasuje do deklaracji zawartej w definicji klastra, i wystawca certyfikatu jest znany lub zaufany.

Na powyższej liście "b" jest potocznie znany jako "przypinanie odcisku palca"; w tym przypadku deklaracja odwołuje się do określonego certyfikatu, a siła schematu uwierzytelniania opiera się na założeniu, że jest nie do obliczenia, aby utworzyć certyfikat, który generuje tę samą wartość skrótu co inny, a jednocześnie jest prawidłowym, dobrze sformułowanym obiektem we wszystkich pozostałych względach. Element "c" reprezentuje alternatywną formę deklarowania certyfikatu, gdzie siła schematu opiera się na połączeniu podmiotu świadectwa i urzędu wystawiającego. W takim przypadku deklaracja odwołuje się do klasy certyfikatów — wszystkie dwa certyfikaty o tych samych cechach są uważane za w pełni równoważne.

W poniższych sekcjach wyjaśniono szczegółowo, jak środowisko uruchomieniowe usługi Service Fabric używa i weryfikuje certyfikaty w celu zapewnienia bezpieczeństwa klastra.

Tożsamości i ich odpowiednie role

Przed zagłębiniem się w szczegóły uwierzytelniania lub zabezpieczania kanałów komunikacyjnych ważne jest, aby wyświetlić listę uczestniczących aktorów i odpowiednie role, które odgrywają w klastrze:

  • środowisko uruchomieniowe usługi Service Fabric określane jako "system": zestaw usług, które zapewniają abstrakcję i funkcjonalność reprezentującą klaster. W przypadku odwoływania się do komunikacji w klastrze między wystąpieniami systemu użyjemy terminu "tożsamość klastra"; w przypadku odwoływania się do klastra jako adresata/celu ruchu spoza klastra użyjemy terminu "tożsamość serwera".
  • hostowane aplikacje, nazywane "aplikacjami": kod dostarczony przez właściciela klastra, który jest zorganizowany i wykonywany w klastrze
  • klienci: jednostki dozwolone do nawiązywania połączenia i wykonywania funkcji w klastrze zgodnie z konfiguracją klastra. Rozróżniamy odpowiednio dwa poziomy uprawnień — "użytkownik" i "administrator". Klient "użytkownika" jest ograniczony głównie do operacji tylko do odczytu (ale nie wszystkich funkcji tylko do odczytu), podczas gdy klient "administrator" ma nieograniczony dostęp do funkcji klastra. (Aby uzyskać więcej informacji, zobacz Role zabezpieczeń w klastrze usługi Service Fabric).
  • (tylko platforma Azure) usługi Service Fabric, które organizuje i udostępniają mechanizmy kontroli dla operacji i zarządzania klastrami usługi Service Fabric, nazywanych po prostu "usługą". W zależności od środowiska "usługa" może odwoływać się do dostawcy zasobów usługi Azure Service Fabric lub innych dostawców zasobów należących do zespołu usługi Service Fabric i obsługiwanych przez zespół usługi Service Fabric.

W bezpiecznym klastrze każde z tych ról można skonfigurować przy użyciu własnej, odrębnej tożsamości, zadeklarowanej jako parowanie wstępnie zdefiniowanej nazwy roli i odpowiadających jej poświadczeń. Usługa Service Fabric obsługuje deklarowanie poświadczeń jako certyfikatów lub jednostki usługi opartej na domenie. (Obsługiwane są również tożsamości oparte na systemie Windows/Kerberos, ale wykraczają poza zakres tego artykułu; zapoznaj się z tematemZabezpieczenia oparte na systemie Windows w klastrach usługi Service Fabric). W klastrach platformy Azure role klientów mogą być również deklarowane jako tożsamości oparte na identyfikatorach Firmy Microsoft.

Zgodnie z powyższym opisem środowisko uruchomieniowe usługi Service Fabric definiuje dwa poziomy uprawnień w klastrze: "administrator" i "użytkownik". Klient administratora i składnik "system" będą działać z uprawnieniami "administratora", więc nie można ich od siebie od siebie cofnąć. Po nawiązaniu połączenia w klastrze/do klastra uwierzytelniony obiekt wywołujący zostanie przyznany przez środowisko uruchomieniowe usługi Service Fabric jedną z dwóch ról jako podstawę kolejnej autoryzacji. Szczegółowo przeanalizujemy uwierzytelnianie w poniższych sekcjach.

Reguły konfiguracji certyfikatu

Reguły walidacji

Ustawienia zabezpieczeń klastra usługi Service Fabric opisują zasadniczo następujące aspekty:

  • typ uwierzytelniania; jest to niezmienna cecha klastra w czasie tworzenia. Przykłady takich ustawień to "ClusterCredentialType", "ServerCredentialType", a dozwolone wartości to "none", "x509" lub "windows". Ten artykuł koncentruje się na uwierzytelnianiu typu x509.
  • reguły weryfikacji (uwierzytelniania); te ustawienia są ustawiane przez właściciela klastra i opisują, które poświadczenia są akceptowane dla danej roli. Przykłady zostaną szczegółowo zbadane bezpośrednio poniżej.
  • ustawienia używane do dostosowywania lub subtelnego zmieniania wyniku uwierzytelniania; przykłady obejmują flagi ograniczające lub nieograniczone wymuszanie list odwołania certyfikatów itp.

Uwaga

Przykłady konfiguracji klastra przedstawione poniżej to fragmenty manifestu klastra w formacie XML jako najbardziej szyfrowany format, który obsługuje bezpośrednio funkcje usługi Service Fabric opisane w tym artykule. Te same ustawienia można wyrazić bezpośrednio w reprezentacjach JSON definicji klastra, niezależnie od tego, czy jest to autonomiczny manifest klastra json, czy szablon zarządzania zasobami platformy Azure.

Reguła weryfikacji certyfikatu obejmuje następujące elementy:

  • odpowiadająca mu rola: klient, klient administracyjny (rola uprzywilejowana)
  • poświadczenie zaakceptowane dla roli zadeklarowane przez odcisk palca lub nazwę pospolitą podmiotu

Deklaracje weryfikacji certyfikatu opartego na odcisku palca

W przypadku reguł weryfikacji opartych na odcisku palca poświadczenia przedstawione przez obiekt wywołujący żądający połączenia w klastrze/do klastra zostaną zweryfikowane w następujący sposób:

  • poświadczenie jest prawidłowym, dobrze sformułowanym certyfikatem: jego łańcuch można skompilować, dopasować podpisy
  • certyfikat jest prawidłowy (NotBefore <= now < NotAfter)
  • skrót SHA-1 certyfikatu jest zgodny z deklaracją jako porównanie ciągu bez uwzględniania wielkości liter z wyłączeniem wszystkich białych znaków

Wszelkie błędy zaufania napotkane podczas tworzenia lub walidacji łańcucha zostaną pominięte dla deklaracji opartych na odcisku palca, z wyjątkiem wygasłych certyfikatów - chociaż istnieją również przepisy dotyczące tego przypadku. W szczególności błędy związane z: stan odwołania jest nieznany lub offline, niezaufany katalog główny, nieprawidłowe użycie klucza, łańcuch częściowy są uznawane za błędy niekrytyczne; w tym przypadku założeniem jest to, że certyfikat jest jedynie kopertą dla pary kluczy — zabezpieczenia polegają na tym, że właściciel klastra ustawił w miejscu środek ochrony klucza prywatnego.

Poniższy fragment manifestu klastra ilustruje taki zestaw reguł weryfikacji opartych na odcisku palca:

<Section Name="Security">
  <Parameter Name="ClusterCredentialType" Value="X509" />
  <Parameter Name="ServerAuthCredentialType" Value="X509" />
  <Parameter Name="AdminClientCertThumbprints" Value="d5ec...4264" />
  <Parameter Name="ClientCertThumbprints" Value="7c8f...01b0" />
  <Parameter Name="ClusterCertThumbprints" Value="abcd...1234,ef01...5678" />
  <Parameter Name="ServerCertThumbprints" Value="ef01...5678" />
</Section>

Każdy z powyższych wpisów odnosi się do określonej tożsamości zgodnie z wcześniejszym opisem; każdy wpis umożliwia również określenie wielu wartości jako rozdzielanej przecinkami listy ciągów. W tym przykładzie po pomyślnym zweryfikowaniu poświadczeń przychodzących prezenter certyfikatu z odciskiem palca SHA-1 "d5ec... 4264" otrzyma rolę "administratora"; z drugiej strony, obiekt wywołujący uwierzytelniający za pomocą certyfikatu '7c8f... 01b0" otrzyma rolę "użytkownika", ograniczoną do głównie operacji tylko do odczytu. Obiekt wywołujący przychodzący, który przedstawia certyfikat, którego odcisk palca to "abcd... 1234" lub "ef01... Program 5678 zostanie zaakceptowany jako węzeł równorzędny w klastrze. Na koniec klient nawiązujący połączenie z punktem końcowym zarządzania klastra oczekuje odcisku palca certyfikatu serwera o wartości "ef01... 5678'.

Jak wspomniano wcześniej, usługa Service Fabric udostępnia przepisy dotyczące akceptowania wygasłych certyfikatów; przyczyną jest to, że certyfikaty mają ograniczony okres istnienia, a w przypadku zadeklarowania przez odcisk palca (który odwołuje się do określonego wystąpienia certyfikatu), zezwolenie na wygaśnięcie certyfikatu spowoduje niepowodzenie połączenia z klastrem lub wręcz zwinięcie klastra. To wszystko jest zbyt łatwe, aby zapomnieć lub zaniedbywać rotację odcisku palca przypiętego certyfikatu, a niestety odzyskiwanie z takiej sytuacji jest trudne.

W tym celu właściciel klastra może jawnie stwierdzić, że certyfikaty z podpisem własnym zadeklarowane za pomocą odcisku palca są uznawane za prawidłowe w następujący sposób:

  <Section Name="Security">
    <Parameter Name="AcceptExpiredPinnedClusterCertificate" Value="true" />
  </Section>

To zachowanie nie rozciąga się na certyfikaty wystawione przez urząd certyfikacji; gdyby tak było, odwołany, znany do naruszenia zabezpieczeń wygasły certyfikat może stać się "ważny", gdy tylko nie będzie już znajdować się na liście odwołania certyfikatów urzędu certyfikacji, a tym samym stanowić zagrożenie bezpieczeństwa. W przypadku certyfikatów z podpisem własnym właściciel klastra jest uważany za jedyną osobę odpowiedzialną za ochronę klucza prywatnego certyfikatu, który nie jest w przypadku certyfikatów wystawionych przez urząd certyfikacji — właściciel klastra może nie wiedzieć, jak lub kiedy certyfikat został uznany za naruszony.

Deklaracje weryfikacji certyfikatów oparte na nazwach pospolitych

Deklaracje oparte na nazwach pospolitych przyjmują jedną z następujących form:

  • nazwa pospolita podmiotu (tylko)
  • nazwa pospolita podmiotu z przypinaniem wystawcy

Najpierw rozważmy fragment manifestu klastra, który ilustruje oba style deklaracji:

    <Section Name="Security/ServerX509Names">
      <Parameter Name="server.demo.system.servicefabric.azure-int" Value="" />
    </Section>
    <Section Name="Security/ClusterX509Names">
      <Parameter Name="cluster.demo.system.servicefabric.azure-int" Value="1b45...844d,d7fe...26c8,3ac7...6960,96ea...fb5e" />
    </Section>

Deklaracje odwołują się odpowiednio do tożsamości serwera i klastra; należy pamiętać, że deklaracje oparte na cn mają własne sekcje w manifeście klastra, niezależnie od standardu "Zabezpieczenia". W obu deklaracjach nazwa reprezentuje wyróżniającą nazwę pospolitą podmiotu certyfikatu, a pole "Value" reprezentuje oczekiwanego wystawcę w następujący sposób:

  • w pierwszym przypadku deklaracja stwierdza, że element nazwy pospolitej podmiotu wyróżniającego certyfikatu serwera ma być zgodny z ciągiem "server.demo.system.servicefabric.azure-int"; puste pole "Wartość" oznacza oczekiwanie, że katalog główny łańcucha certyfikatów jest zaufany na węźle/maszynie, na której jest weryfikowany certyfikat serwera; w systemie Windows oznacza to, że certyfikat może łączyć się z dowolnym certyfikatem zainstalowanym w magazynie "Zaufany główny urząd certyfikacji";
  • w drugim przypadku deklaracja stwierdza, że prezenter certyfikatu jest akceptowany jako węzeł równorzędny w klastrze, jeśli nazwa pospolita certyfikatu jest zgodna z ciągiem "cluster.demo.system.servicefabric.azure-int", a odcisk palca bezpośredniego wystawcy certyfikatu pasuje do jednego z wpisów rozdzielonych przecinkami w polu "Wartość". (Ten typ reguły jest potocznie znany jako "nazwa pospolita z przypinaniem wystawcy").

W obu przypadkach łańcuch certyfikatu jest kompilowany i powinien być wolny od błędów; oznacza to, że błędy odwołania, częściowy łańcuch lub błędy nieprawidłowego czasu zaufania są uznawane za krytyczne, a walidacja certyfikatu zakończy się niepowodzeniem. Przypinanie wystawców spowoduje rozważenie stanu "niezaufanego katalogu głównego" jako błędu niekrytycznego; pomimo pozorów jest to bardziej rygorystyczna forma weryfikacji, ponieważ umożliwia właścicielowi klastra ograniczenie zestawu autoryzowanych/akceptowanych wystawców do własnej infrastruktury kluczy publicznych.

Po skompilowanym łańcuchu certyfikatów jest weryfikowany względem standardowych zasad TLS/SSL z zadeklarowanym podmiotem jako nazwą zdalną; certyfikat będzie traktowany jako dopasowanie, jeśli jego nazwa pospolita podmiotu lub dowolna z alternatywnych nazw podmiotów jest zgodna z deklaracją CN z manifestu klastra. Symbole wieloznaczne są obsługiwane w tym przypadku, a dopasowanie ciągu jest bez uwzględniania wielkości liter.

(Należy wyjaśnić, że sekwencja opisana powyżej może być wykonywana dla każdego typu użycia klucza zadeklarowanego przez certyfikat; jeśli certyfikat określa użycie klucza uwierzytelniania klienta, łańcuch jest kompilowany i oceniany jako pierwszy dla roli klienta. W przypadku powodzenia ocena zakończy się i walidacja zakończy się pomyślnie. Jeśli certyfikat nie ma użycia uwierzytelniania klienta lub walidacja nie powiedzie się, środowisko uruchomieniowe usługi Service Fabric skompiluje i oceni łańcuch uwierzytelniania serwera.

Aby ukończyć ten przykład, poniższy fragment ilustruje deklarowanie certyfikatów klienta według nazwy pospolitej:

    <Section Name="Security/AdminClientX509Names">
      <Parameter Name="admin.demo.client.servicefabric.azure-int" Value="1b45...844d,d7fe...26c8,3ac7...6960,96ea...fb5e" />
    </Section>
    <Section Name="Security/ClientX509Names">
      <Parameter Name="user.demo.client.servicefabric.azure-int" Value="1b45...844d,d7fe...26c8,3ac7...6960,96ea...fb5e" />
    </Section>

Powyższe deklaracje odpowiadają odpowiednio tożsamościom administratora i użytkownika; walidacja certyfikatów zadeklarowanych w ten sposób jest dokładnie taka, jak opisano w poprzednich przykładach, certyfikatów klastra i serwera.

Uwaga

Deklaracje oparte na nazwach pospolitych mają na celu uproszczenie rotacji i ogólne zarządzanie certyfikatami klastra. Zaleca się jednak przestrzeganie następujących zaleceń w celu zapewnienia ciągłej dostępności i zabezpieczeń klastra:

  • preferuj przypinanie wystawcy do polegania na zaufanych katalogach głównych
  • unikaj mieszania wystawców z różnych kluczy publicznych
  • upewnij się, że wszyscy oczekiwani wystawcy są wyświetlani w deklaracji certyfikatu; wystawca niezgodności spowoduje niepowodzenie weryfikacji
  • upewnij się, że punkty końcowe zasad certyfikatu infrastruktury kluczy publicznych są wykrywalne, dostępne i dostępne — oznacza to, że punkty końcowe AIA, CRL lub OCSP są deklarowane na certyfikacie liścia i że są dostępne, aby można było ukończyć tworzenie łańcucha certyfikatów.

Łącząc je wszystkie razem, po otrzymaniu żądania połączenia w klastrze zabezpieczonym za pomocą certyfikatów X.509 środowisko uruchomieniowe usługi Service Fabric użyje ustawień zabezpieczeń klastra w celu zweryfikowania poświadczeń strony zdalnej zgodnie z powyższym opisem; W przypadku pomyślnego uwierzytelnienia obiekt wywołujący/zdalna strona jest traktowana jako uwierzytelniona. Jeśli poświadczenie jest zgodne z wieloma regułami walidacji, środowisko uruchomieniowe przyzna wywołującemu rolę najwyższego poziomu uprawnień dowolnej z dopasowanych reguł.

Reguły prezentacji

W poprzedniej sekcji opisano sposób działania uwierzytelniania w klastrze zabezpieczonym certyfikatem; W tej sekcji wyjaśniono, jak środowisko uruchomieniowe usługi Service Fabric odnajduje i ładuje certyfikaty używane do komunikacji w klastrze; Nazywamy je regułami "prezentacji".

Podobnie jak w przypadku reguł walidacji, reguły prezentacji określają rolę i skojarzą deklarację poświadczeń wyrażoną za pomocą odcisku palca lub nazwy pospolitej. W przeciwieństwie do reguł walidacji deklaracje oparte na nazwach wspólnych nie mają przepisów dotyczących przypinania wystawcy; zapewnia większą elastyczność, a także lepszą wydajność. Reguły prezentacji są deklarowane w sekcji "NodeType" manifestu klastra dla każdego odrębnego typu węzła; ustawienia są podzielone z sekcji Zabezpieczenia klastra, aby umożliwić każdemu typowi węzła pełną konfigurację w jednej sekcji. W klastrach usługi Azure Service Fabric węzeł typu deklaracje certyfikatów są domyślne dla odpowiednich ustawień w sekcji Zabezpieczenia definicji klastra.

Deklaracje prezentacji certyfikatu oparte na odcisku palca

Jak opisano wcześniej, środowisko uruchomieniowe usługi Service Fabric rozróżnia między swoją rolą jako element równorzędny innych węzłów w klastrze, a jako serwer dla operacji zarządzania klastrem. W zasadzie te ustawienia można skonfigurować osobno, ale w praktyce mają tendencję do wyrównania. W pozostałej części tego artykułu zakładamy, że ustawienia są zgodne z prostotą.

Rozważmy następujący fragment manifestu klastra:

  <NodeTypes>
    <NodeType Name="nt1vm">
      <Certificates>
        <ClusterCertificate X509FindType="FindByThumbprint" X509FindValue="cc71...1984" X509FindValueSecondary="49e2...19d6" X509StoreName="my" Name="ClusterCertificate" />
        <ServerCertificate X509FindValue="cc71...1984" Name="ServerCertificate" />
        <ClientCertificate X509FindValue="cc71...1984" Name="ClientCertificate" />
      </Certificates>
    </NodeType>
  </NodeTypes>

Element "ClusterCertificate" demonstruje pełny schemat, w tym parametry opcjonalne ('X509FindValueSecondary') lub te z odpowiednimi wartościami domyślnymi ('X509StoreName'); pozostałe deklaracje pokazują skróconą formę. W powyższej deklaracji certyfikatu klastra stwierdza się, że ustawienia zabezpieczeń węzłów typu "nt1vm" są inicjowane przy użyciu certyfikatu "cc71". 1984" jako podstawowy i "49e2". Certyfikat 19d6 jako pomocniczy; Oczekuje się, że oba certyfikaty zostaną znalezione w magazynie certyfikatów LocalMachine'My (lub ścieżki równoważnej systemu Linux, var/lib/sfcerts).

Deklaracje prezentacji certyfikatów oparte na nazwach pospolitych

Certyfikaty typu węzła można również zadeklarować według nazwy pospolitej podmiotu, jak pokazano poniżej:

  <NodeTypes>
    <NodeType Name="nt1vm">
      <Certificates>
        <ClusterCertificate X509FindType="FindBySubjectName" X509FindValue="demo.cluster.azuredocpr.system.servicefabric.azure-int" Name="ClusterCertificate" />
      </Certificates>
    </NodeType>
  </NodeTypes>

W przypadku dowolnego typu deklaracji węzeł usługi Service Fabric odczytuje konfigurację podczas uruchamiania, lokalizuje i ładuje określone certyfikaty i sortuje je w kolejności malejącej atrybutu NotBefore; wygasłe certyfikaty są ignorowane, a pierwszy element listy jest wybierany jako poświadczenie klienta dla dowolnego połączenia usługi Service Fabric, które podjęto przez ten węzeł. (W efekcie usługa Service Fabric preferuje ostatnio wystawiony certyfikat).

Uwaga

Przed wersją 7.2.445 (7.2 CU4) usługa Service Fabric wybrała najdalej wygasający certyfikat (certyfikat z najdalejszą właściwością "NotAfter")

Należy pamiętać, że w przypadku deklaracji prezentacji opartych na nazwach wspólnych certyfikat jest uznawany za zgodny, jeśli jego nazwa pospolita podmiotu jest równa X509FindValue (lub X509FindValueSecondary) pola deklaracji jako dokładne porównanie ciągów z uwzględnieniem wielkości liter. Jest to sprzeczne z regułami walidacji, które obsługują dopasowywanie symboli wieloznacznych, a także porównania ciągów bez uwzględniania wielkości liter.

Różne ustawienia konfiguracji certyfikatu

Wcześniej wspomniano, że ustawienia zabezpieczeń klastra usługi Service Fabric umożliwiają również subtelną zmianę zachowania kodu uwierzytelniania. Podczas gdy artykuł dotyczący ustawień klastra usługi Service Fabric reprezentuje kompleksową i najbardziej aktualną listę ustawień, rozszerzymy znaczenie kilku ustawień zabezpieczeń w tym miejscu, aby ukończyć pełne uwidocznienie uwierzytelniania opartego na certyfikatach. Dla każdego ustawienia wyjaśnimy intencję, wartość domyślną/zachowanie, sposób, w jaki wpływa na uwierzytelnianie i które wartości są akceptowalne.

Jak wspomniano, walidacja certyfikatu zawsze oznacza kompilowanie i ocenianie łańcucha certyfikatu. W przypadku certyfikatów wystawionych przez urząd certyfikacji to najwyraźniej proste wywołanie interfejsu API systemu operacyjnego zwykle wiąże się z kilkoma wywołaniami wychodzącymi do różnych punktów końcowych wystawiającej infrastruktury kluczy publicznych, buforowaniem odpowiedzi itd. Biorąc pod uwagę częstość występowania wywołań weryfikacji certyfikatów w klastrze usługi Service Fabric, wszelkie problemy z punktami końcowymi infrastruktury kluczy publicznych mogą spowodować zmniejszenie dostępności klastra lub wręcz awarię. Chociaż nie można pominąć wywołań wychodzących (zobacz poniżej w sekcji Często zadawane pytania, aby uzyskać więcej informacji na ten temat), następujące ustawienia mogą służyć do maskowania błędów walidacji spowodowanych niepowodzeniem wywołań listy CRL.

  • CrlCheckingFlag — w sekcji "Zabezpieczenia" ciąg przekonwertowany na UINT. Wartość tego ustawienia jest używana przez usługę Service Fabric do maskowania błędów stanu łańcucha certyfikatów przez zmianę zachowania tworzenia łańcucha; Jest on przekazywany do wywołania "dwFlags" interfejsu CertGetCertificateChain win32 CryptoAPI i można go ustawić na dowolną prawidłową kombinację flag akceptowanych przez funkcję. Wartość 0 wymusza, aby środowisko uruchomieniowe usługi Service Fabric ignorowało błędy stanu zaufania — nie jest to zalecane, ponieważ jego użycie stanowiłoby znaczną ekspozycję na zabezpieczenia. Wartość domyślna to 0x40000000 (CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT).

Kiedy należy używać: do testowania lokalnego z certyfikatami z podpisem własnym lub certyfikatami deweloperów, które nie są w pełni sformułowane/nie mają odpowiedniej infrastruktury kluczy publicznych do obsługi certyfikatów. Może również służyć jako środki zaradcze w środowiskach rozzłoconych powietrzem podczas przechodzenia między PKI.

Jak użyć: użyjemy przykładu, który wymusza sprawdzenie odwołania w celu uzyskania dostępu tylko do buforowanych adresów URL. Zakładając:

#define CERT_CHAIN_REVOCATION_CHECK_CACHE_ONLY         0x80000000

następnie deklaracja w manifeście klastra staje się:

  <Section Name="Security">
    <Parameter Name="CrlCheckingFlag" Value="0x80000000" />
  </Section>
  • IgnoreCrlOfflineError — w sekcji "Zabezpieczenia" wartość logiczna z wartością domyślną "false". Reprezentuje skrót do pomijania stanu błędu tworzenia łańcucha odwołania w trybie offline (lub kolejnego stanu błędu weryfikacji zasad łańcucha).

Kiedy należy używać: testowanie lokalne lub certyfikaty deweloperów, które nie są wspierane przez właściwą infrastrukturę kluczy publicznych. Należy użyć jako środki zaradcze w środowiskach rozgniewanych w powietrzu lub gdy infrastruktura kluczy publicznych jest znana jako niedostępna.

Jak używać:

  <Section Name="Security">
    <Parameter Name="IgnoreCrlOfflineError" Value="true" />
  </Section>

Inne istotne ustawienia (wszystkie w sekcji "Zabezpieczenia"):

  • AcceptExpiredPinnedClusterCertificate — omówiony w sekcji poświęconej weryfikacji certyfikatu opartego na odcisku palca; umożliwia akceptowanie wygasłych certyfikatów klastra z podpisem własnym.
  • CertificateExpirySafetyMargin — interwał wyrażony w minutach przed sygnaturą czasową NotAfter certyfikatu i podczas którego certyfikat jest uznawany za zagrożony wygaśnięciem. Usługa Service Fabric monitoruje certyfikaty klastra i okresowo emituje raporty o kondycji pozostałych dostępności. W interwale "bezpieczeństwo" te raporty dotyczące kondycji są podniesione do stanu "ostrzeżenie". Wartość domyślna to 30 dni.
  • CertificateHealthReportingInterval — określa częstotliwość raportów kondycji dotyczących pozostałego czasu ważności certyfikatów klastra. Raporty będą emitowane tylko raz w tym interwale. Wartość jest wyrażona w sekundach z wartością domyślną 8 godzin.
  • EnforcePrevalidationOnSecurityChanges — wartość logiczna, steruje zachowaniem uaktualniania klastra podczas wykrywania zmian ustawień zabezpieczeń. W przypadku ustawienia wartości "true" uaktualnienie klastra podejmie próbę upewnienia się, że co najmniej jeden z certyfikatów pasujących do dowolnych reguł prezentacji może przekazać odpowiednią regułę weryfikacji. Walidacja wstępna jest wykonywana przed zastosowaniem nowych ustawień do dowolnego węzła, ale jest uruchamiana tylko w węźle hostującym replikę podstawową usługi Menedżer klastra w momencie inicjowania uaktualnienia. W tym zapisie ustawienie ma wartość domyślną "false" i zostanie ustawione na wartość "true" dla nowych klastrów usługi Azure Service Fabric z wersją środowiska uruchomieniowego rozpoczynającą się od wersji 7.1.

Kompleksowe scenariusze (przykłady)

Przyjrzeliśmy się regułom prezentacji, regułom walidacji i flagom dostosowywania, ale jak to wszystko działa razem? W tej sekcji omówimy dwa kompleksowe przykłady pokazujące, jak można wykorzystać ustawienia zabezpieczeń na potrzeby bezpiecznych uaktualnień klastra. Należy pamiętać, że nie jest to kompleksowa rozprawa dotycząca odpowiedniego zarządzania certyfikatami w usłudze Service Fabric. Poszukaj artykułu towarzyszącego w tym temacie.

Rozdzielenie reguł prezentacji i weryfikacji stanowi oczywiste pytanie (lub obawy) dotyczące tego, czy mogą się one rozróżnić i jakie byłyby konsekwencje. W rzeczywistości istnieje możliwość, że wybór węzła certyfikatu uwierzytelniania nie przejdzie przez reguły walidacji innego węzła. W rzeczywistości ta rozbieżność jest główną przyczyną zdarzeń związanych z uwierzytelnianiem. Jednocześnie rozdzielenie tych reguł umożliwia klastrowi kontynuowanie działania podczas uaktualniania, co powoduje zmianę ustawień zabezpieczeń klastra. Należy pamiętać, że poprzez rozszerzenie najpierw reguł weryfikacji jako pierwszego kroku wszystkie węzły klastra będą zbieżne z nowymi ustawieniami, a jednocześnie nadal używają bieżących poświadczeń.

Pamiętaj, że w klastrze usługi Service Fabric uaktualnienie jest wykonywane przez (maksymalnie 5) "domeny uaktualnienia" lub identyfikatory UD. W danym momencie uaktualniane/zmieniane są tylko węzły w bieżącej trasy zdefiniowanej przez użytkownika, a uaktualnienie przejdzie do następnej trasy zdefiniowanej przez użytkownika tylko wtedy, gdy zezwoli na to dostępność klastra. (Zapoznaj się z Uaktualnienia klastra usługi Service Fabric i inne artykuły w tym samym temacie, aby uzyskać więcej szczegółów). Zmiany certyfikatów/zabezpieczeń są szczególnie ryzykowne, ponieważ mogą odizolować węzły od klastra lub pozostawić klaster na krawędzi utraty kworum.

Użyjemy następującej notacji, aby opisać ustawienia zabezpieczeń węzła:

Nk: {P:{TP=A}, V:{TP=A}}, gdzie:

  • Element "Nk" reprezentuje węzeł w domenie uaktualnienia k
  • "P" reprezentuje bieżące reguły prezentacji węzła (przy założeniu, że odwołujemy się tylko do certyfikatów klastra);
  • "V" reprezentuje bieżące reguły walidacji węzła (tylko certyfikat klastra)
  • Element "TP=A" reprezentuje deklarację opartą na odcisku palca (TP), a element "A" jest odciskiem palca certyfikatu
  • "CN=B" reprezentuje deklarację opartą na nazwie pospolitej (CN), a "B" jest nazwą pospolitą podmiotu certyfikatu

Rotacja certyfikatu klastra zadeklarowanego przez odcisk palca

W poniższej sekwencji opisano sposób użycia uaktualnienia 2-etapowego w celu bezpiecznego wprowadzenia pomocniczego certyfikatu klastra zadeklarowanego przez odcisk palca; pierwsza faza wprowadza nową deklarację certyfikatu w regułach walidacji, a druga faza wprowadza ją w regułach prezentacji:

  • stan początkowy: N0 = {P:{TP=A}, V:{TP=A}}, ... Nk = {P:{TP=A}, V:{TP=A}} — klaster jest magazynowane, wszystkie węzły mają wspólną konfigurację
  • po ukończeniu uaktualniania domeny 0: N0 = {P:{TP=A}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A}, V:{TP=A}} — węzły w ud0 będą prezentować certyfikat A i akceptować certyfikaty A lub B; wszystkie inne węzły obecne i akceptują tylko certyfikat A
  • po ukończeniu ostatniej domeny uaktualnienia: N0 = {P:{TP=A}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A}, V:{TP=A, TP=B}} — wszystkie węzły prezentują certyfikat A, wszystkie węzły akceptują certyfikat A lub B

W tym momencie klaster jest ponownie w równowadze, a druga faza uaktualniania/zmiany ustawień zabezpieczeń może rozpocząć się:

  • po ukończeniu uaktualniania domeny 0: N0 = {P:{TP=A, TP=B}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A}, V:{TP=A, TP=B}} — węzły w ud0 zaczną prezentować B, który jest akceptowany przez dowolny inny węzeł w klastrze.
  • po ukończeniu ostatniej domeny uaktualnienia: N0 = {P:{TP=A, TP=B}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A, TP=B}, V:{TP=A, TP=B}} — wszystkie węzły zostały przełączone na prezentowanie certyfikatu B. Certyfikat A można teraz wycofać/usunąć z definicji klastra z kolejnym zestawem uaktualnień.

Konwertowanie klastra z odcisku palca na deklaracje certyfikatów opartych na nazwach wspólnych

Podobnie zmiana typu deklaracji certyfikatu (z odcisku palca na nazwę pospolitą) będzie mieć taki sam wzorzec jak powyżej. Należy pamiętać, że reguły walidacji umożliwiają deklarowanie certyfikatów danej roli zarówno przez odcisk palca, jak i nazwę pospolitą w tej samej definicji klastra. Natomiast reguły prezentacji zezwalają tylko na jedną formę deklaracji. Nawiasem mówiąc, bezpieczne podejście do konwertowania certyfikatu klastra z odcisku palca na nazwę pospolitą polega na wprowadzeniu zamierzonego certyfikatu docelowego najpierw przez odcisk palca, a następnie zmianę tej deklaracji na nazwę pospolitą. W poniższym przykładzie przyjęto założenie, że odcisk palca "A" i nazwa pospolita podmiotu "B" odwołują się do tego samego certyfikatu.

  • stan początkowy: N0 = {P:{TP=A}, V:{TP=A}}, ... Nk = {P:{TP=A}, V:{TP=A}} — klaster jest w spoczynku, wszystkie węzły mają wspólną konfigurację, a element A jest odciskiem palca certyfikatu podstawowego
  • po ukończeniu uaktualniania domeny 0: N0 = {P:{TP=A}, V:{TP=A, CN=B}}, ... Nk = {P:{TP=A}, V:{TP=A}} — węzły w ud0 będą przedstawiać certyfikat A i akceptować certyfikaty z odciskiem palca A lub nazwą pospolitą B; wszystkie inne węzły obecne i akceptują tylko certyfikat A
  • po ukończeniu ostatniej domeny uaktualnienia: N0 = {P:{TP=A}, V:{TP=A, CN=B}}, ... Nk = {P:{TP=A}, V:{TP=A, CN=B}} — wszystkie węzły prezentują certyfikat A, wszystkie węzły akceptują certyfikat A (TP) lub B (CN)

W tym momencie możemy kontynuować zmianę reguł prezentacji przy użyciu kolejnego uaktualnienia:

  • po ukończeniu uaktualniania domeny 0: N0 = {P:{CN=B}, V:{TP=A, CN=B}}, ... Nk = {P:{TP=A}, V:{TP=A, CN=B}} - węzły w ud0 będą przedstawiać certyfikat B znaleziony przez CN i akceptuje certyfikaty z odciskiem palca A lub nazwą pospolitą B; wszystkie inne węzły są obecne i akceptują tylko certyfikat A wybrane przez odcisk palca
  • po ukończeniu ostatniej domeny uaktualnienia: N0 = {P:{CN=B}, V:{TP=A, CN=B}}, ... Nk = {P:{CN=B}, V:{TP=A, CN=B}} — wszystkie węzły prezentują certyfikat B znaleziony przez CN, wszystkie węzły akceptują certyfikat A (TP) lub B (CN)

Zakończenie fazy 2 oznacza również konwersję klastra na certyfikaty oparte na nazwach pospolitych; Deklaracje weryfikacji oparte na odcisku palca można usunąć w kolejnym uaktualnieniu klastra.

Uwaga

W klastrach usługi Azure Service Fabric przedstawione powyżej przepływy pracy są orkiestrowane przez dostawcę zasobów usługi Service Fabric; właściciel klastra jest nadal odpowiedzialny za aprowizowanie certyfikatów w klastrze zgodnie ze wskazanymi regułami (prezentacja lub walidacja) i jest zachęcany do przeprowadzania zmian w wielu krokach.

W osobnym artykule zajmiemy się tematem zarządzania certyfikatami i aprowizowania ich w klastrze usługi Service Fabric.

Rozwiązywanie problemów i często zadawane pytania

Chociaż debugowanie problemów związanych z uwierzytelnianiem w klastrach usługi Service Fabric nie jest łatwe, mamy nadzieję, że poniższe wskazówki i porady mogą pomóc. Najprostszym sposobem rozpoczęcia badań jest zbadanie dzienników zdarzeń usługi Service Fabric w węzłach klastra — niekoniecznie tylko tych, którzy wykazują objawy, ale także węzły, które są uruchomione, ale nie mogą nawiązać połączenia z jednym z ich sąsiadów. W systemie Windows zdarzenia istotności są zwykle rejestrowane w kanałach "Dzienniki aplikacji i usług\Microsoft-ServiceFabric\Admin" lub "Operacyjne". Czasami warto włączyć rejestrowanie CAPI2, przechwytywać więcej szczegółów dotyczących weryfikacji certyfikatu, pobierania listy CRL/CTL itp. (Pamiętaj, aby wyłączyć je po zakończeniu ponownego odtworzenia, może to być dość pełne).

Typowe objawy, które manifestują się w klastrze, w którym występują problemy z uwierzytelnianiem, to:

  • węzły są w dół/na rowerze
  • próby połączenia są odrzucane
  • limit czasu prób połączenia

Każdy z objawów może być spowodowany przez różne problemy, a ta sama główna przyczyna może wykazywać różne objawy; w związku z tym po prostu wyświetlimy niewielką próbkę typowych problemów z zaleceniami dotyczącymi ich rozwiązywania.

  • Węzły mogą wymieniać komunikaty, ale nie mogą się łączyć. Możliwą przyczyną przerwania próby nawiązania połączenia jest błąd "certyfikat nie pasuje" — jedna z stron w połączeniu usługi Service Fabric-to-Service Fabric przedstawia certyfikat, który kończy się niepowodzeniem reguł weryfikacji adresata. Może towarzyszyć jeden z następujących błędów:

    0x80071c44	-2147017660	FABRIC_E_SERVER_AUTHENTICATION_FAILED

    Aby zdiagnozować/zbadać dalej: na każdym z węzłów próbujących nawiązać połączenie, określ, który certyfikat jest prezentowany; sprawdź certyfikat i spróbuj emulować reguły walidacji (sprawdź, czy nie określono równości odcisków palca lub nazwy pospolitej, sprawdź odciski palca wystawcy, jeśli określono).

    Innym typowym kodem błędu towarzyszącym może być:

    0x800b0109	-2146762487	CERT_E_UNTRUSTEDROOT

    W takim przypadku certyfikat jest zadeklarowany przez nazwę pospolitą, a jeden z następujących ma zastosowanie:

    • wystawcy nie są przypięci, a certyfikat główny nie jest zaufany lub
    • wystawcy są przypięci, ale deklaracja nie zawiera odcisku palca bezpośredniego wystawcy tego certyfikatu

  • Węzeł jest w górę, ale nie może nawiązać połączenia z innymi węzłami; inne węzły nie odbierają ruchu przychodzącego z węzła, który kończy się niepowodzeniem. W takim przypadku istnieje możliwość, że ładowanie certyfikatu kończy się niepowodzeniem w węźle lokalnym. Poszukaj następujących błędów:

    • nie można odnaleźć certyfikatu — upewnij się, że certyfikaty zadeklarowane w regułach prezentacji można rozpoznać za pomocą zawartości magazynu certyfikatów LocalMachine\My (lub jak określono). Możliwe przyczyny niepowodzenia mogą obejmować:

      • nieprawidłowe znaki w deklaracji odcisku palca
      • certyfikat nie jest zainstalowany
      • certyfikat wygasł
      • deklaracja nazwy pospolitej zawiera prefiks "CN="
      • deklaracja określa symbol wieloznaczny i nie istnieje dokładne dopasowanie w magazynie certyfikatów (deklaracja: CN=*.mydomain.com, rzeczywisty certyfikat: CN=server.mydomain.com)

    • nieznane poświadczenia — wskazuje brak klucza prywatnego odpowiadającego certyfikatowi, zwykle wraz z kodem błędu:

      0x8009030d	-2146893043	SEC_E_UNKNOWN_CREDENTIALS
0x8009030e	-2146893042	SEC_E_NO_CREDENTIALS

      Aby rozwiązać ten problem, sprawdź istnienie klucza prywatnego; Sprawdź, czy administratorzy SFAdmins otrzymują dostęp "read|execute" do klucza prywatnego.

    • nieprawidłowy typ dostawcy — wskazuje certyfikat generacji kryptograficznej (CNG) ("Microsoft Software Key Storage Provider"); obecnie usługa Service Fabric obsługuje tylko certyfikaty CAPI1. Zazwyczaj towarzyszy mu kod błędu:

      0x80090014	-2146893804	NTE_BAD_PROV_TYPE

      Aby rozwiązać ten problem, utwórz ponownie certyfikat klastra przy użyciu dostawcy CAPI1 (np. "Microsoft Enhanced RSA and AES Cryptographic Provider"). Aby uzyskać więcej informacji na temat dostawców kryptograficznych, zobacz Omówienie dostawców kryptograficznych