Compartilhar via

Considerações de segurança sobre a tecnologia de plataforma e o sistema operacional para o Microsoft Dynamics 365

  • Artigo

 

Publicado: janeiro de 2017

Aplicável a: Dynamics 365 (on-premises), Dynamics CRM 2016

Em um sentido mais amplo, a segurança envolve planejamento e possibilidade de concessões entre ameaças e acesso. Por exemplo, um computador pode estar trancado em um cofre e estar disponível apenas para um administrador do sistema. Esse computador pode estar seguro, mas não é muito útil, pois não está conectado a nenhum outro computador. Se os seus usuários empresariais precisam acessar a Internet e a intranet corporativa, você deve planejar como tornar a rede segura e utilizável.

Neste tópico, você encontrará informações úteis e links para vários recursos que podem ser usados para tornar o computador mais seguro. Isso porque, em última análise, a segurança dos dados do Microsoft Dynamics 365 depende, em grande parte, de como você protege primeiramente os componentes de software e sistema operacional.

Neste tópico

Protegendo o Windows Server

Protegendo o SQL Server

Protegendo o Exchange Server e o Outlook

Protegendo dispositivos móveis

Protegendo o Windows Server

O Windows Server, que é a estrutura base do Microsoft Dynamics 365, proporciona sofisticada segurança de rede. O protocolo de autenticação versão 5 kerberos integrado no Active Directory e no Serviços de Federação do Active Directory (AD FS) permite federar domínios do Active Directory usando autenticação baseada em declarações. Ambos proporcionam poderosa autenticação baseada em padrões. Esses padrões de autenticação permitem que os usuários insiram uma combinação de entrada de nome de usuário e senha para acessar os recursos na rede. O Windows Server também inclui vários recursos que ajudam a aumentar ainda mais a segurança da rede.

Siga estes links para saber mais sobre esses recursos e como tornar a implantação do Windows Server mais segura:

Relatórios de erros do Windows

O Microsoft Dynamics 365 exige o serviço Relatório de Erros do Windows (WER), que a Instalação instalará se estiver ausente. O serviço WER coleta informações, como endereços IP. Esses endereços de IP não são usados para identificar os usuários. O serviço WER não coleta intencionalmente nomes, endereços, endereços de email, nomes de computador ou qualquer outro tipo de informação de identificação pessoal (PII). É possível que essas informações possam ser capturadas na memória ou nos dados coletados de arquivos abertos, mas a Microsoft não as usa para identificar os usuários. Além disso, algumas informações transmitidas entre o aplicativo Microsoft Dynamics 365 e a Microsoft podem não ser seguras. Para obter mais informações sobre o tipo de informações transmitidas, consulte Declaração de privacidade para o Serviço de Relatório de Erros da Microsoft.

Vírus, malware e proteção de identidades

Para proteger melhor a identidade e seu sistema contra vírus ou malware, verifique estes recursos:

  • Microsoft Security. Esta página é um ponto de entrada para dicas, treinamento e diretrizes sobre como manter seu computador atualizado e impedir que ele fique suscetível a exploração, spyware e vírus.

  • Security TechCenter. Esta página tem links para boletins técnicos, avisos, atualizações, ferramentas e diretrizes criados para tornar computadores e aplicativos atualizados e mais seguros.

Gerenciamento de atualização

As atualizações do Microsoft Dynamics 365 incluem melhorias funcionais, de segurança e de desempenho. A implementação das atualizações mais recentes nos aplicativos do Microsoft Dynamics 365 ajuda a garantir uma execução eficiente e confiável do sistema. Você pode encontrar mais informações sobre como gerenciar atualizações aqui:

Protegendo o SQL Server

Como o Microsoft Dynamics 365 depende do SQL Server, verifique se você tomou as seguintes medidas para melhorar a segurança do banco de dados do SQL Server:

  • Aplique os service packs (SPs) e as atualizações mais recentes do SQL Server e do sistema operacional. Consulte o site Microsoft Security para obter detalhes atualizados.

  • Instale todos os arquivos de dados e de sistema do SQL Server em partições NTFS para garantir a segurança em nível de sistema de arquivos. Disponibilize os arquivos apenas para usuários no nível administrativo ou de sistema por meio de permissões NTFS. Esse procedimento ajuda a resguardar o sistema contra usuários que acessem esses arquivos quando o serviço MSSQLSERVER não estiver em execução.

  • Use uma conta de domínio de baixo privilégio. Ou especifique a conta de Serviço de Rede ou Sistema Local para os serviços do SQL Server. Contudo, não é recomendável usar essas contas porque as contas de usuário de domínio podem ser configuradas com menos permissões para executar os serviços do SQL Server. As contas de usuário de domínio devem ter direitos mínimos no domínio, o que pode ajudar a conter (mas não parar) um ataque ao servidor, caso haja comprometimento. Em outras palavras, as contas de usuário do domínio devem ter apenas permissões no nível de usuário local no domínio. Se o SQL Server tiver sido instalado com o uso de uma conta de Administrador de Domínio para executar os serviços, o comprometimento do SQL Server levará ao comprometimento de todo o domínio. Use o SQL Server Management Studio para fazer qualquer alteração necessária nessa configuração, pois as ACLs (listas de controle de acesso) dos arquivos, o Registro e os direitos dos usuários serão alterados automaticamente.

  • Como o SQL Server autentica os usuários com credenciais da Autenticação do Windows ou do SQL Server, sugerimos que você use Autenticação do Windows para conveniência de logon único e a autenticação mais segura.

  • Habilite, pelo menos, a auditoria das entradas que falharam. Por padrão, a auditoria do sistema do SQL Server é desabilitada e nenhuma condição é auditada. Isso dificulta a detecção de intrusões e ajuda o invasor a encobrir suas pistas.

  • Os administradores do Servidor de Relatório devem habilitar o RDL em Área Restrita para restringir o acesso ao Servidor de Relatório.Para obter mais informações:Habilitando e desabilitando o RDL em Área Restrita

  • Configure cada logon no SQL para usar o banco de dados mestre como padrão. Embora os usuários não devam ter direitos sobre esse banco de dados, como prática recomendada, você deve alterar o padrão de cada logon do SQL (com exceção daquelas com a função SYSADMIN) para usar NomeDaOrganização_MSCRM como banco de dados padrão.Para obter mais informações:Protegendo o SQL Server

Protegendo o Exchange Server e o Outlook

As considerações a seguir se referem ao Microsoft Exchange Server ou Exchange Server em um ambiente do Microsoft Dynamics 365:

  • O Exchange Server contém uma ampla série de mecanismos para o controle administrativo preciso de sua infraestrutura. Em particular, você pode usar grupos administrativos para coletar objetos do Exchange Server, como servidores, conectores ou políticas e modificar as ACLs nesses grupos administrativos para garantir que somente alguns usuários possam acessá-los. Por exemplo, talvez você queira oferecer aos administradores do Microsoft Dynamics 365 controle sobre os servidores que diretamente afetam seus aplicativos. Ao implementar grupos administrativos de forma eficiente, você sabe se está fornecendo aos administrados do Microsoft Dynamics 365 exatamente os direitos de que precisam para realizar seus trabalhos.

  • Muitas vezes, pode ser conveniente criar uma unidade organizacional separada para os usuários do Microsoft Dynamics 365 e oferecer aos administradores do Microsoft Dynamics 365 direitos administrativos limitados sobre essa unidade organizacional. Os administradores podem fazer alterações para qualquer usuário dessa unidade organizacional, mas não para qualquer usuário de fora.

  • Sempre verifique se você está devidamente protegido contra retransmissão de emails não autorizada. A retransmissão de emails permite a um cliente SMTP usar um servidor SMTP para encaminhar mensagens de email a um domínio remoto. Por padrão, o Microsoft Exchange Server é configurado para impedir a retransmissão de emails. As configurações dependerão do fluxo de mensagens e da configuração do servidor de email do ISP (provedor de serviços de Internet). Entretanto, a melhor abordagem nesse caso é bloquear as configurações de retransmissão de emails e depois desbloqueá-las gradualmente para permitir o fluxo normal de emails. Para obter mais informações, consulte a Ajuda do Exchange Server.

  • Para usar o monitoramento da caixa de correio de encaminhamento, o E-mail Router exige uma caixa de correio em conformidade com o Exchange Server ou o POP3. É recomendável que você defina as permissões dessa caixa de correio para impedir que outros usuários adicionem regras no servidor. Para obter mais informações sobre as caixas de correio do Exchange Server, consulte Permissões de Destinatários.

  • O serviço do Microsoft Dynamics 365E-mail Router opera com a Conta do sistema local. Isso habilita o E-mail Router para acessar a caixa de correio de um usuário especificado e processar os emails nessa caixa de correio.

Para obter mais informações sobre como tornar o Exchange Server mais seguro, consulte Lista de verificação da segurança da implantação.

Protegendo dispositivos móveis

Conforme as organizações são movidas para suportar uma equipe de trabalho sempre mais móvel, a forte segurança permanecerá essencial. Os seguintes recursos ajudam a implantar as práticas recomendadas para dispositivos móveis, como smartphones e tablets:

Confira Também

Planejamento da implantação do Microsoft Dynamics 365
Integrar (sincronizar) seu sistema de email com o Microsoft Dynamics 365
Configurar e gerenciar telefones e tablets
Considerações de segurança para o Microsoft Dynamics 365

© 2017 Microsoft. Todos os direitos reservados. Direitos autorais