Chapter 15: Implementing Identity and Access Management

In Chapter 4, Service Design for Multi-Cloud, we discussed governance in multi-cloud. In that chapter, we learned that everything and everyone has an identity in the cloud. It is the core principle of identity and access management in cloud. In this chapter, we will learn how we can manage identities and control their behavior by granting them specific roles that allow them to perform only those activities that are related to the primary job of an administrator. We will see that Role-Based Access Control (RBAC) is very important to keep our cloud environments secure. We will learn about authenticating and authorizing identities, how to deal with least privileged accounts, what eligible accounts are, and why a central depository is needed. We will learn how we can federate with Active Directory from Azure, AWS, and Google Cloud.

After this chapter, you will have a good understanding of technologies such as federation, single sign-on, multi-factor authentication, privileged access management, and Identity as a Service (IDaaS).

In this chapter, we're going to cover the following main topics:

• Understanding identity and access management
• Using a central identity store with Active Directory
• Designing access management across multi-cloud
• Exploring Privileged Access Management (PAM)
• Enabling account federation in multi-cloud

Understanding identity and access management

Identity and access management (IAM) is all about controlling access to IT systems that are critical to a business. A key element of IAM is Role-Based Access Control, RBAC for short. In an RBAC model, we define who is alleged to have access to systems, what their role is, and what they are allowed to do according to that role. An important principle of RBAC is least privilege, meaning that a system administrator will only get the rights assigned that are required to perform the job assigned. For example, a database administrator needs access to the database, but it's not very likely that they will need access to network switches too.

In this chapter, we will discuss concepts such as single sign-on (SSO), multi-factor authentication (MFA), and Privileged Access Management (PAM). Before we go into that, let's have a look at the basics of IAM. There are three layers that we have to consider in our architecture:

• Managed identities: In this book, we've written a number of times that in cloud environments, everything should be perceived as an identity. Identities must be known: users, systems, APIs – everything that communicates with components in your cloud environment and with people or systems in the outside world.
• Managed roles: Roles must be defined in our cloud environments and assigned to identities. This includes the process of adding, removing, and updating roles. This is not only valid for persons, but also for systems. A system is an identity and has a specific role: for instance, a domain controller or application server. Thus, system authorizations must be defined and access rights must be given to resources.
• Managed access: This is the definition of who and what are given appropriate levels of access. To use the example of the database administrator once more, a database administrator needs access to the database and not to a network switch. If the database resides in a specific virtual network within the cloud environment, the administrator may need access to that network as well. However, that access should be limited; it is only needed to get to the database. That must be defined in the role.

On all three layers, the principle of least privilege is valid and must be followed through to obtain maximum protection of (sensitive) data in systems. The following diagram shows the main principles and related services of IAM:

Figure 15.1 – Main principles of IAM

The next step is to define what an IAM system needs to do and what sort of tools it provides to control identities and access to our cloud systems.

Primarily, it needs to enable us to control identities. IAM should therefore contain a directory, basically a database that holds all identities. Typically, this directory contains the entities that will access the systems. Almost all enterprises use Active Directory (AD) as their central directory. AD uses objects. An object represents an entity and that can be a user or a computer. It also defines to which domain an object belongs.

Next, the IAM systems must be enabled to grant entities roles and the associated access. If a user is added and a role is assigned to that user, then the IAM system makes sure that access rights are provisioned to that user. Typically, roles and groups will be defined in the directory so that all that remains is to assign a user or object to that role or group. Access rights on the appropriate level are then automatically enabled. IAM should also facilitate a review process: only a few admins should have rights to add users to or remove users and objects from a directory. A user can request specific access, but they will always need a review and approval before rights are actually assigned. PAM and Privileged Identity Management (PIM) can be tools to define that process. We will explore these concepts in the next sections.

Using a central identity store with Active Directory

Before we get into Active Directory (AD) itself, it's important to understand that it should definitively not be confused with Azure Active Directory. The latter is an authentication service in Azure, whereas Active Directory really is a directory.

Understanding AD is not easy, but basic knowledge is necessary when talking about IAM. An enterprise should only have one central directory. Identities should only be kept in one place. That also comes with a risk: if the directory gets breached, an attacker will have access to all identities that exist within the enterprise. It's crucial that the directory and the IAM system is very secure and that directory data is extremely well protected. This is an area where tools such as Saviynt and CyberArk come in: they add an extra security layer on top of IAM.

Both Saviynt and CyberArk offer solutions that are deployed on top of IAM, providing vaults and a way to secure access to systems, for instance, by hashing passwords in encrypted vaults so that users actually don't see passwords, but get them provided by the tools. These tools can also record sessions of logging into systems to enable maximum visibility of activity in an environment, often referred to as an audit trail.

Let's get back to the identity store and AD. The term is very much associated with Microsoft, as it was developed by that company for Windows domain networks. In the meantime, it has become a widely accepted term for the concept itself. AD comprises basically two major components, which are both relevant in cloud environments. The first component is the directory itself; the second component is the domain services.

Domain services comprise a domain controller that authorizes and authenticates objects – users and computers – in a network. That network can be in a public cloud. It can also be a standalone network, but more often, the internal network of the enterprise is extended to a cloud. Extended may not be the right word, though. The enterprise on-premises network and cloud network(s) are merely connected or – it's even better to say – we connect the domains.

To be able to do that, domain controllers are needed in the public cloud. The domain controller makes sure that a specific part of the public cloud is now within our domain. For all of this, AD Federation Services can be used to federate the domain in the cloud with the directory that enterprises already have, commonly on-premises. The following diagram shows My Company X with the AD on-premises. There is an environment in a public cloud as well. That environment federates with the on-premises AD:

Figure 15.2 – Conceptual overview of AD federation

Microsoft AD uses Lightweight Directory Access Protocol (LDAP), Kerberos, and Domain Name Services for these services. LDAP enables authentication and storing data about objects and also applications. Kerberos is used to prove the identity of an object to another object that it communicates with. DNS enables the translation of IP addresses to domain names and vice versa.

This concludes the section about AD and how it's used as an identity store. The next section will explain how access to clouds is controlled.

Designing access management across multi-cloud

In the previous section, we learned that we need to have federation with AD in our public cloud environment. The next question is: how do we do that? Azure uses Azure Active Directory (AAD). Just as a reminder: AAD is not the same as AD. AAD is an authentication service in Azure, using AD as the directory. Microsoft positions AAD as IDaaS, something that we will explore in more detail in the last section of this chapter, Enabling account federation in multi-cloud. The primary function of AAD is to synchronize identities to the cloud – Azure – using the existing AD. For the synchronization, it uses Azure AD Connect.

With AAD, enterprises will have a system that provides employees of these enterprises with a mechanism to log in and access resources on different platforms. That can be resources in Azure itself or resources such as applications hosted on systems in the corporate network.

But AAD also provides access to SaaS solutions such as Office365 and applications that can integrate with Azure. AAD makes sure that users only have to log in once using SSO. It's secured by MFA, meaning that when a user logs in by typing in a password, it is not enough. A second validation is needed to prove their identity. This can be a pin code through a text message or an authenticator app on a mobile device, but also a fingerprint. If the user is authenticated, access is granted to federated services.

The federation between the domains in the corporate network and the corporate domain in Azure cloud is done with Active Directory Federation Services (ADFS). In the cloud, a corporate cloud domain is situated on the domain of the public cloud itself. In Azure, that is defined by onmicrosoft.com: this domain name address signifies that an environment resides in Azure.

Now, if we have company X, which has its domain specified as companyx.com and it wants to have an environment in Azure, the domain in Azure would probably be company.onmicrosoft.com. Next, trust must be established between the corporate domain and the domain in Azure with ADFS. AD federation in Azure is shown in Figure 15.2.

The good news is that it works exactly the same in AWS and GCP. In AWS, ADFS can be enabled as a component of the AWS Federated Authentication service. With ADFS, a user is authenticated against the central identity store, AD. After authentication, ADFS returns an assertion – a statement – that permits the logging into AWS using AWS Security Token Service (STS). STS returns temporary credentials based on AssumeRoleWithSAML, which next allows access to the AWS Management Console of the enterprise environments in AWS. The following diagram shows the concept:

Figure 15.3 – Concept of AWS federated authentication

AssumeRoleWithSAML is something specific to AWS. This function in STS is providing a way to authenticate against the identity store with role-based AWS access. It uses Security Assertion Markup Language (SAML), an open standard for exchanging authentication and authorization data between parties, such as the identity store at a corporate level and the cloud provider. Yes, it's comparable to LDAP, but SAML is more commonly used in the cloud.

Also, GCP embraces SAML to do AD federation. At GCP, it starts with Google Cloud Identity, the service that GCP uses for IAM. But Google also understands that enterprises typically already have an identity store with AD. We can set up federation between GCP's Cloud Identity or G Suite and enable user provisioning from AD, including SSO. SSO is done through SAML.

For the actual federation, we use Google Cloud Directory Sync, a free service from Google. The concept is shown in the following diagram:

Figure 15.4 – Concept of Google Directory Sync

In all of these concepts, it's important to understand how the corporate AD is set up. This set up needs to be mapped to the IAM policies in the cloud platform. AD has a logical division with forests, trees, domains, and organizational units. Forests are the top-level segment of an AD and contain the root-level domain. Objects such as computers and users are grouped in domains. A group of domains forms a tree. Domains and trees within one forest trust each other.

In a public cloud, this division of forests, trees, and domains might not map by default to the structure that a public cloud has. Using GCP as an example, organizations are the container boundaries that hold the resources within GCP. Organizations contain all the projects that can be hierarchically subdivided into folders. These structures have to be mapped to the AD structure, otherwise federation will fail, leading to objects and users that can't authenticate nor have access to specific resources in cloud environments.

It's beyond the scope of this book to do a deep dive of AD, but in the Further reading section, we've listed literature that provides more in-depth insights.

Exploring Privileged Access Management (PAM)

In previous sections, the principle of least privilege was introduced: users only get the minimum set of rights to the systems that they are authorized for/require. Least privilege works with non-privileged accounts or least-privileged user accounts (LUA). Typically, there are two types of LUA:

• Standard user accounts
• Guest user accounts

Both types of accounts are very limited in terms of user rights.

There are situations where these accounts simply aren't sufficient and inhibit people from trying to do their job. The user would then need elevated rights: rights that are temporarily assigned so that the user can continue with their work. An account with such elevated rights is called a privileged account. Examples of privileged accounts are the following:

• Domain administrative accounts: Accessing all resources in the domain
• AD accounts: Accessing AD with rights to, for example, add or remove identities
• Application accounts: Accessing applications and databases to run, for example, batch jobs or execute scripts

A special category would be the break glass accounts, sometimes referred to as emergency accounts. These are accounts that function as a last resort when users are completely locked out of an environment. The break glass account is an account that has access to all resources and has all the rights to literally unlock the environments again.

The issue with these accounts is that they form a much bigger risk than standard, non-privileged accounts. If privileged accounts get breached, a hacker can have control over critical systems and functions. PAM is a solution that mitigates these risks. In short, PAM makes sure that elevated rights can only be used by specified accounts for specific systems at a specified time and for specified reasons.

The principle behind this is called just-in-time and just enough administration. In this principle, an administrator can decide that specific users need certain privileges to perform tasks on systems. But these users will not get these privileges permanently; that would be a violation of the least privilege principle. These users will get eligible accounts, meaning that when a user needs to perform a certain task, the rights to do so will be elevated. To enable the eligible account, the user will need permission that expires after a pre-set time window.

So, the user requests permission to enable the elevated rights from the privileged account. Permission is granted for one, two, or the number of hours that are needed to perform the tasks. After the time has expired, the rights are automatically withdrawn.

PAM on cloud platforms

How does this work on cloud platforms? PAM only works if the principle of least privilege is applied: what privileged accounts are needed, and what roles they will have. The cloud platforms all have an extensive role-based model that can be applied, enabling execution at a granular access level with separation of duties for resources.

Cloud providers work with only a few built-in general role types: roles that can do everything in the cloud tenant, roles that can do specific things in certain areas of the tenant, and roles that can only view things. In addition to those, there's often a role for the purpose of adding users and roles in the tenant. That's not sufficient for a role-based access model that requires more granularity. Cloud providers provide that and have roles specifically for network administrators, database administrators, or even very particular roles just for managing the backups of specific websites.

With a clear overview of our accounts and the roles that these accounts have, PAM can be configured in cloud environments. Azure offers PIM as their solution to identify and set eligible accounts. Be aware that this requires a premium license for AD in Azure. PIM sets eligible accounts, activates JIT, and configures MFA.

In AWS, PAM features are included in the IAM solution. Like Azure, AWS offers a role-based access model and the possibilities of having privileged accounts, using elevated rights, SSO, and MFA. The logic starts with requests being denied by default, except for the root account, which has full access. There must be an explicit allow in an identity or resource policy that overrides the default policy. If these policies exist and are validated, then access is allowed. AWS IAM checks every policy that is connected to the request.

As with many other services on their platform, AWS allows third parties to provide solutions on top of the native technology – in this case, AWS IAM. Both Saviynt and CyberArk are two vendors among the third parties that have developed PAM solutions for AWS.

Lastly, we will look at GCP. GCP offers cloud identities and, like the other clouds, a model for role-based access. One particular feature that needs mentioning here is Recommender. This feature provides usage recommendations to optimize GCP environments, but it also comprises tools to manage IAM in GCP. IAM Recommender automatically detects identities that may lead to security risks and can even remove unwanted access to resources. It uses smart access control.

From the Google Cloud console, the IAM page lists all accounts and the permissions that these accounts have. IAM Recommender displays the number of unused permissions over the past 90 days and will make recommendations, such as to replace the role with an account with a predefined role in Cloud Identity or to create a custom role with the appropriate rights. By doing so, we enforce least privilege in GCP.

Enabling account federation in multi-cloud

We saw in Chapter 2, Business Acceleration Using a Multi-Cloud Strategy, that businesses are shifting more and more from software to services. Companies are looking more to adopt SaaS solutions. Typically, a user would have to log in to separate SaaS solutions, since these are provisioned from a service provider. The risk is that users create new passwords to log in to SaaS solutions. It's easy to lose control of who has access to what. This can be solved through SSO, but the directories of SaaS solutions or web applications need to be federated in that case.

In the field of account federation, Okta has become an increasingly popular IAM solution in recent years. To avoid confusion, it's not an alternative to AD. AD is typically the primary, central directory; Okta is a solution that utilizes AD and takes care of the federation to web applications using single sign-on (SSO). That's what Okta does: it enables IAM with SSO on top of AD.

This is also referred to as an IDaaS solution – a cloud-based service that enables cross-cloud authentication. This is a third-party solution that manages the identities of an enterprise and offers features such as MFA and SSO. These solutions will still need a central directory, though. IDaaS can federate with the existing AD or companies can use a central directory from the IDaaS provider. With the latter option, companies can achieve savings, since they won't be needing on-premises servers and software to host the directory themselves. The diagram shows the high-level concept of IDaaS, enabling authentication and SSO to different SaaS services from one directory:

Figure 15.5 – High-level concept of IDaaS

To be clear, doing so will move all identities fully to the cloud. It's really a decision for the Chief Information Security Officer (CISO) or Chief Information Officer (CIO) to adopt this shift.

Enterprises will need federation using cloud solutions, though. Companies tend to have complex IT environments comprising on-premises systems, IaaS, PaaS, and SaaS. To be able to connect everything, as it were, all in one domain, federation is required. An IDaaS solution can be a valuable option to connect the existing AD to all these different solutions and enable secure access management to them.

Summary

Security starts with IAM: making sure that we have control over who's accessing our environments and what they are allowed to do in systems. In this chapter, we have learned what identities are and that we need a central identity store. From this identity store, we have to federate between the different cloud solutions that an enterprise has. We have learned how we can set up federation and how IDaaS can be a good solution for this.

We've studied concepts of authorization and authentication in the major cloud platforms. An important concept is least privilege. After this chapter, you should be able to make a distinction between standard accounts and privileged accounts. Lastly, we have learned what benefits PAM can have in securing access to our clouds.

The reason to have our cloud environments maximally secured is to protect our data. We have studied identities, access management, and security policies to protect our infrastructure. In the next chapter, we will learn how we should define security policies to keep our data safe.

Questions

1. In IAM, we have three layers that we must consider to identify identities. Can you name them?
2. Both AWS and GCP use a specific protocol for authentication. What's that protocol?
3. If a standard account isn't sufficient, we can "promote" users temporarily with another account that holds more rights. How do we name these accounts?

Further reading

You can refer to Mastering Active Directory, by Dishan Francis, Packt Publishing, for more information on Active Directory.