Scalable Access Management With Opal

Abstract

This paper is an overview of how Opal improves security, productivity and compliance at enterprises by scaling their access management across cloud infrastructure, internal tools and third-party applications. Opal solves the by providing the infrastructure and insights to decentralize organizational workflows. Decentralization ensures those with the most context are the ones actually administering access. On the whole, less access is granted overall and bottlenecked teams like IT, DevOps, Security and Compliance are freer to do higher impact work.

Background: Access management doesn’t scale

Managing access is complicated. Initially, users need access to systems when they first join the company, then later when they change teams or start new projects. Each system has a different set of owners, a different way of requesting and managing access, and a different audit log. Once access has been granted, it needs to be periodically reviewed for compliance. Over time, role and group definitions should to be pruned based on usage according to the principle of least privilege. Finally, when users leave the company, their access should be entirely revoked.

For small organizations, managing the different stages of the access management lifecycle is straightforward. However, at larger organizations, managing so many processes becomes challenging.

The problem: Technology vs process

Unfortunately, implementing least privileged access management at scale is difficult. The core problem is while solutions exist to solve the challenges of access management, there is no integrated solution to address its challenges.
This market gap is evident in how organizations leverage identity providers today. Identity providers, which are the foundational access management solution at most organizations, offer a single surface to create, update and remove users from many different systems. From a technology standpoint, their breadth of integration is powerful. From a process standpoint, however, they offer no in-built guidance for how an organization should operate them. The result: a handful of admins manage all day-to-day operations related to access management, even when they have little to no context, which leads to sprawling directory structures, unclear ownership, access request delays and over-provisioned access.

Similar problems exist for solutions related to ticketing, ephemeral access, access reviews and least privilege. In each instance, the technology exists to solve an immediate access management pain, whether it’s requesting access, revoking access, conducting an access review or pruning a role based on usage. However, at a certain scale, these technological challenges quickly become process challenges. Specifically, a process fails to scale when it lacks:

1. Central integration. Users should not have to navigate across multiple tools and surfaces to execute the process.
2. Clear entry points. Users should understand from what surface and with what inputs they should initiate the process.
3. Well-defined owners. The process should have clear owners that maintain, execute and monitor the process.
4. Well-understood best practices. The process should be designed and executed in a way that supports the needs of the organization holistically.

1. Central integration

When a user needs to interact with multiple surfaces to execute a process, scalability suffers. For instance, if an organization’s access request system is in Jira, the process executor may need to manually navigate to an end system to propagate approvals. This adds overhead and makes the process more error-prone. Additionally, this couples servicing requests with propagating changes. This is especially problematic when end system resources are described with infrastructure as code. In that case, anyone who approves a request must be technical enough to create a code change to propagate the approval or find someone who is.

Moreover, a lack of central integration means relevant context may be missing for both the requester and the reviewer. For instance, support-tickets, on-call schedules and usage data all inform whether a user should have access but this context is scattered across many surfaces. As another example, with many identity providers, a lack of deep integrations with end systems means groups appear as black boxes to users and admins. Requesters must infer what they are receiving and admins what they are configuring based solely on the human-readable name and description of the group.

2. Clear entry points

When a user is unclear from what surface and with what inputs they should initiate the process, scalability suffers. Many workflows such as access requests and reviews require large numbers of users to be involved but have overly broad entry points such as ticketing systems, messaging platforms, email, or spreadsheets. The lack of structure in these channels makes it difficult to build process orchestration as well as audibility. It also leads to user confusion as the location of the entry point and its required inputs are not well-advertised to the user. For instance, an engineer might not know whether to use Jira, Slack or an internal tool to request access to a database. Once they determine which surface to use, they might be further confused about what data is required in the request, which might depend on specific request workstreams.

3. Well-defined owners

When the process lacks a clear owner to maintain, execute and monitor the process, scalability suffers. At most large organizations, responsibility is bottlenecked on one of several teams to include IT, Security, DevOps/SRE and Compliance, depending on the operation. Beyond being short-staffed, these teams are short on context. For example, whether a user should be in a group or a permission should be on a role is a question better left to system and resource owners rather than a catch-all team. Compounding these challenges is the disconnect and dependency between the objectives of these teams. For example, neither DevOps nor IT concerns itself with an organization’s attack surface or compliance posture, and yet Security needs them both to prune access, while Compliance needs them both to review access.

4. Well-understood best practices

Even when entry points and ownership are unambiguous, it’s rarely clear what the organizational best practices are for a given process. Best practices are difficult to automate and codify, as they require a deep, opinionated understanding of the domain. As a result, access management processes are often executed without a holistic understanding of the organization’s needs, which hurts scalability.

For example, identity providers offer little guidance on what taxonomy, if any, a group structure should follow. Ticketing platforms do not make it clear which fields should exist on a ticket to accommodate different access workstreams. Ephemeral access products assume an organization understands which resources should be granted by birthright and which should leverage just-in-time access. Access review systems fail to provide context for which subset of users, resources and groups should fall within scope of a review. And least privilege tools offer little help for which roles should exist in the first place, independent of which should be pruned.

The upshot is organizations have the technological understanding but not the process knowhow to implement least privileged access management at scale.

The solution: Orchestrating the Organization

Opal solves the problem of implementing scaleable least privilege by orchestrating an organization as much as its resources. By solving the problem of process, Opal allows organizations to leverage well-understood technologies to implement access management at scale.

There are two dimensions to Opal’s approach:

1. Process infrastructure. Opal’s positioning as infrastructure and rich set of integrations provides the control plane to surface and orchestrate most workflows related to access management in a decentralized, self-service manner.
2. Process insights. Opal provides the insights ****to help organizations define the correct process owners and policies, as well as implement process best practices so that Opal’s tooling is used with a holistic understanding of the organization’s needs.

Process infrastructure

Opal’s foundational value proposition is its role as process infrastructure. Opal is deployed alongside your developer infrastructure, internal tools and third-party applications. Leveraging its broad array of integrations, Opal acts as an organizational control plane that performs the following functions:

1. Ingestion. Ingest access-control data from remote systems to define a centralized access control model with necessary additional context.
2. Surfacing. Surface UI and API-based entry points for workflows to support operational changes to the access control model.
3. Orchestration. Apply a consistent set of ownership, policies and insights to the access control model.
4. Propagation. Propagate workflow output through a variety of channels to different end systems.

This allows Opal to sit as a unifying orchestration layer for your organization. Any operational workflow related to the access management lifecycle can be abstracted into Opal, which offers the following benefits:

• Entry point is clear. The workflow is surfaced to a user in a consolidated UI catalog or API.
• Context is clear. Contextual data relevant to the workflow such as which resources are in which groups, historical usage data, on-call schedules and support tickets are imported into Opal.
• Ownership is clear. The workflow can be assigned an unambiguous owner.
• Ownership can be safely delegated. The workflow’s owner can be decentralized away from traditional gatekeeping teams, while still being governed by security policy guardrails.
• Workflow output is automatically propagated. The output of the workflow can be propagated remotely through a variety of channels, either directly to the end system, or indirectly via an identity provider of infrastructure as code provider.

Such workflows include, but are not limited to, the following:

• Changing user access (both self-serve and top-down)
• Adding/removing users from groups
• Adding/removing users from resources
• Revoking access as part of an access review
• Initiating just-in-time sessions via the Opal UI or CLI
• Automatically suggesting user pruning on resources and groups

• Changing access definitions (both self-serve and top-down)
• Binding new resources to groups
• Creating and updating new roles
• Automatically suggesting permission pruning on roles
• Automatically suggesting resource pruning on groups

The net result of this infrastructure is that organizational process is scaled. Users now have consolidated entry points for access management workflows, either via the UI or the API. Workflows have clearly defined context and owners with governing policies, and their output is propagated in an automated fashion.

Process insights

Infrastructure and tooling is half the picture — if an organization doesn’t understand its own processes, it will be difficult to define a robust ownership and policy model in Opal. As a result, Opal meets organizations halfway by helping them understand and contextualize their existing processes, define the correct ownership and policy model in Opal, and then seamlessly migrate to using Opal for access management.

Opal has several migration-friendly approaches to surface process insights to organizations:

1. Crowd-sourced requests
2. Usage based insights
3. White glove support

Crowdsourced requests (Security by default)

With this infrastructure, organizations can begin with the strictest access management security configurations possible. Over time, based on request activity and changes in organizational activity, the central gatekeeping teams to include IT, Security, DevOps and Compliance can begin to devolve these processes where safe to those with more context. Process can be pushed further across the organization while the central gatekeepers are still able to implement guardrails in the form of policies that enforce basic review structure, alerting and other measures to prevent misuse of delegated authority. While this initially offers only marginal improvement over the status quo, users can begin making self-service requests to change the access control model and increasingly delegate authority away from centralized teams.

Usage based insights

In addition, organizations can leverage Opal’s usage based insights to help define the correct ownership and policy model. Opal surfaces insights from a variety of sources including AWS Access Analyzer, as well as historical request and usage data.

For instance, if AWS Access Analyzer detects that a role is over-provisioned, Opal can surface this insight as a Slack message to the appropriate role owner. As another example, if Opal detects that several users on the same team regularly request access to the same resource, it can surface a notification to the team manager to request that the resource be bound to the group that manages access for the team. Finally, if Opal detects that no one on a team has used a resource in the last month, Opal can surface a notification to the team owner to suggest that the resource be removed from the team’s group.

White glove support

Finally, Opal offers white glove support for defining the correct ownership and policy model in Opal. The Opal team has worked with dozens of organizations and understands the most common practices around ticketing workflows, group structure definitions, as well the optimal balance of birthright and just-in-time access. Their white glove support is free of charge. They are eager to share their knowledge and expertise!

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.