Managing access at scale is hard.

Chances are your employees use many complex systems like AWS, GitHub, and Salesforce in their day-to-day work. Each of these systems has its own way of defining access control, whether via roles, groups, resources, permission sets, or policies.

With so much variety, it’s difficult to define a single access model that gives users what they need to do their job and nothing more. On the one hand, a simple access model may generalize well across the company but risks giving out too much access. On the other hand, a complex access model may limit company exposure but might not giving enough access for employees to be effective.

To strike a balance between these tradeoffs, companies can implement a two-pronged strategy using a combination of birthright access and just-in-time access.

Birthright access grants an employee what they need based on who they are and what they do within an organization. In other words, this is the standing access an employee has. It’s their “birthright”, just by existing.

JIT access, on the other hand, offers an employee easy workflows for getting access to anything that’s not already granted based on who they are and what they do. In other words, JIT access offers employees a catch-all for everything that doesn’t fit cleanly into the birthright model.

Both birthright and JIT access are essential to a holistic access management strategy, as they complement each other in their strengths and weaknesses. Together, the two approaches can help your organization implement least privilege access at scale.

Birthright access

Birthright access refers to everything an employee needs based on who they are and what they do.

When an employee first joins a company, they might need access to docs in Google Drive, channels in Slack and projects in Jira in order to do their job. Depending on their role, they might need access to even more exotic resources like Salesforce profiles, GitHub repositories, internal tool roles or Kubernetes clusters.

No one wants to spend their first few weeks on the job waiting for access. As a result, companies attempt to automate provisioning birthright access so that when someone joins, they have what they need to do their job from day one.

Challenges

While this automation can be effective, there are a number of challenges with birthright access:

• ‍Implementing role-based access control (RBAC) across systems is difficult. For instance, being an “engineer” might have a well-defined meaning in Jira, where it involves having access to the “Engineering” ticketing project. However, in a more complicated system like AWS, being an “engineer” may offer little insight into what a user needs to do their job.‍
• Some access must be short-lived. In certain cases, access is so sensitive that provisioning it as part of your birthright model introduces unacceptable risks. For instance, access to a production database could leak sensitive customer data, and so it should be given out sparingly, and never permanently.‍
• Birthright over-provisions access. At scale, access is usually applied to entire cohorts of employees (for example, an entire team) regardless of whether every single member of the cohort needs that access. Moreover, after it’s granted, access is rarely revoked. This leads to a gradual accumulation of new access over time, or privilege creep, which hurts an organization’s ability to implement least privilege access and limit their attack surface.‍
• Some access is based on regular events, not one-and-done. For instance, if an engineer is on-call for a particular week, their access requirements will be different from when they’re not on-call. Similarly, if a support person is responding to a customer bug as described in a ticket, their need to access internal tooling might change based on the specifics of that ticket.

None of these cases are well-handled by birthright access. Below we’ll see how JIT access addresses many of these shortcomings.

Just-in-time access

JIT access empowers employees to quickly get access that isn’t granted via the birthright model, often for short periods of time.

For instance, if an engineer is working on a new project for a sprint and they need additional GitHub access, they might use a JIT workflow to get that access. With a robust JIT system, the engineer should be able to easily identify the role or repository they need and fire off an access request. On the gatekeeper’s end, they should be able to easily approve and propagate the desired access change. The JIT system should then revoke access at the end of the sprint automatically.

Because JIT access is based on ad-hoc workflows rather than pre-defined access, it’s agnostic to what a user should or shouldn’t have. That discretion is mostly left up to the reviewer of the JIT access request.

This flexibility allows JIT access to address many of the shortcomings of birthright access.

For example, if the birthright model fails to define the correct role-based abstraction, JIT access empowers employees to quickly adjust their access. If a particular adjustment continues to be made regularly, the birthright model can then be updated accordingly. JIT access also handles sensitive data and resources well in cases where no user should have permanent access, such as production databases.

Finally, JIT access’ time-bounded nature means access is cleaned up automatically, limiting over-provisioning. On top of that, birthright access can be granted more sparingly with the knowledge that any individuals who aren’t given the appropriate access can easily remediate with JIT access.

Challenges

It’s incredibly important that JIT access is easily actioned given that it’s likely to be done frequently. This presents a number of challenges for an effective JIT system to implement:

• ‍JIT access needs centralized workflows. Whether it’s for a Salesforce role or a GitHub repo, effective JIT access should have a centralized catalog for an employee to easily identify what they need, and from which they can kick off an access request. Too many companies have one tool for JIT provisioning, another tool for ticketing, and another tool for audit logging.‍
• JIT access needs decentralized ownership. At many organizations, access requests are all routed to a single team like Security or IT, which creates bottlenecks. Instead, access reviews should be done by those with the most context around a tool, its capabilities, and the data it contains.‍
• Implementing JIT access requires cultural change. Many organizations err on the side of provisioning too much access, rather than too little. Creating a culture where access is given out sparingly but where users can frequently — and seamlessly — request and receive new access requires a meaningful organizational change.

Opal

As you can see, effective access control can be implemented by combining the scalability of birthright access with the flexibility of JIT access.

At Opal, we’re building a solution that unifies the two and augments their capabilities.

On the birthright side, we’ve implemented new ways of visualizing and defining birthright policies, such as on-call schedule based access and support ticket based access.

On the JIT side, we offer tooling to help organizations define a decentralized ownership model, integrate with a variety of different systems, and hook into common productivity toolchains to easily launch workflows. With a single click, employees can get what they need so they can focus on high-value, mission-critical work.

Together, the two approaches can help your organization achieve scaleable least privilege.

About Opal:

Opal is the centralized authorization platform for IT and Infrastructure teams. Deeply integrated with developer infrastructure, SaaS applications, and custom internal tools, Opal enables companies to implement scalable access management.

Want to see it yourself? Contact hello@opal.dev or book a meeting here for a personalized demo.