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

Cluster Azure Service Fabric je prostředek, který vlastníte. Vaším úkolem je zabezpečit clustery, abyste zabránili neoprávněným uživatelům v jejich připojování. Zabezpečený cluster je obzvláště 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 na veřejném internetu, můžou se k němu připojit anonymní uživatelé. Nezabezpečené clustery nejsou podporovány pro produkční úlohy.

Tento článek je 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í uzlů na uzel 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 účastnit jenom počítače, které mají oprávnění k připojení ke clusteru.

Diagram komunikace mezi uzly

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

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 buď v Azure Portal, pomocí šablony Azure Resource Manager, 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 správce a klientských certifikátů jen pro čtení, které jste nastavili pro zabezpečení klienta na uzel. 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é rollovery; 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 Manager.

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í Systému 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 pro clustery Service Fabric ověřování certifikátů X.509.

Informace o nastavení zabezpečení Systému 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 autorizovaní 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átu , nebo zabezpečení Windows, ale doporučení je použít ověřování certifikátů X.509, kdykoli je to možné.

Zabezpečení certifikátu mezi klienty a uzlem

Při vytváření clusteru nastavte zabezpečení certifikátu typu klient-uzel, a to buď v Azure Portal, pomocí šablony Resource Manager, nebo pomocí samostatné šablony JSON. Pokud chcete certifikát vytvořit, zadejte klientský certifikát správce nebo klientský certifikát uživatele. Osvědčeným postupem je, že klientský certifikát správce a uživatelských klientských certifikátů, které zadáte, by se měly lišit od primárních a sekundárních certifikátů určených pro zabezpečení uzlů na uzel. Certifikáty clusteru mají stejná práva jako certifikáty správce klienta. Jako osvědčený postup zabezpečení by je ale měly používat jenom clustery, nikoli 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 jen pro čtení, mají přístup jen pro čtení k možnostem správy. 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 Manager.

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í Azure Active Directory mezi klienty v Azure

Azure Active Directory (Azure AD) umožňuje organizacím (označované jako tenanty) spravovat přístup uživatelů k aplikacím. Aplikace jsou rozdělené na aplikace 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 Azure Active Directory.

Pro clustery spuštěné v Azure můžete také použít Azure AD k zabezpečení přístupu 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 Explorer a sady Visual Studio. V důsledku toho můžete řídit přístup ke clusteru, který vytvoříte dvě Azure AD aplikace: 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ěření 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 a uzly:

  • Použití Azure Active Directory 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 zabezpečení uzlů na uzlech použít certifikát clusteru k ověření uzlů.

V případě samostatných clusterů 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í Systému Windows s účty Windows.

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

Pomocí řízení přístupu můžete omezit přístup k určitým operacím clusteru pro různé skupiny uživatelů. Díky tomu je cluster bezpečnější. 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živatele, mají přístup jen pro čtení k možnostem správy (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 tím, že pro každý typ role zadáte samostatné identity (například pomocí certifikátů nebo Azure AD). 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ů. Používají se také k šifrování a digitálním 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 najdete v tématu Práce s certifikáty. Ke správě certifikátů pro clustery Service Fabric v Azure používáte Key Vault.

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

  • Pokud chcete vytvořit certifikáty pro clustery s produkčními úlohami, 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í) se vyžadují 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 pouze uzly, které můžou prokázat svou 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 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 uveden 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 obsahují rozšíření .pfx nebo .pem.
  • Certifikát musí být vytvořen pro výměnu klíčů, který je exportovatelný do souboru Exchange osobních informací (.pfx).
  • Název subjektu certifikátu musí odpovídat doméně, 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 Explorer. Certifikát TLS/SSL nelze získat z 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, která označuje 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. Jsou zadány 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 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é)

Libovolný počet dalších certifikátů je možné nainstalovat do clusteru 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ý, ať už jde o clustery s Linuxem nebo Windows.

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

Libovolný počet dalších certifikátů je možné zadat pro operace správce nebo klienta uživatele. 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é účelyověř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 neměly instalovat do clusteru, 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.

Poznámka

Všechny operace správy v clusteru Service Fabric vyžadují certifikáty serveru. Klientské certifikáty nelze použít ke správě.

Další kroky