Beveiligingsscenario's voor Service Fabric-clusters

Artikel
10/15/2024

Een Azure Service Fabric-cluster is een resource die u bezit. Het is uw verantwoordelijkheid om uw clusters te beveiligen om te voorkomen dat onbevoegde gebruikers verbinding met hen maken. Een beveiligd cluster is vooral belangrijk wanneer u productieworkloads uitvoert op het cluster. Het is mogelijk om een niet-beveiligd cluster te maken, maar als het cluster beheereindpunten beschikbaar maakt voor het openbare internet, kunnen anonieme gebruikers er verbinding mee maken. Niet-beveiligde clusters worden niet ondersteund voor productieworkloads.

Dit artikel is een overzicht van beveiligingsscenario's voor Azure-clusters en zelfstandige clusters, en de verschillende technologieën die u kunt gebruiken om ze te implementeren:

Beveiliging van knooppunt naar knooppunt
Beveiliging van client-naar-knooppunt
Op rollen gebaseerd toegangsbeheer van Service Fabric

Beveiliging van knooppunt naar knooppunt

Met knooppunt-naar-knooppuntbeveiliging kunt u de communicatie tussen de VM's of computers in een cluster beveiligen. Dit beveiligingsscenario zorgt ervoor dat alleen computers die zijn gemachtigd om deel te nemen aan het cluster, kunnen deelnemen aan het hosten van toepassingen en services in het cluster.

Diagram van communicatie tussen knooppunten

Clusters die worden uitgevoerd in Azure en zelfstandige clusters die worden uitgevoerd in Windows, kunnen beide gebruikmaken van certificaatbeveiliging of Windows-beveiliging voor Windows Server-computers.

Beveiliging van knooppunt-naar-knooppuntcertificaat

Service Fabric maakt gebruik van X.509-servercertificaten die u opgeeft als onderdeel van de configuratie van het knooppunttype wanneer u een cluster maakt. U kunt certificaatbeveiliging instellen in Azure Portal, met behulp van een Azure Resource Manager-sjabloon of met behulp van een zelfstandige JSON-sjabloon. Aan het einde van dit artikel ziet u een kort overzicht van wat deze certificaten zijn en hoe u deze kunt verkrijgen of maken.

Het standaardgedrag van de Service Fabric SDK is het implementeren en installeren van het certificaat met de meest recente vervaldatum. Dit primaire certificaat moet afwijken van de beheerclient en alleen-lezen clientcertificaten die u hebt ingesteld voor beveiliging van client-naar-knooppunten. Het klassieke gedrag van de SDK heeft het definiëren van primaire en secundaire certificaten toegestaan om handmatig geïnitieerde rollovers toe te staan; het wordt niet aanbevolen voor gebruik via de nieuwe functionaliteit.

Zie Een cluster instellen met behulp van een Azure Resource Manager-sjabloon voor meer informatie over het instellen van certificaatbeveiliging in een cluster voor Azure.

Zie Een zelfstandig cluster in Windows beveiligen met behulp van X.509-certificaten voor meer informatie over het instellen van certificaatbeveiliging in een cluster voor een zelfstandig Windows Server-cluster.

Windows-beveiliging tussen knooppunten

Notitie

Windows-verificatie is gebaseerd op Kerberos. NTLM wordt niet ondersteund als verificatietype.

Gebruik waar mogelijk X.509-certificaatverificatie voor Service Fabric-clusters.

Zie Een zelfstandig cluster beveiligen in Windows met behulp van Windows-beveiliging voor informatie over het instellen van Windows-beveiliging voor een zelfstandig Windows Server-cluster.

Beveiliging van client-naar-knooppunt

Client-naar-knooppuntbeveiliging verifieert clients en helpt bij het beveiligen van de communicatie tussen een client en afzonderlijke knooppunten in het cluster. Dit type beveiliging zorgt ervoor dat alleen geautoriseerde gebruikers toegang hebben tot het cluster en de toepassingen die in het cluster zijn geïmplementeerd. Clients worden uniek geïdentificeerd via hun Windows-beveiligingsreferenties of hun certificaatbeveiligingsreferenties.

Diagram van communicatie tussen clients en knooppunten

Clusters die worden uitgevoerd in Azure en zelfstandige clusters die worden uitgevoerd in Windows, kunnen beide certificaatbeveiliging of Windows-beveiliging gebruiken, maar het wordt aangeraden X.509-certificaatverificatie te gebruiken wanneer dat mogelijk is.

Beveiliging van client-naar-knooppuntcertificaten

Stel client-naar-knooppuntcertificaatbeveiliging in wanneer u het cluster maakt, hetzij in Azure Portal, met behulp van een Resource Manager-sjabloon of met behulp van een zelfstandige JSON-sjabloon. Als u het certificaat wilt maken, geeft u een beheerdersclientcertificaat of een gebruikersclientcertificaat op. Als best practice moeten de door u opgegeven beheerdersclient- en gebruikersclientcertificaten afwijken van de primaire en secundaire certificaten die u opgeeft voor beveiliging van knooppunten naar knooppunt. Clustercertificaten hebben dezelfde rechten als clientbeheerderscertificaten. Ze moeten echter alleen worden gebruikt door clusters en niet door gebruikers met beheerdersrechten als aanbevolen beveiligingspraktijk.

Clients die verbinding maken met het cluster met behulp van het beheercertificaat, hebben volledige toegang tot beheermogelijkheden. Clients die verbinding maken met het cluster met behulp van het alleen-lezen clientcertificaat van de gebruiker hebben alleen leestoegang tot beheermogelijkheden. Deze certificaten worden gebruikt voor de Service Fabric RBAC die verderop in dit artikel wordt beschreven.

Zie Een cluster instellen met behulp van een Azure Resource Manager-sjabloon voor meer informatie over het instellen van certificaatbeveiliging in een cluster voor Azure.

Beveiliging van Microsoft Entra op client-naar-knooppunt in Azure

Met Microsoft Entra ID kunnen organisaties (ook wel tenants genoemd) gebruikerstoegang tot toepassingen beheren. Toepassingen zijn onderverdeeld in toepassingen met een webgebaseerde aanmeldingsinterface en toepassingen met een systeemeigen clientervaring. Als u nog geen tenant hebt gemaakt, leest u eerst hoe u een Microsoft Entra-tenant krijgt.

Voor clusters die worden uitgevoerd in Azure, kunt u ook Microsoft Entra ID gebruiken om de toegang tot beheereindpunten te beveiligen. Een Service Fabric-cluster biedt verschillende toegangspunten bij de management-functionaliteit, met inbegrip van de webconsoles Service Fabric Explorer en Visual Studio. Als u de toegang tot het cluster wilt beheren, maakt u twee Microsoft Entra-toepassingen: één webtoepassing en één systeemeigen toepassing. Zie Microsoft Entra-id instellen om clients te verifiëren voor meer informatie over het maken van de vereiste Microsoft Entra-artefacten en hoe u deze vult wanneer u het cluster maakt.

Aanbevelingen voor beveiliging

Voor Service Fabric-clusters die zijn geïmplementeerd in een openbaar netwerk dat wordt gehost op Azure, is de aanbeveling voor wederzijdse verificatie van client-naar-knooppunt:

Microsoft Entra-id gebruiken voor clientidentiteit
Een certificaat voor serveridentiteit en TLS-versleuteling van HTTP-communicatie

Voor Service Fabric-clusters die zijn geïmplementeerd in een openbaar netwerk dat wordt gehost in Azure, is het raadzaam om een clustercertificaat te gebruiken om knooppunten te verifiëren.

Voor zelfstandige Windows Server-clusters, als u Windows Server 2012 R2 en Windows Active Directory hebt, raden we u aan Windows-beveiliging te gebruiken met beheerde serviceaccounts voor groepen. Gebruik anders Windows-beveiliging met Windows-accounts.

Op rollen gebaseerd toegangsbeheer van Service Fabric

U kunt toegangsbeheer gebruiken om de toegang tot bepaalde clusterbewerkingen voor verschillende groepen gebruikers te beperken. Dit helpt het cluster veiliger te maken. Er worden twee typen toegangsbeheer ondersteund voor clients die verbinding maken met een cluster: beheerdersrol en gebruikersrol.

Gebruikers aan wie de beheerdersrol is toegewezen, hebben volledige toegang tot beheermogelijkheden, waaronder lees- en schrijfmogelijkheden. Gebruikers aan wie standaard de gebruikersrol is toegewezen, hebben alleen leestoegang tot beheermogelijkheden (bijvoorbeeld querymogelijkheden). Ze kunnen ook toepassingen en services oplossen.

Stel de beheerders- en gebruikersclientrollen in wanneer u het cluster maakt. Wijs rollen toe door afzonderlijke identiteiten op te geven (bijvoorbeeld met behulp van certificaten of Microsoft Entra-id) voor elk roltype. Zie Op rollen gebaseerd toegangsbeheer voor Service Fabric-clients voor meer informatie over standaardinstellingen voor toegangsbeheer en het wijzigen van standaardinstellingen.

X.509-certificaten en Service Fabric

Digitale X.509-certificaten worden vaak gebruikt om clients en servers te verifiëren. Ze worden ook gebruikt om berichten te versleutelen en digitaal te ondertekenen. Service Fabric maakt gebruik van X.509-certificaten om een cluster te beveiligen en toepassingsbeveiligingsfuncties te bieden. Zie Werken met certificaten voor meer informatie over digitale X.509-certificaten. U gebruikt Key Vault voor het beheren van certificaten voor Service Fabric-clusters in Azure.

Enkele belangrijke zaken die u moet overwegen:

Als u certificaten wilt maken voor clusters waarop productieworkloads worden uitgevoerd, gebruikt u een correct geconfigureerde Windows Server-certificaatservice of een certificaatservice van een goedgekeurde certificeringsinstantie (CA).
Gebruik nooit tijdelijke certificaten of testcertificaten die u maakt met behulp van hulpprogramma's zoals MakeCert.exe in een productieomgeving.
U kunt een zelfondertekend certificaat gebruiken, maar alleen in een testcluster. Gebruik geen zelfondertekend certificaat in productie.
Wanneer u de vingerafdruk van het certificaat genereert, moet u een SHA1-vingerafdruk genereren. SHA1 wordt gebruikt bij het configureren van de vingerafdruk van het client- en clustercertificaat.

Cluster- en servercertificaat (vereist)

Deze certificaten (één primaire en optioneel secundaire) zijn vereist om een cluster te beveiligen en onbevoegde toegang tot het cluster te voorkomen. Deze certificaten bieden cluster- en serververificatie.

Clusterverificatie verifieert communicatie tussen knooppunten voor clusterfederatie. Alleen knooppunten die hun identiteit met dit certificaat kunnen bewijzen, kunnen lid worden van het cluster. Serververificatie verifieert de eindpunten voor clusterbeheer voor een beheerclient, zodat de beheerclient weet dat het met het echte cluster praat en niet met een 'man in het midden'. Dit certificaat biedt ook een TLS voor de HTTPS-beheer-API en voor Service Fabric Explorer via HTTPS. Wanneer een client of knooppunt een knooppunt verifieert, is een van de eerste controles de waarde van de algemene naam in het veld Onderwerp . Deze algemene naam of een van de alternatieve namen van de certificaten moet aanwezig zijn in de lijst met toegestane algemene namen.

Het certificaat moet voldoen aan de volgende vereisten:

Het certificaat moet een persoonlijke sleutel bevatten. Deze certificaten hebben doorgaans extensies .pfx of .pem
Het certificaat moet worden gemaakt voor sleuteluitwisseling, dat kan worden geëxporteerd naar een PFX-bestand (Personal Information Exchange).
De onderwerpnaam van het certificaat moet overeenkomen met het domein dat u gebruikt voor toegang tot het Service Fabric-cluster. Deze overeenkomst is vereist om een TLS te bieden voor het HTTPS-beheereindpunt van het cluster en Service Fabric Explorer. U kunt geen TLS/SSL-certificaat verkrijgen van een certificeringsinstantie (CA) voor het domein *.cloudapp.azure.com. U hebt voor uw cluster een aangepaste domeinnaam nodig. Wanneer u een certificaat van een CA aanvraagt, moet de onderwerpnaam van het certificaat overeenkomen met de aangepaste domeinnaam die u voor uw cluster gebruikt.

Enkele andere zaken die u moet overwegen:

Het veld Onderwerp kan meerdere waarden hebben. Elke waarde wordt voorafgegaan door een initialisatie om het waardetype aan te geven. Meestal is de initialisatie CN (voor algemene naam); bijvoorbeeld CN = www.contoso.com.
Het veld Onderwerp kan leeg zijn.
Als het optionele veld Alternatieve onderwerpnaam is ingevuld, moet het zowel de algemene naam van het certificaat als één vermelding per SAN hebben. Deze worden ingevoerd als DNS-naamwaarden . Zie Een alternatieve onderwerpnaam toevoegen aan een secure LDAP-certificaat voor meer informatie over het genereren van certificaten met SAN's.
De waarde van het veld Beoogde doeleinden van het certificaat moet een geschikte waarde bevatten, zoals serververificatie of clientverificatie.

Toepassingscertificaten (optioneel)

Een willekeurig aantal extra certificaten kan worden geïnstalleerd op een cluster voor toepassingsbeveiligingsdoeleinden. Voordat u uw cluster maakt, moet u rekening houden met de toepassingsbeveiligingsscenario's waarvoor een certificaat moet worden geïnstalleerd op de knooppunten, zoals:

Versleuteling en ontsleuteling van toepassingsconfiguratiewaarden.
Versleuteling van gegevens tussen knooppunten tijdens replicatie.

Het concept van het maken van beveiligde clusters is hetzelfde, ongeacht of het Linux- of Windows-clusters zijn.

Clientverificatiecertificaten (optioneel)

Er kan een willekeurig aantal extra certificaten worden opgegeven voor beheer- of gebruikersclientbewerkingen. De client kan deze certificaten gebruiken wanneer wederzijdse verificatie vereist is. Clientcertificaten worden doorgaans niet uitgegeven door een externe CERTIFICERINGsinstantie. In plaats daarvan bevat het persoonlijke archief van de huidige gebruikerslocatie doorgaans clientcertificaten die daar zijn geplaatst door een basisinstantie. Het certificaat moet de waarde Beoogde doeleinden van clientverificatie hebben.

Standaard heeft het clustercertificaat beheerdersclientbevoegdheden. Deze aanvullende clientcertificaten mogen niet in het cluster worden geïnstalleerd, maar worden opgegeven als toegestaan in de clusterconfiguratie. De clientcertificaten moeten echter op de clientcomputers worden geïnstalleerd om verbinding te maken met het cluster en alle bewerkingen uit te voeren.