07-18-2013 02:38 PM
Hello Friends - we have SAS (9.1.3) server and SAS applications users are using on the server only, end users doesn't have SAS on their own machine. we have some scheduleds running on server,batch jobs, and we sued to send out data on weekly and monthly bases.
My question is - what are the things we need to consider, from administrative perspective, in order to operate the SAS server and applications?
07-18-2013 04:20 PM
a/ is this classic stand alone SAS what services are running or is it a Bi/DI server (metadataserver solutions based) environment
b/ What platfom OS is running. 1/ Windows 2/ Unix(an alikes) or 3/ Mainframe
c/ What are the requirements to meet when you are happy. Full OWASP ISTQB ISO2700- with encryption firewalls., medium level, or being open like a honey-pot. Are there LCM requirements involved?
07-18-2013 05:47 PM
We have Windows server 2003 (old one) with SAS EG 4.1. we do forecast here and send out data to SAP applications. We don't have any web application here and there are no LCM requirements involved. There are no many users so far...Lets say if I am talking in general then?
what kind of access should be there since users are using app on server itself? what could be the restriction for 'SASUSER' and 'PUBLIC'?
how to secure SAS plateform configuration?
how to identify where, how, and to whom metadata permissions are assigned?
what kind of metadata permission should be there to secure metadata
07-19-2013 04:03 AM
As you have no web-based SAS applications these just EG (AMO the same). You did not mention Olap, Miner (Analytics), Di, Information maps or others let us focus on that. For LCM Win2003, WinXP and SAS 9.1 will go into a unsupported state. As long it is working .....
The basics is SAS(R) 9.4 Intelligence Platform: Security Administration Guide (mediated access , host control layers). It is the same as at 9.1.
You will see the cation-note. In the PDF version it is easier to find them all as the indicating security holes.
This note is telling OS-laysers (Windows AD) are essential to be safe. That part should not be a problem to get well. Just remember:
- Eguide usage are sessions on the spawner started by the object spawner.
These are connecting by default to a WS server (part off App server context)
If you allow these sessions to be AD-user based (personal key, like a remote login) there is no problem ont that part.
- Stored process can be used in the same App-server context. They are running under dedicated key managed by you.
This part can require some attention. It is the similar like a windows "runas".
This is triggere by your batch remark, by maybe you are not using this .
SAS 9.4 is having the options of internal metadata user-users (by passing AD) and is having more metadata fucntionalitye and features.
The principals however are the same.
I assume you are using the "unrestricted admin" for normal metdata maintenance. In small environments this is quite acceptable.
This is one attention part of "hardening SAS". Knowing locations key/pswd are stored they they are by default "cut&paste usuable". With SAS is the intention to be able to read files, it is conflicting trying to prohibit that. The platform metadata configuration are host based files (Windows AD).
The key (sasadm) is indicated "unrestriced" as no metdata security is in effect. By that, nothing needed anymore.
Public / SASusers
The default "public" group you can set is nothing to grant (deny all). This is with sasusers set open immediate to do at the default act.
The default "sasusers" you would like to give just Read. This is acceptable when the users are not updating anything in metdata.
SAS(R) 9.4 Intelligence Platform: Security Administration Guide (see cautions). The read is necessary because not all in the metadata is covered, The strange issue: For many not covered objects the security is still enforced from the higher levels.
When for some reason a users is needing a metadata update somewhere the group "sasusers" will need have metadata write rights.
Not doing so can generate strange errors without giving a clue or an errormessage is misleading.
ACT (Access Control Templates) are a little bit strange concept. Let me try to explain.
In Windows you will set the rights on a object managed there immediate. Reuse of the same rights on other objects is not possible.
With ACT's SAS however you define the template and apply that to the objects. The reuse option is in this concept.
You will probably have a security concept at AD. Limiting access to business logic and business data. You can propogate that to that SAS metadata.
With that almost should be possible using ACT's without needing more special adjustments.
There is a paper on best practices. The sample is the SAS local office business, not your business. Another is that the segregation code/data (business) as very common is missing. That approach is involving more complications as trying it to solve that with DCE's.
You will need (by the effect of the needed SASusers group settings)
- a close all ACT to prohibit objects to users. As app-servers are opening up business data-access.
- a read only ACT to protect parts needing only read access to see map structure. (Strored process metadata definitions - menu-s etc)
- Logging is not well available at 9.1. Logserver etc is 9.3 and after
- There is a tool "metacoda" Metacoda | productivity through metadata visibility filling the gap (Paul Homes)
- If you would like auditors able to review metadatasecurity. Define a user/key for them give them (default act) generic Read access but exclude them for the app-server context (SP) of the business data.
The ACT's users, groups are metadatadefinitions. Not protecting them is giving the option they are changed uncontrolled not monitored.
There are many ways to change and maintain the metadata. SAS programs. .Net, java, a default tool is the SMC. IF you can trust your guys not knowing and using the other ways, you could try to hold them off using SMC.
The joke is a user can change his own rights to something he likes if nothing is done. That would give big buzzing and news when it was Oracle Microsoft or another common used well known tool. This part can also be secured (paul homes blog): platformadmin.com - Paul Homes blogging on SAS® platform administration topics "protecting your metadata proteections
07-19-2013 12:22 PM
Thank for your time Jaap Karman - this will help a lot!
i have also find one useful note here
07-23-2013 08:29 PM
These ones are quite old but they do relate specifically to SAS 9.1 and EG 4.1:
These ones are for more recent versions of SAS, although many of the underlying concepts are similar so you might gain some additional info from them too: