Référence technique des contrôles cryptographiques

S’applique à : Configuration Manager (branche actuelle)

Configuration Manager utilise la signature et le chiffrement pour protéger la gestion des appareils dans la hiérarchie du Configuration Manager. Avec la signature, si des données ont été modifiées en transit, elles sont ignorées. Le chiffrement permet d’empêcher un attaquant de lire les données à l’aide d’un analyseur de protocole réseau.

Le principal algorithme de hachage que Configuration Manager utilise pour la signature est SHA-256. Lorsque deux sites Configuration Manager communiquent entre eux, ils signent leurs communications avec SHA-256.

À compter de la version 2107, l’algorithme de chiffrement principal utilisé par Configuration Manager est AES-256. Le chiffrement se produit principalement dans les deux domaines suivants :

• Si vous activez le site pour utiliser le chiffrement, le client chiffre ses données d’inventaire et ses messages d’état qu’il envoie au point de gestion.

• Lorsque le client télécharge des stratégies secrètes, le point de gestion chiffre toujours ces stratégies. Par exemple, une séquence de tâches de déploiement de système d’exploitation qui inclut des mots de passe.

Lorsque vous utilisez la communication client via HTTPS, configurez votre infrastructure à clé publique (PKI) pour utiliser des certificats avec le maximum d’algorithmes de hachage et la longueur de clé. Lors de l’utilisation de certificats CNG v3, les clients de Configuration Manager prennent uniquement en charge les certificats qui utilisent l’algorithme de chiffrement RSA. Pour plus d’informations, consultez Exigences de certificat PKI et Vue d’ensemble des certificats CNG v3.

Pour la sécurité du transport, tout ce qui utilise TLS prend en charge AES-256. Cette prise en charge inclut lorsque vous configurez le site pour le protocole HTTP AMÉLIORÉ (E-HTTP) ou HTTPS. Pour les systèmes de site locaux, vous pouvez contrôler les suites de chiffrement TLS. Pour les rôles basés sur le cloud comme la passerelle de gestion cloud (CMG), si vous activez TLS 1.2, Configuration Manager configure les suites de chiffrement.

Pour la plupart des opérations de chiffrement avec les systèmes d’exploitation Windows, Configuration Manager utilise les algorithmes suivants de la bibliothèque Windows CryptoAPI rsaenh.dll.

Pour plus d’informations sur des fonctionnalités spécifiques, voir Opérations de site.

Opérations de site

Les informations contenues dans le Configuration Manager peuvent être signées et chiffrées. Ces opérations sont prises en charge avec ou sans certificat PKI.

Signature et chiffrement de stratégie

Le site signe les affectations de stratégie client avec son certificat auto-signé. Ce comportement permet d’éviter le risque de sécurité d’un point de gestion compromis d’envoyer des stratégies falsifiées. Si vous utilisez la gestion des clients Internet, ce comportement est important, car il nécessite un point de gestion accessible sur Internet.

Lorsque la stratégie contient des données sensibles, à compter de la version 2107, le point de gestion les chiffre avec AES-256. La stratégie qui contient des données sensibles est envoyée uniquement aux clients autorisés. Le site ne chiffre pas la stratégie qui ne comporte pas de données sensibles.

Lorsqu’un client stocke la stratégie, il chiffre la stratégie à l’aide de l’interface de programmation d’applications de protection des données (DPAPI) de Windows.

Hachage de stratégie

Lorsqu’un client demande une stratégie, il obtient d’abord une attribution de stratégie. Ensuite, il sait quelles politiques s’appliquent à lui, et il ne peut demander que ces organes politiques. Chaque affectation de stratégie contient le hachage calculé pour l’organisme de stratégie correspondant. Le client télécharge les organismes de stratégie applicables, puis calcule le hachage pour chaque organisme de stratégie. Si le hachage de l’organisme de stratégie ne correspond pas au hachage de l’attribution de stratégie, le client ignore l’organisme de stratégie.

L’algorithme de hachage pour la stratégie est SHA-256.

Hachage de contenu

Le service de gestionnaire de distribution sur le serveur de site hache les fichiers de contenu de tous les packages. Le fournisseur de stratégie inclut le hachage dans la stratégie de distribution de logiciels. Lorsque le client Configuration Manager télécharge le contenu, il régénère le hachage localement et le compare à celui fourni dans la stratégie. Si les hachages correspondent, le contenu n’est pas modifié et le client l’installe. Si un seul octet du contenu est modifié, les hachages ne correspondent pas et le client n’installe pas le logiciel. Cette case activée permet de s’assurer que le logiciel approprié est installé, car le contenu réel est comparé à la stratégie.

L’algorithme de hachage par défaut pour le contenu est SHA-256.

Tous les appareils ne peuvent pas prendre en charge le hachage de contenu. Les exceptions sont les suivantes :

• Clients Windows lorsqu’ils diffusent en continu du contenu App-V.

Signature et chiffrement des stocks

Lorsqu’un client envoie un inventaire matériel ou logiciel à un point de gestion, il signe toujours l’inventaire. Peu importe que le client communique avec le point de gestion via E-HTTP ou HTTPS. S’ils utilisent E-HTTP, vous pouvez également choisir de chiffrer ces données, ce qui est recommandé.

Chiffrement de migration d’état

Lorsqu’une séquence de tâches capture des données à partir d’un client pour le déploiement du système d’exploitation, elle chiffre toujours les données. Dans les versions 2103 et ultérieures, la séquence de tâches exécute l’outil de migration de l’état utilisateur (USMT) avec l’algorithme de chiffrement AES-256 .

Chiffrement pour les packages de multidiffusion

Pour chaque package de déploiement de système d’exploitation, vous pouvez activer le chiffrement lorsque vous utilisez la multidiffusion. Ce chiffrement utilise l’algorithme AES-256 . Si vous activez le chiffrement, aucune autre configuration de certificat n’est requise. Le point de distribution multidiffusion génère automatiquement des clés symétriques pour chiffrer le package. Chaque package possède une clé de chiffrement différente. La clé est stockée sur le point de distribution multidiffusion à l’aide des API Windows standard.

Lorsque le client se connecte à la session multidiffusion, l’échange de clés a lieu sur un canal chiffré. Si le client utilise HTTPS, il utilise le certificat d’authentification du client émis par l’infrastructure à clé publique (PKI). Si le client utilise E-HTTP, il utilise le certificat auto-signé. Le client stocke uniquement la clé de chiffrement en mémoire pendant la session de multidiffusion.

Chiffrement pour le support de déploiement du système d’exploitation

Lorsque vous utilisez un média pour déployer des systèmes d’exploitation, vous devez toujours spécifier un mot de passe pour protéger le média. Avec un mot de passe, les variables d’environnement de séquence de tâches sont chiffrées avec AES-128. Les autres données sur le support, y compris les packages et le contenu des applications, ne sont pas chiffrées.

Chiffrement du contenu basé sur le cloud

Lorsque vous activez une passerelle de gestion cloud (CMG) pour stocker du contenu, ce dernier est chiffré avec AES-256. Le contenu est chiffré chaque fois que vous le mettez à jour. Lorsque les clients téléchargent le contenu, il est chiffré et protégé par la connexion HTTPS.

Signature des mises à jour logicielles

Toutes les mises à jour logicielles doivent être signées par un éditeur approuvé pour éviter toute falsification. Sur les ordinateurs clients, l’agent Windows Update (WUA) recherche les mises à jour à partir du catalogue. Il n’installe pas la mise à jour s’il ne trouve pas le certificat numérique dans le magasin Éditeurs approuvés sur l’ordinateur local.

Lorsque vous publiez des mises à jour logicielles avec System Center Mises à jour Publisher, un certificat numérique signe les mises à jour logicielles. Vous pouvez spécifier un certificat PKI ou configurer Mises à jour éditeur pour qu’il génère un certificat auto-signé pour signer la mise à jour logicielle. Si vous utilisez un certificat auto-signé pour publier le catalogue des mises à jour, tel que WSUS Publishers Self-signed, le certificat doit également se trouver dans le magasin de certificats des autorités de certification racines de confiance sur l’ordinateur local. WUA vérifie également si le paramètre de stratégie de groupe Autoriser le contenu signé provenant de l’emplacement intranet du service de mise à jour Microsoft est activé sur l’ordinateur local. Ce paramètre de stratégie doit être activé pour que WUA analyse les mises à jour qui ont été créées et publiées avec System Center Mises à jour Publisher.

Données de configuration signées pour les paramètres de conformité

Lorsque vous importez des données de configuration, le Configuration Manager vérifie la signature numérique du fichier. Si les fichiers ne sont pas signés ou si la case activée de la signature échoue, la console vous invite à poursuivre l’importation. Importez uniquement les données de configuration si vous faites explicitement confiance à l’éditeur et à l’intégrité des fichiers.

Chiffrement et hachage pour la notification du client

Si vous utilisez la notification client, toutes les communications utilisent TLS et les algorithmes les plus élevés que le serveur et le client peuvent négocier. La même négociation se produit pour le hachage des paquets transférés lors de la notification au client, qui utilise SHA-2.

Certificats

Pour obtenir la liste des certificats d’infrastructure à clé publique (PKI) pouvant être utilisés par Configuration Manager, les exigences ou limitations particulières et le mode d’utilisation des certificats, voir Exigences relatives aux certificats PKI. Cette liste inclut les algorithmes de hachage pris en charge et les longueurs de clé. La plupart des certificats prennent en charge les longueurs de clé SHA-256 et 2048 bits.

La plupart des opérations de Configuration Manager qui utilisent des certificats prennent également en charge les certificats v3. Pour plus d’informations, consultez Vue d’ensemble des certificats CNG v3.

Configuration Manager requiert des certificats PKI dans les cas suivants :

• Lorsque vous gérez des clients Configuration Manager sur Internet

• Lorsque vous utilisez une passerelle de gestion cloud (CMG)

Pour la plupart des autres communications nécessitant des certificats pour l’authentification, la signature ou le chiffrement, Configuration Manager utilise automatiquement les certificats PKI, s’ils sont disponibles. S’ils ne sont pas disponibles, Configuration Manager génère des certificats auto-signés.

Gestion des périphériques mobiles et certificats PKI

Certificats de déploiement de système d’exploitation et PKI

Lorsque vous utilisez Configuration Manager pour déployer des systèmes d’exploitation et qu’un point de gestion nécessite des connexions client HTTPS, le client a besoin d’un certificat pour communiquer avec le point de gestion. Cette exigence s’applique même lorsque le client se trouve dans une phase transitoire, comme le démarrage à partir d’un support de séquence de tâches ou d’un point de distribution compatible PXE. Pour prendre en charge ce scénario, créez un certificat d’authentification du client PKI et exportez-le avec la clé privée. Importez-le ensuite dans les propriétés du serveur de site et ajoutez également le certificat d’autorité de certification racine approuvé du point de gestion.

Si vous créez un support de démarrage, vous importez le certificat d’authentification client lorsque vous créez le support de démarrage. Pour protéger la clé privée et d’autres données sensibles configurées dans la séquence de tâches, configurez un mot de passe sur le support de démarrage. Chaque ordinateur qui démarre à partir du support de démarrage utilise le même certificat avec le point de gestion requis pour les fonctions client, telles que la demande de stratégie client.

Si vous utilisez PXE, importez le certificat d’authentification du client vers le point de distribution compatible PXE. Il utilise le même certificat pour chaque client qui démarre à partir de ce point de distribution compatible PXE. Pour protéger la clé privée et d’autres données sensibles dans les séquences de tâches, exigez un mot de passe pour PXE.

Si l’un de ces certificats d’authentification client est compromis, bloquez-le dans le nœud Certificats de l’espace de travail administration , nœud Sécurité . Pour gérer ces certificats, vous devez disposer de l’autorisation Gérer le certificat de déploiement du système d’exploitation.

Une fois que Configuration Manager a déployé le système d’exploitation, installé le client, le client a besoin de son propre certificat d’authentification client PKI pour la communication client HTTPS.

Solutions proxy ISV et certificats PKI

Les éditeurs de logiciels indépendants (ISV) peuvent créer des applications qui étendent le Configuration Manager. Par exemple, un éditeur de logiciels indépendant peut créer des extensions pour prendre en charge les plateformes clientes non Windows. Toutefois, si les systèmes de site nécessitent des connexions client HTTPS, ces clients doivent également utiliser des certificats PKI pour communiquer avec le site. Configuration Manager inclut la possibilité d’attribuer un certificat au proxy ISV qui active les communications entre les clients proxy ISV et le point de gestion. Si vous utilisez des extensions qui nécessitent des certificats proxy ISV, consultez la documentation relative à ce produit.

Si le certificat ISV est compromis, bloquez-le dans le nœud Certificats de l’espace de travail administration , nœud Sécurité .

Copier le GUID du certificat du proxy ISV

À compter de la version 2111, pour simplifier la gestion de ces certificats proxy ISV, vous pouvez maintenant copier son GUID dans la console Configuration Manager.

1. Dans la console Configuration Manager, accédez à l’espace de travail Administration.

2. Développez Sécurité et sélectionnez le nœud Certificats .

3. Triez la liste des certificats en fonction de la colonne Type .

4. Sélectionnez un certificat de type Proxy ISV.

5. Dans le ruban, sélectionnez Copier le GUID du certificat.

Cette action copie le GUID de ce certificat, par exemple : aa05bf38-5cd6-43ea-ac61-ab101f943987

Asset Intelligence et certificats

Depuis novembre 2021, nous avons déconseillé Asset Intelligence et nous recommandons aux clients de désinstaller ce rôle.

Services et certificats Azure

La passerelle de gestion cloud (CMG) nécessite des certificats d’authentification de serveur. Ces certificats permettent au service de fournir une communication HTTPS aux clients sur Internet. Pour plus d’informations, consultez Certificat d’authentification du serveur CMG.

Les clients ont besoin d’un autre type d’authentification pour communiquer avec une passerelle de gestion cloud et le point de gestion local. Ils peuvent utiliser Microsoft Entra ID, un certificat PKI ou un jeton de site. Pour plus d’informations, consultez Configurer l’authentification client pour la passerelle de gestion cloud.

Les clients n’ont pas besoin d’un certificat PKI client pour utiliser le stockage cloud. Une fois qu’il s’est authentifié auprès du point de gestion, celui-ci émet un jeton d’accès Configuration Manager au client. Le client présente ce jeton à la GCC pour accéder au contenu. Le jeton est valable huit heures.

Vérification de la liste de révocation de certificats pour les certificats PKI

Une liste de révocation de certificats (CRL) PKI augmente la sécurité globale, mais nécessite une surcharge administrative et de traitement. Si vous activez la vérification de la liste de révocation de certificats, mais que les clients ne peuvent pas y accéder, la connexion PKI échoue.

IIS active la vérification de la liste de révocation de certificats par défaut. Si vous utilisez une liste de révocation de certificats avec votre déploiement PKI, vous n’avez pas besoin de configurer la plupart des systèmes de site qui exécutent IIS. L’exception concerne les mises à jour logicielles, qui nécessitent une étape manuelle pour activer la vérification de la liste de révocation de certificats pour vérifier les signatures des fichiers de mise à jour logicielle.

Lorsqu’un client utilise HTTPS, il active la vérification de CRL par défaut.

Les connexions suivantes ne prennent pas en charge la vérification de la liste de révocation de certificats dans le Configuration Manager :

• Connexions serveur à serveur

Communication avec le serveur

Configuration Manager utilise les contrôles cryptographiques suivants pour la communication serveur.

Communication du serveur au sein d’un site

Chaque serveur de système de site utilise un certificat pour transférer des données à d’autres systèmes de site dans le même site Configuration Manager. Certains rôles de système de site utilisent également des certificats pour l’authentification. Par exemple, si vous installez le point proxy d’inscription sur un serveur et le point d’inscription sur un autre serveur, ils peuvent s’authentifier mutuellement à l’aide de ce certificat d’identité.

Lorsque Configuration Manager utilise un certificat pour cette communication, si un certificat PKI est disponible avec une fonctionnalité d’authentification de serveur, Configuration Manager l’utilise automatiquement. Si ce n’est pas le cas, Configuration Manager génère un certificat auto-signé. Ce certificat auto-signé dispose de la fonctionnalité d’authentification serveur, utilise SHA-256 et a une longueur de clé de 2 048 bits. Configuration Manager copie le certificat dans le magasin Trusted People sur d’autres serveurs de système de site qui peuvent avoir besoin d’approuver le système de site. Les systèmes de site peuvent ensuite se faire confiance en utilisant ces certificats et PeerTrust.

En plus de ce certificat pour chaque serveur de système de site, Configuration Manager génère un certificat auto-signé pour la plupart des rôles de système de site. Lorsqu’il existe plusieurs instance du rôle de système de site dans le même site, ils partagent le même certificat. Par exemple, vous pouvez avoir plusieurs points de gestion sur le même site. Ce certificat auto-signé utilise SHA-256 et a une longueur de clé de 2 048 bits. Elle est copiée dans le Trusted People Store sur les serveurs du système de site qui peuvent avoir besoin de l’approuver. Les rôles de système de site suivants génèrent ce certificat :

• Point de synchronisation Asset Intelligence

• Point de protection du point de terminaison

• Point de l’état de status de secours

• Point de gestion

• Point de distribution multidiffusion

• Point de Reporting Services

• Point de mise à jour logicielle

• Point de migration d’état

Configuration Manager génère et gère automatiquement ces certificats.

Pour envoyer des messages de status du point de distribution au point de gestion, Configuration Manager utilise un certificat d’authentification client. Lorsque vous configurez le point de gestion pour HTTPS, un certificat PKI est nécessaire. Si le point de gestion accepte les connexions E-HTTP, vous pouvez utiliser un certificat PKI. Il peut également utiliser un certificat auto-signé avec une capacité d’authentification client, utilise SHA-256 et a une longueur de clé de 2 048 bits.

Communication du serveur entre les sites

Configuration Manager transfère des données entre les sites à l’aide de la réplication de base de données et de la réplication basée sur des fichiers. Pour plus d’informations, voir Transferts de données entre sites et Communications entre points de terminaison.

Configuration Manager configure automatiquement la réplication de la base de données entre les sites. Le cas échéant, il utilise des certificats PKI avec une capacité d’authentification du serveur. Si cette option n’est pas disponible, le Configuration Manager crée des certificats auto-signés pour l’authentification du serveur. Dans les deux cas, il s’authentifie entre les sites à l’aide de certificats dans le magasin Trusted People qui utilise PeerTrust. Il utilise ce magasin de certificats pour s’assurer que seuls les serveurs SQL de la hiérarchie Configuration Manager participent à la réplication site à site.

Les serveurs de site établissent une communication site à site à l’aide d’un échange de clés sécurisé qui se produit automatiquement. Le serveur du site d’envoi génère un hachage et le signe avec sa clé privée. Le serveur du site de réception vérifie la signature à l’aide de la clé publique et compare le hachage à une valeur générée localement. En cas de correspondance, le site de réception accepte les données répliquées. Si les valeurs ne correspondent pas, le Configuration Manager rejette les données de réplication.

La réplication de base de données dans Configuration Manager utilise SQL Server Service Broker pour transférer des données entre les sites. Elle utilise les mécanismes suivants :

• SQL Server vers SQL Server : Cette connexion utilise les informations d’identification Windows pour l’authentification du serveur et les certificats auto-signés avec 1024 bits pour signer et chiffrer les données avec l’algorithme AES. Le cas échéant, il utilise des certificats PKI avec une capacité d’authentification du serveur. Il utilise uniquement les certificats du magasin de certificats personnel de l’ordinateur.

• SQL Service Broker : ce service utilise des certificats auto-signés avec 2048 bits pour l’authentification et pour signer et chiffrer les données avec l’algorithme AES. Il utilise uniquement les certificats de la base de données SQL Server master.

La réplication basée sur les fichiers utilise le protocole SMB (Server Message Block). Il utilise SHA-256 pour signer les données qui ne sont pas cryptées et ne contiennent pas de données sensibles. Pour chiffrer ces données, utilisez IPsec, que vous implémentez indépendamment de Configuration Manager.

Clients qui utilisent HTTPS

Lorsque les rôles de système de site acceptent des connexions client, vous pouvez les configurer pour accepter les connexions HTTPS et HTTP, ou uniquement les connexions HTTPS. Les rôles de système de site qui acceptent les connexions à partir d’Internet acceptent uniquement les connexions client sur HTTPS.

Les connexions client sur HTTPS offrent un niveau de sécurité plus élevé en s’intégrant à une infrastructure à clé publique (PKI) pour aider à protéger les communications client-serveur. Toutefois, la configuration de connexions clientes HTTPS sans une compréhension approfondie de la planification, du déploiement et des opérations PKI peut vous rendre vulnérable. Par exemple, si vous ne sécurisez pas votre autorité de certification racine, les attaquants risquent de compromettre la confiance de l’ensemble de votre infrastructure PKI. Si vous ne déployez pas et ne gérez pas les certificats PKI à l’aide de processus contrôlés et sécurisés, les clients ne peuvent pas recevoir les mises à jour logicielles ou les packages critiques.

Communication non chiffrée lorsque les clients utilisent HTTPS

Lorsque les clients communiquent avec les systèmes de site via HTTPS, la majeure partie du trafic est chiffrée. Dans les situations suivantes, les clients communiquent avec les systèmes de site sans utiliser de chiffrement :

• Le client ne parvient pas à établir une connexion HTTPS sur l’intranet et revient à l’utilisation de HTTP lorsque les systèmes de site autorisent cette configuration.

• Communication avec les rôles de système de site suivants :

  • Le client envoie des messages d’état au point d’status de secours.

  • Le client envoie les demandes PXE à un point de distribution compatible PXE.

  • Le client envoie des données de notification à un point de gestion.

Vous configurez les points des services de rapports pour qu’ils utilisent HTTP ou HTTPS indépendamment du mode de communication du client.

Clients qui utilisent E-HTTP

Lorsque les clients utilisent la communication E-HTTP avec des rôles de système de site, ils peuvent utiliser des certificats PKI pour l’authentification du client ou des certificats auto-signés générés par le Configuration Manager. Lorsque Configuration Manager génère des certificats auto-signés, ils ont un identificateur d’objet personnalisé pour la signature et le chiffrement. Ces certificats sont utilisés pour identifier le client de manière unique. Ces certificats auto-signés utilisent SHA-256 et ont une longueur de clé de 2 048 bits.

Déploiement du système d’exploitation et certificats auto-signés

Lorsque vous utilisez Configuration Manager pour déployer des systèmes d’exploitation avec des certificats auto-signés, le client doit également avoir un certificat pour communiquer avec le point de gestion. Cette exigence s’applique même si l’ordinateur se trouve dans une phase de transition telle que le démarrage à partir d’un support de séquence de tâches ou d’un point de distribution compatible PXE. Pour prendre en charge ce scénario pour les connexions client E-HTTP, Configuration Manager génère des certificats auto-signés qui ont un identificateur d’objet personnalisé pour la signature et le chiffrement. Ces certificats sont utilisés pour identifier le client de manière unique. Ces certificats auto-signés utilisent SHA-256 et ont une longueur de clé de 2 048 bits. Si ces certificats auto-signés sont compromis, empêchez les attaquants de les utiliser pour usurper l’identité de clients approuvés. Bloquez les certificats dans le nœud Certificats de l’espace de travail Administration , nœud Sécurité .

Authentification client et serveur

Lorsque les clients se connectent via E-HTTP, ils authentifient les points de gestion à l’aide des services de domaine Active Directory ou de la clé racine approuvée du Configuration Manager. Les clients n’authentifient pas les autres rôles du système de site, tels que les points de migration d’état ou les points de mise à jour logicielle.

Lorsqu’un point de gestion authentifie un client pour la première fois à l’aide du certificat client auto-signé, ce mécanisme offre une sécurité minimale, car n’importe quel ordinateur peut générer un certificat auto-signé. Utilisez l’approbation du client pour améliorer ce processus. Approuver uniquement les ordinateurs approuvés, soit automatiquement par le Configuration Manager, soit manuellement par un utilisateur administrateur. Pour plus d’informations, voir Gérer les clients.

À propos des vulnérabilités SSL

Pour améliorer la sécurité de vos clients et serveurs Configuration Manager, procédez comme suit :

• Activez TLS 1.2 sur tous les appareils et services. Pour activer TLS 1.2 pour Configuration Manager, consultez Comment activer TLS 1.2 pour Configuration Manager.

• Désactivez SSL 3.0, TLS 1.0 et TLS 1.1.

• Réorganiser les suites de chiffrement liées à TLS.

Si vous souhaitez en savoir plus, consultez les articles suivants :

• Limiter l’utilisation de certains algorithmes et protocoles de chiffrement dans Schannel.dll
• Hiérarchiser les suites de chiffrement Schannel

Ces procédures n’affectent pas les fonctionnalités de Configuration Manager.