By Sandeep Chopra.
In my previous post on access control in Windows Fileservers before Windows Server 2012, I argued that container-based authorization can be the right tool for the job when…
- Data-level controls are not necessary
- Discretionary policy enforcement is sufficient
- The number of containers and groups is small
In this post, I describe the set of tools available in Windows Server 2012, and the difference between these tools and traditional access management. The approach is referred to as Dynamic Access Control (DAC), and there’s actually good information out there already on DAC (for example, see this blog, where DAC is discussed from several different technical perspectives).
In a nutshell, the big deal with DAC is that Microsoft has introduced what’s referred to as Attribute Based Access Control (ABAC) natively into its operating system. While ABAC is a well-understood and documented approach for simplifying access management, up until recently ABAC had not yet been broadly available in commercial systems. (The most adopted ABAC implementation is the XACML standard developed by Oasis, described here).
The rest of this post describes Microsoft implementation of ABAC—focusing on what makes this approach so different from the container- and group-based approach.
Difference 1: From Groups to Attributes
In ABAC, access control decisions are structured around the attributes of users and resources.
Taking the example of users first: rather than managing access based only on user ID or group, access can be managed by other pertinent attributes—or a combination of attributes. Windows’ implementation of ABAC leverages user and device claims—which leads some to refer to this authorization model as “Claims Based Access Control,” or CBAC. However, this definition is somewhat inadequate, as DAC can leverage attributes other than claims.
The impact is that IT can create and administer far fewer Groups. You can still manage groups, and you can design controls around those groups. But you can also design controls that reference attributes in addition to group, such as citizenship, project team, clearance level, and so on. Previously, each of these attributes would have to be managed as a Group, and new groups would have to be created to express a combination of groups (for example, project team and clearance level).
Difference 2: From Containers to Classifications
As is discussed in the previous post, ACLs work by applying permissions to resources based on container. ABAC evaluates the attributes of resources themselves, which can even be applied to documents as metadata classifications. For this functionality, DAC leverages Microsoft’s File Classification Infrastructure (FCI), released in Windows Server 2008, which can automate classification using FCI rules. Metadata values can be managed as properties in Active Directory and referenced in DAC access control policies. In this model, users do not have to know which policies should apply to their data. Classifications are applied automatically, based on pre-defined rules. Then, policies reference those classifications to determine access control.
Plus, because these classifications are stored with the files themselves, for example as an Office file property, classifications can be persistent, meaning they can travel with files as they leave the file server. The persistence of file-level classification allows you to reference those classification in other third party authorization tools (for example, to apply controls to what users do at endpoints, in email, or even in enterprise applications, such as SharePoint).
ABAC File Classifications” width=”511″ height=”384″ />
Difference 3: From Permissions to Policies
Two other key differences have to do with how DAC policies work.
Firstly, DAC policies (which are called Central Access Rules (CARs)), are expression-based, and allow you to target user, device, and resource attributes with powerful precision. For example, you can create Boolean AND relationships between user and device claims to more easily capture the intersections between them. It is no longer necessary to express an intersection by creating an additional group.
Secondly, attributes are gathered and evaluated dynamically. This means that you can define relationships between attributes that are evaluated at run-time. For example, consider the following policy: “Allow access if the user is in groups US and Project A, if the user has the same security level as the resource, and the user is assigned to the project the file belongs to.”
Allow|Read, Write| if MemberOf(US) AND MemberOf(ProjectA)
(@user.security=@resource.security) AND (user.project=file.project)
This second difference is the fundamental innovation of ABAC: the distinction between pre-defining a static list of permissions ahead of time (which must be itemized to anticipate every scenario of access that needs to be controlled), versus writing rules that gather and evaluate attributes dynamically. In the dynamic policy described above, you do not need to list out all the security levels. Instead, you write a rule that specifies the user security attribute (whatever that is), must match the resource security attribute (whatever that is).
DAC in Your Authorization Toolkit
As I said last time, Access Management models are like tools in your toolkit—you should try to use the right tool for the job. Converting an entire infrastructure to DAC would be no small task—and I don’t think Microsoft is suggesting you do this. Rather, you should determine what subset of your data warrants this enhanced method of access control. But when is a subset of data a good candidate for DAC? Here are some guidelines:
DAC is the right tool when…
- Data-level controls are necessary, and might even need to persist after files leave the file server
- Discretionary policy enforcement is not sufficient: you need automated processes to classify files and apply access controls
- The number of attributes you care about is high, and/or, you need to target a cross-section of multiple user, device, and resource attributes
DAC may be the wrong tool when…
- Data-level controls are not necessary—controlling data based on the folder name where it is stored is sufficient.
- Discretionary policy enforcement is sufficient—users are capable of complying with information handling policies by storing data in the proper container.
- The number of containers and attributes you need to manage is small, and you do not have a common need to target a fine-grained cross-section of multiple user, device, and resource attributes
—
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.