Security workshop topics

50 minutes

This unit focuses on the recommended topics that should be covered in the Security model workshop.

Security model overview

In the Security model overview section of the template, you should provide a high-level overview of the attendees' security model. The details don't need to be extremely granular because each specific area will be discussed in detail later in the template.

Next, answer the question of how you are managing access to records. This information is helpful to know if specific restrictions are in place on data (such as salespeople only being allowed to view their own customer data) or if other special data access information will impact the security model. In addition, this section can include technical details, such as the requirement to have multifactor authentication to access system data.

Basics

Two slides in the template cover basic information about the security model. The following questions are included on these slides.

How many users do you have (target)? - The number of users has a significant impact on the scalability of your security model. For example, if the customer is relying on sharing records to provide access, they should be aware of the potential performance impact when many records are shared between many users. Some security models that are acceptable for small user counts become unsuitable as user count grows. For that reason, it's important to consider current and expected future user growth.
How many distinct security patterns or configurations do you have in your model, and how many users are in each pattern configuration? - Security pattern refers to the different security configurations that the customer wants to implement to answer the requirements. For example, people in the sales department will use the standard use of user security roles, people in customer service will use a combination of user roles and manager hierarchy, and people in marketing will only use access teams. By determining the expected number of patterns, you'll identify if the security model will be overly complicated or difficult to maintain long term.
What percent of users potentially have more complex security requirements than the rest? - Customers sometimes over-complicate their security models by designing around niche exceptions to the standard process. When you identify the existence of many different non-standard requirements, you should question the requirement and recommend standardizing on the main process.
Do you need to restrict access to data or filter access to data? - This question distinguishes between convenience filters and real security requirements. Wanting to provide users with a simplified view of data that matters most to them is a good goal; however, security shouldn't be used to achieve this objective. Use views to filter data while leaving access to other records available.
What number of security roles do you need? - Keeping the number of security roles to a minimum makes administrative tasks easier to manage. Dynamics 365 includes many standard security roles for standard user types like sales manager, customer service rep, and system administrator. These roles should be used as the basis for the customer's security roles.

If requirements differ from standard roles, consider creating copies of standard roles and iterate from them.
Have you created new security roles instead of customizing existing ones? - A recommended best practice is to save a copy of one of the standard security roles rather than creating a new one.

Security roles include many permissions that are required to get into the application, and creating a new role is problematic because the customer likely won't have all necessary base permissions.

Remind the customer that new permissions are frequently added to the standard security roles by using regular application updates, and these new permissions aren't automatically added to existing custom security roles. If custom security roles are used, someone will need to remember to identify the newly added permissions and update the custom security roles following each update to ensure continuity of system access after updates.
Have you tried to reduce the number of security roles as much as possible? - The more security roles that a Dynamics 365 deployment uses, the more difficult it will be to administer long term. When new functionality is added, if 25 separate security roles are available, and the functionality is needed by everyone, then the maker will need to update 25 security roles to provide access to the new feature.

One popular strategy is to use a base role, which provides the baseline of functionality that is needed to sign in to the application and all tables that are available to all users. Next, supplement that role with extra roles with the role-specific features that are needed by that role.

For example, if all users need to read accounts, but only the sales managers should be able to create new ones, your base role would contain organization level account read permission, and the sales manager role would only include account create permission. Then, if a new feature was added that all users need, it can be added to the base role only.
What's the number of security roles that an individual person needs? - The more security roles that need to be added to an individual user, the more complicated user onboarding will become, and the more likely that someone will make mistakes. If many required roles exist, these roles should be consolidated to help make ongoing administration easier.

Another approach that can help is by using Microsoft Entra ID security group or Microsoft Entra ID Office group teams so that you can grant the roles once to the team and then the users will automatically inherit the roles for the team (so, in the context of the team's business unit), after being added to the appropriate Microsoft Entra ID group.
Are the security roles created at the root business unit level or at the child level? - While you can create roles that are specific to one child business unit, we recommend that you create security roles and edit them at the root business unit level.

Creating roles at the root business unit level makes the role available to all business units, while child-level business unit roles are only available at a single business unit level. If you have a business unit-specific role, when you move a user to another business unit, that role won't be available. Otherwise, you'll have different versions of the same role at a different business unit, making the system difficult to administer.
What's your strategy to update the security roles as you roll out new tables and functionality? - In a rapidly changing environment with continuous development, it can be easy to forget to update roles, or only test with system administrator access, and miss updating security roles to include the new functionality. The customer's strategy should include a process for updating security roles and testing with each persona's role mix whenever a new configuration release is rolled out.

Reasons for this information

The reasons why you should ask for the preceding information from your attendees is because:

It's rare that one security pattern suits all user needs and roles. You need to understand how many different patterns you will need to implement in the project.
Complex security models are frequently designed to accommodate the needs of a fraction of users that don't fall into the main model. In that case, an opportunity to challenge could exist if those users couldn't access the desired data in a different manner or elsewhere, such as reporting.

Business units

In this section, you will provide a description of the hierarchical structure of the customer's internal organization and the business unit structure in Dynamics 365. Some relationship should exist between the business unit structure and the organization structure, but the business unit structure shouldn't be as granular as the organization structure. Though two groups are in different divisions of the company doesn't mean that you'll need to restrict visibility of records between the two groups. Frequently, multiple departments can share the same business unit.

Use a tool like Microsoft Visio, or some other visual diagram/charting application, to create a visual representation of the structure. If you already have a document that visualizes the organizational hierarchy of the company, you can paste a screenshot of that diagram in the document.

Be aware of two potential issues: too many business units or not enough business units.

Too many business units

If the proposed security model identifies that hundreds or thousands of business units will be available, this issue should be flagged as a risk. Business units are like large granite rocks; they are designed to be permanent and infrequently moved. While users can be moved between business units, it's not a trivial matter, especially if they own many records.

When you move a user from Business Unit One to Business Unit Two, the business unit association of every record that the user owns will change. This factor can cause some surprises to other users who are members of the user's original business unit, if they have business unit level read permission. The records that are owned by the moved user will no longer be available to them, but if they own child records of those records, like activities, it could cause odd scenarios to occur. Also, if the user owns many records, moving users between business units can be time-consuming.

Another potential impact from large quantities of business units is extremely slow security role updates. Each role isn't only one record. A copy of each role is added to each business unit. Therefore, if you create thousands of business units, making a small change to a security role could take hours.

A good practice is to keep your business units to a minimum. Use only the minimal number to facilitate true business unit security requirements. For more granular user segmentation, consider the use of teams. Teams are more flexible, they can be used to control security access to records, and users can be members of multiple teams.

Not enough business units

If you're implementing for a single group, it's common to only want to use the root business unit for all users.

While the "keep it simple" approach is great, a strong possibility exists that the customer might, at some point, have some pieces of data that they want to keep secret from a subset of users.

Consider the following scenarios:

You expand Dynamics 365 usage to other parts of the company.
Your company is acquired by a large, multinational company.
The CEO decides to track emails and doesn't want everyone to read them.
The VP of sales discovers several contacts in their address book that need to be in Dynamics 365 but are better kept private from the rest of the company.

Moving people between business units is difficult, and it's a process that you'll want to do only when necessary. If the customer starts with all users in the base business unit, if a change develops that requires a subset of data to be separate, the customer will have to relocate many or all existing users because the root business unit can't be reparented.

To guard against this eventuality, it might be a good idea to initially create one child business unit and then put all users in that business unit. If your business changes to require further segmentation of data, this approach will help simplify those changes because the business unit with the bulk of users can be reparented, or selected users, like the CEO, can be moved to the base business unit. A full-scale business unit move of all users can be avoided.

Teams

The Teams section of the Security model template captures details regarding the planned use of team records for security in Dynamics 365.

In this section, you will provide answers to the following questions:

Do you use owner teams to assign roles to users? - Owner teams (including Microsoft Entra ID security group and Microsoft Entra ID Office group teams) are a great way to assign security roles to users and to reduce administration effort. When a security role is assigned to a team, it's inherited by the member users but applies in the team's business unit scope.
Do you use owner teams to own records? - Team ownership of records can be considered to manage the association of a record with a business unit separately from the otherwise standard owning user's business unit. This approach can be helpful when the functional association of a record and a business unit differs from the user's association with a business unit.

Some downsides and risks are associated with team ownership of records that you should be aware of. Generally, it requires automation to be consistent and user-friendly. Some features, such as goals and forecasting, rely on user ownership of records. Also, the ability to reassign a user's records in bulk (for example when a new salesperson replaces a retiring salesperson and inherits their customer portfolio) isn't available for owner teams.

Team ownership of records can be used to simplify complex security models and reduce the need for excessive record sharing. Owner team roles grant special security permissions in the context of records that are owned by the team. Therefore, if members of a sales team should have the right to edit opportunities for which they're associated, but read-only for opportunities that they aren't associated with, owner security teams can enable this exception without having to use complex sharing.
Do you automate record assignment and how? - When a new account is created, you need to determine how you will assign the record. Additionally, you should consider whether the sales coordinator will remember to accurately assign the record manually. For important record types, such as accounts, we recommend that you have an automated process that automatically assigns records when they are created to simplify ongoing administration of the system. One approach could be storing sales person assignment by state on the territory record in Dynamics 365. Then, when a new account is created, a Microsoft Power Automate flow runs. It compares the state of address one to the territory state field and assigns the account to the appropriate territory and salesperson. Then, it sends a notification email to the salesperson to tell them to contact their new potential customer.
Do you use access teams (system or manually managed)? - Access teams are great solutions to managing special record permissions. For example, if a sales assistant needs to have edit permissions on 25 different accounts, rather than sharing the accounts manually with them, you can add them to an access team subgrid on the record, and then they'll inherit edit permissions based on the access team template that is associated with the grid. Access teams are excellent solutions because only one sharing record for the entire access team is created in the POA table rather than individual records for each person, like record sharing does (see the previous Sharing section in this module). This approach also allows administrators to see who has access to the record.

If the same group of people needs access to multiple records, access teams can also be used to share the records with that team. However, keep in mind that an access team can't own records and they can't be assigned security roles.
Do you automate access team membership? - It's common to have a matrix of people who need access to records. For example, a manufacturing project needs an engineer, an electrician, and a safety engineer. Frequently, these assignments are maintained in another system.

In this case, the access team should be used because the mix of individual people is different on each record and security access is needed for the members of the team. You can automate access team membership by using approaches like integration, actions, or plug-ins.
How do you deploy access team templates across environments? - Access team record permissions are established by an access team template. The template determines what permissions are shared with the members of the team.

One challenge is that access team template records aren't solution aware, meaning that they can't be added to solutions. When customizations are moved between environments, the access team template will need to be moved or manually recreated in the target environment. If you're automating an access team membership, the templates must have identical GUIDs across environments, as they're referenced in your logic.

Multiple approaches are available for you to use to migrate access team templates, including the configuration data migration utility, ETL tools like Scribe or SSIS, or utilities in the XrmToolBox.
Do you use Microsoft Entra ID synchronized groups to manage access rights? -Microsoft Entra ID security group teams or Microsoft Entra ID Office group teams are great for automating the assignment of role permissions to users and should be considered for larger or more complex deployments.

With Microsoft Entra ID, you can fully control permissions from a single source.
Do you have requirements that didn't fit into the standard model? - Identify non-standard security requirements. In the findings and recommendations section, recommend approaches to standardize non-standard requirements.

Implemented security mechanisms

In this section, you will identify what methods are used to automate security, including automated sharing, field-level security, hierarchy security, plug-ins, and relationship behaviors. Refer to the security tools section of this module if you're unfamiliar with any of these approaches.

Reasons for providing this information:

Performance issues can occur if you automate sharing at scale. The PrincipalObjectAccess or POA table is filled with exceptions to the standard security model.
Sharing should typically remain a manual process to grant exceptions to the security model that is in place and should be avoided at scale.
While it's easy to adjust a user's business unit, teams, and roles, it can be complex to do a data migration on custom sharing rules after a reorganization.
Field-level security isn't user or business unit aware.
Hierarchy security can cause performance issues in complex configurations if too many levels are in the depth of the hierarchy.
Cascading behavior in relationships is convenient, but it can sometimes have unintended consequences (such as reassigning closed activities when an account is reassigned). Cascading assignment or sharing can be disabled or modified on a relationship basis, or by using an ORG DB setting of DisableImplicitSharingOfCommunicationActivities.

User interface

Many components of Dynamics 365 are security role enabled, meaning that access to that item can be limited to one or more security roles. This feature is important because different users require different experiences while using common tables, and by limiting access to app components that aren't needed by users, you will provide a simpler, more tailored experience for the user.

Items in Dynamics 365 that can be role-enabled include:

Model-driven apps
Dashboards
Forms
Business process flows
Site map subareas
Command bar buttons
Document templates

In this section of the template, you will identify if roles are being used to simplify access to these areas.

Reasons for providing this information:

Security roles and table privileges can be used to tailor and trim the experience for your users.
The fewer elements that users see, the easier the experience will be.
Model-driven apps can be associated with security roles and help simplify the overall user experience by trimming the list of views, charts, dashboards, forms, and business process flows.
Customers without a strategy in this area might experience unexpected issues. For example, the common Microsoft apps like Sales Hub, Customer Service Hub, and App for Outlook will control access by using app access security roles. If a customer tests with only a system administrator role, they might miss the fact that users without this role need the app access role to use the app (or the app needs to be shared with their custom security roles). This scenario can lead to users not having access to the apps that they need during deployment.

Scalability, performance, and maintainability

In this section of the template, you will examine questions that will identify if potential issues might occur when the application scales to additional users and the amount of data increases.

Maintenance questions and why they matter

Answer the following maintenance questions in the template.

Have you identified scenarios where the record doesn't need to be owned by a user or team? - When creating new tables that represent cross-company referential data and will never need granularity for each business unit, team, or user, you should consider creating them as organization-owned tables.

Record ownership is important where variable visibility or editing permission will need to be granted to different users. However, if general records exist that should be visible to all users, and all users share the same level of edit permissions (such as records that are generated by using an integration), a strategy such as assigning records to the business unit team should be considered so that these records don't need to be reassigned when someone leaves the company.
Have you identified potential scalability challenges in your security design at higher volumes? - Strategies like record sharing can work adequately in smaller deployments but can quickly become inefficient when scaled to large numbers of users.

Also, having users be members of thousands of teams in thousands of business units can be a challenge in terms of performance and scalability.
Have you considered the impact of your data and security models on the POA table? - Excessive sharing leads to a large POA table and can degrade system performance.
Do you regularly update user, team, or business unit records? - As a general rule, regular updates to user, team, or business unit tables should be avoided. For example, updating an attribute on a user table can cause the security cache to flush and potentially impact performance.
Have you considered the impact of a large reorganization to the users, teams, business units, and records? - Business structures change. New companies are acquired, divisions are divested, and people leave or move to other departments. Your structure should be flexible enough so that you can easily add or remove users, teams, or business units without requiring a complete security model redesign.
For users who already have access to a large percentage of records, have you considered providing global access for better performance? - Providing organization/global read access to records can optimize performance for the implementation of a view because the system doesn't have to consider the security principles that apply to a user (individual roles, team roles, shared records, hierarchy) when retrieving records.

While a user might have access to all records from a security standpoint, you should customize system views that will filter the number of records to only present what is relevant to their work.
Do you bulk reassign records when a user leaves? Have you considered the impact of a cascading relationship? - Relationship cascading settings for activities and other common records can cause unexpected results when you are reassigning records, and this behavior should be modified if you don't want to have closed activities reassigned when you reassign customer account and contact records.

Security testing

The security model is composed of multiple parts working together, and it has multiple areas where it could fail. In this section of the template, you will review the approach that will be used for testing security, identify the ongoing plan to monitor access to Dynamics 365, and ensure that the design of security roles is well documented and will be simple to maintain long term.

Security questions and why they matter

In the security testing section of the Security model template, answer the following questions.

Do you have test environments to validate the data in the context of your security requirements? - To adequately test security roles, your customer will require a non-production environment with the same configuration as production and a close approximation of the production dataset. While you don't require 100 percent of the data from production, the data must be similar enough to accurately test the behavior of security roles. It's also important to have distinct test users and not reassign roles to the same test users. The reason is because users who originally have higher permission might retain access to certain records when that role is removed by using record ownership or sharing.

Do you have the security matrix Excel sheet with access levels and privileges defined by your business or customer? It's important to have some documentation of security design outside of the Dynamics 365 security role in case someone changes the security role in Dynamics 365 and you want to remember how it was designed. This document can be an Excel spreadsheet that indicates the appropriate permission level by table.
Do you have test cases around the security matrix for all security roles? - The customer's security requirements likely came from the requirements that were gathered during the previous workshops in the project, and these requirements create the basis of security test cases. Each security restriction should have a test case and be tested thoroughly before go live. Then, the restrictions should be tested in the context of each impacted security role or persona.
Have you considered negative testing on field-level security fields and teams? - It's important to test if someone with a role can see secured fields and can access records that are assigned to their team. Additionally, you should verify that users without these roles or team assignments can't access these items.
Will you perform penetration tests on the platform? - For highly secure environments, penetration testing is an option. Keep in mind that penetration testing must follow the Microsoft Cloud rules of engagement for penetration testing. For more information, see Penetration testing rules of engagement.

Security monitoring

In this section of the template, you will review the customer's strategy for monitoring appropriate access rights and will identify misuse of the application. If activity audits are enabled in Dynamics 365, many user activities are logged in the Microsoft 365 admin center. By using these logs, you can identify unusual or potentially malicious activity in the system, including common actions such as:

Who published customizations
Who was added to a team
Who added a solution
Who published customizations
Who exported to Excel
Who viewed a report
Who exported a report

Standard audit logs monitor when users access the system. Tools like Microsoft Power Automate can alert you when certain activities happen, and Microsoft Entra ID can alert you when people outside of the usual geographies attempt to access the system.

In this section of the Security model workshop template, you will summarize the strategy for monitoring and alerting abnormal behavior and plans to regularly verify user permissions in Dynamics 365.

Regulations and compliance

In this section of the template, you will identify if governmental or compliance regulations are in place that might impact the security model for Dynamics 365. These regulations include consumer data protection regulations like HIPAA, and SEC and auditor concerns like business segmentation. Complete the information in the regulations and compliance slide.

Security beyond Dynamics 365

In this template section, you will look beyond Dynamics to other systems that integrate with Dynamics 365 and associated security. Dynamics 365 is not autonomous; other systems interact with it or are integrated with it. Therefore, you should take a holistic view of security, not just security for the individual pieces. Update the Security Beyond Dynamics 365 slides to answer the following questions.

Have you associated your environments with a security group to control users who have access to it? - Associating a Dynamics 365 environment with a Microsoft Entra ID security group will limit access to the environment for users who are outside of the group and will limit the users who show as enabled in the system. It also simplifies the experience for users because they'll only see the environments that they have access to appear in the environment list.
Do you use Conditional Access in Microsoft Entra ID to control how users access your Office 365/Dynamics 365 data? - Conditional Access in Microsoft Entra ID can be used to limit from where and from what device the environment can be used and what services and connectors can be used.
Do you use mobile device management to manage a fleet of devices (mobile phones and so on)? - By using mobile device management (MDM) solutions, like Microsoft Intune, you can enforce security, remotely manage the deployment of Dynamics 365 mobile apps, and also remotely remove data in case the device is lost or stolen.
Do you integrate with SharePoint? If yes, how are you addressing security in SharePoint versus security in Dynamics 365? - SharePoint document integration automates the creation of document libraries in SharePoint from Dynamics 365 records and provides quick access for Dynamics 365 users to documents that are stored in SharePoint. Security can be a concern because the SharePoint document library security doesn't mirror Dynamics 365 security. If someone has access to the SharePoint site where Dynamics 365 documents are stored, they can view the documents in the library, even if they don't have access to the related Dynamics 365 record. If this situation is a concern, you should consider alternatives where access rights are narrower on the SharePoint side (for example with multiple SharePoint sites, OneDrive for Business integration, or Teams integration).
Do you integrate with Microsoft Power BI? If yes, how are you addressing security in Power BI versus security in Dynamics 365? - When Power BI is reporting directly from Dataverse by using the standard Microsoft Dataverse connector, it reflects only the data that the user has access to in the system. However, if that Power BI report is shared, other users with whom the report is shared will see the data from the report owner.

Row-level security can be implemented to enforce security on the Power BI side, but another option is to create a SQL DirectQuery report in Power BI that will render in the connected user context. Then, sharing a report will only result in sharing the representation of the data, not the actual data, and the Dynamics 365 security model will be fully enforced.
Do you use other security mechanisms? - Other security mechanisms might include multifactor authentication, external authentication providers like OKTA, and others.
Does your security model hold dependencies on independent software vendor (ISV) solutions? If yes, what are they? - ISVs provide valuable solutions that can enhance a deployment of Dynamics 365, but they can also introduce security risks and dependencies. It's important to understand how this solution will be deployed, how it will be updated, and what kind of security access that the ISVs will require.
What are your requirements for data integration security patterns? - When data flows between systems, it's important to understand when security will need to be controlled at the flow level. Make sure that you determine what security access that the integration will need to the source system, what security access that the integration will require in Dynamics 365, and what account that the integration process will run as. We recommended that you use application (non-interactive) users to control access for integration accounts.
If you're using other Microsoft Power Platform capabilities such as Power Automate and Power Apps, what are your security requirements and design? - Power Apps and Power Automate use connectors to integrate to hundreds of different systems, and these tools are part of the same platform as Dynamics 365. Canvas apps in Power Apps and Power Automate flows use Dataverse, as does Dynamics 365, and apps and flows can be managed in solutions along with other Dynamics 365 components in solutions. The introduction of other connectors into the process introduces a number of additional security considerations, including data access and security in those systems and environment strategy for where apps and flows that touch production Dynamics 365 are being built. Other security considerations include access for makers who are connecting to your production Dataverse environment and data loss prevention (DLP) policies that determine which connectors can be used together. The solution architect should ask clarifying questions around Microsoft Power Platform environment strategy and DLP strategy, and then identify what permissions that users will have for making apps and flows.
Do you have specific infrastructure security requirements (encryption and so on)? - Dynamics 365 offers advanced encryption options, including customer-managed keys for eligible scenarios. Identify if these options are used and whether the customer has established a strategy to maintain these methods long term.

Continue