Security and BI Row-Level Permissions

Introduction

Like any other security feature, a secure implementation of BI row-level permissions requires that you pay careful attention to the entire environment in order to avoid vulnerabilities in other security layers. For example, if you do not limit physical access to the target data, there is a risk that users will exploit their physical access to circumvent the filters that you define in your information maps. If this is an acceptable risk, then no special measures are needed. This can be an acceptable risk in environments such as the following:

prototype environments
environments that do not have strict security requirements
environments in which a firewall separates untrusted users
environments in which untrusted users do not have the tools, knowledge, or operating system privileges to access files and metadata on the server tier

If, on the other hand, you require strict security controls against the possibility of malicious activity on your company intranet, then a more tightly protected configuration is necessary. In such circumstances, it is important to strictly limit physical access to the target tables to prevent direct access by regular users. The goal is to enable regular users to have only mediated access to the target tables. The strategy is as follows:

Deny regular users physical access to the tables (using host or DBMS access controls).
Require participating applications to use a dedicated, privileged account to fetch data for requesting users.
Configure the retrieving server and environment in a way that minimizes the risk of a user exploiting the privileged account, or otherwise circumventing the row-level filters.

The Initial Configuration

The initial configuration in a new deployment uses mediated access for BI row-level permissions. The server-side pooled workspace server is used for queries against relational information maps. The following figure depicts this mediation of physical access.

Example of Mediated Physical Access to Sensitive Data

In the initial configuration, mediation is achieved through server-side workspace server pooling. The server’s launch credential retrieves data for all requesting users. The server’s launch credential must have physical access to the data. End-users don’t need physical access to the data. This mediation, in combination with appropriate physical layer access controls, provides some separation, because it prevents users from directly accessing the data under their own credentials.

Incremental Measures for Increased Protection

There are several options for incrementally reducing the likelihood of inappropriate access. For example:

You can give the server-side pooled workspace server a unique launch credential, instead of allowing it to continue to share the stored process server’s launch credential.
You can create an additional server-side pooled workspace server in its own SAS application server, with a dedicated launch credential, and assign sensitive libraries to only that server.

Neither of these options provides comprehensive security, because it is possible for a sophisticated end user to exploit a server-side pooled workspace server and obtain direct (unfiltered) access to the data. For this reason, the secure environment uses a client-side pooled workspace server, instead of a server-side pooled workspace server.

About the Secure Environment

When to Use the Secure Environment

If you require comprehensive security for your BI row-level permissions, you must set up the secure configuration as described in the following topics. This configuration prevents regular users from circumventing row-level filters by accessing the target tables directly.

Overview of the Secure Environment

Here are the key points of the configuration:

You create a restricted client-side pooled workspace server that uses dedicated accounts for the pool administrator and the puddle login. This isolates the puddle account from applications that do not fully enforce row-level security.
You create an additional deployment instance of SAS Web Report Studio. The pool administrator account is known to only the new deployment instance of SAS Web Report Studio, so no other applications can use the pool (and, potentially, exploit the puddle login credential).

Note: In the secure configuration, the only supported client for presenting reports to end users is SAS Web Report Studio. The sensitive data is not available from other applications, such as SAS Enterprise Guide, because physical layer protections grant access to only the puddle account, which is known only to SAS Web Report Studio.

With the secure configuration, sensitive data is available only to designated end users (through SAS Web Report Studio, with row-level filters applied), and to trusted IT staff (through SAS Information Map Studio and through direct access).

Pre-Requisites for Setting Up the Secure Environment

Setting up the secure environment is an advanced task that requires the following preparation:

a separate, additional middle-tier machine to host the second deployment of SAS Web Report Studio (physical separation of the two deployments is necessary in order to avoid JVM port and context root conflicts)
the ability to create two new service accounts in the operating system
familiarity with SAS software installation and deployment, middle-tier administration, and metadata administration

To set up the secure environment, complete all of the tasks in the following topics.