Dynamics 365, powered by Azure technology, enables organisations to tailor security models to their needs.
In addition to universal security tools and functions provided, 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 because of Microsoft Cloud technology.
In this article, we’ll look at the layers of encryption and authentication Microsoft has put into place to secure your data in the cloud. Also, we’ll focus on security roles and how privileges provide granular security measures to access data in Dynamics.
Finally, we’ll discuss what additional steps you can take to safeguard your data.
How Microsoft Protects Your Data.
While Microsoft stores your data and puts the measures in place to protect it, you ultimately own it. Your data is encrypted to keep it secure, and it’s decided who can access it through the authentication process.
ENCRYPTION
Microsoft Dataverse securely stores and manages data from Dynamics 365 and other business applications. This database uses SQL Server Transparent Data Encryption (TDE) for real-time data encryption. This means that even if hackers could access the data, they wouldn’t be able to access the information without Encryption Keys.
Encryption Keys are stored and managed by Microsoft. Administers can access and self-manage these, but it is strongly 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 secure data during transit. All public endpoints are secured using industry-standard Transports Layer Security (TLS), which provides protected connections and integrity between desktops and datacentres.
AUTHENTICATION
To access data, only authenticated users with user rights to Dynamics 365 can establish a connection.
Dynamics 365 identifies users using Microsoft Azure Active Directory (Azure AD). All Dynamics 365 Online users must have a valid Azure AD account in the authorised tenant.
Azure AD accounts can be associated with other apps, such as SharePoint, making it simple to move between applications.
Beyond this, there are further authentication actions and processes that strengthen security. Users may be subject to policies which limit where and when they can access Dynamics 365.
Conditional access is where Azure AD requires a combination of “signals”, such as user location and the device used. This includes real-time risk detection to indicate whether access should be granted. Using these AI and machine learning signals to create adaptive policies will strengthen data security by adding further protection.
Another verification step that can be used for conditional access authentication is Multi-Factor Authentication (MFA). Once activated, MFA prompts users for additional forms of authentication beyond just username and password credentials to complete a login. This could require a code to be entered, 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.
Dynamics 365 Data Security.
Once Azure AD authenticates a 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, use 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 information relevant to their roles and responsibilities.
Each user must have a security role 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 users 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 assigned to a user. As the name suggests, this tends to be based on the user’s job responsibilities. 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 with the same 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 categorise user access 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 – As implied, this security for entities controls what actions users or teams can take on individual records. The owner of a record can share or grant access to a record to another user or team and choose the level of access. It’s important to note access rights apply after user privileges. For instance, if a user doesn’t have the privilege to read Lead records, even if someone were to grant them read access to a specific lead record, they would still be unable to open it. This can be overridden if the user sharing the record has a “sharing privilege” assigned to them.
PRIVILEGES
These are detailed access permissions assigned to different security roles. Each security role consists of record-based and task-based privileges that can be assigned at user and team levels.
- Record-level privileges – cover 8 privileges for: 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 user access level to a specific record or record type. Here, a user can be given “share privileges”, as mentioned above.
- The detail that 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 the 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 considerations. Examples of these privileges include bulk deleting, publishing reports, viewing audit history and publishing duplicate detection rules.
How ANS Help.
Combined with the above, we’ve highlighted additional security measures that our team can help you set up to bolster your data security.
Multi-Factor Authentication (MFA)
As mentioned above, this Azure AD control verifies user identity through an authentication check. We can support your organisation in activating MFA processes to verify a user’s identity 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 and business processes that connect different data sources to prevent organisations from unintentionally exposing sensitive information.
We help organisations implement DLP policies to ensure their users comply 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 will contain sensitive data and cannot be used in the same flow as “No Business Data Allowed” sources.
We can help you create as many policies as needed that will cover all scenarios and apply them to your environments.
Auditing
The auditing feature allows administrators to observe changes made to customer records and user access.
We support organisations in enabling auditing controls to spot instances where security roles need further restrictions, understand how team members use the data, and ensure security breaches are not occurring. For example, Dynamics 365 auditing can be enabled to track the following:
- 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 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 if trusted devices are lost. We’ll work with you to “Enrol” organisation-owned devices in Intune so that administrators can see all the devices enrolled, configure these to meet anti-virus threat protections and other security requirements, set up VPN connections, and view user and device reports to track compliance.
Using Intune, your organisation can instantly wipe organisation data if a device is reported as lost or stolen, if an individual departs, 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 enabled, 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.
Dynamics 365 Data Security: Next Steps.
As you can see, numerous security layers and options can be configured to match your organisation’s unique requirements.
Whether you are 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.
Contact our experts to learn more and discuss what additional actions you can take to protect your business data.
