Partager via

Authentification basée sur des certificats X.509 dans les clusters Service Fabric

Cet article complète la présentation de la sécurité des clusters Service Fabric et décrit les détails de l’authentification basée sur des certificats dans les clusters Service Fabric. Nous partons du principe que le lecteur est familiarisé avec les concepts de sécurité fondamentaux, ainsi que les contrôles exposés par Service Fabric pour contrôler la sécurité d’un cluster.

Rubriques abordées sous ce titre :

  • Notions de base de l’authentification basée sur les certificats
  • Identités et leurs rôles respectifs
  • Règles de configuration de certificat
  • Résolution des problèmes et questions fréquentes

Notions de base de l’authentification basée sur les certificats

En guise d’actualisation rapide, en sécurité, un certificat est un instrument destiné à lier des informations concernant une entité (le sujet) à leur possession d’une paire de clés de chiffrement asymétriques, et constitue ainsi une construction principale de chiffrement à clé publique. Les clés représentées par un certificat peuvent être utilisées pour protéger les données ou pour prouver l’identité des titulaires de clés ; lorsqu’il est utilisé conjointement avec un système PKI (Public Key Infrastructure), un certificat peut représenter des caractéristiques supplémentaires de son sujet, telles que la propriété d’un domaine Internet ou certains privilèges accordés à celui-ci par l’émetteur du certificat (connu sous le nom d’autorité de certification ou d’autorité de certification). Une application courante de certificats prend en charge le protocole de chiffrement TLS (Transport Layer Security), ce qui permet des communications sécurisées sur un réseau informatique. Plus précisément, le client et le serveur utilisent des certificats pour garantir la confidentialité et l’intégrité de leur communication, ainsi que pour effectuer l’authentification mutuelle.

Dans Service Fabric, la couche fondamentale d’un cluster (fédération) s’appuie également sur TLS (entre autres protocoles) pour obtenir un réseau fiable et sécurisé de nœuds participants. Les connexions au cluster via les API clientEs Service Fabric utilisent également TLS pour protéger le trafic, ainsi que pour établir les identités des parties. Plus précisément, lorsqu’il est utilisé pour l’authentification dans Service Fabric, un certificat peut être utilisé pour prouver les revendications suivantes : a) le présentateur des informations d’identification du certificat possède la clé privée du certificat b) le hachage SHA-1 du certificat ('empreinte numérique') correspond à une déclaration incluse dans la définition du cluster, ou c) le nom commun unique du certificat correspond à une déclaration incluse dans la définition du cluster, et l’émetteur du certificat est connu ou approuvé.

Dans la liste ci-dessus, 'b' est communément appelé 'épinglage de l’empreinte numérique' ; dans ce cas, la déclaration fait référence à un certificat spécifique et la force du schéma d’authentification repose sur le principe qu’il est informatiquement impossible de falsifier un certificat qui produit la même valeur de hachage qu’un autre, tout en restant un objet valide et correct sous tous les autres aspects. L’élément 'c' représente une autre forme de déclaration d’un certificat, où la force du schéma repose sur la combinaison de l’objet du certificat et de l’autorité émettrice. Dans ce cas, la déclaration fait référence à une classe de certificats : deux certificats présentant les mêmes caractéristiques sont considérés comme entièrement équivalents.

Les sections suivantes expliquent en détail comment le runtime Service Fabric utilise et valide les certificats pour garantir la sécurité du cluster.

Identités et leurs rôles respectifs

Avant de vous plonger dans les détails de l’authentification ou de la sécurisation des canaux de communication, il est important de répertorier les acteurs participants et les rôles correspondants qu’ils jouent dans un cluster :

  • le runtime Service Fabric, appelé « système » : l’ensemble de services qui fournissent les abstractions et les fonctionnalités représentant le cluster. Lorsque vous faites référence à la communication en cluster entre les instances système, nous allons utiliser le terme « identité de cluster » ; Lorsque vous faites référence au cluster en tant que destinataire/cible du trafic provenant de l’extérieur du cluster, nous allons utiliser le terme « identité du serveur ».
  • applications hébergées, appelées « applications » : code fourni par le propriétaire du cluster, qui est orchestré et exécuté dans le cluster
  • clients : entités autorisées à se connecter et exécuter des fonctionnalités dans un cluster, en fonction de la configuration du cluster. Nous faisons la distinction entre deux niveaux de privilèges : « utilisateur » et « administrateur », respectivement. Un client « utilisateur » est limité principalement aux opérations en lecture seule (mais pas toutes les fonctionnalités en lecture seule), tandis qu’un client « administrateur » a un accès illimité aux fonctionnalités du cluster. (Pour plus d’informations, reportez-vous aux rôles de sécurité dans un cluster Service Fabric.)
  • (Azure uniquement) les services Service Fabric qui orchestrent et exposent des contrôles pour l’opération et la gestion des clusters Service Fabric, appelés simplement « service ». Selon l’environnement, le « service » peut faire référence au fournisseur de ressources Azure Service Fabric ou à d’autres fournisseurs de ressources détenus et gérés par l’équipe Service Fabric.

Dans un cluster sécurisé, chacun de ces rôles peut être configuré avec leur propre identité distincte, déclarée en tant que jumelage d’un nom de rôle prédéfini et de ses informations d’identification correspondantes. Service Fabric prend en charge la déclaration des informations d’identification en tant que certificats ou principal de service basé sur un domaine. (Les identités Basées sur Windows/Kerberos sont également prises en charge, mais elles dépassent l’étendue de cet article ; reportez-vous à la sécurité Windows dans les clusters Service Fabric.) Dans les clusters Azure, les rôles clients peuvent également être déclarés en tant qu’identités basées sur l’ID Microsoft Entra.

Comme indiqué ci-dessus, le runtime Service Fabric définit deux niveaux de privilège dans un cluster : « admin » et « user ». Un client administrateur et un composant « système » fonctionnent tous les deux avec des privilèges « admin », et sont donc indistinguishables les uns des autres. Lors de l’établissement d’une connexion au cluster, un appelant authentifié est accordé par le runtime Service Fabric l’un des deux rôles comme base pour l’autorisation suivante. Nous examinerons en détail l’authentification dans les sections suivantes.

Règles de configuration de certificat

Règles de validation

Les paramètres de sécurité d’un cluster Service Fabric décrivent, en principe, les aspects suivants :

  • le type d’authentification ; il s’agit d’une caractéristique immuable au moment de la création du cluster. Par exemple, ces paramètres sont « ClusterCredentialType », « ServerCredentialType » et les valeurs autorisées sont « none », « x509 » ou « windows ». Cet article se concentre sur l’authentification de type x509.
  • les règles de validation (authentification) ; ces paramètres sont définis par le propriétaire du cluster et décrivent les informations d’identification qui doivent être acceptées pour un rôle donné. Des exemples seront examinés en détail immédiatement ci-dessous.
  • paramètres utilisés pour ajuster ou modifier subtilement le résultat de l’authentification ; Voici des exemples d’indicateurs qui limitent ou empêchent l’application des listes de révocation de certificats, etc.

Remarque

Les exemples de configuration de cluster fournis ci-dessous sont des extraits du manifeste de cluster au format XML, comme format le plus digesté qui prend en charge directement la fonctionnalité Service Fabric décrite dans cet article. Les mêmes paramètres peuvent être exprimés directement dans les représentations JSON d’une définition de cluster, qu’il s’agisse d’un manifeste de cluster json autonome ou d’un modèle Azure Resource Mangement.

Une règle de validation de certificat comprend les éléments suivants :

  • le rôle correspondant : client, client administrateur (rôle privilégié)
  • Informations d’identification acceptées pour le rôle, déclarées par empreinte numérique ou nom commun sujet

Déclarations de validation de certificat basées sur l’empreinte numérique

Dans le cas des règles de validation basées sur l’empreinte numérique, les informations d’identification présentées par un appelant demandant une connexion au cluster sont validées comme suit :

  • Les informations d’identification sont un certificat valide et correctement formé : sa chaîne peut être générée, les signatures correspondent
  • le certificat est valide dans le temps (NotBefore <= maintenant < NotAfter)
  • Le hachage SHA-1 du certificat correspond à la déclaration, par comparaison de chaînes ne respectant pas la casse, excluant tous les espaces blancs

Toutes les erreurs d’approbation rencontrées lors de la création ou de la validation de la chaîne sont supprimées pour les déclarations basées sur l’empreinte numérique, à l’exception des certificats expirés, bien que les dispositions existent également pour ce cas. Plus précisément, les échecs liés de type état de révocation inconnu ou hors connexion, racine non approuvée, utilisation de clé non valide ou chaîne partielle sont considérés comme des erreurs récupérables. Dans ce cas, le principe est que le certificat est simplement une enveloppe pour une paire de clés. La sécurité repose sur le fait que le propriétaire du cluster a mis en place des mesures pour protéger la clé privée.

L’extrait suivant d’un manifeste de cluster illustre un tel ensemble de règles de validation basées sur l’empreinte numérique :

<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>

Chacune des entrées ci-dessus fait référence à une identité spécifique, comme décrit précédemment ; chaque entrée permet également de spécifier plusieurs valeurs, en tant que liste de chaînes séparées par des virgules. Dans cet exemple, lors de la validation réussie des informations d’identification entrantes, le présentateur d’un certificat avec l’empreinte SHA-1 'd5ec... 4264' reçoit le rôle 'admin' ; inversement, un appelant s’authentifiant avec le certificat '7c8f... 01b0 » reçoit un rôle « utilisateur », limité aux opérations principalement en lecture seule. Appelant entrant qui présente un certificat dont l’empreinte numérique est soit « abcd... 1234' ou 'ef01... 5678' sera accepté en tant que nœud homologue dans le cluster. Enfin, un client se connectant à un point de terminaison de gestion du cluster s’attend à ce que l’empreinte numérique du certificat de serveur soit « ef01... 5678'.

Comme mentionné précédemment, Service Fabric prend des dispositions pour accepter des certificats expirés ; la raison est que les certificats ont une durée de vie limitée et, lorsqu’ils sont déclarés par empreinte numérique (qui fait référence à une instance de certificat spécifique), l’expiration d’un certificat entraîne l’échec de la connexion au cluster ou une réduction totale du cluster. Il n’est que trop facile d’oublier ou de négliger la rotation d’un certificat épinglé par empreinte numérique, et malheureusement la récupération à partir d’une telle situation est difficile.

À cette fin, le propriétaire du cluster peut indiquer explicitement que les certificats auto-signés déclarés par empreinte numérique doivent être considérés comme valides, comme suit :

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

Ce comportement ne s’étend pas aux certificats émis par l’autorité de certification ; si c’était le cas, un certificat expiré révoqué, connu-to-be- compromis pourrait devenir « valide » dès qu’il ne figure plus dans la liste de révocation de certificats de l’autorité de certification, et présente ainsi un risque de sécurité. Avec les certificats auto-signés, le propriétaire du cluster est considéré comme le seul responsable de la protection de la clé privée du certificat, ce qui n’est pas le cas avec les certificats émis par l’autorité de certification . Le propriétaire du cluster peut ne pas savoir comment ou quand son certificat a été déclaré compromis.

Déclarations de validation de certificat basées sur des noms courants

Les déclarations courantes basées sur des noms prennent l’une des formes suivantes :

  • nom commun de l’objet (uniquement)
  • Nom commun sujet avec épinglage de l’émetteur

Prenons d’abord un extrait d’un manifeste de cluster illustrant les deux styles de déclaration :

    <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>

Les déclarations font référence aux identités de serveur et de cluster, respectivement ; Notez que les déclarations basées sur cn ont leurs propres sections dans le manifeste de cluster, distinctes de la norme « Sécurité ». Dans les deux déclarations, le « Nom » représente le nom commun de l’objet unique du certificat, et le champ « Valeur » représente l’émetteur attendu, comme suit :

  • Dans le premier cas, la déclaration indique que l’élément de nom commun du sujet distinctif du certificat de serveur est supposé correspondre à la chaîne « server.demo.system.servicefabric.azure-int ». Le champ 'Value' vide indique que la racine de la chaîne de certificats est approuvée sur le nœud/l’ordinateur où le certificat de serveur est en cours de validation. Sur Windows, cela signifie que le certificat peut être chaîné à l’un des certificats installés dans le magasin de l’autorité de certification racine approuvée ;
  • dans le deuxième cas, la déclaration indique que le présentateur d’un certificat est accepté en tant que nœud homologue dans le cluster si le nom commun du certificat correspond à la chaîne « cluster.demo.system.servicefabric.azure-int », et que l’empreinte numérique de l’émetteur direct du certificat correspond à l’une des entrées séparées par des virgules dans le champ « Valeur ». (Ce type de règle est connu sous le nom de « nom commun avec épinglage de l’émetteur ».)

Dans les deux cas, la chaîne du certificat est construite et doit être sans erreur ; en d'autres termes, les erreurs de révocation, une chaîne incomplète ou les erreurs de confiance invalides dans le temps sont considérées comme fatales, et la validation du certificat échouera. L’épinglage des émetteurs fait que l’état « racine non approuvée » sera considéré comme une erreur récupérable. Malgré les apparences, il s’agit d’une forme de validation plus stricte, car elle permet au propriétaire du cluster de contraindre l’ensemble des émetteurs autorisés/acceptés à leur propre infrastructure à clé publique.

Une fois la chaîne de certificats générée, elle est validée par rapport à une stratégie TLS/SSL standard avec l’objet déclaré comme nom distant ; un certificat sera considéré comme une correspondance si son nom commun d’objet ou l’un de ses autres noms d’objet correspond à la déclaration CN du manifeste du cluster. Les caractères génériques sont pris en charge dans ce cas, et la correspondance de chaîne ne respecte pas la casse.

(Nous devons clarifier que la séquence décrite ci-dessus peut être exécutée pour chaque type d’utilisation de clé déclarée par le certificat ; si le certificat spécifie l’utilisation de la clé d’authentification du client, la chaîne est générée et évaluée en premier pour un rôle client. En cas de réussite, l’évaluation se termine et la validation réussit. Si le certificat n’a pas l’utilisation de l’authentification du client ou si la validation a échoué, le runtime Service Fabric génère et évalue la chaîne pour l’authentification du serveur.)

Pour terminer l’exemple, l’extrait suivant illustre la déclaration de certificats clients par nom commun :

    <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>

Les déclarations ci-dessus correspondent aux identités d’administrateur et d’utilisateur, respectivement ; la validation des certificats déclarés de cette manière est exactement comme décrit pour les exemples précédents, des certificats de cluster et de serveur.

Remarque

Les déclarations courantes basées sur des noms sont destinées à simplifier la rotation et, en général, la gestion des certificats de cluster. Toutefois, il est recommandé d’adhérer aux recommandations suivantes pour garantir la disponibilité et la sécurité continues du cluster :

  • Préférer l’épinglage de l’émetteur à l’utilisation des racines de confiance
  • éviter de mélanger des émetteurs de différents PKIs
  • assurez-vous que tous les émetteurs attendus sont répertoriés sur la déclaration de certificat ; un émetteur qui ne correspond pas entraîne une validation ayant échoué
  • Assurez-vous que les points de terminaison de stratégie de certificat de l’infrastructure à clé publique sont détectables, disponibles et accessibles. Cela signifie que les points de terminaison AIA, CRL ou OCSP sont déclarés sur le certificat feuille, et qu’ils sont accessibles afin que la création de la chaîne de certificats puisse se terminer.

Le lier ensemble, lors de la réception d’une demande de connexion dans un cluster sécurisé avec des certificats X.509, le runtime Service Fabric utilise les paramètres de sécurité du cluster pour valider les informations d’identification du tiers distant, comme décrit ci-dessus ; si elle réussit, l’appelant/le tiers distant est considéré comme authentifié. Si les informations d’identification correspondent à plusieurs règles de validation, le runtime accorde à l’appelant le rôle privilégié le plus élevé de l’une des règles correspondantes.

Règles de présentation

La section précédente a décrit le fonctionnement de l’authentification dans un cluster sécurisé par certificat ; cette section explique comment le runtime Service Fabric lui-même découvre et charge les certificats qu’il utilise pour la communication en cluster ; nous appelons ces règles de « présentation ».

Comme avec les règles de validation, les règles de présentation spécifient un rôle et la déclaration d’informations d’identification associées, exprimées par empreinte numérique ou par nom commun. Contrairement aux règles de validation, les déclarations courantes basées sur des noms n’ont pas de provisions pour la validation spécifique de l’émetteur, ce qui permet une plus grande flexibilité ainsi qu’une amélioration des performances. Les règles de présentation sont déclarées dans la ou les sections « NodeType » du manifeste de cluster, pour chaque type de nœud distinct ; les paramètres sont fractionnés des sections Sécurité du cluster pour permettre à chaque type de nœud d’avoir sa configuration complète dans une seule section. Dans les clusters Azure Service Fabric, les déclarations de certificat de type de nœud reflètent par défaut les paramètres correspondants dans la section Sécurité de la définition du cluster.

Déclarations de présentation de certificat basées sur l’empreinte numérique

Comme décrit précédemment, le runtime Service Fabric fait la distinction entre son rôle comme homologue d’autres nœuds du cluster et comme serveur pour les opérations de gestion de cluster. En principe, ces paramètres peuvent être configurés séparément, mais dans la pratique, ils ont tendance à s’aligner. Pour le reste de cet article, nous partons du principe que les paramètres correspondent par souci de simplicité.

Prenons l’extrait suivant d’un manifeste de cluster :

  <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>

L’élément « ClusterCertificate » illustre le schéma complet, y compris les paramètres facultatifs ('X509FindValueSecondary') ou ceux avec les valeurs par défaut appropriées ('X509StoreName') ; les autres déclarations affichent un formulaire abrégé. La déclaration de certificat de cluster ci-dessus indique que les paramètres de sécurité des nœuds de type 'nt1vm' sont initialisés avec le certificat 'cc71..1984' comme certificat principal et le certificat '49e2..19d6' comme certificat secondaire ; les deux certificats doivent être trouvés dans le magasin de certificats LocalMachine'My' (ou le chemin d’accès équivalent sous Linux, var/lib/sfcerts).

Déclarations de présentation de certificat basées sur le nom commun

Les certificats de type de nœud peuvent également être déclarés par nom commun sujet, comme illustré ci-dessous :

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

Pour l’un ou l’autre type de déclaration, un nœud Service Fabric lit la configuration au démarrage, recherche et charge les certificats spécifiés et les trie dans l’ordre décroissant de leur attribut NotBefore ; Les certificats expirés sont ignorés et le premier élément de la liste est sélectionné en tant qu’informations d’identification client pour toute connexion Service Fabric tentée par ce nœud. (En effet, Service Fabric privilégie le certificat le plus récemment émis.)

Remarque

Avant la version 7.2.445 (7.2 CU4), Service Fabric sélectionnait le certificat ayant la date d'expiration la plus éloignée (le certificat avec la propriété NotAfter la plus tardive).

Notez que, pour les déclarations de présentation basées sur un nom commun, un certificat est considéré comme une correspondance si son nom commun d’objet est égal au champ X509FindValue (ou X509FindValueSecondary) de la déclaration par comparaison exacte de chaînes respectant la casse. Cela diffère avec les règles de validation, qui prennent en charge la correspondance avec caractères génériques, ainsi que les comparaisons de chaînes ne respectant pas la casse.

Paramètres de configuration de certificat divers

Il a été mentionné précédemment que les paramètres de sécurité d’un cluster Service Fabric permettent également de modifier subtilement le comportement du code d’authentification. Bien que l’article sur les paramètres du cluster Service Fabric représente la liste complète et la plus à jour des paramètres, nous allons développer la signification de quelques-uns des paramètres de sécurité ici, pour terminer l’exposition complète sur l’authentification basée sur des certificats. Pour chaque paramètre, nous allons expliquer l’intention, la valeur/le comportement par défaut, la façon dont elle affecte l’authentification et quelles valeurs sont acceptables.

Comme mentionné, la validation des certificats implique toujours la génération et l’évaluation de la chaîne du certificat. Pour les certificats émis par l’autorité de certification, cet appel d’API de système d’exploitation apparemment simple implique généralement plusieurs appels sortants vers différents points de terminaison de l’infrastructure à clé publique émettrice, la mise en cache des réponses, et ainsi de suite. Étant donné la prévalence des appels de validation de certificat dans un cluster Service Fabric, les problèmes liés aux points de terminaison du PKI peuvent entraîner une réduction de la disponibilité du cluster ou une panne totale. Bien que les appels sortants ne puissent pas être supprimés (voir ci-dessous dans la section FAQ pour plus d’informations sur ce sujet), les paramètres suivants peuvent être utilisés pour masquer les erreurs de validation provoquées par des appels de liste de révocation de certificats défaillants.

  • CrlCheckingFlag : sous la section « Sécurité », chaîne convertie en UINT. La valeur de ce paramètre est utilisée par Service Fabric pour masquer les erreurs d’état de la chaîne de certificats en modifiant le comportement de la génération de chaînes ; il est transmis à l’appel Win32 CryptoAPI CertGetCertificateChain en tant que paramètre « dwFlags » et peut être défini sur n’importe quelle combinaison valide d’indicateurs acceptés par la fonction. La valeur 0 force le runtime Service Fabric à ignorer toutes les erreurs d’état d’approbation . Cela n’est pas recommandé, car son utilisation constituerait une exposition de sécurité significative. La valeur par défaut est 0x40000000 (CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT).

Quand utiliser : pour les tests locaux, avec des certificats auto-signés ou des certificats de développeur qui ne sont pas entièrement formés/ne disposent pas d’une infrastructure de clé publique appropriée pour prendre en charge les certificats. Peut également être utilisé comme atténuation dans les environnements en « air gap » pendant la transition entre les infrastructures à clé publique.

Comment l’utiliser : nous allons prendre un exemple qui force la vérification de la révocation à accéder uniquement aux URL mises en cache. En supposant:

#define CERT_CHAIN_REVOCATION_CHECK_CACHE_ONLY         0x80000000

puis la déclaration dans le manifeste du cluster devient :

  <Section Name="Security">
    <Parameter Name="CrlCheckingFlag" Value="0x80000000" />
  </Section>
  • IgnoreCrlOfflineError : sous la section « Sécurité », booléen avec la valeur par défaut « false ». Représente un raccourci pour supprimer un état d’erreur de création de chaîne ’revocation offline' (ou un état d’erreur de validation de stratégie de chaîne ultérieur).

Quand utiliser : test local ou avec des certificats de développeur non sauvegardés par une infrastructure à clé publique appropriée. Utilisez-la comme atténuation dans les environnements à air gauté ou lorsque l’infrastructure à clé publique est connue pour être inaccessible.

Comment utiliser :

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

Autres paramètres notables (tous sous la section « Sécurité ») :

  • AcceptExpiredPinnedClusterCertificate : abordé dans la section dédiée à la validation des certificats basés sur l’empreinte numérique. Autorise l’acceptation des certificats de cluster autosignés arrivés à expiration.
  • CertificateExpirySafetyMargin : intervalle exprimé en minutes avant l’horodatage NotAfter du certificat et pendant lequel le certificat est considéré comme étant à risque d’expiration. Service Fabric surveille le ou les certificats de cluster et émet régulièrement des rapports d’intégrité sur leur disponibilité restante. Pendant l’intervalle de « sécurité », les rapports d’intégrité sont élevés à l’état « avertissement ». La valeur par défaut est 30 jours.
  • CertificateHealthReportingInterval : contrôle la fréquence des rapports d’intégrité relatifs au temps de validité restant des certificats de cluster. Les rapports ne seront émis qu’une seule fois par intervalle. La valeur est exprimée en secondes, avec une valeur par défaut de 8 heures.
  • EnforcePrevalidationOnSecurityChanges : booléen contrôle le comportement de la mise à niveau du cluster lors de la détection des modifications des paramètres de sécurité. Si la valeur est « true », la mise à niveau du cluster tente de s’assurer qu’au moins un des certificats correspondant à l’une des règles de présentation peut passer une règle de validation correspondante. La pré-validation est exécutée avant que les nouveaux paramètres ne soient appliqués à n’importe quel nœud, mais s’exécute uniquement sur le nœud hébergeant le réplica principal du service Gestionnaire de clusters au moment du lancement de la mise à niveau. À compter de cette écriture, le paramètre a la valeur « false » par défaut et est défini sur « true » pour les nouveaux clusters Azure Service Fabric avec une version d’exécution commençant par la version 7.1.

Scénario de bout en bout (exemples)

Nous avons examiné les règles de présentation, les règles de validation et les indicateurs d’ajustement, mais comment cela fonctionne-t-il ensemble ? Dans cette section, nous allons utiliser deux exemples de bout en bout illustrant comment les paramètres de sécurité peuvent être utilisés pour des mises à niveau de cluster sécurisées. Notez qu’il ne s’agit pas d’une thèse complète sur la gestion appropriée des certificats dans Service Fabric, recherchez un article complémentaire sur ce sujet.

La séparation des règles de présentation et de validation pose la question évidente (ou préoccupation) de savoir s’ils peuvent différer, et quelles seraient les conséquences. Il est en effet possible que la sélection par un nœud d’un certificat d’authentification ne respecte pas les règles de validation d’un autre nœud. En fait, cette différence est la principale cause des incidents liés à l’authentification. En même temps, la séparation de ces règles permet à un cluster de continuer à fonctionner pendant une mise à niveau qui modifie les paramètres de sécurité du cluster. Considérez que, en augmentant d’abord les règles de validation en tant que première étape, tous les nœuds du cluster convergent sur les nouveaux paramètres tout en utilisant les informations d’identification actuelles.

Souvenez-vous que, dans un cluster Service Fabric, une mise à niveau progresse à travers jusqu’à 5 « domaines de mise à niveau » ou UD. Seuls les nœuds de l’UD actuel sont mis à niveau/modifiés à un moment donné, et la mise à niveau passe à l’utilisateur suivant uniquement si la disponibilité du cluster l’autorise. (Pour plus d’informations, consultez les mises à niveau de cluster Service Fabric et d’autres articles sur la même rubrique.) Les modifications de certificat/sécurité sont particulièrement risquées, car elles peuvent isoler les nœuds du cluster ou laisser le cluster à la périphérie de la perte de quorum.

Nous allons utiliser la notation suivante pour décrire les paramètres de sécurité d’un nœud :

Nk : {P :{TP=A}, V :{TP=A}}, où :

  • 'Nk' représente un nœud dans le domaine de mise à niveau k
  • 'P' représente les règles de présentation actuelles du nœud (en supposant que nous faisons référence aux certificats de cluster uniquement) ;
  • 'V' représente les règles de validation actuelles du nœud (certificat de cluster uniquement)
  • 'TP=A' représente une déclaration basée sur l’empreinte numérique (TP), avec 'A' étant une empreinte numérique de certificat
  • 'CN=B' représente une déclaration commune basée sur un nom (CN), avec 'B' étant le nom commun du sujet du certificat

Rotation d’un certificat de cluster déclaré par empreinte numérique

La séquence suivante décrit comment une mise à niveau en 2 étapes peut être utilisée pour introduire en toute sécurité un certificat de cluster secondaire, déclaré par empreinte numérique ; la première phase introduit la nouvelle déclaration de certificat dans les règles de validation, et la deuxième phase l’introduit dans les règles de présentation :

  • état initial : N0 = {P :{TP=A}, V :{TP=A}}, ... Nk = {P :{TP=A}, V :{TP=A}} : le cluster est au repos, tous les nœuds partagent une configuration commune
  • à la fin de la mise à niveau du domaine 0 : N0 = {P :{TP=A}, V :{TP=A, TP=B}}, ... Nk = {P :{TP=A}, V :{TP=A}} : les nœuds dans UD0 présentent le certificat A et acceptent les certificats A ou B ; tous les autres nœuds présents et acceptent le certificat A uniquement
  • une fois le dernier domaine de mise à niveau terminé : N0 = {P :{TP=A}, V :{TP=A, TP=B}}, ... Nk = {P :{TP=A}, V :{TP=A, TP=B}} : tous les nœuds présentent le certificat A, tous les nœuds acceptent le certificat A ou B

À ce stade, le cluster est à nouveau en équilibre, et la deuxième phase de la mise à niveau/modification des paramètres de sécurité peut commencer :

  • à la fin de la mise à niveau du domaine 0 : N0 = {P :{TP=A, TP=B}, V :{TP=A, TP=B}}, ... Nk = {P :{TP=A}, V :{TP=A, TP=B}} : les nœuds dans UD0 commencent à présenter B, qui est accepté par tout autre nœud du cluster.
  • une fois le dernier domaine de mise à niveau terminé : N0 = {P :{TP=A, TP=B}, V :{TP=A, TP=B}}, ... Nk = {P :{TP=A, TP=B}, V :{TP=A, TP=B}} : tous les nœuds ont basculé vers la présentation du certificat B. Le certificat A peut maintenant être supprimé/supprimé de la définition du cluster avec un ensemble de mises à niveau ultérieur.

Conversion du type de déclaration d’un cluster d’empreinte numérique à nom commun

De même, la modification du type de déclaration de certificat (de l’empreinte numérique au nom commun) suit le même modèle que ci-dessus. Notez que les règles de validation autorisent la déclaration des certificats d’un rôle donné par empreinte numérique et nom commun dans la même définition de cluster. En revanche, cependant, les règles de présentation n’autorisent qu’une seule forme de déclaration. Par ailleurs, l’approche sécurisée pour convertir un certificat de cluster d'une empreinte numérique à un nom commun consiste à d'abord introduire le certificat cible par empreinte numérique, puis à modifier cette déclaration vers un format basé sur le nom commun. Dans l’exemple suivant, nous partons du principe que l’empreinte numérique « A » et le nom commun du sujet « B » font référence au même certificat.

  • état initial : N0 = {P :{TP=A}, V :{TP=A}}, ... Nk = {P :{TP=A}, V :{TP=A}} : le cluster est au repos, tous les nœuds partagent une configuration commune, avec A étant l’empreinte numérique du certificat principal
  • à la fin de la mise à niveau du domaine 0 : N0 = {P :{TP=A}, V :{TP=A, CN=B}}, ... Nk = {P :{TP=A}, V :{TP=A}} : les nœuds de l’UD0 présentent le certificat A et acceptent les certificats avec l’empreinte numérique A ou le nom commun B ; tous les autres nœuds présents et acceptent le certificat A uniquement
  • une fois le dernier domaine de mise à niveau terminé : N0 = {P :{TP=A}, V :{TP=A, CN=B}}, ... Nk = {P :{TP=A}, V :{TP=A, CN=B}} : tous les nœuds présentent le certificat A, tous les nœuds acceptent le certificat A (TP) ou B (CN)

À ce stade, nous pouvons procéder à la modification des règles de présentation avec une mise à niveau ultérieure :

  • à la fin de la mise à niveau du domaine 0 : N0 = {P :{CN=B}, V :{TP=A, CN=B}}, ... Nk = {P :{TP=A}, V :{TP=A, CN=B}} : les nœuds dans UD0 présentent le certificat B trouvé par CN et acceptent les certificats avec l’empreinte numérique A ou le nom commun B ; tous les autres nœuds présents et acceptent le certificat A uniquement, sélectionné par empreinte numérique
  • une fois le dernier domaine de mise à niveau terminé : N0 = {P :{CN=B}, V :{TP=A, CN=B}}, ... Nk = {P :{CN=B}, V :{TP=A, CN=B}} : tous les nœuds présentent le certificat B trouvé par CN, tous les nœuds acceptent le certificat A (TP) ou B (CN)

L’achèvement de la phase 2 marque également la conversion du cluster en certificats basés sur des noms communs ; Les déclarations de validation basées sur l’empreinte numérique peuvent être supprimées dans une mise à niveau de cluster ultérieure.

Remarque

Dans les clusters Azure Service Fabric, les flux de travail présentés ci-dessus sont orchestrés par le fournisseur de ressources Service Fabric ; le propriétaire du cluster est toujours responsable de l’approvisionnement de certificats dans le cluster en fonction des règles indiquées (présentation ou validation) et est encouragé à effectuer des modifications en plusieurs étapes.

Dans un article distinct, nous aborderons la rubrique relative à la gestion et à l’approvisionnement de certificats dans un cluster Service Fabric.

Résolution des problèmes et questions fréquentes

Bien que le débogage des problèmes liés à l’authentification dans les clusters Service Fabric ne soit pas facile, nous espérons que les conseils et astuces suivants pourront vous aider. Le moyen le plus simple pour commencer des enquêtes consiste à examiner les journaux d'événements de Service Fabric sur les nœuds du cluster non seulement ceux présentant des symptômes, mais aussi les nœuds qui sont actifs mais qui ne peuvent pas se connecter à l’un de leurs voisins. Sur Windows, les événements d’importance sont généralement enregistrés sous les canaux « Applications and Services Logs\Microsoft-ServiceFabric\Admin » ou « Operational », respectivement. Parfois, il peut être utile d’activer la journalisation CAPI2, afin de capturer plus de détails sur la validation du certificat, la récupération des listes CRL/CTL, etc. (N’oubliez pas de la désactiver une fois la reproduction terminée, ce journal peut être très détaillé.)

Les symptômes typiques qui se manifestent dans un cluster qui rencontrent des problèmes d’authentification sont les suivants :

  • les nœuds sont arrêtés/en boucle
  • Les tentatives de connexion sont rejetées
  • les tentatives de connexion expirent

Chacun des symptômes peut être causé par des problèmes différents, et la même cause racine peut présenter différentes manifestations ; par conséquent, nous allons simplement répertorier un petit échantillon de problèmes typiques, avec des recommandations pour les résoudre.

  • Les nœuds peuvent échanger des messages, mais ne peuvent pas se connecter. Une cause possible de la fin des tentatives de connexion est l’erreur « certificat non mis en correspondance » : l’une des parties d’une connexion Service Fabric à Service Fabric présente un certificat qui échoue aux règles de validation du destinataire. Peut être accompagné de l’une des erreurs suivantes :

    0x80071c44	-2147017660	FABRIC_E_SERVER_AUTHENTICATION_FAILED

    Pour diagnostiquer/examiner plus en détail : sur chacun des nœuds qui tentent la connexion, déterminez le certificat qui est présenté ; examinez le certificat et essayez d’émuler les règles de validation (vérifiez l’empreinte numérique ou l’égalité de noms commune, vérifiez les empreintes de l’émetteur si spécifiées).

    Un autre code d’erreur associé courant peut être :

    0x800b0109	-2146762487	CERT_E_UNTRUSTEDROOT

    Dans ce cas, le certificat est identifié par son nom commun, et l’un des éléments suivants s’applique :

    • les émetteurs ne sont pas épinglés et le certificat racine n’est pas approuvé, ou
    • les émetteurs sont épinglés, mais la déclaration n’inclut pas l’empreinte numérique de l’émetteur direct de ce certificat

  • Un nœud est actif, mais ne peut pas se connecter à d'autres nœuds ; les autres nœuds ne reçoivent pas le trafic provenant du nœud défaillant. Dans ce cas, il est possible que le chargement du certificat échoue sur le nœud local. Recherchez les erreurs suivantes :

    • certificate not found : vérifiez que les certificats déclarés dans les règles de présentation peuvent être résolus par le contenu du magasin de certificats LocalMachine\My (ou comme spécifié). Les causes possibles de l’échec peuvent inclure :

      • caractères non valides dans la déclaration d’empreinte numérique
      • le certificat n’est pas installé
      • le certificat a expiré
      • la déclaration de nom commun inclut le préfixe 'CN='
      • la déclaration spécifie un caractère générique et aucune correspondance exacte n’existe dans le magasin de certificats (déclaration : CN=*.mydomain.com, certificat réel : CN=server.mydomain.com)

    • informations d’identification inconnues : indique une clé privée manquante correspondant au certificat, généralement accompagnée du code d’erreur :

      0x8009030d	-2146893043	SEC_E_UNKNOWN_CREDENTIALS
0x8009030e	-2146893042	SEC_E_NO_CREDENTIALS

      Pour remédier à ce problème, vérifiez l’existence de la clé privée ; vérifiez que SFAdmins reçoit l’accès « read|execute » à la clé privée.

    • type de fournisseur incorrect : indique un certificat de nouvelle génération de chiffrement (CNG) (« Fournisseur de stockage de clés logicielles Microsoft ») ; à ce stade, Service Fabric prend uniquement en charge les certificats CAPI1. Généralement accompagné du code d’erreur :

      0x80090014	-2146893804	NTE_BAD_PROV_TYPE

      Pour remédier à ce problème, recréez le certificat de cluster à l’aide d’un fournisseur CAPI1 (par exemple, « Microsoft Enhanced RSA et fournisseur de chiffrement AES »). Pour plus d’informations sur les fournisseurs de chiffrement, consultez Présentation des fournisseurs de chiffrement