Role Based Access Control: Why Groups Aren t Enough

Transcription

1 Role Based Access Control: Why Groups Aren t Enough Don Jones w w w. s c r i p t l o g i c. c o m / s m b I T

2 2012 ScriptLogic Corporation ALL RIGHTS RESERVED. ScriptLogic, the ScriptLogic logo and Point,Click,Done! are trademarks and registered trademarks of ScriptLogic Corporation in the United States of America and other countries. All other trademarks and registered trademarks are property of their respective owners. 2 Role Based Access Control: Why Groups Aren t Enough

3 One of the big phrases in security management these days is role-based access control, or RBAC. Its basic idea, which most people understand, is to assign users to roles that correspond to their job titles, which in theory correspond to what they do within the organization (if your organization uses pretty generic titles, then you ll have to come up with more specific and job-related roles, of course). You then assign permissions to those roles. By placing a user in a role, they pick up all of the permissions they need to do their job. Promotion? Move the user to their new role, and their permissions shift accordingly. To some folks, this sounds like the same security management pattern we ve been told to use for years. We put users into groups, and assign permissions to the groups. How is that not RBAC? RBAC isn t DAC Windows traditional security model what you see in Active Directory, on the file system, and so forth is called discretionary access control, or DAC. Under a DAC system which is also shared by many Unix/Linux systems as well as numerous applications permissions are assigned to low-level objects such as files and folders. RBAC systems ideally assign permissions to tasks. Reading and writing a file isn t actually a job task; updating customer data or creating a new customer record is a job task. Even our end-users have been trained, through many years of using DAC-based systems, to think of those tasks in operating system terms. They don t create a customer, they write to a SQL Server database. This is one reason why we have such a hard time really understanding RBAC: We re not used to thinking in terms of job tasks, we think in terms of operating system operations. (source: Figure 1 Discretionary Access Control 3 Role Based Access Control: Why Groups Aren t Enough

4 So at a high level, an RBAC system defines job roles, and then assigns permissions to job tasks to those roles. Get placed into a particular role (and it s likely a single human might fall under several, depending upon the organization), and you get permission to perform that task. Under the hood, an RBAC system running on Windows might well implement that permission assignment by making several changes to a variety of files, folders, databases, directory objects, and whatever else. After all, Windows is a DAC-based system, and so any implementation of RBAC would obviously include modifying access control lists (ACLs) at the end of the day. But that s an implementation detail that we, as humans, shouldn t have to deal with. Instinctively, you probably always know that. After all, what happens when a new guy joins the company? Give him the same permissions as the old guy. Great what permissions were those, exactly? We re told that because management can t keep track of all the specific permissions tweaks and nudges that are made to all of those files, folders, and so forth. Neither can we! On the other hand, in an RBAC system, management could be expected to communicate the job tasks the new guy would perform: He ll manage existing customers, and he ll also need the ability to review financials. In an RBAC system, we could do that and then (one that system was set up properly) let the system worry about the actual low-level permissions needed to make it happen. The Research Triangle Institute did a paper for the National Institute of Standards and Technology (NIST) in December 2010 analyzing the economic benefits of RBAC in a business environment ( It s a good read if you re not familiar with the specifics of RBAC models. At the end, the report found that firms with 10,000 employees would save about $24,000 per year (in 2009 dollars) by using RBAC instead of low-level Windows ACLs. That s a decent savings, and it s pretty easy to save that much by implementing an RBAC system. The number will actually be much higher in environments dealing with legislative or industry requirements like PCI DSS, HIPAA, GLB, SOX, and so forth, since those requirements create a much higher security workload in a DAC-based environment. Try telling me what resources Joe has access to in your environment, and you ll know what I mean! Getting RBAC in Windows Some bits of Windows do use RBAC. Exchange Server, for example while not technically part of Windows utilizes RBAC, in part because the underlying permissions are really, really complex to manage directly. SQL Server, through administrator-created custom database roles, also offers the ability to do RBAC. In many ways, a role is just a package of permissions. But in one important way, a role isn t just a convenient way of applying a bunch of low-level permissions at once. A role is only useful if it s packaged together a set of permissions that represent a job task. For example, SQL Server s built-in Database Reader database role isn t a true role in the RBAC sense, because read database isn t a job task. If you created a custom role named, Read customer information, then that might qualify as an RBAC-style role, because it represents a job task that an end user could describe to you, and it might require numerous under-the-hood permissions adjustments to make it happen. This isn t news to Microsoft, of course. Windows Server 2008, for example, supports a feature called Windows Authorization Manager (AzMan), a developer-centric feature that enables the creation of RBAC-based applications. This isn t something you can just slap on a file server, though; it s intended for newly-built applications, not the core operating system stuff. 4 Role Based Access Control: Why Groups Aren t Enough

5 In a really, really small environment, you probably can use Windows domain groups to create an RBAC solution. You ll follow the age-old method of assigning permissions to local groups, placing users in global groups, and placing global groups into local groups: The Account-Global-Domain Local-Permission model, or AGDLP, that s been tested on every Windows certification exam since time began. In RBAC terms, your domain global groups will represent job tasks so be sure to title them that way. Domain local groups will represent batches of permissions that each job task needs, thus making the connection between roles and the lower-level, object-based permissions. (By the way, this discussion focuses on Windows Server 2008 R2 and earlier; the announced Dynamic Access Control in Windows 8, which opens up some completely new, and much more RBAC-based, ways of working with permissions on files and folders, and eventually much more). The problem with larger organizations is that the business of managing groups and whatnot simply becomes burdensome, because you have so many. Also, keep in mind that domain global groups only work within a domain. If you have more than one domain containing resources, you ll have to back off a level to universal groups adding a whole new layer of management and complexity. Have multiple forests? Well, then you re probably out of luck managing groups across multiple forests, including all the trust-related stuff, just becomes too difficult. Another problem with using Windows groups is the lack of separation of duties. In a true RBAC system, one benefit you re supposed to get is that the people who put users into roles aren t the same people that assign permissions to the roles. In other words, an administrator might set up the roles and their permissions, since doing so is a pretty technically-challenging task. But they couldn t control the members of the role; that would be controlled by Human Resources or someone else, since putting people into job-related roles is understandable to that level of the organization. That means that HR (or whoever) and administrators provide a check to each other, and that a rogue administrator can t grant extra permissions to just one person. With Windows groups, on the other hand, administrators are literally in Full Control unless you make some very serious modifications to the default permissions of your domain and your servers. Okay so How Do You Get RBAC, Then? While groups will likely be used to implement RBAC, they themselves are not roles. That means, to get roles, you re going to have to add another layer of management, and that will usually involve some third-party solution. That solution might just be you writing scripts in PowerShell or something: If you create a database of available roles, track what users are in them, and keep track of which underlying groups enable a role s permissions, then you d end up with a home-grown RBAC solution. Creating that will require a lot of time and care and will probably be an ongoing project for the rest of your career. Once you have RBAC, you re also going to be asked for reporting, auditing, and lots of other features. Plenty of third parties play in this space, though, and many of them interface not only with files and folders, but also with Exchange, SQL Server, SharePoint, Active Directory, and other server-level solutions. That means dropping someone into a role could potentially offer them permissions across the entire environment, which is exactly what you want. You may wonder, okay, great. I m on board. How do I get all this set up? It sounds impossible. The initial creation of an RBAC system can, as you might imagine, be incredibly time-consuming. Once again, good tools can handle it. Setting up an RBAC system really requires little more than a careful inventory of existing permissions, and that s 5 Role Based Access Control: Why Groups Aren t Enough

6 not hard, it s just tedious and time-consuming. Tedious and time-consuming is what computers do best, if you ve got the right software to tell them how. With the right tools and they do exist you can inventory your environment s current permissions, and use that information to make a first pass at automatically constructing corresponding roles. Okay, I see that these 400 users have substantially the same permissions. I m creating a role for them, and attaching those permissions to that role. The result might not be perfect, but it will represent your current reality, and put you on a better footing to examining that reality and starting to make incremental changes to it. (source: Figure 2 What is RBAC? The real trick is in remembering, at all times, what RBAC is: A separation of duties. Whoever controls the underlying permissions shouldn t control role membership, and vice-versa. An organization-wide abstract. Regardless of how many domains, servers, and forests you might have, the RBAC system rides on top of all of it. Job-related. Roles represent job tasks or job titles, not lower-level operating system permissions. 6 Role Based Access Control: Why Groups Aren t Enough