Planifier la sécurité dans Configuration Manager
S’applique à : Configuration Manager (branche actuelle)
Cet article décrit les concepts suivants que vous devez prendre en compte lors de la planification de la sécurité avec votre implémentation de Configuration Manager :
Certificats (auto-signés et PKI)
Clé racine approuvée
Signature et chiffrement
Administration basée sur les rôles
Identifiant Microsoft Entra
Authentification du fournisseur SMS
Avant de commencer, veillez à connaître les principes fondamentaux de la sécurité dans Configuration Manager.
Certificats
Configuration Manager utilise une combinaison de certificats numériques auto-signés et d’infrastructure à clé publique (PKI). Utilisez des certificats PKI dans la mesure du possible. Certains scénarios nécessitent des certificats PKI. Lorsque les certificats PKI ne sont pas disponibles, le site génère automatiquement des certificats auto-signés. Certains scénarios utilisent toujours des certificats auto-signés.
Pour plus d’informations, consultez Planifier des certificats.
Clé racine approuvée
La clé racine approuvée Configuration Manager fournit un mécanisme permettant aux clients Configuration Manager de vérifier que les systèmes de site appartiennent à leur hiérarchie. Chaque serveur de site génère une clé d’échange de site pour communiquer avec d’autres sites. La clé d’échange de site du site de niveau supérieur dans la hiérarchie est appelée clé racine approuvée.
La fonction de la clé racine approuvée dans Configuration Manager ressemble à un certificat racine dans une infrastructure à clé publique. Tout ce qui est signé par la clé privée de la clé racine approuvée est approuvé plus bas dans la hiérarchie. Les clients stockent une copie de la clé racine approuvée du site dans l’espace root\ccm\locationservices de noms WMI.
Par exemple, le site émet un certificat au point de gestion, qu’il signe avec la clé privée de la clé racine approuvée. Le site partage avec les clients la clé publique de sa clé racine approuvée. Les clients peuvent ensuite faire la distinction entre les points de gestion qui se trouvent dans leur hiérarchie et les points de gestion qui ne se trouvent pas dans leur hiérarchie.
Les clients obtiennent automatiquement la copie publique de la clé racine approuvée à l’aide de deux mécanismes :
Vous étendez le schéma Active Directory pour Configuration Manager et publiez le site sur les services de domaine Active Directory. Les clients récupèrent ensuite ces informations de site à partir d’un serveur de catalogue global. Pour plus d’informations, consultez Préparer Active Directory pour la publication de site.
Lorsque vous installez des clients à l’aide de la méthode d’installation push du client. Pour plus d’informations, consultez Installation push du client.
Si les clients ne peuvent pas obtenir la clé racine approuvée à l’aide de l’un de ces mécanismes, ils approuvent la clé racine approuvée fournie par le premier point de gestion avec lequel ils communiquent. Dans ce scénario, un client peut être mal dirigé vers le point de gestion d’un attaquant, où il recevrait la stratégie du point de gestion non autorisé. Cette action nécessite un attaquant sophistiqué. Cette attaque est limitée au peu de temps avant que le client récupère la clé racine approuvée à partir d’un point de gestion valide. Pour réduire ce risque qu’un attaquant redirige mal les clients vers un point de gestion non autorisé, préprovisionnez les clients avec la clé racine approuvée.
Pour plus d’informations et pour connaître les procédures de gestion de la clé racine approuvée, consultez Configurer la sécurité.
Signature et chiffrement
Lorsque vous utilisez des certificats PKI pour toutes les communications clientes, vous n’avez pas besoin de planifier la signature et le chiffrement pour sécuriser la communication des données client. Si vous configurez des systèmes de site qui exécutent IIS pour autoriser les connexions client HTTP, décidez comment sécuriser la communication cliente pour le site.
Importante
À compter de Configuration Manager version 2103, les sites qui autorisent la communication client HTTP sont déconseillés. Configurez le site pour HTTPS ou HTTP amélioré. Pour plus d’informations, consultez Activer le site pour HTTPS uniquement ou HTTP amélioré.
Pour protéger les données que les clients envoient aux points de gestion, vous pouvez demander aux clients de signer les données. Vous pouvez également exiger l’algorithme SHA-256 pour la signature. Cette configuration est plus sécurisée, mais ne nécessite pas SHA-256, sauf si tous les clients la prennent en charge. De nombreux systèmes d’exploitation prennent en charge cet algorithme en mode natif, mais les systèmes d’exploitation plus anciens peuvent nécessiter une mise à jour ou un correctif logiciel.
Alors que la signature permet de protéger les données contre la falsification, le chiffrement permet de protéger les données contre la divulgation d’informations. Vous pouvez activer le chiffrement pour les données d’inventaire et les messages d’état que les clients envoient aux points de gestion du site. Vous n’avez pas besoin d’installer de mises à jour sur les clients pour prendre en charge cette option. Les clients et les points de gestion nécessitent davantage d’utilisation du processeur pour le chiffrement et le déchiffrement.
Notes
Pour chiffrer les données, le client utilise la clé publique du certificat de chiffrement du point de gestion. Seul le point de gestion possède la clé privée correspondante. Il peut donc déchiffrer les données.
Le client démarre ce certificat avec le certificat de signature du point de gestion, qu’il démarre avec la clé racine approuvée du site. Veillez à provisionner en toute sécurité la clé racine approuvée sur les clients. Pour plus d’informations, consultez La clé racine approuvée.
Pour plus d’informations sur la configuration des paramètres de signature et de chiffrement, consultez Configurer la signature et le chiffrement.
Pour plus d’informations sur les algorithmes de chiffrement utilisés pour la signature et le chiffrement, consultez Informations de référence techniques sur les contrôles de chiffrement.
Administration basée sur les rôles
Avec Configuration Manager, vous utilisez l’administration basée sur les rôles pour sécuriser l’accès dont les utilisateurs administratifs ont besoin pour utiliser Configuration Manager. Vous sécurisez également l’accès aux objets que vous gérez, tels que les collections, les déploiements et les sites.
Avec la combinaison de rôles de sécurité, d’étendues de sécurité et de regroupements, vous séparez les affectations administratives qui répondent aux exigences de votre organisation. Utilisés ensemble, ils définissent l’étendue administrative d’un utilisateur. Cette étendue administrative contrôle les objets affichés par un utilisateur administratif dans la console Configuration Manager et contrôle les autorisations dont dispose un utilisateur sur ces objets.
Pour plus d’informations, consultez Principes de base de l’administration basée sur des rôles.
Identifiant Microsoft Entra
Configuration Manager s’intègre à l’ID Microsoft Entra pour permettre au site et aux clients d’utiliser l’authentification moderne.
Pour plus d’informations sur l’ID Microsoft Entra, consultez la documentation Microsoft Entra.
L’intégration de votre site avec l’ID Microsoft Entra prend en charge les scénarios Configuration Manager suivants :
Scénarios clients
Scénarios de serveur
Authentification du fournisseur SMS
Vous pouvez spécifier le niveau d’authentification minimal pour que les administrateurs accèdent aux sites Configuration Manager. Cette fonctionnalité impose aux administrateurs de se connecter à Windows avec le niveau requis avant de pouvoir accéder à Configuration Manager. Elle s’applique à tous les composants qui accèdent au fournisseur SMS. Par exemple, la console Configuration Manager, les méthodes du Kit de développement logiciel (SDK) et les applets de commande Windows PowerShell.
Configuration Manager prend en charge les niveaux d’authentification suivants :
Authentification Windows : exiger une authentification avec des informations d’identification de domaine Active Directory. Ce paramètre est le comportement précédent et le paramètre par défaut actuel.
Authentification par certificat : exiger l’authentification avec un certificat valide émis par une autorité de certification PKI approuvée. Vous ne configurez pas ce certificat dans Configuration Manager. Configuration Manager nécessite que l’administrateur soit connecté à Windows à l’aide de l’infrastructure À clé publique.
Authentification Windows Hello Entreprise : exiger une authentification avec une authentification à deux facteurs forte liée à un appareil et utilisant la biométrie ou un code confidentiel. Pour plus d’informations, consultez Windows Hello Entreprise.
Importante
Lorsque vous sélectionnez ce paramètre, le fournisseur sms et le service d’administration exigent que le jeton d’authentification de l’utilisateur contienne une revendication d’authentification multifacteur (MFA) de Windows Hello Entreprise. En d’autres termes, un utilisateur de la console, du SDK, de PowerShell ou du service d’administration doit s’authentifier auprès de Windows avec son code confidentiel Windows Hello Entreprise ou biométrie. Sinon, le site rejette l’action de l’utilisateur.
Ce comportement s’adresse à Windows Hello Entreprise, et non à Windows Hello.
Pour plus d’informations sur la configuration de ce paramètre, consultez Configurer l’authentification du fournisseur SMS.