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.
Common Fate can be used to implement Just-In-Time access to cloud providers.
Stage 4: Adaptive Access
Least privilege equals maximum effort
- Eric Brandwine, VP & Distinguished Engineer at Amazon
Adaptive cloud access management takes historical access in to consideration, and automatically scoped to the least privileges required to enable the business tasks at hand. Access is based not on what users think they need, but on what they actually use and require. Due to the cost and effort involved, this high level of maturity is usually only attainable for teams of more than 100 engineers.
Data-Driven Permissions
This most advanced level of access management represents the most efficient alignment of technical requirements with business needs, making least privilege access the standard, not the exception. In many cases, common actions are performed via automation, so elevated access is not required or granted to users.
This level of access is the pinnacle of access management, since it builds upon the earlier levels, and refines the process of identifying and provisioning access.
Challenges
This level of maturity and automation requires the most up-front effort and work. It requires automation in all areas. The requirement for automation also provides the ability to produce an exhaustive audit trail and visibility in to the system. At this stage there should be zero manual access to production, but break-glass access is available with appropriate checks and balances, notifications and alerts, for the inevitable unusual scenarios. Especially in the early days of this maturity, access needs to be reviewed, not a blocker to access but as “trust, but verify” in action. The main drawback to this level of maturity is the human adjustment and learning curve required, since most engineers are used to working with lower levels of maturity.
Conclusion
This first piece introduces the different levels of cloud access maturity in a cloud environment.
In following pieces, the practical implementations of the different maturity levels will be detailed, and how organizations can progress their maturity level.
Read Part 2 of our maturity guide here.
