Security module overview
In this template section, you 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.