Service Fabric clusterbeveiligingsscenario's

Artikel
07/02/2021
9 minuten om te lezen

Een Azure Service Fabric 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 op het cluster gebruikt. Het is mogelijk om een niet-beveiligde cluster te maken, maar als het cluster beheer eindpunten voor het openbare internet blootstelt, kunnen anonieme gebruikers er verbinding mee maken. Niet-beveiligde clusters worden niet ondersteund voor productieworkloads.

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

Beveiliging van knooppunt naar knooppunt
Beveiliging van client naar knooppunt
Service Fabric op rollen gebaseerd toegangsbeheer

Beveiliging van knooppunt naar knooppunt

Beveiliging van knooppunt-naar-knooppunt helpt de communicatie tussen de VM's of computers in een cluster te beveiligen. Dit beveiligingsscenario zorgt ervoor dat alleen computers die zijn gemachtigd om lid te worden van het cluster, kunnen deelnemen aan het hosten van toepassingen en services in het cluster.

Diagram van knooppunt-naar-knooppuntcommunicatie

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

Beveiliging van knooppunt-naar-knooppuntcertificaat

Service Fabric gebruikt X.509-servercertificaten die u opgeeft als onderdeel van de configuratie van het knooppunttype wanneer u een cluster maakt. U kunt certificaatbeveiliging instellen in de 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 ze kunt verkrijgen of maken.

Service Fabric Het standaardgedrag van de SDK is het implementeren en installeren van het certificaat met het meest in de toekomst verlopen. Dit primaire certificaat moet verschillen van de client met beheerdersrechten en alleen-lezen clientcertificaten die u hebt ingesteld voor beveiliging van client naar knooppunt. Met het klassieke gedrag van de SDK kon het definiëren van primaire en secundaire certificaten handmatig geïnitieerde rollovers toestaan; het wordt niet aanbevolen voor gebruik via de nieuwe functionaliteit.

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

Zie Secure a standalone cluster on Windows by using X.509 certificates (Een zelfstandig cluster op 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.

Beveiliging van knooppunt-Windows knooppunt

Notitie

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

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

Zie Secure a standalone cluster on Windows by using Windows security (Een zelfstandig cluster op Windows beveiligen met behulp van Windows-beveiliging) voor meer 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 de communicatie tussen een client en afzonderlijke knooppunten in het cluster te beveiligen. Dit type beveiliging zorgt ervoor dat alleen geautoriseerde gebruikers toegang hebben tot het cluster en de toepassingen die op het cluster zijn geïmplementeerd. Clients worden uniek geïdentificeerd via hun Windows of hun certificaatbeveiligingsreferenties.

Diagram van communicatie tussen client en knooppunt

Clusters die worden uitgevoerd op Azure en zelfstandige clusters die worden uitgevoerd op Windows kunnen gebruikmaken van certificaatbeveiliging of Windows-beveiliging,maar het wordt aanbevolen om waar mogelijk X.509-certificaatverificatie te gebruiken.

Beveiliging van client-naar-knooppunt-certificaat

Stel beveiliging van het client-naar-knooppunt-certificaat in wanneer u het cluster maakt, in de 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 clientcertificaat voor beheerders of een gebruikersclientcertificaat op. Als best practice moeten de beheerdersclient- en gebruikersclientcertificaten die u opgeeft, verschillen van de primaire en secundaire certificaten die u opgeeft voor beveiliging van knooppunt-naar-knooppunt. Clustercertificaten hebben dezelfde rechten als clientbeheerderscertificaten. Ze mogen echter alleen worden gebruikt door het cluster en niet door gebruikers met beheerders beheerders best practice.

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 gebruikersclientcertificaat hebben alleen leestoegang tot beheermogelijkheden. Deze certificaten worden gebruikt voor de Service Fabric RBAC die later in dit artikel wordt beschreven.

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

Beveiliging van client naar Azure Active Directory knooppunt in Azure

Azure Active Directory (Azure AD) kunnen organisaties (ook wel tenants genoemd) gebruikerstoegang tot toepassingen beheren. Toepassingen worden onderverdeeld in toepassingen met een webgebaseerde aanmeldingsinterface en toepassingen met een systeemeigen clientervaring. Als u nog geen tenant hebt gemaakt, leest u eerst Een tenant Azure Active Directory maken.

Voor clusters die worden uitgevoerd in Azure, kunt u Azure AD ook gebruiken om de toegang tot beheer-eindpunten 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 gevolg hiervan maakt u twee Azure AD-toepassingen om de toegang tot het cluster te bepalen: één webtoepassing en één native toepassing. Zie Azure AD instellen om clients te verifiëren voor meer informatie over het maken van de vereiste Azure AD-artefacten en hoe u deze kunt vullen 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:

Azure Active Directory gebruiken voor de identiteit van de client
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, wordt aanbevolen om een clustercertificaat te gebruiken voor het verifiëren van knooppunten.

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

Service Fabric op rollen gebaseerd toegangsbeheer

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 rol Administrator 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 clientrollen Administrator en User in wanneer u het cluster maakt. Wijs rollen toe door voor elk roltype afzonderlijke identiteiten op te geven (bijvoorbeeld met behulp van certificaten of Azure AD). Zie voor meer informatie over standaardinstellingen voor toegangsbeheer en het wijzigen van standaardinstellingen Service Fabric op rollen gebaseerd toegangsbeheer voor Service Fabric clients.

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 X.509-certificaten gebruikt 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 Service Fabric clusters in Azure.

Enkele belangrijke zaken om rekening mee te houden:

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

Cluster- en servercertificaat (vereist)

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

Clusterverificatie verifieert de communicatie tussen knooppunt en clusterfederatie. Alleen knooppunten die hun identiteit met dit certificaat kunnen bewijzen, kunnen lid worden van het cluster. Serververificatie verifieert de eindpunten voor clusterbeheer bij een beheerclient, zodat de beheerclient weet dat het met het echte cluster spreekt en niet met een 'man in the middle'. 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 voor onderwerp (SAN's) van het certificaat moet aanwezig zijn in de lijst met toegestane algemene namen.

Het certificaat moet aan de volgende vereisten voldoen:

Het certificaat moet een persoonlijke sleutel bevatten. Deze certificaten hebben doorgaans extensies .pfx of .pem
Het certificaat moet worden gemaakt voor sleuteluitwisseling, die kan worden geëxporteerd naar een bestand Exchange persoonlijke gegevens (.pfx).
De onderwerpnaam van het certificaat moet overeenkomen met het domein dat u gebruikt voor toegang tot Service Fabric cluster . Deze afstemming is vereist om een TLS op te geven voor het HTTPS-beheer-eindpunt en de 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 om rekening mee te houden:

Het veld Onderwerp kan meerdere waarden hebben. Elke waarde wordt vooraf laten gaan 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 naam voor onderwerp is ingevuld, moet het zowel de algemene naam van het certificaat als één vermelding per SAN hebben. Deze worden ingevoerd als DNS-naamwaarden. Zie How to add a Subject Alternative Name to a secure LDAP certificate (Alternatieve naam voor onderwerp 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 aantal extra certificaten kan worden geïnstalleerd op een cluster voor toepassingsbeveiligingsdoeleinden. Voordat u het 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, of het nu Linux- of Windows zijn.

Certificaten voor clientverificatie (optioneel)

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

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