Understand the security architecture
When you understand the security architecture of D365 Finance, you can more easily customize security to fit your business requirements.
The system architecture of D365 Finance uses the functionality of Microsoft Azure. This allows D365 Finance applications to work and communicate with different devices.
The security model is hierarchical, with each element of the hierarchy representing a different level of detail. Consider the following safety considerations:
- D365 Finance uses role-based security.
- Access is granted only to security roles, not individual users.
- Users are assigned to roles. A user assigned to a security role has access to the privilege set associated with that role.
- A user who is not assigned to any role has no privileges.
Role-based security
Role-based security is aligned with the business structure. Users are assigned to security roles based on their responsibilities within the organization and their involvement in business processes. The administrator grants access to responsibilities performed by users of a role, not to program elements that users are required to use.
In role-based security, access is not granted to individual users, only to security roles. Users are assigned to roles. A user assigned to a security role has access to the privilege set associated with that role. A user who is not assigned to any role has no privileges.
All users must be assigned to at least one security role to access D365 Finance. The security roles assigned to a user determine the duties that the user can exercise and the parts of the user interface they can display.
Users are assigned to roles via System Administration > Security > Assign Users to Roles.
Because rules can be configured for automatic role assignments, the administrator does not need to be involved every time a user’s responsibilities change. Once security roles and rules are defined, administrators can control daily user access based on business data.
By default, sample security roles are provided. All the features of D365 Finance are associated with at least one of the example security roles. The administrator can assign users to the security role samples, modify the security role samples based on business needs or create security roles. By default, the role examples are not hierarchical.
Duties
Duties are part of a business process. The administrator assigns responsibilities to security roles. One responsibility can be assigned to multiple roles. In D365 Finance, responsibilities contain privileges. For example, the Maintain Banking Transactions duty contains generate deposit slips and cancel payments privileges. Duties and privileges can be assigned to security roles. However, we recommend that you use duties to grant access to D365 Finance.
Privileges
Privileges can be assigned directly to roles. However, for ease of maintenance, we recommend that you assign only duties to roles. A privilege specifies the level of access required to complete a job, solve a problem or perform an assignment. It also contains permissions on individual application objects, such as user interface elements and tables.
For example, the Cancel Payments privilege contains permission on menu items, fields and tables that are required to cancel payments.
By default, privileges are provided for all D365 Finance features. The administrator can change the permissions associated with a privilege or create privileges.
Permissions
Permissions represent access to individual secure objects, such as menu items and tables. Privileges are composed of permissions and represent access to tasks, such as posting a journal and processing credits and collections. Duties are composed of privileges and represent parts of a business process, such as maintaining cash and bank transactions. Duties and privileges can be assigned to roles to grant access to D365 Finance.
In D365 Finance, each function, such as a form or service, is accessible via an entry point. Menu items, web content items and service operations are collectively referred to as “entry points”.
Authentication
Only authenticated users with user rights in D365 Finance can establish a connection. D365 Finance use Microsoft Entra ID as their primary identity provider. To access the system, users must be provisioned in an instance of D365 Finance and must have a valid Microsoft Entra ID account in an authorized tenant.
Authorization
Authorization refers to control of access to the D365 Finance program. Security permissions control access to individual program items: menus, menu items, action and command buttons, reports, service operations, web URL menu items, web controls and fields in the D365 Finance client.
In D365 Finance, individual security permissions are combined into privileges, which are themselves combined into duties. The administrator grants program access to security roles by assigning responsibilities and privileges to those roles.
D365 Finance uses contextual security to determine access to securable objects. When a privilege is associated with an entry point (such as a menu item), an access level, such as Read or Delete, is specified. The D365 Finance authorization subsystem detects access at runtime, when a user accesses this entry point, and applies the specified level of access to the securable object that the entry point leads to. This feature ensures that you do not assign more permissions to a user than necessary.
Audits
User sign-in and logout auditing is now enabled in D365 Finance. The system logs when a user logs in or out of the application. A logout is recorded even if the user’s session expires or ends.
A system administrator or security administrator can access audit logs via the User Log page (System Administration> Inquiries > User log).
The External Roles form allows administrators to assign security roles to an external role such as a customer, supplier, prospect, potential supplier or collaborator.
The Inactive User Security Accounts page allows you to identify inactive accounts and determine whether accounts are enabled or disabled.
Encryption
Encryption at rest
Microsoft uses encryption technology to protect customer data while at rest in an environment’s SQL Server database and Azure Storage.
D365 Finance uses server-side encryption using service-managed keys. All aspects of key management, such as key issuance, rotation and backup, are handled by Microsoft.
In addition to the default encryption at rest mentioned above, you can use the encryption API available in the Global X++ class.
The Global::editEncryptedField() and Global::editEncryptedStringField() methods use the environment-specific data encryption certificate to encrypt and decrypt data. You can use these methods to provide an additional layer of protection, in addition to the default rest-encryption technology used for data storage.
Encryption in transit
Connections between clients and Microsoft data centers are encrypted and all public endpoints are secured using the standard TLS 1.2 protocol. TLS effectively establishes an optimal secure connection between the browser and server to ensure that data confidentiality and integrity are preserved between desktops and datacenters.
Extensible data security policies
XDS allows developers to supplement role-based security by restricting access to table records based on security policies. The query in the policy applies a filter, and only records that meet the conditions of the filter are accessible from restricted tables.
The data security policy components are:
- Constrained tables: the table or tables from which data is filtered or secured. For example, in a strategy to secure access to transactions based on the client, the CustTrans table would be an example of a restricted table.
- Primary table: allows you to secure the contents of the associated restricted table. In the example below, the CustTable table would be the primary table. The primary table must have an explicit relationship to the restricted tables.
- Policy query: Allows you to secure the contents of constrained tables by using a range condition on the contents of the primary table. Only the recordings included in the range are accessible. For example, the range can be based on a specific value for Client.
- Context: controls the conditions under which a strategy is applicable. Two main types of contexts are available: role context and application context:
- Role context: based on roles assigned to the user. Two sub-options are available for the role context:
- Role name: indicates that the security policy is applied only to the application user assigned to the role equal to the value of the Role Name field.
- Role property: This value is used in conjunction with the ContextString property to specify the context of multiple user roles. It is applied when the Context String value set in the policy’s Role Property field is the same as the ContextString field for assigned user roles.
- Application context: applied if the context string defined by the application using the XDS::SetContext API is the same as the value defined in the Context String field for the policy. In the Application Object (AOA) tree, policies and their components are displayed under Security > Policies.
The policy query is added to the WHERE clause (or ON clause) on the SELECT, UPDATE, DELETE and INSERT operations involving the specified constrained tables. Unless carefully designed and tested, policy queries can have a strong impact on performance. Therefore, be sure to follow simple but important guidelines when developing an extensible data security strategy.
If at least two security policies apply, the intersection (not the union) of records included by each policy is the only accessible record. In other words, a record must meet all applicable security policies before access to the record is allowed.
D365FOAdviceTips 
Leave a comment