Using Multiple Alternate Access IDs

The sample PeopleSoft Database Vault security policies provide protection of highly sensitive information in the PeopleSoft tables from database "super users." In some cases, you may need a more tailored access, such as in the cases of upgrades, patching, auditing, and the separation of duties for the PeopleSoft Access ID.

You can leverage Database Vault so that PeopleSoft tables, procedures and triggers could be protected can still be protected while allowing special access to complete upgrade and maintenance tasks. The privileges in the Database Vault PeopleSoft template can be given to the multiple, alternate, access IDs. By using multiple, alternate, access IDs to perform PeopleSoft maintenance, you can mitigate the issues involved with distributing the password of the base access ID to multiple users.

The multiple, alternate, access IDs (PSFTDBAnn) technique has been tested with Database Vault in the field on PeopleSoft installations and offers a solution where unique, identifiable accounts can be used to perform PeopleSoft patching and upgrades. These accounts can be limited to the modules and machine names from which the PSFTDBAnn ID can run. These accounts also can be heavily audited, to make sure that they do not introduce malicious code, which removes the need to implement heavy auditing on the base access ID account.

With multiple, alternate, access IDs you can:

• Use multiple, alternate, access IDs that can be used just for PeopleSoft upgrade/maintenance.

• Create PSFTDBAnn accounts that have many auditing options enabled, not affecting the use of the production access ID (SYSADM).

• Use Oracle’s Audit Vault to enhance the separation-of-duties when it comes to centrally managing audit information.

• Configure Database Vault so that the PSFTDBAnn account can be restricted to particular machines and times, and so on.

• Tale advantage of Database Vault's strictly DBA account(s) (PSFTDBA) that can modify the database and system, but not issue selects on tables in the PeopleSoft Realm. The PSFTDBA account can do many DBA activities such as alter tablespaces, examine performance, start and stop the system, but not see sensitive information. The PSFTDBA account can apply Oracle Database Patches, but not apply PeopleSoft type of patches.

• Restrict knowledge of the access ID password, as it is no longer required for PeopleSoft maintenance.

• Address many more of the concerns third party auditors are identifying on systems that contain highly sensitive information in PeopleSoft applications.

In the following examples, the unofficial account "PSFTDBAn" represents multiple access IDs, although it can be almost any name. The PSFTDBAn accounts need to retain the ability to do ‘SELECTS’ on PeopleSoft objects. This technique leverages a protected Login Trigger that alters the CURRENT_SCHEMA, so that the PSFTDBAn accounts can act as the access ID (SYSADM) account, but preserve the user's identity (PSFTDBA1) when running any commands.

To configure multiple, alternate, access IDs:

1. Create one to 'n' multiple, alternate, access IDs (authorized Oracle USERS):

   create user psftdba1 identified by oracle_1;
   create user psftdba2 identified by oracle_1;
   create user psftdba3 identified by oracle_1;
   

2. Grant minimal privileges to these alternate authorized USERS:

   grant connect,resource to psftdba1;
   grant connect,resource to psftdba2;
   grant connect,resource to psftdba3;

3. CREATE an Oracle instance level logon trigger to issue an ALTER SESSION SET CURRENT_SCHEMA whenever an alternative authorized user logs into the instance.

   drop trigger psft_login_trg;
   create or replace trigger psft_login_trg
   after logon on database
   
   begin
   -- * use dvf if in a database vault environemnt.
   -- * database vault would also help protect the peoplesoft realm, and 
   logon trigger, and so on
   -- if dvf.f$session_user in ('PSFTDBA1' , 'PSFTDBA2', 'PSFTDBA3') then
   if sys_context('userenv','session_user') in in ('PSFTDBA1' , 'PSFTDBA2',
    'PSFTDBA3') then
   execute immediate 'alter session set current_schema=’SYSADM';
   end if;
   end;
   /
   
   

Every time one of the alternative authorized USERs logs into the instance, an ALTER SESSION SET CURRENT_SCHEMA=ACCESSID is issued. From here on in any operation performed that is unqualified would be done in the ACCESSID schema.

For example, if the 'PSFTDBA1' were logged into the database directly using SQLPLUS or indirectly using Data Mover, then any 'VALID' operation performed that is unqualified would be done in the ACCESSID schema. All of ‘PSFTDBA1's actions on the database could be audited if the Oracle Auditing facility (Audit Vault) were used. If you need to verify you have database connectivity, you can use the PSFTDBAn account for your test. Data Mover and SQR testing from the workstation will be able to use the PSFTDBAn account.