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
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).
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.
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.
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.