Organizations of every type and size are looking to the cloud for a multitude of benefits, including agility, quick time-to-value, cost savings and scalability. But enterprise-scale deployments can make this process complex, more so as it relates to identity and access management (IAM). Protections through the cloud are often a web of permissions that, if your team does not maintain them properly, can lead to a costly data breach. Let’s take a look at how exactly cloud-native IAM works. Next, check back for the second in this series of three articles on cloud-native IAM controls.

According to the 2020 Cost of a Data Breach Report, nearly 20% of the companies that suffered a malicious attack found that it was due to stolen or compromised credentials. Alongside these compromised credentials, misconfigured cloud servers were the most frequent threat vector. These survey results show how poor management of identities, access and privileges can impact your business. When it comes to public cloud environments, much of the onus for defensive configuration and management is on you, not the cloud provider.

Learn more

Cloud Identity Means a Perimeter-less Landscape Demanding Stronger Controls

I want to avoid the impression that cloud-native IAM from a specific cloud service provider is not helpful. That isn’t the case at all. Native IAM controls found in public cloud offerings and open environments can offer unique benefits such as agility for DevOps processes and developer-friendly IAM features. In contrast, an enterprise IAM program delivers advanced features that go beyond these controls and conform to corporate governance policies.

I see many of the same customer challenges across these complex, multiple cloud environments that enterprise IAM programs have resolved. Many of the public cloud providers offer native IAM controls for target environments but lack the connection to larger programs of work. In addition, the concept of enforcing least privilege through proper governance and privileged access with these native controls becomes quite difficult. When you start to look at trying to use these controls across multicloud setups or at an enterprise level, it becomes even more difficult.

IT and IAM teams must go beyond native controls and think about the IAM governance program from a broader, programmatic perspective. You should leverage these native controls according to a unified corporate governance policy that includes a predefined access model.

Getting the Work Done with Cloud-Native IAM Controls

In various cloud environments, the native IAM controls are commonly called identity management. But what’s confusing is that these controls are not truly enterprise-level identity management as we know it. They are simple access control. For instance, there’s no life cycle for digital identities. You can assign users to specific accounts, but you cannot really manage the life cycle of people — joiners, movers and leavers. The critical auditing needs for action on organizational and other changes are handled at an enterprise level.

The cloud-native IAM controls are not intended to manage a full identity life cycle. They are intended for specific use cases. For example, with the Red Hat platform, you have two main use cases. The primary ones are DevOps and IT operations. In these specific use cases, you can set up predefined roles and policies using native controls. But these stay where you put them. They don’t extend beyond the specific platform used.

IT also plays a part in the DevOps chain. For example, if you are going through the entire DevOps chain at some point in time, you are setting up new permissions and roles. This is where the DevOps use case connects to IT. Even in open-source environments, you will often need to use more than just one basic IAM function.

Can Cloud-Native IAM Controls Work in Multicloud Environments?

If you are working in multicloud environments, then the answer is no. Every provider has its own unique set of IAM functions. IAM controls are specific to each cloud service provider. They don’t talk to or operate with one another or in other cloud platforms. So, with the native controls, you have different components that provide piecemeal IAM functions.

The specific entitlements from cloud environments often do not align with the enterprise roles. They may be similar, but the details are very different. In the end, you need to define specific roles at an enterprise level that contain entitlements for cloud environments.

In the next article, I will share a few strategies for how to broaden these cloud-native IAM controls. Until then, learn how to design an IAM program optimized for your business.

More from Identity & Access

Passwords, passkeys and familiarity bias

5 min read - As passkey (passwordless authentication) adoption proceeds, misconceptions abound. There appears to be a widespread impression that passkeys may be more convenient and less secure than passwords. The reality is that they are both more secure and more convenient — possibly a first in cybersecurity.Most of us could be forgiven for not realizing passwordless authentication is more secure than passwords. Thinking back to the first couple of use cases I was exposed to — a phone operating system (OS) and a…

Obtaining security clearance: Hurdles and requirements

3 min read - As security moves closer to the top of the operational priority list for private and public organizations, needing to obtain a security clearance for jobs is more commonplace. Security clearance is a prerequisite for a wide range of roles, especially those related to national security and defense.Obtaining that clearance, however, is far from simple. The process often involves scrutinizing one’s background, financial history and even personal character. Let’s briefly explore some of the hurdles, expectations and requirements of obtaining a…

From federation to fabric: IAM’s evolution

15 min read - In the modern day, we’ve come to expect that our various applications can share our identity information with one another. Most of our core systems federate seamlessly and bi-directionally. This means that you can quite easily register and log in to a given service with the user account from another service or even invert that process (technically possible, not always advisable). But what is the next step in our evolution towards greater interoperability between our applications, services and systems?Identity and…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today