Scénáře zabezpečení clusteru Service Fabric

Článek
08/25/2024

Cluster Azure Service Fabric je prostředek, který vlastníte. Je vaší zodpovědností zabezpečit clustery, aby se zabránilo neoprávněným uživatelům v jejich připojování. Zabezpečený cluster je zvlášť důležitý při spouštění produkčních úloh v clusteru. Je možné vytvořit nezabezpečený cluster, ale pokud cluster zveřejňuje koncové body správy pro veřejný internet, můžou se k němu anonymní uživatelé připojit. Nezabezpečené clustery nejsou podporovány pro produkční úlohy.

Tento článek obsahuje přehled scénářů zabezpečení pro clustery Azure a samostatné clustery a různé technologie, které můžete použít k jejich implementaci:

Zabezpečení uzlů na uzel
Zabezpečení mezi klienty a uzly
Řízení přístupu na základě role Service Fabric

Zabezpečení uzlů na uzel

Zabezpečení mezi uzly pomáhá zabezpečit komunikaci mezi virtuálními počítači nebo počítači v clusteru. Tento scénář zabezpečení zajišťuje, že se do hostování aplikací a služeb v clusteru můžou zapojit jenom počítače s oprávněním k připojení ke clusteru.

Diagram komunikace mezi uzly

Clustery spuštěné v Azure a samostatné clustery spuštěné v systému Windows můžou používat zabezpečení certifikátů nebo zabezpečení Windows pro počítače s Windows Serverem.

Zabezpečení certifikátu node-to-node

Service Fabric používá certifikáty serveru X.509, které zadáte jako součást konfigurace typu uzlu při vytváření clusteru. Zabezpečení certifikátů můžete nastavit na webu Azure Portal pomocí šablony Azure Resource Manageru nebo pomocí samostatné šablony JSON. Na konci tohoto článku si můžete prohlédnout stručný přehled o tom, co jsou tyto certifikáty a jak je můžete získat nebo vytvořit.

Výchozím chováním sady Service Fabric SDK je nasazení a instalace certifikátu s nejbližším datem vypršení platnosti. Tento primární certifikát by se měl lišit od klienta pro správu a klientských certifikátů jen pro čtení, které jste nastavili pro zabezpečení mezi klienty a uzly. Klasické chování sady SDK umožnilo definování primárních a sekundárních certifikátů, aby bylo možné ručně iniciované převody; nedoporučuje se používat pro nové funkce.

Informace o nastavení zabezpečení certifikátů v clusteru pro Azure najdete v tématu Nastavení clusteru pomocí šablony Azure Resource Manageru.

Informace o nastavení zabezpečení certifikátů v clusteru pro samostatný cluster Windows Serveru najdete v tématu Zabezpečení samostatného clusteru ve Windows pomocí certifikátů X.509.

Zabezpečení Windows mezi uzly

Poznámka:

Ověřování systému Windows je založené na protokolu Kerberos. Protokol NTLM není podporován jako typ ověřování.

Kdykoli je to možné, použijte ověřování certifikátů X.509 pro clustery Service Fabric.

Informace o nastavení zabezpečení Windows pro samostatný cluster Windows Serveru najdete v tématu Zabezpečení samostatného clusteru ve Windows pomocí zabezpečení Systému Windows.

Zabezpečení mezi klienty a uzly

Zabezpečení mezi klienty a uzly ověřuje klienty a pomáhá zabezpečit komunikaci mezi klientem a jednotlivými uzly v clusteru. Tento typ zabezpečení pomáhá zajistit, aby ke clusteru měli přístup jenom oprávnění uživatelé a aplikace nasazené v clusteru. Klienti jsou jedinečně identifikováni prostřednictvím svých přihlašovacích údajů zabezpečení systému Windows nebo přihlašovacích údajů zabezpečení certifikátu.

Diagram komunikace mezi klientem a uzlem

Clustery spuštěné v Azure a samostatné clustery spuštěné ve Windows můžou používat buď zabezpečení certifikátů, nebo zabezpečení Windows, ale doporučuje se použít ověřování certifikátů X.509, kdykoli je to možné.

Zabezpečení certifikátu mezi klientem a uzlem

Při vytváření clusteru na webu Azure Portal pomocí šablony Resource Manageru nebo pomocí samostatné šablony JSON nastavte zabezpečení certifikátů typu klient-uzel. Pokud chcete vytvořit certifikát, zadejte klientský certifikát správce nebo klientský certifikát uživatele. Osvědčeným postupem je, že zadané klientské certifikáty klienta a uživatele pro správu by se měly lišit od primárních a sekundárních certifikátů, které zadáte pro zabezpečení mezi uzly. Certifikáty clusteru mají stejná práva jako certifikáty správce klienta. Jako osvědčený postup zabezpečení by je ale měl používat jenom cluster, a ne správci.

Klienti, kteří se připojují ke clusteru pomocí certifikátu správce, mají úplný přístup k možnostem správy. Klienti, kteří se připojují ke clusteru pomocí klientského certifikátu uživatele jen pro čtení, mají k možnostem správy přístup jen pro čtení. Tyto certifikáty se používají pro RBAC Service Fabric popsané dále v tomto článku.

Informace o nastavení zabezpečení certifikátů v clusteru pro Azure najdete v tématu Nastavení clusteru pomocí šablony Azure Resource Manageru.

Informace o nastavení zabezpečení certifikátů v clusteru pro samostatný cluster Windows Serveru najdete v tématu Zabezpečení samostatného clusteru ve Windows pomocí certifikátů X.509.

Zabezpečení Microsoft Entra mezi klienty v Azure

Microsoft Entra ID umožňuje organizacím (označované jako tenanti) spravovat přístup uživatelů k aplikacím. Aplikace jsou rozdělené do aplikací s webovým přihlašovacím uživatelským rozhraním a aplikacemi s nativním klientským prostředím. Pokud jste tenanta ještě nevytvořili, začněte tím, že si přečtete , jak získat tenanta Microsoft Entra.

V případě clusterů spuštěných v Azure můžete také pomocí ID Microsoft Entra zabezpečit přístup ke koncovým bodům správy. Cluster Service Fabric nabízí několik vstupních bodů ke své funkci správy, včetně webového Service Fabric Exploreru a sady Visual Studio. V důsledku toho můžete řídit přístup ke clusteru, který vytvoříte dvě aplikace Microsoft Entra: jednu webovou aplikaci a jednu nativní aplikaci. Informace o tom, jak vytvořit požadované artefakty Microsoft Entra a jak je naplnit při vytváření clusteru, najdete v tématu Nastavení ID Microsoft Entra pro ověřování klientů.

Doporučení zabezpečení

U clusterů Service Fabric nasazených ve veřejné síti hostované v Azure doporučujeme vzájemné ověřování mezi klienty:

Použití ID Microsoft Entra pro identitu klienta
Certifikát pro identitu serveru a šifrování TLS komunikace http

U clusterů Service Fabric nasazených ve veřejné síti hostované v Azure doporučujeme k ověření uzlů použít certifikát clusteru.

Pro samostatné clustery Windows Serveru, pokud máte Windows Server 2012 R2 a Windows Active Directory, doporučujeme používat zabezpečení Systému Windows se skupinami účty spravované služby. V opačném případě použijte zabezpečení Windows s účty Windows.

Řízení přístupu na základě role Service Fabric

Řízení přístupu můžete použít k omezení přístupu k určitým operacím clusteru pro různé skupiny uživatelů. To pomáhá zajistit lepší zabezpečení clusteru. Pro klienty, kteří se připojují ke clusteru, se podporují dva typy řízení přístupu: role správce a role uživatele.

Uživatelé, kteří mají přiřazenou roli Správce, mají úplný přístup k možnostem správy, včetně možností čtení a zápisu. Uživatelé, kteří mají ve výchozím nastavení přiřazenou roli Uživatel, mají k možnostem správy přístup jen pro čtení (například možnosti dotazů). Můžou také řešit aplikace a služby.

Při vytváření clusteru nastavte role klienta správce a uživatele. Přiřaďte role zadáním samostatných identit (například pomocí certifikátů nebo ID Microsoft Entra) pro každý typ role. Další informace o výchozích nastaveních řízení přístupu a o tom, jak změnit výchozí nastavení, najdete v tématu Řízení přístupu na základě role Service Fabric pro klienty Service Fabric.

Certifikáty X.509 a Service Fabric

Digitální certifikáty X.509 se běžně používají k ověřování klientů a serverů. Slouží také k šifrování a digitálnímu podepisování zpráv. Service Fabric používá certifikáty X.509 k zabezpečení clusteru a poskytování funkcí zabezpečení aplikací. Další informace o digitálních certifikátech X.509 naleznete v tématu Práce s certifikáty. Key Vault slouží ke správě certifikátů pro clustery Service Fabric v Azure.

Je potřeba vzít v úvahu několik důležitých věcí:

Pokud chcete vytvořit certifikáty pro clustery, na kterých běží produkční úlohy, použijte správně nakonfigurovanou certifikační službu Windows Serveru nebo jednu ze schválené certifikační autority (CA).
Nikdy nepoužívejte žádné dočasné nebo testovací certifikáty, které vytvoříte pomocí nástrojů, jako je MakeCert.exe v produkčním prostředí.
Certifikát podepsaný svým držitelem můžete použít, ale jenom v testovacím clusteru. Nepoužívejte certifikát podepsaný svým držitelem v produkčním prostředí.
Při generování kryptografického otisku certifikátu nezapomeňte vygenerovat kryptografický otisk SHA1. SHA1 se používá při konfiguraci kryptografických otisků certifikátu klienta a clusteru.

Certifikát clusteru a serveru (povinné)

Tyto certifikáty (jeden primární a volitelně sekundární) jsou potřeba k zabezpečení clusteru a zabránění neoprávněnému přístupu k němu. Tyto certifikáty poskytují ověřování clusteru a serveru.

Ověřování clusteru ověřuje komunikaci mezi uzly pro federaci clusteru. Ke clusteru se můžou připojit jenom uzly, které můžou prokázat svoji identitu pomocí tohoto certifikátu. Ověřování serveru ověřuje koncové body správy clusteru klientovi pro správu, aby klient pro správu věděl, že mluví se skutečným clusterem, a ne s "mužem uprostřed". Tento certifikát také poskytuje protokol TLS pro rozhraní API pro správu HTTPS a pro Service Fabric Explorer přes PROTOKOL HTTPS. Když klient nebo uzel ověří uzel, jedna z počátečních kontrol je hodnota společného názvu v poli Předmět . Tento běžný název nebo jeden z alternativních názvů subjektu certifikátů (SANs) musí být v seznamu povolených běžných názvů.

Certifikát musí splňovat následující požadavky:

Certifikát musí obsahovat privátní klíč. Tyto certifikáty obvykle mají přípony .pfx nebo .pem.
Certifikát musí být vytvořen pro výměnu klíčů, který je exportovatelný do souboru Personal Information Exchange (.pfx).
Název subjektu certifikátu se musí shodovat s doménou, kterou používáte pro přístup ke clusteru Service Fabric. Tato shoda se vyžaduje k poskytnutí protokolu TLS pro koncový bod správy HTTPS clusteru a Service Fabric Exploreru. Certifikát TLS/SSL nelze získat od certifikační autority (CA) pro doménu *.cloudapp.azure.com. Pro svůj cluster musíte získat název vlastní domény. Pokud požádáte o certifikát od certifikační autority, musí název subjektu certifikátu odpovídat názvu vlastní domény, který používáte pro svůj cluster.

Některé další věci, které je potřeba vzít v úvahu:

Pole Předmět může mít více hodnot. Každá hodnota má předponu inicializace označující typ hodnoty. Inicializace je obvykle CN (pro běžný název), například CN = www.contoso.com.
Pole Předmět může být prázdné.
Pokud je vyplněné volitelné pole Alternativní název subjektu, musí mít společný název certifikátu i jednu položku na síť SAN. Tyto hodnoty se zadávají jako hodnoty názvu DNS. Informace o vygenerování certifikátů, které mají sítě SAN, najdete v tématu Postup přidání alternativního názvu subjektu k zabezpečenému certifikátu LDAP.
Hodnota pole Zamýšlený účel certifikátu by měla obsahovat odpovídající hodnotu, například ověřování serveru nebo ověřování klienta.

Certifikáty aplikací (volitelné)

V clusteru je možné nainstalovat libovolný počet dalších certifikátů pro účely zabezpečení aplikací. Před vytvořením clusteru zvažte scénáře zabezpečení aplikací, které vyžadují instalaci certifikátu na uzlech, například:

Šifrování a dešifrování hodnot konfigurace aplikace
Šifrování dat mezi uzly během replikace

Koncept vytváření zabezpečených clusterů je stejný bez ohledu na to, jestli se jedná o clustery s Linuxem nebo Windows.

Klientské ověřovací certifikáty (volitelné)

Pro operace správce nebo klienta uživatele je možné zadat libovolný počet dalších certifikátů. Klient může tyto certifikáty používat, pokud je vyžadováno vzájemné ověřování. Klientské certifikáty obvykle nevystavují certifikační autorita třetí strany. Místo toho osobní úložiště aktuálního umístění uživatele obvykle obsahuje klientské certifikáty umístěné v kořenové autoritě. Certifikát by měl mít hodnotu Zamýšlený účel ověřování klienta.

Ve výchozím nastavení má certifikát clusteru oprávnění klienta správce. Tyto další klientské certifikáty by se do clusteru neměly instalovat, ale jsou určené jako povolené v konfiguraci clusteru. Klientské certifikáty ale musí být nainstalované na klientských počítačích, aby se připojily ke clusteru a provedly všechny operace.