IAM Challenges in the Public Cloud: Feeling the Pain Already?
The need for an IAM solution isn’t new, but the public cloud has introduced new complications for IT teams. We break down the IAM challenges that have arisen in the cloud era – and how to address them.
What does Identity and Access Management (IAM) for/in IT departments have in common with the song “All I Want For Christmas Is You” in shopping centers in December? Well, both are an integral part of the experience and you only enjoy them if you make money off it. It’s a pain for everyone else.
What is IAM? IAM is the security practice looking at concepts and tools for controlling and managing access to company resources such as laptops, servers, printers – and now also company assets in the public cloud. The frustrating point for managers is: Most IT organizations have invested in IAM in recent years. However, this evergreen topic resurrects again – this time in the context of the cloud. So, the question is: What’s different this time?
Let’s dig into what IAM challenges have arisen in the cloud era.
IAM and VMs in the Public Cloud
Most companies have a lot of IaaS workloads in the cloud. They run applications on Linux or Windows VMs. Obviously, the IAM solution must cover admin and non-admin users on these machines (Figure 1, #1). It looks straightforward, but there is a surprise.
Figure 1 -- Use cases of IAM in cloud computing
In the cloud, the VM creation process is radically different. In the on-prem world, larger organizations have dedicated server admin teams. They configure and deliver servers and VMs for and to application teams following strict procedures. In contrast, every (application) team can spin up their VM in the cloud – and stopping this self-service novelty is like advocating for horse-drawn carriages over cars. But when every engineer can create VMs, the IT department must ensure that all VMs are registered and integrated into a central IAM solution and a resource directory. Otherwise, an engineer might create and work only with local admin or user accounts – and if they are on holiday, nobody else can log in. Figure 2 illustrates how engineers can create a VM (only) with a local admin in the Microsoft Azure GUI. Afterward, they can do whatever they want on the VMs.
Figure 2 -- Creating a VM in Azure
Preventing non-IAM-managed VMs requires two concrete tasks:
The IAM integration must be part of the creation scripts and modules for VMs. It is probably a joint task for the IAM and the cloud platform teams.
The cloud platform must force engineers to only create VMs with these specific scripts and modules. At least the platform management must detect and report non-compliant VMs.
IAM and Applications on Cloud VMs
IT organizations run VMs in the cloud because applications run on these VMs. The applications have internal users (employees). Many also have external users, e.g., customers or partners. On this layer (Figure 1, #2), IAM requirements do not change when companies shift workloads from on-prem servers to cloud VMs or from one cloud provider to another. However, sophisticated cloud services might create headaches for software engineers. AWS Cogito or the GCP Identity Platform enable developers to add user and access management to their applications easily. The likely result: the defragmentation of customer and user management in a company.
The consequence of the defragmentation: Application frontends and company web portals require different passwords and reauthentication when customers or employees change between them. Just think of a Microsoft Word document that requires one password to start the editor, another for printing a text to the printer queue, and a third for renaming the file on the OS level before saving it.
Plus, there is GDPR to consider. The data protection office might not appreciate if one human has different representations in various applications and web portals rather than having one central user repository to which all applications and databases connect. Thus, enterprise architecture and user experience experts might be actively interested in preventing applications from incorporating these new IAM-related cloud services.
PaaS & Portal: The Implications for IAM
While VMs and applications bring little novelties to IAM, cloud portals and platform-as-a-service (PaaS), on the other hand, are a new IAM challenge. Cloud portals are web GUIs for managing complete cloud data centers (Figure 1, Ž). In these portals, engineers can configure networks, start VMs, or reconfigure PaaS services (Figure 1, ). Well-known PaaS services include the Azure CosmosDB database or the AWS S3 storage service, which have applications invoke and integrate via web service calls. Behind both visible phenomena – cloud portals and PaaS services – are the cloud providers’ management APIs. Engineers and applications submit their commands and access cloud resources via them. Obviously, managing cloud access to and from these APIs is a prime case for every IAM team.
When integrating public clouds into an existing IAM solution, IT professionals must consider two specifics: First, clouds have highly complex and large access rights models compared to nearly every other application. Second, cloud security engineers can define policies in the cloud or configure PaaS services that interfere with IAM rules. A simplistic example: If the engineer grants anonymous access to an Azure storage account for everyone on the internet, the IAM settings for this storage account might be of limited value.
Figure 3 provides an AWS example an Azure example. AWS offers a rustic user experience: An engineer writes a bucket policy that references users respectively principles in the AWS IAM. In Azure, engineers can define the database owner directly on the GUI by referencing the Microsoft Azure Active Directory (AAD). The AAD looks more sophisticated than the AWS IAM, but one fundamental problem is the same: Many companies have an on-premise IAM solution, and now they have an additional cloud-native IAM solution. Both worlds must come together, e.g., Microsoft AD Federation with AWS, to unify user and access management for all company platforms and simplify IAM integration.
Figure 3 -- Configuring access for AWS S3 with bucket policies (left) and Azure Database Server (right)
More poetic: There shall only be one IAM. IT organizations might believe they can handle the “little bit of IAM work” in one public cloud in addition to their current workload. This assumption falls apart when zooming out from a single cloud to a complex, cloud-heavy enterprise application landscape.
IAM and Cloudified Enterprise Architectures
Considering all the employee laptops, customers accessing your online shops via web browsers or mobile apps, and dozens or even thousands of servers in the data center, is IAM integration in the cloud not just another medium-sized IAM project, be it the AWS, GCP, or Azure cloud? Then, finally, you are done with IAM for the next decade! Aren’t you?
You bet not. That’s only one phase of the IAM challengs facing IT pros. First, CIOs and CTOs in medium and large enterprises can define one primary cloud provider. Still, teams might already run services and applications on other clouds. Chances are high that one or two other secondary cloud providers are already integral to your enterprise architecture. Second, M&A activities will diversify cloud estates in larger companies in the next few years and require integrating additional cloud environments with significant workloads. Third, there are “office clouds,” such as Office 365 and Google Workplace, to which many enterprises switch. Finally, standard software providers push their subscription-based software-as-a-service offerings. Salesforce, Dropbox, Zendesk, Slack, and GitHub are popular services in the business context, and more are yet to come. They all require a central IAM approach, guaranteeing work for IAM teams in the years to come.
It is objectively impossible to manage users, roles, and access rights separately for each cloud if there are five or ten SaaS business services and three clouds. Handling new joiners, employees who leave, or experts who have switch positions internally are all a nightmare without one consolidated view of users, roles, and resources. The rule is: Companies invest in single sign-on for user-friendliness and work effectiveness, but the centralization and consolation of users, roles, and resources in one IAM solution is a security necessity.
Figure 4 -- IAM challenges for enterprises with high cloud adoption
I want to conclude with good news for IAM specialists and not-so-good news for CISOs. IAM teams only integrate clouds and SaaS services into their IAM solution. A CISO, on the other hand, must worry about IAM challenges plus securing all these clouds and services – not to speak of the data and business-critical processes in them. So, Figure 4 visualizes potential IAM integration projects for the team and your CISO’s nightmare they are not aware of yet. For them, the horror of Halloween might arrive earlier this year than they expects!
About the Author
You May Also Like