Control access for users scripts

[mvfelipelli]

Hi guys!

I hope you are all well and healthy!

What is the best way to limit user permissions when running "proc export" or libname for external sources to avoid data extraction? Would it be through the SAS Metadata Server? (Data Library Manager, User Manager, and others)

Thanks! 🙂

[SASKiwi]

Your question isn't clear. Typically you control users' access to data, not limiting what they are allowed to do with data. I would say it is problematic to limit what users can do with data they have permission to access. For example what would stop a SAS user opening a SAS table and manually copying it and pasting it into some other tool of their choice like Excel?

You would be better off limiting access to the data to just authorised users. And to do that fully you would need to use metadata-bound SAS libraries.

[Kurt_Bremser]

All you need to do to "extract data" is a PROC COPY to a different location. Or a DATA step with a FILE statement.

If you can't trust your users, don't let them work with SAS.

[jklaverstijn]

I 100% agree with @SASKiwi  that you should first and foremost lock up the data and not the tools to access them.

I also respectfully disagree with @Kurt_Bremser. A healthy dose of mistrust towards users is the start of any security initiative. Working for a government institution with highly sensitive data we make distrusting our users the foundation of every system design. But we do give them SAS as much as possible.

That said, I can imagine that you would even want to be careful with what users can do with the data they are privileged to access. Being allowed to run a a report does not mean one should be allowed to export the underlying data and send them off in an email. That's where SAS offers the LOCKDOWN option. Have a look at that. It may be just what yo need or be too much. That depends.

What we often do is to limit users to the use of VDI's . These virtual desktops do not have any networked connection to the outside world so exporting data and even copy/paste does not work. There are limits to what one can achieve but VDI's are very effective.

Hope this helps,

- Jan.

[Kurt_Bremser]

Nothing prevents a user from doing screenshots with a cellphone.

Hey, we've got tons of those right here on the communities from poor beginners who do that in their despair to satisfy their bosses' deadline.

I see all these "security" measures as delusions.

Nobody is more paranoid than the NSA, and they got Snowden.

[Sajid01]

Hello @mvfelipelli 
Here are my thoughts.

1.As stated by others restrict access to data

1.Restricting through metadata server. This can be bypassed.
2.Restricting access through  libname : This requires a read permission to the file if it is a sas dataset, excel spreadsheet etc. Deny read access.
If it is a database, do not give access to the user.
3.Proc export : This requires a write permission, Deny write access at the filesystem level. But a user will have Write access to SAS workspace and can always export there

[mvfelipelli]

Whereas there are many ways to extract data from SAS, for example:

SAS/ACCESS to PC Files
LIBNAME [file type] – excel, .txt. Csv, etc
LIBNAME PCFILES
PROC EXPORT DBMS=[file type]
ODS [file type]
PROC EXPORT DBMS=[file type]
ODS TAGSETS.CSV
DATA step, using FILE and PUT to create delimited files
ODS TAGSETS.EXCELXP
FILENAME DDE
SAS Add-In for Microsoft Office

And considering that every run goes through SAS Metadata Manager, would it be possible to contain the data extraction run?

There is sensitive data, strategic business data, as well as the issue of data viewing permission and access, according to the rules and permissions that the user is inserted.

We still have to consider the home office and ensure that this data is not downloaded and used inappropriately. VDI access takes care of some of this, for sure.

However, seeking to ensure that the user gets an error when running a PROC EXPORT would give the company a greater sense of security and compliance.

[Sajid01]

And considering that every run goes through SAS Metadata Manager, would it be possible to contain the data extraction run?
It is possible to by pass metadata manager. So this is not always true.

However, seeking to ensure that the user gets an error when running a PROC EXPORT would give the company a greater sense of security and compliance.

No.
It all depends upon the type of environment we are working with.

[mvfelipelli]

So does this mean that data security depends exclusively on the user?

Can the by pass in the Metadata manager be prevented by folder permissions in the OS?

[Sajid01]

Corporate security does not depend on the user, but on the environment / architecture.

It is difficult to give a specific solution to a general question but we can have general guidelines.
The SAS environment in small organizations are substantially different from those in large environments.

This question has an emphasis on preventing user from extracting or stealing company data.
Based on my experience I would suggest the following

1.At program development stage, developer's have access to either masked or mocked data.. There will be no access to PII data (personally identifiable information such as ssn, DOB etc) or actual data.
The data will have the same attributes as production data, but it will not be the same data.

2.Production run is through batch jobs and users don't have access to production servers; So no access to production data.
3.Code promotion is done per separate teams (application support etc)

4.I have come across teams, where vi editor is the preferred editor on Unix/Linux shell. . NO SAS EG or SAS Studio. Users can neither copy nor print the code let alone data.

5..Access is provided on need to know basis not  by virtue of position. ( Manager may not have access but developer  may have)

The list could be exhaustive. Depend upon what level of security is needed.

[mvfelipelli]

Perfectly said! I thank you very much!

Basically what has been brought to us is to implement a way to have more security of sensitive data and strategic data. Preventing the export of raw data by unauthorized users or those who have no explicit need to do so.

Avoiding actions like exporting all customer data to sell it.

The important thing would be:
1. Marcello can read the data, so read permission,
2. Marcello can export the data to a spreadsheet to work on that data, so export permission.

This is according to the user's level of responsibility, compliance, GDPR, or other law/regulation

[SASKiwi]

Your customer is asking for the impossible and needs to understand this. You need to get them to agree to terms and conditions that are possible. Yes you can make it difficult for an unauthorized user to export data, but the expert user will always have ways and means of getting around this. Unless the customer is prepared to accept the limitations of what is possible then you could end up being blamed for any security breach. BTW this isn't a SAS-specific issue, it is a general IT security one.

[Kurt_Bremser]

Think like this: how are your users intended to report their findings?

And then ask yourself how to prevent specific data from flowing through the same path.