Last week we discussed how the modern perimeter is often now considered to be digitally Identity-based. We laid out some fundamental concepts and terms, such as Identity Provider (IdP), Single Sign On (SSO), and Multi-Factor Authentication (MFA). While all of these are challenging to do in large enterprise organizations in their own right, they become exponentially more difficult when done in multi-cloud environments.
While multi-cloud is generally discussed in the context of Infrastructure-as-a-Service (IaaS), meaning typically AWS, Azure or GCP, the reality is most organizations are already multi-cloud. Most organizations are already using multiple cloud providers’ services for compute, storage, and more. Each of these services and consumption activities is associated with its own identities, permissions, authentication, and authorization activities.
Handling Permissions and Access Controls with Multi-Cloud
Even if we stick with the general definition of multi-cloud in the context of IaaS, handling IdPs, identities, permissions, and access control in the multi-cloud paradigm is a challenging endeavor. Based on data from the 2021 Verizon Data Breach Investigation Report (DBIR), upwards of 60% of data breaches involved some type of compromised credential. This puts IAM at the center of most data breaches and of course a key focus area for malicious actors.
Each Cloud Service Provider (CSP) has its own unique platform and features when it comes to accounts, permission, and access control. Rationalizing that across the various CSPs is difficult, especially for organizations just starting to build a level of cloud security maturity. Multi-cloud essentially creates scenarios where subjects are trying to access resources across cloud providers and service offerings.
Facilitating Access Across Cloud Environments
Two of the most common ways IAM is handled in multi-cloud involves either provisioning credentials in each cloud environment or utilizing Federation, as a method to facilitate access across cloud environments and their associated resources. You’re essentially creating a trust relationship between the IdPs of the respective CSPs. This method tends to be more secure and preferred because you minimize identity sprawl, whereas with the first method you would need to have credentials created in any CSP environment you’re operating in.
The Complications of Secrets & Multi-Cloud
Another factor complicating IAM in the cloud, which inevitably is more complex in multi-cloud environments is the handling of secrets. While this can include traditional things such as Usernames and Passwords, in cloud-native environments it is increasingly involving other forms of secrets as well such as API keys and personal access tokens—both of which can be compromised by malicious actors and utilized to conduct unauthorized activities in or across cloud environments.
These secrets can be inadvertently saved, stored, or distributed by developers in cloud-native environments working with things such as source code, container images, or Infrastructure-as-Code (IaC) manifests.
Experiencing Malicious Activity
Further complicating this is when the CSPs themselves experience malicious activity which can have a cascading effect across their supply chain of consumers, partners, and integrations. A good example of this would be the recent notification from GitHub, which notified victims that an unauthorized party downloaded private repository contents by using third-party OAuth tokens.
Organizations are also increasingly turning to solutions such as Identity-as-a-Service (IDaaS) providers such as Okta, although they have had their own recent concerning activities. IDaaS offerings can often serve as CSP agnostic options to facilitate access across cloud environments. Some organizations have also begun to adopt innovative workload identity solutions such as SPIFFE and SPIRE which aim to provide a universal identity control plane for distributed systems, such as multi-cloud environments.
Final Thoughts
As is evident from the conversation above, IAM in multi-cloud environments is a complex and technical endeavor. When you look at the historical reality that credentials are involved in over half of data breaches, most data breaches in the cloud are due to customer misconfigurations and upwards of 99% of cloud identities are overly-permissioned, you don’t need to be a fortune teller to place a bet on what the future looks like, and it’s not pretty.
Want more cybersecurity insights? Visit the Cybersecurity channel:
