Friday, July 13, 2007

Successful RBAC

Gunnar Peterson responded to yesterday's RBAC post and I wish to make clear that I do not claim that he worships at the security altar. There are many reasons why an RBAC implementation will fail, just as there are many reasons why an ERP or CRM or any-other abbriviated/acronymed technological implementation will fail - and almost always it can be traced back to

1) the implementors don't understand the technology
2) they don't have buy-in up and down the line
3) they allow impossible goals to be set

Successfully implementing RBAC requires much more than simply gazing at the org chart. It does require an exercise in viewing the jobs/titles of the company and abstracting a core "role identity" but it also requires role mining - finding out what resources existing users have access to (and what rights and privileges they have regarding those resources). Analysis of people with similar access rights cross-referenced to those with similar job duties/requirements, and then going through a thorough rationalization/normalization process is absolutely necessary for an RBAC implementation to have a reasonable chance of success. It's necessary, but certainly not sufficient.

Using attributes as filters is, of course, an excellent way to introduce dynamic roles (or groups, if you're just getting started) and allows for an abstraction layer (the attribute really only needs to be intelligible to a machine or service) that should ease the pain of integrating acquisitions, re-orgs, multi-tasked employees, outsourcing and decentralization.

Comments: Post a Comment

© 2003-2006 The Virtual Quill, All Rights Reserved


[Powered by Blogger]