Just in Time Access

Just in Time Access A More Secure Approach to

Special-Case Access Needs that Fall Outside of RBAC & ABAC Policies

Univers 55 RomanStandard IA Light Gray

CREATE

Align with top of letter or top of ribbon.

Depth is 2x width of “I”

Space between TM and logo is 1 x “I”

POSITION

“I”

1x “I”

2x width of “I”

Just in Time Access: A More Secure Approach to Special-Case Access Needs

2

Contents

PAGE

INTRODUCTION 3

RBAC AND ABAC – WHAT THEY DO & WHEN THEY’RE NEEDED 4

THE EXCEPTION TO THE ROLE 6

NEW ROLES ARE NOT ALWAYS THE ANSWER 7

A JUST-IN-TIME APPROACH TO EDGE USE ACCESS 11

ACCESS FOR EVERY SITUATION 13

THE PAM LINK TO JUST IN TIME ACCESS 14

A SOLUTION, JUST IN TIME 15


3

Introduction

Identity and Access Management (IAM) systems provide organizations with dynamic, wide-ranging methods for controlling access to their applications, systems, and proprietary resources. Perhaps the most widely known and commonly used methods—Role-Based and Attribute-Based Access Controls (RBAC and ABAC)—let organizations quickly defi ne fi lters or rules that determine access based on a user’s roles or attributes, respectively.

Both methods fi ll unique and important needs in granting and controlling access in many situations. But neither one is the complete, or even the most ideal, solution in every case—particularly when it comes to exception or edge use cases. Identity Automation thinks there is a better way to manage special-case access needs through the approach known as Just In Time (JIT) Access—providing provisional access to users when they request it and for only as long as they need it.

This eBook will explain the needs, motivations, and common use cases for the JIT Access approach. We will also highlight some of the shortcomings of RBAC- or ABAC-only models, and show how a fresh JIT approach can improve access management for users, as well as administrative and support teams, when and where it is needed—with less dedicated administrative and maintenance time, automated deprovisioning, and more robust system security.

There is a better way to manage special-case access needs: Just In Time (JIT) Access—providing provisional access to users when they request it and for only as long as they need it.

ATTRIBUTE-BASED ACCESS CONTROLS

ATTRIBUTES AUTHORIZATION ENGINE TARGET SYSTEMS

USERATTRIBUTES

INPUTS

POLICY

EXCEPTIONS

WORKFLOWS

EMAIL

CRM

HR SYSTEMS

SERVICE MANAGEMENT

VPN

DIRECTORIES

OUTPUTS

VPN

ORGANIZATIONALATTRIBUTES

DERIVEDATTRIBUTES

GEOGRAPHICALATTRIBUTES


4

RBAC and ABAC – What They Do & When They’re Needed

Most IAM products provide various methods for controlling access to organizational resources, but two of the most widely used are Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC). Each one has its merits and benefi ts for managing access rights in specifi c situations.

RBAC controls access based on 1) the roles that users have within the system, and 2) rules stating what access is allowed for users in a given role. Most IAM solutions defi ne a role as a local grouping of one or more users in the directory system that share common affi liations, such as the same department, physical location, or user type.

Consider, for example, a user with a position as clerk in an organization’s Accounts Payable (AP) department. With RBAC, this user would automatically get added as a member to the AP Role, granting him or her access to AP functions in the accounting system.

ABAC, by contrast, enables fi ne-grained access control, which allows for more input variables into an access control decision. Any available attribute in the directory can be used by itself or in combination with others to defi ne the right fi lter for controlling resource access.

ABAC is more fl exible than RBAC and can control access based on three different attribute types: user attributes, attributes associated with the application or system to be accessed, and current environmental conditions.

An example of ABAC would be allowing only those users who are Type = “Employees” and have Department = “HR” to access the HR/Payroll system, and only at Location = “Corporate Offi ce.”

Each of these control methods plays an important and unique role in an organization’s access management and provisioning framework. When making access control decisions with broad strokes, for example, giving all teachers in a school system access to Google or all contractors a company email account, RBAC is the preferred method. But when access is required at a fi ner level of detail or granularity, such as giving Google access to only those teachers who teach Grade 5 at a certain school, ABAC should be used.

RBAC and ABAC are dynamic control tools for user access requirements on a large scale.


5

RBAC and ABAC are dynamic control tools for user access requirements on a large scale. For example, a new employee joining the IT department in a company’s Houston offi ce would be assigned the “Houston offi ce” role and the “IT” role, which grants them access to specifi c systems and applications when their account is fi rst created. This role assignment and access is done dynamically, based on the RBAC and ABAC confi gurations set up in the company’s IAM system. And if the user should change offi ce locations or move into a new role or department, the RBAC and ABAC controls would automatically update the roles and access accordingly.


6

The Exception to the Role

One might naturally ask that if RBAC and ABAC are such powerful tools, why does an organization need to use anything else? While it’s true that RBAC and ABAC cover the majority of a given user’s access needs, neither method is ideally suited for every use case.

All organizations will have exception or edge use cases arise from time to time, in which access to an application or system cannot be determined solely from the user’s standard attributes. Certain access will inevitably be considered special and granted only under particular conditions, such as for limited time periods, special projects, extraordinary circumstances, or emergency situations.

Consider a common scenario in which an IAM system is confi gured to grant employees access based on the departments to which they belong. If access is managed through predefi ned RBAC/ABAC dynamic fi lters, then users in the IT department are assigned an IT role and given access to IT department applications and systems. Similarly, users in the Finance department are assigned a Finance role and granted access to business department systems and applications. However, neither would have routine access to the other department’s systems, because their positions do not require it.

But what if the IT director needed periodic access to a business system, such as when he or she is planning the department’s annual budget? The common access-granting solution calls for creating a new Finance role for the IT director using RBAC and ABAC static membership tools. This process is usually not the most effi cient, as it requires manual monitoring and management. It also calls for coordination between the requestor and access granter, typically including several out-of-band communications, before access is fi nally granted.

As the number of employees, vendors, contractors, and departments within an organization grows, so too does the complexity associated with managing access to a growing number of applications and systems.

� e Exception to the Role


7

New Roles Are Not Always the Answer

Organizations with more limited or older legacy IAM systems often have no choice but to handle new access requests by assigning new roles to a user. However, the very concept of roles—and the accompanying practices of role analytics, role mining, and roles engineering—is quickly becoming an outdated and ineffi cient means of solely managing access rights, particularly for edge use cases.

As the number of employees, vendors, contractors, and departments within an organization grows, so too does the complexity associated with managing access to a growing number of applications and systems. System administrators commonly manage this complexity by preemptively creating more roles for exceptions and edge use cases.

If they are using traditional RBAC methods, administrators are forced into role nesting, where new roles are stacked on top of existing ones, to provide users with deep, granular-level access to an application. Before long, the organization may fi nd itself facing the very real risk of role creep—the unsupportable and unmanageable situation in which new roles are created inside of existing roles, for every new access need and use case that arises.

This approach presents signifi cant management and operational challenges. By digging themselves into an ever deeper “role hole,” organizations set a bad precedent that leads to some unwieldy access management problems down the road. For example, it is bad practice for a user to have both Requestor and Approval roles at the same time because the user could approve his or her own requests—a defi nite confl ict of interest. Or having a dependency where your ability to have a certain role (Role 2) is dependent on already having another role (Role 1). So, for example, a person can’t be administrator of a system (Role 2) unless he or she is fi rst a user (Role 1) in that system.

As you can see, when roles are nested, it because much more diffi cult to manage, support, and identify role properties because the role structure is so complex. The task of keeping track of additional roles-within-roles for each user becomes a signifi cant support effort—fi rst for the IT department and then for individual business owners or unit managers who have to oversee access rights to certain applications.

The level of role complexity may also be too much for some business applications and systems to bear. A system originally set up for one basic user and an admin user might slow down or crash as it attempts to interpret requests from a user with more and more roles piled onto his or her profi le.

If an organization has more roles than users or if all roles are statically assigned, you are probably approaching access management in the wrong way.

New Roles Are Not Always the Answer


8

In addition, the largely manual process of handling exception use cases is not particularly effi cient, robust, or secure. Consider a common scenario: a part-time contractor is hired to complete a project lasting just a few months. The contractor is initially set up and given access to the two or three systems needed for the project. If the contractor should require access to additional systems as the project proceeds, permission is granted on an as-needed, ad-hoc basis—which often slows down the project’s progress.

And once the project is complete, the process of deactivating the contractor’s system access must be done manually. Typically, the administrator will turn off user access to the fi rst few systems, but access to other systems might inadvertently be left open long after the contractor has moved on. Systems added at a later time by another administrator are particularly vulnerable to being lost or forgotten.

Now, consider that larger organizations might have hundreds of exception use cases like this to manage. No one person can effectively keep track of who has access to which systems or when this access needs to be turned off. Situations like these are what put companies in the headlines after they’ve suffered a security breach.

While every organization and situation is different, there are some common red fl ags that indicate bad practices with roles. For instance, if an organization has more roles than users or if all roles are statically assigned, you are probably approaching access management in the wrong way. And yet, instead of pausing to rethink their access management approach, many organizations attempt to “solve” the problem with expensive role mining, roles engineering, and roles analytics solutions.

Instead of pausingto rethink theiraccess managementapproach, manyorganizations attemptto “solve” the problemwith expensiverole mining, rolesengineering, and rolesanalytics solutions.


9

Any number of vendors stand ready to sell a role mining tool that examines an organization’s structure, reviews the various business applications and systems in use, and then conducts an analysis designed to optimize the number of roles. Such tools might slightly improve the role assignment issue—cutting the number of roles down by as much as half—but they do not solve the problem outright. They merely allow the organization to operate more effectively, while perpetuating a bad habit.

This strategy makes sense only if one considers why these tools exist in the fi rst place: to provide a sustaining service. It is not in the vendor’s best interest to offer role-mining tools that trim an organization’s total number of roles down to a mere handful; they would essentially be putting themselves out of work. Instead, these tools are designed to simply make roles-based access more manageable, not to address the root of the problem.

It is not in the role-mining vendors’ best interest to offer role-mining tools that trim an organization’s total number of roles down to a mere handful; they would essentially be putting themselves out of work. Instead, these tools are designed to simply make roles-based access more manageable, not to address the root of the problem.


11

A Just-In-Time Approach to Edge Use Access

Classic roles management techniques and tools defi nitely have their place and provide value. But when it comes to special use cases, traditional techniques tend to treat exceptions like every other access request—the exception becomes the rule. If every access request becomes an exercise in piling new roles onto the user’s profi le, it’s time for the organization to rethink their approach—or at least fi nd an alternative solution for edge use cases that works in concert with the existing RBAC/ABAC-based IAM system.

We at Identity Automation recommend an alternative access-granting solution called Just In Time (JIT) Access—granting access to applications or systems for predetermined periods of time, only when needed. Many users are familiar with the concept of “just in time” as it relates to provisioning, a means of getting an account created in the system. With JIT Provisioning, if a user doesn’t already have an account in a target application, the application recognizes that. The IAM system then simply creates the account for the user on the fl y, the fi rst time he or she accesses it.

JIT Access is similar, but different in fundamental ways. Rather than providing high-level access to applications like JIT Provisioning, JIT Access allows for more granular, short-term access. Or, if a user doesn’t have access to an application or system via their “birthright” access from RBAC and ABAC policies, the IAM system can easily and quickly enable provisional access when the user requires it.

JIT Access works on the principle of creating Entitlements for a user as requested. While the word “Entitlements” has different meanings, in this context, the term refers to access rights to an application/system or a special access privilege inside of an application/system.

Entitlements are defi ned for each application and privilege a user might need. Users will automatically get some Entitlements via the RBAC/ABAC confi gurations set up for their job function, such as “Basic User.”

For other Entitlements, for instance when a user needs additional access in an exception situation (such as “Power User” access), a Workfl ow process enables users to request the appropriate Entitlement. Workfl ow refers to the implemented governance or business process that defi nes the steps required to have Entitlements granted, denied, removed, or revoked.

When it comes to special use cases, traditional techniques tend to treatexceptions like every other access request—the exception becomes the rule.


12

Users simply request the appropriate Entitlement, and the Workfl ow is followed to grant the access or privilege. Each Entitlement and associated Workfl ow can support approvals, escalations, expirations, and other logic conditions as needed or appropriate when being requested. They also support context, meaning that the process steps change slightly depending on the user and current conditions surrounding the request.

The “Just In Time” part comes from the fact that users can quickly get the access to what they need—without having to prearrange it or go through a long, drawn-out approvals process that impedes productivity. Instead, users simply requests the access they need, and are quickly granted access or an access privilege level to an application or system.

This JIT Access approach streamlines the process for granting user access, without having to submit help tickets, convene committees or wait days to assess the request up through the managerial chain of command. It is also a massive productivity booster that enables employees to get business tasks done faster, but without compromising security.

JIT Access follows the security principle of least privilege—providing users only the access they need for the minimum time they need it, and then removing that access or privilege. Access can be granted for just a few minutes or several months, depending on the sensitivity level of the application or the organization’s governance requirements. Special approvals and logic checks can be added when access to sensitive applications or systems is requested.

This access affords another critical benefi t: every Entitlement request, grant, revoke or other access control action is auditable. In this way, organizations will always know who did what and when, so they are always ready for an audit.

Let’s look at an example of a JIT access request where a system administrator needs to complete software updates to a system because security patches were just released, but does not have the privileges to do so by default. The administrator submits a request for “administrator access rights” to this system via workfl ow. Due to the sensitive nature of the request, it is fi rst sent by the IAM system to his supervisor for approval, and then, once approved, on to the system business owner for his approval. The business owner can see who made the request, when the request was made, and that the supervisor approved it. Once the business owner approves the request, the administrator receives a notifi cation that his access has been approved, and he has been given “administrator privileges” on that system for four hours. At the end of the four hours, the IAM system automatically removes those privileges from the administrator’s account.

JIT Access follows the security principle of least privilege—providing users only the access they need for the minimum time they need it, and then removing that access or privilege.


13

Access for Every Situation

No single access methodology can effectively manage every access use case across an organization. But taken together, the RBAC, ABAC, and JIT Access methodologies can address the vast majority of requests and give organizations far greater control and knowledge over every user’s systems access at any point in time.

Identity Automation recommends a simple approach to leveraging the different access control methods. Traditional RBAC and ABAC should be used to handle those use cases in which user attribute data is leveraged to dynamically assign roles and other access. These cases are the most common, representing the vast majority of all use cases in an organization.

For the remaining use cases, which encompass one-off exceptions or fringe cases requiring special steps to grant access, organizations should leverage Workfl ows as the primary means for users to request JIT Access.

Organizations can effi ciently handle their user access needs through RBAC/ABAC, while streamlining access management for any edge use cases with JIT Access. This proven approach provides the best balance between security and usability, while avoiding the signifi cant costs and resource requirements associated with implementing traditional roles management approaches for every use case.

Organizations can effi ciently handle their user access needs through RBAC/ABAC, while streamlining access management for any edge use cases with JIT Access.


14

The PAM Link to Just In Time Access

At its core, JIT Access is essentially a common use case or subset of the account protection disciplines known as Privileged Access Management (PAM). PAM is a process in which users request elevated access within their existing account for an application or system to perform duties that their standard level of access does not allow. A user makes an access request for a specifi c system or application, and once approved by the administrator, the user will have access through his or her normal account.

PAM provides varied, granular access to each user for a limited period of time. Companies are increasingly using this capability for greater fl exibility in their identity management solutions, and there are multiple methods, tools, and techniques for managing specifi c access under PAM.

The access fl exibility and security provided by PAM tools are what ultimately enable JIT Access to work so effectively—providing fast, managed and semi-automated access to privileged accounts as needed, while protecting against malicious outsiders or rogue employees.


15

A Solution, Just in Time

Whether for a simple collaborative project in which a user must access a different department’s resources or an emergency situation when systems are down, the effi cient handling of exception situations is critical in any IAM implementation.

Just In Time Access provides an innovative way to give users timely access and privileges to organizational resources that are outside their normal, routine work function. This approach enables users to request the access they need, when they need it, for any edge use case, while still allowing the organization to apply appropriate controls and oversight. Complex and expensive role management processes and tools are not required.

When JIT Access is combined with RBAC and ABAC policies, organizations can effectively cover virtually all of their access needs. This all-encompassing access control methodology gives organizations of all sizes the optimal balance between effi ciency, security, usability, and governance.

Identity Automation’s IAM platform, RapidIdentity fully supports this approach to access management and governance. Our models scale to any size organization, providing easily implemented access management and control for anywhere from 50 to 50,000 users.

When JIT Access is combined with RBAC and ABAC policies, organizations can effectively cover virtually all of their access needs.

IDENTITY AUTOMATION

7102 N Sam Houston Pkwy W, Ste 300 Houston, TX 77064, USA

Phone: +1 281-220-0021 Email: [email protected]

www.identityautomation.com

Just in Time Access

Documents

Transcript of Just in Time Access