In the final part of this series on Golden Rules for Metadata Security Model Design, we look at Rule 7: Apply ACTs to folders where possible, and Rule 8: Name security model objects clearly and simply.
If you missed the first four posts in this series, you should read part 1, part 2, part 3 and part 4 before this one.
I want to acknowledge the work of Johannes Jørgensen and Cecily Hoffritz of SAS Denmark, who published the first six of these eight Golden Rules in their paper ‘Metadata Security in SAS® 9.4 – Step-by-Step’. I have expanded on their work (adding two more rules, additional explanation, and much else besides) in an overall 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.
Where possible, apply ACTs to metadata folders, rather than to objects. Only where that is not possible because the object is not in a metadata folder, you may apply ACTs to an object directly.
For example, to secure a library, put the metadata library definition in a metadata folder, and apply the necessary ACTs to that folder.
As another example, if tables should have the same permissions as their parent library, put those tables in the same folder as the library. But where a table requires different permissions to its parent library, put it in another folder (e.g. a subfolder of the folder containing the library), and apply ACTs to that folder to set the required permissions for the table.
Some objects which must be secured are not in the metadata folder tree. In order to set permissions on those objects and prevent them from being modified by users who should not be able to modify them, it is necessary to apply ACTs to the objects directly. Examples object types for which this applies include ACTs themselves, Application Server Contexts such as SASApp and SASMeta, metadata server and logical server definitions, spawners etc. Several examples are given in the accompanying paper ‘Recommended SAS® 9.4 Security Model Design: Data Integration’ (available here) in section ‘9.1.1 Apply ACTs to the DI ACTs and to SASApp’.
Groups should be named to clearly indicate what they are.
ACTs should be named for the single group they feature, where possible.
Groups in an LDAP Provider such as Active Directory should be named in a way which satisfies the corporate naming convention for LDAP groups, while also indicating that the group is associated with a specific SAS deployment, tenant and or project. Good elements to include in the group name are:
In an organization with many SAS ecosystems, each having multiple tenants, and each tenant having multiple projects, the names of groups in Active Directory can be long and complex.
Dynamic groups (i.e. groups which are synchronized into SAS metadata from an LDAP service provider) should have names which match the name in that LDAP service provider as closely as possible. This is why in ‘Table 3 – Example group names in Active Directory (or another LDAP service)’ in the Core Principals and Practices paper (attached to my recent post here), the first column is titled ‘Example Active Directory Group Name , also name of corresponding dynamic group in SAS metadata’. Keeping the names the same or very similar same makes it easier for administrators to understand which groups correspond to each other later.
One element you may consider removing from group names as you synchronize them with SAS metadata is the part which identifies the deployment within the ecosystem (e.g. Dev, Test or Prod). If you choose to implement shadow groups (static groups which mirror your dynamic groups, see section 5.3.5 and Appendix B – Shadow Groups in the Core Principals and Practices paper, you can keep the deployment name element in the dynamic group name. If you will use dynamic groups directly in ACTs (more on this in sections 5.3.3 and 5.3.4 of that same paper), you should remove the ‘SAS deployment name’ (Dev/Test/Prod) element from the SAS metadata group name, so that your ACTs contain groups with the same name in each SAS deployment in your ecosystem.
If the corporate naming convention does not allow LDAP groups to be named in this manner, define the best names you are able to in the LDAP directory service, and create a lookup table and a step in your user and group synchronization program, to associate each dynamic group with its corresponding static group. That lookup table is then the reference defining which groups correspond to each other.
Static groups in SAS metadata (i.e. groups which are NOT synchronized from an LDAP service provider) should have names which omit most of the elements above, concentrating on the part of the group name which indicates what its members do in this specific SAS deployment, e.g. DI Developers, VA Report Designers etc. One SAS deployment does not usually need to have objects in it whose names reference other SAS deployments, or even hint that other SAS deployments may exist. For example, it is not necessary for DI Developers in a Development environment to be labeled “Dev DI Developers”; “DI Developers” is better.
I hope you have found these Golden Rules, and the reasoning behind them helpful in any security models you design. Please do let me know if you have any other ideas for practices that should always be followed with security model design. And releases of products on SAS Viya which include the General Authorization system begin to roll out, we will start seeing some real-world lessons learned for security model design in SAS Viya. Please do let me know of you see any interesting new trends emerging, that we can share with the wider community.
Until next time, thanks for reading!