Security Overview for FusionOps¶
Implementing security for FusionOps development ensures that solutions have sufficient guardrails and governance and can be scaled safely.
This section provides the following considerations:
- Overview of Power Platform platform's out-of-the-box security capabilities and corresponding roles.
- A security checklist by role: Citizen Developer, Professional Developer, IT Professional, and Security Professional.
- Curated references.
Six Layers of Security¶
Security constructs can be conceptualized as the Six Layers of Security for Power Apps, Power Automate and Power Virtual Agent. Each can be implemented independently, but ultimately all layers complement one another. Security for Power Pages is different due to its target audience and use cases.
The table below provides information about each layer and the role responsible.
| Layer | Description | Docs Reference | Roles Responsible |
|---|---|---|---|
| 1. Tenant access and isolation | User authentication is done via Azure Active Directory (Azure AD) meaning security measures like group policies, and conditional access may apply. Tenant isolation allows admins to effectively govern the movement of tenant data from Azure AD authorized data sources to and from their tenant. Simultaneously, it minimizes the risk of data exfiltration outside the tenant. There are three built-in administrative roles for Power Platform at tenant level: - Global Admin roles have full administration to all services in tenant including administering Dynamics 365, Power Platform Administrator. - Power Platform Administrator roles can create and manage all aspects of environments, e.g., Power Apps, Power Automate, and Data Loss Prevention policies. - Dynamics 365 Administrator roles can manage multiple environments, but must also be added to the environment security group to manage that environment. | Service admin roles Restrict cross-tenant access | IT Professional |
| 2. Environment Access | A Power Platform environment is a space to store, manage, and share your organization's business data, apps, chatbots, and flows. It serves as a container to separate apps that might have different roles, security requirements, or target audiences. Security setup is a critical part of administrators' Power Platform environment strategy. There are two built-in roles that provide access to permissions within an environment. - Environment Admin role can perform all administrative actions on an environment - Environment Maker role can create resources within an environment including apps, connections, custom connectors, gateways, and flows using Power Automate. | Power Platform Environment Overview, Establish an environment strategy | IT Professional |
| 3. Resource Permissions | Security privileges differ by resource. Examples resources are: Canvas app, model-driven app, Power Automate cloud flow, and Power Virtual Agent bot. - For example, users, non-owner (i.e., the maker or the deployment user account), of the Canvas app can be a User, which means they can run the app. They can also be a Co-owner, which means they can run, edit and share the app. - If it is a Model-driven App, there can be many Security Roles to choose from. - Security privileges for cloud flow in Power Automate is similar to canvas app in that there are owners that can edit, update, delete the flow, access run history, and add/remove other owners, whereas Run-only can only run the flow. - A Power Virtual Agent bot can be shared with a User Bot permission to allow users to chat with it; a bot can also be shared with Manager, Power Automate user, Transcript viewer permissions to collaborate on authoring the bot. References in the next column discuss other permissions capabilities may require, such as the ones related to connections, and data sources. | Share a canvas app Share a model-driven app Share a cloud flow Share a bot with other users | Citizen Developer Pro Dev |
| 4. Connector access and DLPs | Connectors are key to Power Platform: they are a proxy or a wrapper around an API that allows the underlying service to talk to Microsoft Power Automate, Microsoft Power Apps, and Azure Logic Apps. Connectors provide a way for users to connect their accounts and use a set of prebuilt actions and triggers to build their apps and workflows. Therefore, they can expedite the development process significantly. Authentication support in connectors can vary since each underlying connector service may require different authentication mechanism. For example, Microsoft Dataverse connector supports Azure AD (OAuth2), so do all connectors to different Microsoft 365 services. Whereas Azure SQL Connector also supports sqlAuthentication in addition to Azure. Some legacy system connectors like the SAP connector support Basic authentication. Admins define Data Loss Prevention Policies (DLPs) that help prevent users unintentionally expose organizational data. DLP policies can be scoped at the environment level or tenant level, offering flexibility to craft sensible policies that strike the right balance between protection and productivity. | Connectors Overview Data Loss Prevention Policies | IT Professional |
| 5. Dataverse security | Dataverse is an enterprise, scalable, secure data platform that is a first party to the Power Platform. It underpins many Dynamics 365 applications. Dataverse ships with a rich set of security models - role-based security, record ownership, field-level security, and record sharing. When building applications with Dataverse, understanding security constructs helps developers and architects build apps that adhere to secure by design principles. For example, when designing security for end users, it is best practice to ship custom security role(s) trimmed the minimum-security privileges to perform intended actions in Dataverse. This practice avoids assigning elevated out-of-the-box security roles. Dataverse is not required for building Power Apps. Optional data services available include Azure SQL, Azure Blob Storage, Azure Cosmos DB, Oracle Database, Amazon Redshift, and Amazon S3. | What is Microsoft Dataverse Why use Dataverse Security concepts in Dataverse | Pro Dev |
| 6. On-premises data gateway | When developing applications requiring connections to on-premises data sources, the on-premises data gateway serves as a bridge. It enables fast and secure data transfer between on-premises data and various Microsoft cloud services, such as Power BI, Power Apps, Power Automate, Azure Analysis Services, and Azure Logic Apps. This way, organizations can keep databases and other data sources on on-premises networks, and securely use that on-premises data in cloud services. A stored credential is used to connect from the gateway to on-premises data sources. Regardless of the user, the gateway uses the stored credential to connect. | On-premise data gateways | IT Professional |
Minimum security privilege required for a dev crew¶
It is a best practice to abide by the minimum security privilege required to develop with Power Platform in a development environment. This security privilege differs depending on whether Dataverse is present in the subject environment. For more detail, see the Security for Pro Dev page.
| Topic | Dev Env with no Dataverse | Dev Env with Dataverse |
|---|---|---|
| Minimum Security role(s) required | 1. Environment Maker | 1. Environment Maker 2. System Customizer |
| Justification to IT Admins | Fulfills requirement to create application resources associated with an environment, including apps, connections, custom APIs, gateways, and flows using Microsoft Power Automate. | In addition to the justification outlined in the left column, which is granted by the Environment Maker security role. Developers will also need the ability to customize the Dataverse instance. |
| References | Predefined security roles | Security roles and privileges required for customization |
| Step-by-step instructions | Assign security roles to users in an environment that has no Dataverse database | Assign security roles to users in an environment that has a Dataverse database |