Christine Vitron

12月 192017
 

In my last article, Managing SAS Configuration Directory Security, we stepped through the process for granting specific users more access without opening up access to everyone. One example addressed how to modify security for autoload. There are several other aspects of SAS Visual Analytics that can benefit from a similar security model.

You can maintain a secure environment while still providing one or more select users the ability to:

  • start and stop a SAS LASR Analytic Server.
  • load data to a SAS LASR Analytic Server.
  • import data to a SAS LASR Analytic Server.

Requirements for these types of users fall into two areas: metadata and operating system.

The metadata requirements are very well documented and include:

  • an individual metadata identity.
  • membership in appropriate groups (for example: Visual Analytics Data Administrators for SAS Visual Analytics suite level administration; Visual Data Builder Administrators for data preparation tasks; SAS Administrators for platform level administration).
  • access to certain metadata (refer to the SAS Visual Analytics 7.3: Administration Guide for metadata permission requirements).

Operating System Requirements

Users who need to import data, load data, or start a SAS LASR Analytic Server need the ability to authenticate to the SAS LASR Analytic Server host and write access to some specific locations.

If the SAS LASR Analytic Server is distributed users need:

If the compute tier (the machine where the SAS Workspace Server runs) is on Windows, users need the Log on as a batch job user right on the compute machine.

In addition, users need write access to the signature files directory, the path for the last action logs for the SAS LASR Analytic Server, and the PIDs directory in the monitoring path for the SAS LASR Analytic Server.

Signature Files

There are two types of signature files: server signature files and table signature files. Server signature files are created when a SAS LASR Analytic Server is started. Table signature files are created when a table is loaded into memory. The location of the signature files for a specific SAS LASR Analytic Server can be found on the Advanced properties of the SAS LASR Analytic Server in SAS Management Console.

SAS Configuration Directory Security for SAS Visual Analytics

On Linux, if your signature files are in /tmp you may want to consider relocating them to a different location.

Last Action Logs and the Monitoring Path

In the SAS Visual Analytics Administrator application, logs of interactive actions for a SAS LASR Analytic Server are written to the designated last action log path. The standard location is on the middle tier host in <SAS_CONFIG_ROOT>/Lev1/Applications/SASVisualAnalytics/VisualAnalyticsAdministrator/Monitoring/Logs. The va.lastActionLogPath property is specified in the SAS Visual Analytics suite level properties. You can access the SAS Visual Analytics suite level properties in SAS Management Console under the Configuration Manager: expand SAS Applicaiton Infrastructure, right-click on Visual Analytics 7.3 to open the properties and select the Advanced tab.

The va.monitoringPath property specifies the location of certain monitoring process ID files and logs. The standard location is on the compute tier in <SAS_CONFIG_ROOT>/Lev1/Applications/SASVisualAnalytics/VisualAnalyticsAdministrator/Monitoring/. This location includes two subdirectories: Logs and PIDs. You can override the default monitoring path by adding the va.monitoringPath extended attribute to the SAS LASR Analytic Server properties.

Host Account and Group

For activities like starting the SAS LASR Analytic Server you might want to use a dedicated account such as lasradm or assign the access to existing users. If you opt to create the lasradm account, you will need to also create the related metadata identity.

For group level security on Linux, it is recommended that you create a new group, for example sasusers, to reserve the broader access provided by the sas group to only platform level administrators. Be sure to include in the membership of this sasusers group any users who need to start the SAS LASR Analytic Server or that need to load or import data to the SAS LASR Analytic Server.

Since the last action log path, the monitoring path, and the autoload scripts location all fall under <SAS_CONFIG_ROOT>/Lev1/Applications/SASVisualAnalytics/VisualAnalyticsAdministrator, you can modify the ownership of this folder to get the right access pattern.

A similar pattern can also be applied to the back-end store location for the data provider library that supports reload-on-start.

Don’t forget to change the ownership of your signature files location too!

SAS Admin Notebook: Managing SAS Configuration Directory Security for SAS Visual Analytics was published on SAS Users.

11月 022017
 

Managing SAS Configuration Directory SecurityNeed to grant one or more users access to part of your secure SAS configuration directory? You can do it without opening up your SAS configuration directory to everyone.

Most SAS 9.4 Platform deployments on Unix have been done using the SAS Installer account known as sas. The sas account is the owner of the SAS configuration directory. Along with the sas account comes a sas group that out of the box is given generous access to the SAS configuration.

SAS Configuration Directory

The SAS configuration not only includes scripts like sas.servers but it also includes configuration files and logs. It generally includes a lot of control over the SAS environment. Despite locked down security of the SAS configuration on Unix out of the box, there are still valid situations when you need to grant one or more users access to part of the SAS configuration. For example, you might need to enable logging for the workspace server and need to grant write access to the workspace server Logs directory. Or maybe you’re setting up an account to be used for autoloading data into the Public LASR Server. There are many more such examples where you might need to grant one or more users access to part of the SAS configuration.

The sas Group

How do you grant someone access to part of the SAS configuration directory? Why not add the user in question to the sas group? While this may grant your user the access you want, it also introduces the potential for a lot of problems. Keep in mind that the sas group has (and needs) broad access to the SAS configuration. When adding a user to the sas group you are granting that user the same access as the sas group. If the user is administering your SAS environment, that might be okay. If that user is not going to administer your SAS environment, you’ve opened the door for someone to modify or delete any and all of your SAS configuration.

So, what should you do? The short answer is that you should only grant the access needed to the users who need it.

Modifying Security for Workspace Server Logging

Let’s look at the example of enabling the workspace server to produce logs. This is typically done if you need to collect logs for troubleshooting. By default, the workspace server runs under each individual user’s credentials; therefore, each workspace server user would need to be given access to create logs under the workspace server Logs directory. By default, the sas user and sas group are given read, write and execute permission on the workspace server Logs directory. All other users have no access to the workspace server Logs directory. This is a situation where granting all other users read, write and execute access while you need to generate workspace server logs is the recommendation.

Be aware that if logging is enabled for the workspace server, any user who does not have read, write and execute access to the workspace server’s Logs directory will not be able to launch a workspace server session.

The complete steps for enabling workspace server logging can be found in the SAS 9.4 Intelligence Platform: System Administration Guide.

Modifying Security for Autoload

In SAS Visual Analytics, the autoload feature allows periodic synchronization between files on disk and data in memory in a LASR server. The autoload feature for the Public LASR Server is mostly configured out of the box; however, there are a few steps required in order for autoload to be fully enabled. The final step is to schedule the job that will perform the autoload.

By default, the autoload directory for the Public LASR Server is in the SAS configuration directory. It is owned by the sas user and the sas group. The first step in the documentation for how to start autoload is to identify which account will be used to schedule the autoload script. The account you use needs access to both metadata and to the autoload configuration directory. The sas account has access to the autoload configuration directory by default but is not registered in metadata. The ideal answer is to find a balance between overloading an account like sas and not overcomplicating your environment. You could register the sas account in metadata but that would not be my preference. You could also provide metadata server connection information in the autoload script but storing a user id and password in a file is less than ideal. A better solution is the one presented in the Visual Analytics 7.3 – Recommended Post-Install Activities: create an account for the purpose of running autoload, for example, lasradm. The account needs to exist on the operating system (or other authentication provider being used) and in metadata. You would change the ownership of the autoload directory to the lasradm account and to a group other than sas. Creating an operating system group for all of your SAS users is a convenient way to grant permissions or rights to the group of users who will be using SAS. You can create a sasusers group, add lasradm as a member, and make sasusers the group owner of the autoload directory. Now you can schedule the autoload script as lasradm.

SAS Admin Notebook: Managing SAS Configuration Directory Security was published on SAS Users.