Bonnes pratiques de sécurité pour Microsoft Dynamics 365

 

Date de publication : janvier 2017

S’applique à : Dynamics 365 (on-premises), Dynamics CRM 2016

Internet Information Services (IIS) est un service Web exigible inclus dans Windows Server.Microsoft Dynamics 365 dépend de la sécurité et de l’efficacité du service Web IIS. Prenez en compte les éléments suivants :

• Dans les fichiers de configuration machine.config et web.config, vous pouvez déterminer si le débogage est activé et si des messages d'erreur détaillés sont envoyés au client. Assurez-vous que le débogage est désactivé sur tous les serveurs de production et qu'un message d'erreur générique est envoyé au client en cas de problème. Vous évitez ainsi l'envoi inutile d'informations à propos de la configuration du serveur Web au client.

• Vérifiez que les Service Packs et mises à jour les plus récents pour le système d'exploitation et IIS ont été appliqués. Pour obtenir les informations les plus récentes, consultez le site Web Microsoft Sécurité.

• Programme d’installation de Microsoft Dynamics CRM Server crée des pools d'applications appelés CRMAppPool et CRMDeploymentServiceAppPool qui fonctionnent sous les informations d'identification spécifiées au cours de l'installation. Pour faciliter un modèle à faibles privilèges, il est conseillé de spécifier des comptes d’utilisateur de domaine distincts pour ces pools d’applications plutôt que d’utiliser un compte Service réseau. Par ailleurs, il est recommandé de ne pas installer d'autres applications ASP.NET sous ces pools d'applications. Pour plus d'informations sur les autorisations minimales requises pour ces composants, voir Autorisations minimales requises pour le programme d’installation et les services Microsoft Dynamics CRM.

Important

• Assurez-vous que tous les sites Web qui s'exécutent sur le même ordinateur que le site Web Microsoft Dynamics 365 peuvent également avoir accès à la base de données Dynamics 365.

• Si vous utilisez un compte d'utilisateur de domaine, avant d'exécuter le Programme d’installation de Microsoft Dynamics CRM Server, vous devrez peut-être vérifier que le nom de principal du service (SPN) est correctement défini pour ce compte, et si nécessaire, définir le SPN correct. Pour plus d’informations sur les noms de principal du service et leur définition, voir Comment utiliser SPN lorsque vous configurez les applications Web qui sont hébergées sur IIS.

Gestion des noms de principal du service dans Microsoft Dynamics 365

L'attribut de nom de principal du service (SPN) est un attribut à plusieurs valeurs non lié qui est créé à partir du nom d'hôte DNS. Le nom de principal du service est utilisé pendant l'authentification mutuelle entre le client et le serveur hébergeant un service spécifique. Le client recherche un compte d'ordinateur basé sur le SPN du service auquel il tente de se connecter.

Le programme d'installation de Microsoft Dynamics 365 Server déploie des services propres au rôle et des pools d'applications Web qui fonctionnent avec les informations d'identification utilisateur spécifiées pendant l'Installation. Pour examiner la liste complète de ces rôles et des autorisations nécessaires, voir Autorisations minimales requises pour le programme d’installation et les services Microsoft Dynamics CRM.

Lorsque déployez une infrastructure Microsoft Dynamics 365 hébergée, deux de ces rôles peuvent demander une attention particulière :

• Service Web de déploiement

• Service d'application

Dans des scénarios de batterie de serveurs Web, comme dans le cas d'une offre hébergée, il est recommandé de conserver l'authentification du mode noyau activée. En outre, vous devez envisager l'utilisation de comptes d'utilisateurs de domaine distincts pour exécuter ces services pour les raisons suivantes :

• L'utilisation de comptes de service distincts pour ces rôles serveur facilite l'implémentation de l'équilibrage de charge matérielle.

• Le rôle serveur Service Web de déploiement nécessite l'élévation des autorisations pour mettre en service les organisations de la base de données Dynamics 365. Si vous souhaitez choisir un modèle avec moins de privilèges, la solution la plus sûre pour implémenter les SPN dans une infrastructure Microsoft Dynamics 365 hébergée implique l'exécution du Service Web de déploiement sous un autre compte d'utilisateur de domaine que le service d'applications.

Si vous décidez d'utiliser des comptes de domaine distincts pour ces rôles serveur, vous devez vérifier que le SPN est correct pour chaque compte avant de démarrer le Programme d’installation de Microsoft Dynamics CRM Server. Ainsi, la définition du SPN correct sera plus simple.

Si l'authentification du mode noyau est activée, les SPN seront définis pour le compte de l'ordinateur, indépendamment du compte de service spécifié. Lorsque vous implémentez une batterie de serveurs Web, activez l'authentification du mode noyau et modifiez le fichier ApplicationHost.config local.

Si les services Web de déploiement et d'applications sont exécutés sur le même système et si l'authentification du mode noyau est désactivée, vous pouvez configurer les deux services afin qu'ils s'exécutent sous le même compte d'utilisateur de domaine pour empêcher les problèmes de SPN en double. Si vous ne pouvez pas activer l'authentification du mode noyau, installez les services Web de déploiement et d'applications sur des systèmes distincts. Les SPN devront peut-être être créés manuellement dans la mesure où l'authentification du mode noyau est désactivée.

Pour plus d'informations sur les SPN et leur définition, consultez la page liste de vérification des noms de principal du service (SPN) pour l'authentification Kerberos avec IIS 7.0/7.5 (éventuellement en anglais).

Voir aussi

Considérations relatives à la sécurité pour Microsoft Dynamics 365
Meilleures pratiques d'administration pour les déploiements locaux de Microsoft Dynamics 365

© 2017 Microsoft. Tous droits réservés. Copyright