Udostępnij za pośrednictwem

Operating system and platform technology security considerations for Microsoft Dynamics 365

  • Artykuł

 

Applies To: Dynamics 365 (on-premises), Dynamics CRM 2016

In the broadest sense, security involves planning and considering tradeoffs between threats and access. For example, a computer can be locked in a vault and available only to one system administrator. This computer may be secure, but it’s not very usable because it’s not connected to any other computer. If your business users need access to the Internet and your corporate intranet, you must consider how to make the network both secure and usable.

In this topic you’ll find helpful information and links to many resources you can use to make your computing environment more secure. Because ultimately, Microsoft Dynamics 365 data security largely depends on how well you first secure the operating system and software components.

In this topic

Securing Windows Server

Securing SQL Server

Securing Exchange Server and Outlook

Securing mobile devices

Securing Windows Server

Windows Server, the foundation of Microsoft Dynamics 365, provides sophisticated network security. The Kerberos version 5 authentication protocol that is integrated into Active Directory and Active Directory Federation Services (AD FS) lets you federate Active Directory domains by using claims-based authentication. Both give you powerful standards-based authentication. These authentication standards let users enter a single user name and password sign-in combination for resource access across the network. Windows Server also includes several features that help make the network even more secure.

Follow these links to learn more about these features and how to make your Windows Server deployment more secure:

Windows error reporting

Microsoft Dynamics 365 requires the Windows Error Reporting (WER) service, which Setup will install if it is missing. The WER service collects information, such as IP addresses. These IP addresses are not used to identify users. The WER service does not intentionally collect names, addresses, email addresses, computer names, or any other form of personally identifiable information (PII). It is possible that such information may be captured in memory or in the data collected from open files, but Microsoft does not use it to identify users. In addition, some information that is transmitted between the Microsoft Dynamics 365 application and Microsoft may not be secure. For more information about the type of information that is transmitted, see Privacy statement for the Microsoft Error Reporting Service.

Virus, malware, and identity protection

To better protect your identity and your system against malware or viruses, check out these resources:

  • Microsoft Security. This page is an entry point for tips, training, and guidance about how to keep your computer up to date and prevent it from being susceptible to exploitation, spyware, and viruses.

  • Security TechCenter. This page has links to technical bulletins, advisories, updates, tools, and guidance designed to make computers and applications up to date and more secure.

Update management

Microsoft Dynamics 365 updates include security, performance, and functional improvements. Making sure your Microsoft Dynamics 365 applications have the latest updates helps make sure your system runs as efficiently and reliably as it can. You can find more information about how to manage updates here:

Securing SQL Server

Because Microsoft Dynamics 365 relies on SQL Server, make sure you take the following measures to improve the security of your SQL Server database:

  • Apply the latest operating system, SQL Server service packs (SPs), and updates. Check the Microsoft Security website for the latest details.

  • Install all SQL Server data and system files on NTFS partitions for file system-level security. You should make the files available only to administrative or system-level users through NTFS permissions. This helps safeguard against users who access those files when the MSSQLSERVER service is not running.

  • Use a low-privilege domain account. Or, specify the Network Service or Local System Account for SQL Server services. However, we do not recommend that you use these accounts because Domain User accounts can be configured with fewer permissions to run the SQL Server services. Domain User accounts should have minimal rights in the domain, which should help contain (but will not stop) an attack on the server if there is a compromise. In other words, Domain User accounts should have only local user-level permissions in the domain. If SQL Server is installed using a Domain Administrator account to run the services, a compromise of SQL Server will lead to a compromise of the entire domain. If you have to change this setting, use SQL Server Management Studio to make the change, because the access control lists (ACLs) on files, the registry, and user rights will be changed automatically.

  • Because SQL Server authenticates users who have either Windows Authentication or SQL Server credentials, we suggest you use Windows Authentication for single sign-on convenience and the most secure authentication.

  • At a minimum, enable auditing of failed sign-ins. By default, SQL Server system auditing is disabled, and no conditions are audited. This makes intrusion detection difficult and helps attackers cover their tracks.

  • Report Server administrators should enable RDL Sandboxing to restrict access to the Report Server. More information: Enabling and Disabling RDL Sandboxing

  • Configure each SQL logon to use the master database as the default database. Although users shouldn’t have rights to the master database, as a best practice, you should change the default for every SQL logon (except those with the SYSADMIN role) to use OrganizationName_MSCRM as the default database. More information: Securing SQL Server

Securing Exchange Server and Outlook

The following considerations are for Microsoft Exchange Server or Exchange Server in a Microsoft Dynamics 365 environment:

  • Exchange Server contains a rich series of mechanisms for precise administrative control of its infrastructure. In particular, you can use administrative groups to collect Exchange Server objects like servers, connectors, or policies, and then modify the ACLs on those administrative groups to make sure only certain users can access them. You may, for example, want to give Microsoft Dynamics 365 administrators control over servers that directly affect their applications. When you implement administrative groups efficiently, you know you are giving Microsoft Dynamics 365 administrators exactly the rights they need to do their jobs.

  • Frequently, you may find it convenient to create a separate organizational unit (OU) for Microsoft Dynamics 365 users, and give Microsoft Dynamics 365 administrators limited administrative rights over that OU. Administrators can make changes for any user in that OU, but not for any user outside it.

  • Always be sure you adequately protect against unauthorized email relay. Email relay lets an SMTP client use an SMTP server to forward email messages to a remote domain. By default, Microsoft Exchange Server is configured to prevent email relay. The settings you configure will depend on your message flow and how your Internet service provider's (ISP) email server is configured. However, the best approach here is to lock down your email relay settings and then gradually open them to let email flow successfully. For more information, see the Exchange Server Help.

  • If you use forward mailbox monitoring, the Email Router requires an Exchange Server or POP3-compliant mailbox. We recommend you set the permissions on this mailbox to prevent other users from adding server-side rules. For more information about Exchange Server mailboxes, see Recipients Permissions.

  • The Microsoft Dynamics 365Email Router service operates under the Local System Account. This enables the Email Router to access a specified user's mailbox and process email in that mailbox.

For more information about how to make Exchange Server more secure, see Deployment Security Checklist.

Securing mobile devices

As organizations move to support an increasingly mobile workforce, strong security remains essential. Here are some resources to help you implement best practices for mobile devices, such as smartphones and tablets:

See Also

Planning your deployment of Microsoft Dynamics 365
Integrate (synchronize) your email system with Microsoft Dynamics 365
Set up and manage phones and tablets
Security considerations for Microsoft Dynamics 365

© 2016 Microsoft. All rights reserved. Copyright