(source: http://technet.microsoft.com/en-us/library/dd298183.aspx)
Role-based access control, or RBAC, is a big deal in security management these days. It offers separation of duties, because the folks who put people into roles don’t control the permissions assigned to those roles. It offers better security reporting. Most importantly, it makes it easier to put access control in the hands of HR, management, and other people who should be deciding “who has access to what,” and taking that “gatekeeper” role out of IT’s hands – who never wanted it anyway.
Very small environments can sometimes implement a partial RBAC system by using Windows domain global groups to represent job tasks. That doesn’t mean a group for “accessing such-and-such files and folders,” because that isn’t a job task. A job task is, “updating customer data,” and the underlying permissions – which you’d assign to domain local groups – might include files, folders, databases, mailboxes, and who knows what else.
But groups don’t provide full RBAC, because groups are literally under the Full Control of Domain Admins, so there’s no separation of duties. And, the bigger an environment grows – especially as multiple domains and forests enter the picture – the less suitable groups are for implementing a true RBAC system.
Most organizations these days still put IT in the role of Permissions Gatekeeper. One must apply to IT to gain permissions to a resource, and IT often has some kind of process in place to verify that one is allowed to have those permissions. It’s an awkward process, to be sure, but one forced upon us by the Discretionary Access Control (DAC) model that’s been in Windows since its beginning – a model well-suited to the original departmental file servers that Windows powered, but a model growing increasingly less-suitable as Windows expands throughout the data center.
What’s your organization’s permissions model? Ask IT, IT asks someone else? Have you automated it? Do you use a true RBAC system on top of Windows permissions?
