Multi-platform role design

TL;DR

• Vendor provided roles target reference architectures and operating models
• Vendor provided roles have names or labels that do not fully communicate the organisational intent of using the role (e.g. ViewRole for a support function)
• Vendor provided roles do not align across platforms
• Vendor provided roles do not align to organisational operating model
  • (Vendor roles align to a hypothetical models, not your organisation’s)
• Vendor provided roles have gaps against the org model
• Bottom up design creates point solutions with operational bottlenecks
• Bottup up design increasingly adds friction that prevents scaling, increases the cost of change, and raises operational costs (BAU)

Inconsistent access patterns are a headache

When we opt to use a vendor platform we need to align the platform to our operating model. This alignment is crucial to remove operational bottlenecks and enable robust governance. Most of the time, an organisation’s use of a vendor platform grows organically and integrates with other platforms organically. This creates inconsistencies in naming, access patterns, visibility that increase the cost of change, increase access complexity.

This organic use of platforms is a bottom up approach and it limits growth. What are the main items that cause us headaches?

• Different processes give access to different roles with tailored entitlements
• Designing roles, implementing roles, granting access to roles, gaining access to roles, and reviewing role access use all require platform-specific SME knowledge.
• The implementation details of individual platforms leak upwards and direct the design and execution of the operating model.
• Adding additional platforms increases operating model complexity and limits or decreases an organisation’s ability to scale

Planned use of platforms is a top down approach and it enables growth. How does this remove friction?

• Identical processes give access to identical roles with tailored entitlements
• Designing roles, granting access to roles, gaining access to roles, and reviewing role access use all require shared operating model knowledge.
• Only role implementation requires platform-specific SME knowledge.
• The implementation details of individual platforms are specified to meet the needs of the common operating model.
• Adding additional platforms introduces minimal overhead with linear scaling

Ignore the vendor provided roles

Vendor provided roles are so ill-defined for operational purposes that most hyperscalers don’t let their professional services teams touch them directly on client projects. This should give you a big hint that maybe, just maybe, they’re not the right tool for you. Let’s look a bit closer at why.

They don’t differentiate between ownership types

For vendors, ownership is some contractul boundary between vendor and customer (e.g. shared responsibility model or some license to operate) and any roles provided by the vendor to accomodate an operating model on the other side of that boundary will be a rough and generic guess at best.

We often don’t fully understand what vendor roles actually allow

To understand what a role does we have to be deeply familiar with the effect of each individual permission associated with it. The almost univeral ReadOnly role is a prime example - does having read only access to an environment mean we can access and exfiltrate any customer data within the role’s scope? Why yes, that is exactly what that role will allow in many cases.

ISO Reference model

Vendor roles are inconsistent across vendors

Sample Azure role definition

Sample AWS role definitions

Vendor roles don’t map cleanly to internal functions

Business functions and vendor provided roles don’t match - a very common scenario is for a vendor-provided role to have excessive privileges for the functions it’s attached to, leading to unnecessary implementation of detective controls to plug audit gaps for critical systems.

Vendor roles overlap in functionality

One of the design principles I push for is exclusive change access to specific resources for roles. This greatly simplifies reasoning about the platform, eliminates cross-team contention to change a resource and allows for automation of access reviews. Having multiple parties write to the same resource makes ownership ambiguous, and is rarely something that anyone wants. Use the permission model to make change exclusive to a single party.

Vendor roles are ambiguous and entitlements only map to technical operations

Regardless of service or implementation details, we care about,

• Credential exposure
• Data Access
• Privilege escalation
• Resource exposure

There exists no definitive list of Sensitive IAM Actions that can lead to credential or data access, privilege escalation, or making resources public. Several tools have tried to take an opinion on this issue, but there is no centralized list of these sensitive IAM Actions that tools and IAM policy writers can reference.1

Note for hyperscalers,

Create an internal reference model

Surface the operating model

Most operating models have gaps or ambiguities but even when they are only implicit, operating models are very easy to surface.

Place the operating model over the assets

Model the relationship between internal platform management and tenancies

Observations,

• The administrative structures for organising and grouping workloads, ownership and policies follow a consistent pattern when adopted by enterprises.
• Management and Workload resources co-exist where workloads are run (e.g. applications)
• Levels of hierarchy are an indicator of organisational maturity
  • 1 level : All functions are collapsed (e.g. startup)
  • 2 levels : Platform and root are collapsed (small business)
  • 3 levels : Multiple internal platforms under a single root (enterprise)

Note for hyperscalers,

The technical structures differ across CSP platforms and terminology is used inconsistently among them.