Continuous, rapid developments in technology are increasing the challenges faced by Identity and Access Management (IAM) teams. There are new security threats, new ways to access networks via devices, and issues caused by increased demands for productivity and efficiency. Not surprisingly, a recent survey of CISOs found “61 percent believe IAM is more difficult today than it was two years ago.”
One area of IAM, Authorization, is particularly crowded with a variety of solutions that grant or access to network resources using different criteria. Each type of Authorization method is offered by multiple vendors with a variety of options. As with the rest of IAM, innovation and new challenges have affected the market, leading to new products but also revealing problems in the way some good solutions have been implemented. In this blog, we focus on the latter, highlighting practices to avoid.One of the most common IAM mistakes is not properly defining attributes. Attributes are data about users: names, positions, locations, etc. Attributes or combinations of them are used in Attribute-Based Access Control (ABAC) solutions as the basis for granting access to resources (networks, apps, etc). For example, you might want to grant all service representatives the ability to see a customer’s balance but only give supervisors the right to change it. You could do this by defining an attribute called “position” and then configuring both “regular” and “supervisor” positions, complete with permissions. This sounds simple, but today many positions involve a variety of responsibilities, with people wearing multiple hats (think multiple ‘roles’), making it difficult to know which attributes to choose.
Speaking of roles, Role-Based Access Control (RBAC) suffers from the tendency of users to create too many similar roles, i.e., role explosion. RBAC involves creating roles, each with a permission set, and then assigning users to the roles. For example, a bank might create two positions: teller and supervisor with different permission sets and then assign employees to the relevant role. The ability to create many roles has a drawback in practice, however: sometimes, a company creates so many very specific roles that it is difficult to tell them apart easily, and even harder to keep track of them.
Role explosion also occurs if there is a separate role structure for each program or employee directory access; even if each has a small permission set, an employee may have several roles. Moreover, roles must be maintained manually, meaning any change consumes a great deal of time and company resources. Thus, role explosion can make a logical plan impossible to manage efficiently.
Both ABAC and RBAC solutions suffer from another problem: lack of visibility into Authorizations. Authorization is usually performed by scripts written in a computer language. Anyone not trained in programming will have a hard time reading these scripts and therefore cannot assess how well a solution actually meets the company’s Authorization needs.
A good policy is transparent enough that one can understand at a glance which groups of users will be granted access to a resource and which will be denied. An Authorization plan that lacks this level of visibility is problematic at best because it makes management dependent on the people who designed it, generally IT, for Authorization decisions. That’s despite the fact that access management impacts a business to such an extent that only company executives should be setting Authorization policies. Thus, a lack of visibility is not only inconvenient, but actually stops management from doing its job.
The fourth and final IAM mistake is choosing an Authorization company that doesn’t meet your organization’s requirements. These days, enterprise-sized businesses seldom design their own Authorization policy from scratch; they use an External Authorization Management (EAM) solution. In doing so, it’s important to avoid one that suffers from the problems discussed above. Moreover, you also don’t want a platform that is hard to modify or to test because it is likely your company’s needs will change over the next few years and it is certain that your business environment will. With the greater number of devices that legitimately need to access your network, you must ensure that your EAM supports all of them as well as working with any resources hosted on a public or private cloud.
Fortunately, there is a better answer: Policy-Based Access Control (PBAC).
PBAC enables management to create fine-grained Authorization policies based on run-time conditions, including time and location, rather than using static RBAC roles. For example, a business might want to give the same salespeople different access rights when they are in their office than when they are at a client site. By avoiding roles, PBAC also avoids role explosion. Moreover, PBAC gives a company complete control over Authorization administration, decision-making, and enforcement. PBAC is designed to handle all devices both on and off the cloud. It’s no wonder that PBAC has become the Authorization solution of choice.
