It would be very useful if you could control (through Roles/Capabilities) who can submit libname statements and possibly to where (limitable to certain servers/locations/types etc.).
This will enable central management of data through Management Console and prevent proliferation of data.
I recommend checking out Metadata-Bound Libraries (SAS(R) 9.4 Guide to Metadata-Bound Libraries), which provide more robust protection to data. Ultimately, the physical data needs to be secured at the host layer.
One trick you can do to keep honest people honest is to create a statement-style macro called "libname", thereby overriding the LIBNAME statement. For example:
libname mstore "C:\SAS\Config\Lev1\SASApp\SASEnvironment\SASMacro";
options implmac mstored sasmstore=mstore;
%macro libname(p1, p2, p3, p4, p5, p6, p7, p8) /stmt store des="Disable Libname";
%put ERROR: Use of the Libname statement is not allowed;
Then, when users submit a LIBNAME statement they will get an error in the log with the message specified in the macro. This is definitely not secure, as users can redefine the macro (ex. "%macro libname; %mend;") to regain full access to the LIBNAME statement, but it would probably deter most. Enabling statement-style macros also has some performance overhead.
Finally, even if you could securely restrict execution of the LIBNAME statement, there are other ways to access data in SAS without using a library. For example, a user (with OS permissions) can directly read a data file as a binary stream and write it back out (DATA step, fopen, fget, fput, fwrite). Therefore, ultimately, any real data security must be put in place at the physical host operating system layer. I can understand the desire to limit the use of the LIBNAME statement, just pointing out it would not be a substitute for security.
Thanks for the response.
As you said, a macro just isn't robust enough.
I understand, and have used, metadata bound libraries before, and they goes some way to solving the issue.
Off the top of my head the issues to that are still:
- I can still just write a libname to the same location with a different name, thus ignoring the metadata.
- Assigning libraries as metadata-bound still (as of 9.3) requires that you specify permissions in the .cfg file because the assigning of meta properties doesn't work correctly. This may have been fixed in 9.4, I've yet to check.
Ignoring flat files (for the moment!) as let's face it people can do what they want with those, there is a still a requirement within Enterprise scenarios to prevent people setting up or connecting to data sources at random.
I understand that the security ultimately (unfortunately) has to be at the OS level, but a simple restriction on libnames, especially from GUI clients (EG specifically) would greatly reduce the complexities involved in setting up a well controlled data environment. It's not going to solve the whole problem, but at the moment the inability for admins to control what goes in and out of SAS, while great for analysts, is an administrative nightmare.
There is an upcoming LOCKDOWN feature (in the first maintenance release of SAS 9.4) that will probably get you much closer to what you desire. It will allow admins to place servers in a lockdown state (restricting access from within a SAS server process to the host operating environment) and specify ("white list") which files and directories a SAS session can access when in the lockdown state. In a lockdown state, users will only be able to submit LIBNAME statements to locations that have been "white listed". Executing LIBNAME statements to locations outside of the "white list" will be rejected.
Btw, you can't "back-door" Metadata-Bound libraries the way you can Metadata Libname Engine (MLE) libraries. A user can still submit a libname to the same physical location where a metadata-bound library is defined, but they won't be able to access the registered data this way, as it has been protected and requires metadata access and permission as part of registering the data in a metadata-bound library. Of course, users can still submit LIBNAME statements anywhere and access other data for which they have OS permissions.
Casey, I like your comment (seen it before) by that statement:
Of course, users can still submit LIBNAME statements anywhere and access other data for which they have OS permissions.
You could do:
- metadata-bound libraries, That is just SAS libraries not all other kind of data.
- Trying to implement OS security with a Lockdown feature in SAS.
- Trying to eliminated the OS usage by X-command. At the same time implementing a lot of OS accces in SAS language and still requiring X functionality by some of them and with some of the Solutions.
What this boils down is: Implement a good security model based on the OS level.
This is very good with Windows (AD) using a doain approach.
This is good with mainframes z/OS. But this platform looks to his end now.
This is missing with Linux/Unix.
- It is not really missing, but the approach as that diffferent you must be very experienced with Unix to get it.
- There are mostly guideline setup by Unix-security guys that missing the goals of using by: data-science, Analytics, BI
It would make more sense trying to solve this last issue as that is the root-cause.
Before doing that is must be recognized that there is a misperception at OS Unix security that it is the root cause.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.