Posted inTech Blogs

Power Platform – Security Principles and Recommendations

Power Platform – Security Principles and Recommendations

Power Platform – Security Principles and Recommendations

Audience:

IT Admin, System Admin, CoE Owners and Power Platform Management teams.

Business Value:

  • Environment security that hosts Power Platform solutions
  • Various IT/Environment recommendations that helps IT team to manage Power Platform instance/environment/solutions.

Power Platform: Security Pillars
 
Power Platform – Security Principles and Recommendations
 

Based on the above representation, there are various areas where the IT/Security team need to focus on securing the Power Platform / Azure / Dataverse environment(s)

Compliance Strategy:
 
Power Platform – Security Principles and Recommendations

Utilize Microsoft Trust center to validate that Microsoft and your implementation comply with regulatory requirements for data security.

Data Management is the core of the security standards. Analyze where your data is located and the impact on regulatory requirements.

DPR: Data Protection Resources are listed below

Service Accounts Strategy:
 
Power Platform – Security Principles and Recommendations
 
Review privileged roles in Microsoft 365 and the Power Platform

Limit and regularly review the list of elevated user and service accounts

Utilize Azure AD applications and service principals for integration and deployment

Power Platform Network Security:

Power Platform – Security Principles and Recommendations

For specific network requirements, consider Azure ExpressRoute with Microsoft Power Platform

  • Azure ExpressRoute provides a way to connect your on-premises network to Microsoft cloud services by using private connectivity. This is useful when you need to make sure your network or internet connection can handle additional traffic; to manage the predictability of traffic; or to ensure data never transits across the public internet.
  • Configuring ExpressRoute for Power Platform services requires Microsoft peering. This means that the traffic will be routed to go to Power Platform public IP address ranges (and BGP communities are not supported).
  • Learn more on using Azure ExpressRoute with the Power Platform:
    https://docs.microsoft.com/power-platform/guidance/expressroute/overview

Leverage Azure Networking Connectivity

  • Connect from the Power Platform into your Azure Virtual Network.

For complex architectures with multiple integrations, consider using API gateways

Monitoring Controls:


Leverage auditing and logging controls available in Microsoft 365 and Microsoft Dataverse

Integrate with Microsoft Sentinel

  • Microsoft Sentinel is a scalable, cloud-native, security information event management (SIEM) and security orchestration automated response (SOAR) solution for alert detection, threat visibility, proactive hunting, and threat response.
  • Learn more on Microsoft Sentinel https://docs.microsoft.com/azure/sentinel/connect-dynamics-365


Monitor usage and Application Telemetry

Data Security & Controls:

Review your Power Platform environments encryption

All environments of Microsoft Dataverse perform real-time encryption of data, at rest and in-transit. By default, Microsoft stores and manages the encryption key, but under eligible conditions, admins can choose to self-manage it.


Scan, classify, and label Dataverse data with Azure Purview

Azure Purview is a unified data governance service that helps you manage and govern your data, with automated data discovery, sensitive data classification, and end-to-end data lineage.

Enable Lockbox policies for your Power Platform environments

Lockbox provides an interface to review – and approve or reject – data access requests, typically in the context of a support request. After access is granted to Microsoft, any customer data access during the elevated access period is recorded and made available as audit logs.


Environment Security & Strategy

Assess if your environments should be visible to all users or not


Understand environment system and manual backups


Evaluate need for data archival and retention policies

  • Move Dataverse data to long-term storage to support regulatory requirements, internal and external audit requirements, and reduce non-active data from the transactional store.

Have representative non-customer data for test sets in non-production environments

  • Avoid using customer personal and business confidential data in non-production environments.
  • If performing production environment copies, consider implementing processes to obfuscate sensitive data

Solution Model / Package Security:

Keep your model simple and have the future in mind

  • Be mindful of the required effort to maintain the security model.
    Anticipate the impact of reorganizations, user onboarding, user leaving or user changing roles.
  • Try to limit the number of security patterns, security roles, business units (and their depth) and teams.

Avoid unhealthy patterns

  • Automated sharing at scale is never easy to maintain and can introduce scalability and performance issues. Try to cover as many scenarios as possible with simple patterns, and only resort to sharing for exceptions to the model.
  • Plug-ins firing on Retrieve and Retrieve Multiple events also have caveat and impact performances negatively.


Understand that customization of the user interface is different from securing data

  • When a user has update privileges on a record, just because a field is set as read-only on a form doesn’t mean the data can’t be updated through other means. True security resides server-side.
  • Hiding the “Export to Excel” button doesn’t mean users can’t export the data with other tools.
  • That being said, security roles can and should also be leveraged to create simple role-based UX.

Assess security impacts in related applications and/or features

  • Evaluate access rights in satellite apps and services (e.g., Customer Insights, SharePoint, Teams, Portals, Power BI, etc.).

User Account/Roles Management:

Implement a least privilege strategy when designing your security roles

  • Consider only providing users with what is necessary (just-enough-access – JEA) to accomplish their job by reducing read/write privileges to a user or business unit scope and avoid granting delete privileges by favoring deactivating records instead.

When possible, drive security roles assignment through Azure AD groups

  • Managing user roles through Azure AD group teams greatly reduces administration effort and risks of error.


Start from a copy of existing security roles and create them at the root business unit

  • This allows better control over the new security roles and avoids conflicts with first-party updates.
  • Security roles at the root business level can be included in solutions and deployed to other environments.

Be mindful of privileges potentially leading to elevated permissions

E.g., “Promote User to Microsoft Dynamics 365 Administrator Role”

  • Combine similar roles for easier management
    • You rarely need as many security roles as there are job titles.
  • Consider reporting to simplify a security model
    • If managers only need an overview of business (e.g., territory pipeline forecast), instead of defining a complex model on individual records, consider an anonymized report with limited access to the underlying raw data.
  • Monitor customizations being deployed to production
    • By being source control-centric and with a gated Application Lifecycle Management (ALM) approach – with code reviews and approvals of pull requests – reduce risk of deploying malicious or unsecure customizations.
  • Have a secure process to handle changes to data involved in sensitive operations
    • E.g., updating a customer phone number used for verification, should it be approved, audited?
  • Consider security checks and trainings for employees accessing confidential data
    • Reduce risks by performing security checks and providing security trainings.
  • Don’t use Dataverse as a vault for highly sensitive information such as credit cards
    • Compliant tools and solutions should be considered instead

Power BI / Reports Security Principles:

Have a data management strategy for all data that is stored outside of a core application.

  • When data is exported to external data stores, you need to apply your own security mechanism for reporting, as the Dataverse security permissions are no longer honored.
  • The reporting strategy should include security requirements (encryption, access controls, row level, PII) as well as data residency and retention requirements.
  • Learn more on how row-level security (RLS) can be used in Power BI to restrict data access for given users.
    https://docs.microsoft.com/power-bi/admin/service-admin-rls

Understand how and when to leverage the Power BI Dataverse connector with DirectQuery

Microsoft Resources for reference:

Dynamics 365 Implementation Guide

Success by Design: Security Strategy

Power Platform and Dynamics 365 Apps – Guide to security and compliance 2021

Embrace proactive security with Zero Trust

Tags:

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply

Your email address will not be published. Required fields are marked *