Secure Library definition questions

[robm]

Hi People!

Just experimenting with securing individual SAS libraries forcing authentication via metadata servers and it seems fairly straight forward however

the thing that puzzles me and causes concern is when I am creating a "New Secured Library" it requires me to enter a password even though users will be authenticating via

ntlm/kerberos passwords using the metadata server.

method I am using

SAS(R) 9.4 Guide to Metadata-Bound Libraries, Second Edition

now the problem arises when i goto unbind and delete the metadata link ... the unbind works and its no longer secured however that password that was initially input see highlighted image above is still in there

which is ok if you can remember it this will remove it from each table (a little laborious if you have a bunch of tables)

proc datasets library=TEST2 nolist;

modify Stcd110_census_term_enrolment(pw=<password>/);

modify Stcr502_length_of_study(pw=<password>/);

modify Stir110u_fall_enrolment(pw=<password>/);

modify Stir110u_winter_enrolment(pw=<password>/);

modify Stir115u_summer_session_enrolmt(pw=<password>/);

run;

quit;

what I am looking for is why I need that password in there is there a way around it , or is there a way in management console to get rid of it at the same time so i don't end up with a forgotten password scenario

[jakarman]

IT may be looking straightforward but is a faking you. SAS(R) 9.4 Guide to Metadata-Bound Libraries, Second Edition Who Should Use Metadata-Bound Libraries?

"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 chapter of limitations is in front of that.
The answer why you are needing passwords is at SAS(R) 9.4 Guide to Metadata-Bound Libraries, Second Edition "Passwords for Metadata-Bound Data"
 
Every new tool is coming with his advantages and disadvantages. When you are not capable of managing security at the host level do not expect this will solve that. PEBKAC and GIGO are the "law of misery conservation". Ever thought of DR/BCM and big data analytics data-scientists accessing all data as they like?                                                                

[robm]

thanks Jaap!

we had read through "Who Should Use Metadata-Bound Libraries?" and understood that  our physical OS protection is solid (as it can be its on windows ) but the idea of making then secure is interesting in that the files cannot be easily taken off server and read via SAS or R or whatever (they are all sas7bdat) on a USB device thats why we were trying to do this.

However when I delete and unbind the libraries the original password is retained and when you try an access it from EG or SAS studio you are acctually prompted for the password which is great I guess it is still protecting your files ...but here is the issue if I protect a library (directory of sas7bdats) and 3 years later it is decided that the library no longer needs to be secure and I unbind it but have forgotten the password or it is lost from our password keypass then I have rendered it unreadable ?? is that not correct?

[LinusH]

The password is used for metadata maintenance only - not during queries.

If you are authorised to read the data you can still extract it to new table.

[jakarman]

Robm, The AES encryption is a good one as is the encryption with using a salt as read-password in the classic dataset. It is encryption at the data-level, when the file is physical copied it is still protected. To make it workable for the users that de-encryption should be made invisible for them. (NO POPUP)

When there are users having access to the data they must be able to read that.  Unless closing the business-needs (and business) that is a BCM requirement to deliver that. Having that data they can copy that to excel or whatever.  That is your challenge of security awareness having that not being happened. Yep Linus mentioned that too. You cannot block that option to persons having access. You should monitor their actions and keep the data at a save environment. Pushing them away with an unfriendly/unworkable system is counter effective.   It would better to offer those tools SAS and R they can do their work in safe way than the are get tempted/forced to organize that in a shadow-it unsafe way.

USB a problem? Block that access at the OS level with using closed desktops that are using disk-encryptions (os-level). Close the access to cloud storage (internet) and only allowing approved connections. (log and analyze logs) 

The deleting of the data is as easy as deleting those OS files. An more important question is able to restore that data as of  DR and common Backup/Restore requirements. You could have big problems to get those aligned with in house processes.      
 

[merrittr]

ok I think I am having a problem explaining my problem/question here it is again:

just testing this securing of libraries out and looking at all the advantages and disadvantages of them. os here is one scenario

I associate a library with the security via metadata server then at some point in the future the powers that be say "remove this security" I then hit delete and un-link this library from secured libraries

at this point that library requires me to enter that long forgotten password

how do i avoid this when doing an delete and unlink?

[jakarman]

Merritr I do not know how to recover that forgotten password. The same as you researching advantages/disadvantages.

I stopped with this as was being a lonely guy and not seeing any way to get this covered. More complicating as the results (PDF/HTML Excel) and code (sas) were needing the same kind of level of security requirements (same info).  

[Patrick]

Ignore below and read Linus answer to it instead. I leave the following text with incorrect statements as posted as Linus refers to it.

How I understand these metadata library bound SAS files work:

- On SAS file level nothing else than password protection is used as it exists already since long (PW data set option).

- Using a metadata bound library will allow you 1) that all files under this library will get password protection, 2) to store the password on metadata server level, 3) having SAS providing the password when accessing the SAS files (so the user doesn't need to know it).

On SAS file level old fashioned password protection is used: If you copy the SAS files to another location (not using SAS) you can still open them via SAS using the password (but now you need to know it).

You should also compress your SAS files as else you can still open them with an editor and lots of the stuff will be in there in clear text.

If you loose your password then, well, what's a password worth if there are other means to read the file without password. So hopefully you can't easily unprotect your files in such a case (you possibly would then contact SAS TechSupport and see if they have internal means to help you - but it certainly would mean you would have to provide your data to SAS).

[LinusH]

, I think you are missing a major point here.

It's called metadata-bound for a reason. Yes, you may be able to open a secured table in a different location, but metadata authorization will still be enforced. So a connection to the mother metadata server is required. Without this requirement, things like authorization on on object and row-level would be useless. Read my article

Compression are good in many situations. But for encryption? Why, when you got AES out of the box?

[Patrick]

Agree with you. Should have possibly verified what I'm writing before my post as it was based on some presentations I've seen when metadata bound libraries got newly introduced - and how I understood things work. So thanks for correcting my wrong statements.

[jakarman]

The compression or the encryption is needed as you could see all data accessing the file as an text file.

Linus the aes encryption is added with 9.4 and is not available with 9.3. It is a good argument to follow the latest releases and not getting to far behind. A major requirement for that is an IT implementation not too different from common IT government policies. Yep that is one I keep to state as that alignment is a root cause problem.

As the binding of the Sas dataset is made to a metadata ever.  That is giving the question on DR and BR requirements. Who what when where why with the how.

[merrittr]

Thanks guys i think we will look to using FS security first and see how that goes.