Personalized Community is here!
Quickly customize your community to find the content you seek.
Microsoft Customer Co-creation
Help impact how the tools and services you rely on are developed. Microsoft Customer Co-creation connects you directly with our engineers so you can provide feedback before a single line of code is written. Interested? Learn more at Microsoft Customer Co-creation
2022 Release Wave 1 PlanDynamics 365 release plan for the 2022 release wave 1 describes all new features releasing from April 2022 through September 2022.
2022 release wave 1 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
The security model is one of the most complex areas of any
Dynamics 365 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/
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.
With Dynamics 365 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 Dynamics 365.
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
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
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.
The security model within the Common Data Service or
Dynamics 365 is constructed with several core building blocks.
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.
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.”
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.
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.
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.
The post Dynamics365 / CDS – Five Layers of Security appeared first on Dave Burrell.
Business Applications communities