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.
