Planifier la sécurité dans le Configuration Manager

S’applique à : Configuration Manager (branche actuelle)

Cet article décrit les concepts suivants à prendre en compte lors de la planification de la sécurité avec votre implémentation de Configuration Manager :

  • Certificats (auto-signés et PKI)

  • La clé racine approuvée

  • Signature et chiffrement

  • Administration basée sur les rôles

  • Identifiant Microsoft Entra

  • Authentification du fournisseur SMS

Avant de commencer, assurez-vous de bien connaître les principes de base de la sécurité dans Configuration Manager.

Certificats

Configuration Manager utilise une combinaison de certificats numériques d’infrastructure à clé publique (PKI) auto-signés. 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 les certificats.

La clé racine approuvée

La clé racine approuvée du Configuration Manager fournit un mécanisme permettant aux clients de 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 pour le 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 alors faire la différence entre les points de gestion qui sont dans leur hiérarchie et les points de gestion qui ne sont 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. Ensuite, les clients récupèrent ces informations de site à partir d’un serveur de catalogue global. Pour plus d’informations, voir Préparer Active Directory pour la publication de sites.

  • Lorsque vous installez des clients à l’aide de la méthode d’installation par envoi de client push. Pour plus d’informations, voir 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 font confiance à la clé racine approuvée fournie par le premier point de gestion avec lequel ils communiquent. Dans ce scénario, un client peut être dirigé par erreur vers le point de gestion d’un attaquant où il recevrait la stratégie du point de gestion non autorisé. Pour effectuer cette action, un attaquant sophistiqué est nécessaire. Cette attaque est limitée au court laps de temps avant que le client ne récupère la clé racine de confiance à partir d’un point de gestion valide. Pour réduire le risque qu’un attaquant dirige les clients vers un point de gestion non autorisé, pré-approvisionnez les clients avec la clé racine approuvée.

Pour plus d’informations et pour suivre 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 client, 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 de la manière de sécuriser la communication client pour le site.

Importante

À compter de la version 2103 de Configuration Manager, 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 exiger des clients qu’ils signent 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 le 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.

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 messages de données et 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 une utilisation plus importante du processeur pour le chiffrement et le déchiffrement.

Remarque

Pour chiffrer les données, le client utilise la clé publique du certificat de chiffrement du point de gestion. Seul le point de gestion a la clé privée correspondante, donc lui seul peut déchiffrer les données.

Le client amorce ce certificat avec le certificat de signature du point de gestion, qu’il démarre avec la clé racine approuvée du site. Assurez-vous de provisionner en toute sécurité la clé racine approuvée sur les clients. Pour plus d’informations, consultez La clé racine de confiance.

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 techniques de référence sur les contrôles de chiffrement.

Administration basée sur les rôles

Avec le 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 le 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.

En combinant les rôles de sécurité, les étendues de sécurité et les regroupements, vous séparez les affectations administratives qui répondent aux besoins de votre organisation. Utilisés conjointement, ils définissent l’étendue administrative d’un utilisateur. Cette étendue d’administration contrôle les objets qu’un utilisateur administratif voit dans la console du gestionnaire de Configuration Manager et contrôle les autorisations dont un utilisateur dispose 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 est intégré à Microsoft Entra ID pour permettre au site et aux clients d’utiliser l’authentification moderne.

Pour plus d’informations sur Microsoft Entra ID, consultez la documentation de Microsoft Entra.

L’intégration de votre site avec Microsoft Entra ID prend en charge les scénarios de Configuration Manager suivants :

Scénarios client

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é oblige les administrateurs à 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 du Configuration Manager, les méthodes du Kit de développement logiciel (SDK) et les applets de commande de Windows PowerShell.

Configuration Manager prend en charge les niveaux d’authentification suivants :

  • Authentification Windows : exiger l’authentification avec les 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 : exigez une authentification avec un certificat valide émis par une autorité de certification PKI approuvée. Vous ne configurez pas ce certificat dans le Configuration Manager. Configuration Manager requiert que l’administrateur soit connecté à Windows à l’aide de PKI.

  • Authentification Windows Hello Entreprise : exiger une authentification avec une authentification forte à deux facteurs 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 PIN Windows Hello Entreprise ou biométrique. Dans le cas contraire, le site rejette l’action de l’utilisateur.

    Ce comportement concerne 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.

Étapes suivantes

  • Last updated on