Sdílet prostřednictvím

Ověřování na základě certifikátů X.509 v clusterech Service Fabric

  • Článek

Tento článek doplňuje úvod do zabezpečení clusteru Service Fabric a podrobně popisuje ověřování pomocí certifikátů v clusterech Service Fabric. Předpokládáme, že čtenář je obeznámen se základními koncepty zabezpečení a také s ovládacími prvky, které Service Fabric zpřístupňuje k řízení zabezpečení clusteru.

Témata pokrytá pod tímto názvem:

  • Základy ověřování na základě certifikátů
  • Identity a jejich příslušné role
  • Pravidla konfigurace certifikátu
  • Řešení potíží a nejčastější dotazy

Základy ověřování na základě certifikátů

V zájmu zabezpečení je certifikát nástrojem, který má svázat informace týkající se entity (předmětu) ke svému vlastnictví dvojice asymetrických kryptografických klíčů, a proto představuje základní konstruktor kryptografie veřejného klíče. Klíče reprezentované certifikátem lze použít k ochraně dat nebo k prokázání identity držitelů klíčů; při použití ve spojení se systémem infrastruktury veřejných klíčů (PKI) může certifikát představovat další vlastnosti svého subjektu, například vlastnictví internetové domény nebo určitá oprávnění udělená vystavitelem certifikátu (označovaným jako certifikační autorita nebo certifikační autorita). Běžná aplikace certifikátů podporuje kryptografický protokol TLS (Transport Layer Security), který umožňuje zabezpečenou komunikaci přes počítačovou síť. Konkrétně klient a server používají certifikáty k zajištění ochrany osobních údajů a integrity komunikace a také k provádění vzájemného ověřování.

V Service Fabric se základní vrstva clusteru (Federace) také staví na protokolu TLS (mimo jiné protokoly), aby bylo dosaženo spolehlivé a zabezpečené sítě zúčastněných uzlů. Připojení ke clusteru prostřednictvím klientských rozhraní API Service Fabric používají protokol TLS i k ochraně provozu a také k vytvoření identit stran. Konkrétně platí, že pokud se používá k ověřování v Service Fabric, můžete použít certifikát k prokázání následujících deklarací identity: a) prezentující přihlašovacích údajů certifikátu má k dispozici privátní klíč certifikátu b) hash SHA-1 certifikátu (kryptografický otisk) odpovídá deklaraci zahrnuté v definici clusteru nebo c) rozlišující běžný název certifikátu odpovídá deklaraci zahrnuté v definici clusteru. a vystavitel certifikátu je známý nebo důvěryhodný.

V seznamu výše se "b" označuje jako "připnutí kryptografického otisku"; v tomto případě deklarace odkazuje na konkrétní certifikát a síla schématu ověřování spočívá v místní lokalitě, že je výpočetně neproveditelné k vytvoření certifikátu, který vytváří stejnou hodnotu hash jako jiný, a přitom je stále platným dobře vytvořeným objektem ve všech ostatních ohledech. Položka "c" představuje alternativní formu deklarování certifikátu, kde síla schématu spočívá v kombinaci předmětu osvědčení a vydávající autority. V tomto případě deklarace odkazuje na třídu certifikátů – všechny dva certifikáty se stejnými vlastnostmi jsou považovány za plně ekvivalentní.

Následující části podrobně popisují, jak modul runtime Service Fabric používá a ověřuje certifikáty, aby se zajistilo zabezpečení clusteru.

Identity a jejich příslušné role

Než se ponoříte do podrobností o ověřování nebo zabezpečení komunikačních kanálů, je důležité uvést zúčastněné aktéry a odpovídající role, které hrají v clusteru:

  • modul runtime Service Fabric, označovaný jako "systém": sada služeb, které poskytují abstrakce a funkce představující cluster. Při odkazech na komunikaci v clusteru mezi instancemi systému použijeme termín "identita clusteru"; při odkazování na cluster jako příjemce nebo cíl provozu z vnějšího clusteru použijeme termín "identita serveru".
  • hostované aplikace, označované jako "aplikace": kód poskytnutý vlastníkem clusteru, který je orchestrován a spuštěn v clusteru
  • klienti: entity se mohou připojit ke clusteru a spouštět funkce v clusteru podle konfigurace clusteru. Rozlišujeme mezi dvěma úrovněmi oprávnění – "uživatel" a "admin". Klient uživatele je omezen především na operace jen pro čtení (ale ne všechny funkce jen pro čtení), zatímco klient správce má neomezený přístup k funkcím clusteru. (Další podrobnosti najdete v tématu Role zabezpečení v clusteru Service Fabric.)
  • (pouze Azure) služby Service Fabric, které orchestrují a zveřejňují ovládací prvky pro provoz a správu clusterů Service Fabric, označované jako "služba". V závislosti na prostředí může služba odkazovat na poskytovatele prostředků Azure Service Fabric nebo na jiné poskytovatele prostředků vlastněné a provozované týmem Service Fabric.

V zabezpečeném clusteru je možné nakonfigurovat každou z těchto rolí s vlastní, jedinečnou identitou deklarovanou jako párování předdefinovaného názvu role a odpovídajících přihlašovacích údajů. Service Fabric podporuje deklarování přihlašovacích údajů jako certifikátů nebo instančního objektu založeného na doméně. (Podporují se také identity založené na systému Windows/Kerberos, ale jsou nad rámec tohoto článku; Zabezpečení na základě Windows v clusterech Service Fabric.) V clusterech Azure můžou být klientské role také deklarovány jako identity založené na ID Microsoft Entra.

Jak je uvedeno výše, modul runtime Service Fabric definuje v clusteru dvě úrovně oprávnění: admin a user. Klient správce a komponenta "systém" by fungovaly s oprávněními správce, a proto se navzájem neschválily. Po navázání připojení ke clusteru bude ověřený volající udělen modulem runtime Service Fabric jednu ze dvou rolí jako základ pro následnou autorizaci. Podrobněji prozkoumáme ověřování v následujících částech.

Pravidla konfigurace certifikátu

Ověřovací pravidla

Nastavení zabezpečení clusteru Service Fabric v zásadě popisují následující aspekty:

  • typ ověřování; jedná se o neměnnou vlastnost clusteru v době vytvoření. Příkladem takových nastavení jsou ClusterCredentialType, ServerCredentialType a povolené hodnoty jsou none, x509 nebo Windows. Tento článek se zaměřuje na ověřování typu x509.
  • ověřovací pravidla (ověřování) tato nastavení nastaví vlastník clusteru a popíše, které přihlašovací údaje se pro danou roli přijmou. Příklady se prověří podrobněji níže.
  • nastavení použitá k úpravě nebo dílčí změně výsledku ověřování; Příklady zde zahrnují příznaky omezující nebo neomezené vynucení seznamů odvolaných certifikátů atd.

Poznámka:

Příklady konfigurace clusteru uvedené níže jsou výňatky z manifestu clusteru ve formátu XML, protože nejrozsáhlší formát, který podporuje přímo funkce Service Fabric popsané v tomto článku. Stejná nastavení se dají vyjádřit přímo v reprezentacích JSON definice clusteru, ať už jde o samostatný manifest clusteru JSON nebo šablonu azure Resource Mangement.

Ověřovací pravidlo certifikátu se skládá z následujících prvků:

  • odpovídající role: klient, klient pro správu (privilegovaná role)
  • přihlašovací údaje přijaté pro roli deklarované buď kryptografickým otiskem, nebo běžným názvem subjektu

Deklarace ověření certifikátu založeného na kryptografickém otisku

V případě ověřovacích pravidel založených na kryptografickém otisku se přihlašovací údaje předávané volajícím požadující připojení ke clusteru ověří následujícím způsobem:

  • přihlašovací údaje jsou platným, dobře vytvořeným certifikátem: jeho řetěz lze sestavit, podpisy se shodují.
  • certifikát je platný (NotBefore <= now < NotAfter)
  • hodnota hash SHA-1 certifikátu odpovídá deklaraci, protože porovnání řetězců bez rozlišování malých a velkých písmen s výjimkou všech prázdných znaků

Všechny chyby důvěryhodnosti, ke kterým došlo při vytváření řetězu nebo ověřování, se potlačí u deklarací založených na kryptografickém otisku s výjimkou certifikátů s vypršenou platností – i když pro tento případ existují i ustanovení. Konkrétně selhání související s: stav odvolání je neznámý nebo offline, nedůvěryhodný kořenový adresář, neplatné použití klíče, částečné řetěz jsou považovány za ne závažné chyby; v tomto případě je to, že certifikát je pouze obálka pro pár klíčů – zabezpečení spočívá ve skutečnosti, že vlastník clusteru nastavil opatření k ochraně privátního klíče.

Následující výňatek z manifestu clusteru exemplifuje takovou sadu ověřovacích pravidel založených na kryptografickém otisku:

<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ždá z výše uvedených položek odkazuje na konkrétní identitu, jak je popsáno výše; každá položka také umožňuje zadat více hodnot jako seznam řetězců oddělených čárkami. V tomto příkladu po úspěšném ověření příchozích přihlašovacích údajů prezentujícího certifikátu s kryptografickým otiskem SHA-1 d5ec... 4264 bude udělena role "správce"; naopak volající ověřující certifikát '7c8f... 01b0 bude udělena role uživatel, omezena na primárně operace jen pro čtení. Příchozí volající, který prezentuje certifikát, jehož kryptografický otisk je buď "abcd... 1234 nebo ef01... Hodnota 5678 se přijme jako partnerský uzel v clusteru. Klient, který se připojuje ke koncovému bodu správy clusteru, nakonec očekává, že kryptografický otisk certifikátu serveru bude ef01... 5678'.

Jak už bylo zmíněno dříve, Service Fabric zřizuje přijímání certifikátů s vypršenou platností; důvodem je, že certifikáty mají omezenou dobu životnosti a při deklaraci kryptografickým otiskem (který odkazuje na konkrétní instanci certifikátu) způsobí vypršení platnosti certifikátu buď selhání připojení ke clusteru, nebo přímé sbalení clusteru. Je to vše příliš snadné zapomenout nebo zanedbávat rotace kryptografického otisku připnutý certifikát, a bohužel obnovení z takové situace je obtížné.

Za tímto účelem může vlastník clusteru explicitně uvést, že certifikáty podepsané svým držitelem deklarované kryptografickým otiskem jsou považovány za platné:

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

Toto chování se nevztahuje na certifikáty vydané certifikační autoritou; Pokud by tomu tak bylo, mohl by se odvolaný, známý certifikát, jehož platnost vypršela, stát "platným", jakmile už nebude na obrázku seznamu odvolaných certifikátů certifikační autority, a tudíž může představovat bezpečnostní riziko. U certifikátů podepsaných svým držitelem je vlastník clusteru považován za jedinou stranu odpovědnou za ochranu privátního klíče certifikátu, což není případ certifikátů vydaných certifikační autoritou – vlastník clusteru nemusí vědět, jak nebo kdy byl jeho certifikát deklarován.

Běžné deklarace ověřování certifikátů založené na názvu

Deklarace založené na běžných názvech mají jednu z následujících forem:

  • běžný název subjektu (pouze)
  • běžný název subjektu s připnutím vystavitele

Pojďme nejprve zvážit výňatek z manifestu clusteru, který ukazuje oba styly deklarace:

    <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>

Deklarace odkazují na identity serveru a clusteru, v uvedeném pořadí; všimněte si, že deklarace založené na CN mají v manifestu clusteru vlastní oddíly oddělené od standardního "zabezpečení". V obou deklarací představuje "Název" rozlišující společný název subjektu certifikátu a pole Hodnota představuje očekávaného vystavitele následujícím způsobem:

  • v prvním případě deklarace uvádí, že se očekává, že společný název prvku rozlišujícího předmětu certifikátu serveru odpovídá řetězci "server.demo.system.servicefabric.azure-int"; Prázdné pole Hodnota označuje očekávání, že kořen řetězu certifikátů je důvěryhodný na uzlu nebo počítači, kde se certifikát serveru ověřuje; v systému Windows to znamená, že certifikát může zřetězený až k některému z certifikátů nainstalovaných v úložišti důvěryhodné kořenové certifikační autority;
  • v druhém případě deklarace uvádí, že prezentující certifikátu je v clusteru přijat jako partnerský uzel, pokud běžný název certifikátu odpovídá řetězci "cluster.demo.system.servicefabric.azure-int" a kryptografický otisk přímého vystavitele certifikátu odpovídá jedné z položek oddělených čárkami v poli Hodnota. (Tento typ pravidla se označuje jako "běžný název s připnutím vystavitele".)

V obou případech se řetěz certifikátu sestaví a očekává se, že bude bez chyb; chyby odvolání, částečné řetězení nebo chyby důvěryhodnosti neplatného času jsou považovány za závažné a ověření certifikátu selže. Připnutí vystavitelů způsobí, že stav nedůvěryhodného kořenového adresáře bude považován za ne závažnou chybu; navzdory vzhledu je to přísnější forma ověřování, protože umožňuje vlastníkovi clusteru omezit sadu autorizovaných/přijatých vystavitelů na vlastní PKI.

Po vytvoření řetězu certifikátů se ověří standardní zásada TLS/SSL s deklarovaným subjektem jako vzdáleným názvem; certifikát bude považován za shodu, pokud jeho běžný název subjektu nebo některý z jeho alternativních názvů subjektu odpovídá deklaraci CN z manifestu clusteru. V tomto případě se podporují zástupné znaky a porovnávání řetězců nerozlišuje malá a velká písmena.

(Měli bychom objasnit, že výše popsaná posloupnost by mohla být provedena pro každý typ použití klíče deklarovaného certifikátem. Pokud certifikát určuje použití ověřovacího klíče klienta, řetěz se sestaví a vyhodnotí jako první pro roli klienta. V případě úspěchu je vyhodnocení dokončeno a ověření úspěšné. Pokud certifikát nemá využití ověřování klienta nebo ověření selhalo, modul runtime Service Fabric sestaví a vyhodnotí řetěz ověřování serveru.)

K dokončení příkladu znázorňuje následující výňatek deklarování klientských certifikátů běžným názvem:

    <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>

Výše uvedené deklarace odpovídají identitám správců a uživatelů; ověřování certifikátů deklarovaných tímto způsobem je přesně popsáno v předchozích příkladech certifikátů clusteru a serveru.

Poznámka:

Běžné deklarace založené na názvech jsou určeny ke zjednodušení obměny a obecně ke správě certifikátů clusteru. Doporučuje se ale dodržovat následující doporučení, aby se zajistila nepřetržitá dostupnost a zabezpečení clusteru:

  • preferovat připnutí vystavitele k závislosti na důvěryhodných kořenech
  • vyhnout se kombinování vystavitelů z různých veřejných klíčů
  • zajistit, aby všechny očekávané vystavitele byly uvedeny v deklaraci certifikátu; neshodující se vystavitel způsobí neúspěšné ověření.
  • ujistěte se, že koncové body zásad certifikátu PKI jsou zjistitelné, dostupné a přístupné – to znamená, že koncové body AIA, CRL nebo OCSP jsou deklarovány v certifikátu typu list a že jsou přístupné, aby bylo možné dokončit vytváření řetězu certifikátů.

Při spojování všech jednotek po přijetí požadavku na připojení v clusteru zabezpečeném pomocí certifikátů X.509 použije modul runtime Service Fabric nastavení zabezpečení clusteru k ověření přihlašovacích údajů vzdálené strany, jak je popsáno výše; v případě úspěchu se volající nebo vzdálená strana považuje za ověřenou. Pokud přihlašovací údaje splňují více ověřovacích pravidel, modul runtime volajícímu udělí nejvyšší privilegovanou roli některého z odpovídajících pravidel.

Pravidla prezentace

Předchozí část popisuje, jak funguje ověřování v clusteru zabezpečeném certifikátem; tato část vysvětluje, jak modul runtime Service Fabric sám zjistí a načte certifikáty, které používá pro komunikaci v clusteru; nazýváme tato pravidla "prezentace".

Stejně jako u ověřovacích pravidel určují pravidla prezentace roli a přidruženou deklaraci přihlašovacích údajů vyjádřenou kryptografickým otiskem nebo běžným názvem. Na rozdíl od ověřovacích pravidel nemají běžné deklarace založené na názvu ustanovení pro připnutí vystavitele; to umožňuje větší flexibilitu i vyšší výkon. Pravidla prezentace jsou deklarována v oddílech NodeType manifestu clusteru pro každý odlišný typ uzlu; nastavení jsou rozdělena z částí Zabezpečení clusteru, aby každý typ uzlu měl úplnou konfiguraci v jedné části. V clusterech Azure Service Fabric jsou deklarace certifikátu typu uzlu výchozí pro odpovídající nastavení v části Zabezpečení definice clusteru.

Deklarace prezentace certifikátu založené na kryptografickém otisku

Jak jsme už popsali dříve, modul runtime Service Fabric rozlišuje svou roli jako partnerský vztah jiných uzlů v clusteru a jako server pro operace správy clusteru. V zásadě je možné tato nastavení nakonfigurovat odlišně, ale v praxi se obvykle zarovnají. Ve zbývající části tohoto článku předpokládáme, že nastavení odpovídá jednoduchosti.

Podívejme se na následující výňatek z manifestu clusteru:

  <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 ukazuje úplné schéma, včetně volitelných parametrů (X509FindValueSecondary) nebo těch s příslušnými výchozími hodnotami (X509StoreName); v ostatních deklaracích je zkrácený formulář. Výše uvedená deklarace certifikátu clusteru uvádí, že nastavení zabezpečení uzlů typu nt1vm je inicializováno certifikátem cc71.. 1984 jako primární a 49e2. Certifikát 19d6 jako sekundární; Očekává se, že se oba certifikáty nacházejí v úložišti certifikátů LocalMachine'My' (nebo ekvivalentní cesta Linuxu, var/lib/sfcerts).

Běžné deklarace prezentací certifikátů založené na názvech

Certifikáty typu uzlu lze deklarovat také běžným názvem subjektu, jak je znázorněno níže:

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

U některého typu deklarace uzel Service Fabric přečte konfiguraci při spuštění, vyhledá a načte zadané certifikáty a seřadí je sestupně podle atributu NotBefore; Prošlé certifikáty se ignorují a první prvek seznamu je vybrán jako přihlašovací údaje klienta pro jakékoli připojení Service Fabric, o které se tento uzel pokusil. (Service Fabric ve výsledku upřednostňuje nejnovější vydaný certifikát.)

Poznámka:

Před verzí 7.2.445 (7.2 CU4) služba Service Fabric vybrali nejnovější certifikát s vypršenou platností (certifikát s nejbližší vlastností NotAfter).

Všimněte si, že pro deklarace prezentace založené na běžných názvech se certifikát považuje za shodu, pokud se její běžný název subjektu rovná poli X509FindValue (nebo X509FindValueSecondary) deklarace jako přesné porovnání řetězců s rozlišováním velkých a malých písmen. To je na rozdíl od ověřovacích pravidel, která podporují porovnávání se zástupnými znaky a porovnávání řetězců bez rozlišování malých a velkých písmen.

Různá nastavení konfigurace certifikátu

Dříve bylo zmíněno, že nastavení zabezpečení clusteru Service Fabric také umožňuje subtálně měnit chování ověřovacího kódu. Zatímco článek o nastavení clusteru Service Fabric představuje komplexní a nejaktuálnější seznam nastavení, rozšíříme význam několika zde vybraných nastavení zabezpečení, abychom dokončili úplné zveřejnění ověřování na základě certifikátů. Pro každé nastavení vysvětlíme záměr, výchozí hodnotu nebo chování, jak ovlivňuje ověřování a jaké hodnoty jsou přijatelné.

Jak už bylo zmíněno, ověření certifikátu vždy znamená sestavení a vyhodnocení řetězu certifikátu. U certifikátů vydaných certifikační autoritou obvykle toto jednoduché volání rozhraní API operačního systému obvykle zahrnuje několik odchozích volání různých koncových bodů vydávající infrastruktury veřejných klíčů, ukládání odpovědí do mezipaměti atd. Vzhledem k prevalenci volání ověření certifikátů v clusteru Service Fabric můžou všechny problémy v koncových bodech infrastruktury veřejných klíčů vést ke snížení dostupnosti clusteru nebo k přímé rozpisu. I když odchozí volání nelze potlačit (další informace najdete níže v části Nejčastější dotazy), následující nastavení lze použít k maskování chyb ověřování způsobených neúspěšnými voláními seznamu CRL.

  • CrlCheckingFlag – v části "Zabezpečení" řetězec převedený na UINT. Hodnota tohoto nastavení se používá službou Service Fabric k maskování chyb stavu řetězu certifikátů změnou chování řetězové budovy; Předá se do volání Win32 CryptoAPI CertGetCertificateChain jako parametr dwFlags a lze ho nastavit na libovolnou platnou kombinaci příznaků přijatých funkcí. Hodnota 0 vynutí modul runtime Service Fabric ignorovat všechny chyby stavu důvěryhodnosti – nedoporučuje se, protože jeho použití by představovalo významné ohrožení zabezpečení. Výchozí hodnota je 0x40000000 (CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT).

Kdy použít: pro místní testování s certifikáty podepsanými svým držitelem nebo certifikáty vývojářů, které nejsou plně vytvořené nebo nemají správnou infrastrukturu veřejného klíče pro podporu certifikátů. Při přechodu mezi infrastrukturami veřejných klíčů se může také použít jako zmírnění rizik v prostředích se vzduchem.

Postupy: Použijeme příklad, který vynutí kontrolu odvolání jenom pro přístup k adresám URL uloženým v mezipaměti. Za předpokladu:

#define CERT_CHAIN_REVOCATION_CHECK_CACHE_ONLY         0x80000000

pak se deklarace v manifestu clusteru stane:

  <Section Name="Security">
    <Parameter Name="CrlCheckingFlag" Value="0x80000000" />
  </Section>
  • IgnoreCrlOfflineError – v části Zabezpečení je logická hodnota s výchozí hodnotou false. Představuje zástupce pro potlačení stavu chyby sestavení řetězu odvolání offline (nebo následného stavu chyby ověření zásad řetězu).

Kdy použít: místní testování nebo s certifikáty vývojářů, které nejsou podporovány správnou pkI. Používejte jako zmírnění rizik v prostředích s mezerami vzduchu nebo v případě, že je infrastruktura veřejných klíčů nepřístupná.

Jak používat:

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

Další použitelná nastavení (všechna v části Zabezpečení):

  • AcceptExpiredPinnedClusterCertificate – probírá se v části věnované ověření certifikátu založeného na kryptografickém otisku; umožňuje přijmout certifikáty clusteru podepsané svým držitelem, jejichž platnost vypršela.
  • CertificateExpirySafetyMargin – interval vyjádřený v minutách před časovým razítkem notAfter certifikátu a během kterého se certifikát považuje za rizikový pro vypršení platnosti. Service Fabric monitoruje certifikáty clusteru a pravidelně generuje zprávy o stavu jejich zbývající dostupnosti. V intervalu "bezpečnost" jsou tyto zprávy o stavu zvýšeny na stav upozornění. Výchozí hodnota je 30 dní.
  • CertificateHealthReportingInterval – řídí četnost zpráv o stavu týkajících se zbývající doby platnosti certifikátů clusteru. Sestavy se budou generovat pouze jednou za tento interval. Hodnota se vyjadřuje v sekundách s výchozím nastavením 8 hodin.
  • EnforcePrevalidationOnSecurityChanges – logická hodnota, řídí chování upgradu clusteru při zjišťování změn nastavení zabezpečení. Pokud je nastavená hodnota true, upgrade clusteru se pokusí zajistit, aby alespoň jeden z certifikátů odpovídajících libovolnému pravidlu prezentace mohl předat odpovídající ověřovací pravidlo. Před provedením předběžného ověření se provede nové nastavení u jakéhokoli uzlu, ale spustí se pouze na uzlu, který je hostitelem primární repliky služby Správce clusteru v době zahájení upgradu. Od tohoto zápisu má nastavení výchozí hodnotu false a pro nové clustery Azure Service Fabric s verzí modulu runtime počínaje verzí 7.1 se nastaví na true.

Kompletní scénář (příklady)

Podívali jsme se na pravidla prezentace, ověřovací pravidla a úpravy příznaků, ale jak to všechno funguje společně? V této části si projdeme dva ucelené příklady, které ukazují, jak je možné využít nastavení zabezpečení pro bezpečné upgrady clusteru. Mějte na paměti, že to není komplexní přehled o řádné správě certifikátů v Service Fabric, vyhledejte doprovodný článek k tomuto tématu.

Oddělení pravidel pro prezentaci a ověřování představuje jasnou otázku (nebo obavu), zda se mohou rozbíhají a jaké důsledky by měly být. Je skutečně možné, že výběr ověřovacího certifikátu uzlu nepřejde ověřovacími pravidly jiného uzlu. Ve skutečnosti je tato nesrovnalost primární příčinou incidentů souvisejících s ověřováním. Současně oddělení těchto pravidel umožňuje clusteru pokračovat v provozu během upgradu, což změní nastavení zabezpečení clusteru. Vezměte v úvahu, že rozšířením prvních ověřovacích pravidel jako prvního kroku budou všechny uzly clusteru konvergovat na novém nastavení a přitom stále používat aktuální přihlašovací údaje.

Vzpomeňte si, že v clusteru Service Fabric probíhá upgrade prostřednictvím (až 5) upgradových domén nebo identifikátorů UD. V daném okamžiku se upgradují nebo mění jenom uzly v aktuálním UD a upgrade bude pokračovat k dalšímu UD jenom v případě, že to dostupnost clusteru umožňuje. (Viz Další podrobnosti najdete v upgradech clusteru Service Fabric a dalších článcích na stejném tématu.) Změny certifikátů a zabezpečení jsou zvláště rizikové, protože můžou izolovat uzly od clusteru nebo ponechat cluster na okraji ztráty kvora.

K popisu nastavení zabezpečení uzlu použijeme následující zápis:

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

  • Nk představuje uzel v upgradovanou doméně k
  • "P" představuje aktuální pravidla prezentace uzlu (za předpokladu, že odkazujeme pouze na certifikáty clusteru);
  • 'V' představuje aktuální ověřovací pravidla uzlu (pouze certifikát clusteru)
  • 'TP=A' představuje deklaraci založenou na kryptografickém otisku (TP) a "A" je kryptografický otisk certifikátu.
  • "CN=B" představuje společnou deklaraci založenou na názvu (CN), přičemž "B" je běžný název subjektu certifikátu.

Obměně certifikátu clusteru deklarovaného kryptografickým otiskem

Následující posloupnost popisuje, jak lze použít 2fázový upgrade k bezpečnému zavedení certifikátu sekundárního clusteru deklarovaného kryptografickým otiskem; První fáze zavádí novou deklaraci certifikátu v ověřovacích pravidlech a druhá fáze ji zavádí do prezentačních pravidel:

  • počáteční stav: N0 = {P:{TP=A}, V:{TP=A}}, ... Nk = {P:{TP=A}, V:{TP=A}} – cluster je neaktivní, všechny uzly sdílejí společnou konfiguraci.
  • po dokončení upgradu domény 0: N0 = {P:{TP=A}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A}, V:{TP=A}} – uzly v UD0 budou prezentovat certifikát A a přijímat certifikáty A nebo B; všechny ostatní uzly, které jsou přítomné a přijímají pouze certifikát A
  • po dokončení poslední upgradování domény: N0 = {P:{TP=A}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A}, V:{TP=A, TP=B}} – všechny uzly prezentující certifikát A, všechny uzly by přijímaly certifikát A nebo B.

V tomto okamžiku je cluster opět v rovnováhy a druhá fáze upgradu/změny nastavení zabezpečení může začít:

  • po dokončení upgradu domény 0: N0 = {P:{TP=A, TP=B}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A}, V:{TP=A, TP=B}} – uzly v UD0 začnou prezentovat B, což přijme jakýkoli jiný uzel v clusteru.
  • po dokončení poslední upgradování domény: N0 = {P:{TP=A, TP=B}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A, TP=B}, V:{TP=A, TP=B}} – všechny uzly se přepnuly na prezentaci certifikátu B. Certifikát A se teď dá z definice clusteru vyřadit nebo odebrat s následnou sadou upgradů.

Převod clusteru z kryptografického otisku na deklarace certifikátů založených na běžných názvech

Podobně bude změna typu deklarace certifikátu (z kryptografického otisku na běžný název) postupovat stejným způsobem jako výše. Všimněte si, že ověřovací pravidla umožňují deklarovat certifikáty dané role kryptografickým otiskem i běžným názvem ve stejné definici clusteru. Naproti tomu pravidla prezentace umožňují pouze jednu formu deklarace. Mimochodem, bezpečný přístup k převodu certifikátu clusteru z kryptografického otisku na běžný název je zavést zamýšlený cílový certifikát nejprve kryptografickým otiskem a pak tuto deklaraci změnit na běžný název založený na názvu. V následujícím příkladu budeme předpokládat, že kryptografický otisk A a běžný název subjektu B odkazuje na stejný certifikát.

  • počáteční stav: N0 = {P:{TP=A}, V:{TP=A}}, ... Nk = {P:{TP=A}, V:{TP=A}} – cluster je neaktivní, všechny uzly sdílejí společnou konfiguraci s kryptografickým otiskem primárního certifikátu.
  • po dokončení upgradu domény 0: N0 = {P:{TP=A}, V:{TP=A, CN=B}}, ... Nk = {P:{TP=A}, V:{TP=A}} – uzly v UD0 budou prezentovat certifikát A a přijímat certifikáty s kryptografickým otiskem A nebo běžným názvem B; všechny ostatní uzly, které jsou přítomné a přijímají pouze certifikát A
  • po dokončení poslední domény upgradu: N0 = {P:{TP=A}, V:{TP=A, CN=B}}, ... Nk = {P:{TP=A}, V:{TP=A, CN=B}} – všechny uzly prezentující certifikát A, všechny uzly by přijímaly certifikát A (TP) nebo B (CN).

V tuto chvíli můžeme pokračovat ve změně pravidel prezentace s následným upgradem:

  • po dokončení upgradu domény 0: N0 = {P:{CN=B}, V:{TP=A, CN=B}}, ... Nk = {P:{TP=A}, V:{TP=A, CN=B}} – uzly v UD0 budou prezentovat certifikát B nalezený cn a přijímají certifikáty s kryptografickým otiskem A nebo běžným názvem B; všechny ostatní uzly, které jsou přítomné a přijímají pouze certifikát A vybraný kryptografickým otiskem
  • po dokončení poslední domény upgradu: N0 = {P:{CN=B}, V:{TP=A, CN=B}}, ... Nk = {P:{CN=B}, V:{TP=A, CN=B}} – všechny uzly prezentující certifikát B nalezený cn, všechny uzly by přijímaly certifikát A (TP) nebo B (CN).

Dokončení fáze 2 označuje také převod clusteru na běžné certifikáty založené na názvech; Deklarace ověřování založené na kryptografickém otisku je možné v následném upgradu clusteru odebrat.

Poznámka:

V clusterech Azure Service Fabric jsou výše uvedené pracovní postupy orchestrovány poskytovatelem prostředků Service Fabric; Vlastník clusteru stále zodpovídá za zřizování certifikátů do clusteru podle uvedených pravidel (prezentace nebo ověření) a doporučuje se provádět změny v několika krocích.

V samostatném článku se budeme zabývat tématem správy a zřizování certifikátů v clusteru Service Fabric.

Řešení potíží a nejčastější dotazy

I když ladění problémů souvisejících s ověřováním v clusterech Service Fabric není snadné, doufáme, že vám pomůžou následující rady a tipy. Nejjednodušší způsob, jak zahájit šetření, je prozkoumat protokoly událostí Service Fabric na uzlech clusteru – nejen ty, které vykazují příznaky, ale také uzly, které jsou v provozu, ale nemůžou se připojit k jednomu ze svých sousedů. Ve Windows jsou události významnosti obvykle protokolovány v kanálech Applications and Services Logs\Microsoft-ServiceFabric\Admin nebo Operational. Někdy může být užitečné povolit protokolování CAPI2, zachytit další podrobnosti týkající se ověření certifikátu, načtení seznamu CRL/CTL atd. (Nezapomeňte ho po dokončení opakování zakázat. Může to být docela podrobné.)

Typické příznaky, které se projevuje v clusteru, u kterých dochází k problémům s ověřováním, jsou:

  • uzly jsou dole/cyklistika
  • Pokusy o připojení jsou odmítnuty.
  • Vypršení časového limitu pokusů o připojení

Každý z příznaků může být způsoben různými problémy, a stejná původní příčina může ukazovat různé projevy; jako takové zobrazíme malý vzorek typických problémů s doporučeními pro jejich opravu.

  • Uzly můžou vyměňovat zprávy, ale nemůžou se připojit. Možná příčina ukončení pokusů o připojení je chyba "Certifikát neodpovídá" – jedna ze stran v připojení Service Fabric-to-Service Fabric prezentuje certifikát, který selže ověřovacími pravidly příjemce. Může být doprovázena některou z následujících chyb:

    0x80071c44	-2147017660	FABRIC_E_SERVER_AUTHENTICATION_FAILED

    Pokud chcete diagnostikovat nebo prozkoumat další informace: na každém uzlu, který se pokouší o připojení, určete, který certifikát se prezentuje; zkontrolujte certifikát a zkuste napodobit ověřovací pravidla (zkontrolujte, jestli je kryptografický otisk nebo rovnost běžných názvů, zkontrolujte, jestli jsou zadány kryptografické otisky vystavitele).

    Dalším běžným doprovodným kódem chyby může být:

    0x800b0109	-2146762487	CERT_E_UNTRUSTEDROOT

    V tomto případě je certifikát deklarován běžným názvem a platí následující:

    • vydavatelé nejsou připnuti a kořenový certifikát není důvěryhodný nebo
    • vydavatelé jsou připnuti, ale deklarace neobsahuje kryptografický otisk přímého vystavitele tohoto certifikátu.

  • Uzel je vzhůru, ale nemůže se připojit k jiným uzlům; ostatní uzly nepřicházejí příchozí provoz z neúspěšného uzlu. V takovém případě je možné, že načítání certifikátu na místním uzlu selže. Vyhledejte následující chyby:

    • certifikát nebyl nalezen – ujistěte se, že certifikáty deklarované v pravidlech prezentace lze vyřešit obsahem úložiště certifikátů LocalMachine\My (nebo podle zadaného). Možné příčiny selhání můžou zahrnovat:

      • Neplatné znaky v deklaraci kryptografického otisku
      • certifikát není nainstalován.
      • Platnost certifikátu vypršela.
      • deklarace common-name obsahuje předponu CN=.
      • deklarace určuje zástupný znak a v úložišti certifikátů neexistuje přesná shoda (deklarace: CN=*.mydomain.com, skutečný certifikát: CN=server.mydomain.com).

    • Neznámé přihlašovací údaje – označuje buď chybějící privátní klíč odpovídající certifikátu, obvykle doprovázený kódem chyby:

      0x8009030d	-2146893043	SEC_E_UNKNOWN_CREDENTIALS
0x8009030e	-2146893042	SEC_E_NO_CREDENTIALS

      Chcete-li napravit, zkontrolujte existenci soukromého klíče; ověřte, že nástroj SFAdmins má udělený přístup ke čtení|execute k privátnímu klíči.

    • Chybný typ poskytovatele – označuje certifikát Crypto New Generation (CNG) (Poskytovatel úložiště softwarových klíčů Společnosti Microsoft); v tuto chvíli Service Fabric podporuje pouze certifikáty CAPI1. Obvykle je doprovázen kódem chyby:

      0x80090014	-2146893804	NTE_BAD_PROV_TYPE

      Pokud chcete certifikát clusteru napravit, vytvořte ho znovu pomocí zprostředkovatele CAPI1 (např. "Microsoft Enhanced RSA a AES Cryptographic Provider"). Další podrobnosti o poskytovatelích kryptografických služeb najdete v tématu Principy kryptografických zprostředkovatelů.