HR Security (or lack of)

[o2bnaz]

Help!

We have recently went live with the HR/Payroll module. We are on XE running
on an AS400 using DB2.

Situation: The developers (internal) have managed to access the HR tables via
UTB & RDA and take a peek at Salary info. JDE says that it has to be database
security and/or a ca-zillion column securities.

I know that through ODBC, they can get to the tables on the 400 (DB Security
is on it's way), but what can be done RIGHT NOW in OW-XE to stop these turkeys
without a lot of column/row security to kill the performance?

Any kind and thoughtful suggestions?

-Tom

____________________________________________________________________
Get free email and a permanent address at http://www.amexmail.com/?A=1

 

[AGARIA]

You must do several things to properly secure JDEdwards.
1) Make sure these administrators do not know the passwords to any database users that have access to data. (ex. jde, sa)
2) Make sure no one has access to the jde.ini on the server
3) Put security against everyone except yourself for running the security program.
4) Use JDEdwards column security on hr table that contains the data you don't want people to access. (Column security does not impact performance)

If you don't do all of the above, there are ways to get access to any table.

 

[cdawes]

Ouch, that's gotta hurt!

Here's what we do. We only give developers environment access to DEV. The
next thing I do is put Row security on the pathcode so developers can only
check in or check out of the dev path code:

ROW SECURITY

User/ Group Security Type Object Name Data Item Alias From
Value Thru Value
JDEDEV 4 *ALL CodePath PATHCD CRPB733 CRPB733
JDEDEV 4 *ALL CodePath PATHCD DEVB733 DEVB733
JDEDEV 4 *ALL CodePath PATHCD PLANNER PLANNER
JDEDEV 4 *ALL CodePath PATHCD PRISTB733 PRISTB733
JDEDEV 4 *ALL CodePath PATHCD PRODB733 PRODB733

Configure all pathcodes with no ADD, CHANGE, DELETE or VIEW except for
DEVB733.

Now to really cheese of the developers lock down the Database Source that
they can browse to. When they fire up UTB they can enter the table name and
then enter the datasource. Lock them out of this and give them View only
access. This way they can only see the Development datasources. Of course
this is all dependent on no 'real' data being in DEV (Business Data - TEST).

COLUMN SECURITY

User/ Group Security Type Object Name Object Description Data
Item Alias
*PUBLIC 2 *ALL All Objects DatabasePath DATP

Hope this helps.

Colin




Colin Dawes, MSc
Business Systems Analyst
The City of Guelph

 

[AGARIA]

Re: RE: HR Security (or lack of)

If you want to secure against everything, you have to secure the database too. Securing JDEdwards and/or limiting developers only to development will not stop access to the data. If they know what table that information is located in, what column that information is located in, what database that information is located in, and a database password (like the password for the JDE superuser), they can just go through the backend to check out the information. If you don't have your foundation secure, no amount of JDEdwards security will help you secure it. If all that is secured, then securing it through JDEdwards is all that you need to do.