Delen via

Verificatie op basis van X.509-certificaten in Service Fabric-clusters

  • Artikel

Dit artikel vormt een aanvulling op de inleiding tot de beveiliging van Service Fabric-clusters en gaat in op de details van verificatie op basis van certificaten in Service Fabric-clusters. We gaan ervan uit dat de lezer bekend is met fundamentele beveiligingsconcepten en ook met de besturingselementen die Service Fabric beschikbaar maakt om de beveiliging van een cluster te beheren.

Onderwerpen die onder deze titel worden behandeld:

  • Basisbeginselen van verificatie op basis van certificaten
  • Identiteiten en hun respectieve rollen
  • Certificaatconfiguratieregels
  • Problemen oplossen en veelgestelde vragen

Basisbeginselen van verificatie op basis van certificaten

Als een korte vernieuwingsfunctie is een certificaat een instrument dat bedoeld is om informatie over een entiteit (het onderwerp) te binden aan het bezit van een paar asymmetrische cryptografische sleutels, en vormt dus een kernconstructie van openbare-sleutelcryptografie. De sleutels die door een certificaat worden vertegenwoordigd, kunnen worden gebruikt om gegevens te beschermen of om de identiteit van sleutelhouders te bewijzen; wanneer een certificaat wordt gebruikt in combinatie met een PKI-systeem (Public Key Infrastructure), kan een certificaat aanvullende kenmerken van het onderwerp vertegenwoordigen, zoals het eigendom van een internetdomein of bepaalde bevoegdheden die aan het certificaat zijn verleend door de uitgever van het certificaat (ook wel certificeringsinstantie of CA genoemd). Een veelgebruikte toepassing van certificaten is het cryptografische protocol Transport Layer Security (TLS) ondersteunen, waardoor beveiligde communicatie via een computernetwerk mogelijk is. De client en server gebruiken met name certificaten om de privacy en integriteit van hun communicatie te waarborgen en om wederzijdse verificatie uit te voeren.

In Service Fabric bouwt de fundamentele laag van een cluster (federatie) ook voort op TLS (onder andere protocollen) om een betrouwbaar, beveiligd netwerk van deelnemende knooppunten te bereiken. Verbindingen met het cluster via Service Fabric Client-API's maken gebruik van TLS en om verkeer te beveiligen en ook om de identiteiten van de partijen tot stand te brengen. Wanneer een certificaat wordt gebruikt voor verificatie in Service Fabric, kan een certificaat worden gebruikt om de volgende claims te bewijzen: a) de presentator van de certificaatreferentie beschikt over de persoonlijke sleutel van het certificaat b) de SHA-1-hash van het certificaat ('vingerafdruk') komt overeen met een declaratie die is opgenomen in de clusterdefinitie, of c) de DN-naam van het certificaat komt overeen met een declaratie die is opgenomen in de clusterdefinitie. en de verlener van het certificaat is bekend of vertrouwd.

In de bovenstaande lijst staat b ook wel bekend als 'vingerafdrukpinning'; In dit geval verwijst de declaratie naar een specifiek certificaat en de sterkte van het verificatieschema blijft op de veronderstelling dat het rekenkundig onbereikbaar is om een certificaat te vervalsen dat dezelfde hashwaarde produceert als een ander certificaat, terwijl het nog steeds een geldig, goed gevormd object in alle andere opzichten is. Item c vertegenwoordigt een alternatieve vorm van het declareren van een certificaat, waarbij de sterkte van het schema berust op de combinatie van het onderwerp van het certificaat en de uitgevende instantie. In dit geval verwijst de declaratie naar een klasse certificaten: twee certificaten met dezelfde kenmerken worden beschouwd als volledig gelijkwaardig.

In de volgende secties wordt uitgebreid uitgelegd hoe de Service Fabric-runtime certificaten gebruikt en valideert om de clusterbeveiliging te waarborgen.

Identiteiten en hun respectieve rollen

Voordat u ingaat op de details van verificatie of het beveiligen van communicatiekanalen, is het belangrijk om de deelnemende actoren en de bijbehorende rollen die ze spelen in een cluster weer te geven:

  • de Service Fabric-runtime, 'systeem': de set services die de abstracties en functionaliteit bieden die het cluster vertegenwoordigen. Wanneer we verwijzen naar communicatie in het cluster tussen systeemexemplaren, gebruiken we de term 'clusteridentiteit'; wanneer u naar het cluster verwijst als ontvanger/doel van verkeer van buiten het cluster, gebruiken we de term 'serveridentiteit'.
  • gehoste toepassingen, aangeduid als 'toepassingen': code die wordt geleverd door de eigenaar van het cluster, dat wordt ingedeeld en uitgevoerd in het cluster
  • clients: entiteiten die zijn toegestaan om verbinding te maken met en functionaliteit uit te voeren in een cluster, volgens de clusterconfiguratie. We maken onderscheid tussen twee niveaus van bevoegdheden: respectievelijk 'gebruiker' en 'beheerder'. Een 'gebruikersclient' is voornamelijk beperkt tot alleen-lezenbewerkingen (maar niet alle alleen-lezenfunctionaliteit), terwijl een 'admin'-client onbeperkte toegang heeft tot de functionaliteit van het cluster. (Raadpleeg voor meer informatieBeveiligingsrollen in een Service Fabric-cluster.)
  • (Alleen Azure) de Service Fabric-services die besturingselementen organiseren en beschikbaar maken voor de werking en het beheer van Service Fabric-clusters, ook wel 'service' genoemd. Afhankelijk van de omgeving kan de service verwijzen naar de Azure Service Fabric-resourceprovider of andere resourceproviders die eigendom zijn van en worden beheerd door het Service Fabric-team.

In een beveiligd cluster kunnen al deze rollen worden geconfigureerd met hun eigen, afzonderlijke identiteit, gedeclareerd als de koppeling van een vooraf gedefinieerde rolnaam en de bijbehorende referentie. Service Fabric ondersteunt het declareren van referenties als certificaten of op een domein gebaseerde service-principal. (Windows-/Kerberos-identiteiten worden ook ondersteund, maar vallen buiten het bereik van dit artikel; raadpleeg Windows-beveiliging in Service Fabric-clusters.) In Azure-clusters kunnen clientrollen ook worden gedeclareerd als op Microsoft Entra ID gebaseerde identiteiten.

Zoals hierboven vermeld, definieert de Service Fabric-runtime twee bevoegdheidsniveaus in een cluster: 'admin' en 'user'. Een beheerderclient en een systeemonderdeel werken beide met beheerdersbevoegdheden en dus onherstelbaar van elkaar. Bij het tot stand brengen van een verbinding in/met het cluster wordt een geverifieerde aanroeper verleend door de Service Fabric-runtime een van de twee rollen als basis voor de volgende autorisatie. In de volgende secties wordt de verificatie uitgebreid onderzocht.

Certificaatconfiguratieregels

Validatieregels

De beveiligingsinstellingen van een Service Fabric-cluster beschrijven in principe de volgende aspecten:

  • het verificatietype; dit is een aanmaaktijd, onveranderbaar kenmerk van het cluster. Voorbeelden van dergelijke instellingen zijn 'ClusterCredentialType', 'ServerCredentialType' en toegestane waarden zijn 'none', 'x509' of 'windows'. Dit artikel is gericht op de x509-type verificatie.
  • de validatieregels (verificatie); deze instellingen worden ingesteld door de eigenaar van het cluster en beschrijven welke referenties voor een bepaalde rol moeten worden geaccepteerd. Voorbeelden worden hieronder uitgebreid onderzocht.
  • instellingen die worden gebruikt om het resultaat van verificatie aan te passen of subtly te wijzigen; Voorbeelden hier zijn vlaggen die het afdwingen van certificaatintrekkingslijsten beperken of beperken, enzovoort.

Notitie

Voorbeelden van clusterconfiguraties die hieronder worden gegeven, zijn fragmenten uit het clustermanifest in XML-indeling, zoals de meest verwerkte indeling die rechtstreeks ondersteuning biedt voor de Service Fabric-functionaliteit die in dit artikel wordt beschreven. Dezelfde instellingen kunnen rechtstreeks worden uitgedrukt in de JSON-weergaven van een clusterdefinitie, ongeacht of het een zelfstandig json-clustermanifest of een Azure Resource Mangement-sjabloon is.

Een certificaatvalidatieregel bestaat uit de volgende elementen:

  • de bijbehorende rol: client, beheerderclient (bevoorrechte rol)
  • de referentie die is geaccepteerd voor de rol, gedeclareerd door vingerafdruk of algemene naam van het onderwerp

Certificaatvalidatiedeclaraties op basis van vingerafdruk

In het geval van validatieregels op basis van vingerafdruk worden de referenties die door een aanroeper die een verbinding in/naar het cluster aanvraagt, als volgt gevalideerd:

  • de referentie een geldig, goed opgemaakt certificaat is: de keten kan worden gebouwd, handtekeningen komen overeen
  • het certificaat is geldig (NotBefore <= now < NotAfter)
  • de SHA-1-hash van het certificaat komt overeen met de declaratie, als een hoofdlettergevoelige tekenreeksvergelijking, met uitzondering van alle witruimten

Vertrouwensfouten die zijn opgetreden tijdens het bouwen of valideren van ketens, worden onderdrukt voor declaraties op basis van vingerafdruk, met uitzondering van verlopen certificaten, hoewel er ook bepalingen voor dat geval bestaan. Met name fouten met betrekking tot: intrekkingsstatus onbekend of offline, niet-vertrouwde hoofdmap, ongeldig sleutelgebruik, gedeeltelijke keten worden beschouwd als niet-fatale fouten; het uitgangspunt is in dit geval dat het certificaat slechts een envelop is voor een sleutelpaar. De beveiliging ligt in het feit dat de eigenaar van het cluster op plaatsen heeft ingesteld om de persoonlijke sleutel te beschermen.

Het volgende fragment uit een clustermanifest illustreert een dergelijke set validatieregels op basis van vingerafdruk:

<Section Name="Security">
  <Parameter Name="ClusterCredentialType" Value="X509" />
  <Parameter Name="ServerAuthCredentialType" Value="X509" />
  <Parameter Name="AdminClientCertThumbprints" Value="d5ec...4264" />
  <Parameter Name="ClientCertThumbprints" Value="7c8f...01b0" />
  <Parameter Name="ClusterCertThumbprints" Value="abcd...1234,ef01...5678" />
  <Parameter Name="ServerCertThumbprints" Value="ef01...5678" />
</Section>

Elk van de bovenstaande vermeldingen verwijst naar een specifieke identiteit zoals eerder beschreven; elke vermelding maakt het ook mogelijk om meerdere waarden op te geven, als door komma's gescheiden lijst met tekenreeksen. In dit voorbeeld, bij het valideren van de binnenkomende referenties, de presentator van een certificaat met de SHA-1 vingerafdruk 'd5ec... 4264' krijgt de rol beheerder; omgekeerd, een aanroeper die wordt geverifieerd met certificaat '7c8f... 01b0 krijgt een 'gebruikersrol', beperkt tot voornamelijk alleen-lezen bewerkingen. Een inkomende beller die een certificaat presenteert waarvan de vingerafdruk 'abcd... 1234 of ef01... 5678' wordt geaccepteerd als een peerknooppunt in het cluster. Ten slotte verwacht een client die verbinding maakt met een beheereindpunt van het cluster dat de vingerafdruk van het servercertificaat 'ef01... 5678'.

Zoals eerder vermeld, maakt Service Fabric wel bepalingen voor het accepteren van verlopen certificaten; de reden hiervoor is dat certificaten een beperkte levensduur hebben en, wanneer ze worden gedeclareerd met vingerafdruk (die verwijst naar een specifiek certificaatexemplaren), waardoor een certificaat kan verlopen, kan dit leiden tot een fout bij het maken van verbinding met het cluster of een rechte samenstorting van het cluster. Het is allemaal te gemakkelijk om een vingerafdruk-vastgemaakt certificaat te vergeten of te negeren, en helaas is het herstel van een dergelijke situatie moeilijk.

Daartoe kan de eigenaar van het cluster expliciet aangeven dat zelfondertekende certificaten die door vingerafdruk zijn gedeclareerd, als volgt als geldig worden beschouwd:

  <Section Name="Security">
    <Parameter Name="AcceptExpiredPinnedClusterCertificate" Value="true" />
  </Section>

Dit gedrag is niet van toepassing op certificaten die zijn uitgegeven door de CA; Als dat het geval is, kan een ingetrokken, bekend verlopen certificaat 'geldig' worden zodra het certificaat niet meer in de certificaatintrekkingslijst van de CA zou voorkomen en dus een beveiligingsrisico zou vormen. Met zelfondertekende certificaten wordt de eigenaar van het cluster beschouwd als de enige partij die verantwoordelijk is voor het beveiligen van de persoonlijke sleutel van het certificaat. Dit is niet het geval bij certificaten die zijn uitgegeven door een CA. De eigenaar van het cluster is mogelijk niet op de hoogte van hoe of wanneer het certificaat is gedeclareerd.

Algemene certificaatvalidatiedeclaraties op basis van een naam

Algemene declaraties op basis van namen hebben een van de volgende formulieren:

  • algemene onderwerpnaam (alleen)
  • algemene onderwerpnaam met verlener vastmaken

Laten we eerst een fragment uit een clustermanifest overwegen waarin beide declaratiestijlen worden geïllustreerd:

    <Section Name="Security/ServerX509Names">
      <Parameter Name="server.demo.system.servicefabric.azure-int" Value="" />
    </Section>
    <Section Name="Security/ClusterX509Names">
      <Parameter Name="cluster.demo.system.servicefabric.azure-int" Value="1b45...844d,d7fe...26c8,3ac7...6960,96ea...fb5e" />
    </Section>

De declaraties verwijzen respectievelijk naar de server- en clusteridentiteiten; Houd er rekening mee dat de declaraties op basis van cn hun eigen secties in het clustermanifest hebben, gescheiden van de standaardbeveiliging. In beide declaraties vertegenwoordigt de 'Naam' de gemeenschappelijke naam van het onderwerp van het certificaat en het veld 'Waarde' de verwachte verlener, als volgt:

  • in het eerste geval geeft de declaratie aan dat het algemene naamelement van het DN-onderwerp van het servercertificaat naar verwachting overeenkomt met de tekenreeks "server.demo.system.servicefabric.azure-int"; het lege veld Waarde geeft de verwachting aan dat de basis van de certificaatketen wordt vertrouwd op het knooppunt/de computer waarop het servercertificaat wordt gevalideerd; in Windows betekent dit dat het certificaat kan worden gekoppeld aan een van de certificaten die zijn geïnstalleerd in het archief vertrouwde basis-CA;
  • in het tweede geval geeft de declaratie aan dat de presentator van een certificaat wordt geaccepteerd als een peerknooppunt in het cluster als de algemene naam van het certificaat overeenkomt met de tekenreeks cluster.demo.system.servicefabric.azure-int, en de vingerafdruk van de directe uitgever van het certificaat overeenkomt met een van de door komma's gescheiden vermeldingen in het veld Waarde. (Dit regeltype wordt ook wel 'algemene naam met verlener vastmaken' genoemd.)

In beide gevallen wordt de keten van het certificaat gebouwd en wordt naar verwachting foutloos; Dat wil gezegd, intrekkingsfouten, gedeeltelijke keten- of tijdsfouten met een ongeldige vertrouwensrelatie worden beschouwd als onherstelbare fouten en mislukt de certificaatvalidatie. Het vastmaken van de verleners leidt ertoe dat de status 'niet-vertrouwde hoofdmap' wordt gezien als een niet-fatale fout; ondanks verschijningen is dit een strengere vorm van validatie, omdat de eigenaar van het cluster de set geautoriseerde/geaccepteerde verleners kan beperken tot hun eigen PKI.

Nadat de certificaatketen is gebouwd, wordt deze gevalideerd op basis van een standaard TLS/SSL-beleid met het gedeclareerde onderwerp als de externe naam; een certificaat wordt beschouwd als een overeenkomst als de algemene naam van het onderwerp of een van de alternatieve namen van het onderwerp overeenkomt met de CN-declaratie van het clustermanifest. Jokertekens worden in dit geval ondersteund en de tekenreekskoppeling is niet hoofdlettergevoelig.

(We moeten verduidelijken dat de hierboven beschreven volgorde kan worden uitgevoerd voor elk type sleutelgebruik dat door het certificaat is gedeclareerd. Als het certificaat het gebruik van de clientverificatiesleutel opgeeft, wordt de keten eerst gebouwd en geëvalueerd voor een clientrol. In het geval van succes is de evaluatie voltooid en is de validatie geslaagd. Als het certificaat niet beschikt over het gebruik van clientverificatie of als de validatie is mislukt, bouwt en evalueert de Service Fabric-runtime de keten voor serververificatie.)

Het volgende fragment illustreert het declareren van clientcertificaten op algemene naam om het voorbeeld te voltooien:

    <Section Name="Security/AdminClientX509Names">
      <Parameter Name="admin.demo.client.servicefabric.azure-int" Value="1b45...844d,d7fe...26c8,3ac7...6960,96ea...fb5e" />
    </Section>
    <Section Name="Security/ClientX509Names">
      <Parameter Name="user.demo.client.servicefabric.azure-int" Value="1b45...844d,d7fe...26c8,3ac7...6960,96ea...fb5e" />
    </Section>

De bovenstaande declaraties komen respectievelijk overeen met de beheerders- en gebruikersidentiteiten; validatie van certificaten die op deze manier zijn gedeclareerd, is precies zoals beschreven voor de vorige voorbeelden, van cluster- en servercertificaten.

Notitie

Algemene declaraties op basis van namen zijn bedoeld om de rotatie te vereenvoudigen en in het algemeen het beheer van clustercertificaten te vereenvoudigen. Het wordt echter aanbevolen om te voldoen aan de volgende aanbevelingen om de continue beschikbaarheid en beveiliging van het cluster te garanderen:

  • voorkeur geven aan het vastmaken van verleners om te vertrouwen op vertrouwde roots
  • voorkomen dat verleners van verschillende PKI's worden gemengd
  • ervoor zorgen dat alle verwachte uitgevers worden vermeld in de certificaatdeclaratie; een niet-overeenkomende verlener resulteert in een mislukte validatie
  • zorg ervoor dat de eindpunten van het certificaatbeleid van de PKI kunnen worden gedetecteerd, beschikbaar en toegankelijk zijn. Dit betekent dat de AIA-, CRL- of OCSP-eindpunten worden gedeclareerd op het bladcertificaat en dat ze toegankelijk zijn, zodat het bouwen van certificaatketens kan worden voltooid.

De Service Fabric-runtime gebruikt de beveiligingsinstellingen van het cluster bij het ontvangen van een aanvraag voor een verbinding in een cluster dat is beveiligd met X.509-certificaten, de beveiligingsinstellingen van het cluster om de referenties van de externe partij te valideren, zoals hierboven beschreven; als dit lukt, wordt de beller/externe partij beschouwd als geverifieerd. Als de referentie overeenkomt met meerdere validatieregels, verleent de runtime de aanroeper de hoogste bevoorrechte rol van een van de overeenkomende regels.

Presentatieregels

In de vorige sectie werd beschreven hoe verificatie werkt in een met een certificaat beveiligd cluster; in deze sectie wordt uitgelegd hoe de Service Fabric-runtime zelf de certificaten detecteert en laadt die worden gebruikt voor communicatie in het cluster; We noemen deze 'presentatieregels'.

Net als bij de validatieregels geven de presentatieregels een rol en de bijbehorende referentiedeclaratie op, uitgedrukt in vingerafdruk of algemene naam. In tegenstelling tot de validatieregels hebben gemeenschappelijke op naam gebaseerde declaraties geen bepalingen voor het vastmaken van verleners; dit biedt meer flexibiliteit en verbeterde prestaties. De presentatieregels worden gedeclareerd in de sectie(s NodeType) van het clustermanifest, voor elk afzonderlijk knooppunttype; de instellingen worden gesplitst uit de beveiligingssecties van het cluster, zodat elk knooppunttype de volledige configuratie in één sectie kan hebben. In Azure Service Fabric-clusters worden certificaatdeclaraties van het knooppunttype standaard ingesteld op de bijbehorende instellingen in de sectie Beveiliging van de definitie van het cluster.

Declaraties van certificaatpresentaties op basis van vingerafdruk

Zoals eerder beschreven, maakt de Service Fabric-runtime onderscheid tussen de rol als peer van andere knooppunten in het cluster en als de server voor clusterbeheerbewerkingen. In principe kunnen deze instellingen afzonderlijk worden geconfigureerd, maar in de praktijk worden ze meestal uitgelijnd. Voor de rest van dit artikel gaan we ervan uit dat de instellingen overeenkomen met de eenvoud.

Laten we rekening houden met het volgende fragment uit een clustermanifest:

  <NodeTypes>
    <NodeType Name="nt1vm">
      <Certificates>
        <ClusterCertificate X509FindType="FindByThumbprint" X509FindValue="cc71...1984" X509FindValueSecondary="49e2...19d6" X509StoreName="my" Name="ClusterCertificate" />
        <ServerCertificate X509FindValue="cc71...1984" Name="ServerCertificate" />
        <ClientCertificate X509FindValue="cc71...1984" Name="ClientCertificate" />
      </Certificates>
    </NodeType>
  </NodeTypes>

Het element ClusterCertificate demonstreert het volledige schema, inclusief optionele parameters ('X509FindValueSecondary') of de parameters met de juiste standaardwaarden ('X509StoreName'); in de andere declaraties wordt een verkort formulier weergegeven. De bovenstaande clustercertificaatdeclaratie geeft aan dat de beveiligingsinstellingen van knooppunten van het type nt1vm worden geïnitialiseerd met certificaat CC71.. 1984 als primair en de '49e2.' 19d6'-certificaat als secundaire; beide certificaten zijn naar verwachting te vinden in het certificaatarchief LocalMachine 'My' (of het linux-equivalente pad, var/lib/sfcerts).

Algemene certificaatpresentatiedeclaraties op basis van een naam

De certificaten van het knooppunttype kunnen ook worden gedeclareerd op de algemene naam van het onderwerp, zoals hieronder wordt geïllustreerd:

  <NodeTypes>
    <NodeType Name="nt1vm">
      <Certificates>
        <ClusterCertificate X509FindType="FindBySubjectName" X509FindValue="demo.cluster.azuredocpr.system.servicefabric.azure-int" Name="ClusterCertificate" />
      </Certificates>
    </NodeType>
  </NodeTypes>

Voor beide typen declaraties leest een Service Fabric-knooppunt de configuratie bij het opstarten, zoekt en laadt u de opgegeven certificaten en sorteert u deze in aflopende volgorde van het kenmerk NotBefore; verlopen certificaten worden genegeerd en het eerste element van de lijst wordt geselecteerd als de clientreferentie voor een Service Fabric-verbinding die door dit knooppunt wordt geprobeerd. (In feite geeft Service Fabric de voorkeur aan het meest recent uitgegeven certificaat.)

Notitie

Vóór versie 7.2.445 (7.2 CU4) heeft Service Fabric het meest verre verlopende certificaat geselecteerd (het certificaat met de meest verre eigenschap 'NotAfter')

Houd er rekening mee dat voor presentatiedeclaraties op basis van algemene naam een certificaat wordt beschouwd als een overeenkomst als de algemene naam van het onderwerp gelijk is aan het veld X509FindValue (of X509FindValueSecondary) van de declaratie als een hoofdlettergevoelige, exacte tekenreeksvergelijking. Dit is in tegenstelling tot de validatieregels, die ondersteuning bieden voor jokertekens, evenals hoofdlettergevoelige tekenreeksvergelijkingen.

Diverse configuratie-instellingen voor certificaten

Eerder werd vermeld dat de beveiligingsinstellingen van een Service Fabric-cluster ook het gedrag van de verificatiecode subtly kunnen wijzigen. Hoewel het artikel over Service Fabric-clusterinstellingen de uitgebreide en meest recente lijst met instellingen vertegenwoordigt, gaan we verder met de betekenis van een aantal van de beveiligingsinstellingen hier om de volledige weergave van verificatie op basis van certificaten te voltooien. Voor elke instelling leggen we de intentie, standaardwaarde/gedrag uit, hoe dit van invloed is op verificatie en welke waarden acceptabel zijn.

Zoals vermeld, impliceert certificaatvalidatie altijd het bouwen en evalueren van de keten van het certificaat. Voor door ca uitgegeven certificaten omvat deze blijkbaar eenvoudige OS-API-aanroep meestal verschillende uitgaande aanroepen naar verschillende eindpunten van de verlenende PKI, caching van antwoorden enzovoort. Gezien de prevalentie van certificaatvalidatie-aanroepen in een Service Fabric-cluster, kunnen eventuele problemen in de eindpunten van de PKI leiden tot een verminderde beschikbaarheid van het cluster of uitsplitsing. Hoewel de uitgaande aanroepen niet kunnen worden onderdrukt (zie hieronder in de sectie Veelgestelde vragen voor meer informatie hierover), kunnen de volgende instellingen worden gebruikt om validatiefouten te maskeren die worden veroorzaakt door mislukte CRL-aanroepen.

  • CrlCheckingFlag - onder de sectie Beveiliging, tekenreeks geconverteerd naar UINT. De waarde van deze instelling wordt door Service Fabric gebruikt om fouten in de status van de certificaatketen te maskeren door het gedrag van het ketengebouw te wijzigen; het wordt doorgegeven aan de Win32 CryptoAPI CertGetCertificateChain-aanroep als de parameter dwFlags en kan worden ingesteld op elke geldige combinatie van vlaggen die door de functie worden geaccepteerd. Een waarde van 0 dwingt de Service Fabric-runtime om eventuele vertrouwensstatusfouten te negeren. Dit wordt niet aanbevolen, omdat het gebruik ervan een aanzienlijke blootstelling aan de beveiliging zou vormen. De standaardwaarde is 0x40000000 (CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT).

Wanneer moet u het volgende gebruiken: voor lokaal testen, met zelfondertekende certificaten of ontwikkelaarscertificaten die niet volledig zijn gevormd/geen juiste openbare-sleutelinfrastructuur hebben om de certificaten te ondersteunen. Kan ook worden gebruikt als beperking in lucht-gapped-omgevingen tijdens de overgang tussen PKI's.

Procedure: we nemen een voorbeeld waarin de intrekkingscontrole wordt afgedwongen om alleen toegang te krijgen tot URL's in de cache. Ervan uitgaande dat:

#define CERT_CHAIN_REVOCATION_CHECK_CACHE_ONLY         0x80000000

vervolgens wordt de declaratie in het clustermanifest:

  <Section Name="Security">
    <Parameter Name="CrlCheckingFlag" Value="0x80000000" />
  </Section>
  • IgnoreCrlOfflineError- onder de sectie 'Beveiliging' booleaanse waarde met een standaardwaarde 'false'. Vertegenwoordigt een snelkoppeling voor het onderdrukken van een foutstatus voor het bouwen van een ketenketen (of een volgende foutstatus voor ketenbeleidsvalidatie).

Wanneer gebruikt u: lokaal testen of met ontwikkelaarscertificaten die niet worden ondersteund door een juiste PKI. Gebruik als beperking in lucht-gapped-omgevingen of wanneer de PKI bekend is dat deze niet toegankelijk is.

Procedure:

  <Section Name="Security">
    <Parameter Name="IgnoreCrlOfflineError" Value="true" />
  </Section>

Andere belangrijke instellingen (alles onder de sectie Beveiliging):

  • AcceptExpiredPinnedClusterCertificate - besproken in de sectie die is toegewezen aan certificaatvalidatie op basis van vingerafdruk; staat toe dat verlopen zelfondertekende clustercertificaten worden geaccepteerd.
  • CertificateExpirySafetyMargin - interval, uitgedrukt in minuten voorafgaand aan de notafter-tijdstempel van het certificaat, en gedurende welke het certificaat risico loopt op verlooptijd. Service Fabric bewaakt clustercertificaten en verzendt periodiek statusrapporten over de resterende beschikbaarheid. Binnen het veiligheidsinterval worden deze statusrapporten verhoogd naar de status 'waarschuwing'. De standaardwaarde is 30 dagen.
  • CertificateHealthReportingInterval - bepaalt de frequentie van statusrapporten met betrekking tot de resterende geldigheid van clustercertificaten. Rapporten worden slechts eenmaal per dit interval verzonden. De waarde wordt uitgedrukt in seconden, met een standaardwaarde van 8 uur.
  • EnforcePrevalidationOnSecurityChanges - Booleaanse waarde bepaalt het gedrag van de clusterupgrade bij het detecteren van wijzigingen van beveiligingsinstellingen. Als deze optie is ingesteld op 'true', probeert de clusterupgrade ervoor te zorgen dat ten minste één van de certificaten die overeenkomen met een van de presentatieregels een bijbehorende validatieregel kan doorgeven. De prevalidatie wordt uitgevoerd voordat de nieuwe instellingen worden toegepast op een knooppunt, maar wordt alleen uitgevoerd op het knooppunt dat als host fungeert voor de primaire replica van de Cluster Manager-service op het moment dat de upgrade wordt gestart. Vanaf dit schrijven heeft de instelling de standaardwaarde 'false' en wordt deze ingesteld op 'true' voor nieuwe Azure Service Fabric-clusters met een runtimeversie die begint met 7.1.

End-to-endscenario (voorbeelden)

We hebben gekeken naar presentatieregels, validatieregels en het aanpassen van vlaggen, maar hoe werkt dit allemaal? In deze sectie behandelen we twee end-to-end voorbeelden die laten zien hoe de beveiligingsinstellingen kunnen worden gebruikt voor veilige clusterupgrades. Let op: dit is niet bedoeld als een uitgebreid dissertatie over het juiste certificaatbeheer in Service Fabric, zoek naar een begeleidend artikel over dat onderwerp.

De scheiding van presentatie- en validatieregels vormt de voor de hand liggende vraag (of bezorgdheid) of ze kunnen afwijken en wat de gevolgen zijn. Het is inderdaad mogelijk dat de selectie van een knooppunt van een verificatiecertificaat de validatieregels van een ander knooppunt niet doorgeeft. In feite is deze discrepantie de primaire oorzaak van verificatiegerelateerde incidenten. Tegelijkertijd zorgt de scheiding van deze regels ervoor dat een cluster blijft werken tijdens een upgrade die de beveiligingsinstellingen van het cluster wijzigt. Houd er rekening mee dat door eerst de validatieregels als eerste stap te verbeteren, alle knooppunten van het cluster convergeren op de nieuwe instellingen terwijl de huidige referenties nog steeds worden gebruikt.

Zoals u weet, wordt in een Service Fabric-cluster een upgrade uitgevoerd tot (maximaal 5) 'upgradedomeinen' of UD's. Alleen knooppunten in de huidige UD worden op een bepaald moment bijgewerkt/gewijzigd en de upgrade gaat alleen verder met de volgende UD als de beschikbaarheid van het cluster dit toestaat. (Raadpleeg Upgrades van Service Fabric-clusters en andere artikelen in hetzelfde onderwerp voor meer informatie.) Certificaat-/beveiligingswijzigingen zijn bijzonder riskant, omdat ze knooppunten van het cluster kunnen isoleren of het cluster aan de rand van quorumverlies kunnen verlaten.

We gebruiken de volgende notatie om de beveiligingsinstellingen van een knooppunt te beschrijven:

Nk: {P:{TP=A}, V:{TP=A}}, waarbij:

  • 'Nk' vertegenwoordigt een knooppunt in upgradedomein k
  • 'P' vertegenwoordigt de huidige presentatieregels van het knooppunt (ervan uitgaande dat we alleen verwijzen naar clustercertificaten);
  • 'V' vertegenwoordigt de huidige validatieregels van het knooppunt (alleen clustercertificaat)
  • 'TP=A' vertegenwoordigt een declaratie op basis van vingerafdruk (TP), waarbij A een certificaatvingerafdruk is
  • 'CN=B' vertegenwoordigt een algemene op naam gebaseerde declaratie (CN), waarbij 'B' de algemene naam van het certificaat is

Een clustercertificaat roteren dat is gedeclareerd met vingerafdruk

In de volgende reeks wordt beschreven hoe een upgrade van twee fasen kan worden gebruikt om veilig een secundair clustercertificaat te introduceren, gedeclareerd met vingerafdruk; de eerste fase introduceert de nieuwe certificaatdeclaratie in de validatieregels en de tweede fase introduceert deze in de presentatieregels:

  • initiële status: N0 = {P:{TP=A}, V:{TP=A}}, ... Nk = {P:{TP=A}, V:{TP=A}} - het cluster is in rust, alle knooppunten delen een algemene configuratie
  • bij het voltooien van het upgradedomein 0: N0 = {P:{TP=A}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A}, V:{TP=A}} - knooppunten in UD0 zullen certificaat A presenteren en certificaten A of B accepteren; alle andere knooppunten aanwezig en accepteren alleen certificaat A
  • na het voltooien van het laatste upgradedomein: N0 = {P:{TP=A}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A}, V:{TP=A, TP=B}} - alle knooppunten presenteren certificaat A, alle knooppunten accepteren certificaat A of B

Op dit moment is het cluster weer in evenwicht en kan de tweede fase van de upgrade/veranderende beveiligingsinstellingen beginnen:

  • bij het voltooien van upgradedomein 0: N0 = {P:{TP=A, TP=B}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A}, V:{TP=A, TP=B}} - knooppunten in UD0 beginnen met het presenteren van B, dat wordt geaccepteerd door elk ander knooppunt in het cluster.
  • na het voltooien van het laatste upgradedomein: N0 = {P:{TP=A, TP=B}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A, TP=B}, V:{TP=A, TP=B}} - alle knooppunten zijn overgeschakeld naar het presenteren van certificaat B. Certificaat A kan nu worden buiten gebruik gesteld/verwijderd uit de clusterdefinitie met een volgende set upgrades.

Een cluster converteren van vingerafdruk naar declaraties op basis van een algemene naam

Op dezelfde manier volgt het wijzigen van het type certificaatdeclaratie (van vingerafdruk naar algemene naam) hetzelfde patroon als hierboven. Houd er rekening mee dat met validatieregels de certificaten van een bepaalde rol kunnen worden gedeclareerd door zowel vingerafdruk als algemene naam in dezelfde clusterdefinitie. De presentatieregels staan daarentegen slechts één vorm van declaratie toe. Overigens is de veilige methode voor het converteren van een clustercertificaat van vingerafdruk naar een gemeenschappelijke naam het beoogde doelcertificaat eerst door vingerafdruk te introduceren en die declaratie vervolgens te wijzigen in een gemeenschappelijke naam. In het volgende voorbeeld wordt ervan uitgegaan dat de vingerafdruk 'A' en de algemene onderwerpnaam 'B' naar hetzelfde certificaat verwijzen.

  • initiële status: N0 = {P:{TP=A}, V:{TP=A}}, ... Nk = {P:{TP=A}, V:{TP=A}} - het cluster is in rust, alle knooppunten delen een gemeenschappelijke configuratie, waarbij A de vingerafdruk van het primaire certificaat is
  • bij het voltooien van het upgradedomein 0: N0 = {P:{TP=A}, V:{TP=A, CN=B}}, ... Nk = {P:{TP=A}, V:{TP=A}} - knooppunten in UD0 presenteren certificaat A en accepteren certificaten met vingerafdruk A of algemene naam B; alle andere knooppunten aanwezig en accepteren alleen certificaat A
  • na het voltooien van het laatste upgradedomein: N0 = {P:{TP=A}, V:{TP=A, CN=B}}, ... Nk = {P:{TP=A}, V:{TP=A, CN=B}} - alle knooppunten presenteren certificaat A, alle knooppunten accepteren certificaat A (TP) of B (CN)

Op dit moment kunnen we doorgaan met het wijzigen van de presentatieregels met een volgende upgrade:

  • bij het voltooien van het upgradedomein 0: N0 = {P:{CN=B}, V:{TP=A, CN=B}}, ... Nk = {P:{TP=A}, V:{TP=A, CN=B}} - knooppunten in UD0 presenteren certificaat B gevonden door CN en accepteren certificaten met vingerafdruk A of algemene naam B; alle andere knooppunten aanwezig en accepteren alleen certificaat A, geselecteerd met vingerafdruk
  • bij het voltooien van het laatste upgradedomein: N0 = {P:{CN=B}, V:{TP=A, CN=B}}, ... Nk = {P:{CN=B}, V:{TP=A, CN=B}} - alle knooppunten presenteren certificaat B gevonden door CN, alle knooppunten accepteren certificaat A (TP) of B (CN)

Voltooiing van fase 2 markeert ook de conversie van het cluster naar algemene op naam gebaseerde certificaten; de validatiedeclaraties op basis van vingerafdruk kunnen worden verwijderd in een volgende clusterupgrade.

Notitie

In Azure Service Fabric-clusters worden de hierboven gepresenteerde werkstromen ingedeeld door de Service Fabric-resourceprovider; de eigenaar van het cluster is nog steeds verantwoordelijk voor het inrichten van certificaten in het cluster volgens de aangegeven regels (presentatie of validatie) en wordt aangemoedigd om wijzigingen in meerdere stappen uit te voeren.

In een afzonderlijk artikel behandelen we het onderwerp van het beheren en inrichten van certificaten in een Service Fabric-cluster.

Problemen oplossen en veelgestelde vragen

Hoewel het opsporen van verificatieproblemen in Service Fabric-clusters niet eenvoudig is, hopen we dat de volgende hints en tips kunnen helpen. De eenvoudigste manier om met onderzoeken te beginnen, is door de Service Fabric-gebeurtenislogboeken op de knooppunten van het cluster te onderzoeken, niet noodzakelijkerwijs alleen de knooppunten met symptomen, maar ook knooppunten die geen verbinding kunnen maken met een van hun buren. In Windows worden gebeurtenissen van significantie meestal geregistreerd onder respectievelijk de kanalen Toepassingen en Services\Microsoft-ServiceFabric\Admin of Operational. Soms kan het handig zijn om CAPI2-logboekregistratie in te schakelen, om meer details vast te leggen met betrekking tot de certificaatvalidatie, het ophalen van CRL/CTL enzovoort. (Vergeet niet om het uit te schakelen nadat u de repro hebt voltooid, het kan behoorlijk uitgebreid zijn.)

Typische symptomen die zich in een cluster voordoen die verificatieproblemen ondervinden, zijn:

  • knooppunten zijn offline/fietsen
  • verbindingspogingen worden geweigerd
  • time-out voor verbindingspogingen

Elk van de symptomen kan worden veroorzaakt door verschillende problemen en dezelfde hoofdoorzaak kan verschillende manifestaties vertonen; Daarom vermelden we gewoon een kleine steekproef van typische problemen, met aanbevelingen voor het oplossen van deze problemen.

  • Knooppunten kunnen berichten uitwisselen, maar kunnen geen verbinding maken. Een mogelijke oorzaak voor het beëindigen van verbindingspogingen is de fout 'certificaat niet overeenkomend': een van de partijen in een Service Fabric-naar-Service Fabric-verbinding presenteert een certificaat dat de validatieregels van de ontvanger mislukt. Kan vergezeld gaan van een van de volgende fouten:

    0x80071c44	-2147017660	FABRIC_E_SERVER_AUTHENTICATION_FAILED

    Om verder te onderzoeken: op elk van de knooppunten die de verbinding proberen te maken, bepaalt u welk certificaat wordt gepresenteerd; controleer het certificaat en probeer de validatieregels te emuleren (controleer op vingerafdruk of gemeenschappelijke naam gelijkheid, controleer de vingerafdruk van de uitgever indien opgegeven).

    Een andere veelvoorkomende bijbehorende foutcode kan zijn:

    0x800b0109	-2146762487	CERT_E_UNTRUSTEDROOT

    In dit geval wordt het certificaat gedeclareerd met een algemene naam en is een van de volgende opties van toepassing:

    • de verleners zijn niet vastgemaakt en het basiscertificaat wordt niet vertrouwd of
    • de verleners zijn vastgemaakt, maar de declaratie bevat niet de vingerafdruk van de directe uitgever van dit certificaat

  • Een knooppunt is up, maar kan geen verbinding maken met andere knooppunten; andere knooppunten ontvangen geen inkomend verkeer van het mislukte knooppunt. In dit geval is het mogelijk dat het laden van het certificaat op het lokale knooppunt mislukt. Zoek naar de volgende fouten:

    • certificaat niet gevonden: zorg ervoor dat de certificaten die zijn gedeclareerd in de presentatieregels, kunnen worden omgezet door de inhoud van het certificaatarchief LocalMachine\My (of zoals opgegeven). Mogelijke oorzaken voor fouten kunnen zijn:

      • ongeldige tekens in de vingerafdrukdeclaratie
      • het certificaat niet is geïnstalleerd
      • het certificaat is verlopen
      • de declaratie common-name bevat het voorvoegsel 'CN='
      • de declaratie geeft een jokerteken op en er bestaat geen exacte overeenkomst in het certificaatarchief (declaratie: CN=*.mydomain.com, werkelijk certificaat: CN=server.mydomain.com)

    • onbekende referenties: geeft een ontbrekende persoonlijke sleutel aan die overeenkomt met het certificaat, meestal vergezeld van foutcode:

      0x8009030d	-2146893043	SEC_E_UNKNOWN_CREDENTIALS
0x8009030e	-2146893042	SEC_E_NO_CREDENTIALS

      Controleer het bestaan van de persoonlijke sleutel om dit te verhelpen; controleer of SFAdmins toegang heeft tot de persoonlijke sleutel 'read|execute'.

    • ongeldig providertype - geeft een CNG-certificaat (Crypto New Generation) aan ('Microsoft Software Key Storage Provider'); Op dit moment ondersteunt Service Fabric alleen CAPI1-certificaten. Meestal vergezeld van foutcode:

      0x80090014	-2146893804	NTE_BAD_PROV_TYPE

      U kunt dit oplossen door het clustercertificaat opnieuw te maken met behulp van een CAPI1-provider (bijvoorbeeld Microsoft Enhanced RSA en AES Cryptographic Provider). Raadpleeg Cryptografische providers voor meer informatie over cryptoproviders