Meilleures pratiques d’administration pour les déploiements locaux de Dynamics 365 Customer Engagement (on-premises)
En respectant quelques règles d’administration simples, vous pouvez améliorer sensiblement la sécurité de votre déploiement local de Dynamics 365 Customer Engagement (on-premises) :
Généralement, il n’est pas nécessaire que les utilisateurs Customer Engagement possèdent des privilèges administratifs sur le domaine. Dès lors, tous les comptes d’utilisateur de Customer Engagement doivent être limités aux privilèges accordés au type de compte Utilisateurs de domaine. En outre, en appliquant le principe de limitation des privilèges, quiconque utilise le système Customer Engagement ne doit posséder que les droits strictement nécessaires. Cela commence au niveau du domaine. Un compte d’utilisateur de domaine doit être créé et utilisé pour exécuter Customer Engagement. Les comptes administrateur de domaine ne doivent jamais être utilisés pour exécuter Customer Engagement.
Limitez le nombre de rôles Administrateur de déploiement et Administrateur système de Dynamics 365 Customer Engagement (on-premises) aux personnes responsables des modifications de règles. Tous les autres administrateurs SQL Server, Microsoft Exchange Server ou Active Directory n’ont pas à être membres du groupe d’utilisateurs Customer Engagement.
Assurez-vous qu’au moins deux ou trois personnes de confiance bénéficient du rôle Administrateur de déploiement. Ceci permet d’éviter le verrouillage du système si l’administrateur de déploiement principal n’est pas disponible.
Dans certaines organisations, il est courant de réutiliser des mots de passe dans différents systèmes et domaines. Ainsi, un administrateur responsable de deux domaines peut créer dans les deux des comptes d’administrateur qui utilisent le même mot de passe, voire définir des mots de passe d’administrateur local sur des ordinateurs de domaine qui sont identiques dans tout le domaine. Dans un tel cas, si un seul compte ou ordinateur venait à être compromis, c’est la sécurité de tout le domaine qui serait en jeu. Les mots de passe ne peuvent jamais être utilisés de la sorte.
Il est également assez habituel d’utiliser les comptes Administrateurs de domaine comme comptes de services courants tels que les systèmes de sauvegarde. Toutefois, l’utilisation de comptes Administrateurs de domaine comme comptes de service présente un risque de sécurité. Il est très facile pour quiconque possède des droits administratifs sur l’ordinateur, de récupérer le mot de passe. En conséquence, si un ordinateur est compromis, tout le domaine peut l’être. Les comptes de service ne doivent jamais être des comptes Administrateurs de domaine et doivent, dans la mesure du possible, disposer de privilèges limités.
Un compte d’utilisateur de domaine spécifié pour exécuter un service Dynamics 365 Customer Engagement (on-premises) ne doit pas être aussi configuré comme utilisateur de Customer Engagement. Cela peut entraîner un comportement inattendu de l’application.