Golden Rules for Security Model Design
Over my next few blog posts, I would like to propose a set of Golden Rules for Metadata Security Model Design.
These rules are fundamental to an overall SAS Global Enablement and Learning (GEL) Recommended SAS 9.4 Security Model Design approach, which I recently published in the SAS Community Library - here are part 1 and part 2. There are eight rules, and this time we'll cover the first two.
The first six golden rules closely follow golden rules developed by Johannes Jørgensen and Cecily Hoffritz of SAS Denmark, in their paper 'Metadata Security in SAS® 9.4 – Step-by-Step'. Some of the words in this blog post are taken directly from their paper - they are so well written I cannot improve on their explanation. I have however added or expanded the explanations for most of the rules I will describe in this series.
These golden rules are the core principles of GEL’s metadata security best practices.
These golden rules still allow you a great deal of freedom and creativity in designing your security model. Some rules make obvious sense. The value of other rules may appear debatable outside the context of the GEL Recommended SAS 9.4 Security Model Design series of papers. But in that context, they make good sense, and I will refer to supporting material where relevant.
There are two simple pre-requisites for understanding these rules properly:
- You need an understanding of SAS metadata security, especially how permissions are inherited
- You must know what the white, green and grey background colors mean in the Authorization tab in SAS Management Console
Rule 1: Only use ACTs, never ACEs
Detail
Secure resources using a combination of inheritance (tick marks with grey background) and Access Control Templates (ACTs, tick marks with green background).
In our recommended approach to metadata security design, it is absolutely strictly forbidden for you to use Access Control Entries (ACEs, tick marks with white background on resources).
Explanation
If you only apply ACTs and not ACEs, your job as an administrator will be easier because you can maintain all security changes centrally in the Authorization Manager Plugin of SAS Management Console.
Permitted exceptions
When SAS is deployed, some ACEs are already applied to certain objects by the SAS deployment wizard. Do not change these.
The security design behind row level security on information maps and cubes forces you to apply ACEs.
No other exceptions are permitted.
Rule 2: Only add groups to ACTs
Detail
Add groups to ACTs. Do not add users to ACTs.
We suggest you add only one group to each ACT and include the group name in the ACT name.
Take adequate precautions if you have groups which are synchronized from an external LDAP provider.
Explanation
It is much less effort to maintain your security model for groups rather than for individual users. If you only use groups in your ACTs, you can grant users the permissions they need by placing them in the appropriate groups. You can change a user’s permissions by changing the groups they belong to, far more easily than by removing that user from a number of ACTs (or worse, removing their ACEs if you can find them!) and then adding that user to new ACTs.
Avoid adding groups which are automatically synchronized into SAS Metadata from an LDAP provider, using something like the User Import Macros, unless you have taken adequate precautions to ensure that those groups are unlikely to be deleted inadvertently. See my previous blog post 'Shadow Groups for LDAP Synchronisation' for a discussion of shadow groups and why you may wish to use them, or some other method to protect your security model from inadvertent deletion of synchronized groups.
More next time, when I will present Rule 3, the most important rule of all.
You can find all the other posts in this series here:
