Gestion de conformité : DCM ou DSC ?

Si nous avons eu l’occasion de travailler ensemble, vous savez déjà mon attachement à la standardisation et, par voie de conséquence, à l’utilisation de techniques permettant de gérer des réglages de manière industrielle ; c’est à dire en regroupant les systèmes par famille. Il est ainsi possible de gérer un nombre limité de familles plutôt que de continuer à gérer les systèmes individuels. Avec la multiplication du nombre de systèmes à gérer par le biais des solutions de virtualisation, il devient obligatoire de gérer collectivement l’ensemble des systèmes. Pour un ensemble de systèmes, des réglages identiques doivent se retrouver de manière à éviter des dysfonctionnements.

J’ai délivré de nombreuses missions autour de la gestion de la configuration souhaitée de System Center Configuration Manager appelé en anglais DCM pour Desired Configuration Management ou, plus récemment, CSM pour Compliance and Settings Management depuis ConfigMgr 2012.

Avec Windows Server 2012 R2 / Windows 8.1 et PowerShell 4.0 est apparu DSC pour Desired State Configuration dont les objectifs peuvent paraître identiques à DCM ; à savoir, gérer la conformité de vos systèmes.

Au passage, vous pouvez bénéficier de PowerShell 4.0 sur des systèmes plus anciens tels que Windows Server 2008 R2 ou Windows 7 par le biais de Windows Management Framework 4.0 ou WMF 4.0 depuis l’emplacement suivant :
https://www.microsoft.com/en-us/download/details.aspx?id=40855

WMF 4.0 apporte non seulement PowerShell 4.0, mais aussi les autres composants de gestion dont BITS et WinRM, tout en mettant à jour la couche WMI. Il nécessite l’installation préalable du Microsoft .NET Framework en version 4.5.

Si vous utilisez encore Windows 8, n’hésitez pas à passer en Windows 8.1 pour recevoir cette version des composants de gestion.

En quoi diffèrent DCM et DSC et quoi se complètent-ils ?

DCS ne repose sur aucun autre composant que la présence de PowerShell en version 4 et ultérieur qui est présent, en standard sur des systèmes récents, y compris dans des installation en mode dit “core” bien qu’il ne soit pas activé par défaut.

DCM repose sur l’agent de ConfigMgr. Il peut utiliser des scripts en PowerShell, mais aussi d’autres langages de Scripting, voire, sans programmation.

Les 2 solutions visent à simplifier la gestion des configurations en évitant des écarts qui peuvent avoir des effets sur le fonctionnement des systèmes.

DSC vise prioritairement à régler le fonctionnement des systèmes sur lesquels il est utilisé en tirant parti des possibilités des systèmes d’exploitation à ajouter ou retirer des rôles et fonctionnalités du système d’exploitation, mais aussi en mettant en œuvre des réglages spécifiques de ces rôles et fonctionnalités.

DCM permet d’identifier des dérives de configuration, puis, optionnellement, des corriger ces dérives. Pour un certain nombre de réglages, la remédiation automatique est utilisable, mais pour des réglages plus spécifiques, il peut être nécessaire de recourir à des distributions classiques sur un regroupement (collection) de l’ensemble des systèmes qui ne sont pas conformes.

DSC est largement utilisé dans les phases de déploiement des systèmes d’exploitation de manière à appliquer rapidement des réglages sur un grand nombre de systèmes d’une même famille.

Sur le plan des possibilités de type de contrôle, DSC comme DCM sont des solutions évolutives sur lesquelles le travail est plus ou moins complexe selon qu’il a été nativement prévu de faire un type de vérification donné :

De manière globale, DSC est majoritairement utilisé pour régler rapidement des distorsions voire effectuer les réglages initiaux quand DCM sera plutôt utilisé pour de l’analyse de déviation. DSC est utilisé pour de configuration initiale quand DCM vérifie l’évolution possible du parc contrôlé. Le parc géré par DCM doit être plutôt pérenne de manière à laisser le temps à l’agent ConfigMgr de s’installer, puis de prendre la liste des réglages à contrôler avant de décider de les corriger, soit de manière automatisée, soit par des distributions plus ou moins automatisées.

Au-delà de ces comparaisons, une troisième possibilité existe pour appliquer des réglages de manière industrielle à des ensembles de systèmes à travers la notion de Group Policy Objects (GPO) de l’Active Directory, mais celles-ci ne concernent que des systèmes qui sont membres de l’Active Directory et il peut être, parfois, utile de vérifier la bonne application de ces réglages qui sont censés être appliqués via des GPOs.