Dynamics 365 Customer Engagement (on-premises) の設置型展開の管理に関するベスト プラクティス
いくつかの簡単な管理規則に従うことで、Dynamics 365 Customer Engagement (on-premises) 設置型展開のセキュリティを大幅に向上できます。
通常、Customer Engagement ユーザーがドメイン上で管理者特権を持つ必要はありません。 したがって、すべての Customer Engagement ユーザー アカウントをドメイン ユーザーのメンバーシップに制限します。 また、最小限の特権の原則に従って、Customer Engagement システムを使用するすべてのユーザーの権限も最小限のものにします。 まず、ドメイン レベルから設定を始めます。 Customer Engagement の実行には、ドメイン ユーザー アカウントを作成して使用してください。 ドメイン管理者アカウントは、Customer Engagement の実行に決して使用しないでください。
Dynamics 365 Customer Engagement (on-premises) 展開管理者およびシステム管理者ロールの数を、ルールの変更を担当する 2 ～ 3 名のユーザーに限定します。 SQL Server、Microsoft Exchange Server、または Active Directory の管理者である他のユーザーは、Customer Engagement ユーザー グループのメンバーである必要はありません。
少なくとも 2 ～ 3 名の信頼できるユーザーに展開の管理者ロールを割り当てる必要があります。 こうしておくと、中心的な展開管理者が不在でもシステムは通常どおりに稼動します。
組織によっては、複数のシステムや複数のドメイン間でパスワードを再使用していることがあります。 たとえば、2 つのドメインを担当する管理者が、それぞれのドメインで同じパスワードを使用するドメイン管理者アカウントを作成したり、ドメイン コンピューター上にドメイン全体のパスワードと同じローカル管理者パスワードを設定したりすることもあります。 このような場合、1 つのアカウントまたは 1 台のコンピューターのセキュリティが侵害されると、ドメイン全体のセキュリティが侵害される可能性があります。 パスワードは、絶対にこのような方法で再使用しないでください。
また、ドメイン管理者アカウントを、バックアップ システムなどの共通サービスのサービス アカウントとして使用している事例もよく見られます。 しかし、ドメイン管理者アカウントをサービス アカウントとして使用することには、セキュリティ上のリスクがあります。 管理者権限があればどのユーザーでも、コンピューター上でパスワードを簡単に取得することができます。 そのような場合、ドメイン全体でセキュリティが侵害されるおそれがあります。 ドメイン管理者アカウントを絶対にサービス アカウントとして使用しないでください。また、サービス アカウントの特権はできる限り制限してください。
また、Dynamics 365 Customer Engagement (on-premises) サービスを実行するために指定されるドメイン ユーザー アカウントは、Customer Engagement ユーザーとして構成する必要もあります。 これに起因して、アプリケーションで予期しない動作が発生することがあります。