Posts
3 Pitfalls to Avoid with Role Based Access Control Projects
By Eric Rosenzweig
Implementing a Role Based Access Control (RBAC) solution into your business is a great way to improve the efficiency with which to provide appropriate access to employees. It’s also a terrific means to more accurately and effectively certify that employee access is, and remains, correct. However, with such a large, wide-reaching project, there are some pitfalls, which should not be overlooked or underestimated, because they can adversely affect the whole project. Here are 3 of those pitfalls to be mindful of:
1. Getting the Support of your Non-IT Business Partners
After all, this is a project to make their lives easier. Creating a high level steering committee from the business side to work with IT in designing the business process around the new functionality of RBAC can get them involved and truly feeling like this is their project, as well. In our current economy, project funding is often reviewed in order to determine what’s absolutely necessary. The business, which generally controls the overall IT budget allocations, is going to look more favorably on projects that they have a better understanding of, are involved with themselves, and that will reduce operational costs. Not having their support can lead to a budget cut, less resources, or worse yet, the termination of your project. Not to mention, having their support will definitely make roll out a much smoother transition.
2. Missing Access Data
Whether your business already has an identity and access management solution in place and is looking to improve upon it by moving to RBAC, or if your business is going in fresh using RBAC as its first attempt at automated access management, the solution will only be as good as the access data currently available. Systematically, a role can only be built around systems, applications, and their entitlements that are stored by you, that you have real time access to, or that are reported to you via scheduled file uploads.
Ideally, all of your organization’s data will be available at the start of your RBAC implementation. If not, be cautious to not overlook certain access requirements that a business area might have to perform a specific job function, and adjust the role creation accordingly. For instance, if a marketing assistant role is created, but it doesn’t have the entitlements to access all of the data required to perform that role, then this will create greater headaches by having the incomplete role out there. A marketing assistant would need to do something else, outside of being assigned a role membership, in order to perform the job. Therefore, it’s better to not create that marketing assistant role until it’s complete.
Confused on how to know if a role created from all of the current access data is complete? Well, that’s where pitfall number 3 comes in…
3. Avoiding Business Role Ownership
In order to validate that the roles created are complete, people need to get involved in the process that are actually familiar with the job functions to be performed by a user within a proposed role, and what the access requirements would be for that person. The best way for those people to be involved and to have them vouch for the integrity of the roles, is to make them a role owner. If the assignment of a role owner responsibility is avoided, or the value of their collaboration on the initial role creation overlooked, then there’s no possible way to ensure that the roles are 100% accurate, effective, and that they’ll stay that way over time.
The role owner stays in tune with the role, realizes when there needs to be a change in its configuration, and certifies that it’s still correct and purposeful to their business. A role can be created based on the info available then presented to the manager or potential role owner to verify that role will do the job for them. They should have the knowledge and familiarity to let you know if something is missing.
