Download presentation
Presentation is loading. Please wait.
1
Security Overview of Dynamics AX and D365FO
Alex Meyer Director of Dynamics AX/365FO Development Fastpath, Inc. Twitter: @alexmeyer_ITGuy Blog: d365foblog.com
2
Agenda Welcome AX 2012 Security Model Overview
D365FO Security Model Overview Security Development Tool Demo Common Data Service GDPR Features Questions
3
AX 2012 Security Model Hierarchy based users are assigned roles which are made up of duties which are made up of privileges and access to tables, forms, menu items are assigned to privileges.
4
AX 2012 Security Model AX 2012 D365FO Pessimistic security model
Template Roles, Duties, Privileges are delivered Roles are system wide User roles can be restricted by legal entity Record level security is available Replaced by Extensible Data Security (XDS) Policies Setup users via Active Directory Groups Security reports – limited D365FO Follows the same security model with minor differences Pessimistic security model – user only has access to objects they have explicitly been given permissions to XDS – Restrict access to data based on effective date, sales territory, or organization Setup users via Active Directory Groups – authentication in AX is done by Active Directory, so you can create an AD group, put AX users into that group, then setup and assign security to that group within AX, all users in that group will be granted the security of the group
5
Assigning Object Permissions
AX 2012 D365FO AX 2012: Hierarchy based No access -> View -> Edit -> Create -> Correction -> Full Control (Delete) One access level per object D365: Still hierarchy based Can have multiple access levels per object Unset – No access is assigned Grant – access level is granted for this access type Deny – explicitly denying access to an object overrides any grants assigned to the user from any other role, duty, or privilege
6
Environment Differences
AX 2012 Design time and runtime lived in same environment D365FO Design time is on development VM, runtime is web app in Azure Design Time: Where code is developed and customized Runtime: Where application is actually ran D365FO Design Time: Visual Studio environment Runtime: Azure If you create/customize a role, duty, or privilege in the UI, a delta is created and applied to the environment to reflect that change Customizations done in the UI are not ‘development artifacts’ (code) in that they cannot be moved from the runtime to design time currently (Microsoft working on making a method to do this) This is a big deal because if you want to move roles between environments (dev/test -> prod) you need your security to be in the design time(code) to be able to create a package to move Best advice, is to create all role, duties, and privileges in your design time environment (Visual Studio) so all of your security changes are captured and can be applied to other environments.
7
D365FO Data Security Transparent Data Encryption – Data and logs in Azure SQL are encrypted at rest Table Permissions Framework (TPF) Used for High Business Impact (HBI) data Users must be given explicit access to field otherwise it will be hidden Can be applied at field level Extensible Data Security (XDS) still available Transparent Data Encryption – client does not have to do anything to set this up, it is all done by Azure SQL behind the scenes Table Permissions Framework – With Dynamics 365 can not be applied at the field level for the table, in AX 2012 this had to be turned on at the table level first and then each field of the table would have to be set manually
8
Entry Point Security If accessing the form through menu item 1:
In AX 2012, the effective permission to the table is DELETE In D365, the effective permission to the table is READ D365 honors the menu item permission when accessing the form One main difference in security from AX 2012 to Dynamics 365 is entry point security. In the scenario we’re looking at here we are going to assume you are accessing a form within either AX/Dynamics 365 through a menu item (in our case menu item 1) that you have READ access to. You also have access to this form through another menu item at a DELETE level. In AX 2012, the security framework took the highest permission level that you had through a menu item and applied it to the table. Which means in this case, you would have DELETE access to the table and because command buttons on the form were tied to table access this would inadvertently allow users who had accessed the form through a READ menu item to modify the object (an example of this would be the DELETE button being enabled). In Dynamics 365, the menu item permission is honored when accessing a form. So if you access a form through a READ menu item, you will only have READ access to the table, if you access the form through a DELETE menu item you will have DELETE access to the table.
9
Data Entities New to Dynamics 365
Encapsulates a business concept that may exist across multiple tables with Dynamics 365 Allows for easy CRUD operations (especially from outside of Dynamics 365) Template Data Entities come out of the box, can create customized ones as well Have their own security property called Integration Mode Basically it’s a SQL view that allows for CRUD operations As far as security, treat them as a table Data services - The ability to use OData services (API) for the entity. Data Management - The ability to use asynchronous integration options for the entity, such as import/export and connector integration. Gives ability to interact with the system without writing X++ or going directly to SQL
10
Security Development Tool in AX
‘Beta’ tool from Microsoft Security reporting Task Recording Test workspace Reduces need for test user accounts Limitations Cannot open test multi-role assignment (Can use sub-roles) Does not work if you use AD Groups for user provisioning Licensing D365 – Where’d it go? Beta tool from Microsoft, it’s been in beta since AX 2012 was released and probably will probably never be ‘officially’ released Had it’s own model file you had to import to add to your environment Allows for getting very granular security reporting (role -> duty -> privilege breakdowns) Task recordings (recording steps taken within the application) Allows for testing a role within a test workspace without having to assign the role to a test user for testing Has licensing reports surrounding users There is no separate security development tool in Dynamics 365, Microsoft has decided to bring most of the features over and put them directly in the application itself The reason they did this is because in AX 2012, the design time and run time environments sat on the same machine so it could interact with both With Dynamics 365, the design time is completely separate from the runtime so the tool had to be written into the application itself
11
Demo
12
Common Data Service Centralized database to aggregate data from multiple systems Includes mappings from source to destination environments Comes out of the box with standard entities called the Common Data Model, can also create custom elements Being transitioned to new version called Common Data Service for Apps (built on XRM platform with Power Apps front-end) Since CDS is built on XRM platform, security model follows CRM security model Roles -> Privileges Sharing Access Levels: Global, Deep, Local, Basic, None CRM Security Model Out of box: Roles (14) -> Privileges (580+) Access Levels: Global - This access level gives a user access to all records within the organization, regardless of the business unit hierarchical level to which the instance or the user belongs. Users who have Global access automatically have Deep, Local, and Basic access, also. Because this access level gives access to information throughout the organization, it should be restricted to match the organization's data security plan. This level of access is usually reserved for managers with authority over the organization. The application refers to this access level as Organization. This access level gives a user access to records in the user's business unit and all business units subordinate to the user's business unit. Users who have Deep access automatically have Local and Basic access, also. Because this access level gives access to information throughout the business unit and subordinate business units, it should be restricted to match the organization's data security plan. This level of access is usually reserved for managers with authority over the business units. The application refers to this access level as Parent: Child Business Units. Local - This access level gives a user access to records in the user's business unit. Users who have Local access automatically have Basic access, also. Because this access level gives access to information throughout the business unit, it should be restricted to match the organization's data security plan. This level of access is usually reserved for managers with authority over the business unit. The application refers to this access level as Business Unit. Basic - This access level gives a user access to records he or she owns, objects that are shared with the user, and objects that are shared with a team of which the user is a member. This is the typical level of access for sales and service representatives. The application refers to this access level as User. - Example usage would be creating a user or sales order in one system and wanting to push that data into D365FO, you would push that data into CDS from the source system and D365FO as the destination system would consume that - Continuing with this example though, now you can modify D365FO data from outside of D365FO and could bypass the application security all together - Also your D365FO data could live in this database as well (GDPR concerns) - If you are planning on using this system you should have a plan in place for auditing this feature for security
13
GDPR Features Roles with Sensitive Access
Located in System Administration -> Inquiries -> User Log Records all user logins to environment, can also specify roles that have ‘sensitive access’ whenever a user logs in and is assigned one of those roles it is recorded
14
GDPR Features Asset Classification on table fields
Available on all table fields Added in PU8 Allows for classification of data that resides in the table field
15
GDPR Features Asset Classification on table fields
Customer Content – data collected and managed by the controller End User Identifiable Information (EUII) – natural value used to identify a user of the service End User Pseudonymous Information (EUPI) – generated value used to identify the user of the service Organizational Identifiable Information (OII) – value used to identify the organization using the service System Metadata – value that describes the software or used by the software Object Metadata – value that describes the software or used by the software Account Data – value provided by or used by the tenant to identify the billing information or identify the software Support Data –information used to provide customer support
16
GDPR Features Person Search Report
Can search by Id, Name, or Address Information
17
GDPR Features Person Search Report Results
Example results of the person search report
18
Common Security Challenges
Access security is low priority for project team Everyone assigned System Administrator Security is in the domain of IT/Sys Admin not BPOs Expensive customizations in place of security No consideration for segregation of duties Process controls not part of the design Dilution of ‘go-live’ security design Access security is a low priority for project team If user says they need permissions to x, y, and z it’s easy to just give them this access without thinking of ramifications of that User productivity > validating user should have this access Everyone assigned sys admin Easy cop out Something to watch out for if using customizations or 3rd party vendors (make sure to get a least privilege role set up) Security is in domain of IT not BPOs BPOs know what user should have access to but don’t have permissions or understanding of system to correctly assign rights to user, IT has ability to assign these rights but no idea if users should have these rights or issues that could arise from assigning these rights Expensive customizations in place of security Instead of addressing security directly, sometimes complex customizations are applied to enable/disable certain features Can add unneeded complexity and might incur a performance impact No consideration for segregation of duties During designing of security, very rarely are SOD principals kept in mind. Much easier to design initial security with SOD in mind rather than going back after the fact and reconfiguring security to include this Process controls not part of the design During security design, controls for SOD issues are not designed and/or documented. Being able to effectively document current controls ahead of time will save you a lot of time/stress during an audit Dilution of ‘go-live’ security design It is important to get security set up correctly at ‘go-live’ but also to important to revisit your security on a periodic basis ‘Permission creep’ can occur where users just accumulate permissions and user access is not reassessed No user is ever going to complain about having too much access
19
Reviewing Security Take a risk based approach to reviews
Monitor and report on user access BPOs should review access Update process controls and SOD rules to reflect security changes Take a risk based approach to reviews Not every permission within AX is important or critical when reviewing access Limit down scope to critical areas when doing reviews BPOs should review access IT does not know whether a user should have a particular access BPOs should be involved in access reviews to validate security Monitor and report on user access Have a process to be able to report on user access If an auditor came to you tomorrow and asked which users have access to a particular object could you answer them? SysAdmin - Obviously very important to know who is assigned this role at all times ‘Firefighter access’ situation, make sure role is revoked Update processes, rules, and matrices As security changes, you will want to revisit controls and SOD rules
20
Resources Book Whitepaper Security Matrix
Security and Audit Field Manual for Microsoft Dynamics 365 Finance and Operations 2nd Edition available at Summit Phoenix Whitepaper Develop and Implement Least Privilege Security for Dynamics 365 for Finance and Operations Security Matrix AX 2012 D365FO
21
Fastpath for Dynamics AX/365FO
Fastpath ensures our customers can confidently answer these three critical questions: Who has access to their systems? What did they do with that access? Where are they vulnerable? Assure Segregation of Duties and Security Access Reviews Audit Trail Critical Data Change Tracking Identity Manager Compliant User and Emergency Access Provisioning Security Designer Create and Change Security in Dynamics Assure – shows where users have access and how they are getting that access Audit Trail – shows what users are doing with their access Identity Manager – workflow around user provisioning and modifications If you have questions or interest about our products feel free to contact or
22
Links Dynamics 365 For Operations Blog (Personal Blog)
YouTube Tutorial on Simulating the Security Development Tool in Dynamics 365 for Operations (5:35) D365 Wiki Task Recorder in Microsoft Dynamics 365 for Operations Security Development Tool User Guide Microsoft Dynamics AX 2012 R3 Licensing Guide Introduction to Microsoft Dynamics 365 licensing Dynamics AX Server Team Blog Role-based Security Use Patterns for Developers Developing Extensible Data Security Policies Security Roles & Licensing Whitepaper Table Permissions Framework Transparent Data Encryption Understanding Security in Microsoft Dynamics AX 2009
23
Questions? Alex Meyer Director of Dynamics AX/365FO Development
Fastpath, Inc. Twitter: @alexmeyer_ITGuy Blog: d365foblog.com
Similar presentations
© 2025 SlidePlayer.com Inc.
All rights reserved.