-
-
Question:
Answer:
There are certain fields in JDE that contain personal identifying information (PII). The data is grouped into two areas: Address Book and HR Data. The Address Book fields include Tax ID, Additional Tax ID, Address, Phone Number, Electronic Address, Date of Birth, Gender, as well as up to 8 user-defined fields. The HR data is more extensive and contains sensitive data like pay rate and Social Security numbers that should not be available to those who are not directly working with them. These could be of value for bad actors if they had access to them, so it is important to control access.Address Book fields are grouped into categories called search types based on the type of Address Book entry. There are three default search types and many more that can be set up to allow for more control. The three default search types are Employees (E), Vendors (V), and Customers(C). The fields can be restricted independently for each search type by using Personal Data Security. Personal Data Security is a feature that is disabled by default (P0000/Address Book Constants) and controls access by using Permission Lists (P01138/Address Book Data Permissions).
Permission Lists control the ability to view the address book fields for each search type. For example, there could be one Permission List that shows all fields for employees and blocks all fields for customers and vendors as well as another list that shows only contact information (Phone number and email) for all search types. The Permission Lists are given to users or roles by utilizing Permission List Relationships (P95922) in a similar fashion to security. It is important to note that each user can only have 1 active Permission List, so you need to be careful how they are defined and assigned to users or roles. The first list would be used by someone in HR who sets up all information for new employees while the second could be given to all users in the system to allow them to communicate more easily. HR Data is controlled in a similar way. The data can be moved onto its own data source and must be granted to users or roles.
With this information, you can set up Personal Data Security in a variety of ways, but there are best practices to ensure that your data is secured. The strategy that we recommend is to create a baseline level of access that is granted to all users and to grant additional access through Permission Lists assigned to roles (and named accordingly). The first step is to create the baseline list for *PUBLIC. A good baseline to make sure that all access is intentional would be to hide every field in every search type, but it may make more sense to allow, for example, all contact information to be viewed and nothing else. The baseline should work with the rest of your security model. Next, you want to create permissions lists that make sense for your business and assign them to the appropriate roles. This allows you to manage permission lists by simply assigning a role. There could be many permissions lists depending on the amount of control your business needs. Since only one permission list can be active at a time, users that would be using the Permission Lists for multiple functions will need to have their own permission list that incorporates all the allowed fields for each search type. If most of the users work in many areas, it may be easier to design your security model with permission lists assigned directly to the users without intermediate lists assigned to the roles.
Perhaps you want your shipping users to have access to all customer information except tax IDs, but no access to vendor or employee information. Set the permissions list to reflect the search types and fields that are appropriate for the business function and assign the list to the role for that business function or directly to the users who perform it. There should be access to all fields for setup purposes, although this can be split into multiple lists for more control (HR setup separated from vendor or customer setup). Now the permissions lists and relationships have been developed to match the security model you are using, but the fields are still only secured in programs related to Address Book. The information is used in many other applications, and the data is not yet fully secured. The important last step is to extend the protection from Personal Data Security across the system. This is accomplished by changing the JDE.INI settings to enable the data privacy skip record (enableDataPrivacySkipRecord = true). The default option for this is false, which allows records to appear in other output sources.
The last step in securing your company’s Personal Identifying Information is to segregate the HR data into its own data source. Setting up the data source is similar to what was done in implementation, so we won’t go over it here. Data sources can be granted to users or roles, so access can be limited to the users who have a business reason to be using that data. Unless a user has been granted access to the HR Data Source, they will have no way of accessing or viewing the data that is contained within that Data Source. The Data Source should be setup using a DB user different than what is used for the default Data Sources to further ensure separation of access. Our recommendation to control access is to verify that access is removed from all users and grant access through the appropriate HR roles or by assigning access directly to the users. In this way, you can make sure that no unapproved users have access to your company’s HR data.
To sum up, just because application and action security are controlled in your system, does not necessarily mean that your PII Data is secured. Having a proper data security plan and structure in place will allow for peace of mind that the personal information of your vendors, customers, and employees is secured. More importantly, this data is only being accessed by users that have been granted that access specifically. Business (and personal) risk are drastically reduced with a strict and effective PII Data plan.
If we can help with any questions, please email us at inquiries@getgsi.com or click Contact Us.
Meet the Author
Dillon Connor, gAcademy Consultant - Security CPD