Cloud access represents an important challenge to businesses using the cloud in 2024. Unlike historical data center-based environments where the physical network was the perimeter of a company’s digital estate, now identity and access management (IAM) represents the most important boundary that requires protection. This is because in a software defined system like the cloud, the right identity has permission and the ability to change all other resources, including the network.
Identity is the Customer’s Responsibility
Modern hyper-scale cloud providers operate on a shared responsibility model (for example AWS and GCP), and the configuration of IAM is one of the first customer-owned aspects of the approach. Cloud providers pledge to provide a secure identity access solution for customers to use, but require that customers use it correctly to ensure appropriate access to their resources.
In a public cloud environment, where most costs are incurred on a usage/pay-as-you-go basis, access to resources represents not only a data security issue, but also a cost risk. Unauthorized access to your environment is bad not only for your reputation and brand, but also your budget.
Overview of the Cloud Access Maturity Model
This presents new and unfamiliar challenges in the modern, global and distributed workplace, and in this piece we will define a series of maturity levels for businesses to measure themselves, and hopefully aim towards to improve their security in the cloud over time.
- Administrator-centric
- Role-Based Access Control (RBAC)
- Just-in-time (JIT) Access
- Adaptive Access
As with any real-world environment, organizations will rarely fit neatly into a single stage of maturity. Different teams and applications will demonstrate different levels of maturity.
The value of this model is to give a common vocabulary and shared understanding of what “good” looks like for cloud access. With a common goal in mind, even large organizations can move towards higher levels of maturity.
A company’s maturity will be reflective of the least mature systems, or the maturity of the majority of their systems. This makes common tooling, centralized oversight, and demonstration of good patterns even more valuable and useful in an environment.
Stage 1: Administrator-centric
In the early stages of a business, functionality takes priority over security, and access is over-provisioned. At this level, access is concerned only with “who” is doing actions, rather than any other considerations. This approach is commonly seen in early-stage organizations and have less than 20 engineers.
The starting point for almost all organizations is an administrator-centric approach, where most - if not all - users receive administrator access, or something close enough to not make a difference to the risk profile. This is because a user with over-provisioned access can do their job, while a user with under-provisioned access cannot do their job.
Common Scenarios
This level of maturity is demonstrated in many “getting started” guides and blogs, where the first step is to provision an entity (like an AWS IAM User) with administrator privileges, so that the documentation can focus on the functional aspects, rather than the security concerns.
Many best practices approaches and techniques are not possible, because business and operational requirements are still being discovered and defined. For example, the principal of least privilege requires a legitimate purpose to define what “least” means for a particular user or principal.
Challenges
Symptoms of this stage include things like self-inflicted damage and outages. The common concept of “blast radius” describes the worst-case scenario if something goes wrong, and at this stage of maturity it can mean damage to any and all of the business systems.
Key person risk is a legitimate concern, since individual users have non-trivial access. Attribution of actions can be difficult or impossible due to the levels of access provisioned. Even if an audit log exists, it may not be trust worthy, because the users it audits have access to change it.
Stage 2: Role-Based Access Control (RBAC)
The next level of maturity focuses on a move away from administrator access for all activities, to more focused, business-aware, role-based access. At this level of maturity, a business centric, up-front thinking approach must be taken to requirements, and define the roles that to meet those requirements appropriately. This represents a shift to “what” level of access, rather than just “who” is accessing. This stage is common in organizations with 20 to 50 engineers.
Business Benefits
Even though administrator access is still available, day-today usage is greatly reduced, and users like developers (who don’t have a business requirement for administrator access) are no longer given elevated privileges.
This means that day-to-day exposure to blast radius exposure and damage is limited. Key person risk is reduced, since the shared roles represent the access required to operate the business systems, not an individual user.
Challenges
Defining the right level of access for roles can be a challenge in the early days of this stage of maturity. Managing and updating roles as they evolve over time can be burdensome for teams that have a low level of automation. If roles don’t meet the requirements of the users, they will fall-back in to old habits of using administrator access for everything, removing the benefit of having roles to assume. Even when users do the “the right thing” and assuming specific roles, the extra noise and indirection can be overwhelming if not managed appropriately, leading to a lack of auditability and understanding of their own environment.
Stage 3: Just-in-time (JIT) Access
At this level of maturity, access is not only role-based and linked to business activities, but the permission to use those levels are only provided when an approved business requirement is demonstrated. Access management is now about the “why” of access, not just “what” level of access is requested. JIT access to environment represents the alignment of access management with business requirements: if you don’t have a valid reason for access, you don’t have it.
Time-Limited Permissions
Access to a particular role or level of access is subject to an approval, and granted for a limited time window. Requests are approved by the appropriate business-level stakeholders, or by pre-existing rules, such as developers assigned to manage a particular account. Access is removed when the requirement is over, resulting in less standing access that could be accidentally used or abused. This approach dramatically reduces the problem of blast radius, because while mistakes are still possible, their impact is greatly reduced due to less standing or implicit access.
This level of advanced and deliberate access is more mature than most cloud-based businesses today, and is a common aspirational goal of many organizations. It makes most sense in organizations with 50-100 engineers, so that the investment in automation has a positive return on the effort required.
Challenges
Including an approval process, regardless of how well this aligns access to business requirements, introduces friction. To avoid this friction, teams or users might hoard access, or use access like build systems to accomplish tasks that should be done in a different manner. If approvals are not granted in a smooth and timely manner, they become a barrier to productivity and time to resolution of issues. Due to these challenges, automation becomes an absolute requirement at this level of maturity, which represents its own set of challenges for an organization.
CommonFate.io is self-hosted JIT access to your AWS accounts, GCP projects, and more.
