By Sandeep Chopra.
If you are debating whether to upgrade to Windows Server 2012, plenty of articles describe its new security benefits (for example, see here and here). Fewer articles discuss the basic shift in Access Management this release can enable. To understand the potential benefits of one key feature, Dynamic Access Control, it’s useful to compare this approach with more well-known models of Access Management, such as ACLs and Security Groups. This blog is first in a series that compares how Access Management was handled in Windows environments prior to the 2012 release with what’s possible now.
Container-Based Controls: ACLs and Group Management
ACLs and Security Groups are currently the most ubiquitous model of Access Management. ACLs come standard in operating environments and many enterprise applications, and are familiar to both IT professionals and the common Windows user. ACLs are simply lists of users (Security Groups) with permissions applied to containers. While ACLs can also be applied to files, this is not a common solution for addressing broad authorization requirements. It’s not practical to manually apply permissions to (what might be) thousands of files. More typically, ACLs are applied to containers (folders) on file servers and network shares.
The ACL and Security Group model is both manual (with permissions defined per container, by an Administrator), and static (pre-determined and applied ahead of time). For reasons discussed below, this model can expect a lot of IT Administrators and end users. From the perspective of regulatory and compliance staff, this model does not always ensure accurate controls.
From the Perspective of IT Administrators
From an IT Administrator perspective, managing permissions and containers can become difficult. One reason is data tends to expand and organizations tend to have lots containers. Administering which Security Group(s) should have access to which containers quickly becomes complex and error-prone. The number of Security Groups that IT must manage also tends to grow, especially when authorization requirements are more complex. For example, the following graphic describes how many separate Security Groups must be maintained to apply controls to a growing list of containers, for a fairly simple authorization case. One problem is that, prior to Windows Server 2012, there was no support for conditional expressions or logical ANDs between Security Groups. This means it was necessary to create another set of Groups to express an intersection between groups (in first example below, a control that applies to both Project A Group and Secure Group).
For End Users
From an end user perspective, properly securing data on a file server requires you to know exactly which container to put it in. In this discretionary model, users have to be familiar with all the pertinent information storage and sharing policies, know which policies apply to the data under question, and know which designated container is the one to use.
For Compliance and Regulatory Staff
From the perspective of compliance and regulatory staff, another limitation with Security Groups and ACLs is the lack of precision. It’s not “containers” compliance people care about when they think about authorization requirements—it’s the characteristics of data that warrant a control in the first place. You cannot apply ACLs directly around these characteristics. The best you can do is express these characteristics in the name of the container (in the sample above, Project A, Secure).
There are several problems with this approach. While the value of the data might be captured by directory name, the actual value may be more specific, or there might be multiple values (or classifications) that apply to data. Plus, even when a container name accurately represents the value of data that is driving access control, that attribute is not applied at the file-level. If a file is moved to a different location, where the correct ACLs are not applied, protection on the file will be lost.
Container Based Controls in Your Authorization Toolkit
Access Management models are like tools in your toolkit—you should try to use the right tool for the job. In the past, IT organizations have been limited by what tools are available. Now that there are more choices, administrators should evaluate their requirements and decide which approach is the best option. The following guidelines apply to using ACLs and Security Groups.
The Right Tool When… Container-based controls that rely on Groups and ACLs can be the right tool for the job when the number of containers and groups required is small, when users can be expected to know which policies apply for data and can be trusted to comply with those policies, and when data-level controls are not necessary. ACLs can also be a good tool for deploying a baseline access control model, on top of which finer-grained controls may be layered.
The Wrong Tool When… Container-based controls alone are the wrong tool in environments where the numbers of containers and groups grow very large, when discretionary controls are not adequate, when controls must be applied outside a container, and when data-level controls are necessary.
—
Sandeep Chopra is the Director of Product Management at NextLabs. Sandeep’s extensive experience in Enterprise Information Risk Management includes work at Microsoft and Deloitte. In the past, he has created products, such as SharePoint, and delivered consulting services for Fortune 500 companies, enabling them to implement sustainable, risk-based data protection programs.