Golden Rules for Security Model Design

8 Likes

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:

MichelleHomes · ‎07-13-2017

Rule 1 is one of my favourite #SASadmin tips and hearing @CecilyHoffritz say it in Danish is a bonus!!! https://twitter.com/HomesAtMetacoda/status/855305298524774400