Chapter 11: Defining Power Platform Security Concepts

Securing customer and operational data is a key concern of organizations embarking on a digital transformation journey. In this chapter, you will learn how to design a Power Platform security model that facilitates the implementation by defining the business unit and team structures, security roles, and column security. You will also define the Azure Active Directory configurations required to support a secure authentication process, alongside data loss prevention (DLP) policies.

We will define Power Apps Portal, Power Automate, and Canvas apps security mode to support the customer’s requirements. You will design management policies to control changes to the security model.

In this chapter, we’re going to cover the following topics:

• Designing the Power Platform core security model
• Identifying data loss prevention policies for Power Platform solutions
• Securing Dataverse-based applications 
• Defining access routes for external Power Platform users

Designing the Power Platform core security model

Designing a Power Platform core security model involves tackling access to data and systems from three vectors:

• Authentication: This vector helps provide a means for users or other systems to validate their right to access Power Platform applications. Authentication is generally handled by the Microsoft 365 user management processes.
• Network: We know that connecting to Power Platform systems requires access at the network level. Power Platform solutions are SaaS cloud-hosted. Network access to those cloud-hosted services is, therefore, part of the solution architects’ design remit.
• Authorization: Once a user is authenticated, they are granted access to Power Platform resources and/or systems based on the permissions associated with their account. Solution architects define the authorization strategies that grant user access.

Understanding an organization’s security requirements

During the discovery phase, solution architects work with the business to identify the security infrastructure currently in place. The implementation of a Power Platform solution is unlikely to be the guiding factor for an organization’s security and authentication strategy. Power Platform solutions architects look to work with the policies and framework currently in place.

Security infrastructure discovery checklist

To understand an organization’s existing security framework, solution architects work with business analysts and systems owners to complete a security baseline checklist, similar to the one described in the following table:

Table 11.1 – Example security infrastructure discovery checklist

These questions will help you get a base understanding of the current security and authentication infrastructure. The answers may warrant further questions and investigation to pinpoint the detailed security framework. Once you understand the security systems in place, you are ready to find out how they are managed.

Security management discovery

Once the existing security framework has been identified, you can proceed to discover its management and change processes. The following set of questions can help solution architects understand the security processes to be followed when implementing a Power Platform solution:

Table 11.2 – Example security management discovery questions

The answers to these questions will dictate the process to be followed during the design and implementation of the Power Platform security concepts.

Power Platform security guidelines and best practices

The following are a set of guidelines and best practices you should follow when designing and implementing the Power Platform security concepts:

• Grant access to data as needed: This concept means to grant access to the data that’s required for users’ roles while providing read-only access to related data for context. Deleting data is to be limited, in favor of deactivating records.
• Keep it simple: When defining a security strategy, solution architects consider how difficult it would be to manage on a day-to-day basis, and the effort involved in making changes to the security model. Hence, it is a good idea to keep it simple.
• Use the features provided by the platform: Customer requirements may sometimes lead to a custom security implementation. These requirements may be born out of apprehension that’s inherent to moving to a cloud-based solution. Custom security implementations are often expensive to build, and difficult to change and maintain. Solution architects work to understand the real need behind complex security requirements and propose a solution that leverages the standard Power Platform and Microsoft 365 security features.
• Implement security at the platform layer: This concept helps leverage the platform’s security features rather than bespoke application security. Standard platform layer security is usually easier to implement and maintain.
• The security model is a living document: Organizations evolve and so do requirements and Power Platform implementations. Solution architects design a security model and make the designs accessible to the system owners. As the usage of the system grows, the security model may require updates as the original requirements and the decisions that were made around them may no longer apply.

Securing Power Platform environments

There are several ways users may gain access to Power Platform environments. Solution architects understand all the access vectors and define a security model that defines how each of them will be configured.

Controlling access via security groups

Power Platform environments may be associated with a Microsoft 365 or Azure AD group, effectively restricting access to the environment to members of that group. During the initial environment definition, solution architects define the security groups that are required to control access to each environment level.

Once an environment is associated with a group, only members of that group can access the system (except for Microsoft 365 global admins, Power Platform admins, and delegate admins).

The following diagram illustrates a typical Power Platform environment and security group configuration:

Figure 11.1 – Example Power Platform security group environment configuration

Having configured the environments and security groups, administrators can control the users that have access to each Power Platform environment level by adding and removing users from each group. Environments may be configured to use security groups via the Power Platform administration portal, as illustrated in the following screenshot:

Figure 11.2 – Setting security group access for a Power Platform environment

If a Power Platform environment is not associated with a security group, all users with the appropriate license will be automatically added to the environment. When a Microsoft 365/AD user is added to a security group, they are automatically added to the Dataverse environment. Conversely, when a user is removed from a security group, their corresponding Dataverse user is deactivated.

Note

When a security group is associated with a Power Platform environment, all the users that were previously active within the system will be deactivated unless they are already in the security group (or they have a Microsoft 365 admin role granting them access to the environment).

Microsoft 365 roles and admin accounts

Microsoft 365 includes specialized roles that automatically grant system administrators access to Power Platform environments. These Microsoft 365 roles are as follows:

• Global Administrator: Users with this role have the highest level of control over a Microsoft 365 tenant, and they are automatically granted system administrator access to all Power Platform environments within it. These users are granted access regardless of the security group configuration.
• Microsoft Power Platform Admin: Users with this Microsoft 365 role are granted access to all Power Platform environments. They can manage Power Apps, Power Automate, and data loss prevention policies. These users are granted access regardless of their security group configuration.
• Delegated Admin: Used by Microsoft Cloud Solution Provider program (CSP), partners, this role grants users access to all services within a tenant. Users with this role will also have system administrator access to Power Platform environments.

Environment roles

Users may also be granted roles within a Power Platform environment. If a Dataverse database does not exist with an environment, the following two roles may be used:

• Maker: Users with this environment role can create and manage Power Apps within a Power Platform environment
• Admin: Users can manage the Power Platform environment’s configuration and settings

Once a Dataverse database has been created within a Power Platform environment, the Dataverse security model takes over.

Providing Dataverse API access to external applications

External applications looking to access the Dataverse API will need to authenticate themselves. Two types of users exist for this purpose.

• Users: Licensed users with a Microsoft 365 account. While external clients can authenticate with a Microsoft 365 username and password, it is not the recommended access route. A Power Platform or Dynamics 365 license will be required, and standard users do not provide the same means of security afforded by application users.
• Application users: Users registered in Azure AD as application registrations. These types of users do not consume a Power Platform or Dynamics 365 license.

Please refer to Chapter 10, Power Platform Integration Strategies, for instructions on creating application users.

Further Reading

The following documentation provides full details on managing application users within a Power Platform environment: https://docs.microsoft.com/power-platform/admin/manage-application-users.

Defining data loss prevention policies for Power Platform solutions

Data loss prevention (DLP) policies help prevent data from being released unintentionally. They help protect the security of a tenant.

When configuring and implementing a Power Platform solution, it is important to be aware of the following DLP features and restrictions that may be in place.

Key DLP considerations

The following are some key DLP considerations:

• DLP controls the combination of connectors that may be used
• DLP policies are not enabled by default
• Tenant administrators may define DLP policies for all environments within a tenant
• DLP policies may be implemented at the tenant or environment level
• Environment DLP policies may not override tenant DLP policies
• DLP policies are cumulative, with the most restrictive policy being applied

Data loss prevention best practices

The following is a list of guiding principles when defining DLP policies:

• It is a good idea to define the minimal number of policies.
• Avoid applying multiple policies to an environment if possible.
• Apply DLP policies across all environments, block unsupported non-Microsoft connectors, and classify Microsoft connectors as “business data.”
• Define a policy for Power Platform default environments and other non-production environments, with additional restrictions on connectors classified as business data.
• For specific environments that require additional access, create additional policies or exclude them from the more restrictive ones.
• Establish policies early and create exceptions later.

Deployment of data loss prevention policies

When deploying DLP policies, solution architects consider the following:

• When a DLP is rolled out, it may disable existing Power Apps or Cloud Flows.
• Policies may take minutes to propagate to all environments.
• Policies may be applied at the tenant or environment level only, not at the user level.
• Users may view the DLP policies that have been applied.

If an existing process is found to be in breach of the DLP policies, it will be automatically disabled, and the owner will receive the following email notification:

Figure 11.3 – Notification received by owners of processes restricted by DLP policies

DLP deployment checklist

Before DLP policies are configured, it is important to validate the rollout by running through a DLP deployment checklist that includes the following aspects:

• Confirm feasibility: Confirm that the Power Platform solution can be delivered and configure DLP to allow the Power Platform solution to function.
• Confirm owners: Understand what the Power Platform team has control over, and what is controlled by other teams or groups.
• Confirm lead time: The lead time required for configuring DLP policies so that it can be taken into account during the rollout of the solution.

Configuring and updating DLP policies

Depending on the size of the organization, there may be individuals or teams dedicated to configuring DLP policies. Power Platform solution architects either configure or provide input for configuring DLP policies to ensure the Power Platform solution is secure, while at the same time being able to perform.

DLP policies may be configured via the Power Platform admin center by selecting the Data policies option, as illustrated in the following screenshot:

Figure 11.4 – Configuring Power Platform DLP policies

The DLP configuration pages allow you to categorize connectors into one of three areas:

• Non-business (default): Connectors for non-sensitive data
• Business: Connectors that will handle sensitive business data
• Blocked: Connectors that may not be used

The following screenshot illustrates the DLP connector configuration page. Note that custom connectors may also be configured and restricted via a DLP policy using an API/connector host URL pattern:

Figure 11.5 – DLP connector restriction options

And finally, once the connectors have been assigned to their appropriate DLP restriction categories, the policy itself may be associated with all Power Platform environments or specific environments, as illustrated in the following screenshot:

Figure 11.6 – Defining the scope of DLP policies

DLP policies are powerful tools that can help prevent the unauthorized distribution of business data. Solution architects work with organizations to define and configure DLP policies to ensure the Power Platform’s data is secure.

Further Reading

Please refer to the following documentation for detailed instructions on how to configure DLP policies: https://docs.microsoft.com/power-platform/admin/prevent-data-loss.

Securing Dataverse-based applications 

In this section, we will discuss how to secure Dataverse and the applications that use its security framework. We will start by looking at how users interact with the solution, tailoring the security settings to enable authorized tasks and restrict other activities.

Common usage patterns for security design

When defining the security model, solution architects assess how the system will be used. The following table lists the key patterns for users looking to access Power Platform applications:

Table 11.3 – Common usage patterns for Dataverse applications

When defining the security model, solution architects analyze how users interact with data and whether they work by themselves or interact with other team members.

Best practices

Power Platform solution architects secure Dataverse solutions with the following best practices in mind:

• Design security to cater to the majority of access patterns, and treat exceptions as such.
• Use Dataverse Business Units as security boundaries for controlling access to data, rather than as a replica of the organizational structure.
• Use the simplest security model that meets the requirements while still being performant.
• Access to a single record may not be revoked when access to a broader dataset containing the record has been granted. The security model must be defined accordingly.

Leveraging Dataverse security features

Dataverse provides a rich feature set for managing data access privileges. The following list outlines the main Dataverse security concepts:

• Users
• Teams
• Business Units
• Table ownership
• Security roles
• Column-level security
• Sharing
• Azure AD security groups
• Auditing
• Hierarchical security

The following subsections describe each of these security concepts.

Users

Users looking to access Dataverse data require a user record. Privileges are configured for that user, granting access to tables, columns, and rows. These user records are automatically created when a Microsoft 365 user account is granted access to Dataverse by assigning the corresponding licenses and security groups (where appropriate; see Azure AD Groups security configuration for Dataverse teams, as described in the following section).

The two main types of Dataverse users are as follows:

• Licensed Users: Users with a Microsoft 365 user account
• Application users: Users configured for applications and external services to communicate with Dataverse

Licensed Users

Users with the appropriate license and group membership will appear on the Power Platform admin center page, as follows:

Figure 11.7 – Power Platform admin center page listing active users

Application users

New application users can be registered via the App registrations section of the Azure Active Directory page in the Azure portal. The following screenshot illustrates an example application user registered in Active Directory:

Figure 11.8 – The Azure portal page listing App registrations configured in AD

Once the application registration is complete, the application user may be created in the Power Platform admin center. The resulting application user is illustrated in the following screenshot:

Figure 11.9 – Power Platform admin center listing configured application users

Standard users and application users can then be given security roles and assigned to teams.

Further Reading

Please refer to the following documentation for additional details on Power Platform application users: https://docs.microsoft.com/en-us/power-platform/admin/manage-application-users.

Teams

Dataverse Teams provide a means of grouping users. Grouping users into teams reduces or removes the need for managing rights for each user, and provides a mechanism for granting row access to the entire group.

There are four types of Dataverse teams:

• Owner Teams: These teams may own (or be assigned) rows. As a result, members of that team are granted access to those rows.
• Access Teams: Used for easily sharing access to records, access teams are not associated with security roles. They provide a mechanism for associating and granting access to users and specific records.
• Azure AD Security Group Teams: These teams work the same as Owner Teams. Membership is managed in Azure AD security groups.
• Azure AD Office Group Teams: The same as Azure AD Security Group Teams, except they are associated with a Microsoft 365 group, which may be created by users with lesser privileges.

When creating a Dataverse Azure AD Security or Office Group team, it is possible to define whether members, guests, or owners of the group will be replicated as Dataverse users. The following screenshot illustrates the available options:

Figure 11.10 – Group member replication options available when creating an Azure AD Security or Office Group team

Solution architects review the organization’s functional and security requirements and define a team strategy that leverages the different types of teams. The following diagram illustrates various use cases for the different types of Dataverse teams:

Figure 11.11 – Diagram illustrating various use cases for the different types of Dataverse teams

Business units

Dataverse business units contain teams and users. They are key components in the Dataverse security model, as they allow data to be partitioned within tables. Combining business units with security models allows users and their data to be segmented.

When designing the Dataverse security model, solution architects define a business unit hierarchy that matches the security requirements, rather than the organizational structure,

Consider the following when defining Business Units:

• Dataverse Business Units are there to facilitate the segmentation of data.
• As their primary function is to secure data, they should be defined and created with that purpose in mind.
• Since they mirror an organization’s structure directly, Dataverse Business Units are likely to hinder the security modeling process as they will create additional unnecessary complexity to be worked around.
• It is the combination of security roles and business units that control the segmentation of data.

The following diagram illustrates a typical business unit structure:

Image 11.12 – Example Dataverse business unit structure

Note

Most of the time, you will want to define a business unit hierarchy based on security requirements. There are exceptions to this rule, where the organizational structure may, at times, match the needs of the Dataverse security model.

Table ownership

Dataverse tables are configured on creation using one of two ownership modes:

• User and Team Owned: Rows within the table will be owned by either a user or a team. This ownership mode provides more granular control over access to data rows. Security roles associated with the teams and users can control the level of access on a record based on its owner.
• Organization Owned: Rows are owned by the organization as a whole, and do not have a specific user or team owner. Using Organization table ownership simplifies the security model, as table ownership is not a factor in the configuration. This configuration trades the ability to control user/team-level access to rows for simplicity.

  Note

  Once a table has been created using organization-level ownership, it can’t be changed. The table would need to be recreated, resulting in potential migration and refactoring efforts. Solution architects should only select organization-level table ownership when it is confirmed that there will never be a need to control access to its rows based on the user or team that owns it.

Security roles

Dataverse security roles provide granular control over the level of access granted to users and teams. They are the central mechanism for controlling who has access to Dataverse data, the level of access, the features may use, and the actions they may perform.

Security roles may be assigned to teams (and therefore granted to the team’s members) or directly assigned to individual users.

Record-level privileges

Security roles can specify the level of permissions to be granted to users and teams. The following screenshot illustrates the eight available privileges:

Figure 11.13 – Security role privileges

Solution architects review the business requirements and define the minimum level of access required by users. The eight record-level privileges are as follows:

• Create: Grants users the ability to create rows
• Read: Grants users the ability to view rows
• Write: Grants users the ability to update rows
• Delete: Grants users the ability to delete rows
• Append: Grants users access to link a row to another record (for example, linking a contact record to an account by setting the contact record’s account lookup)
• Append To: Grants users the ability to associate a record from another row (for example, from the account record, associate existing contacts with the account)
• Assign: Grants users the ability to assign rows (available in team/user-owned tables)
• Share: Grants users the ability to share rows

Levels of access

Row-level privileges may be further configured by the five levels of access illustrated in the following screenshot:

Figure 11.14 – The five levels of access for a row-level security role

The five levels of access are as follows:

• Global/Organization: Organization-level access to rows. The highest level of access is usually restricted to managers and individuals that require full dataset access.
• Deep: Business Unit and child Business Unit-level access to rows. This grants access to rows owned by users/teams within the business unit and business units below. This level of access is usually restricted to managers with oversight over a business unit and its subordinates.
• Local: Business Unit-level access to rows. This grants access to rows owned by users/teams within the same business unit. This level of access is usually restricted to managers with oversight over a specific business unit.
• Basic: User/team-level access to rows. This grants access to rows owned by the user, or a team the user belongs to, rows that are shared with the user, and rows that are shared with a team the user belongs to. This is the typical level of access that’s granted to sales and customer service staff.
• None: Grants no access to data.

Security roles member privilege inheritance

Security roles may be configured for member privilege inheritance. The two inheritance options are as follows:

• Team privileges only
• Direct user (Basic) access level and team privileges

As the name implies, the key difference between these two application modes is that, when a security role is assigned to a team, the team’s user has the security role assigned as if it has been directly associated with their user. This removes the need to assign security roles directly to users and allows administrators to manage Dataverse access using solely user team memberships.

When selecting Direct User (Basic) access level and Team Privileges, the team’s members will receive the security role privileges as if the role had been assigned directly to the user. This removes the need to assign at least one security role to the user record, simplifying the user management and onboarding process:

Figure 11.15 – Security role member’s privilege inheritance options

Note

Using Direct User security roles in combination with Azure AD Group Teams is a great way to streamline the creation and management of Dataverse users. New users may be added to a Microsoft 365 group and have their accounts created in Dataverse. Any necessary security roles are assigned automatically.

Layering security roles

The effect of security roles is cumulative. When a user is granted multiple security roles, they gain access to rows by aggregating all the permissions granted by the assigned roles. This aggregation of security roles provides a means of defining security design strategies that leverage security role layers.

The four main Dataverse security role layering strategies are as follows:

• Position role

Position-specific roles include all the permissions a user requires. Roles will typically be named after the position that it caters for (for example, Sales Person or Customer Service Manager). While this strategy provides a clear set of self-contained roles, each fully defining all the privileges a position requires, it may result in a higher maintenance overhead, as the various roles are likely to have a common set of permission across them. Adding a new custom table may mean editing all the roles to include access to the new table:

Figure 11.16 – Example of a position role-based security model

• Base role and position role

This security role strategy adds a base layer to the position role. The base security role includes permissions that are common across the board (for example, all users will need a basic level of create/read/write access to contact records). The position role can then focus on complementing the base role, including permissions that are specific to the position in question. An example set of base and position roles are as follows:

• Contoso – Baseline: Grants base access to all common tables
• Contoso – Sales: Grants basic level read/write access to leads and opportunities

A member of the sales team could then be assigned the Baseline and Sales person roles, thus completing their access to Dataverse:

Figure 11.17 – Example of a base role and position role security model

• Base role and capability role

This strategy is similar to the base role and position role strategy. The main difference is that the specialized roles are built around capabilities rather than staff member positions. An example set of base and capability roles are as follows and shown in the Figure 11.18:

• Contoso – Baseline: Grants base access to all common tables
• Contoso – Surveys: Allows you to manage surveys sent to customers

Figure 11.18 – Example of a base role and capability role security model

• Base role + position role + capability role

This strategy combines the position and capability roles, providing greater flexibility when defining and assigning permissions. An example set of roles is as follows and shown in the Figure 11.19:

• Contoso – Baseline: Grants base access to all common tables
• Contoso – Sales: Grants basic level read/write access to leads and opportunities
• Contoso – Surveys: Allows you to manage surveys sent to customers

Figure 11.19 – Example of a base role + position + capability role security model

Column-level security

Dataverse columns may be configured for column-level security, allowing administrators to specify the user and/or teams that will be granted access. Column-level security works separately from security roles and is designed to provide further control over who can see and update data within specific fields. This may be used to control access to personal data within a contact record, granting read access to only a select group of people or teams.

Sharing

The sharing feature within Dataverse allows rows to be shared with a user or team that would not normally have access.

Note

Sharing a large number of records will result in performance degradation as sharing creates a sharing record per row per user, resulting in a potentially large dataset that needs to be checked by Dataverse every time a user attempts to access a row. Therefore, sharing is used when the volume of data to be shared is expected to be low.

Auditing

Auditing is configured at the environment, table, and column levels. When auditing is enabled, it logs data changes performed by Dataverse users.

Read actions are not monitored by the Dataverse auditing facility. They may, however, be captured using activity logging, which is monitored via the Microsoft 365 Security and Compliance Center. Activity logging must be enabled before use.

Defining a Dataverse permissions matrix

Both implementation consultants and stakeholders will benefit from a high-level permissions matrix. This is typically a table that presents the different roles (or teams) and the actions they can perform in the system. From the requirements captured so far, solution architects list the various activities and the users that perform them in a matrix, as follows:

Table 11.4 – Example of a high-level Dataverse permissions matrix

The Dataverse permissions matrix allows you to quickly review and compare roles. It also serves as a discussion point with stakeholders, who will be able to visualize the separation of roles. The security design may then be adjusted based on these discussions.

Defining access routes for external Power Platform users

External users may access Power Platform applications via several routes. The following is a summary of the main routes through which external users may access the Power Platform:

• Power Pages

Power Pages (previously Power Apps Portals) may be configured to authenticate external users through a variety of authentication protocols, including AD and Azure AD B2C.

• Connected tenants

Microsoft 365 tenants may be connected, granting access to users from one tenant to the other. This implementation route allows users from another organization or Microsoft 365 tenant to access Model-Driven Apps, Canvas Apps, and Dataverse using the credentials from the external tenant.

• Custom applications

Custom applications may implement any number of authentication strategies. While the connection from the custom application to Power Platform and Dataverse may be through an application user or service account, external users may authenticate any number of bespoke protocols with the custom application, thus allowing external users access to Power Platform data.

As a solution architect, you will work with the business to identify the optimal access route for external users.

Summary

In this chapter, you learned how to work through the security architecture discovery process, and you learn about how to define security concepts for Power Platform applications, and, more specifically, the Dataverse security concepts. A solid security solution design is crucial for the successful implementation and ongoing operation of Power Platform applications.

In the next chapter, you will learn how to manage the implementation of Power Platform solutions, including how to validate compliance with security concepts and how to resolve automation and integration conflicts.