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

cluster Azure Service Fabric je prostředek, který vlastníte. Je vaše zodpovědnost za zabezpečení clusterů, aby se zabránilo neoprávněným uživatelům v jejich připojení. Zabezpečený cluster je obzvláště důležitý při spuš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 na veřejný Internet, můžou se k němu připojit anonymní uživatelé. Nezabezpečené clustery se pro produkční úlohy nepodporují.

Tento článek představuje 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í mezi uzly
• Zabezpečení klient-uzel
• Service Fabric řízení přístupu na základě role

Zabezpečení mezi uzly

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 můžou účastnit hostování aplikací a služeb v clusteru jenom počítače, které jsou autorizované pro připojení ke clusteru.

clustery běžící v Azure a samostatné clustery se systémem v Windows můžou pro Windows serverových počítačů použít zabezpečení certifikátů nebo zabezpečení Windows .

Zabezpečení certifikátů mezi uzly

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átu můžete nastavit buď v Azure Portal, pomocí šablony Azure Resource Manager, nebo pomocí samostatné šablony JSON. Na konci tohoto článku vidíte stručný přehled toho, co tyto certifikáty jsou a jak je můžete získat nebo vytvořit.

Service Fabric Výchozím chováním sady SDK je nasadit a nainstalovat certifikát v budoucnu do data vypršení platnosti. Tento primární certifikát by měl být odlišný od klienta správce a klientských certifikátů jen pro čtení, které jste nastavili pro zabezpečení klient-uzel. Klasické chování sady SDK povoluje definování primárních a sekundárních certifikátů, aby bylo možné ručně iniciovat přecházení. nedoporučuje se používat pro nové funkce.

Informace o tom, jak nastavit zabezpečení certifikátů v clusteru pro Azure, najdete v tématu Nastavení clusteru pomocí šablony Azure Resource Manager.

informace o tom, jak nastavit zabezpečení certifikátů v clusteru pro samostatný serverový cluster Windows, najdete v tématu zabezpečení samostatného clusteru v Windows pomocí certifikátů X. 509.

zabezpečení mezi uzly Windows

informace o nastavení zabezpečení Windows samostatném serverovém clusteru Windows najdete v tématu zabezpečení samostatného clusteru v Windows pomocí zabezpečení Windows.

Zabezpečení klient-uzel

Zabezpečení typu klient-uzel ověřuje klienty a pomáhá zabezpečit komunikaci mezi klientem a jednotlivými uzly v clusteru. Tento typ zabezpečení pomáhá zajistit, že ke clusteru a aplikacím nasazeným v clusteru mají přístup jenom autorizovaní uživatelé. klienti se jednoznačně identifikují pomocí přihlašovacích údajů zabezpečení Windows nebo jejich přihlašovacích údajů pro zabezpečení certifikátů.

clustery běžící v Azure a samostatné clustery, které běží na Windows, můžou používat zabezpečení certifikátů nebo zabezpečení Windows, i když je to možné, doporučuje se používat ověřování certifikátu X. 509, kdykoli to bude možné.

Zabezpečení certifikátu klienta k uzlu

Nastavte zabezpečení certifikátu klienta na uzel při vytváření clusteru, a to buď v Azure Portal, pomocí Správce prostředků šablony, nebo pomocí samostatné šablony JSON. Certifikát vytvoříte tak, že zadáte certifikát klienta správce nebo klientský certifikát uživatele. Osvědčeným postupem je, že je třeba zadat klientské certifikáty pro správce a uživatele, které zadáte, se liší 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. Měli byste je ale používat jenom v clusterech a ne prostřednictvím administrativních uživatelů jako osvědčený postup zabezpečení.

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 jen pro čtení, mají přístup jen pro čtení k funkcím pro správu. tyto certifikáty se používají pro Service Fabric RBAC, která je popsána dále v tomto článku.

Informace o tom, jak nastavit zabezpečení certifikátů v clusteru pro Azure, najdete v tématu Nastavení clusteru pomocí šablony Azure Resource Manager.

informace o tom, jak nastavit zabezpečení certifikátů v clusteru pro samostatný serverový cluster Windows, najdete v tématu zabezpečení samostatného clusteru v Windows pomocí certifikátů X. 509.

zabezpečení Azure Active Directory klienta na uzel v Azure

Azure Active Directory (Azure AD) umožňuje organizacím (označovaným jako klienti) spravovat přístup uživatelů k aplikacím. Aplikace jsou rozděleny na ty s webovým přihlašovacím uživatelským rozhraním a s nativním klientským prostředím. pokud jste ještě nevytvořili tenanta, začněte tím, že si přečtete, jak získat klienta Azure Active Directory.

Pro clustery běžící v Azure můžete k zabezpečení přístupu ke koncovým bodům správy použít taky službu Azure AD. cluster Service Fabric nabízí ke své funkci správy několik vstupních bodů, včetně webových Service Fabric Explorer a Visual Studio. V důsledku toho můžete řídit přístup ke clusteru, který vytváříte dvě aplikace Azure AD: jednu webovou aplikaci a jednu nativní aplikaci. Informace o tom, jak vytvořit požadované artefakty Azure AD a jak je naplnit při vytváření clusteru, najdete v tématu Nastavení Azure AD pro ověřování klientů.

Doporučení zabezpečení

u clusterů Service Fabric nasazených ve veřejné síti hostované v Azure je doporučení pro vzájemné ověřování mezi klientem a uzlem:

• použití Azure Active Directory pro identitu klienta
• Certifikát pro identitu serveru a šifrování TLS pro komunikaci http

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

pro samostatné serverové clustery Windows, pokud máte Windows Server 2012 R2 a Windows Active Directory, doporučujeme použít Windows zabezpečení se skupinovými účty spravované služby. jinak použijte Windows zabezpečení s účty Windows.

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

Ří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á zvýšit zabezpečení clusteru. Pro klienty, kteří se připojují ke clusteru, jsou podporovány 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 funkcím správy, včetně funkcí pro čtení a zápis. Uživatelům, kteří mají přiřazenou roli uživatele, mají ve výchozím nastavení přístup jen pro čtení k funkcím pro správu (například možnosti dotazů). Můžou také řešit aplikace a služby.

Nastavte role správce a uživatele klienta při vytváření clusteru. Přiřaďte role poskytnutím samostatných identit (například pomocí certifikátů nebo Azure AD) pro každý typ role. další informace o výchozím nastavení řízení přístupu a o tom, jak změnit výchozí nastavení, najdete v tématu Service Fabric řízení přístupu na základě role 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ů. Používají se také k šifrování a digitálnímu podepisování zpráv. Service Fabric k zabezpečení clusteru a poskytování funkcí zabezpečení aplikací používá certifikáty X. 509. Další informace o digitálních certifikátech X. 509 najdete v tématu práce s certifikáty. pomocí Key Vault můžete spravovat certifikáty pro Service Fabric clustery v Azure.

Mezi důležité věci, které je potřeba vzít v úvahu:

• pokud chcete vytvořit certifikáty pro clustery, na kterých běží produkční úlohy, použijte správně konfigurovanou službu Windows Server certificate service nebo jednu z schválených certifikační autority (CA).
• Nikdy nepoužívejte žádné dočasné ani testovací certifikáty, které vytvoříte pomocí nástrojů, jako je MakeCert.exe v produkčním prostředí.
• Můžete použít certifikát podepsaný svým držitelem, ale pouze 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 je to, co se používá při konfiguraci kryptografických otisků certifikátu klienta a clusteru.

Certifikát clusteru a serveru (povinné)

K zabezpečení clusteru a zabránění neoprávněnému přístupu k němu se vyžadují tyto certifikáty (jedna primární a volitelně sekundární). Tyto certifikáty poskytují ověřování clusteru a serverů.

Ověřování clusteru ověřuje komunikaci mezi uzly a federačním clusterem. Do clusteru se mohou připojit pouze uzly, které mohou prokázat svoji identitu pomocí tohoto certifikátu. Ověřování serveru ověřuje koncové body správy clusteru klientovi pro správu, takže klient pro správu ví, že mluví se skutečným clusterem a ne "muž uprostřed". tento certifikát taky poskytuje TLS pro rozhraní API pro správu HTTPS a pro Service Fabric Explorer přes HTTPS. Když klient nebo uzel ověří uzel, jednou z počátečních kontrol je hodnota společného názvu v poli subjekt . V seznamu povolených běžných názvů musí být buď tento běžný název, nebo jeden z alternativních názvů předmětu (San) s certifikáty.

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

• Certifikát musí obsahovat privátní klíč. Tyto certifikáty mají obvykle příponu. pfx nebo. pem.
• certifikát musí být vytvořen pro výměnu klíčů, který lze exportovat do souboru osobních informací 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í TLS pro koncový bod správy HTTPS clusteru a Service Fabric Explorer. Certifikát TLS/SSL nemůžete od certifikační autority (CA) pro doménu *. cloudapp.azure.com získat. 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.

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

• Pole předmětu může mít více hodnot. Každá hodnota je předpona s inicializací k označení typu hodnoty. Obvykle se jedná o inicializaci CN (pro běžný název); například cn = www . contoso.com.
• Pole předmětu může být prázdné.
• Pokud se v poli alternativní název subjektu naplní nepovinné pole, musí mít běžný název certifikátu i jednu položku na síť SAN. Ty se zadávají jako hodnoty názvu DNS . Informace o tom, jak vygenerovat certifikáty, které mají sítě SAN, najdete v tématu Postup přidání alternativního názvu subjektu do certifikátu zabezpečeného protokolu LDAP.
• Hodnota pole zamýšleného účelu certifikátu by měla obsahovat odpovídající hodnotu, jako je ověřování serveru nebo ověřování klientů.

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 Vezměte v úvahu scénáře zabezpečení aplikací, které vyžadují, aby byl v uzlech nainstalován certifikát, například:

• Šifrování a dešifrování hodnot konfigurace aplikace.
• Šifrování dat napříč uzly během replikace.

koncept vytváření zabezpečených clusterů je stejný, bez ohledu na to, jestli jsou clustery Linux nebo Windows.

Certifikáty pro ověřování klientů (volitelné)

Pro klientské operace správce nebo uživatele lze zadat libovolný počet dalších certifikátů. Klient může tyto certifikáty použít, když je potřeba vzájemné ověřování. Klientské certifikáty obvykle nejsou vydávány certifikační autoritou třetí strany. Místo toho osobní úložiště aktuálního umístění uživatele obvykle obsahuje klientské certifikáty, které jsou umístěny v kořenové autoritě. Certifikát by měl mít zamýšlenou hodnotu pro ověření klienta.

Ve výchozím nastavení má certifikát clusteru oprávnění klienta správce. Tyto další klientské certifikáty by neměly být nainstalovány do clusteru, ale jsou zadány jako povolené v konfiguraci clusteru. Klientské certifikáty ale musí být nainstalované na klientských počítačích pro připojení ke clusteru a provádění operací.

Další kroky

• Vytvoření clusteru v Azure pomocí šablony Správce prostředků
• Vytvoření clusteru pomocí webu Azure Portal