Host Access to SAS Tables

Managing the Risks of Mediated Host Access

Direct Access versus Mediated Access

A SAS table (data set) is stored as a file in a host operating system. In general, a SAS table can be directly accessed and read by anyone who has the necessary host operating system permissions to that file. You can use the SAS metadata authorization layer to further constrain access. However, those additional constraints apply only when the user requests that data in a metadata-aware context.

As a simple example, assume that you have registered a library and several tables in the metadata. In SAS Management Console, you deny userA the ReadMetadata permission for a table named Salary. This prevents userA from seeing the Salary table in metadata-aware applications. However, if userA has host access to the physical file that contains the table data, userA can open that file in Base SAS and examine all of the data. When the table is accessed directly, the metadata layer denial of ReadMetadata permission isn't applied. In the following figure, the first image illustrates the issue and introduces the concept of mediated access.

Host Access to SAS Data

With mediated access, a workspace server or stored process server retrieves SAS data from the host operating system using a service account called a launch credential. The server uses one account to retrieve data on behalf of each requesting user. Mediation is an integral part of a standard configuration as follows:

Host access from the stored process server and the pooled workspace server is always mediated.
Host access from the standard workspace server is mediated if the server is configured to use SAS token authentication or if the server is providing client-side pooling.

Mediation offers the following advantages:

Mediation makes pooling of workspace servers possible. For Web applications, in particular SAS Web Report Studio, some form of pooling (client-side or server-side) is strongly recommended for performance reasons. Both forms of pooling always result in mediated host access to SAS data.
Mediation facilitates partial access to a SAS table through metadata-layer controls (for example, row-level or column-level access). Host-layer controls are at the file level. Such controls can grant or deny access to only an entire table.
Mediation helps you avoid creating end-user accounts on back-end servers that host SAS data.

CAUTION:

Along with its advantages, mediation introduces some risk.

If your deployment includes sensitive data in SAS tables, it is essential to review existing host-layer controls and to understand the effects of mediated access.

Managing the Risks of Mediated Host Access

The risks of mediated host access are as follows:

Someone might obtain the service account ID and password and use those credentials to directly access the data.
Someone might misuse the server in order to access data in a manner that circumvents metadata-layer controls.

The following table describes techniques for reducing risk. Keep in mind that there is no absolute security and that you must balance security goals against other considerations.

Alternatives for Reducing Mediation Risks

Modification	Risk Reduction	Notes
Use a different launch credential for each server. For example, configure the server-side pooled workspace server with its own dedicated launch credential.	Diversification reduces exposure for each launch credential.	Recommended if you have sensitive data in SAS tables.
Limit the availability of SAS Information Map Studio by installing that application only where it is needed.	Reduces opportunity to misuse that application.	Recommended if you have server-side pooling.
Limit the SAS folder locations from which relational information maps can be used.	Reduces opportunity to use a rogue information map, but affects only SAS Web Report Studio and SAS Web Report Viewer.	This measure is necessary as one part of making row-level permissions that are defined in information maps fully secure. See Limit the Availability of Relational Information Maps That Implement Row-Level Security in SAS Intelligence Platform: Web Application Administration Guide.
Set up client-side pooling using a protected, dedicated service account as the puddle login.	Reduces opportunity to misuse the server by creating a rogue application. A client-pooled workspace server can be used from only designated Web applications.
Delete the server-side pooled workspace server (and, for performance reasons, set up client-side pooling for SAS Web Report Studio).	Eliminates opportunity to misuse that server (in SAS Information Map Studio or in a rogue application).
Set up a restricted deployment of SAS Web Report Studio with client-side pooling.	Fully isolates the restricted client-side pool (with a dedicated pool administrator as well as a dedicated puddle login).	See Secure Environment for BI Row-Level Permissions in SAS Guide to BI Row-Level Permissions.

Example: Multiple Levels of Host Access

The preceding figure depicts a simple case where there is only one level of host access. You can establish multiple levels of host access by setting up multiple servers, each with its own launch credential. This can involve a trade off of granularity ("how many different levels of access will I establish?") against administrative effort ("how much server metadata will I create and manage?").

For example, the following instructions show how you can physically isolate sensitive data that is accessed through a logical workspace server that uses SAS token authentication.

In the operating system that hosts the SAS data:
1. Establish a separate file system directory for each level of access. This enables you to avoid setting host permissions on individual files. For example, to separate HR tables, you might create an HR directory.
2. Create or identify one service account for each level of access. For example, to provide physical protection for HR data, you might add an hrsrv account.
  
  Note: For servers on Windows, each launch account must have the Windows privilege Log on as a batch job.
3. Set operating system permissions so that each account has appropriate access to your SAS data. For example, deny the general use account (sassrv) physical access to the HR data and grant the HR account (hrsrv) physical access to all data (including the HR data).
  
  Note: If you want certain IT staff to be able to access the data directly using their own accounts, preserve that access.
In SAS Management Console's User Manager, select the SAS General Servers group, right-click, and select the Accounts tab. For each service account that you created in step 1, click New and enter the service account credentials as an additional login for the SAS General Servers group. Include a password in each of these logins. For example, you might enter the HR login as follows:
```
DefaultAuth | WIN\hrsrv | password
```
Note: Each of these logins will be directly associated with a particular server, instead of being looked up by authentication domain. For this reason, it doesn't matter which authentication domain you use. You can ignore any warnings about the SAS General Servers group having multiple logins in the same authentication domain.

Note: Users should not be members of the SAS General Servers group. This group is for service identities only. Users don't retrieve these credentials, so users shouldn't have access to these logins. In a standard configuration, these logins are available only to the privileged service identity (the SAS Trusted User) that the spawner uses to read all server metadata.
In Server Manager, select the logical workspace server , right-click, and select Properties. On the Options tab, verify that the Use server access security check box and the SAS token authentication radio button are selected. Click Cancel.
Select the logical workspace server again, right-click, and select Add Server. Set up one additional server for each level of access. All of the servers can use the same port. For example, you might add a server named Human Resources.
Beneath the logical workspace server, complete these steps for each server that you added:
1. Select the server, right-click, select Properties, and select the Options tab. In the Launch credentials drop-down list, select one of the service accounts (use a different account for each server). For example, for the Human Resources server, you would first select More logins and then search for and select the login that references the hrsrv account.
  
  Note: In order to see this login in the list, you need user administration capabilities.
2. On the Authorization tab, use the ReadMetadata permission to control who can use that server. Be sure to preserve necessary service access.
Under Server Manager, select the object spawner , right-click, and select Properties. On the object spawner's Servers tab, add the new servers to the Selected Servers list.
To make the changes take effect:
1. Expand the object spawner , right-click the computer , and select Connect.
2. Right-click the computer again and select Refresh Spawner. In the message box, click Yes.
3. Right-click the computer a third time and select Disconnect.
To validate, expand the logical workspace server and select a server . On each connection object in the display area, right-click and select Test Connection. Test the connections for every other sibling server that you added under the logical workspace server.

If you want to also enable power users to access data using their own accounts, set up a separate application server icon

for those users. In that application server, add a logical workspace server icon

that uses some form of host authentication. Even though regular users wouldn't be able to authenticate (because they wouldn't have host accounts for the workspace server machine), it is a good practice to limit ReadMetadata access to the additional application server.

You can use a similar approach to set up multiple levels of host access for a stored process server or a server-pooled workspace server. For multiple levels of host access from a client-pooled workspace server, set up multiple puddles. Always ensure that the server's host identity meets all of the requirements for a launch credential.

Host Access to SAS Tables

Direct Access versus Mediated Access

Managing the Risks of Mediated Host Access

Example: Multiple Levels of Host Access

See Also