PowerPlatform / Dataverse – Five Layers of Security

The security model is one of the most complex areas of any Power Platform implementations, due to this many times security is an afterthought and left to just before go-live. This, however, should be tackled early on in the design of the project. Understanding data security will drive the system design. Think security by design. With the introduction of the General Data Protection Regulation (GDPR), this is of utmost importance.

GDPR at a Glance

The GDPR requires you to put in place appropriate technical and organisational measures to implement the data protection principles and safeguard individual rights. This is ‘data protection by design and by default’.

In essence, this means you have to integrate or ‘bake in’ data protection into your processing activities and business practices, from the design stage right through the lifecycle.

This concept is not new. Previously known as ‘privacy by design’, it has always been part of data protection law. The fundamental change with the GDPR is that it is now a legal requirement.

Data protection by design is about considering data protection and privacy issues upfront in everything you do. It can help you ensure that you comply with the GDPR’s fundamental principles and requirements and forms part of the focus on accountability.

https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/accountability-and-governance/data-protection-by-design-and-default/

Five Layers of Security

With the Power Platform deeply embedded within the Azure infrastructure, it is possible to add security at all levels of your implementation right from Initial login right down to field level security within the Power Platform.

Azure Active Directory

Azure Active Directory provisions the first layer of
security, conditional access. Conditional access takes many signals from the
user and applies a number of logic statements to determine if the user should
be granted access.

Conditional access can be used to control variables such as
the user’s location and device, which provides a high level of security. As an
example, you could block access from any device that is not located within your
corporate network. It is worth noting that enabling users to access from all
locations that they may work from should be allowed so not to restrict users
productivity.

Common Access Signals

• User or group
  membership
  • Policies can be targeted to specific users and groups, giving
    administrators fine-grained control over access.
• IP Location
  information
  • Organisations can create trusted IP address ranges that can be
    used when making policy decisions.
  • Administrators can specify entire countries IP ranges to block
    or allow traffic from.
• Device
  • Users with devices of specific platforms or marked with a particular
    state can be used when enforcing Conditional Access policies.
• Application
  • Users attempting to access specific applications can trigger
    different Conditional Access policies.
• Real-time and
  calculated risk detection
  • Signals integration with Azure AD Identity Protection allows
    Conditional Access policies to identify risky sign-in behaviour. Policies can
    then force users to perform password changes or multi-factor authentication to
    reduce their risk level or be blocked from access until an administrator takes
    manual action.
• Microsoft Cloud App
  Security (MCAS)
  • Enables user application access and sessions to be monitored and
    controlled in real-time, increasing visibility and control over access to and
    activities performed within your cloud environment.

Environmental Access

Within each Azure tenant, you can create a variety of
different types of environments and control access to each of them at both an
individual user level or by forming groups of users.

Users can be given access to none, one or many different
environments based on their requirements; for example, a development user may
only need access to Dev and Test. In contrast, an end-user will only need
access to Prod.

Each environment can be configured differently, which has an
impact or security. The critical point to note is that a production instance
cannot be deleted. It has to be converted to a sandbox before deletion is
available.

Resource Permissions

In Office365 users can be given access to specific resources
or applications. If a user only requires access to Dynamics365 and Outlook,
then all other applications can be restricted. A data analyst may also need
access to PowerBI.

Dataverse / Power Platform Security Roles

The security model within the Dataverse or Power Platform is constructed with several core building blocks.

Business Units

Business Units form a hierarchy that contains groups of
Users and Teams, and the records the Users and Teams own. The hierarchy
provides security boundaries to control the scope of the User permissions. This
means that permissions can be granted to records so that users can perform
different actions on records that are owned by other Users or Teams in their
Business Unit from the actions that they can perform on records that are
located in another Business Unit.  
Business Units are also helpful when you consider your reporting
requirements. Depending on the access levels that are granted to Users to read
records, sometimes a single report can be used by several users in different
Business Units to receive the results that they must have. This occurs because
the records that are reflected in the report are filtered only to include the
records that the user has access to. If users have access to records for the
whole Organisation, you can use Business Units in the queries of your report to
filter or categorise results. When you plan a CDS deployment, it might be
helpful to refer to an organisation chart of the company structure. However,
you do not have to replicate this in your Business Units. It is recommended
that you create only the Business Units that you must have to meet the security
or reporting requirements of the business.

Security Roles

The security permissions that are defined in each Security
Role consist of privileges that describe the actions that are allowed at a
selected access level that describes where the privilege applies. The
permissions are displayed in the form by using a series of icons, the key for
which is included on the Security Role form as shown in the “Security Role
Core Records Tab Entity Privileges.”

Teams

A Team is a group of users who work together for a long
time, such as a department of an organisation, or temporarily such as a project
team. Whether to use Teams in CDS is optional. There is no requirement that an
organisation must create their own Teams or do anything with the default Teams.

Hierarchy Security

The Manager hierarchy security model, is based on the
management chain or direct reporting structure, where the manager’s and the
subordinate’s relationship is established by using the Manager field on the
user entity. With this security model, the managers can access the data that
their subordinates have access to. They can perform work on behalf of their
direct reports or access information that needs approval.

The manager can have full access to the subordinate’s data
for the direct reports. For non-direct reports, a manager can only have the
read-only access to their data.

Cross Tenant Restrictions

With the introduction of Power Automate and other integration
techniques that are available to citizen developers cross tenant restrictions
play a vital role. It is critical to configure robust data loss prevention
policies to ensure that business data does not leave the business systems.

Conventional business systems include Dynamics 365 and
SharePoint. DLP policies should be configured to restrict data from these
sources being connected to social media, for example.

Access can also be configured at a tenant to tenant level.

Original Post https://daveburrell.co.uk/dynamics365-dataverse-five-layers-of-security/