Scalable AWS Access Management Part 1: Managing Permissions for AWS Accounts

Overprovisioned access is the new normal 

At Opal, we are frequently asked, “How are you different than the AWS integration with my identity provider?” Our answer is, “Just look at all data breaches involving overprovisioned access!” Most companies are not following principles of least privilege.  Too many people have extensive and indefinite access, which only accumulates as time goes on. In 2021, 51% of Twitter employees had privileged access to production systems and data. 

Identity providers are a great tool to deliver broad, group-based access, known as birthright access, typically managed via a set of complex, manual rules. While this is an excellent solution for relatively static data, access to cloud infrastructure is far too dynamic to capture this way.  Instead, access must be specific and granted when developers need it (and revoked when they don’t). Without a more holistic approach to authorization, overprovisioned access is unavoidable. Modern enterprises need a purpose-driven platform to implement least privilege while driving productivity. 

Opal Overview

This multi-part blog series will cover how Opal enables companies of all sizes to implement scalable access management for cloud infrastructure. This first post will discuss how Opal enables modern enterprises to implement least privilege for AWS accounts. The next post will outline our vision to integrate with AWS organizations and AWS Identity Center / SSO.

After building internal authorization systems at companies like Dropbox and Collective Health, the Opal team understands that operators should decentralize access management, incentivize self-service, and provide easy-to-use primitives. Start-ups to publicly traded companies trust our platform to build, maintain, and automate access management best practices.

The right people having access: decentralized access to AWS

At earlier stage startups, most engineering managers and security teams have a strong sense of available IAM roles and their access levels to most of the engineers at the company. However, as companies grow, this context is impossible to replicate. Most centralized IT or security teams don’t work closely with the apps they provision or know what access different engineers need. Enforcing the principle of least privilege requires a deep understanding of access boundaries. Without this knowledge, it’s difficult to understand if the requester really needs “admin” or if they can still do the work with “write” or even “read” permissions. 

Opal firmly believes in decentralization. Rather than relying on central teams, we want to delegate responsibilities to system owners and managers with the most context. 

In the product, every resource and group has Admins and Required Reviewers. Admins are responsible for setting necessary security configurations, such as:

• Who should be able to see this resource in their app catalog?
• What is the maximum duration for which “write” access can be requested?
• Does the approver need 2FA? 

Required reviewers are the teams and managers that can approve the request. Example workflows would include:

• Managers must first approve access requests to a customer database before the InfoSec team
• Read-only access to SSH can be auto-approved 

The context is compelling. It enables companies to increase productivity and security. Access requests can be routed directly to those who understand the applications and their boundaries, bypassing manual follow-ups with freeform justifications. Approvers can get the info they need fast with configurable request templates and have a simple, auditable way to request more information.

Having the right amount of access: granular cloud resources

IAM roles govern access to AWS services.  These roles are critical for provisioning bulk access to developers. However, they are most commonly distributed based on coarse, user-based attributes such as belonging to a large, multi-purpose engineering team. For this reason, typical management of IAM roles suffers from a few critical problems:

1. Access is indefinite and not dynamic.
2. It’s difficult to understand how roles are grouped or “bundled.”
3. Roles need to be manually managed and updated by operators.

 Most organizations don’t have the resources or time to set up the proper architecture and default to a few roles, such as 

• “Admin - All” 
• “ReadOnly - All”

With limited granularity, over-provisioned access is unavoidable.  For example, suppose business operations or sales engineers request access to a database to resolve a query. In that case, granting ubiquitous access to all databases or AWS is commonplace. 

Opal solves this problem through the usage of resources. By automatically syncing with AWS tags, Opal can represent databases, servers, IAM roles, Kubernetes clusters, and applications as resources. Furthermore, individual permissions, such as ReadOnly or Admin, are known as access levels. In Opal’s catalog, developers can browse and request access to resources directly. Operators can also map resources to familiar identity provider groups where those relationships are transparent and well understood for the best of both worlds.

Leveraging this framework, Opal can solve the three problems outlined above:

1. Rather than provisioning indefinite birthright access, engineers can use Opal to request temporary just-in-time access
2. Opal automatically ingests resources and decentralizes management to system owners with the most context
3. Developers can ask for specific permissions and see what resources groups grant.

Having access for the right amount of time: context-based access 

Once permissions are granted to employees, they usually have access until they leave the company. Despite having permanent access, most employees don’t need permanent access. Since most provisioning processes are fairly manual, companies don’t have the resources or time to de-provision access. People who are granted access for one-off tasks, changed departments or just received over-provisioned access now have permanent access long after they need it. 

The first shift that Opal brings is the concept of just-in-time access. Rather than inheriting birthright access, employees have to request it explicitly. To make this process efficient, Opal has heavily invested in Slack automation, delegation, and self-service user experience. 

The second shift that Opal brings is time-based access. Usually, an engineer only needs access temporarily to accomplish a defined task. Once completed, their access is no longer needed. Employees can specify the duration of their access requests, which automatically deprovisions their access. Reviewers can also reject the request if they think the duration is unnecessarily long for the tasks

The third shift is event-based access. While time-based access revokes permissions after a specified duration, such as one day or week, event-based access revokes permissions after completing a specific task. This relationship grants engineers access based on-call schedule membership or an assigned support ticket. 

Unifying identity governance with privileged access management

Thus far, we have covered how Opal can help provide granular, short-lived, just-in-time access. However, access is one-half of the problem. The second half is credential management. Traditionally, engineers use shared credentials in a centralized vault presenting security risks and operational challenges:

1. Operators can use local credentials if they lose access to their email during termination, for example, AWS IAM session tokens.
2. Shared credentials make it impossible to attribute logins or session activity based on identities.
3. Rotating passwords to servers and databases is a manual, labor-intensive process prone to human error.

With Opal, developers can automatically generate identity-based credentials that expire after 15-minutes. This workflow strengthens a company's security posture and eliminates an entire category of operational tasks. 

Summary

Opal helps you achieve least privilege by granting the right people minimal permissions to their AWS resources for the right amount of time. We’ve released a multi-part blog to discuss our vision and capabilities. In the next part, we discuss Opal’s vision to address the needs of start-ups to publicly-traded enterprises through AWS Organizations and AWS Identity Center / SSO.

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.