Best Practices with SAS® 9 Metadata Security Presentation at SFANZ 2010

Thanks to everyone who attended my presentation at SFANZ last week, especially those who asked questions and provided feedback. If you would like a copy of the presentation, you can download it here in both PowerPoint and PDF formats. It should also be available from the SAS Forum Australia & New Zealand site too.

These are my notes that go with the slides …

Abstract

SAS9 metadata security is becoming increasingly more important as SAS9 platform installations continue to grow and evolve. With more content, larger user communities, and a wider variety of application interfaces, time-poor SAS platform administrators are looking for better ways to manage security with their organizations valuable metadata and data resources. Knowledge and use of current SAS9 metadata security best practices can be a key differentiator between stressed platform administrators and well organized administrators. One group might spend their time applying ad-hoc quick fixes, and tracking down authorization conflicts, whereas the other group will plan ahead to reduce day to day overheads and minimize the impact of change. This paper will provide an outline of some of the key SAS9 metadata security best practices together with information on where to go to find out more.

Slides 1 & 2 : Title / Agenda

I will start with a quick introduction, move onto practices that are more procedural in nature and then cover some of the major implementation practices. This is quite a large topic for the short space of time available and so I can only really scratch the surface. I hope that you decide to discover more about this topic, so I will finish up by pointing you at some resources where you can find more information, including my blog where I expand on some of these topics.

I’d like to start out with a quick intro to metadata security with a show of hands. Please raise your hands if you have used SAS Enterprise Guide to view the contents of a SAS table… Now raise your hands if you have every created or run a SAS stored process… Now those who have used SAS Data Integration Studio to create and run ETL jobs… How about those who have used SAS Management Console to manage servers… All of those tasks are based on things represented in SAS metadata and the ability for you to view and possibly update them is managed through metadata security and access controls. The SAS platform administrator is responsible for appropriately securing the metadata to meet business requirements. Managing access to metadata in an efficient manner is not always easy and that’s where knowledge of best practices can help.

Slide 3: Best Practices

Best practices can be thought of as collected wisdoms from the community. They are shared methods proven through experience to be more effective than others. They might be more robust, cost less to implement, take less time to manage, and be easier to change as requirements evolve. Given enough time most people will discover these methods for themselves. We make mistakes along the way and learn from them for next time. People often share these experiences and contribute to the knowledge of the community as a whole. If we can learn best practices from other people we can save ourselves time and effort.

Here are some of the things that can be avoided with knowledge of metadata security best practices:

An ad-hoc security implementation, triggered by individual email/phone requests, consisting of hundreds or thousands of per-user, per-object based access controls
A chaotic implementation with unpredictable or unexpected access controls (only unexpected from the administrator’s perspective – the metadata server will always make a consistent access decision but it may not be what the administrator expects due to a large number of ad-hoc, unexpected and conflicting access controls)
A metadata security implementation which is undocumented, practically undocumentable, or out-of-sync with the available documentation.
The significant effort that may be required to rationalize and consolidate an ad-hoc security implementation when business access rules change.

This presentation consists of a mixture of my own experiences as well as information I have picked up from others along the way. You will probably recognize some of these from your own discoveries too.

I will start with a few procedural practices…

Slide 4: Continuous Learning

To understand and implement best practices we need a solid understanding of the software. Just as the software we use evolves over time, so do best practices. They change to match changes in software, and also change as new or improved techniques are discovered. For example, best practices with SAS 9.2 differ somewhat from best practices with SAS 9.1.3. To keep up-to-date with best practices we need continuous learning by interacting with other people in the same field and sharing experiences. Here are some of the mechanisms by which we can stay up-to-date. They include SAS training courses, SAS certification, SAS documentation, conference papers, online communities as well as knowledge of additional 3rd party software such as Metacoda Security Plug-ins.

Slide 5: Concept Awareness (1): Identity Hierarchy

As a platform administrator, there are 3 key concepts that we need to know about in order to understand metadata security access controls, plan a security implementation and assess the impact of changes. The first of these is the identity hierarchy. You can think of this as a tree consisting of the user and the groups they are a member with multiple branches that represent nested group memberships. This hierarchy plays a key role in resolving access decision conflicts. Here we have an example of the identity hierarchy for a user as is shown by Metacoda Security Plug-ins.

I discuss this topic further in a separate Identity Hierarchy blog post.

Slide 6: Concept Awareness (2): Inheritance Paths

Another important concept is inheritance paths. Most metadata objects inherit their access controls from other objects. An understanding of inheritance paths helps us know where those inherited permissions are most likely to come from, and where any changes we make are likely to flow to. There have been some significant changes between SAS 9.1.3 and SAS 9.2.

With SAS 9.1.3 a number of objects had multiple inheritance paths where they inherited their access controls from multiple parents. Whilst this provided flexibility, it also caused some confusion as it was necessary to consistently secure all inheritance paths otherwise you could end up with situations where an object that was secured through one inheritance path was unsecured through another.

SAS 9.2 replaces this with a single inheritance model which is simpler to understand and easier to secure.

The SAS Management Console Inheritance tab, part of SAS 9.2 and available from SAS Institute as a plug-in for SAS 9.1.3, provides a mechanism for us to view the inheritance paths for an object.

I discuss this topic further in a separate Inheritance Paths blog post.

Slide 7: Concept Awareness (3): Access Decision Flow

The last major concept I will mention is the access decision flow. These are the rules the SAS metadata server follows to determine for a specific user, a specific object and a specific permission whether that user is granted or denied access.

The flow diagram shown here comes from the SAS® 9.2 Intelligence Platform Security Administration Guide, Chapter 5 Authorization Model in the section titled Authorization Decisions.

The layout of the diagram has changed from SAS 9.1.3 to SAS 9.2. Whilst it looks complex to start with, the rules are straightforward and memorable. It does not take long before you can make a determination yourself without having to refer to the diagram.

Some might say that with the new explore permissions tool in SAS 9.2 it is no longer necessary to understand this flow chart. I disagree because whilst the tool allows you to see the permissions for a specific situation, it is an understanding of the rules behind it that allows an administrator to think more generally and understand the ramifications and potential conflicts for any changes that she may make.

Slides 8 & 9: Plan Well

As with many things, time invested in planning upfront pays dividends later. Planning will help you develop an efficient security plan that meets your requirements. A clear idea of your goals will help you avoid an overly complex implementation that is hard to manage.

These are some of the things worth considering when you are planning your SAS metadata security implementation:

Collaborate with everyone who has a stake or may be able to help. As well as talking to the business about their security requirements, talk to the IT department too. They will know of any general security policies that you may need to be aware of.
Your IT department will also be able to help you integrate with enterprise directories such as Microsoft Active Directory or LDAP which will be a major time saver for you. Whilst it is not trivial to implement, enterprise directory integration is well worth the effort as it allows you to automatically synchronize your SAS metadata users and groups with existing users and groups in your enterprise directory and leave user and group management to your IT department.
Be prepared for the security requirements to evolve over time as the business itself changes with new projects, new teams, new data sources, new servers etc. You may also need to be ready for changes and new discoveries during your implementation. A good security plan will help you to make changes without requiring a significant effort.
Consider which groups of users will perform which job roles and identify the SAS software and features they will need access to. In SAS 9.1.3 this will help you with your security plan and software distribution requirements. In SAS 9.2 you will also be able to use this to plan your roles & capabilities to determine which SAS software features they will have access to, such as the ability within Enterprise Guide to save files to the local computer and the accessibility of the various plug-ins in SAS Management Console.
A well thought out tree folder structure that partitions content based on projects, organizational structure and/or job roles can significantly simplify your security plan and minimize ongoing maintenance.
Once you have your folder structure planned, you can determine how you should secure it.
Remember that you will also need to secure content, such as servers, groups and access controls that are not contained in folders.
When your plan is ready, document it, then implement it using your documentation.
Plan your testing too. It is easy to underestimate the amount of time required for sufficient testing, especially if security is important to your organization.

Slide 10: Develop a Security Plan

When developing your security plan consider what type of model you require and how complex it needs to be. You will want to keep it as simple as possible whilst still meeting access requirements. Try to avoid an overly complex plan.

You might have an “Open” security model if you organization doesn’t have any specific access requirements. In this model anyone can do almost anything given access to the appropriate software.

Moving on from this, smaller organizations, perhaps just starting out with SAS, might have a basic security model where their users are divided up into administrators who are also developers, a single group of authors and everyone else who are consumers.

Alternatively, larger organizations with more mature SAS installations may need a more complex security model. This might have multiple administrators, independent teams of developers, multiple groups of authors and multiple groups of consumers all with different access requirements. There may well also be a need for OLAP member level and BI row level security.

Now onto a few implementation best practices…

Slides 11 & 12: Prefer ACTs over ACEs

There are 2 ways of securing content in the SAS metadata repository.

The first is to use explicit permissions on individual objects – also known as Access Control Entries (or ACEs).

The second is to create re-usable packages of identities and associated permissions called Access Control Templates (or ACTs) and apply them wherever they are needed.

Whilst ACEs are very simple to apply, especially for a first-time administrator, it is best practice to use ACTs. This is because ACTs are much easier to manage and are change-friendly. When the time comes, as it always does, to change the rules you only have to change the definition of the ACT, and that change will flow through everywhere the ACT has been applied. If you secure with ACEs you will need to visit and change each one individually.

As an administrator one of my goals is to try to minimize ACEs, replacing them with appropriate ACTs where possible. This screenshot shows our ACE Reviewer software displaying a list of ACEs for me to target.

When minimizing ACEs, be aware that there are a number of ACEs that cannot, or should not, be removed. A number of SAS applications create and manage their own ACEs, and these ACEs should be left alone. Additionally, ACEs used for OLAP member level security, or BI row level security, cannot be replaced with ACTs.

Slide 13: Prefer Groups over Users

It is an industry standard best practice to secure content using groups rather than users. This is not specific to SAS software, but we follow the same principle when using SAS software. The user population, their location and roles within the organization, changes very regularly whereas groups are relatively static. Users change, they join and leave the organization, they move departments or get seconded, and they get sick or go on leave. Don’t be afraid of groups containing 1 user, you might only have 1 marketing director, but if she goes on extended leave and someone else takes over her role for a short while, you will be glad you created a Marketing Directors group.

One of our goals as administrators is to have a security plan where we can manage access on a day to day basis, not by changing access controls, but by adding and removing users from groups.

To keep on top of this best practice we can regularly look for access controls that refer to users and improve them by removing the users and replacing them with appropriate groups. This screenshot shows our ACT Reviewer software highlighting an ACT that contains a reference to a user.

Slide 14: Secure Folders over Objects

Another security best practice, that is not just specific to SAS software, is to secure groups of related content using folders rather than securing the individual items.

If you find yourself securing individual objects, then you may be creating a significant maintenance headache for yourself. Instead, think about whether the item can be moved either to an existing folder, with appropriate access controls, or to a new folder specifically created and secured for the new access requirements.

We can create hierarchies of folders that are aligned with our access requirements, whether they are project, organizational structure or job role based, or a hybrid. Then we take advantage of inheritance paths, where objects inherit their access controls from the folder they are contained in, and secure the high level folders with ACTs, leaving the individual objects alone to inherit permissions.

One of the improvements in SAS 9.2 that helps us with this practice is the WriteMemberMetadata permission. This permission allows us to grant access to modify the contents of folders without having to grant permission to modify the folder itself.

Slides 15 & 16: Wide Denials, Narrow Grants

For me, this practice is one that can help avoid significant headaches with permission denials and identity hierarchy conflicts through precedence mismatches.

This is best explained by an example…

A folder has been created to contain content that should only be visible to members of the Australia group and not members of the Asia/Pacific group. It has been secured to grant the ReadMetadata permission to Australia and deny it from Asia/Pacific.

But there is a problem with this…

Sam and Tara are both members of the Australia and Asia/Pacific groups but by different mechanisms:

Sam is a direct member of Australia and an indirect member of Asia/Pacific because the Australia group is a member of the Asia/Pacific group. Due to identity precedence rules Sam can see the folder.

Tara has been made a direct member of both groups when she should have been a direct member of the Australia group only. Due to identity precedence conflict rules Tara cannot see the folder even though she is in the Australia group.

With an understanding of identity hierarchies and the access decision flow, this makes sense and is easily corrected by removing Tara as a direct member of the Asia/Pacific group. However, in practice, these identity precedence mismatches can easily recur, and if we are using enterprise directory integration we may not be in direct control of the group memberships either.

A solution is to only ever deny permissions widely to the PUBLIC (or SASUSERS) group and then explicitly grant permissions narrowly back to those specific groups that require access. Because PUBLIC/SASUSERS are lowest in the identity hierarchy the potential for these identity precedence mismatches is practically eliminated.

Slide 17: Thorough Testing

After implementing your security plan it is good practice to test it thoroughly. This is especially important in a high security environment where it may also be a legal requirement. Testing will give you more confidence that there are no conflicts with unexpected grants or denials of permissions.

Test a variety of different classes of users: users who are not registered in metadata, users who are registered in metadata but not direct members of any groups. Test users with single and multiple group memberships looking for potential conflicts.

Test a variety of different actions such as open, update, rename, move and delete, to test a variety of different permissions.

One of the benefits we have as administrators is the ability to impersonate users. We can use our own credentials to log in as a specific user and test access as if we were them. Remember that this impersonation is only at the SAS metadata level and not at the operating system level.

I also like to set up a private administrator-only environment. I call it Lev9 and use it for disruptive or destructive testing that you would not want to do even in your development environment. It allows you to keep your developers happy too. Disruptive testing includes things like significant changes to high level access controls that could affect a significant number of users. Destructive testing allows you to test the ability or inability to delete important things like servers and high level folders without impacting other users.

Slide 18: Regular Reviews

Your security plan and its implementation will both evolve, and sometimes in different directions. If security is important for your organization then you will want to review your plan and its implementation regularly, update the plan to meet changing business requirements, and keep the implementation in line with the plan updating the documentation accordingly.

This screenshot shows some of the security implementation documentation that can be exported from our software. We have had a number of people approach us about this because they needed a mechanism whereby they could generate this documentation and publish it internally and regularly to prove that appropriate metadata security controls have been put in place.

Slide 19: Summary

That brings me to the end of the best practices part of my presentation. The key things I hope you will take away from this presentation are to keep learning, plan your implementation well, secure using ACTs rather than ACEs, groups rather than users, and folders rather than objects. Be careful with permission denials, test your implementation carefully and thoroughly, and review it regularly.

Slides 20 & 21: Resources (SAS 9.2) / (SAS 9.1.3)

If you would like to find out more about this topic, I have a couple of slides in the presentation with a list of resources that will help. I won’t go through the list here but you will find it in the online version of the presentation. There are resources for SAS 9.1.3 as well as resources for SAS 9.2. All of these links are also in a prior blog post and on my platformadmin.com blog Reading List.

Slide 22: About Metacoda

Just before I finish I would like to mention my company Metacoda. We are a SAS Alliance member that specializes in the development of software to integrate with SAS software with the goal of improving your productivity through enhanced metadata visibility. Many of the screenshots you have seen in this presentation were taken from our Metacoda Security Plug-ins product. If you would like to find out more then please visit our web site. We also have a flyer in your conference bag with more details.

Slide 23: Q&A

If you have any comments or questions please feel free to contact me using any of the mechanisms available here.

One thought on “Best Practices with SAS® 9 Metadata Security Presentation at SFANZ 2010”