In part 1 of our Cloud Access Maturity Model, we outlined four stages of access management maturity in the cloud: Administrator-centric, Role-Based Access Control (RBAC), Just-in-Time (JIT), and finally Adaptive.
In this follow-up piece we provide more detail about what each level looks like, how to measure maturity with metrics, and ultimately how to progress to the next stage.
Stage 1: Administrator-centric
In the Administrator-centric stage, access management is at its most basic level. This stage is characterized by over-provisioned access, where most - and often all - users have administrator privileges. This stage prioritizes functionality and ease of use over security, which poses significant business risks.
Pains
This stage of maturity is like running on a legacy system, since it’s missing the security advances of the last 10 years. This stage also goes hand-in-hand with long-term credentials (for example, IAM user access keys) that are one of the main sources of compromise.
The main mitigation available in this stage is to limit the number of people that have access to the system. Adding additional layers of authentication, like multi-factor authentication (MFA), at least adds additional verification that the user is who they claim to be, but still doesn’t address the excess permission granted.
Obtaining compliance certifications at this stage is very difficult due to such a low level of maturity. Any business that requires or prioritizes official compliance recognition needs to make changes immediately.
Metrics
The number of entities with administrator access, which should be as low as possible. If administrator access can’t be avoided, it should at least be tracked and measured, so that it can be improved over time.
The number human users without MFA enabled, which should be zero. Ideally, MFA should be enforced by the identity provider.
The age of long-term credentials, which should be lower than an agreed threshold, for example 30 days. This can and should be enforced by the identity provider, for example password rotation. Additionally, any user-controlled credential should meet minimum complexity requirements, for example password strength, and it should be enforced.
Advancement
The key to success at this level of maturity is to spend as little time as possible at it! By tracking the metrics and reviewing them periodically will help push them in the right direction. It’s not hard to mature beyond this stage, which makes it even less forgivable to spend excessive time at it.
Adding a centralized identity provider (IdP) for human users will de-couple identity from access, help reduce duplication, and push activities towards using roles and short-term credentials.
Identifying and tracking machine users with administrator access gives a focus point for access to remove or reduce over time, and regularly reviewing this list will encourage people to do the right thing on a day-to-day basis.
Stage 2: Role-Based Access Control (RBAC)
The RBAC stage represents a significant step forward in access management maturity. At this stage, organizations move away from universal administrator access approach to more focused, business-aware roles. This stage requires upfront thinking about access requirements and defining roles that meet these needs appropriately, which represents a move towards deliberate, context-aware security.
Pains
Even though this approach greatly improves on the previous stage of maturity, there’s still lessons to be learned. Working out what each role should have access to, and how many roles is appropriate is a process that takes time, feedback, and practice - You don’t know you’ve got too many roles until you’ve got too many roles! A lack of ownership or agreement roles’ scope is almost guaranteed to happen at this stage. In addition to roles still being too permissive, another potential source of pain at this stage is roles not being permissive enough, or not accurately scoped to the task requirements. This leads to users falling back to administrator-level (or similarly over-permissive) roles to get their job done on a day-to-day basis.
Metrics
Number of permissions granted to individuals, which should go down to as close to zero as possible. When this metric is high, it suggests roles are poorly defined.
The number of roles available, which should go up, and eventually reach a stable number. The exact number will depend on things like the team structure and business requirements, but regardless should eventually stabilize.
Advancement
Reviewing the approach towards resource containment can be a valuable exercise at this stage, since it will directly impact the scoping of roles. This means accounts in AWS, projects in GCP, and subscriptions in Azure.
Automation can be used to help generate roles based on historical activities. The increased resource management that comes with RBAC means that automation in general becomes more valuable, since it helps address the associated management overhead. More specifically, automation can also be used to help generate roles based on historical activity, giving higher levels of confidence.
Stage 3: Just-in-time (JIT) Access
In the Just-in-time Access stage, organizations add a temporal dimension to their access management, so that access is not only role-based but also time-limited. This represents an additional dimension of access management that is still tied to specific business requirements. Adding a time limit to access significantly reduces the “standing access” available to entities, and aligns permissions more closely with actual needs.
Pains
Introducing a time-based approval step to access undoubtedly increases security, but that comes at the cost of convenience. If approvals take too long, users may try to revert back to using standing or long-term access to avoid being blocked. This highlights the need for automation to streamline the approval process as much as possible.
A common trap to fall into at this stage is to require manual/human approvals for all access, even if it’s a non-critical level of access. As much as possible, the additional friction of approvals should be used for higher, more business-critical levels of access, to reduce productivity bottlenecks.
Metrics
Standing hours of access, which should go down to as low as possible.
Access request approval rate, which should be as high as possible. If this number is low, it suggests that the policies around access are not fit for purpose i.e. users are requesting access they shouldn’t have been able to request.
Percentage of approvals that are auto-approved, which should be high but stable. This should be as high as possible for entitlements that are not critical.
Time to approval response, which should be as low as possible, to a reasonable expectation. This means that requests are approved or denied in a reasonable and consistent timeframe.
Advancement
This stage requires extensive automation, and advancing beyond it requires even more! This level of security becomes prohibitively limiting to productivity if not entirely automated.
Counter intuitively, this stage is not focused on limiting the permissions granted, only they are granted for an appropriate reason and time period. This means that you might be granting more privileges, but for less time - In this stage, less really is more!
Roles and levels of access should be well understood and defined, and only change periodically, for example when new teams or projects are spun-up. As part of the automation process, activity and audit actions need to be extensively and consistently logged, so that they can be used in the next stage of maturity.
CommonFate.io is self-hosted JIT access to your AWS accounts, GCP projects, and more.
