Service Fabric för klustersäkerhet

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 går att skapa ett oskyddat 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:

• Nod-till-nod-säkerhet
• Säkerhet från klient till nod
• Service Fabric rollbaserad åtkomstkontroll

Nod-till-nod-säkerhet

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 delta i att vara värd för program och tjänster i klustret.

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

Certifikatsäkerhet från nod till nod

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 Portal, 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 fram till det framtida utgångsdatumet. Det här primära certifikatet ska vara ett annat än administratörsklienten och skrivskyddade klientcertifikat som du anger för klient-till-nod-säkerhet. Sdk:ns klassiska beteende tillät definition av primära och sekundära certifikat för att tillåta manuellt initierade övertaganden. Det rekommenderas inte för användning över de nya funktionerna.

Information om hur du ställer in 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 ställer in certifikatsäkerhet i ett kluster för ett fristående Windows Server-kluster finns i Skydda ett fristående kluster på Windows med X.509-certifikat.

Nod-till-nod Windows säkerhet

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

Säkerhet från klient till nod

Klient-till-nod-säkerhet 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 via antingen sina Windows säkerhetsautentiseringsuppgifter eller sina autentiseringsuppgifter för certifikatsäkerhet.

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

Certifikatsäkerhet från klient till nod

Konfigurera certifikatsäkerhet från klient till nod när du skapar klustret, antingen i Azure Portal, 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 vara annorlunda ä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 en säkerhetsmetod.

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 den Service Fabric RBAC som beskrivs senare i den här artikeln.

Information om hur du ställer in 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 ställer in certifikatsäkerhet i ett kluster för ett fristående Windows Server-kluster finns i Skydda ett fristående kluster på Windows med X.509-certifikat.

Säkerhet från klient till nod Azure Active Directory azure

Azure Active Directory (Azure AD) gör det möjligt för organisationer (så kallade klientorganisationer) att hantera användaråtkomst till program. Programmen är indelade i de med ett webbaserat inloggningsgränssnitt och program med en inbyggd klientupplevelse. Om du inte redan har skapat en klientorganisation börjar du med att läsa Hämta en Azure Active Directory klientorganisation.

För kluster som körs i Azure kan du också använda Azure AD 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å Azure AD-program: en webbapp och ett inbyggt program. Information om hur du skapar nödvändiga Azure AD-artefakter och hur du fyller i dem när du skapar klustret finns i Konfigurera Azure AD 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änd Azure Active Directory 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 rekommenderar vi att du använder ett klustercertifikat för att autentisera noder för nod-till-nod-säkerhet.

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

Service Fabric rollbaserad åtkomstkontroll

Du kan använda åtkomstkontroll för att begränsa åtkomsten till vissa klusteråtgärder för olika grupper av användare. Detta hjälper till att göra 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 bara 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 tillhandahålla separata identiteter (till exempel genom att använda certifikat eller Azure AD) för varje rolltyp. Mer information om standardinställningar för åtkomstkontroll och hur du ändrar standardinställningar finns i Service Fabric rollbaserad åtkomstkontroll 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 signera meddelanden digitalt. 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 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 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älv signerat certifikat, men bara i ett testkluster. Använd inte ett själv signerat certifikat i produktion.
• När du genererar tumavtrycket för certifikatet måste du generera ett SHA1-tumavtryck. SHA1 är det som används när du konfigurerar tumavtryck 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 slutpunkterna för klusterhantering 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 också en TLS för HTTPS-hanterings-API:et och för Service Fabric Explorer över 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 det här gemensamma namnet eller något av certifikatens alternativa namn för certifikat (SAN) måste 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 filnamnstilläggen .pfx eller .pem
• Certifikatet måste skapas för nyckelutbyte, som kan exporteras till en personalinformationsfil Exchange .pfx).
• Certifikatets ämnesnamn måste matcha den domän som du använder för att få åtkomst Service Fabric klustret. 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 *.cloudapp.azure.com domänen. 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 föregås av 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 namn för certifikatutfärdare fylls i måste det ha både certifikatets eget 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 Avsett syfte för certifikatet ska innehålla ett lämpligt värde, till exempel Serverautentisering eller Klientautentisering.

Programcertifikat (valfritt)

Val av ytterligare certifikat kan installeras i ett kluster i programsäkerhetssyfte. Innan du skapar klustret bör du tänka på 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 replikeringen.

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

Certifikat för klientautentisering (valfritt)

Val annat antal certifikat kan anges för administratörs- eller användarklientåtgärder. Klienten kan använda dessa certifikat när ömsesidig autentisering krävs. Klientcertifikat utfärdas vanligtvis inte av en tredjeparts certifikatutfärdare. 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 Avsett syfte 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.

Nästa steg

• Skapa ett kluster i Azure med hjälp av en Resource Manager mall
• Skapa ett kluster med Azure Portal