Référence technique pour les contrôles cryptographiques utilisés dans Configuration Manager
S'applique à: System Center 2012 Configuration Manager, System Center 2012 Configuration Manager SP1, System Center 2012 Configuration Manager SP2, System Center 2012 R2 Configuration Manager, System Center 2012 R2 Configuration Manager SP1
Notes
Cette rubrique s'affiche dans le guide Administration de site pour System Center 2012 Configuration Manager et dans le guide Sécurité et confidentialité pour System Center 2012 Configuration Manager.
System Center 2012 Configuration Manager utilise la signature et le chiffrement pour contribuer à protéger la gestion des appareils dans la hiérarchie Configuration Manager. La signature garantit que si des données ont été modifiées en transit, les données seront ignorées. Le chiffrement empêche une personne malveillante de lire les données à l'aide d'un analyseur de protocole réseau.
L'algorithme de hachage principal utilisé par Configuration Manager pour la signature est SHA-256. Quand deux sites Configuration Manager communiquent entre eux, ils signent leurs communications à l'aide de SHA-256. L'algorithme de chiffrement principal implémenté dans Configuration Manager est 3DES. Il est utilisé pour stocker des données dans la base de données Configuration Manager et lorsque les clients communiquent à l'aide du protocole HTTP. Lorsque vous utilisez les communications client sur HTTPS, vous pouvez configurer votre infrastructure à clé publique (PKI) pour utiliser les certificats RSA avec des longueurs de clé et algorithmes de hachage maximales documentées dans Configuration requise des certificats PKI pour Configuration Manager.
Pour la plupart des opérations cryptographiques pour les systèmes d'exploitation Windows, Configuration Manager utilise les algorithmes SHA-1, SHA-2, 3DES et AES ainsi que RSA de la bibliothèque CryptoAPI de Windows, rsaenh.dll.
Utilisez les sections suivantes pour plus d'informations :
Contrôles cryptographiques pour les opérations de Configuration Manager
Certificats utilisés par Configuration Manager
Contrôles cryptographiques pour la communication du serveur
Contrôles cryptographiques pour les clients qui utilisent la communication HTTPS pour les systèmes de site
Contrôles cryptographiques pour les clients qui utilisent la communication HTTP pour les systèmes de site
Important
Afficher des informations sur les modifications recommandées en réponse aux vulnérabilités SSL dans Sur les vulnérabilités du protocole SSL.
Contrôles cryptographiques pour les opérations de Configuration Manager
Les informations contenues dans Configuration Manager peuvent être signées et chiffrées, que vous utilisiez ou non des certificats PKI avec Configuration Manager.
Signature et chiffrement de stratégie
Les affectations de stratégies client sont signées par le certificat de signature du serveur de site auto-signé afin d'éviter qu'un point de gestion compromis envoie des stratégies qui ont été falsifiées, ce qui présenterait un risque de sécurité. Cette sécurité est particulièrement utile lorsque vous utilisez la gestion des clients Internet. En effet, cet environnement exige un point de gestion exposé aux communications sur Internet.
La stratégie est chiffrée à l'aide de 3DES lorsqu'elle contient des données sensibles. Une stratégie qui contient des données sensibles est envoyée aux clients autorisés uniquement. Une stratégie qui ne contient pas de données sensibles n'est pas chiffrée.
Lorsque la stratégie est stockée sur les clients, elle est chiffrée à l'aide d'une interface de programmation d'applications de protection des données (DPAPI).
Hachage de stratégie
Lorsque les clients Configuration Manager demandent une stratégie, ils commencent par se procurer l'attribution d'une stratégie de sorte qu'ils sachent quelles stratégies s'appliquent à eux. Ils ne demandent ensuite que le corps de ces stratégies. Chaque attribution de stratégie contient le hachage calculé pour le corps de la stratégie correspondante. Le client récupère les corps des stratégies applicables, puis il calcule le hachage de ce corps. Si le hachage du corps de la stratégie téléchargée ne correspond pas à celui de l'attribution de la stratégie, le client annule le corps de la stratégie.
L'algorithme de hachage pour la stratégie est SHA-1 et SHA-256.
Hachage du contenu
Le service du Gestionnaire de distributions sur le serveur de site hache les fichiers 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 été altéré et le client installe le logiciel. Si un seul octet du contenu a été altéré, les hachages ne correspondront pas et le logiciel ne sera pas installé. Cette vérification permet de s'assurer que le logiciel correct est installé, car son contenu réel fait l'objet d'une contre-vérification avec la stratégie.
L'algorithme de hachage par défaut pour le contenu est SHA-256. Pour modifier ce paramètre par défaut, consultez la documentation relative au Kit de développement logiciel (SDK) Configuration Manager.
Tous les appareils ne prennent pas en charge le hachage du contenu. C'est notamment le cas des clients suivants :
Clients Windows diffusant du contenu App-V.
Clients Windows Phone : ces clients vérifient toutefois la signature d'une application qui est signée par une source approuvée.
Clients Windows RT : ces clients vérifient toutefois la signature d'une application signée par une source approuvée et utilisent également la validation du nom complet du package.
iOS : ces clients vérifient toutefois la signature d'une application qui est signée par un certificat de développeur issu d'une source approuvée.
Clients Nokia : ces clients vérifient toutefois la signature d'une application qui utilise un certificat auto-signé ou la signature d'un certificat issu d'une source approuvée, pour que le certificat puisse signer les applications Nokia Symbian Installation Source (SIS).
Android. En outre, ces appareils n'utilisent pas la validation de signature pour l'installation des applications.
Clients qui s'exécutent sur des versions de Linux et UNIX qui ne prennent pas en charge SHA-256. Pour plus d'informations, voir la section Sur Linux et les systèmes d'exploitation UNIX que ne faire pas prise en charge de SHA-256 dans la rubrique Planification du déploiement du Client pour les serveurs Linux et UNIX.
Signature et chiffrement d'inventaire
L'inventaire que les clients envoient aux points de gestion est toujours signé par les appareils, qu'ils communiquent ou non avec les points de gestion via HTTP ou HTTPS. S'ils utilisent le protocole HTTP, vous pouvez choisir de chiffrer ces données, ce qui constitue une meilleure pratique de sécurité.
Chiffrement de la migration d'état
Les données stockées sur les points de migration d'état pour le déploiement de système d'exploitation sont toujours chiffrées par l'Outil de migration utilisateur (USMT) en utilisant l'algorithme 3DES.
Chiffrement pour les packages multidiffusion pour déployer des systèmes d'exploitation
Pour chaque package de déploiement de système d'exploitation, vous pouvez activer le chiffrement lorsque le package est transféré vers des ordinateurs à l'aide de la multidiffusion. Le chiffrement utilise la norme AES (Advanced Encryption Standard). Si vous activez le chiffrement, aucune configuration de certificat supplémentaire n'est nécessaire. Le point de distribution multidiffusion génère automatiquement des clés symétriques pour le chiffrement du package. Chaque package possède une clé de chiffrement qui lui est propre. La clé est stockée sur le point de distribution multidiffusion à l'aide des API Windows standard. Lorsque le client se connecte à la session de multidiffusion, l'échange de clé se produit sur un canal chiffré, soit avec le certificat d'authentification de client émis par l'infrastructure à clé publique (lorsque le client utilise le protocole HTTPS), soit avec le certificat auto-signé (lorsque le client utilise le protocole HTTP). Le client stocke la clé en mémoire uniquement pendant la durée d'ouverture de la session de multidiffusion.
Chiffrement pour le support pour déployer des systèmes d'exploitation
Lorsque vous utilisez un support pour déployer des systèmes d'exploitation et spécifier un mot de passe pour protéger le support, les variables d'environnement sont chiffrées à l'aide de la norme AES (Advanced Encryption Standard). Les autres données sur le support, y compris les packages et le contenu pour les applications, ne sont pas chiffrées.
Chiffrement du contenu hébergé sur des points de distribution cloud
À compter de System Center 2012 Configuration Manager SP1, lorsque vous utilisez des points de distribution cloud, le contenu que vous téléchargez vers ces points de distribution est chiffré en utilisant l'algorithme AES (Advanced Encryption Standard) et une taille de clé de 256 bits. Le contenu est de nouveau chiffré à chaque fois que vous le mettez à jour. Lorsque des clients téléchargent le contenu, celui-ci est chiffré et protégé par la connexion HTTPS.
Signature dans les mises à jour logicielles
Toutes les mises à jour logicielles doivent être signées par un éditeur approuvé pour les protéger contre les altérations. Sur les ordinateurs clients, l'Agent Windows Update (WUA) analyse les mises à jour du catalogue, mais n'installe pas la mise à jour s'il ne parvient pas à localiser le certificat numérique dans le magasin des éditeurs approuvés, sur l'ordinateur local. Si un certificat auto-signé a été utilisé pour la publication du catalogue de mises à jour, comme par exemple des éditeurs WSUS auto-signés, le certificat doit également se trouver dans le magasin de certificats des autorités de certification racine approuvées, sur l'ordinateur local, pour vérifier la validité du certificat. WUA vérifie également si le paramètre Autoriser le contenu signé de la stratégie de groupe d'emplacement des services de mise à jour Microsoft sur l'intranet 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 à l'aide de l'éditeur de mises à jour.
Lorsque les mises à jour logicielles sont publiées dans l'éditeur de mises à jour System Center, un certificat numérique signe les mises à jour logicielles quand elles sont publiées sur un serveur de mise à jour. Vous pouvez soit spécifier un certificat PKI, soit laisser l'éditeur de mises à jour générer un certificat auto-signé pour signer la mise à jour logicielle.
Données de configuration signées pour les paramètres de conformité
Lorsque vous importez des données de configuration, Configuration Manager vérifie la signature numérique du fichier. Si les fichiers n'ont pas été signés, ou si la vérification de la signature numérique échoue, vous recevrez un avertissement et serez invité à continuer l'importation. Ne poursuivez l'importation des données de configuration que si vous faites explicitement confiance à l'éditeur et si vous êtes certain de l'intégrité des fichiers.
Chiffrement et hachage pour la notification du client
Si vous utilisez la notification du client, toutes les communications utilisent le protocole TLS et le niveau de chiffrement le plus élevé que le serveur et les systèmes d'exploitation clients peuvent négocier. Par exemple, un ordinateur client exécutant Windows 7 et un point de gestion exécutant Windows Server 2008 R2 peuvent prendre en charge le chiffrement AES 128 bits, tandis qu'un ordinateur client exécutant Vista et communiquant avec le même point de gestion négociera seulement un chiffrement 3DES. La même négociation se produit lors du hachage des paquets transférés lors de la notification du client, qui utilise l'algorithme SHA-1 ou SHA-2.
Certificats utilisés par Configuration Manager
Pour obtenir la liste des certificats d'infrastructure à clé publique (PKI) qui peuvent être utilisés par Configuration Manager, les exigences ou limitations particulières et comment les certificats sont utilisés, voir Configuration requise des certificats PKI pour Configuration Manager. Cette liste inclut les longueurs de clé et les algorithmes de hachage pris en charge. La plupart des certificats prennent en charge l'algorithme SHA-256 et la longueur de clé 2 048 bits.
Notes
Le nom d'objet ou l'autre nom d'objet des certificats utilisés par Configuration Manager doit contenir uniquement des caractères codés sur un octet.
Les certificats PKI sont requis pour les scénarios suivants :
Lorsque vous gérez des clients Configuration Manager sur Internet.
Lorsque vous gérez des clients Configuration Manager sur des appareils mobiles.
Lorsque vous gérez des ordinateurs Mac.
Lorsque vous utilisez des points de distribution cloud.
Lorsque vous gérez des ordinateurs Intel AMT hors bande.
Pour la plupart des autres communications Configuration Manager nécessitant des certificats pour l'authentification, la signature ou le chiffrement, Configuration Manager utilise automatiquement les certificats PKI s'ils sont disponibles. Dans le cas contraire, Configuration Manager génère des certificats auto-signés.
Configuration Manager n'utilise pas de certificats PKI lorsqu'il gère des appareils mobiles à l'aide du connecteur Exchange Server.
Gestion d'appareils mobiles et certificats PKI
Si l'appareil mobile n'a pas été verrouillé par l'opérateur mobile, vous pouvez utiliser Configuration Manager ou Microsoft Intunepour demander et installer un certificat client. Ce certificat fournit une authentification mutuelle entre le client de l'appareil mobile et les systèmes de site Configuration Manager ou les services Microsoft Intune. Si l'appareil mobile est verrouillé, vous ne pouvez pas utiliser Configuration Manager ou Intune pour déployer des certificats. Pour plus d'informations, voir Comment installer des clients sur des appareils Windows Mobile et Nokia Symbian en utilisant Configuration Manager.
Si vous activez l'inventaire matériel des appareils mobiles, Configuration Manager ou Intune inventorie également les certificats qui sont installés sur l'appareil mobile.
Gestion hors bande et certificats PKI
La gestion hors bande pour les ordinateurs Intel AMT utilise au moins deux types de certificats émis par l'infrastructure à clé publique : un certificat de configuration AMT et un certificat de serveur web.
Le point de service hors bande utilise un certificat de configuration AMT pour préparer les ordinateurs à la gestion hors bande. Les ordinateurs AMT à configurer doivent approuver le certificat présenté par le point de gestion hors bande. Par défaut, les ordinateurs basés sur AMT sont configurés par le fabricant de sorte qu'ils utilisent des autorités de certification externes, telles que VeriSign, Go Daddy, Comodo et Starfield. Si vous achetez un certificat de configuration auprès d'une autorité de certification externe et configurez Configuration Manager pour qu'il utilise ce certificat de configuration, les ordinateurs basés sur AMT approuveront l'autorité de certification du certificat de configuration et la configuration pourra être effectuée. Toutefois, l'emploi de votre propre autorité de certification interne pour l'émission du certificat de configuration AMT est une pratique de sécurité recommandée. Pour plus d'informations, voir Meilleures pratiques de sécurité pour la gestion hors bande.
Les ordinateurs AMT exécutent un composant de serveur Web dans leur microprogramme et ce composant de serveur Web chiffre le canal de communication avec le point de service hors bande à l'aide du protocole TLS (Transport Layer Security). Il n'existe pas d'interface utilisateur dans le BIOS AMT qui permette de configurer un certificat manuellement. Vous devez donc disposer d'une autorité de certification d'entreprise Microsoft qui approuve automatiquement les requêtes de certificat émanant d'ordinateurs AMT. La requête utilise le fichier PKCS#10 pour le format de requête, lequel utilise à son tour le fichier PKCS#7 pour transmettre les informations relatives au certificat à l'ordinateur AMT.
Même si l'ordinateur AMT est authentifié auprès de l'ordinateur qui le gère, ce dernier ne possède pas de certificat client PKI correspondant. À la place, ces communications utilisent l'authentification Kerberos ou l'authentification HTTP Digest. Lorsque HTTP Digest est utilisé, il est chiffré à l'aide de TLS.
Un type de certificat supplémentaire peut être nécessaire pour la gestion des ordinateurs AMT hors bande : un certificat client facultatif pour les réseaux sans fil et les réseaux câblés authentifiés 802.1X. Un certificat client peut être requis par l'ordinateur basé sur AMT en vue de son authentification auprès du serveur RADIUS. Lorsque le serveur RADIUS est configuré pour l'authentification EAP-TLS, un certificat client est toujours nécessaire. Lorsque le serveur RADIUS est configuré pour l'authentification EAP-TTLS/MSCHAPv2 ou PEAPv0/EAP-MSCHAPv2, la configuration RADIUS indique si un certificat client est nécessaire ou non. Ce certificat est demandé par l'ordinateur AMT en utilisant les mêmes processus que la demande de certificat de serveur Web.
Déploiement de système d'exploitation et certificats PKI
Lorsque vous utilisez Configuration Manager pour déployer des systèmes d'exploitation et un point de gestion qui nécessite des connexions client HTTPS, l'ordinateur client doit également posséder un certificat pour communiquer avec le point de gestion, même s'il se trouve dans une phase de transition telle que le démarrage depuis le média de séquence de tâches ou un point de distribution PXE. Pour la prise en charge de ce scénario, vous devez créer un certificat d'authentification de client PKI, l'exporter avec la clé privée, puis l'importer vers les propriétés du serveur de site. Ajoutez également le certificat de l'autorité de certification racine approuvée du point de gestion.
Si vous créez un média de démarrage, vous importez le certificat d'authentification du client lors de la création du média de démarrage. Configurez un mot de passe sur le support de démarrage pour protéger la clé privée et les autres données sensibles configurées dans la séquence de tâches. Chaque ordinateur qui démarre depuis le support de démarrage présentera le même certificat au point de gestion que celui requis pour les fonctions de clients telles que la demande de stratégies client.
Si vous utilisez le démarrage PXE, vous importez le certificat d'authentification du client vers le point de distribution PXE, et il utilise le même certificat pour tous les clients démarrant à partir de ce point de distribution PXE. Une meilleure pratique de sécurité exige que les utilisateurs qui connectent leurs ordinateurs à un service PXE fournissent un mot de passe dans le but de protéger la clé privée et d'autres données sensibles dans les séquences de tâches.
Si l'un de ces certificats d'authentification client est compromis, bloquez les certificats dans le nœud Certificats de l'espace de travail Administration, nœud Sécurité. Pour gérer ces certificats, vous devez disposer du droit Gérer un certificat de déploiement de système d'exploitation.
Une fois le système d'exploitation déployé et le Configuration Manager installé, le client a besoin de son propre certificat d'authentification client PKI pour les communications client HTTPS.
Solutions proxy ISV et certificats PKI
Les éditeurs de logiciels indépendants (ISV) peuvent créer des applications qui étendent Configuration Manager. Par exemple, un éditeur de logiciels indépendant peut créer des extensions pour la prise en charge de plates-formes clientes autres que Windows, comme les ordinateurs Macintosh ou UNIX. Toutefois, si les systèmes de site nécessitent des connexions clientes HTTPS, ces clients doivent également utiliser des certificats PKI pour communiquer avec le site.Configuration Manager offre la possibilité d'affecter un certificat au proxy ISV qui autorise les communications entre les clients de proxy ISV et le point de gestion. Si vous utilisez des extensions qui nécessitent des certificats de proxy ISV, consultez la documentation de ce produit. Pour plus d'informations sur la création de certificats proxy d'éditeurs de logiciels, consultez le kit du développeur de logiciels (SDK) Configuration Manager.
Si le certificat ISV est compromis, bloquez le certificat dans le nœud Certificats de l'espace de travail Administration, nœud Sécurité.
Asset Intelligence et certificats
Configuration Manager s'installe avec un certificat X.509 que le point de synchronisation Asset Intelligence utilise pour se connecter à Microsoft.Configuration Manager utilise ce certificat pour demander un certificat d'authentification client au service de certificats Microsoft. Le certificat d'authentification du client est installé sur le serveur du système de site du point de synchronisation Asset Intelligence. Il est utilisé pour authentifier le serveur auprès de Microsoft. Configuration Manager utilise le certificat d'authentification client pour télécharger le catalogue Asset Intelligence et télécharger des logiciels.
La longueur de clé de ce certificat est de 1024 bits.
Points de distribution cloud et certificats
À compter de System Center 2012 Configuration Manager SP1, les points de distribution cloud nécessitent un certificat de gestion (auto-signé ou PKI) que vous téléchargez vers Microsoft Azure. Ce certificat de gestion nécessite une fonctionnalité d'authentification du serveur et une longueur de clé de certificat de 2 048 bits. En outre, vous devez configurer un certificat de service pour chaque point de distribution cloud. Il ne peut pas être auto-signé, mais il doit également disposer d'une fonctionnalité d'authentification du serveur et d'une clé de certificat de 2 048 bits.
Notes
Le certificat de gestion auto-signé sert uniquement aux tests et n'est pas destiné à être utilisé sur des réseaux de production.
Les clients ne nécessitent pas un certificat PKI de client pour utiliser des points de distribution cloud. Ils s'authentifient auprès de l'infrastructure de gestion à l'aide d'un certificat auto-signé ou d'un certificat PKI de client. Le point de gestion envoie ensuite un jeton d'accès Configuration Manager au client et ce dernier le présente au point de distribution cloud. Le jeton reste valide pendant huit heures.
Connecteur Microsoft Intune et certificats
Lorsque Microsoft Intune inscrit des appareils mobiles, vous pouvez gérer ces appareils dans Configuration Manager en créant un connecteur Microsoft Intune. Le connecteur utilise un certificat PKI disposant d'une fonctionnalité d'authentification du client pour authentifier Configuration Manager auprès de Microsoft Intune et transférer toutes les informations ainsi échangées à l'aide du protocole SSL. La taille de la clé de certificat est de 2 048 bits et elle utilise l'algorithme de hachage SHA-1.
Lorsque vous installez le connecteur, un certificat de signature est créé et stocké sur le serveur de site pour les clés de chargement de version test et un certificat de chiffrement est créé et stocké sur le point d'enregistrement de certificat pour chiffrer la demande d'accès du protocole d'inscription du certificat simple (SCEP). Ces certificats ont aussi une taille de clé de 2 048 bits et utilisent l'algorithme de hachage SHA-1.
Lorsque Intune inscrit des appareils mobiles, il installe un certificat PKI sur ces appareils. Ce certificat possède une fonctionnalité d'authentification de client et utilise une taille de clé de 2 048 bits ainsi que l'algorithme de hachage SHA-1.
Ces certificats PKI sont automatiquement demandés, générés et installés par Microsoft Intune.
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 surcharge administrative et de traitement, mais elle est plus sécurisée. Toutefois, si la vérification de la liste de révocation des certificats est activée alors que la liste de révocation des certificats est inaccessible, la connexion PKI échoue. Pour plus d'informations, voir la section Planification de la révocation de certificats PKI dans la rubrique Planification de la sécurité dans Configuration Manager.
La vérification de la liste de révocation des certificats est activée par défaut dans les services Internet (IIS). Par conséquent, si vous utilisez une liste de révocation des certificats avec votre déploiement PKI, aucune configuration supplémentaire n'est requise sur la majorité des systèmes de site Configuration Manager qui exécutent les services Internet. L'exception concerne les mises à jour logicielles, qui nécessitent une étape manuelle pour activer la vérification de la liste de révocation des certificats afin de vérifier les signatures des fichiers de mises à jour logicielles.
La vérification de la liste de révocation des certificats est activée par défaut pour les ordinateurs client lorsqu'ils utilisent des connexions client HTTPS. La vérification de la liste de révocation des certificats n'est pas activée par défaut lorsque vous exécutez la console de gestion hors bande pour vous connecter à un ordinateur AMT, et vous pouvez activer cette option. Vous ne pouvez pas désactiver la vérification de la liste de révocation des certificats pour les clients installés sur des ordinateurs Mac dans Configuration Manager SP1 ou version ultérieure.
La vérification de la liste de révocation des certificats n'est pas prise en charge pour les connexions suivantes dans Configuration Manager :
Connexions serveur à serveur.
Appareils mobiles inscrits par Configuration Manager.
Appareils mobiles inscrits par Microsoft Intune.
Contrôles cryptographiques pour la communication du serveur
Configuration Manager utilise les contrôles cryptographiques suivants pour la communication du 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 vers les autres systèmes de site du 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 de 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 ce type de communication, si un certificat PKI disposant d'une fonctionnalité d'authentification de serveur est disponible, Configuration Manager l'utilise automatiquement. Dans le cas contraire, Configuration Manager génère un certificat auto-signé. Ce certificat auto-signé a une capacité d'authentification serveur, utilise l'algorithme SHA-256 et a une longueur de clé de 2048 bits.Configuration Manager copie le certificat dans le magasin Personnes autorisées 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 s'approuver mutuellement à l'aide de 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 instances de rôle de système de site dans le même site, ils partagent le même certificat. Par exemple, vous pouvez disposer de plusieurs points de gestion ou de plusieurs points d'inscription dans le même site. Ce certificat auto-signé utilise également l'algorithme SHA-256 et sa longueur de clé est de 2 048 bits. Il est également copié dans le magasin Personnes autorisées sur des serveurs de système de site qui pourront avoir besoin de l'approuver. Les rôles de système de site suivants génèrent ce certificat :
Point de service Web du catalogue des applications
Point du site web du catalogue des applications
Point de synchronisation Asset Intelligence
Point d'enregistrement de certificat
Point Endpoint Protection
Point d'inscription
Point d'état de secours
Point de gestion
Point de distribution multidiffusion
Point de service hors bande
Point de Reporting Services
Point de mise à jour logicielle
Point de migration d'état
Point du programme de validation d'intégrité système
Connecteur Microsoft Intune
Ces certificats sont gérés automatiquement par Configuration Manager et, le cas échéant, générés automatiquement.
Configuration Manager utilise également un certificat d'authentification du client pour envoyer des messages d'état du point de distribution vers le point de gestion. Lorsque le point de gestion est configuré pour les connexions client HTTPS uniquement, vous devez utiliser un certificat PKI. Si le point de gestion accepte les connexions HTTP, vous pouvez utiliser un certificat PKI ou choisir d'utiliser un certificat auto-signé qui possède la possibilité d'authentification client, utilise l'algorithme SHA-256 et dont la longueur de clé est de 2 048 bits.
Communication du serveur entre 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 les fichiers. Pour plus d'informations, voir Référence technique pour les communications entre sites dans Configuration Manager.
Configuration Manager configure automatiquement la réplication de base de données entre sites et utilise des certificats PKI qui offrent la possibilité d'authentification serveur s'ils sont disponibles. Dans le cas contraire, Configuration Manager crée des certificats auto-signés pour l'authentification serveur. Dans les deux cas, l'authentification entre sites est établie à l'aide de certificats dans le magasin Personnes autorisées qui utilise PeerTrust. Ce magasin de certificats est utilisé pour garantir que seuls les ordinateurs SQL Server qui sont utilisés par la hiérarchie Configuration Manager participent à la réplication entre sites. Tandis que les sites principaux et le site d'administration centrale peuvent répliquer des modifications de configuration vers tous les sites de la hiérarchie, les sites secondaires peuvent répliquer les modifications de configuration uniquement vers leur site parent.
Les serveurs de site établissent une communication entre sites à l'aide d'un échange de clé sécurisé qui s'effectue automatiquement. Le serveur de site émetteur génère un hachage et le signe avec sa clé privée. Le serveur de site récepteur vérifie la signature en utilisant la clé publique et compare le hachage à la valeur générée localement. Si les valeurs correspondent, le site récepteur accepte les données répliquées. Si les valeurs ne correspondent pas, Configuration Manager rejette les données de réplication.
La réplication de base de données dans Configuration Manager utilise Service Broker SQL Server pour transférer des données entre sites à l'aide des mécanismes suivants :
Connexion SQL Server à SQL Server : cette connexion utilise des informations d'identification Windows pour l'authentification serveur et des certificats auto-signés 1 024 bits pour signer et chiffrer les données à l'aide de la norme AES (Advanced Encryption Standard). Si les certificats PKI avec la possibilité d'authentification serveur sont disponibles, ils seront utilisés. Le certificat doit se trouver dans le magasin Personnel pour le magasin de certificats Ordinateur.
SQL Service Broker : il utilise des certificats auto-signés avec 2 048 bits pour l'authentification et pour signer et chiffrer les données à l'aide de la norme AES (Advanced Encryption Standard). Le certificat doit se trouver dans la base de données principale SQL Server.
La réplication basée sur des fichiers utilise le protocole SMB (Server Message Block) et l'algorithme SHA-256 pour signer les données qui ne sont pas chiffrées mais elle ne contient aucune donnée sensible. Si vous souhaitez chiffrer ces données, vous pouvez utiliser IPsec et vous devez implémenter cette procédure indépendamment de Configuration Manager.
Contrôles cryptographiques pour les clients qui utilisent la communication HTTPS pour les systèmes de site
Lorsque les rôles de système de site acceptent les connexions client, vous pouvez les configurer pour accepter les connexions HTTP et HTTPS, 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 via HTTPS.
Les connexions client via HTTPS offrent un niveau de sécurité plus élevé grâce à l'intégration avec une infrastructure à clé publique (PKI) pour protéger la communication client-serveur. Cependant, si vous configurez les connexions client HTTPS sans une connaissance approfondie de la planification, du déploiement et des opérations d'une infrastructure à clé publique, un certain risque persiste. Par exemple, si vous ne sécurisez pas votre autorité de certification racine, des personnes malveillantes sont susceptibles de compromettre la fiabilité de l'ensemble de votre infrastructure à clé publique. Le fait de ne pas parvenir à déployer et à gérer les certificats d'infrastructure à clé publique à l'aide de processus contrôlés et sécurisés peut aboutir à des clients non gérés qui ne peuvent pas recevoir de mises à jour logicielles critiques ou de packages.
Important
Les certificats PKI qui sont utilisés pour la communication client protègent la communication uniquement entre le client et certains systèmes de site. Ils ne protègent pas le canal de communication entre le serveur de site et les systèmes de site ou entre des serveurs de site.
Communication qui n'est pas chiffrée lorsque les clients utilisent la communication HTTPS
Lorsque les clients communiquent avec des systèmes de site à l'aide du protocole HTTPS, les communications sont généralement chiffrées via le protocole SSL. Cependant, dans les cas suivants, les clients communiquent avec les systèmes de site sans recourir au chiffrement :
le client ne parvient pas à effectuer une connexion HTTPS sur l'Intranet et revient à utiliser le protocole HTTP lorsque les systèmes de site autorisent cette configuration
Communication vers les rôles de système de site suivants :
le client envoie des messages d'état au point d'état de secours
le client envoie des demandes PXE à un point de distribution compatible PXE
Le client envoie les données de notification à un point de gestion
Les points Reporting services sont configurés pour utiliser HTTP ou HTTPS, indépendamment du mode de communication client.
Contrôles cryptographiques pour les clients qui utilisent la communication HTTP pour les systèmes de site
Lorsque les clients utilisent la communication HTTP vers des rôles de système de site, ils peuvent utiliser les certificats PKI pour l'authentification client ou les certificats auto-signés que Configuration Manager génère. Quand Configuration Manager génère des certificats auto-signés, ceux-ci ont un identificateur d'objet personnalisé pour la signature et le chiffrement et ces certificats permettent d'identifier le client de façon unique. Pour tous les systèmes d'exploitation pris en charge sauf Windows Server 2003, ces certificats auto-signés utilisent SHA-256 et ont une longueur de clé de 2 048 bits. Pour Windows Server 2003, SHA1 est utilisé avec une longueur de clé de 1 024 bits.
Déploiement de 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, un ordinateur client doit également posséder un certificat pour communiquer avec le point de gestion, même si l'ordinateur se trouve dans une phase de transition telle que le démarrage depuis le média de séquence de tâches ou un point de distribution PXE. Pour prendre en charge ce scénario pour les connexions client HTTP, Configuration Manager génère des certificats auto-signés qui ont un identificateur d'objet personnalisé pour la signature et le chiffrement et ces certificats permettent d'identifier le client de façon unique. Pour tous les systèmes d'exploitation pris en charge sauf Windows Server 2003, ces certificats auto-signés utilisent SHA-256 et ont une longueur de clé de 2 048 bits. Pour Windows Server 2003, SHA1 est utilisé avec une longueur de clé de 1 024 bits. Si ces certificats auto-signés sont compromis, afin d'empêcher les intrus de les utiliser pour emprunter l'identité des 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 HTTP, ils authentifient les points de gestion à l'aide des services de domaine Active Directory ou à l'aide de la clé racine approuvée de Configuration Manager. Les clients n'authentifient pas d'autres rôles de système de site, comme les points de migration de l'état ou les points de mise à jour logicielle.
Lorsqu'un point de gestion authentifie un client pour la première fois en utilisant le certificat auto-signé du client, ce mécanisme offre une sécurité minimale car n'importe quel ordinateur peut générer un certificat auto-signé. Dans ce scénario, le processus d'identité client doit être complété par une approbation. Seuls les ordinateurs approuvés doivent obtenir cette approbation, soit automatiquement par Configuration Manager soit manuellement par un utilisateur administratif. Pour plus d'informations, voir la section sur l'approbation dans la rubrique Communications initiées par les Clients.
Sur les vulnérabilités du protocole SSL
Nous vous recommandons de désactiver le protocole SSL 3.0, d'activer la sécurité TLS 1.1 et 1.2, et de réorganiser les suites de chiffrement en rapport avec TLS pour améliorer la sécurité de vos serveurs Configuration Manager. Pour découvrir comment effectuer ces actions, consultez cet article de la Base de connaissances. Cette action n'affecte pas les fonctionnalités de Configuration Manager.