Separating PD security from PY/DV

[Muhammad]

Hi,
Currently we have one security for PD, PY, and DV. Auditors have asked us to separate PD security from rest of PY and DV. I would appreciate if someone can please point me some document or steps of separating the PD security from rest of environments.
Thanks
Muhammad

 

[klwong]

This is not a standard practice, and I don't know of available documentation for it. Are you just trying to separate just the security (application, action, etc.), or are you also trying to separate the user IDs, passwords, etc.?

 

[antoine_mpo]

Hi Muhammad,

Would you give more information about your architecture ? What version of EntrepriseOne do you use ?
And indeed, you should be more precise about what you mean by "security", because this cover several things.
I'm talking about Xe, because i don't know if it still the same in earlier version, but security is mainly with the following tables :
- F00950, where are stored application security, row exit security, action security, row security, ...
- F0092, where are stored users and groups
- F98OWSEC, where are stored user passwords

In E1 xE standard, they're all tables from SYS7333.

Personnaly, i've already used different F00950 tables for 2 environments, mainly for security set up testing.
In that case, you need to create (generate through OMW) another table in a different datasource, and then add OCM Mappings for the environment you want to separate.

Except the fact you have to always be careful where you are when you make security change, something you must be aware of is that in web client (at least if using websphere), if you allow to connect to several environments from the same WAS node (which is possible even if not really recommended), the security table used will always be the one set up for the "default environment" (defined in the jas.ini of the WAS). So if you set up a different security table for let's say PY7333 environment, and the default environment of your WAS in DV7333, it won't use the security table you expected.

About F98OWSEC, never tried to use different ones with different environments (i mean except if you have different environments in seperate platforms with their own set of Data dictionnary, System tables, ...), and honestly, don't really see in what way it could be useful.

Is this any help ?

Regards,

 

[Robert Robinson]

Whoa...before we get to the HOW, let's get the answer to WHY...I have audited through JD Edwards in a previous life, and have never felt the compunction to separate prod and non prod instances for the purposes of security (there are plenty on mitigating controls that can be established to control and monitor access to PD). Further, at my current company, we are under the august auspices of Sarbanes-Oxley (something similar to having an elephant stand on your chest and never get off) and our auditors have NEVER asked us to separate the instances.

The questions to ask are, what is the audit objective? What key control will be satisfied by separating the instances? Can audit satisfaction be gained by using an additional review process? And, most importantly, what additional in- house costs will be attendant to this change (e.g. increases in time spent in security maintenance), because the cost of an audit control should NEVER exceed the benefit derived from said control.

Off my soapbox now...

 

[habarric]

If you have your roles setup properly and have roles that are specific to production(ie, roles only have access to PD, not other environments as well) then you already have your security separated.

If you wanted to go the more complex route, I think it would be easy enough to just OCM the F00950 table to an environment specific data source, but then the only way to promote security changes is to copy them up with SQL or F98403, which adds another layer of risk.

 

[m@dm@x]

I'm currently in the process of doing something similar in nature. I've created a seperate data source for F00950 for specific users and used OCM to point them in the right direction.

Max

 

[jjanowski]

This practice is very common and works GREAT. You Just need to OCM map F00950. It introduces a greatly simplified structure for change management. It also can greatly reduce the roles required in your overall JDE model if introduced correctly/intelligently. It creates a landscape much more mindful of SOX. Watch out for Bootstrap tables. F95921 is an example – BOOTSTRAPS CANNOT BE OCM’d.

Basically you have Prod(PD) security and NonProd(PY,TS,DV, etc…) security for everything else – It is that easy. You can give a developer role full access (minus Security and CNC) in non prod and read only (Business Analyst) in Prod on the same role. PRETTY KOOL…

 

[Jfreyre]

I couldn't agree more It works pretty great, and as a matter of facts I use it as some sort of change management cycle in a security context, but of course every time We want to promote the changes into our production environment I have to recreate them as I've never made the needed tweak in our system. Anyway I wonder what do you think, should I add some flag column in our custom security table in order to copy the registries between datasources? and How should I copy those rows between them?

 

[jjanowski]

I have always done the manual approach. Basically doing the sec changes 2x – 1st time in NONPROD (DV,TS,PY) to test/document user approval and then 2nd time in PROD(PD) simulating a promotion. I have made mistakes which could justify enhancing (writing your suggested program) for the process to eliminate redundant entry. A custom copy program to systematically manage moving the NONPROD data source (intelligently selected) records (after final approval) would be REALLY nice and error proof. I would recommend a UBE that documents the before and after records. Associate the system outputted documentation to the security change tickets and you are really SOX friendly.

I would go as far to say it is impossible to challenge technical security change management with your idea…

 

[Jfreyre]

that's a pretty good idea of yours but what if (I'm not completly aware of the regulations on SOAX) you store those changes in a custom table? wouldn't be easier have an auditable table of those changes?

I wonder what muhammad thinks about the ideas discussed in this topic.

 

[jjanowski]

Also great idea. Audit table would work nicely too.

I would still suggest some reporting features – US SOX auditors tend to really like (system generated) evidence attached to change tickets.

 

[altquark]

>sigh<

And yet another "workaround" created for Xe days manages to slip into 8.12 and 9.0 installs.....

Guys, there is NO SOX requirement that require any company to create separate ID's between pre-prod and production. In fact, "Segregation of Duties" has NOTHING to do with SOX compliancy WHATSOEVER. I've read the text of the law, back to front, and presented at Quest several times on the actual issues related to Auditors "muddying up" the waters of what SOX compliancy is (my presentation can be viewed from either my website, or on the Quest website from 2007 Collaborate - breakout session 23130).

At the end of the day, the only section that deals with development and production is Sarbanes-Oxley Section 404.

[ QUOTE ]

Management Assessment of Internal Controls
- Operational processes are documented and practiced demonstrating the origins of data within the balance sheet
Internal Controls Management
- Establishment
- Maintenance
- Documentation
- Transparency


[/ QUOTE ]
Section 404 asks companies to establish internal controls management, maintain the procedures set in place, provide documentation and full transparency of procedures.

Thats it. Read the entire SOX law, and the entire thing comes down to the fact that you have to provide supporting documentation to explain how code got into PD. Surprise surprise.

So, once that has been put to bed, lets talk about companies that DO want to create Segregation of Duties for whatever other reason.

Under Xe, it wasn't really possible to segregate developers from accessing PD "differently" than in DV - without taking two routes :

1. Give the developer two user ID's (one for DV/PY, another for PD)
2. Create two F00950's and maintain security twice

Now, along came roles in 8.x - and its possible to have multiple roles for a user - and each role can be assigned an environment. So, it IS now possible to limit a developer's ID in PD completely differently to how they access DV. Without the necessity of creating multiple ID's or F00950's. Thankyou JDE.

To sit there without knowing what version Mohammed is referring to and then come out with blanket statements about the two F00950 file solution being "commonly used" is not accurate with 8.x customers.

Lets please, please identify WHAT solutions are best for WHAT versions of JDE. Sorry about the rant, but I want to clarify that the practice of using multiple F00950's is actually an OLDER practice no longer in use or required in 8.x

 

[cdawes]

Multiple F00950's are still used in the 8.9 - 9.0 world but not usually from a SOX perspective - mostly from a CYA perspective.

I typically see this used where there have been "issues" with the security setup and the Functional team needs to validate the setup before it it used in Production.


This scenario allows testing in Non-Production before "promotion" to Prod. Way too many examples where Security can actually hurt you.

Take for example row security where JDE doesn't always tell you that only 1/2 of a transaction worked. It may appear that the security was initally okay but it's not until someone on the functional team does the validation that they find the "oops".

So in this respect it can still be very valid to have multiple F00950 Security tables.

To put this in real terms about 80% of the customers my company services have a single Security table if they are on 8.9 or later.

That leaves 20% with 2 (or more) security tables.


Colin

 

[jdel6654]

I think 20% is too low an estimate. Just based on the number of respondants to this post and my personal experience, I would say probably 50%. Multiple F00950's are not used for a CYA perspective. Each environment has its own purpose so it only makes sense that security would have a different function. I can think of probably a 100 reasons why you would have to have multiple F00950's - none of which are related to CYA. In most situations you really have to lock down production. In a pre-prod UAT environment, you have to be able to test out the security without limiting your CRP team. In CRP, you have to prevent OMW kinds of changes (versions, etc.) without restricting people from menu changes and unneeded row security. In development, you really need to have open security. The reality is that if you know what you are doing, multiple security tables (and I mean more than just 1) can be managed.

Given the choice most CNC people would prefer just one with locked down security. The reality is that most businesses dictate the requirements for security not the CNC.

 

[Muhammad]

Excellent replies. This forum is much better than Oracle offcial support. We decided to separate PD from other environments by roles. This is simple and fulfill our requirements as well.
Muhammad