Multi-Cloud Security and Compliance: The Comprehensive Guide 2021

This is a comprehensive guide to cloud security and compliance in 2021.

If you work as a CISO, Enterprise Architect, Cloud (Security) Architect, in DevOps or you are just interested in cloud security, this guide is for you.

In this new guide you will learn:

  • What cloud security and compliance is
  • Who the stakeholders are – inside and outside of your organization
  • What threats jeopardize your cloud environment
  • How to address security challenges on an organizational and technical level
  • How to create a security concept that combines organizational and technical security aspects
  • How to improve the interface between central IT and compliance, governance and regulatory departments

If you want to dive deeper, this guide will go into more detail on:

  • The concept of shared responsibility
  • IAM and tenant isolation
  • Shadow IT
  • Best practices on landing zone configuration
  • Security specifics of AWS, GCP and Azure
  • Certifications like ISO 27001 or CSA


Chapter 1: Cloud Security and Compliance Fundamentals

Let’s get started with a chapter on the basics of cloud security and compliance.

Specifically, in this chapter we are going to cover why cloud security and compliance are extremely important!

This first chapter will also show what cloud security and compliance is.

Let’s dive right in!

What is Cloud Security?

Cloud security is a strategy and concept to protect cloud computing environments, applications and data. Important elements of cloud security are organizational and technical security, as well as an overarching strategy. Although it might never be possible to prevent every variety of attack – a well-designed cloud security strategy vastly reduces the risks to data, infrastructure and applications.

The CIA and Zero Trust in Information Security

In our case CIA has nothing to do with THE CIA - it stands for the three key components of information security: Confidentiality, availability and integrity.

Cloud security is no exemption - every security strategy should aim to achieve these goals.

Arguably the most relevant goal in current security considerations is integrity.

Today's enterprise IT architectures have become so complex, that traditional perimeter security thinking won’t get you very far any more. It is very probable that your organization has no clear picture of who is doing what within their enterprise IT.

That is a great threat to the integrity of data, applications and resources.

The modern approach to information and cloud security is the zero trust approach: Assume that your firewalls have been breached, assume that the enterprise network ist just as hostile as the internet - and construct your security strategy around that.

Here are the three guiding principles to the zero trust approach:

  1. Verify explicitly
  2. Use least privileged access
  3. Assume breach

Why is cloud security so important?

You can have the best applications and the most satisfied customers.

But what if sensitive data is exposed – due to misconfiguration?

Exposing sensitive customer data greatly reduces your customers trust and may result in churn.

What if an attacker gains access to your infrastructure? Imagine an airline that loses control of the airline app backend. Resulting downtime leaves customers unable to book flights and passengers unable to check-in.

Competitors that have access to your company secrets can pose an existential threat!

Those scenarios will cost reputation and in the end a lot of money:

According to a report from IBM and the Ponemon Institute the average costs of a data breach is just short of 4 million dollars.

High profile cases of cloud security incidents include Facebook, Capital One and Docker Hub.

What are the main cloud security risks?

Most cloud security incidents can be mapped to one of these 4 categories:

  • Data is exposed or leaked due to a lack of protection
  • An unauthorized user from outside the organization has access to internal data
  • An internal, authorized user has too much access to internal data
  • A malicious attack incapacitates cloud infrastructure

Cloud security measures aim at reducing the risks posed by these threats by protecting data, managing user authentication and access, and keeping resources and services running.

Infobox: Cloud computing vs. on-premise computing

"We wish for the same security measures and capabilities on-prem as they are available in the public clouds"

We hear this a lot when talking to our customers.

Cloud security risks can seem daunting. But they overlap a lot with traditional IT security risks. Cloud computing is often more secure than on-premises computing. Most cloud providers have more resources to implement comprehensive security concepts than individual businesses do, which lets cloud providers like Amazon, Microsoft or Google keep infrastructure up to date and patch vulnerabilities as soon as possible. For example, 3,500 security experts work on keeping Microsoft's Azure Service secure. Even the CIA decided to go all-in on the Cloud with a private AWS account.

How can you improve the security of your clouds?

Achieving a higher level of security in your clouds is done by a combination of organizational and technical measures.

To get an overview on the current state of your cloud governance capabilities, have a look at our cloud governance assessment.

Let’s have a look at what that means and what you need to take into account:

  • Shared responsibility
  • Stakeholders in your organization
  • Internal regulations
  • Identity and Access Management
  • Tenant Isolation
  • Shadow IT
  • Encryption at rest and in transit
  • Credential management
  • Network architecture
  • Monitoring
  • Audit logging
  • Regional restrictions
  • Landing zones
  • Transparency
  • Certification
  • Exit Strategy

And that is likely not an exhaustive list.

Luckily this guide covers all of these aspects and a few more!

Chapter 2: Shared responsibility and stakeholders

First of all: It is important to know who is responsible for what aspect of cloud security:

The cloud provider, cloud foundation or DevOps team in your company or - most importantly - yourself? To clarify ownership throughout your organization and enable the departments and teams concerned with aspects of cloud security is a vital process for implementing a cloud security concept and strategy.

This chapter will shed light on responsibilities and relevant shareholders.

Let’s get to know the people concerned with your cloud security!

What is behind the concept of shared responsibility?

A very basic concern in cloud security is preventing unauthorized physical access to the servers. Does that mean you have to lock server room doors at Amazon, Microsoft or Google? Of course not: The responsibility for all the different aspects of security is shared. You don’t have to worry about locked doors or even patching the underlying software of the clouds you use.

Example: Pooled Audit

However, there is another side of the coin. A lot of companies, especially in regulated environments, e.g. the financial services industry are required to ensure unrestricted audit rights, when they outsource material IT workloads. This means that they would have to provide access to the service provider’s premises, when conducting an audit. This had been a showstopper for a lot of organizations within the European Union. In 2017, pioneering companies like the “Deutsche Börse” initiated a new concept, called the “Collaborative Cloud Audit Group” that enables financial institutions to group together to perform such audits in order to reduce the effort on both sides, the cloud providers and the financial institutions.

In turn, that means that there are other areas, for which the cloud providers don’t take responsibility. For example:


  • How you set up your organizational structure, e.g. IAM processes
  • How you configure and secure your infrastructure, e.g. network setup, firewalls, load balancers
  • How you secure your applications  

A general rule is that the cloud provider is responsible for the security of the cloud, while you as their customer are responsible for the security in the cloud. However there are other aspects that affect the shared responsibility model, e.g. the service model you are using (Iaas/PaaS/SaaS).

Here is an example: If you use a SaaS service like Google Docs, you don't have to take care of the VM images or databases this application is running on. If you deploy your own MySQL cluster to AWS EC2 instances however, you are responsible to encrypt the connection via SSL or TLS.

Who are the stakeholders in the cloud security business?

Put simply, the providers are responsible for the security “of” the cloud- whereas you and your organization - as their customer - are responsible for the security “in” the cloud.

Let’s have a look at what that means in a little more detail as you’ll have to figure out how to distribute responsibilities within your organization as well.:

Provider: The provider usually makes sure that your infrastructure built within its platform is secure and reliable. This responsibility includes physical security of hosts, network and datacenter as well as the software security of storage, databases and networking.

CISO: The CISO cares about the information and data security of a whole organization. That includes - but is not limited to - the cloud. The CISO takes executive responsibility for security operations, data loss and fraud prevention, identity and access management and the overall security architecture.

SOCs: A SOC (Security Operations Center) is a central organizational unit that is responsible to protect IT infrastructure across the organization. Monitoring IT systems, identifying security risks and responding to security incidents when they occur are part of the team’s core responsibilities.

DevOps : DevOps teams are responsible for secure engineering, secure deployment and operations, availability management, backups, separation of duties and security evaluations.

Cloud Foundation: Most large organizations aim to transform their IT environment towards cloud-native technologies to achieve more agility in their software delivery. They often set up a dedicated team to manage cloud infrastructure and provide secure cloud environments to DevOps teams across the organization. These teams are often called "Cloud Center of Excellence" or "Cloud Foundation" as they lay the foundation for the use of cloud infrastructure. This foundation may cover security and compliance aspects and relieves DevOps teams from security or compliance requirements that are independent of the application, e.g. the geographic restriction of cloud data centers.

Chapter 3: Cloud Compliance

This guide has been talking about cloud security a lot without touching on the important topic of cloud compliance so far. The second your organization decides to move data and applications to the cloud compliance becomes a huge issue!

Time to take a look at what you need to know about compliance and regulations when it comes to the cloud.

What is cloud compliance?

The term cloud compliance refers to the need that cloud-delivered systems must be inline with internal and external regulations. A common example is the European General Data Protection Regulation (GDPR), which concerns virtually every organization. But there are also very specific regulations for example in the financial or healthcare sector that companies need to comply with. This compliance must be transparent and auditable for regulators.

Which rules are there for cloud compliance?

The first step towards achieving cloud compliance is to be aware of the standards and regulations that apply within your industry and specifically within your organization. Standards and regulations may apply to certain

  • Industries
  • Geographies

Depending on the relevance of your industry there may be different regulations in place. Here are some examples, however this list is not exhaustive.

  • KRITIS for critical infrastructure (national)
  • BAIT and VAIT (Supervisory Requirements for IT in Financial Institutions/Insurance Undertakings)  (national by the BaFin)
  • ISO/IEEC 2700x (international by the International Organization for Standardization and the International Electrotechnical Commission)

What happens if you fail to be compliant?

Organizations are made responsible to meet a large variety of regulations. Failing to meet these can result in fines and a negative impact on your trustworthiness and reputation.

A widely discussed example is the GDPR, which focuses on data protection and privacy. 

Even if your organization is based outside the EU – as long as you have business in the EU, GDPR compliance is required. The possible fines are enormous. According to the highest fines were due to insufficient technical and organizational measures to ensure information security. Marriott International was fined more than 110 million euros and British Airways almost twice that amount because of information security violations.

Cloud security and cloud compliance is a shared responsibility between cloud providers and organizations. In the past years, cloud providers have invested a lot in providing better transparency and better tools to be an eligible infrastructure provider, even for very sensitive industries or governments.

How do you stay compliant when working with the cloud?

A great challenge to staying compliant is the ever changing environment and requirements of internal and external regulations. That brings us to our list of 4 aspects you need to take into account:

  1. Be aware of regulations and guidelines
  2. Control access
  3. Classify the data and document, where it's at
  4. Encrypt the data you are entrusted with

But there is a lot more to ensuring continuous compliance - especially across multiple environments and vendors: With a declarative approach you can fully utilize the advantages the cloud offers by automating the efforts of enforcing your compliance policies across your multi-cloud environments.

Chapter 4: Organizational Security in Cloud Computing

Let's talk about organizational security.

This chapter will tell you what organizational security is. It will also show why it is an important part of any cloud security strategy. And if you want to learn about what aspects you should definitely consider for your organization - you came to the right place!

Let's go!

What is organizational security?

Organizational security is everything you do on an organizational (as opposed to technical) level to improve the security of your cloud.

How can you improve the organizational security level?

In this case you don't have to evaluate whose responsibility the measures for organizational security are depending on the cloud operating model: Organizational security is for everyone!

(Sidenote: Clear responsibilities are important! In that way an organization stays responsive during a security incident.)

  • Implementing principle of least privilege
  • Isolating tenants in a multi-tenant environment
  • Practicing the 4-eye-principle
  • Fighting shadow IT
  • Preventing accidental misconfiguration
  • Classification of data

What is the principle of least privilege

The principle of least privilege (PoLP) is the concept of granting access to only the resources that are absolutely necessary to do the assigned tasks. It is pretty similar to what you might know from movies about secret agents: They only know what is necessary to accomplish the mission: In that way they can't endanger the whole operation in case of failure.

But we're not the CIA or MI5 so let's see what the principle of least privilege means in terms of cloud security!

4 Tips to implement the principle of least privilege

From developer onboarding to long-term management of user and permission lifecycles, managing access to cloud infrastructure is complex and security-critical. Authorizations should be granted as sparingly as possible (principle of least privilege) in order to reduce security risks. At the same time, the productivity of developers should not be restricted by lacking access rights or tedious approval processes. A simple and transparent process for assigning access rights is therefore essential.

  1. Avoid excessive use of broad primitive roles
  2. Assign roles to groups, not individuals
  3. Reduce risk and control access to your project by using networking features
  4. Consider using managed platforms and services

Quarantine your applications and environments

A relatively easy but very important step in securing your cloud workloads is tenant isolation.

By that we mean 2 things:

  1. Every application needs to run in its own tenant.
  2. Different development environments, e.g. development, staging and production environments of each of your applications should run within their own tenant.

A common setup with our customers are three cloud tenants for every application you move to the cloud: Development, staging and production. The number of stages ranges from 2 up to 6, depending on the use case.

Let's have a look at a company that did not follow this principle – Tesla:

In 2018 security experts discovered that hackers gained access to Tesla's cloud resources. Not to steal company secrets but use them to mine crypto currencies. All of that happened on a tenant that was used for several applications and environments. That made it relatively easy for the attackers to hide their malware in the general activity on this tenant. It’s much harder to identify deviations of regular activity within a shared environment. One team responsible for a single app would probably have identified high expenses or unknown resources much earlier.

The dark truth about Shadow IT

According to a survey by the Cloud Security Alliance, only 8% of the CIOs believe they know about the secret digital infrastructure in their company. This shadow IT, or Stealth IT as it is more aptly referred to, hides from the radar of IT managers. Eco, the Association for the Internet Economy, asked 580 experts from German medium-sized companies for its IT security report - the result is clear and worrying: three quarters of those surveyed assume that a shadow IT exists in their company. Nearly 25% fear a "considerable extent".

Even without an actual security breach, shadow IT costs your organization money, right now. It is uncontrolled and may contain unnecessary workload, organization-wide discounts by the cloud providers, e.g. for reserved instances are not taken into account. There are examples of cloud costs being billed as travel expenses on company credit cards, making the controlling of cloud costs hardly possible.

Chapter 5: Technical Security in Cloud Computing

Now that we have covered the ins and outs of organizational security, let's turn to its even more powerful brother: Technical security!

This chapter will cover what technical security is when it comes to keeping your cloud secure.

You will learn about important aspects of technical security, like encryption at rest, credential management and audit logging.

What is technical security?

In the realm of IT – or in our case more specifically – cloud security, the term technical security refers to technical actions that can be taken to implement and enforce security measures.

How can you improve your technical security level?

Here's a list of aspects and concepts you definitely have to take into account when thinking about technical cloud security:

Once again, make sure you understand who is responsible for each aspect. The cloud service provider? If not, who in your organization is it?

  • Encryption
  • Credential management
  • Network architecture
  • Monitoring
  • Audit logging
  • Regional restrictions

Even if you make use of cloud-native service offers, you have to evaluate whether the service is compliant to your internal and external regulations. To give you an example: With AWS Key Management Service (KMS), AWS offers a managed service to generate encryption keys. Some organizations however, have the requirement to have exclusive control on their HSM (hardware security module, the device that manages digital keys and performs encryption and decryption functions), which isn’t fulfilled by the KMS service. To address this need AWS launched additional services for this specific use case.

Encryption at rest: Protecting data, even if it has been stolen

Simply put, data encryption is the process of translating one form of data into another form of data that unauthorized users can’t decrypt. For example, you saved a copy of a paid invoice on your server with a customer’s credit card information. You definitely don’t want that to fall into the wrong hands. By encrypting data at rest, you’re essentially converting your customer’s sensitive data into another form of data. This usually happens through an algorithm that makes it practically impossible for somebody without the encryption key to decode it. Only authorized personnel will have access to these files, thus ensuring that your data stays secure.

Encryption in transit: Get the armored vehicle for your data

Data that is being moved from one place to the other is vulnerable to attackers. Unencrypted data transfer puts this data at risk. To protect it against eavesdropping or a Man-in-the-Middle you need to enforce your defined encryption requirements. It’s also a good idea to authenticate the network communications using Transport Layer Security (TLS) or IPSec.

Credential management

Credential management is key to securing any kind of system: From the traffic on our roads, to the traffic in our data centers. The management of drivers licences and IT credentials have a lot in common. They both are:

  1. Generated,
  2. stored,
  3. backuped,
  4. used,
  5. audited,
  6. changed,
  7. and eventually revoked and deleted.

Those 7 aspects need to be taken in account when managing credentials. That’s about how far our little metaphor will get us here. Let’s dive into multi-cloud credential management:

When we say credentials, we mean passwords, tokens or keys that grant access to your workload. Manage credentials and authentication mechanisms in a way that reduces the risk of accidental or malicious use.

Here are a few tipps, tricks and best practices:

  • Define IAM configurations to meet your organizational, legal, and compliance requirements.
  • Integrate with the centralized federation provider of your organization to reduce complexity. In that way, all users are authenticated in a centralized place.
  • Enforce password requirements to protect against password attacks like rainbow tables or brute force.
  • Enforce multi-factor authentication (MFA) to provide an additional layer of access control.
  • Lock physical credentials away That includes hardware MFA tokens.
  • Rotate credentials regularly to avoid unauthorized use of old credentials.
  • Audit credentials from time to time.

Network architecture

Most organizations have a hybrid infrastructure, with parts in the cloud and parts on-premises. Sensitive data is often kept on-prem, for security reasons, but also because large amounts of data in the cloud lead to an immense lock-in effect, as it is very easy to get the data in there, but costly to take it out again. That's why a lot of applications running in the cloud need access to on-prem infrastructure.

All 3 public cloud providers offer Virtual Private Clouds (VPCs) that enable you to build virtual network topologies that you can fully control.

Here are some VPC Best-Practices to improve network security:

  • Use multiple availability zones for high availability
  • Use public subnets for external-facing resources and
  • Private subnets for internal resources
  • Use ACLs —> Access Control Lists to limit the traffic between components to the minimum

It can make sense to hand out new cloud tenants with standard network components already deployed (via Landing Zones) to relieve DevOps teams and avoid insecure configurations.

4 Tips for monitoring cloud security

Cloud Monitoring is another critical aspect of keeping your workloads secure. Correct monitoring will tell you if your cloud infrastructure functions as intended while minimizing the risk of data breaches.

To do that there are a few guidelines to follow:

  • Your monitoring tools need to be scalable to your growing cloud infrastructure and data volumes
  • Aim for constant and instant monitoring of new or modified components
  • Don't rely on what you get from you cloud service provider alone - you need transparency in every layer of your cloud infrastructure
  • Make sure you get enough context with your monitoring alerts to help you understand what is going on

You can and should monitor on different layers (e.g. network, application performance) and there are different tools for doing this. SIEM (Security Information and Event Management) tools collect data from various sources. They process this data to identify and report on security-related incidents and send out alerts whenever a potential risk has been identified.

Audit Logging

With audit logging you document changes applied to your cloud tenants: Has a new user been added to your AWS account? Were access rights granted in your Azure subscription? Or who logged in when and for how long into your Google Cloud Project?

Audit logs are an absolute necessity when it comes to cloud security and compliance! And there are three main reasons why:

  1. Compliance auditing: Audit logs are official records that can be used to prove compliance to an auditor.
  2. Security analysis: Audit logs let you trace malicious behaviour and potential attacks.
  3. Operational troubleshooting: Audit logs help you find what is wrong with your tenants.

Closing remarks to this topic: Disk space is cheap, there is absolutely no reason to not keep audit logs.

Infobox: The most common audit logging services

At AWS user activity and API usage can be tracked with AWS CloudTrail. CloudTrail stores event logs in the CloudTrail console, Amazon S3 buckets and (optionally) in Amazon CloudWatch logs.

Azure provides a whole barrage of logging, auditing and monitoring tools. Audit logs can be retrieved from the Azure Active Directory portal.

Google Cloud Platform offers Cloud Audit Logs, that maintain three audit logs for each project, folder and organization.

Regional Restrictions

Regional restrictions in the context of this guide are mainly a compliance concern that can be addressed technically. Many european companies want to, or need to, make sure that their data is stored on servers within EU jurisdiction. Same with managed services: They often need to be delivered from a certain geography. 

With AWS for example you can disable entire regions (that’s not possible with all of them) and set up IAM policies that restrict access to certain geographies.

Chapter 6: The combined approach to cloud security

Achieving security in all aspects of cloud computing is a multilayered quest for every organization. Single measures of organizational and technical security are important but not enough.

This chapter will discuss the overarching organizational and technical security measures you need to know about and implement within your organization.

Learn about metadata for applications, the danger of configuration drift and how landing zones greatly improve the security and compliance of your tenants.


Maintaining organizational metadata - or context information - for applications, such as Application IDs, cost centers or security contacts is a way to establish a connection between the organization and the actual implementation of the application and integrate cloud infrastructure to the surrounding IT landscape, including CMDBs (Configuration Management Databases), SIEMs or Accounting systems like SAP.

Let’s have a look at two examples:

  • Providing a cost center when creating a new cloud tenant enables cloud foundation teams or management systems like meshcloud to map the occuring cost of an application to the corresponding department.
  • SOCs scan infrastructure for vulnerabilities. If a vulnerability is detected, it is essential to know within which application the affected infrastructure is used and who is responsible for its security and therefore fixing the breach.

Declarative model vs. Workflow-centric approaches

We’ve almost reached the end. And by now it’s pretty clear that cloud security and compliance are a complex endeavour with many different technical and organizational aspects to take into account. The complexity increases, if you consider that all these aspects do not only have to be set up and implemented once, but for a heterogeneous application landscape throughout the application lifecycle. Looking at a longer term perspective this leads to a risk for a phenomenon called configuration drift.

What is configuration drift?

Configuration drift describes a deviation of configurations from their initial setup due to frequent changes in hardware and software.
Within a complex cloud landscape you’ll have to think about how to treat configuration drift, from detecting it, to managing and correcting it. 

Declarative model vs. Workflow-centric approach

A common way to speed up slow manual processes is to automate the workflow. So for example, instead of having an Azure Admin manually create and configure a subscription for a DevOps team, there will be a script automating the workflow to reduce the time needed. 

But what happens if the DevOps team lead goes ahead and changes the configuration to better suit the application’s needs? Right, configuration drift, and no one will be aware of it.

A superior approach is to define a desired state. To stick with the Azure example, this could be an Azure subscription with access permissions for a DevOps team lead and one of his team members. This desired state definition can be continuously compared to the actual state. If no subscription or permissions exist yet, they will be initially set up. If the DevOps team lead changes the configuration, this will be detected. If it is intended the desired state can be updated, if not the action can be undone to get back to the desired configuration.

Infobox: How vs. What

Workflow-centric approaches focus on “how” to achieve a desired outcome, while declarative approaches provide a clear definition of “what” is to be achieved. A declarative approach has the benefit that it enables a continuous validation of the actual state against the defined desired state (re-certification) and provides a single source of truth to avoid configuration drift.

Landing Zones

Configuring a new tenant to be secure and compliant can be quite the hassle – especially if you have to do a basic set of tasks over and over again. This is where landing zones come in. Landing zones allow to quickly set up a multi-tenant environment with a baseline of identity and access management, data security, governance and logging already in place.

The basic purpose of a landing zone is to build and secure the airport before an application lands in the cloud.

But landing zones are not "fire and forget": A proper landing zone lifecycle management is an important part to keep your environments secure and compliant.

The big cloud service providers have the concept of landing zones implemented in some way.

Exit Strategy

Moving your workloads to the cloud brings many advantages – like on demand infrastructure and elastically scalable services. While most cloud users love the feel of innovation and progress to it, many don't think too much about how to get out again – why would they? But having a solid exit strategy in place is essential! In some industries, like banking, it is a regulatory requirement, as stated in the EBA Guidelines on outsourcing arrangements. The goal of an exit strategy is to ensure business continuity under changing circumstances. What if the service provider terminates the contract? What if the services do not meet the defined quality standards? Being able to handle these scenarios without interrupting critical business functionality is part of a comprehensive cloud transformation strategy. 

So here are 4 aspects you will have to have an eye on when building your cloud exit strategy:

  1. Most importantly: Take inventory! Knowing your assets is essential. Exit strategies often apply to critical business functions only. So it’s important to know what you have running in which cloud – an up to date cloud inventory is of great help.
  2. Open-source infrastructure is key. Open-source infrastructure components like Kubernetes clusters or open-source databases can make a move between clouds much easier. The more proprietary services you use, the harder it will be to adapt your application to running in a new cloud environment.
  3. Go multi-cloud from the beginning. Contract negotiations between enterprises and cloud providers can take a while. It’s too late to start the process, when it’s actually time to move
  4. Watch out for organizational lock-in. Even if from a technical perspective your application can easily be moved to a different cloud provider, there’s more to it. If you are running cloud applications at scale, setting up the corresponding cloud environments transferring permissions and configurations comes with massive complexity. Use a centralized governance system like mehscloud to keep your organizational structures independent from specific providers.

To learn more about the meshcloud platform, please get in touch with our sales team or book a demo with one of our product experts. We're looking forward to getting in touch with you.

The Cloud Identity and Access Management Guide for 2021

This is a comprehensive overview of cloud identity and access management.

If you work as an Enterprise Architect, in a Cloud Foundation Team, in DevOps - or you're just interested in cloud identity and access management - this post is for you.

In this post you will learn:

  • What cloud identity and access management is
  • Why good cloud IAM is so important
  • The difference between authentication and authorization
  • The principle of least privilege
  • How identity federation works
  • How the big cloud service provider handle IAM

What is Identity and Access Management?

In the enterprise IT environment, IAM is all about managing the roles, access authorizations, and requirements of individual users. The core task is to assign a digital identity to an individual. Once created, this identity must be maintained, updated, and monitored throughout the entire lifecycle of a user.

Why is good Cloud Identity and Access Management so important?

Authentication identifies and verifies who you are. Authorization determines what an identity can access within a system once it has authenticated to it. The combination of a central identity, authentication, and authorization is a major pillar of cloud security. It enforces that only authorized people can access only those systems that are necessary to fulfill the tasks relevant to their role in the organization. On the other hand, it allows to audit changes in these systems and traces them back to specific people. A requirement getting more and more important when designing an identity and access management system for your organization is to have efficient processes in place so your team can focus on their actual work.

Authentication vs. Authorization

Let's start by looking at authentication:

The authentication process consists of two parts of information:

The first part of this process is to define who you are, effectively presenting your identity. An example of this would be your login username to your AWS account or environment.

The second part of the authentication process is to verify that you are who you say you are in the first step. This is achieved by providing additional information which should be kept private and secret for security purposes. However, this private information does not have to be a unique value within the system. In the AWS example, you provide your identity in the form of a username to your AWS account, which will be a unique value. The next step is to verify that identity by providing a password.

Authorization deals with the question of what an authenticated user is allowed to do. So here, we are really looking at your access privileges, roles, and permissions.

The Principle of Least Privilege

The principle of least privilege (PoLP) is the concept of granting access to only the resources that are necessary to do the assigned tasks. And within this access only granting the necessary permissions.

It is pretty similar to what you might know from movies about secret agents: They operate on a need-to-know basis to accomplish the mission - in that way they can't endanger the whole operation in case of failure.

4 Tips to implement the principle of least privilege

From developer onboarding to long-term management of user and permission lifecycles, managing access to cloud infrastructure is complex and security-critical. Authorizations should be granted as sparingly as possible (principle of least privilege) to reduce security risks. At the same time, the productivity of the teams should not be restricted by lacking access rights or tedious approval and login processes. A simple and transparent process for assigning access rights is therefore essential.

1. Restrict the use of broad primitive roles
The use of primitive roles generally grants more privileges than necessary. Use custom or pre-defined roles that are more specific, to limit access to the necessary minimum.

2. Assign roles to groups, not individuals
To keep the assignment of roles maintainable, assign them to groups rather than to individuals. This way you can make sure they don’t keep roles when moving to another job in the company or the group role changes.

3. Use networking features to control access
Configure resource and application connectivity following the same principle of least privilege to reduce the risk of unauthorized access. The permission to modify network configuration should only be granted to those directly responsible.

4. Consider using managed platforms and services
To limit your responsibilities for security configuration and maintenance of accounts and permissions you might consider using managed platforms and services.

Be Aware of Privilege Escalation

An important aspect to consider when designing processes in the field of identity and access management is privilege escalation. Privilege escalation describes the case where users with a limited set of permissions have the possibility (due to a bug or bad design) to change their own permissions and gain elevated access. When it comes to privilege escalation we distinguish between vertical and horizontal privilege escalation.

Vertical Privilege Escalation: A user obtains higher privileges (more permissions) than intended (e.g. write instead of read permissions)

Horizontal Privilege Escalation: A user obtains privilege to access more resources than intended.

Identity and Access Management in the Cloud

Compared to traditional environments, cloud environments are more dynamic as resources change frequently and so permissions do as well. Nevertheless, when it comes to cloud identity and access management the same requirements apply to any local environment. To get to an integral identity and access management, cloud IAM and on-premise IAM should not co-exist. Instead, they should be an integral part of the same approach.

To avoid heterogeneous solutions within individual cloud silos it has proven to be best practice to let a central cloud foundation team take over the basic governance of all clouds and thus also of the identity and access management across all clouds.

IAM integration is a requirement for most enterprise systems because you want people to have a single identity to ensure the lifecycle is managed. So cloud needs to be integrated and identities closely monitored as there is sensitive data in the cloud.

Five Common Challenges in Cloud IAM

1. Lack of agility
Existing processes don’t meet cloud-native requirements like self-service, immediate implementation, and scalability

2. Strictly regulated field
Identity and Access Management underlies strict regulation (Bafin requirements - PDF) and has established processes outside the cloud world, e.g. joiner/mover/leaver or segregation of duties

3. Missing transparency and risk of shadow IT
There is no cross-cloud overview on existing cloud tenants and related permissions. Undetected shadow IT is a real financial and security risk.

4. Lack of automation
Cloud projects are frequently changing dynamic environments and come with a great number of IAM objects that is impossible to manage manually

5. Complexity
Large complexity due to the use of multiple clouds, strict separation of environments, multiple roles, flexible teams

The Benefits of Identity Federation

Federated identity is where a third-party identity service vouches for the authenticity of your users – usually by confirming they’ve entered the correct username and password. Federated identity enables users to use their existing directory service credentials to get seamless access to cloud platforms. The gains of Identity Federation are:

1. Single-Sign-On (SSO)
Seamless access to applications with one set of credentials and authorization through a central identity provider like Microsoft's Active Directory Federation Service (ADFS).

2. Security
Multiple login credentials expose your organization to various risks, including the potential use of easy-to-crack passwords by users. Managing a single set of credentials provides convenience to employees and IT admins and helps in creating a strong, single password that can be rotated regularly.

3. Productivity
IT teams have to spend a lot of time helping users resolve login issues keeps both parties from doing actual work and solving actual problems.

Azure, AWS and GCP: Identity and Access Management Overview

The cloud providers each handle the topic of identity and access management a little differently.

Here is a little overview:


Azure Active Directory (Azure AD) is Microsoft’s cloud-based identity and access management service, which helps your employees sign in and access resources in:

  • External resources, such as Microsoft 365, the Azure portal, and thousands of other SaaS applications.
  • Internal resources, such as apps on your corporate network and intranet, along with any cloud apps developed by your own organization. For more information about creating a tenant for your organization, see Quickstart: Create a new tenant in Azure Active Directory.

Amazon Web Services

AWS Identity and Access Management (IAM) enables you to manage access to AWS services and resources securely. Using IAM, you can create and manage AWS users and groups, and use permissions to allow and deny their access to AWS resources.

IAM is a feature of your AWS account offered at no additional charge. You will be charged only for use of other AWS services by your users.

To get started using IAM, or if you have already registered with AWS, go to the AWS Management Console and get started with these IAM Best Practices.

Google Cloud Platform

Google Cloud Identity and Access Management let administrators authorize who can take action on specific resources, giving you full control and visibility to manage Google Cloud resources centrally. For enterprises with complex organizational structures, hundreds of workgroups, and many projects, Cloud IAM provides a unified view into security policy across your entire organization, with built-in auditing to ease compliance processes.

Leverage Cloud Identity, Google Cloud’s built-in managed identity to easily create or sync user accounts across applications and projects. It's easy to provision and manage users and groups, set up single sign-on, and configure two-factor authentication (2FA) directly from the Google Admin Console. You also get access to the Google Cloud Organization, which enables you to centrally manage projects via Resource Manager.

To learn more about the meshcloud platform, please get in touch with our sales team or book a demo with one of our product experts. We're looking forward to getting in touch with you.