BookmarkSubscribeRSS Feed
Reddy_GS
Calcite | Level 5


Hi Team,

I have question on SAS adminstration:

If 10 power users connecting to Oracle with common user id and password and all the 10 users have read and write access. How do monitor which user did what after connecting to data base. Suppose if some one deleted the data set from the oracel data base using shared user id and password how do we identify in SAS who did that particlar task and what time. (unix environment)

Appreciate for your time

Thank you

9 REPLIES 9
Doc_Duke
Rhodochrosite | Level 12

This is a good argument for ditching the common user ID.

A lot of SAS sessions will not have this information at all (EGuide can have an overall log turned on).  The unix admin logs may have when each user's SAS session connected to the Oracle server, but that won't tell you exactly who did the action if there were multiple logged on at once.

Reddy_GS
Calcite | Level 5

In this can how do we ensure there are proper security measures have been taken into the process and make sure we do not loose any data

SASKiwi
PROC Star

I am wondering why your common userid has modify access to your Oracle database? If you want to ensure no data is lost then if your userid had read-only access then this would solve your issue.

jakarman
Barite | Level 11

No matter what kind of users you have (power ones or normal ones), there are conventions to come to well behaved installations. ITIL Cobit ISO27k Sox-404 FDA and more are giving the high level goals (auditability traceability) for user actions data governance.  It is a "standard of good proactice" and that is not equal to do best practices.

To start:

- Each technical system (Oracle Unix SAS) should maintain all log actions and all users being identified being unique.

  With sensitive data (all that is not public) users should always use their own key.

Question:  why are you not doing that?  

Define in Oracle and Unix and SAS for every user their own unique identity for their normal work.

In that case an admin (high priviledged segregated from the normal key) can see what the are doing in each part of the service without any problem in the Oralce logs (oracle admin) or Unix logs (Unix admin) or SAS logs (sas metadata admin). Well trying to control the OS or Oracle by means of SAS metadata is a joke. SAS cannot control those things as there are far too many ways you can use the OS or Oracle without SAS.  The OS can live without SAS but SAS wil need always an OS. Oracle can always be accessed without SAS they are not needing each other.

DDL  DML DCL are common RDBMS to be covered What are the difference between DDL, DML and DCL commands? | Oracle FAQ

With RBAC you are organizing the security according HR-functions role. The technical implementation goes by using groups (all systems know that concept)

Adding a key in the technical groups will give you a consistent security approach. The difficulty can be defining those technical groups.  

---->-- ja karman --<-----
Reddy_GS
Calcite | Level 5

Thank you very much for  your valuble time.

Kurt_Bremser
Super User

10 power users using the same credentials with write/modify access? If my security officer caught me allowing that, I'd be out of the company in a New York minute and face a liability suit on top.

So get rid of that. YESTERDAY.

If you want to monitor everything that is done via a workspace server, you need to modify the logconfig.xml and the sasv9_usermods.cfg for that workspace server so that each session writes its own individual persistent log (sasv9_usermods.cfg) and that the log contains all actions (logconfig.xml)

Reddy_GS
Calcite | Level 5

i would really appreciate if you would let me what information do I need to type in logconfig.xml and sasv9_usermods.cfg.

Regards

Reddy

Kurt_Bremser
Super User

(As the SAS install user)

In your workspace server config directory, rename logconfig.xml to logconfig.xml.bak, and copy logconfig.trace.xml to logconfig.xml.

In logconfig.xml, change the fileNamePattern to something that suits you; in our case, the log files are written to a directory owned by root where a user has only write/execute (not read) permissions via her group; this means that the user can create and write the log, but can't find it so she cannot remove/alter it. Log files have date and process number in the file name to make them unique.

Also in logconfig.xml, change the level for the IOM protocol message logger from Error to Info.

No changes to sasv9_usermods.cfg are needed, unless you want to change the name/location for the logconfig.xml file (not recommeded)

Restart the Object Spawner (don't know if necessary, but won't hurt)

If you want to retrace which user made a certain change, you still will have to dig through all the logs of the given day, but at least now you have the logs. The default configuration saves nothing of import.

Be aware that with this configuration, the log directory may grow quite quickly, so make sure that logs are archived regularly or users may exceed their quotas.

jakarman
Barite | Level 11

Reddy.GS Your first step is:  get rid of those share accounts. You are needing Oracle logging and monitoring. SAS in not in control of that.

Your second step is:  Get your SAS environment configured and set up in a decent way (not the standard installation). Have your OS controls and monitoring organized

A step to do than is:  Adding logging monitoring to the SAS tool as middleware. The first steps are required as an foundation to build one.

For monitoring in SAS (not Oracle not the OS ) you have APM and event-manager. SAS Audit, Performance and Measurement package . The files (initial) and technical instruction are already on your system.  

It is not trivial SAS(R) 9.3 Logging: Configuration and Programming Reference as it is part of the SIEM concepts Security information and event management - Wikipedia, the free encyclopedia. Which are coming as part of business principles and governance often with high level standards (iso27k ITIL Cobit) by regulators (financial medical privacy).

The simple message: You can forget your challenge being solved by typing something in some config file.

Sorry for that bad news. It really should have been covered before starting an installation.

---->-- ja karman --<-----

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 9 replies
  • 3054 views
  • 2 likes
  • 5 in conversation