Some organizations with multicloud environments opt for a cloud service provider with native identity access management (IAM). However, these same people often struggle when it comes to adding the cloud-native controls into a larger enterprise IAM program.

In part 1 of our cloud-native IAM controls blog, we explored why these controls are not enough for managing identity and access risk at an enterprise level. In this article, we will offer insight into governance concerns and a potential approach to help bridge the gaps.

Setting Up Cloud-Native IAM Controls Properly

Most businesses need help with their approach to entitlements management for their clouds. Your goal should be to deliver a blueprint to your developers and IT admins with the roles, policies and entitlements needed to connect cloud-native controls to an enterprise-level program. Once you’ve established a blueprint, the next step is to automate IAM controls to provide something like ‘IAM as code’ so that you can reduce risk and streamline the work.

Diving Deeper

The approach starts with setting up specific policies and roles for governance. The policies dictate how to deal with cloud-native IAM controls. Defining IAM roles at the enterprise level helps provide specific permissions for users on what they can and cannot do. In other words, you need to create a repeatable pattern for groups of users assigned to a specific role — contractors, project managers, admins, etc.

Each role needs specific IAM access so that the agility of these cloud-native landscapes is preserved. What does this mean? Let’s break it down.

Different Options for Different Governance Needs

To begin with, you need a mix of roles and rules set up within the enterprise governance solution. They should reflect the native IAM functional controls.

You should further define the rules by case or the context in which a user needs more approval when they request access. For example, if you are talking about a DevOps use case, you often have in the DevOps team a ‘sprint master’ or project manager. This role can request cloud-native IAM privileges that are assigned to someone else in the project team.

You should align the DevOps-specific role at the enterprise level. Through the classical identity governance path, your environment will capture the access request for auditing and recertification.

Multicloud environments demand a multilayered IAM approach. You need to automate most of these layers in the sense they should be approved and agreed upon in advance with the relevant stakeholders. Only when you have that stakeholder approval can you automate.

An identity and access governance program comes configured with predefined roles, rules and use cases. The enterprise IAM program provides automation and enables the client to move from a reactive manual state to a proactive state. As you automate, you can expect less risk. The more manual a process, the more potential for human error, such as misconfiguration of privileges or forgetting to remove users when they leave.

Reducing Risk With Cloud-Native IAM

In our first blog, we discussed how security failures are often the result of mishandling of identities, access and privileges. Automation can help reduce this type of risk. But you need the right policies, rules and role templates to get IAM security right.

Manual processes in identity and access governance do introduce risk. The goal of identity management is to reduce risk. Whenever possible, you will want to automate role selection and privileges. Make sure users adhere to those roles so you don’t inject any undue risk.

A blueprint to integrate the enterprise identity and access governance tools with the cloud-native IAM features will help guide you through automation. This is the most efficient option because you can review the roles and policies across multiple cloud environments.

If you’re an enterprise looking to scale your enterprise IAM program, start with these three principles of designing modern IAM programs:

• Enhance identity assurance,
• Integrate identity intelligence, and
• Address compliance mandates with identity governance.

Stay tuned for our third and final blog post in this series to learn more about blueprints and how to connect cloud-native IAM controls to an enterprise IAM program.