Allowing Approved Permissions to Restricted Data

Reply
Occasional Contributor
Posts: 18

Allowing Approved Permissions to Restricted Data

I am trying to figure out a way to allow a user to run certain "approved" Stored Processes that require access to SAS Datasets on a UNIX server that the user cannot access any other way.  In order to facilitate programmers being able to create and test these Stored Processes, it would be good to have limited or small sample access to the data for them (separate dataset? or prefiltered infomap? or infomap with associated stored process?).  I have am considering using a combination of information maps, stored processes, and maybe a dedicated SAS server.  Is there a way that I can restrict access to the information map, stored process, or server for users directly, but allow them to run a stored process that has been given permission (via a pooled server?)?

I am assuming that is a fairly common issue.  What are the best practices for dealing with this?

Valued Guide
Posts: 3,208

Re: Allowing Approved Permissions to Restricted Data

There are a lot of security papers at sas support. One very good one is:

http://support.sas.com/resources/papers/proceedings13/420-2013.pdf What SAS® Administrators Should Know About

I cite:

WHAT IS *NOT* SECURE

The only thing worse than a lack of security is a false sense of security. There are a couple of areas in SAS Enterprise Guide that might look or feel like security, but should not be relied upon for security. It is important to be aware of their limitations.

What is needed is:

- well defined ACT's that will manage the security in the metadata according the needs. Advice segregate code-like and data like definitions

- Access at Unix-level that will isolate the code and data parts in the same way

- At appserver contect a dedicated key for the SP-server (called it pooled it will be shared) so it will able to process code and able to update data

  The WS server (personal keys) limiting much more in access according the business requirements.

- A change process with promote/ship and test fall-back scenarios being part of all (DTAP) software lifecyclement.

By this giving fullfilment to CategorySmiley Tonguerinciple - OWASP. and Certifying Software Testers Worldwide - ISTQB® International Software Testing Qualifications Board for all the more technical requirements. A change proces ITIL (DTAP stages) to be added.

---->-- ja karman --<-----
Occasional Contributor
Posts: 18

Re: Allowing Approved Permissions to Restricted Data

Can anyone share any real life examples of data access designs that allowed users to access data through approved channels (infomaps, stored processes, etc.), but not directly?

Valued Guide
Posts: 3,208

Re: Allowing Approved Permissions to Restricted Data

Seen the name I assumed you knew already all of the real life implementation.  So I gave the generic backgrounds of the why.

It are desing iusses well metnioned:

-SAS(R) 9.4 Intelligence Platform: Security Administration Guide (About Access Management)   See cautions

- http://support.sas.com/resources/papers/proceedings12/297-2012.pdf (page 10,11,12)

As long as users have the necessary host operating system permissions, they will be able to directly access and read a SAS table. So, what this boils down to is that any real data security must be put in place at the physical host operating system layer.

And it is not only SAS tables but also all other type of data. Th SAS language has a lot of functionality of acessing files even without any for need for having the X-cmd. Expect many tools (eg Eminer) having instructions to use the OS directly in manuals.

The choice is trying to close down any option of programming doing anlytics and just use predefined programs or accept that SAS most valuable part is doing analytics.

With the first choice you need a waterfall programming staff in the way of a CICS mainframe program apporach.        

Accepting the analytics behavior of SAS will need well defined OS layers. You can find a sample of it as "diginote" a not really existing tool to be used in a business environment. When you want additional information (LCM SDLC DTAP) I could give that.   

The same security structure is easily be propagated to metadatasecurity. By this you will also get welle defined access through approved channels.

When a synchronisation proces is in place this can be imbedded in the expected existing RBAC processes in a business.

Having the SP-processes by different service accounts (maintained at general servers group) it will be a consistent approach.

It is cooperating and listening well to your clients and doing sufficient investigation on that.

---->-- ja karman --<-----
Occasional Contributor
Posts: 18

Re: Allowing Approved Permissions to Restricted Data

Thank you for your extensive responses.  I have been researching and experimenting with different ways to meet the requirements given me to restrict access to the detail data for our small group of SAS users.  Whether this is an appropriate goal is debatable.

I am still new at this, bur I have come up with the following proposed model to secure the micro data while still allowing that data to be aggregated by approved SAS stored processes:

Source SAS Datasets (secured):

     Permissions on UNIX folder containing SAS datasets: 700  o=storedprocess_id g=sas_users

     Permissions on Datasets: 700 o=storedprocess_id g=sas

Metadata Resources:

     SAS Stored Process Server: Only "Read Metadata" permission allowed for SAS groups who will be testing and using the stored processes.

     SAS Folders containing all objects: Only "Read Metadata" permission allowed to SAS groups and users who are not SAS Admins.

     SAS Stored Processes: Only "Read Metadata" permission allowed to SPECIFIC SAS groups or users who are not SAS Admins.  Underlying code is in a UNIX folder with permissions 750 0=storedprocess_id g=sas_users.  Underlying code file has permissions 740 o=storedprocess_id g=sas_users.  (Would there be a security benefit or problem with storing the code in the Metadata?)

     SAS Metadata Librarys: Only "Read Metadata" permission allowed to users who are not SAS Admins. (Not sure I need this if the library used by the SAS code bypasses the metadata.)

     SAS Metadata Tables: "Read Metadata" & "Read" permissions allowed to users who are not SAS Admins. (Also not sure I need this if the library used by the SAS code bypasses the metadata.)

The process would involve having directly accessible dummy SAS datasets that SAS programmers/developers could use for initial code debugging.  They would then create a Stored Process (run on the workspace server) to get the prompts and other information developed and tested.  This would be submitted to the SAS Admins who could oversee final testing and approval. Once approved, alter the library statements and location of the underlying code and place in a proper location for additional testing and then finally use.

Obviously, a lot of details are still undefined, but will this work as a basic model?  What flaws or vulnerabilities are there in this model that would defeat the initial goal of no direct access to the detailed data?

Occasional Contributor
Posts: 18

Re: Allowing Approved Permissions to Restricted Data

I did find one problem with this design.  We have allowed our SAS programmers to create SAS Stored Processes as necessary in the past.  Our policy is that they should use the workspace server for this purpose so that programs created will still enforce user and group specific access permissions.  However, with my design, if they choose to select the Stored Process server instead, they will be able to use the storedprocess_id to access the data and create any code they wanted to do that.

I have researched this some, and it appears that the Write Metadata permission for registering stored processes is at the application server level (SASApp), not the logical server level (SASApp Workspace Server, SASApp Stored Process Server, etc.).

Is there a way to allow a group of SAS users to register SAS Stored Processes on the Workspace Server, but not the Stored Process Server?

The only thing that I have been able to think of is to have a second application server (ex. SASApp-Secure) that SAS programmers do not have write metadata permissions to.  I could then use a different storedprocess_id for this server, or just remove the Stored Process Server from SASApp.

I will keep looking for more flaws, but please let me know if you see anything else specific that I am overlooking.

Valued Guide
Posts: 3,208

Re: Allowing Approved Permissions to Restricted Data

The good things what I see:

- You accepted the need for thinking about OS security and metadata security.

-  you have segregated the code (Sp) and data part (libnames/dataset)
These are the basics to get a working model.
To be added are the different requirements in the life cyclemanagement. What I mean is that:

-  in development (D business code/logic) a little different security set up is needed to have devloppers working efficiently.

- within a test (T business) environment it should already by strict conform the targeted production environment. For the sake of Agile development (progress efficiency) the life-cycle management of code could be left to the development team while being superviced by a SAS platform Admin.

- (business) Acceptance / Production should be strict secured being audited having change processes with all adminstrative and technical types of logging and monitoring.

This is a result when you are following those earlier mentioned guidelines, these are a result of mandatory ones. All the technical details is the challenging part as they are not mentioneds/described.

Working out, you will get something as: DTAP lcm scm - soll ist, templates  (part of my personal pages)
 

OS layer controls

The security design has been set up by "closed by default" approach. This is the save way.

You are using the Storedprocess_id as owner for the code and the data. By that updating.code is requiring update richts and data. And while runnig data it is possible code being changed. This is commonly not acceptable. The solution for that is using different keys for the data and code part.

Doing that you are needing to allow rights at the group definitions.
Needing groups for granting access to a business object.  That is nice because existing RBAC procedures are following that approach.

Unix and HFS security is a simpel but mostly not well understood. I can share the following:

Hacking Linux Exposed (part 1) and Hacking Linux Exposed (2) . The mind setting quirks
- The execute-bit rights at directories is for allowing cd (change directory). That is different with files (execute code)
- The gid-bit with directories is telling for new files to inherit the group from the directory, not from te creator.

- The sticky-bit with directories is telling just the owner of the file of the owner of the directory is allowed to delete files.

   You will find this also at Hadoop. Hadoop is based on Unix approach.

By that setting rights for directories can be 3770 or 2750. That are 4 digits, one more as often known 3.

Creating new files is also defining the security by the creator. There is no security admin role for that :smileyshocked:.
The umask setting of the user/key is defining the security rights of new files. Umask 077 will set up files with 700 access rights. 

SAS implementations are causing more confusing with Unix :smileyshocked:. It behaves at some points different as expected by Unix learning books. 
It is caused by sasauth (root-level), the fork processing spawning all the SAS sessions (yes the spawners).
It is the spawner keys attributes being used for all SAS spawned sessions not the key being defined of the users/servers by security admins.
If have seen that for: ulimits, umask and some more. And not only for SAS but also with other tools doing similar tricks.
This can be corrected in usermod-scripts of the related appserver definitions.  .../lev-/SASapp/...
The wanted umask settting being defined  there. Possible being different for differtent app-servers WS/SP servers. As the default/current location is also not set as expected, causing  possible problems, you can correct/set that also at that configuration point.

 

SAS Metadata layer controls

The security design has been set up by "open by default" approach. This is not a save way of design.

You have the requirement of the global ACT containing the rights all users allowing rm and wm (wmm).

What is needing is closing where possible and than reopening again. (described in bisecag)

With a folder structure and group approach as described for OS level it is solvable using just ACT's. By that all complexity off DCE's being bypassed.

By default every user is allowed to change his (and of others) the metadata security controls.
This is an additional security point.  

Do not be asthonised you need to grant rm and wm access to SP/WS servers for users.
The change of that SP/WS object is controlled by admin richts. wm is (possible) needed for updating statistic by users at associated metadata records.  The wm is controlling the metadata-object, not the underlying business-data.

  

PS

With this kind of security designing you should think and find the risks that are left open.
Expect: if you do not dot that, someone else will.

---->-- ja karman --<-----
Valued Guide
Posts: 3,208

Re: Allowing Approved Permissions to Restricted Data

In the desing I described the developers have a different metadata server (Lev_). Each level of the DTAP has his own metadata server and possible some more shadows as being segregations by machines..

By that there is a no issue on the SASApp server as they are already different implementations. There is no shared metadataserver.

This also fullfils the common requirement of devlopers not being allowed to have access to production, more specific no access to production data. They should normally be able to review the code.

You have mentioned just one flaw, There must be many more.

The root cause is the requirement of allowing all users wm/rm at the global ACT. It is the default open access approach.

Once upon a time I got into the requirement of allowing users to change their own rights. Do not laugh, that is very bad.     

---->-- ja karman --<-----
Occasional Contributor
Posts: 18

Re: Allowing Approved Permissions to Restricted Data

Thank you again for your response!

I have been reviewing your personal page (DTAP lcm scm - soll ist, templates  ) and it is opening my eyes to many of the industry best practices that are missing at my organization.  The evolution of our SAS usage is probably not unique, but definitely not ideal.

I am slightly embarrassed by the fact that I have never considered having multiple metadata servers.  To be fair, I have been looking for documentation on the reasons for this type of development, and other than your works, I have only found the steps for how you can actually make the new metadata server not when or why you would.

If I understand you correctly, by having a second metadata server, you can theoretically register the same resource (and path) with the same name but have different permissions for the resource.  Is this correct?  Also, you can register a different version (dummy data for development) of that same resource under that same name, and then simply copy the metadata to the production environment and alter references and permissions there.  Again, am I understanding this correctly?

With this situation, I would not need to create a new SAS application server, but rather use different permissions on two separate references (one per metadata server) to the same SAS application server?  Would you also use one object spawner for the entire development?

What are the pros and cons of this design compared to adding a second application server in a single metadata environment?

Also, for your information, we have a single UNIX machine that runs all of our "tiers" except for our client tier which is on Windows PCs.  This has functioned well enough for our small shop and we have no plans of new hardware in the near future.

Still in the early stages of understanding all of this, but I greatly appreciate your expert opinions.  Thanks!

Valued Guide
Posts: 3,208

Re: Allowing Approved Permissions to Restricted Data

The setup of multiple metdataservers is documented with the argument. "development, test, and production"

SAS(R) 9.3 Intelligence Platform: System Administration Guide, Second Edition (Port Numbering in a Multiple-Level Environment)

SAS(R) 9.4 Intelligence Platform: Installation and Configuration Guide (search for 8562)

Every level metdataserver objectspawner is getting its own ports. One objectspawner will do.

But remember all is copied at the level by having different port-numbers.  dev/tst/prod are segregated at that.

http://support.sas.com/resources/papers/proceedings13/475-2013.pdf  page 17 (af of design/concepts).

All what is kept in the metadata you can give the same names in the folders. Yes... 

- The naming of SASApp servers are logically the same, Yes....

- You could set up the same names of ACT's applying the security in the same way.  Yes.

- Defining the content users/groups at every ACT could be something needing a differentation. Different users/groups.

- Libnames can get the same long en short names (YEs..) . Only the physical connection should be different.

- Source code repositories should get the same name (Yes..)  the physical locations should be different

  (SAS metadata folder is the same) namings)     

By this export/import should do 90%-99% of the work getting from dev to test to prod.

There is a trick th have the physical names also kept the same in the SAS metadatadefinitions.

The use of the !  exclamation mark in a physical name will use there the environment variable (Unix Windows) By that is possible in teh user_mods config or script having the variation. Alle naming being equal in the metadata. 

The pro's of having several metdataservers are (adding a appserver is the mirror of it):

- you can isolate the users and usage. Does a developer something bad it easy to stop that without having any risk hurting the production.

- The logical names can kept the same. developers/users can communicate byt that.

At teh same time knowing it is fake data for developers.

- a fully chage process from dev to prod can be implemented as nothing is shared.

The con's

- initial more work    

---->-- ja karman --<-----
Occasional Contributor
Posts: 18

Re: Allowing Approved Permissions to Restricted Data

Can the different metadata servers specify a different pooled identity to run the stored process server as?  If not, then wouldn't I still need a separate stored process server?

If the production data is accessible by the stored process server pooled id, then I would have to restrict write access to that stored process server that uses that pooled id.  If I want my developers/testers to be able to create and debug the stored processes behavior (prompts, etc.) using dummy data, they will need write permission on their reference to the application server.  If the workspace server and stored process server are under the same application server, then I am back to my other problem where the developers and testers can write code that uses the stored process server, and therefore the stored process pooled id that has access to the production data.  It still seems to me that I would need a second application server definition with more restricted write access and a different pooled id to access the production data.

What am I misunderstanding?

Valued Guide
Posts: 3,208

Re: Allowing Approved Permissions to Restricted Data

Snlfam1, You are going fast seeing a lot of the holes. Seeing them is giving the option to mitigate.

- The WS-servers when run by the personal key (PA) will be no challenge

- The SP-server (and WS-pooled and ..) are running with a generic key. (NPA). You could this key indicate as having "high privileges".

By default sassrv is the key running everything for all SAS servers using a generic key. It is behaving something like a root-key.

That is a bad security approach indeed.

You can define every SP-server to use his own dedicated account.

SAS(R) 9.4 Intelligence Platform: Security Administration Guide (Metadata Groups) see the last note.

The logins of all servers like the SP are needed to be defined at the "general servers group".

During the configuration (defining metadata appservers) you can define them also.

As the goal of the SP would be accessing controlled the business dat you could set up a NPA for that

As the code (T,A,P) is possible needed to be verified not being changed you could set up a NPA for that.

The result is having 2 (code/data) *4 (d,t,a,p) NPA's serving the role as owner for files/directories.

In my approach for easy recognition I dit the classification/role (code/data  d/t/a/p) in the naming convention.

Hand over of the NPA serving the role for owner of the data for developers (sudo or direct) will give them the options and responsability isolated as a sandbox approach to their environment. They never can access other environments wiht that even it is the same machine.

Killing a SP process? let them is not a probem SAS will restart it automatically.

Hand over of the NPA serving the role for owner of the data for Production ... That should be monitored?

sudo Is a common way to solve it.  I did it this all with the key/pswd approach under "general servers".

Mentioned sudo. it is an option at the command line definition of the SP proces (SMC metadatabase definition appservers).

By that the object-spawner (that NPA) must get autorized to do those sudo's. The advantage is no keys/passwords in the metadata are needed for that. The disadvantage is being dependent of the sudo security admin.

---->-- ja karman --<-----
Ask a Question
Discussion stats
  • 11 replies
  • 612 views
  • 6 likes
  • 2 in conversation