Introduction
To ensure that the customer's deployment of Microsoft Dynamics 365 is more secure, the solution architect should plan and deliver a Security model workshop. The workshop's goal is to evaluate the proposed security model and provide feedback and recommendations that highlight the technical risks and issues and then identify best practices.
The Security model workshop should be scheduled and completed during the implementation phase of the project. It should provide a summary of all security-related areas that were previously discussed during prior workshops.
You can download examples of templates for each module workshop and use them when you conduct these workshops for solutions.
Why security matters
Dynamics 365 drives your customers' businesses. Sensitive business data regarding customers, financial information, and business critical processes in the system needs to be secure for customers who adopt the system.
The correct security strategy balances legitimate security requirements with the need for system access and cross-business collaboration. When implementing Dynamics 365, you need to balance two concerns: user access and system security.
From one viewpoint, the concern of data and system security is important. Your data drives your business. Your customers, your orders, the contact information for key business contacts are items that you don't want to fall into the hands of a competitor. With regulations surrounding personal data, your company could be liable if a data breach impacts personal data.
Alternatively, you have system usability and user adoption concerns. A main reason for implementing Dynamics 365 is to increase visibility and sharing of business data between groups, including elimination of data silos in your organization. By giving visibility to contacts and accounts across your organization, teams can effectively collaborate rather than compete, which helps ensure that you have one version of the truth when it comes to master contact and account information. If you go too far in either direction, you risk failure of your implementation.
If you're too lax with security, users can change data that they shouldn't be able to change, thus polluting the single version of the truth and creating a perception that the data in the system isn't reliable.
If too stringent in your security, and if you secure everything so that users can only see a small subset of the records in the system, you will diminish the value of Dynamics 365 as a collaboration tool. Then, by design, you will revert to the old data silos, only in a different location.
Security model considerations
Before exploring the workshop details, the following sections will review key security elements that are common to most Dynamics 365 implementations.
Build a security strategy
While everyone's security strategy will be slightly different, the following guidelines might be helpful for your implementation.
Be more restrictive about write than read
To maintain good data quality, limiting who can edit or delete records is a good idea, such as limiting edit or delete rights to only owners of the records. Frequently, it makes more sense to be less restrictive about what records other users can read. This approach preserves the usability of Dynamics 365 and allows users to maintain context about how their records relate to other records, such as parent accounts. However, the approach removes the risk that users might, by malice or mistake, edit or delete records that they don't own.
Simplify
Many tools are included in the Dynamics 365 security toolbox; however, before you decide to use all of them, consider how simple it might be to manage the security model long term. If the administrator needs to remember to assign four different roles to a new user, and then add them to multiple teams for the security model to work, the customer is unlikely to be able to maintain the strategy long term. The solution architect should consider the impact of the security design on user experience. Additionally, they need to determine how complex the management of the security strategy will be for system administrators. The best security strategies are simple, well documented, and reproducible. For this reason, using features like Active Directory security groups is a great idea for larger more complex deployments because the role, team, and business unit assignment can be automated, and the chance of human error is minimized.
Ensure that security design is based on legitimate business requirements
Make sure to determine whether your decisions about security design are deriving from a position of fear or from a legitimate business concern. If from fear, perhaps the decision is being driven by a mistake that someone has made in the past. Fear is never a good design motivation, especially fear of your employees. You trust your employees to do their jobs, represent your company, and sell your products. Occasionally, overly stringent security design indicates fundamental trust issues between management and employees.
Document and reevaluate your security design
Security design is a concept that's considered at the beginning of a Dynamics 365 implementation, but it will occasionally be overlooked thereafter. Periodically, as the customer's usage patterns change, or their user base changes, the initial security design decisions aren't the best fit and need to be adjusted.
For example, when you have a smaller user base, a single business unit design can work well. However, if your user base grows and encompasses multiple departments with diverse requirements, you might need to add more units to scale your deployment to a larger user base. No absolute rule has been established; the best practice is to periodically review security strategy and design, evaluate its strengths and weaknesses, and then identify areas for improvement. For this reason, documenting the security model as part of the Success by Design framework is important because it creates documentation that can be revisited intermittently by the customer and consultant and then updated as security requirements change.
Security strategy drives configuration choices
As the customer or partner designs their table structure, they need to keep their security strategy in mind. Table configuration supports your security strategy. For example, if tables are created with organization level ownership, the customer will be unable to restrict table record access by ownership or business unit. Even if you don't have plans to restrict access to the table, it's a best practice to always select user or team ownership, unless the table will be used only for cross-company reference data, such as feeding a lookup list. Also, keep in mind how security of one table should affect related table security. If access to a parent record should cascade to the child records, you will want to use parental or configurable cascading relationship types.
Security at the platform layer, not the app layer
Numerous ways to control reading and editing data are available. You can set fields to read-only on your model-driven form, use JavaScript to mask fields from the user experience, and hide fields from forms and views. None of these approaches are considered security because, while these approaches guide user behavior, they don't secure the data. Users can get to the data in other ways. For real security to occur, you need to use security features like roles, teams, and business units.
Security model components
Dynamics 365 provides several tools that you can use collectively to meet almost any security requirement. This section briefly covers the primary tools that are available to a solution architect to deliver a comprehensive security model.
Business units
Business units provide a framework to define the organizational structure of your users and records in Dynamics 365. Business units will group users and teams by organizational hierarchy and can work with security roles to grant or restrict access to data.
The capability of business units comes from the hierarchical nature of the business units. Users can be given access to records only in their business unit, or they can have access to their business unit and the business units below their unit. For example, the hierarchical nature of business units can allow you to limit access to records at the site, district, region, and corporate levels.
Factors that you should know about business units:
The root business unit is created when a Microsoft Dataverse database is provisioned.
A user or a team can only be a member of one business unit.
Records are tied to only one business unit through their owning user or team.
A user or a team can be moved to a different business unit. When you are moving a user or a team between business units, all records that are owned by the user or team might need to be reassociated with the new business unit, and people with business unit level read security in the old business unit will lose access to those records.
When you are moving a user or a team to a new business unit, all security roles will need to be reapplied to the user or team.
Non-root business units can be deleted after they're disabled.
Business units can be moved in the hierarchy, but the root business unit can't be reparented.
Business unit structure typically resembles a company's organizational chart, but it should not need to be as granular as your organization chart, unless you have a specific business reason to do so. You should see business units as building blocks for your security model. In most cases, you don't have to create a business unit for each department in your company. For example, at one site, the sales and marketing departments might be able to share the same business unit if records don't need to be restricted between groups. Keep in mind that security roles work with business units, so though sales and marketing are in the same business unit, all users won't necessarily be able to see all records if their security roles limit them to user level.
Security roles
Security roles determine the permission level that users have within the entities in the organization. Security roles can be assigned to the users or teams. Security roles determine which entities that the user can access, which records within the table they can act on, and what permissions that they have with those records.
When assigned to a user or a team, the security role always applies within the scope of the business unit of the user or team. Therefore, if a user inherits a security role from a team, the privileges that are granted by that security role will apply in the scope of the team's business unit, not the user's. This approach can be useful to extend the access rights scope of a user to other business units. For example, using the preceding business unit diagram, a user from the Chicago Office business unit can be added to a team that is linked to the Atlanta Office business unit, and they can be granted read rights to the business unit's records.
Teams
Teams is another way of grouping users and can play a role in your security strategy. Multiple types of teams are available in Dynamics 365:
Owner teams can be assigned security roles and can be used as record owners in Dynamics 365. When a user is added as a member of an owner team, they inherit from the team's security role, but the role applies in the context of the team's business unit. Owner teams can be useful when you are linking a record to a specific business unit.
Microsoft Entra ID security group teams are similar to owner teams, but they are linked with a Microsoft Entra ID security group. Users who are added to the Microsoft Entra ID security group with a Dynamics 365 license are automatically enabled in the system, and they are added to the linked Dynamics 365 team when they connect to the environment. This feature is useful when you are managing user access rights outside of Dynamics 365 because users can inherit the security roles that are assigned to the Dynamics 365 teams.
Microsoft Entra ID Office group teams are similar to Microsoft Entra ID security group teams, except that they use an Office 365 group instead of a Microsoft Entra ID security group. The primary difference is that Office 365 groups can be created, and group management can be performed by people who aren't Active Directory administrators.
Access teams are special types of teams that can't own records and can't have security role association. However, like owner teams, access teams can have shared records with them. When enabled at the table level, access teams can grant specific record level permissions to the member of the record's access team. This option is an alternative to manually sharing the record with a user or a team. For entities that are configured for access teams, creation of these teams is automated by using access team templates.
When assigning a security role to an owner team (including Azure AD security group teams or Microsoft Entra ID Office group teams), its member's privilege inheritance setting should be checked to ensure that it's set properly. This setting can allow users who are members of the team to inherit user-level privileges, as if the security role had been directly assigned to them. This feature is useful when you are allowing users to own records in their name, even though they don't have a security role directly assigned to them. For example, with this setting, users can own personal views. With owner teams, security roles don't need to be granted directly to individual users, which helps reduce administration effort.
Hierarchy security
Hierarchy security can be used to grant visibility for user-owned records to that user's management and higher levels of the hierarchy. For example, if a sales manager with a team of five people needs to see records that are owned by someone on their team, hierarchy security can provide that access. Hierarchy security supports two different hierarchy models:
Manager hierarchy - Grants access based on the manager relationship. With the manager hierarchy security model, a manager has access to the records that are owned by the user, or by the team that a user is a member of, and to the records that are directly shared with the user or the team that a user is a member of.
Position hierarchy - Grants access based on definable position levels. This model is useful when security access needs to be provided based on indirect reporting structures. With the Position hierarchy security model, a user at a higher position has access to the records that are owned by a lower position user, or by the team that a user is a member of, and to the records that are directly shared to the user or the team that a user is a member of.
Field security
Field security allows you to secure data at the field level, such as when certain users need to view or edit a record but shouldn't see specific details. This feature is important in situations where data needs to be truly secure because it's secured at the platform layer. Essentially, whether a user signs in to a model-driven app or a canvas app, exports data to Microsoft Excel, or runs a report, field security profiles will secure the data.
After a user has been granted access (for example, read) to a set of secured fields through a field security profile, they're granted access to those fields on all records that they have access to with their security configuration or through sharing.
Sharing
Sharing allows specific record-level access to be granted to specific users and teams. Use of sharing should be limited to handling exceptions, when possible. Previously, it was common to use and automate record sharing for complex record access scenarios. Sharing can be a beneficial approach because it gives administrators and users, who have the appropriate permissions, the ability to grant specific permissions to specific records and it is useful for handling exceptions to the rule. For example, if you need to have Salesperson A handle Salesperson B's accounts while they are out for a month, sharing can help you accomplish that task. Sharing can also be automated, meaning that if you need a specific condition to automatically share records with a user or team, simple plug-ins, workflow assemblies, or ETL tools can be used to do that. This feature has been the answer to many Dynamics 365 customers' challenging security requirements in the past.
While sharing is a useful feature, it also creates multiple potential issues, including:
Performance - Sharing is facilitated by the principal object access (POA) table. When you share a record with a user or team, a record is created in the POA table that contains the ID of the user, the ID of the record, and the permission that they should have. The cascading nature of sharing means that if a parental or configurable cascading relationship exists that is sharing enabled, the child records in those relationships will also be shared with the user or team (and more records will be added to the POA table). Complex reparent or inherited share scenarios can also create records, which can cause the POA table to grow quickly. This scenario becomes a performance issue when the table expands (somewhere between 20 million and 2 billion records). When you query Dynamics 365, such as when opening a view or advanced find, or when viewing a chart, the results are filtered by the POA table. If the table is large or indexes aren't optimized, it can lead to slow system performance.
Administration challenges - You can't easily identify which records are shared with a user. While you can select a record and show whom it is directly shared with, a method doesn't exist to help you to accomplish that task for all records. Also, cascading or inherited shares don't show in the sharing dialog on the record. Without opening each record in the context of that user, it's almost impossible to know if your sharing strategy is working correctly.
Forgotten shares - Previously, a scenario was explained where you shared Salesperson B's records with Salesperson A, who handled their coworker's accounts while they were off for a month. Odds are that the administrator will forget to stop sharing those records, which could create issues if Salesperson B needs to reconnect to people in their workflow.
Can't make it right - After the customer uses the system for a year or two, they might find that it has become inaccurate or out-of-date. They might also decide to make a wholesale change to their sharing strategy; accordingly, they want to run a batch job to set and update all records with the appropriate sharing permission. No simple method exists for completing this task with sharing.
Alternatives to sharing
Steps that you can take to avoid issues with sharing include:
Use team ownership - With team ownership, you can assign records to teams of users in multiple business units.
Share with teams, not users - If you share a record with 10 users, 10 POA records will be created, times 10 POA records for each child cascading shared record. If you share the record with a team that has 10 users, only one POA record is created (along with one POA record for each cascading share). This approach will help reduce the size of your POA table dramatically. If you want to remove a user's permissions, you can remove them from the team.
Use access teams for controlled sharing - Use this approach if you can't create owner teams but still want to be able to grant special access to specific records to specific users. In this scenario, you want to give certain users access to only read the record, while you want other users to be able to read or write to the record. Access teams can handle that situation, and you can have multiple access team templates, one for read and one for read/write. Access teams are designed with performance in mind, so they don't actually create the team and share the record until you add the first member of the team. When a record is shared with an access team, a record is also created in the POA table.
Sample security scenario
The following scenario explains how these tools can be combined to provide a comprehensive security model. In this example, Contoso LTD is a consumer products company that wants to ensure that users have access to information that is necessary for them to do their job while protecting sensitive data. By combining the security tools in Dynamics 365, the company can address each of the following scenarios.
Bob
Field-level security prevents Bob from seeing sensitive information on a record, and team or business unit security limits their view to only the company's issues.
Manufacturing engineer
Needs to be able to see quality issues that are reported by clients
Shouldn't be able to see the email and mobile phone of the client
Shouldn't be able to see issues for other companies
Amy
Business unit security means that Amy can see records that are owned by someone else in the division, but that Amy can't see or edit records in other divisions.
Customer service rep
Creates customer service cases from use complaints
Should be able to see customer information and case history for clients that use her division’s products
Shouldn't be able to see customer data for other divisions
Roy
Hierarchical security enables Roy to see records that are owned by their direct or indirect reports, but not other users.
Sales manger
Needs to see his direct reports' records
Shouldn't see data for other sales managers
Linda
Linda’s security role provides organization-wide visibility for data in Dynamics 365.
General manager
Needs visibility for all customer data and related issues
Security model workshop
The Security model workshop should be limited to about one hour and is often conducted as part of a Microsoft Teams meeting when everyone isn't together on site. Attendees should include key stakeholders from the customer and partner teams. Solution architects, functional leads, and technical leads are mandatory.
The security details from the Solution blueprint workshop template should be referenced in preparation for the Security model workshop.