Perils of DataMover Access – Part 1

Did you know that users connected to DataMover will have database access similar to access id?

What does this mean for you in a Production Environment? This can be really scary if you do not have security in place to ensure that DataMover access is restricted and controlled. Use the below SQL to determine who has access to DataMover, through which permission list and role.

SELECT DISTINCT A.CLASSID, B.ROLENAME, C.ROLEUSER
FROM PSAUTHITEM A, PSROLECLASS B, PSROLEUSER C, PSOPRDEFN D
WHERE A.CLASSID = B.CLASSID
AND B.ROLENAME = C.ROLENAME
AND A.MENUNAME = ‘DATA_MOVER’
AND D.OPRID = C.ROLEUSER
AND D.ACCTLOCK = 0

Ensure that the above SQL does not fetch any surprises.

What can a user with access to Datamover do?

As we see above, the user can create an Oracle user and grant DBA role to that user. And this is just one example of the access that is available to that OPRID after logging on to Datamover. Basically all access available to access id is now available to the OPRID.

Summary:
1. Ensure that only authorized OPRID’s have access to DataMover security in PeopleSoft
2. Audit changes to PSAUTHITEM
3. Control privileges granted to access id. Do not go overboard and assign DBA role to the access id.

Next Steps:
In Part 2, I will provide some tips on auditing online security to ensure that any online changes to DataMover access are audited.
In Part 3, I will cover tips for DataMover security in non-production environment and conclude the post on ‘Perils of DataMover Access’.