Metadata bound libraries, is it worth the administrative overhead?

[MRSA]

I would like to understand if there's a good case for using metadata bound libraries in general and the following set-up in particular:

• SAS 9.4 on a Linux server
• Access to the server only through EG and SAS Studio
• No shell or XCMD access for users
• Data is primarily sorted on a database server, users will take cuts of data and store on SAS server for further analysis
• Users are organized in relatively large number of groups that work on one or more projects. Few users are in more than one group
• A group should not have access to other groups' SAS data and analysis output.

Without metadata bound libraries (MLB), (almost) all we have to do is

1. Provision users in SAS and on Linux
2. Provision Linux groups and populate with users
3. Create respective data and output folders on the Linux for each group with appropriate permissions

In this case, the users of each group can create folders to organize their data sets and results however they wish. Essentially the SAS server storage space is used similar to a file system with only file system security in place.

With MLB, the following needs to be done:

1. Provision users in SAS and on Linux
2. Provision Linux groups and populate with users
3. Create respective data and output folders on the Linux for each group with appropriate permissions
4. Create SAS groups and populate with users
5. Create SAS metadata folders and secure them based on the SAS groups
6. Create SAS Secured Libraries with encryption
7. Provision secured libraries to each group with appropriate permissions (create table, etc)
8. Create and assign libraries that correspond to the secured libraries
9. Do some magic with symbolic links so that users are not able to navigate the data folder, and not able to create sub-folders there, essentially preventing them to store data unencrypted
10. Monitor the output folders to make sure SAS data files are not stored there

In this case, users are not able to freely organize their data tables in folders, they only have a library to store their data. This means they have to adopt naming convention for their tables in the library and be extra careful not to overwrite each others tables. Essentially, the SAS server storage is used similar to a database schema. Administrators still need to monitor output folders to make sure data files are not stored there unencrypted. I understand the additional benefit of encryption at rest, but this seems to protect the data mainly from storage administrators. In case the SAS server is compromised, I don't think MLB provides any additional benefits as the encryption keys are maintained in metadata and someone who has come this far to gain access to the server, probably could figure out how to unencrypt the data as well.

Maybe I am missing the point of MLB. What do you think?

Thanks

[SASKiwi]

Is encryption of data at rest a requirement of your organisation's security policy or is there a business requirement you are satisfying by doing this? If there is no such requirement then I'd say the administration overhead of MBLs is not worth it.

In other words your need for MBLs should be driven by business requirements as the administration overhead is significant. BTW MBLs can only be accessed via SAS metadata and metadata-defined libraries so the chances of cracking the encryption independently are pretty slim.

[MRSA]

The business requirement is optimal security, i.e. the right balance of usability and security. Encryption at rest is not currently a mandatory requirement, but it may become one in the future. Even then, I don't see MLB fulfilling that requirement entirely, as we still have to watch other folders for unencrypted datasets. The set-up also has to be future proof and allow for easy integration with other SAS products and I am not sure if predefined libraries are needed for products like SAS VA (no experience with those). Some of our users are heavy SAS desktop users who are used to organizing data, scripts, and results for their projects in folders and MLB forces them to have data in libraries and obviously they don't like it.

[SASKiwi]

IMHO I'd wait until the requirement becomes mandatory, then implement it in your next SAS upgrade. BTW with MBLs users cannot independently store their SAS data in other locations as they can no longer assign LIBNAMEs in code - all LIBNAMEs have to be done in SAS Management Console and stored in SAS metadata.

[MRSA]

And I noticed I have been using MLB instead of MBL 🙂

[MRSA]

Thanks,
What would prevent the users to create a libref to a location that they have access to?

[Quentin]

I haven't explored this much but as a programmer, I don't like the idea of metadata bound libraries.  I feel like they shift the balance of power too far toward the administrators.

If you've got a bunch of experienced SAS programmers, they are used to writing their own libname statements to access SAS datasets (and relational databases, and flat files and .... )  For this group, centrally defined metadata libraries may be a nice convenience, but with a metadata bound library you say "the only way to read this SAS dataset is with a (the?) metadata library", that's annoying to me.  I want to write my own libname statements.

As you say, even with metadata security you still need OS-level security.  So metadata bound libraries don't save you from designing the OS-level security.

For the (smallish) group of folks working on our main server, we have a fairly basic metadata security model.  We have a metadata group for each project, and that determines who can see which metadata objects.  For most of the data sources (SAS datasets and databases), we rely on OS security.  I typically don't even define a data source as a metadata object unless I need to use it to define some other metadata object (e.g. stored process prompt).  Most of the SAS code that I write on our BI server would also run fine on PC SAS, because the code itself doesn't reference metadata objects.  It's worked well for me, and made it easier to move back and forth between PC SAS, and server SAS (mostly coding DI jobs and stored processes for web stuff).

I suppose if we had a more sophisticated metadata security model, then the idea of metadata bound libraries would be a benefit.  Because it would prevent people from circumventing our fancy metadata security.  And there are things you can do with metadata security (I think row-level and column-level access) which you can't do with OS security of a SAS dataset.  I definitely see value in metadata security layered on top of OS security.  But if you aren't relying much on metadata security, then I wouldn't think metadata bound libraries would offer much.

But I'm just a user with a biased perspective, not an admin.  Would be interested to hear the pro-MBL argument.  When I think metadata administration, my first thought is @MichelleHomesand @PaulHomes.  Perhaps they'll jump in.

[SASKiwi]

This would only be possible if the users had access to SAS Management Console and they had administrator rights to create data sources. As already mentioned if you create a MBL environment then you can't create SAS libraries in code using LIBNAME statements. 

[MRSA]

This works perfectly fine and stores data set in home folder of the user.
libname mylib base '~/';
data mylib.cars;
set SASHELP.cars;
proc freq data=mylib.cars;
run;

[SASKiwi]

Sorry, I was under the impression that you could enforce all of your permanent SAS libraries to be metadata-bound but after checking the documentation I don't think that is the case. You can have a mix of MBLs and non-MBLs in your SAS environment.

[ChrisHemedinger]

One of the main use cases for MBLs is to prevent unauthorized users from assigning a libname to a path they should not, and then getting access to data.  MBLs ensure that the user permissions are granted in metadata, despite permitted file system access.

In your scenario, if your Linux groups are enforcing proper access to the proper file system folders for the proper people, then there isn't a risk that a rogue user can assign a libname to a folder they aren't supposed to see...right?  So I don't think it buys you anything.  And your source database has its own security layer (assuming each user has their own credentials for access), so no need for an additional layer there.

And yes, the data in MBLs is encrypted to prevent snooping by those who would circumvent the metadata approach -- but the encryption might not conform to specific "at rest" encryption requirements you might have in your policies.  You would have to compare your policies -- if specific techniques are stated -- with the MBL documentation for admins.

[PaulHomes]

As others have already suggested, obviously you should only go to the effort to creating and maintaining additional protections that are proportionate to the sensitivity of the data and the risk of inappropriate access. If your content is already adequately protected, according to organisational requirements, then why add the complexity of SAS Metadata-Bound Libraries (MBLs)?

You may have already seen them but just in case, and for the benefit of others who may be following this thread, some good documentation references that discuss the appropriateness and benefits of MBLs include the following:

• SAS 9.4 Guide to Metadata-Bound Libraries
  • Who Should Use Metadata-Bound Libraries?
  • Permissions for Metadata-Bound Data
  • Providing Fine-Grained Access Using Condition Permissions
  • Providing Fine-Grained Access Using Views
    
    

To try to provide another perspective I will pose some questions/scenarios where MBLs can provide benefits. These may not apply to your situation but may help show some situations where MBLs can help. If these examples don't help directly then perhaps they might still explain why it can sometimes be useful to have the additional flexibility they can provide.

Securing content through multiple authorisation layers (that have both common and unique features) can be done for several reasons e.g.

1. defence-in-depth - redundant layers may provide protections when other layers fail due to accidental or deliberate changes
2. completeness/flexibility - taking advantage of features not available in preceding layers e.g. row/column level permissions
3. user experience consistency e.g. don't show users content they wouldn't have access to in preceding layers

A question I often see is why use metadata permissions (and perhaps MBLs) when operating system permissions can be used?

Leaving aside the defence-in-depth argument, sometimes it is not possible to rely purely on file system permissions. Consider SAS tables being accessed within the context of a SAS Stored Process Server, SAS Pooled Workspace Server, or SAS Workspace Server configured for SAS Token Authentication. The operating system identity is the same for all users - a service identity. In this case SAS metadata authorisation allows for finer level access controls than is possible with file system access controls. In this situation SAS metadata access controls allow you to control access for the requesting SAS identity (preferably through SAS metadata groups) where file system access controls cannot.

Why use metadata permissions when people can just use the libname-loophole (as it is often called)?

If you have configured SAS metadata access controls for SAS tables then there is the potential for SAS coders to bypass the metadata permissions by coding a base engine libname statement to get direct access to the data. If your file system access controls mirror your SAS metadata access controls then this may not be a concern, but if they need to be different, perhaps due to service identity use or row level permissions, then MBLs allow you to prevent this bypassed-access and enforce the additional use of the metadata authorisation layer.

How do I ensure row/column level permissions are enforced?

Some organisations have requirements to limit access to subsets of data based on filter conditions based on the requesting identity. In the past this has been done with SAS information maps over the tops of SAS tables but then you had to consider 1) people bypassing the information maps and going directly to the tables and 2) information maps were not as widely accessible as SAS tables. MBLs allow permission conditions to be applied at the SAS table level. This is as low as you can go since these types of access controls cannot be done at the file system level.

SAS tables in MBLs also have a wider range of metadata permission support than SAS tables in traditional libraries. Imagine you have a custom application requirement where users can add new data to a table but not modify or delete that data once added. By using a MBL and ensuring their effective permissions are +S, +I, -D, -U then you constrain them to view and add data but not delete or update it. If that person could gain file system access to the underlying table then adding encryption prevents them from copying the table to another location, modifying the data outside of the MBL and moving it back again.

Whilst I think that the responses so far have probably already answered the questions for your scenario, I hope this has helped add some general insight on where MBLs can be useful or even required.

[MRSA]

Thanks everyone for your comments.

@PaulHomes

You mention a really good point about different server contexts. In our implementation we have disabled the ability to use stored procedures due to security concerns, i.e. users being able to invoke stored procedures that run under the context of the service account and potentially gain access to data that they normally don't have access to. I think we should investigate more how MBL can prevent such scenarios.

Apart from that, we also see a potential benefit in MBL with regards to data management, which is reducing duplication and proliferation of data sets. The users may need same cut of data for various projects, and using MBLs, provides more visibility to what is already available which could lead to less storage consumption (premium storage is of course not cheap) and a bit more collaboration among them. However as @Quentin alluded to, we are sensing some resistance from the experienced SAS programmers.

All that said, the architecture of MBL is a bit flawed IMHO which despite adding extra layers of complexity, still allows for non-compliance. I see it as SAS base engine trying really hard to act like a RDBMs engine, but still carrying the legacy of a file based database system with itself.

[ronan]

Very interesting discussion, thanks for posting !

Per se, MBL cannot guarantee full security unless you also assign some security at filesystem level (POSIX or NTFS based, in practice). This means, as @PaulHomes said, that perhaps only when strong encryption at rest is required, MBL own requirements prove beneficial all things considered. 

This is why I'll recommend to balance MBL with another set of security tools, SAS Locked Down mode, which is very practical when security rules must be tightened without spending too much time upon security issues. This might be somewhat difficult to enable with SAS workspace sessions when the end users are used to create everything manually (which is not a good practice in general, tells me Mordac).

https://blogs.sas.com/content/sasdummy/2014/02/21/using-lockdown-sas94/

[SASKiwi]

If you combined LOCKDOWN with the locked down folders pointing only at  MBL enabled folders would that prevent users creating their own permanent SAS libraries outside of MBL?  I'm interested in understanding how they would work together..

BTW, enjoying this great discussion