Keeping your business data secure with Dynamics 365 & wider Microsoft Technology

Microsoft built Dynamics 365 and the Power Platform onto Azure technology, to allow organisations to shape their security models around their business needs. In addition to universal security tools and functions which are provided as part of the service offering, a range of additional security layers are ready to be configured.

This level of security is very difficult to achieve internally and is only possible with Dynamics 365 Online because of the wider Microsoft technology surrounding it.

In this article we’ll take a look at the layers of encryption and authentication Microsoft have put into place to secure data in the cloud, as well as how security roles and privileges provide granular security measures for accessing data in Dynamics 365. Finally, we’ll discuss additional steps you could take to further safeguard your data, depending on your unique security needs.

How Microsoft Protects Your Data

Microsoft likes to make it clear; whilst they hold the data and put the measures in place to protect it, you own your data. Your data is encrypted to keep it secure and through the process of authentication, it’s decided who has access to this.

ENCRYPTION

Microsoft’s Dataverse securely stores and manages data used by Dynamics 365 and other business applications. This database uses SQL Server Transparent Data Encryption (TDE), to perform real-time encryption of data when written to disk. This means that even if hackers were able to get to the data, they wouldn’t be able to access the actual information without Encryption Keys.

Encryption Keys are stored and managed by Microsoft. Administers are able to access and self-manage them, but it is highly recommended to allow Microsoft to manage these directly.

Microsoft’s encryption practices don’t just stop there; they also encrypt connections between customers and Microsoft data centres to ensure data is secure during transit. All public endpoints are secured using industry-standard Transports Layer Security (TLS), which ensures protected connections and integrity between desktops and datacentres.

AUTHENTICATION

When it comes to accessing data, only authenticated users who have user rights to Dynamics 365 can establish a connection. Dynamics 365 uses Microsoft Azure Active Directory (Azure AD) to identify users. All Dynamics 365 Online users must have a valid Azure AD account in the authorised tenant. Azure AD accounts can then be associated to other business applications, such as SharePoint, which makes it as simple as possible for users to move between applications.

Beyond this, there are still further authentication actions and processes that strengthen security. Users may be subject to implemented policies which can limit where and when they are able to access Dynamics 365. Conditional access is where Azure AD requires a combination of “signals”, such as user location, the device used, and includes real-time risk detection, to indicate whether access should be granted or not. Using these AI and machine learning signals to create adaptive policies really strengthens data security by adding a further level of protection.

Another verification step that can be used for conditional access authentication is Multi-Factor Authentication (MFA). Once activated, this will prompt users for additional forms of authentication, beyond just username and password credentials to complete a login. This could require a code to be entered which is sent to the user's phone via SMS, or approving a sign-in notification on the Microsoft Authenticator app. Enabling MFA options is widely believed to block 99.9% of automated cyber-attacks.

How Dynamics 365 Protects Your Data

Once Azure AD authenticates the user, each Dynamics 365 application handles authorisation for data use and services within the application. Taking the time to understand the security architecture of Dynamics 365 will help you adjust security settings to match the requirements of your business. This comes in the form of defining and enforcing security roles and privileges.

SECURITY ROLES

Model-Driven Apps, such as Dynamics 365 Sales, Customer Service, Marketing and Field Service, utilise security roles which give users access based on the combination of roles, teams and business units assigned to them. This restricts users to only access the information which is relevant to their role and responsibilities.

Each user must have a security role to sign-in before they can log-in. If an individual user is assigned more than one security role, they will have access to the combination of these on an additive basis. Below are different categories that determine what a user can access with their security role.

• Business units - Your root business unit, is your entire organisation and therefore applies to everyone. But smaller business units can exist to separate those in the organisation by factors like business function or geographical location. We recommend you keep these as simple as possible and manage more granular security issues using role-based security.
  
• Role-based security - A role is a group of permissions that can be assigned to a user. As the name suggests, this tends to be based on the job responsibilities of the user. Permissions include privileges such as creating, reading, updating and deleting records (CRUD) in an entity. Roles can be assigned to one or more entities, and users can be associated with one or more roles. This is why it is suggested that finer detailed security measures are managed at this level. Examples of predefined roles already provided are “System Administrator” and “System Customiser”, but you can edit these and create as many new roles as needed.
  
• Teams - A team is a collection of users. A team security role can be applied, and anyone in that team will be associated to the security role. This can cross business units, to give the same permission to users from different business units.
  
• Hierarchy security - The hierarchy security model can be used to categorise access for users based on their position in the company hierarchy. This is useful when managers need access to records or reports which aren’t usually available for their department.
  
• Record-based security - Apply record-based security to entities and control what action can be taken on individual records by users or teams, by assigning access rights. The owner of a record can share or grant access to the record to another user or team, and choose whether to grant write access, or simply read access. It's important to note, access rights apply after user privileges. For example, if a user doesn’t have the privilege to read Lead records, even if someone were to grant them read access to a lead record, they would still not be able to see it. This can be overridden if the user sharing the record has “sharing privilege” assigned to them.

PRIVILEGES

These are the detailed access permissions assigned to different security roles. Each security role consists of record-level privileges and task-based privileges. Privileges can be assigned at user and team level.

Record-level privileges cover eight different record-level privileges: create, read, write, delete, append, append to, assign and share. You can decide which of these privileges are assigned to a security role, to determine the level of access a user has to a specific record or record type. It is here, that a user can be assigned “share privileges” as mentioned earlier.

However, the detail which can be controlled goes further than entire records. Field-based security allows restrictions to be applied around individual fields on a record. For example, a user might have record-level privilege to read Account records but, due to field-based security, data in the Payment Detail field will be masked.

Task-based privileges tend to be on/off controls, and aren’t based on business units or organisational consideration. Examples of such privileges include being able to bulk delete, publish reports, view audit history and publish duplicate detection rules.

How Preact Can Help You Protect Data

In combination with the information above, here are some extra security measures which Preact can help you set up to reinforce your data security.

Multi-Factor Authentication (MFA)

As mentioned above, this Azure AD control, verifies user identify through an authentication check in addition to regular username and password credentials. We can support your organisation in activating MFA processes to verify a user's identify and complete their login.

Data Loss Prevention Policies (DLP)

The primary purpose of DLP policies is to ensure rules are in place, when creating flows / business processes that connect different sources of data, which prevent organisations from unintentionally exposing sensitive information. As such, Preact helps organisations implement DLP policies to make sure their users stay compliant with organisation guidelines when connecting data.

This begins by classifying all data sources as “Business Data Only” or “No Business Data Allowed”. If a data source is marked as “Business Data Only”, it means this contains sensitive data and therefore cannot be used in a same flow as “No Business Data Allowed” sources.

For example, if you store sensitive client data in Dynamics 365 and SharePoint, you would assign them as “Business Data Only”. Whilst they can be placed in a flow together, other “No Business Data Allowed” sources like Skype or a social connector, such as Twitter, wouldn’t be allowed in the same flow.

We can help you create as many different policies as you need that will cover all scenarios and apply them to your environments.

Auditing

Using the auditing feature, allows administrators to observe changes made to customer records and user access. Preact supports organisations in enabling auditing controls which enable them to spot instances where security roles need further restrictions, understand how team members are using the data, and ensure security breaches are not taking place. For example, Dynamics 365 auditing can be enabled to track:

• Which users access the system and at what time?
• Who created, updated, deactivated or deleted a record?
• Changes in field values
• Changes to security roles and sharing privileges

To avoid the unnecessary volumes of audit data swallowing up cloud storage capacity, we'll help you define auditing controls which only track what you need. For instance, specify which entities you want to track, or go even further by enabling or disabling auditing on specific fields.

Microsoft Intune for Device Management

If you have team members in the field, or employees who work remotely, Intune provides greater protection of business data in the event that trusted devices are lost. We'll work with you to “Enrol” organisation-owned devices in Intune, so administrators can see all the devices enrolled, configure these meet anti-virus threat protections and other security requirements, set up VPN connections, and view user and device reports to track compliance.

Through Intune, your organisation will be able to instantly wipe organisation data if a device is reported as lost or stolen, if an individual leaves, or if a device is no longer being used.

Intune also allows device management at an application level. Administrators can add and assign mobile apps to user groups and devices, configure apps to run with specific settings enables, update existing apps, track usage of apps and do a selective wipe by removing only organisation data from apps. As Intune integrates with Azure AD, it's also easier to implement conditional access policies.

What's Next?

As you can see, there are many available security layers and options which can be configured to match your organisation's unique requirements. Whether you’re considering Dynamics 365, or if your organisation has already deployed the system, consider what security measures you need to give you the best data protection and then review whether those needs are met. Contact Preact if you would like to find out more and discuss what further actions you can take to better protect your business data.