JDE HR Tables and Data Security

[jdel6654]

The company I am working for is starting a new project to implement JDE HR modules. There is a justifiable concern about data security.

Currently we run E1 in production for Distribution, Supply Chain, and Finance modules. The HR modules will be new.

I would like to get some feedback from other JDE HR customers (not necessarily PSFT customers) that utilize other JDE modules. I would like to know how they protect their data from 3rd party developers/contractors as well as unauthorized users & developers of E1.

We are trying to determine what is the best approach for protecting our HR data while keeping a relatively open and stable environment on the development, test, and production instances of SC, Finance, etc. that are already being used.

There are 2 schools of thought being considered:

A. Lock down all E1 app and db access in all environments and then merge in the HR "environment"

B. Segregate the HR-related tables onto a separate database server and lock down the other server. Use OCM mappings to tie the data from the different environments.

Any opinions would be greatly appreciated.

 

[morglum666]

I would use the absolutely vanilla, standard approach.

Within users of JDE you do the normal "All doors shut" model. You may need to get more creative for any interfaces (Database access, etc) but I would never set up custom security without having a really good reason to do so.

JDE's security model will protect HR and any other sensitive data you require. As a side note, we use HR as well and you will want to make sure you are using address book security and are on a later tools release as there was some limitations to address book security in older tools releases.

Malcolm

 

[jdel6654]

Thanks for your quick reply Malcolm.

I understand and agree with your all-doors closed approach to app security.

However, I am curious as to how you keep people from using SQL tools or MS Access or query tools from accessing this data?

 

[morglum666]

In terms of securing the database I think there are multiple approaches, with multiple pros and cons. I don't have a tonne of experience with it.

One option you can do is to take the default database accounts (CRPDTA, PRODDTA) and use custom passwords for them. If memory serves, you will need to store the new passwords on the deployment server and the enterprise server in their respective INI (JDBJ, etc) files. I did this at my last employer and it worked well and allowed us to secure interfaces.

However - Giant warning flag - Historically, there has been problems with ESUs and other upgrade type processes when some key accounts like JDE are not set to their default password. Hopefully the clue phone has been ringing at Oracle but you should be aware of this. My brain is telling me something about a table conversion nightmare but its been a while.

Theres a frequent poster on here who I think has some more ideas, I would try there as well...

http://jeffstevenson.karamazovgroup.com

Cheers!

Malcolm

 

[DBohner-(db)]

There are some REALLY Simple means, to Data Security:
- ONLY hire folks you CAN trust
- Get rid of folks you CAN'T Trust (zero tolerance)
- Don't provide external access to to the Database(s)
* SQL, ODBC, DB Tools ....

If there IS NO ACCESS, then you don't have to secure against access.

Troubleshooting and performance come into play, any time an organization becomes 'Security Happy' and disproportionate.

(db)

 

[Larry_Jones]

Sounds like your company has its family jewels dangling in the wind for anybody to yank or cutoff.

As delivered / installed, JDE schemas allows anyone (PUBLIC) full access to the database tables - Add/Change/Delete.

Its the Customer's responsibility to secure the data, change passwords, etc. Its not that hard to do. Otherwise you're hanging out there . . . ANY user can google standard passwords to PRODDTA. ANY user can google SQL commands. Security by obscurity doesn't work anymore (if ever).

 

[jdel6654]

In theory, I wish I could agree with you Daniel. But, my experience has been otherwise. Even the most moral / honest / ethical people like to dig into personnel and personal data for juicy tidbits. Until we became a JDE HR customer, we were mostly safe from this kind of thing. There's only so much benefit from old sales and manufacturing data.

And, if we were using another HR system like PeopleSoft or Horizon or something like that, I know for certain the databases wouldnt be shared with the same people that support the manufacturing and distribution aspects of the business. If we were on some other HR system besides JDE, we would be buying another set of database servers. The security people could lock down those servers to their heart's content.

I guess I was hoping that someone could offer an innovative approach. I have to admit that my idea to OCM map all of the HR data to another database server is not what the people leading the project want to see done. They want to get rid of all the tools that make it possible for admins and developers to do their jobs properly.

Its unfortunate that noone seems to have had to deal with this kind of thing before.

 

[DBohner-(db)]

If you don't provide Access via E1 (all doors closed) to your HR/PR Data, users will not be able to access your HR Data (work with Q-Soft or All-Out to make it secure, don't do it alone).

If you do not enable third-party tools/access to the database, Users/Customers/Consultants won't be able to dig into the data using third-party tools. The most dangerous thing you can do is to allow third-party access.

The concept of placing HR/PR data in other databases and on other systems has proven to be cumbersome - and troublesome.

As Larry didn't say, but would encourage - regular rotation of ALL Passwords is very recommended.

Every Company that does HR/PR has dealt with the issue - Generally, if your organization follows 'standard' Doors Closed, Password and locks third-party tools; it's not an issue.

My parts are not hanging in the wind, and my quarters are all stitched together - AND most issues have a very simple resolution, if you do not over estimate the problem. Now, Larry - would you kindly hand me back my credit card and forget my bank account numbers?

(db)

(db)

 

[Larry_Jones]

When I tried to buy a latte with it it said "DENIED!"

 

[jdel6654]

I got your point on all-doors-closed - no issue there.

The problem is not with app security, the problem is with 3rd party tools, mainly SQL.

[ QUOTE ]
If you do not enable third-party tools/access to the database, Users/Customers/Consultants won't be able to dig into the data using third-party tools. The most dangerous thing you can do is to allow third-party access.

[/ QUOTE ]

From my perspective, in this day of outsourcing, it really doesn't matter whether they are employees or contractors. The issue is around locking down sql-based tools. If you are doing any kind of development whatsoever, it is virtually impossible to take away SQL. You could even say this is true for system admin work too. Taking away SQL is the problem.

One could say implement table/object-based security. But if you do that, you will end up doing an enormous amount of working putting this in place. Why not just put the HR tables on another database server and be done with it? From my perspective, this is the central problem.

 

[DBohner-(db)]

jde,

Aren't those same employees and contractors that are implementing your HR going to be the one(s) you want to secure the data from?

Trust me, we see eye-to-eye that HR/PR data needs to be very secure. However, there are so many ways to attempt to secure it. If any one person has access to the data - then it is no-longer secure.

Note to self: The concentration should not be in Securing 'only' HR / PR data - it should be in securing System-Wide Data. How does it make sense to better secure HR/PR data, than a Customer / Vendor List? The IRS is fairly good at losing their data regarding Employees. Some companies live/die by their Vendor/Customer lists, alone.

The at-odds we face, are in 'why' one area warrants better security than any other. It is the System that should be secured - not, necessarily, the specific tables.

Usually, if you give a knowledgeable developer access to any area of your E1 implementation, chances are they will be able to find the door open to the areas they need access to (even when the doors are slammed). Give a developer ODBC access to your DV environment on an iSeries - and, in many cases, you just gave them SQL Access to the system.

(db)

 

[jdel6654]

[ QUOTE ]
Aren't those same employees and contractors that are implementing your HR going to be the one(s) you want to secure the data from?

[/ QUOTE ]

My company probably doesn't care if the other data is accessible. In fact, in many instances, any one of these people may justifiably need access to the Dist / Mfg / Fin data at any given time - and yes we trust them with that data. A great deal of this info is part of a regular financial statement.

HR/PR data is different. This is the kind of data that can cause havoc to a company's HR office if it is made public.

So yes I want to take away the tools (assuming I know all of them) to the HR data. For the other datum, not so much because the status quo already allows this access.

 

[riko44]

Interesting discussion ... we are utilizing multi-level approach –

Within E1 we do have ‘all doors/applications shut by default’ policy. Nevertheless only application security didn’t seem to be enough. There were multiple concerns – 1) we have multiple super-users who have access to Data Browser, so technically they can open any table.
2) Developers can also potentially develop applications that have access to any sensitive data.
3) There are also multiple third party tools (DSI for example) which access data using E1 but effectively bypassing E1 application security.

So we added additional level of HR security within E1. For that purpose we are mostly using table (row) security.
Couple dozen sensitive HR/Payroll tables are effectively blocked from *PUBLIC via Row security (for example for table F06017 / *PUBLIC / AN8 Row Security form 0 to 999999999 View=No’)
There is a special E1 ‘HR’ role that specifically grants access to the HR/payroll tables neutralizing *PUBLIC security. This gives us better visibility as to who has access to HR data. All such users must have ‘HR’ role.
We are also using Address book security

On the database level we are also using ‘all doors shut’ approach. .
Non-HR Developers/consultants who need direct Database SQL access have their own Database accounts with access only to the specifically listed tables (therefore HR/Payroll tables are excluded form all but few users)