Securing our Oracle DB

I wish to make our JDE Oracle data base more secure and am seeking guidance
on how to do that.

Our stats:
1. We are running OneWorld B733, SP11.1 on Sun Solaris UNIX.
2. We are using Oracle 8.1.6.

The JDE installation scripts (e.g., crusrs.unx) established various userids
(e.g., produser) with easy-to-discern passwords and granted all privileges
on every table to Public. That level of security is too loose for our shop.

I have found one Knowledge Garden document (oti-00-0115.htm) that addresses
the issue of securing Oracle objects, but it is incomplete from my
perspective. I have additional questions:

1. The abovementioned document lists three userids (jde, jdedba, produser)
as needing full privileges but then suggests that there may be others that
need similar treatment. What are the other critical userids used internally
by JDE apps?

2. We want to change the passwords for key Oracle userids (jde, etc.). What
do we need to do to keep JDE apps (e.g., P01012) functioning if we change
passwords associated with these userids?

hi marie,
while i am not an oracle guy a lot of security for one world applies to all data bases. to start you should change the JDE password and well as all of the other system-supplied user passwords. you must be very careful with changes to the JDE password since this is used in the jde.ini on your enterprise server to start services (at least they are called services on my sql database) and getting access to the oracle data base. if you change the JDE password without changing the jde.ini on your enterprise server your system will not run.
look on the KG for a white paper on changing the JDE password.
to the best of my knowledge the JDE user's password is the only only one that needs this special care.
dave


NT 4.0 SP5, SQL 7.0, One World B7321 SP12.4

Marie,

here's how we dealt with the same situation.

1. Create a role called JDE_ROLE
2. Grant this role to all JDE/OW specific DB Accounts
3. Write a SQL script that joins the OL table (objb733.f9860) and the Oracle DBA_TABLES view. This script generates the following commands for each table:
REVOKE ALL PRIVILEGES ON crpb733.f89210 FROM PUBLIC;
GRANT ALL PRIVILEGES ON crpb733.f89210 TO jde_role;
GRANT SELECT ON crpb733.f89210 TO _role;

At this point your database is secured from all non-JDE accounts except those who have granted the IT_ROLE - and they are Read Only anyway. Test the system (bring it up) and make sure everything is still functional.
4. Now you should secure the JDE DB Accounts by changing their passwords within Oracle. If like us you are using 1 master DB account for all users (the JDE one) DO NOT change this one yet. All the Schema Accounts though like proddta, objb733, etc should have their passwords changed. The runtime system DOES NOT use these accounts except when you are doing something such as creating (or re-creating) a table in the Object Librarian - the user is prompted for the password then. After making these changes again test that the system still works.
5. Now you're ready to change Master JDE account's password. For each user (except 1 or 2 admin users to leave as a backstop) change their System password to the new database password for their system (database) account. You can do this using P98OWSEC.
6. Change the master JDE DB account (which is JDE here).
7. The Enterprise Server's JDE.INI file has one or two places in it that need to reflect the change to the JDE db password. Specifically
[SECURITY]
USER=JDE
PASSWORD=XXXXX
You may also need to change the [NETWORK QUEUE SETTINGS] section if you've taken the steps to keep the ID and passwords for the UBE processes from showing when a ps -ef is issued from the Unix shell.
[NETWORK QUEUE SETTINGS]
QUser=JDE
QPassword=XXXXX
After making these changes bring the system up and test again. Is everything running? Can users connect?
8. Secure JDE.INI so only your UNIX JDE accounts have access to it.

Everything should be working and fairly secure at this point ...

I'm sure someone can point out any fallacies in the above process

Cheers!




Larry Jones
[email protected]
OneWorld B733.1, SP 11.3
HPUX 11, Oracle SE 8.1.6