Säkerhetsscenarier för Service Fabric-kluster

Artikel
10/15/2024

Ett Azure Service Fabric-kluster är en resurs som du äger. Det är ditt ansvar att skydda dina kluster för att förhindra att obehöriga användare ansluter till dem. Ett säkert kluster är särskilt viktigt när du kör produktionsarbetsbelastningar i klustret. Det är möjligt att skapa ett osäkert kluster, men om klustret exponerar hanteringsslutpunkter för det offentliga Internet kan anonyma användare ansluta till det. Oskyddade kluster stöds inte för produktionsarbetsbelastningar.

Den här artikeln är en översikt över säkerhetsscenarier för Azure-kluster och fristående kluster och de olika tekniker som du kan använda för att implementera dem:

Säkerhet från nod till nod
Säkerhet från klient till nod
Rollbaserad åtkomstkontroll för Service Fabric

Säkerhet från nod till nod

Nod-till-nod-säkerhet hjälper till att skydda kommunikationen mellan de virtuella datorerna eller datorerna i ett kluster. Det här säkerhetsscenariot säkerställer att endast datorer som har behörighet att ansluta till klustret kan vara värdar för program och tjänster i klustret.

Diagram över kommunikation från nod till nod

Kluster som körs i Azure och fristående kluster som körs i Windows kan båda använda antingen certifikatsäkerhet eller Windows-säkerhet för Windows Server-datorer.

Säkerhet för nod-till-nod-certifikat

Service Fabric använder X.509-servercertifikat som du anger som en del av konfigurationen av nodtyp när du skapar ett kluster. Du kan konfigurera certifikatsäkerhet antingen i Azure-portalen, med hjälp av en Azure Resource Manager-mall eller med hjälp av en fristående JSON-mall. I slutet av den här artikeln kan du se en kort översikt över vad dessa certifikat är och hur du kan hämta eller skapa dem.

Service Fabric SDK:s standardbeteende är att distribuera och installera certifikatet längst in i det framtida utgångsdatumet. Det här primära certifikatet bör skilja sig från administratörsklienten och skrivskyddade klientcertifikat som du har angett för säkerhet från klient till nod. SDK:ns klassiska beteende gjorde det möjligt att definiera primära och sekundära certifikat för att tillåta manuellt initierade rollovers. det rekommenderas inte för användning över de nya funktionerna.

Information om hur du konfigurerar certifikatsäkerhet i ett kluster för Azure finns i Konfigurera ett kluster med hjälp av en Azure Resource Manager-mall.

Information om hur du konfigurerar certifikatsäkerhet i ett kluster för ett fristående Windows Server-kluster finns i Skydda ett fristående kluster i Windows med hjälp av X.509-certifikat.

Windows-säkerhet från nod till nod

Kommentar

Windows-autentisering baseras på Kerberos. NTLM stöds inte som en autentiseringstyp.

När det är möjligt använder du X.509-certifikatautentisering för Service Fabric-kluster.

Information om hur du konfigurerar Windows-säkerhet för ett fristående Windows Server-kluster finns i Skydda ett fristående kluster i Windows med hjälp av Windows-säkerhet.

Säkerhet från klient till nod

Säkerhet från klient till nod autentiserar klienter och hjälper till att skydda kommunikationen mellan en klient och enskilda noder i klustret. Den här typen av säkerhet säkerställer att endast behöriga användare kan komma åt klustret och de program som distribueras i klustret. Klienter identifieras unikt genom antingen sina Windows-säkerhetsautentiseringsuppgifter eller sina autentiseringsuppgifter för certifikatsäkerhet.

Diagram över kommunikation från klient till nod

Kluster som körs i Azure och fristående kluster som körs i Windows kan använda antingen certifikatsäkerhet eller Windows-säkerhet, men rekommendationen är att använda X.509-certifikatautentisering när det är möjligt.

Säkerhet för klient-till-nod-certifikat

Konfigurera certifikatsäkerhet från klient till nod när du skapar klustret, antingen i Azure-portalen, med hjälp av en Resource Manager-mall eller med hjälp av en fristående JSON-mall. Om du vill skapa certifikatet anger du ett administratörsklientcertifikat eller ett användarklientcertifikat. Som bästa praxis bör de administratörsklient- och användarklientcertifikat som du anger skilja sig från de primära och sekundära certifikat som du anger för nod-till-nod-säkerhet. Klustercertifikat har samma rättigheter som klientadministratörscertifikat. De bör dock endast användas av kluster och inte av administrativa användare som bästa praxis för säkerhet.

Klienter som ansluter till klustret med hjälp av administratörscertifikatet har fullständig åtkomst till hanteringsfunktioner. Klienter som ansluter till klustret med hjälp av det skrivskyddade användarklientcertifikatet har endast läsbehörighet till hanteringsfunktioner. Dessa certifikat används för Service Fabric RBAC som beskrivs senare i den här artikeln.

Information om hur du konfigurerar certifikatsäkerhet i ett kluster för Azure finns i Konfigurera ett kluster med hjälp av en Azure Resource Manager-mall.

Information om hur du konfigurerar certifikatsäkerhet i ett kluster för ett fristående Windows Server-kluster finns i Skydda ett fristående kluster i Windows med hjälp av X.509-certifikat.

Microsoft Entra-säkerhet från klient till nod i Azure

Med Microsoft Entra-ID kan organisationer (så kallade klientorganisationer) hantera användaråtkomst till program. Program är indelade i de som har ett webbaserat inloggningsgränssnitt och de som har en intern klientupplevelse. Om du inte redan har skapat en klientorganisation börjar du med att läsa Hämta en Microsoft Entra-klientorganisation.

För kluster som körs i Azure kan du också använda Microsoft Entra-ID för att skydda åtkomsten till hanteringsslutpunkter. Service Fabric-kluster erbjuder flera startpunkter för dess hanteringsfunktioner, däribland den webbaserade Service Fabric Explorer och Visual Studio. För att styra åtkomsten till klustret skapar du därför två Microsoft Entra-program: ett webbprogram och ett internt program. Information om hur du skapar nödvändiga Microsoft Entra-artefakter och hur du fyller i dem när du skapar klustret finns i Konfigurera Microsoft Entra-ID för att autentisera klienter.

Säkerhetsrekommendationer

För Service Fabric-kluster som distribueras i ett offentligt nätverk som hanteras i Azure är rekommendationen för ömsesidig klient-till-nod-autentisering:

Använda Microsoft Entra-ID för klientidentitet
Ett certifikat för serveridentitet och TLS-kryptering för http-kommunikation

För Service Fabric-kluster som distribueras i ett offentligt nätverk som finns i Azure är rekommendationen för säkerhet från nod till nod att använda ett klustercertifikat för att autentisera noder.

För fristående Windows Server-kluster rekommenderar vi att du använder Windows-säkerhet med grupphanterade tjänstkonton om du har Windows Server 2012 R2 och Windows Active Directory. Annars använder du Windows-säkerhet med Windows-konton.

Rollbaserad åtkomstkontroll för Service Fabric

Du kan använda åtkomstkontroll för att begränsa åtkomsten till vissa klusteråtgärder för olika användargrupper. Detta gör klustret säkrare. Två typer av åtkomstkontroll stöds för klienter som ansluter till ett kluster: Administratörsroll och Användarroll.

Användare som har tilldelats rollen Administratör har fullständig åtkomst till hanteringsfunktioner, inklusive läs- och skrivfunktioner. Användare som har tilldelats användarrollen har som standard endast läsbehörighet till hanteringsfunktioner (till exempel frågefunktioner). De kan också lösa program och tjänster.

Ange klientrollerna Administratör och Användare när du skapar klustret. Tilldela roller genom att ange separata identiteter (till exempel med hjälp av certifikat eller Microsoft Entra-ID) för varje rolltyp. Mer information om standardinställningar för åtkomstkontroll och hur du ändrar standardinställningar finns i Rollbaserad åtkomstkontroll i Service Fabric för Service Fabric-klienter.

X.509-certifikat och Service Fabric

Digitala X.509-certifikat används ofta för att autentisera klienter och servrar. De används också för att kryptera och digitalt signera meddelanden. Service Fabric använder X.509-certifikat för att skydda ett kluster och tillhandahålla programsäkerhetsfunktioner. Mer information om digitala X.509-certifikat finns i Arbeta med certifikat. Du använder Key Vault för att hantera certifikat för Service Fabric-kluster i Azure.

Några viktiga saker att tänka på:

Om du vill skapa certifikat för kluster som kör produktionsarbetsbelastningar använder du en korrekt konfigurerad Windows Server-certifikattjänst eller en från en godkänd certifikatutfärdare (CA).
Använd aldrig några tillfälliga certifikat eller testcertifikat som du skapar med hjälp av verktyg som MakeCert.exe i en produktionsmiljö.
Du kan använda ett självsignerat certifikat, men bara i ett testkluster. Använd inte ett självsignerat certifikat i produktion.
När du genererar certifikatets tumavtryck måste du generera ett SHA1-tumavtryck. SHA1 används när du konfigurerar tumavtrycken för klient- och klustercertifikat.

Kluster- och servercertifikat (krävs)

Dessa certifikat (en primär och eventuellt en sekundär) krävs för att skydda ett kluster och förhindra obehörig åtkomst till det. Dessa certifikat tillhandahåller kluster- och serverautentisering.

Klusterautentisering autentiserar nod-till-nod-kommunikation för klusterfederation. Endast noder som kan bevisa sin identitet med det här certifikatet kan ansluta till klustret. Serverautentisering autentiserar klusterhanteringsslutpunkterna till en hanteringsklient, så att hanteringsklienten vet att den pratar med det verkliga klustret och inte en "man i mitten". Det här certifikatet tillhandahåller även en TLS för HTTPS-hanterings-API:et och för Service Fabric Explorer via HTTPS. När en klient eller nod autentiserar en nod är en av de första kontrollerna värdet för det gemensamma namnet i fältet Ämne . Antingen måste det här vanliga namnet eller något av certifikatens alternativa namn (SAN) finnas i listan över tillåtna gemensamma namn.

Certifikatet måste uppfylla följande krav:

Certifikatet måste innehålla en privat nyckel. Dessa certifikat har vanligtvis tilläggen .pfx eller .pem
Certifikatet måste skapas för nyckelutbyte, som kan exporteras till en Fil för personligt informationsutbyte (.pfx).
Certifikatets ämnesnamn måste matcha den domän som du använder för att få åtkomst till Service Fabric-klustret. Den här matchningen krävs för att tillhandahålla en TLS för klustrets HTTPS-hanteringsslutpunkt och Service Fabric Explorer. Du kan inte hämta ett TLS/SSL-certifikat från en certifikatutfärdare (CA) för domänen *.cloudapp.azure.com. Du måste skaffa ett anpassat domännamn för ditt kluster. När du begär ett certifikat från en certifikatutfärdare måste certifikatets ämnesnamn matcha det anpassade domännamn du använder för klustret.

Några andra saker att tänka på:

Fältet Ämne kan ha flera värden. Varje värde prefixeras med en initiering för att ange värdetypen. Vanligtvis är initieringen CN (för eget namn); till exempel CN = www.contoso.com.
Fältet Ämne kan vara tomt.
Om det valfria fältet Alternativt ämnesnamn har fyllts i måste det ha både certifikatets gemensamma namn och en post per SAN. Dessa anges som DNS-namnvärden . Information om hur du genererar certifikat som har SAN finns i Så här lägger du till ett alternativt ämnesnamn till ett säkert LDAP-certifikat.
Värdet för fältet Avsedda syften i certifikatet bör innehålla ett lämpligt värde, till exempel serverautentisering eller klientautentisering.

Programcertifikat (valfritt)

Valfritt antal ytterligare certifikat kan installeras i ett kluster i programsäkerhetssyfte. Innan du skapar klustret bör du överväga de programsäkerhetsscenarier som kräver att ett certifikat installeras på noderna, till exempel:

Kryptering och dekryptering av programkonfigurationsvärden.
Kryptering av data mellan noder under replikering.

Begreppet att skapa säkra kluster är detsamma, oavsett om de är Linux- eller Windows-kluster.

Certifikat för klientautentisering (valfritt)

Valfritt antal ytterligare certifikat kan anges för administrations- eller användarklientåtgärder. Klienten kan använda dessa certifikat när ömsesidig autentisering krävs. Klientcertifikat utfärdas vanligtvis inte av en certifikatutfärdare från tredje part. I stället innehåller det personliga arkivet för den aktuella användarplatsen vanligtvis klientcertifikat som placeras där av en rotutfärdare. Certifikatet ska ha värdet Avsedda syften för klientautentisering.

Som standard har klustercertifikatet administratörsklientbehörighet. Dessa ytterligare klientcertifikat bör inte installeras i klustret, men anges som tillåtna i klusterkonfigurationen. Klientcertifikaten måste dock installeras på klientdatorerna för att ansluta till klustret och utföra åtgärder.