Vulnérabilités et risques connus

Date de publication : janvier 2017

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

Cette rubrique décrit les risques et les vulnérabilités potentiels lorsque vous utilisez Microsoft Dynamics 365, ainsi que les limitations et les solutions de contournement qui s'appliquent le cas échéant.

Contenu de la rubrique

Risques lorsque les utilisateurs se connectent à Dynamics 365 sur un réseau non sécurisé

Recommandations de sécurité pour les déploiements de rôles serveur

Authentification anonyme

Isolation du rôle HelpServer pour les déploiements avec accès via Internet

Problèmes et limites de l'authentification basée sur les revendications

Sécurisation du fichier web.config

Les appels Internet sortants issus du code personnalisé exécuté par le service de traitement Bac à sable (sandbox) sont activés

Sécurisation des communications serveur vers serveur

Attaques de reliaison de DNS

JavaScript autorisé pour les URL de Power BI sur les tableaux de bord personnels

Risques lorsque les utilisateurs se connectent à Dynamics 365 sur un réseau non sécurisé

Voici les éventuels problèmes survenant lorsque vous exécutez Microsoft Dynamics 365 sans utiliser de protocole TLS (Transport Layer Security) ou SSL (Secure Sockets Layer) (HTTPS) :

• Les données fournies par les utilisateurs de Microsoft Dynamics 365, notamment les définitions de graphiques visuels, peuvent être altérées par des « attaques de l'intercepteur » avec une connexion HTTP non sécurisée. Pour pallier cette vulnérabilité, configurez Microsoft Dynamics 365 pour n'utiliser que le protocole TLS/SSL. Pour plus d’informations sur la configuration de Microsoft Dynamics 365 Server pour utiliser TLS/SSL, voir Sécuriser les communications réseau client-serveur de Dynamics 365.

Recommandations de sécurité pour les déploiements de rôles serveur

Les recommandations suivantes peuvent contribuer à renforcer la sécurité et la fiabilité de votre déploiement Microsoft Dynamics 365.

Authentification anonyme

Microsoft Dynamics 365Déploiement avec accès via Internet (IFD) requiert une authentification anonyme activée dans IIS pour l'authentification basée sur les revendications. Le jeton d'authentification basée sur les revendications ne contient pas les informations d'identification brutes, ni la chaîne de connexion à Microsoft Dynamics 365 Server. Toutefois, le fichier web.config contient des informations de configuration sur le mode d’authentification. Pour plus d'informations, consultez la rubrique Sécurisation du fichier web.config plus loin dans cette rubrique. Utilisez TLS/SSL pour sécuriser le site Web Microsoft Dynamics 365.

Isolation du rôle HelpServer pour les déploiements avec accès via Internet

Les Microsoft Dynamics 365Déploiement avec accès via Internet (IFD) requièrent une authentification anonyme. Dans la mesure où une authentification Web anonyme est utilisée, le répertoire virtuel utilisé par l'Aide de Microsoft Dynamics 365 peut faire l'objet d'une attaque de déni de service.

Pour isoler les pages de l'Aide de Microsoft Dynamics 365 et protéger les autres rôles Microsoft Dynamics 365 Server d'éventuelles attaques de déni de service, il est conseillé d'installer le rôle Serveur d'aide sur un ordinateur distinct.

Pour plus d'informations sur l’installation de rôles Microsoft Dynamics 365 sur des ordinateurs distincts, voir Rôles serveur de Microsoft Dynamics 365.

Pour plus d’informations sur la réduction du risque d’attaque de déni de service, voir MSDN : amélioration de la sécurité des applications Web : menaces et contre-mesures (éventuellement en anglais).

Problèmes et limites de l'authentification basée sur les revendications

Cette rubrique décrit les problèmes et les limites de l’authentification basée sur les revendications avec Microsoft Dynamics 365.

Vérifiez que le fournisseur d'identité utilise une stratégie de mots de passe forts.

Lorsque vous utilisez une authentification basée sur les revendications, il est recommandé de vérifier que le fournisseur d’identité approuvé par le service d'émission de jeton de sécurité (STS), puis Microsoft Dynamics 365, applique des stratégies de mots de passe forts.Microsoft Dynamics 365 n’applique pas de stratégie de mots de passe forts. Par défaut, lorsqu'il est utilisé comme fournisseur d'identité, Active Directory applique une stratégie de mots de passe forts.

Les sessions du serveur de fédération AD FS restent valides jusqu'à 8 heures, même pour les utilisateurs désactivés ou supprimés.

Par défaut, les jetons du serveur Services ADFS (Active Directory Federation Services) affectent une durée d'expiration des cookies du SSO (single sign-on) de Web de 8 heures. Ainsi, même lorsqu'un utilisateur est désactivé ou supprimé d'un fournisseur d'authentification, tant que la session de l'utilisateur reste active, l'utilisateur peut continuer à s'authentifier pour sécuriser les ressources.

Utilisez l'une de ces options pour contourner ce problème :

• Désactivez l'utilisateur dans Microsoft Dynamics 365 et dans Active Directory. Pour plus d'informations sur la désactivation d'un utilisateur dans Microsoft Dynamics 365, voir Gérer les utilisateurs. Pour plus d’informations sur la désactivation d’un utilisateur dans Active Directory, voir l'Aide Utilisateurs et ordinateurs Active Directory.

• Réduire la durée de vie de l'ouverture de session unique sur le Web. Pour ce faire, voir l’aide de la gestion Services ADFS (Active Directory Federation Services).

Sécurisation du fichier web.config

Le fichier web.config créé par Microsoft Dynamics 365 ne contient pas de chaînes de connexion ou de clés de chiffrement. Cependant, le fichier contient des informations de configuration sur le mode et la stratégie d'authentification, les informations d'état de l'affichage ASP.NET et l'affichage des messages d'erreur de débogage. Si le fichier est modifié dans un but malveillant, il peut constituer une menace pour le serveur là où Microsoft Dynamics 365 s'exécute. Pour sécuriser le fichier web.config, il est recommandé de procéder de la façon suivante :

• Attribuer des autorisations au dossier contenant le fichier web.config pour n’inclure que les comptes d’utilisateur qui le requièrent, tels que les administrateurs. Par défaut, le fichier web.config est situé dans le dossier <drive:>Program Files\Microsoft Dynamics CRM\CRMWeb.

• Limiter le nombre d’utilisateurs qui peuvent accéder de façon interactive aux serveurs Dynamics 365, par exemple, les utilisateurs disposant d’une autorisation pour l’ouverture de sessions console.

• Désactiver l’exploration des répertoires sur le site Web Dynamics 365. Par défaut, cette option est désactivée. Pour plus d'informations sur la désactivation de l’exploration des répertoires, voir l’aide du Gestionnaire des services IIS.

Les appels Internet sortants issus du code personnalisé exécuté par le service de traitement Bac à sable (sandbox) sont activés

Par défaut, les appels sortants de code personnalisé exécutés par le Service de traitement Bac à sable (sandbox) de Microsoft Dynamics 365 qui accèdent aux services sur Internet sont activés. Pour les déploiements de Microsoft Dynamics 365 à très haut niveau de sécurité, ceci peut constituer un risque pour la sécurité. Si vous ne souhaitez pas autoriser les appels sortants issus de code personnalisé, tel que les plug-ins ou les activités de workflow personnalisées de Dynamics 365, vous pouvez désactiver les connexions sortantes issues de code personnalisé exécutées par le Service de traitement Bac à sable (sandbox) en suivant la procédure indiquée ici.

Au lieu de bloquer tous les appels sortants, vous pouvez appliquer des restrictions d'accès au Web aux plug-ins en Bac à sable (sandbox).Pour plus d'informations :MSDN : Isolement, approbations et statistiques des plug-ins

La désactivation des connexions sortantes pour le code personnalisé implique la désactivation des appels vers les services cloud, comme Microsoft Azure et la base de données SQL de Microsoft Azure.

Désactivation des connexions sortantes pour le code personnalisé sur l'ordinateur qui exécute le service de traitement Bac à sable (sandbox)

1. Sur l’ordinateur qui exécute Windows Server sur lequel le rôle serveur Microsoft Dynamics 365Service de traitement Bac à sable (sandbox) est installé, démarrez l’Éditeur du Registre et recherchez la sous-clé de Registre suivante :
   HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MSCRM

2. Cliquez avec le bouton droit sur MSCRM, pointez vers Nouveau, cliquez sur Valeur DWORD, tapez SandboxWorkerDisableOutboundCalls, puis appuyez sur Entrée.

3. Cliquez avec le bouton droit sur SandboxWorkerDisableOutboundCalls, cliquez sur Modifier, tapez 1, puis appuyez sur Entrée.

4. Fermez Éditeur du Registre.

5. Redémarrez le Service de traitement Bac à sable (sandbox). Pour ce faire, cliquez sur Démarrer, tapez services.msc, puis appuyez sur Entrée.

6. Cliquez avec le bouton droit sur Service de traitement Bac à sable (sandbox) Microsoft Dynamics 365, puis sur Redémarrer.

7. Fermez le composant logiciel enfichable des services Microsoft Management Console (MMC).

Sécurisation des communications serveur vers serveur

Par défaut, les communications serveur vers serveur de Microsoft Dynamics 365, telles que les communications entre le rôle Serveur d'application Web et le serveur exécutant Microsoft SQL Server, ne s'exécutent pas par le biais d'un canal sécurisé. En conséquence, les informations transmises entre les serveurs sont vulnérables à certaines attaques, telles que les attaques dites « de l'intercepteur ».

Il est recommandé de mettre en œuvre la mise en réseau sécurisée, comme le Pare-feu Windows, pour protéger les informations transmises entre les serveurs de votre organisation.Pour plus d'informations :Présentation du Pare-feu Windows avec sécurité avancée

Attaques de reliaison de DNS

Comme beaucoup d'applications basées sur le Web, Microsoft Dynamics 365 peut être vulnérable aux attaques de reliaison de DNS. Dans ce type d'attaque, un navigateur Web récupère des pages de deux serveurs différents, pensant que les serveurs proviennent du même domaine, trompant ainsi l'utilisateur en déjouant la protection normalement assurée par la politique de la même origine. Avec cette technique, un intrus peut falsifier des données Dynamics 365 à l'aide de l'identité de la victime via des attaques sur les éléments dynamiques des pages Dynamics 365.

Pour plus d'informations sur comment se protéger contre de telles attaques, voir Protection des navigateurs contre les attaques de reliaison de DNS.

JavaScript autorisé pour les URL de Power BI sur les tableaux de bord personnels

Étant donné que JavaScript peut être utilisé pour que les tableaux de bord personnels puissent utiliser Power BIURLs, vous devez connaître les risques suivants d'attaques par injection de scripts de la part de sources malveillantes :

• Redirection arbitraire vers un site Web inattendu, tel qu'un site Web d’hameçonnage.

• Création de nombreux objets JavaScript volumineux pour essayer de bloquer le navigateur Web.

Pour réduire le risque, mettez en œuvre les recommandations suivantes :

• Autorisez uniquement les sites SharePoint approuvés à héberger les documents Microsoft Office Excel utilisés pour incorporer des rapports Power BI dans les tableaux de bord.Pour plus d'informations :Introduction à Power BI pour le Centre d'administration Office 365

• Sécurisez le site SharePoint qui héberge les composants Power BI afin que seules les sources de confiance puissent ajouter des documents qui sont ensuite ajoutés aux tableaux de bord.Découvrez les niveaux d'autorisation SharePoint

• Demandez aux utilisateurs de Microsoft Dynamics 365 d'éviter d'ajouter des composants non approuvés à leurs tableaux de bord. Cette procédure est similaire à celle qui veut que vous demandiez aux utilisateurs de ne pas ouvrir les pièces jointes et de ne pas cliquer sur les liens hypertexte des messages électroniques provenant de sources inconnues.

Voir aussi

Considérations relatives à la sécurité pour Microsoft Dynamics 365
Ports réseau pour Microsoft Dynamics 365
Configurations prises en charge par Microsoft Dynamics 365

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