My children learned this skill early in life: when you want to secure permission for a questionable activity (say, "watch 5 hours of Phineas and Ferb" or "eat a bowl of candy for breakfast"), you should approach the most lenient adult in the household. In my early days of fatherhood, that adult was me. Typical response: "Sure, I guess that's okay."
I soon learned my lesson and implemented a different protocol. "Hmm, I don't know about that. What does Mom say?" That typically shuts them down.
SAS administrators have struggled with a similar challenge. It's simple to use SAS Management Console to define SAS libraries and control which users can see/access those libraries. But even when you go to the trouble of "locking down" a library definition within the SAS Metadata Server, a resourceful programmer can usually figure out where the data physically resides and attempt to bypass your "metadata rules" by issuing a LIBNAME statement directly to the data source.
SAS admins know this as "the LIBNAME loophole". That's why we always caution against using metadata permissions as your sole security mechanism, and instead be sure to secure your data tables with file system permissions (or database permissions for DBMS sources).
Metadata-bound libraries change that dynamic. Beginning with SAS 9.3 Maintenance 2 you can define your data source as a "secure library" in SAS metadata, and bind metadata-based permissions to the library, its tables and columns, and even (with creative tricks) at the row level.
If an end user attempts to bypass the metadata layer by issuing a LIBNAME statement directly to the folder with the data sets, guess what? SAS recognizes that there is a security watermark on the tables and frustrates the attempt with the response, "Hmm, I don't know about that. Go ask the SAS Metadata Server."
If the user tries to access the tables via direct access in SAS Enterprise Guide, the response is the SAS equivalent of "talk to the hand".
Even using direct non-SAS methods, such as the SAS OLE DB Provider or the SAS Universal Viewer, will fail to grant access to would-be data peekers:
C:\Projects\metadatabound_hack.vbs(19, 1) : Data library or data set is bound to Metadata and cannot be accessed from this product.
(Note: metadata-bound libraries support only file-based SAS data sets and views -- BASE engine libraries. It does not extend to DBMS tables that you reach with SAS/ACCESS products.)
Defining a Secure Library
There are two ways for a SAS administrator to define a metadata-bound library. You can use the new AUTHLIB procedure or -- in SAS 9.4 -- you can use the Secured Library wizard in SAS Management Console. Here's an example AUTHLIB program:
/* Create the secured library */ libname bankdata "C:\DataSources\SecretData"; proc authlib library=bankdata; create securedfolder='/System/Secured Libraries' securedlibrary='Bank Data' pw='pass1'; run; |
Note that the password value in the syntax is not a security loophole or backdoor that can grant access to anyone who knows it. It's simply like a PIN for the administrator to later make changes to the contents of the secured library or its properties. Still, admins should guard the password and keep track of it.
The data tables appear in a special "Secured Libraries" folder within SAS Management Console. If you want the tables to also appear within a traditional SAS libref, you can define a library that points to the path with the standard "New Library" wizard in SAS Management Console. This will provide authorized SAS programmers and SAS Enterprise Guide users with data access for their queries, tasks, and programs.
Combining secured libraries with other admin features
Metadata-bound libraries can be used in combination with other powerful SAS administration features:
- In SAS 9.4, you can further protect your data "at rest" by encrypting the files.
- You can use system-wide auditing to record potential attempts at security bypass and other events.
It's enough to make a SAS administrator weep with joy. ("<sniff> - These metadata libraries are all grown up.")
Further Reading
See Paul Homes' excellent summary of how he tested the effectiveness of metadata-bound libraries from different versions of SAS. Good news: he wasn't able to "break in" without authorization. (Whew!)
See the official documentation at: SAS 9.4 Guide to Metadata-Bound Libraries. (Here's the 9.3m2 version of the book.)
Read Diane Hatcher's paper: SAS 9.3 Administration Guilty Pleasures: A Few of My Favorite Things
4 Comments
do not forget to read the manual on metadatabound libraries (RTFM).
As just the existence of a feature can be abused in design questions.
http://support.sas.com/documentation/cdl/en/seclibag/66930/HTML/default/viewer.htm#p0f9aq5vtdli0qn1tyv9ja703xeg.htm
Who Should Use Metadata-Bound Libraries?
As with any other security-related decision, a decision about whether to use metadata-bound libraries involves weighing the benefits of enhanced protection against increased administrative effort and complexity. This topic is intended to help you make a decision that is appropriate for your resources, environment, and security goals.
If all of the following circumstances exist, it makes sense to consider using metadata-bound libraries:
•You have SAS data sets that require a high level of security, with access distinctions at the user or group level.
•You are running (or planning to run) a SAS Metadata Server in which your users are registered.
•You have not already met your security requirements through a combination of physical layer (operating system) separation and customized configuration of your SAS servers.
The following prerequisite knowledge is essential for successful use of metadata-bound libraries:
•You have a basic understanding of the SAS metadata environment, including its authorization system.
•You know how to create folders and set permissions in SAS Management Console.
•You have read and understood at least the first two chapters of this document.
The following additional factors should be considered in a decision about whether to use metadata-bound libraries:
•If your metadata promotion strategy does not maintain a separate set of physical data for each deployment level (for example, development, test, and production), significant additional administrative complexity is involved (compared to using secured libraries against a single set of physical data).
•Recovering from actions that inadvertently disrupt coordination between the physical data and its corresponding metadata objects can be complex.
•Any batch processing against metadata-bound data requires that the metadata server is available and that the requesting user can connect to it.
Note: In working with metadata-bound libraries, it is also useful to know how to write and submit SAS code.
The introduction of children seeking the easiest way to achieve a goal is a good one.
Think like a possible hacker or person wanting to abuse critical information is the start of real information risk management.
Where are the reasoning about:
- the need and the implementation on backup/restore, retention policy and D/R
- the connection to using the often mandatory tools at OS level for backup (Eg TSM)
- What about all those people (admins or not) accessing the system with eg SSH?
How would it be that SAS is overruling the system OS (hardened) integrity?
Jaap, it is important to think critically about any data design/implementation where security is an important goal. Metadata-bound libraries offer one option -- another arrow in the quiver of the SAS admin. OS security and DBMS management are other options. And these can all be used together to achieve the ultimate goals of user service and data security.
Pingback: Fencing in your SAS users with LOCKDOWN - The SAS Dummy
Pingback: New superpowers for SAS administrators - SAS Users Groups