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.
Admin-key
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.
Securing
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.
Some addtions:
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)
Reviewing metdatasecurity.
- 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.
Securing Metadata
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
---->-- ja karman --<-----
Click image to register for webinar
