A First Look at Auditing in the New SAS Viya

[#1]

This is the latest installment in a series of "first look" posts covering the new SAS Viya (2020.1 and beyond) functionality. In this post, we'll highlight what's new in auditing. As one might expect, a lot has changed in the way auditing is implemented in order to accomodate (among other things) the deployment of SAS Viya on Kuberenetes.

In Viya, auditing is process wherein REST activity generated by SAS services is intercepted, and used to create and store records about system events. These events are recorded for actions performed on resources (such as user-created SAS content) or security-related actions such as user logons. While this is no different to earlier versions, the way in which it is implemented has changed significantly.

What's new?

The Audit service has been revamped. It has been rewritten in Go, partly in order to better support the capture of events produced by other Go-based services in SAS Viya, but also to deliver a more efficient and flexible auditing framework. In fact, the whole auditing process flow, from event capture through to reporting and archiving of audit records, has been overhauled. The SAS Operations Infrastructure Framework is no longer around. Instead, the auditing functionality it provided has been replaced with a new framework based around the Audit service.

The diagram below provides a visual representation of the new process.

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

• Viya services produce events (information about REST activity), which are written to the application queue in RabbitMQ. This part essentially remains the same as it did in Viya 3.x.
• The Audit service picks up the messages from the queue, and writes them to tables in the AUDIT schema in PostgreSQL.
• The Audit service includes a task which runs every 2 hours to load new records from PostgreQL to CAS. Previously, this was handled by the genAudit task. Crucially, some more intelligence has been built in to this process, to reduce the likelihood of the load to CAS timing out. The new process is more efficient and appends only new records to the CAS table.
• The User Activity Report is provided out of the box, and is based on the loaded data (which is actually not loaded to memory until the report is opened).

Note that the User Activity Report is the only audit report available out of the box in SAS Viya. Obviously, customers are free to create additional customized reports to meet their auditing needs, but the other reports available in earlier versions are no longer included. This is simply a consequence of Viya's move to a containerized deployment. Reports to look at system resource consumption do not make sense, since Viya is deployed in a Kubernetes cluster. The cluster admin will use other tools to monitor and report on system resources. Inside the Viya deployment, auditing focuses solely on reporting on user activity (i.e. to understand system usage, or for investigative or compliance reasons). In addition to using the the User Activity report, the sas-viya CLI's audit plugin can also still be used to surface audit records.

The other point to note is that the frequency of the scheduled task is configurable, like many other aspects. As in earlier versions, properties defined configuration instances accessible from SAS Environment Manager control the behavior. There are three instances that relate to the Audit service:

• sas.audit.reporting: controls the reporting aspect of the auditing flow. For example, the properties here can be modified to change the frequency at which records are loaded to CAS, or to limit the applications from which to include audit records in the data set that is exported to CAS. One other useful new feature is the ability to exclude audit records generated by internal application accounts (e.g. records created by user "sas.audit" for internal processes).
• sas.audit.archive: controls what happens to historical audit records. For instance, how long to keep audit records in PostgreSQL and what to do with them after specified period has lapsed.
• sas.audit.record: this new instance provides an option to select the amount of data that is captured. Users can select from low, medium or high recording levels (or they can disable record creation altogether).
  
  
  Note that while previously recording levels could be set on a per application basis, it required a little bit of playing around to find the right application names and valid actions. Now, the slider simply controls the setting for all applications, and takes away the guesswork of specifying valid actions for which to capture records. Check out the SAS Viya Administration documentation for more information about setting the recording level.
  
  

Overall, the new auditing implementation is simpler, more flexible, more efficient, and better equipped to handle larger volumes of audit data. And more functionality is on the way. A new "activity" auditing function is in the works, which will allow for higher-level records to be created for user-centric actions. This would simplify the process of auditing user actions even further, with a single activity record representing an action such as a user opening a report. Stay tuned for more information.

Thanks for reading. I hope the information provided has been helpful. Please leave a comment below to ask questions or share your own experiences.

Note: This article addresses features of SAS Viya 2020.1 (and later)

[yuhong_tw]

Is it possible in current version or in the future release that the auditing implementation is able to record the IP address of end users?

As to my understanding, the field of remote address in the systemData.audit CAS table is to record the IP of the applications in Viya. 

[paterd2]

In 3.5 you have the ability to just audit read without using HIGH, reports.action.read.state=all.

Is this also possible in viya4 ?