Compartilhar via


Práticas recomendadas de segurança do Dynamics 365 Customer Engagement (on-premises)

O Internet Information Services (IIS) é um serviço Web aperfeiçoado incluído no Windows Server. O Dynamics 365 Customer Engagement (on-premises) depende de um serviço Web do IIS eficiente e seguro. Considere estes fatores:

  • Nos arquivos de configuração machine.config e web.config, você pode determinar se a depuração será habilitada e se mensagens de erro detalhadas devem ser enviadas para o cliente. Verifique se a opção de depuração está desabilitada em todos os servidores de produção e também se uma mensagem de erro genérica é enviada ao cliente caso ocorra um problema. Esse procedimento evita que informações desnecessárias sobre a configuração do servidor Web sejam enviadas ao cliente.

  • Verifique se os service packs e as atualizações mais recentes do IIS e do sistema operacional foram aplicados. Para obter as informações atualizadas, consulte o site Segurança da Microsoft.

  • A Instalação do Dynamics 365 Server cria pools de aplicativos, chamados CRMAppPool e CRMDeploymentServiceAppPool, que operam com as credenciais de usuário especificadas durante o processo de instalação. Para facilitar um modelo de privilégios mínimos, recomendamos que você especifique contas de usuário de domínio separadas para esses pools de aplicativos em vez de usar a conta de Serviço de Rede. Além disso, recomendamos que nenhum outro aplicativo conectado ao ASP.NET seja instalado nesses pools de aplicativos. Para obter informações sobre as permissões mínimas necessárias para esses componentes, consulte Permissões mínimas necessárias para a Instalação e os serviços do Microsoft Dynamics 365.

Importante

  • Certifique-se de que todos os sites executados no mesmo computador como site do Dynamics 365 Customer Engagement (on-premises) também possam ter acesso ao banco de dados do Customer Engagement.
  • Se você usar uma conta de usuário de domínio, antes de executar a Instalação do Microsoft Dynamics 365 Server, talvez precise verificar se o nome da entidade de serviço (SPN) foi definido corretamente para essa conta e, se necessário, definir o SPN correto. Para obter mais informações sobre SPNs e como defini-los, consulte Como usar SPNS ao configurar aplicativos Web hospedados no IIS.

Gerenciamento do nome principal de serviço no Microsoft Dynamics 365

O atributo Nome Principal de Serviço (SPN) é um atributo não vinculado e com vários valores criado a partir do nome de host DNS. O SPN é usado durante a autenticação mútua entre o cliente e o servidor que hospeda um serviço particular. O cliente localiza uma conta de computador baseada no SPN do serviço ao qual está tentando se conectar.

O instalador do Dynamics 365 Server implanta serviços específicos da função e pools de aplicativos Web que funcionam mediante credenciais de usuário especificadas durante a instalação. Para examinar a lista completa dessas funções e de seus requisitos de permissão, consulte Permissões mínimas necessárias para a Instalação e os serviços do Microsoft Dynamics 365.

Ao implantar uma infraestrutura hospedada do Dynamics 365 Customer Engagement (on-premises), duas destas funções podem exigir consideração adicional:

  • Serviço Web de Implantação

  • Serviço de Aplicativo

Em cenários de farm da Web, como é o caso de uma oferta hospedada, a recomendação é deixar a autenticação de modo kernel habilitada. Além disso, você deve considerar cuidadosamente o uso de contas de usuário do domínio separadas para a execução desses serviços porque:

  • Ter contas de serviço separadas para essas funções de servidor facilita a implementação de balanceamento de carga de hardware.

  • A função de servidor Serviço Web de Implantação exige permissões elevadas para provisionar organizações no banco de dados do Customer Engagement. Se quiser aderir a um modelo menos privilegiado, a abordagem mais segura para a implementação de SPNs em uma infraestrutura hospedada do Dynamics 365 Customer Engagement (on-premises) envolve a execução do Serviço Web de Implantação com uma conta de usuário do domínio distinta do Serviço de Aplicativo.

Se você seguir esta sugestão de usar contas do domínio separadas para as funções de servidor, deverá se certificar de que o SPN está correto para cada conta antes de iniciar a instalação do Dynamics 365 Server. Isso facilitará a definição do SPN correto quando necessário.

Se a autenticação de modo kernel estiver habilitada, os SPNs serão definidos para a conta de máquina, independentemente da conta de serviço especificada. Ao implementar um farm da Web, habilite a autenticação de modo kernel e modifique o arquivo ApplicationHost.config local.

Se os serviços Web de aplicativo e de implantação estiverem em execução no mesmo sistema, e a autenticação de modo kernel estiver desabilitada, você poderia configurar a execução de ambos os serviços sob a mesma conta de usuário do domínio para impedir problemas de SPN duplicado. Se você não puder habilitar a autenticação do modo Kernel, instale os serviços Web Aplicativo e Implantação em sistemas separados. Ainda pode ser necessário criar SPNs manualmente, uma vez que a autenticação de modo kernel está desabilitada.

Consulte também

Considerações de segurança para o Microsoft Dynamics 365
Práticas recomendadas de administração do Microsoft Dynamics 365