This post continues on the Power Platform Admin Essential Checklist and focuses on the “Secure” pillar.
SECURE
Setting up Power Platform security is essential to safeguard sensitive data, prevent unauthorized access, and maintain compliance with data protection regulations, ensuring the platform’s integrity and trustworthiness.
It also helps organizations control who can create, access, and modify apps and data within Power Platform, reducing the risk of data breaches and maintaining a secure working environment. Proper security configuration ensures that users can effectively utilize Power Platform without compromising data integrity or privacy.
The key focus areas from a data security perspective for admins are the following:
Securing Power Platform with DLP policies protects sensitive data and ensures compliance with regulations, enhancing overall data security. It’s a crucial component of a robust security strategy. Check the common DLP deployment question addressed below.
Microsoft Entra ID Conditional Access can be used to enforce security policies based on user and device conditions, ensuring secure access to Azure and Microsoft 365 services. It helps protect against unauthorized access and strengthens identity and access management. Applying the same type of the security enforcement to Power Platform resources can be easily done, lookup here.
Cross-tenant isolation in Power Platform is used to separate and secure data and resources between different organizations or tenants, ensuring that they do not have unintended access to each other’s data or configurations. This is important for maintaining data privacy, compliance, and security when multiple organizations or departments are using Power Platform within a shared environment.
Your organization's data is likely one of the most important assets you're responsible for safeguarding as an administrator. The ability to build apps and automation to use that data is a large part of your company's success. You can use Power Apps and Power Automate for rapid build and rollout of these high-value apps so that users can measure and act on the data in real time. Apps and automation are becoming increasingly connected across multiple data sources and multiple services. Some of these might be external, third-party services and might even include some social networks. Users generally have good intentions, but they can easily overlook the potential for exposure from data leakage to services and audiences that shouldn't have access to the data.
Where do you start with DLP policies in your organisation?
According to Microsoft best practices, we begin with the tenant-level DLP policy, which covers all existing environments and any future ones. To simplify, we categorize all Office 365 standard connectors into the ‘Business’ bucket, place the rest in the ‘Blocked’ category, and assign connectors that can’t be blocked to the ‘Non-business’ bucket. This policy is the most restrictive in the organization and also applies to the Default environment. It’s crucial to cover the Default environment with a DLP policy because all licensed users have a Maker role in that environment.
Description
1 Assign one or more connectors across connector classification groups
2 Connector classification group pivot tables
3 Search bar to find connectors across properties like Name, Blockable, Type, or Publisher
4 Connector classification group that maps any new connectors added by Microsoft Power Platform after your DLP policy is created.
5 Select, multi-select, or bulk-select connectors to move across groups
6 Alphabetical sort capability across individual columns
7 Action buttons to assign individual connectors across connector classification groups
Our organization is small, and Power Platform adoption is low. Do we still need to establish DLP policies?
It is easier to start from scratch than to begin with the Power Platform tenant where Makers have already developed resources. Starting from a clean slate means simply setting things up. However, when dealing with existing resources, you must address environmental remediations, as existing components may potentially break after the policy is applied. In such cases, you have to manage change effectively, assisting Makers in reorganizing their resources or even rebuilding some. Getting things right before the organization fully adopts Power Platform saves a lot of time, money, and effort, as remediating issues takes time and slows down the adoption process.
We already have many apps and flows developed, but we're just starting to deploy DLP policies. We prioritize security but are concerned that applying changes may break our existing resources. Where should we begin?
Unfortunately, you must go through the remediation process before you can apply your DLP policy. This is because the connectors allowed in a new policy won’t match the connectors that Makers have already started using, particularly in the Default environment. As a result, some of the apps and automations may stop working. You need to come up with a remediation plan and then proceed with the necessary steps to mitigate the risk and address the issues related to policy deployment.
You should start by deploying a DLP policy for the Default environment first, and then you can address project and shared environments.
Using Microsoft Entra ID security features in your organisation? You could set it up for Power Platfrom as well
Did you know you can limit access to ALL apps and ALL Flows via Microsoft Enterprise ID conditional access?
Or simply get Makers to use MFA to authenticate to access the particularly sensitive data via apps.
For the multiple tenants in my organisation, with the default setup, could I access data sources from different tenants within the same app and flow?
The default configuration in Power Platform with tenant isolation Off is to allow cross-tenant connections to be established seamlessly, if the user from tenant A establishing the connection to tenant B presents appropriate Microsoft Entra credentials. If admins want to allow only a select set of tenants to establish connections to or from their tenant, they can turn tenant isolation On.
What's going to happen to the existing apps and flows using the cross-tenant connections after applying the restrictions?
IIf restrictions are applied, flows and apps using cross-tenant connections will break. It’s essential to complete the remediation process before enforcing tenant isolation restrictions.
Setting up Power Apps and Power Automate admin and governance can be a complex and challenging task, with various aspects like user management, security, compliance, and environment management requiring careful consideration. To establish a robust foundation and avoid potential pitfalls, it’s advisable to seek the expertise of professionals who specialize in Power Platform administration and governance.
Technomancy experts can help your organization navigate the intricacies of these tools, ensure best practices are followed, and tailor solutions to specific business needs, ultimately facilitating a smoother and more effective deployment of Power Apps and Power Automate within the organization.
Leave your contact details and we will reach out to discuss it as soon as possible.