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.")
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!)
Read Diane Hatcher's paper: SAS 9.3 Administration Guilty Pleasures: A Few of My Favorite Things