You have probably met SAS Administrators who seem to style themselves after Mordac the Preventer.
You may have met more admins who are everyone's friend, and will let their 'trusted' users do anything on the platform. These folks are comfortable sharing (i.e. shirking) responsibility for the survival of their SAS platform with end users who don't have its stability as their primary concern, and may not be aware that there are inevitably many hard-to-locate ways to break something as complex as a SAS deployment.
In my opinion, the ideal - you guessed it - depends on the circumstances and the risks. But most SAS Administrators have tasks they would rather delegate, without granting ultimate power over the SAS platform to the people who deal with day to day content management.
This is where the role of content and/or data administrator comes in. For very little effort, creating one or more content or data administrator roles buys you a good deal of security.
When designing the job roles in a security model, someone - a SAS Platform Administrator - does need to have ultimate control over the platform, and the ability to do big, potentially-disruptive things like:
- Define, reorganise or delete users and groups
- Define or remove any group's (and user's) permissions to do things with any content and any data
- Modify server configuration - potentially breaking it or opening it up to misuse
- Define or delete definitions of logical/application servers
- Edit/move/delete any metadata/content, no matter whom it belongs to
- Disable the authorization system (!)
However, a number of users of the system may need permission to do less potentially-disruptive things such as:
- Move content between folders, e.g. to publish reports
- Promote content between SAS deployments/environments
- Deploy DI jobs
- Change permissions on content and folders in a limited part of the overall deployment
- Administer data (forgive me - I'm describing this in an overly simple way but it is a very well established topic)
There are countless other examples of tasks which are commonplace, and which we SAS administrators (small 'a', and this is especially relevant when working in a non-production deployment) tend to just do as 'sasadm' or equivalent because it's just easier and we're lazy efficient. I don't mean to belittle the importance of those tasks - they're vital. But you don't need full SAS administration rights to do them.
I'm relaxed about this laziness efficiency in a lab environment, throwaway classroom-use-only VM or similar.
But it's crazy to even consider giving more than one or two users in a real production environment (by which I mean one used for real work, having real consequences - this might include dev, test, staging environments etc.) the full power of SAS Administrator rights, and thereby the means to break your entire SAS deployment.
Everyone has an 'error rate'; we all make mistakes. SAS administration mistakes are more likely to be made by someone whose main job is not administering the SAS platform, someone who is not armed with a deep and complete knowledge of why it is configured the way it is. Fewer platform admins equals fewer mistakes with consequences which are hard to reverse. It also equals a more correct understanding of the current platform configuration for the person or people who DO manage it as their main job.
So, when anything of real value depends on a SAS deployment, and it cannot be recovered from a backup with trivial effort and trivial consequences, design your security model to include one or more groups/roles for users who need limited administration privileges, and do not make those groups members of the SAS Administrators group, directly or indirectly.
The aim is to enable your users to do their jobs, while not enabling them to put you out of yours.
In SAS 9, grant the content administrator group(s) limited permissions on selected folders such as Write Metadata (WM), Write Member Metadata (WMM), Manage Member Metadata (MMM) for groups or roles, Manage Credentials Metadata (MCM) for users and groups. SAS 9 data administrators may need such permissions as Write, Create, Delete, Insert, Update, Create Table, Drop Table, Alter Table, on folders (or libraries if you must).
In SAS Viya, grant your content administrator group(s) limited permissions on selected folders like Update, Delete, Secure, Add and Remove, and in CAS grant them LimitedPromote, Promote, AlterCaslib, AlterTable and/or other permissions as necessary to allow them to perform the tasks they need to perform. SAS Viya data administrators will need additional CAS permissions too.
You may also need to grant data administrators more permissions on the filesystem, or in external databases such as an RDBMS or Hadoop - by giving them access to different credentials in the relevant authentication domain.
But the main thing is: try not to put your content administrators or data administrators in the SAS Administrators group!
