Planifier la sécurité dans Configuration Manager

Mises à jour vers Configuration Manager (Current Branch)

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

  • Certificats (auto-signés et PKI)

  • Clé racine de confiance

  • Signature et chiffrement

  • Administration basée sur les rôles

  • Azure Active Directory

  • Authentification du fournisseur de SMS

Avant de commencer, assurez-vous que vous êtes familiarisé avec 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 autant que 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, voir Planifier les certificats.

Clé racine de confiance

La clé racine de confiance 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 sites 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 de confiance.

La fonction de la clé racine de confiance 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 de confiance est approuvé plus loin dans la hiérarchie. Les clients stockent une copie de la clé racine de confiance du site dans root\ccm\locationservices l’espace de noms WMI.

Par exemple, le site émettra un certificat au point de gestion, qu’il signe avec la clé privée de la clé racine de confiance. Le site partage avec les clients la clé publique de sa clé racine de confiance. Ensuite, les clients peuvent faire la différence entre les points de gestion qui se 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 de confiance à l’aide de deux mécanismes :

  • Vous étendez le schéma Active Directory pour Configuration Manager et publiez le site dans 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 Push client. Pour plus d’informations, voir Installation push du client.

Si les clients ne peuvent pas obtenir la clé racine de confiance à l’aide de l’un de ces mécanismes, ils font confiance à la clé racine de confiance fournie par le premier point de gestion avec qui ils communiquent. Dans ce scénario, un client peut être dirigé de manière erronée vers le point de gestion d’un attaquant où il reçoit la stratégie du point de gestion non malveillant. Cette action nécessite une attaque sophistiquée. Cette attaque est limitée au peu de temps avant que le client récupère la clé racine de confiance à partir d’un point de gestion valide. Pour réduire ce risque qu’un attaquant a mal dirigé les clients vers un point de gestion non fiable, pré-provisionnez les clients avec la clé racine de confiance.

Pour plus d’informations et de procédures pour gérer la clé racine de confiance, voir 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 avez installé des systèmes de site qui exécutent IIS pour autoriser les connexions client HTTP, décidez comment sécuriser la communication client pour le site.

Important

À compter de configuration Manager version 2103, les sites qui autorisent la communication client HTTP sont supprimés. Configurez le site pour HTTPS ou Http amélioré. Pour plus d’informations, voir 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 la prise en charge. De nombreux systèmes d’exploitation utilisent cet algorithme en mode natif, mais les systèmes d’exploitation plus anciens peuvent nécessiter une mise à jour ou un correctif logiciel.

Bien que la signature contribue à protéger les données contre la falsification, le chiffrement contribue à 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 plus 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, donc seul il peut 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 de confiance du site. Veillez à mettre en service en toute sécurité la clé racine de confiance sur les clients. Pour plus d’informations, voir La clé racine de confiance.

Pour plus d’informations sur la configuration des paramètres de signature et de chiffrement, voir Configurer la signature et le chiffrement.

Pour plus d’informations sur les algorithmes de chiffrement utilisés pour la signature et le chiffrement, consultez la référence technique des 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 d’administration ont besoin pour utiliser Configuration Manager. Vous sécurisationz é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 collections, vous séparez les affectations administratives qui répondent aux besoins de votre organisation. Utilisés ensemble, ils définissent l’étendue administrative d’un utilisateur. Cette étendue administrative contrôle les objets qu’un utilisateur d’administration voit 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.

Azure Active Directory

Configuration Manager s’intègre à Azure Active Directory (Azure AD) pour permettre au site et aux clients d’utiliser l’authentification moderne.

Pour plus d’informations sur Azure AD, voir Azure Active Directory documentation.

L’intégration de votre site avec Azure AD prend en charge les scénarios Configuration Manager suivants :

Scénarios clients

Scénarios de serveur

Authentification du fournisseur de 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 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 SDK et Windows PowerShell cmdlets.

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

  • Windows authentification : 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 de certificat : exiger l’authentification avec un certificat valide émis par une autorité de certification pKI fiable. Vous ne configurez pas ce certificat dans Configuration Manager. Configuration Manager exige que l’administrateur soit Windows à l’aide de l’ki PKI.

  • Windows Hello’authentification pour les entreprises : nécessite une authentification à 2 facteurs forte liée à un appareil et qui utilise la biométrie ou un code confidentiel. Pour plus d’informations, voir Windows Hello entreprise.

    Important

    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 d’Windows avec son code confidentiel Windows Hello Entreprise ou la biométrie. Sinon, le site rejette l’action de l’utilisateur.

    Ce comportement s’Windows Hello entreprise, et non Windows Hello.

Pour plus d’informations sur la configuration de ce paramètre, voir Configurer l’authentification du fournisseur de SMS.

Prochaines étapes