12-30-2017 03:51 AM - edited 12-30-2017 04:01 AM
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:
Without metadata bound libraries (MLB), (almost) all we have to do is
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:
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?
01-04-2018 01:32 PM - edited 02-07-2018 11:24 AM
There has been a lot of good discussion on this topic thus far, but I've seen some possible confusion that I wanted to clarify. Metadata-bound libraries are a unique configuration that are different from libraries simply defined within the metadata. You can define libraries in the metadata for various types of data sources, such as SAS data sets or external database data. However, metadata-bound libraries (MBLs) are only applicable to SAS data sets and associated SAS indexes.
When you define a metadata-bound library, you run PROC AUTHLIB code to password-protect and physically bind all data sets in a defined path to metadata. With this approach, the data set password gets stored in metadata and you effectively lock down direct access to SAS data via a BASE engine libname statement and enforce metadata permissions for access to the SAS data. Users don't need to supply the password for data access, they instead just require a metadata aware SAS session and metadata permission to access the data.
If you want to encrypt the data at rest, then you would also use the REQUIRE_ENCRYPTION, ENCRYPT, and ENCRYPTKEY options on the PROC AUTHLIB statement to enforce encryption of the MBL data. See the SAS 9.4 Guide to Metadata-Bound Libraries for more information PROC AUTHLIB.
SAS Management Console has a user interface for defining MBLs, which effectively just generates and executes PROC AUTHLIB code behind the scenes. However, I typically like to write the code myself and run it outside of SAS Management Console just to clearly define and document the code options used.
As an FYI, I am a member of a SAS Consulting team that works with customers on architecture, administration, and security topics. In our experience, we have primarily only utilized Metadata-bound libraries for implementations which require encryption of SAS data. There is definite administration overhead in implementing MBLs, but they are the best way to seamlessly enforce encryption of SAS data. I always inform our customers that SAS data set encryption also requires defined user and administration processes in order to monitor and enforce the use of MBLs. Deepali Rai is another SAS consultant I work with and she will actually be presenting a SAS Global Forum 2018 paper on this topic based on best practices we have learned in wo.... Look for her in Denver in April!
12-30-2017 04:37 PM - edited 12-30-2017 06:08 PM
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.
12-30-2017 06:08 PM
12-30-2017 06:25 PM
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.
12-30-2017 07:34 PM
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.
12-30-2017 09:07 PM
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.
12-31-2017 11:47 PM
01-01-2018 03:12 AM
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.
01-01-2018 01:42 PM
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.
01-01-2018 05:54 PM
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:
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.
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.
01-01-2018 10:43 PM
Thanks everyone for your comments.
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.
01-02-2018 11:33 AM
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).
01-03-2018 02:20 PM
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
Need further help from the community? Please ask a new question.