BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
TomKari
Onyx | Level 15

Hi, all

 

I'm delving into metadata bound libraries, for an environment that must have very high security. I have a security question about the physical base tables in the library.

 

My understanding is this: When I create a metadata bound library, which includes some SAS datasets, the underlying data in the datasets isn't transformed. In other words, if I use O/S facilities to take a copy of the SAS dataset, and then use other tools to examine the bytes, the underlying variables will be there in clear text.

 

I'm hoping that someone can confirm or correct that understanding.

 

Second, my understanding from the SAS documentation is that I can use SAS facilities to encrypt the underlying SAS datasets, and the encryption key will be stored in the metadata server, resulting in seamless access for users with appropriate access authorization in metadata server.

 

It looks to me like, other than using secure erasure techniques when an underlying dataset must be deleted, that this will provide full protection against unuauthorized access to the data in the SAS datasets.

 

I'd appreciate it if someone with expertise in this subject could confim or correct my understanding.

 

Thank you so much!

   Tom

1 ACCEPTED SOLUTION

Accepted Solutions
angieh
SAS Employee
I've worked with multiple customers to implement metadata-bound libraries, primarily in cases where we used them to seamlessly encrypt SAS data at rest (where no file system layer encryption option was available).



If you setup metadata-bound libraries (MBLs), by default the underlying SAS data is NOT encrypted. You are simply password-protecting the physical SAS data. So MBLs do require a password at a minimum to implement. If you ALSO want to encrypt the physical data, then you would select the encryption option when creating the MBL. You can do this either via the SAS Management Console user interface, or (my preference) using Proc authlib code and specifying the "require_encryption" and "encrypt" options. In which case your code may look something like this:

libname secdata "c:\securedata";

proc authlib lib=secdata;

create securedlibrary="Secured Data Library"

securedfolder="Secured Data Folder"

pw=pass123

require_encryption=yes

encrypt=AES

encryptkey=key_value_can_be_up_to_64_characters;

run;

quit;



One thing to remember is that on UNIX systems, the directory owner must be the account used to create the MBL.



I hope that helps to clarify.

Regards,

Angie




View solution in original post

7 REPLIES 7
LinusH
Tourmaline | Level 20

Hi @TomKari

Perhaps I'm misunderstanding you, but it seems that your initial statement is somewhat incorrect.

Data sets in a meta bound library will be encrypted, using the key and algorithm of you choice. So, from a physical perspective, existing data set will be rewritten and encrypted. You will not be able to watch it and understand what it contains from other tools, or from a non authorized SAS user/session.

 

And yes, the access and authorization will appear as seamless to the user, as long the data reside in it's original place, and the user logs in to the metadeata server that has the metabound library registration.

 

Not sure about your last statement about deleting, perhaps you could rephrase/exemplify?

Data never sleeps
anja
SAS Employee

Good morning,

 

lets see of i can help with this ...

 

A metadata-bound Library is a physical library that is tied to a corresponding metadata object.

So when you create a metadata-bound library, SAS generates a new metadata object and binds

the physical library to that object.

A user must have permissions for whatever action is requested, and at the same time, the corresponding

OS id has to have the necessary permissions on the physical table.

 

If you'd copy data from a metadata-bound lib to another location on the OS, the security information on

that tables is still "active", meaning, the information is being copied with it. See

http://support.sas.com/documentation/cdl/en/seclibag/66930/HTML/default/viewer.htm#n14a0xp98mxlrgn1g...

 

As for encryption:

SAS encryption works for data in transit and data at rest. Data at rest means encryption for passwords of 

configuration files, metadata repositories, SAS code, SAS data sets, SAS HDAT in Hadoop and SAS

Performance Data Engine & Server (SPDE & SPDS) data.

Data in transit includes connections between SAS clients and SAS servers as well as browsers and  SAS servers.

It further includes encryption of data betweeen server to server, including  SAS servers or SAS servers and

Third Party servers.

The data sets in a metadata-bound libs are autmatically encrypted with the SAS proprietary encryption.

This encryption happens automatically with all data sets, whether bound to a lib or not. If AES is added as

stronger encryption key, it has to be added to the data in the metadata-bound lib.

 

I am not quite clear whether your mentioning of encryption is a question ?

 

Does that help?

Please let me know in case of any further questions.

 

Best

Anja

TomKari
Onyx | Level 15

Thank you both!

 

@LinusH

 

I'm understanding you to be saying that at the time of creation of a metadata-bound library, all of the SAS datasets in the library will be automatically encrypted, with no further action required on my part.

 

The last sentence simply applies to removing a SAS dataset. Regular O/S deletion doesn't overwrite the disk area, so the bytes in that area COULD potentially be subject to examination. A very far-fetched hypothetical, but for the best security I'd want to use one of the security agency-approved programs that overwrites the disk on dataset removal.

 

@anja

 

Yes, I agree that if I use O/S facilities to copy a metadata-bound library, the security info will still be active. This means I can't use SAS to see the data, but I can't see any reason why I can't use a third-party hex browser to examine the bytes.

 

I assume that your statement that "This encryption happens automatically with all data sets, whether bound to a lib or not." is only in the case where I've turned on encryption by default. I'm trying to figure out if I need to take any additional steps after creating a metadata-bound library to encrypt the SAS datasets in the library. I believe, based on LinusH's response, that I don't.

 

Thanks again to both of you for clarifying what I find to be a somewhat mysterious process.

   Tom

 

angieh
SAS Employee
I've worked with multiple customers to implement metadata-bound libraries, primarily in cases where we used them to seamlessly encrypt SAS data at rest (where no file system layer encryption option was available).



If you setup metadata-bound libraries (MBLs), by default the underlying SAS data is NOT encrypted. You are simply password-protecting the physical SAS data. So MBLs do require a password at a minimum to implement. If you ALSO want to encrypt the physical data, then you would select the encryption option when creating the MBL. You can do this either via the SAS Management Console user interface, or (my preference) using Proc authlib code and specifying the "require_encryption" and "encrypt" options. In which case your code may look something like this:

libname secdata "c:\securedata";

proc authlib lib=secdata;

create securedlibrary="Secured Data Library"

securedfolder="Secured Data Folder"

pw=pass123

require_encryption=yes

encrypt=AES

encryptkey=key_value_can_be_up_to_64_characters;

run;

quit;



One thing to remember is that on UNIX systems, the directory owner must be the account used to create the MBL.



I hope that helps to clarify.

Regards,

Angie




LinusH
Tourmaline | Level 20

About deletions: I never thought about this angle. But if you require this type of security, there are probably much else to secure prior to start thinking of this hypothetical scenario. Either way, any disk bits that may physically remain after file deletion will still be in encrypted, so if you feel that the existing encrypted data sets have the appropriate level of security, the deleted one are as well, with quite a margin.

Data never sleeps
TomKari
Onyx | Level 15

I agree, and I wasn't really worried about it, what brought it to my mind was a discussion in one of the SAS documents about how to change the encryption key if you suspect it has been disclosed. Only in this case would it be a concern; otherwise, as you say, the datasets are still encrypted.

 

Although, as the FBI Venona investigation showed, sometimes messages that have been secure for a decade or two can be cracked at a later time!

 

Tom

TomKari
Onyx | Level 15

Thank you all for the terrifically informative responses. This gives me everything I need.

 

One of those cases where I wish I could mark them all as solutions!

 

Tom

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 7 replies
  • 3738 views
  • 7 likes
  • 4 in conversation