4. The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle. Safe Harbor
5. Overview <Insert Picture Here> During any implementation or upgrade, security becomes a huge project task. The typical project will run into resource issues as the functional teams are trying to accomplish their testing and configuration. Security tends to get put on a back burner, or even forgotten about as pressing deadlines start to loom closer and closer. How do you plan security tasks into a project, so that you are better prepared, and what considerations should be prepared for early on in the project to help pave the way down the road?
What decisions need to be made in the first month of the project plan? (3c, groups, si’s the whose & methodologies) Who should be making those decisions? Early tasks that should be taken prior to letting the users into the database environments? (process, mass change, primary, dda, query trees, baseline user profile for self-service. Mapping pages- Who and How? PeopleTools, Reporting Tools and other Misc. page Permissions Designing, Building, and Testing permissions Row Level security, Defining SACR, Functional teams responsibilities for Security Config pages (enrollment, actions
If using consultant, bring in early, get through 80% or so, then come back week or two before go-live through week or two after
Main Points- Get the leads behind this early on, separate security pieces, App security, data security, query security, process security, mass change, search match, and the list goes on! There can be more than one way to reach the same page, highway, freeway, side roads, take the subway. Will you use multiple paths, or do you want to limit it to one?
This is a good place to bring up query security again, who needs access to the joint tables in query? HCM- Identify campus users needing access into HCM for HCM’s approval, and HCM employees that need CS specific pages.
Points- less intimidating to users coming into the system Focus the attention on the pages that matter Remember, these pages aren’t gone forever (big fear of some users) they can always view them and play with them in Demo, and they can be added back into the mix in the future if needed Query- Set up a “all access” node on the tree for records that all modules will need access to
Security decisions- parameters mandated by policy (separation of duties, masking, no correct history, no generic userid’s, no multiple userid’s for any user)
Have the teams start on their modules security mapping first, as the security person can start building this while getting approvals for the “shopping lists” By handling the cross module pages this way, you can get approvals, suggestions for better pages, or in some cases decisions for no access to the requested pages, as well as people may realize that they also need access to a page another team is requesting
Schedule down time to refresh cache as this will be required once in a while. If it is scheduled, less impact to users. If you can get security tested prior to SIT or UAT, great
Determine ahead of time when the “god access: ID’s get locked in testing process, and production security becomes the name of the game.
Differentiate go to from earlier slide from modules go to person
Function- less personal, more flexible, less maintenance- pages exist in only 1-3 pemission lists, depending on the level of access needed Roles- less thought, less permission lists, more work to maintain the PL’s as pages may exist in many more PL’s during an upgrade, patch, update