3

Cloud Identity and Access Management

Enterprises need a seamless way to provide access for their users to applications and resources on multiple clouds. Identity and Access Management (IAM) is the core component for managing identity across a hybrid cloud. This has two important considerations to manage and solve:

• How to manage identity and access for users to cloud resources, services, and platforms, which is typically referred to as Cloud IAM.
• How to manage identity and access for users for cloud applications, often referred to as IAM for cloud applications

IAM deals with identifying a user and cloud resources and managing access to these resources for the user, based on policies. IAM provides fine-grained access control to cloud resources and services under specific conditions. IAM policies define and manage permissions for each user to specific resources. IAM goals are more business-aligned than technical components. Enterprises need a robust and mature IAM capability to keep their costs at a minimum and that can be swiftly changed based on business requirements. In this chapter, we will take a deep dive into the patterns and best practices for addressing identity and access for users, leveraging security services, tools, and technologies provided by the cloud.

Figure 3.1 – IAM patterns

As shown in Figure 3.1, from an operational perspective, IAM patterns are covered under the following areas in this chapter:

• User management
• Authentication
• Authorization
• Governance and administration

IAM applications extend these requirements to cloud applications and their users. This will be covered in the next chapter.

User management patterns

Within cloud environments, you need to plan for providing and managing access to different types of users and identities. Users of the cloud include the following:

• Admin users: This set is the group of administrative users that typically includes product owners, managers, and team leads of cloud applications. They also manage the other users involved in an application, such as the developers and operators. These users typically require complete access to the application and platform development environments. They also need visibility into each cloud user’s activity on the cloud. These user accounts are authorized to view sensitive information and execute actions that can have a wider impact. So, an increased level of protection, auditing, and governance is required for admin users.
• DevOps users: This set of users includes developers and operators, cloud application developers, and platform developers who create, maintain, and delete applications. Additionally, this type of user has the need to create and consume additional services from the cloud. These activities of this user set are also subject to audit, as they are typically authorized to read sensitive information and can update applications and data. So, the access of developers is restricted to only specific project areas or environments in the cloud, based on the requirements.
• Application users: These are users of cloud-hosted applications. These applications can be web or backend applications. Users could also include other applications or systems that consume APIs from the cloud. Depending on the user and the requirement, the identification and authentication model is selected. IAM for this set of users will be discussed in detail in the next chapter.

The user management patterns cover the problems, contexts, and solutions for the following key goals:

• Managing a user:
  • Single-user onboarding/self-registration
  • User provisioning
  • User de-provisioning
  • Options to manage user attributes and credentials
• Managing groups:
  • Bulk user onboarding
  • Group creation
  • Group deletion

It is also critical to protect cloud users from identity theft and privacy abuses, limiting the potential for and impact of a cyberattack, and streamlining numerous operational processes. Identity management is the process of managing information used to identify users. From a cloud user’s perspective, they would want to use a single identity and access any cloud resources for the development, deployment, or management of their applications on the cloud.

Registration pattern

We will look into the following example.

Problem

How do we onboard a new user to a cloud platform?

Context

This involves how to create or register users, individually or in bulk, to use the cloud and related resources. The stages under identity management include requests for onboarding, provisioning the identity, securing the approvals if needed, and propagating the identity to the target systems as needed. Communicating the various stages to the relevant parties through notifications is another key aspect to be addressed under identity management.

Solution

Before any user can access a cloud service or resources, they have to complete an onboarding or registration process. The following figure shows the pattern a user can use to register for cloud usage through a self-registration page:

Figure 3.2 – User self-registration

An individual cloud user, such as a developer working on a personal project or a small company, can self-register as a new user for the cloud through the registration page provided by the cloud provider. Then, they can use their ID to access cloud services and resources. The registration process creates a user and associates them with an account. The user acknowledges the service agreements listed by the cloud provider. The cloud provider acknowledges the personal data collected and creates a new user. The credentials the user has shared can be used for subsequent logins to the cloud to use the service or access the resources, as shown in the following diagram:

Figure 3.3 – Admin-initiated invite and self-registration

Each cloud user will be associated with an account or organization as part of the onboarding process for billing, contracting, and support purposes. The owner of the account also needs to be created for user administration purposes. The account owner will have privileges to create other users for their account. As shown in the preceding diagram, an organization or account owner can create new users by specifying a temporary password. The user then receives the notification and has to complete the process, entering a permanent password and other attributes required to complete the registration.

Identity federation pattern

We will look into the following example.

Problem

How can an enterprise onboard several of its employees to the cloud?

Context

The self-registration pattern is not a feasible and scalable option to onboard a large number of employees to the cloud. Identity management is crucial to an organization, and it needs to be highly available and scalable, since identity is at the edge or the entry point to every application or microservice in the cloud. It can influence the productivity of your employees and the security of your organization.

The other key challenge is that the user life cycle management needs to be very dynamic. The user can change departments and be given new roles and responsibilities. If the user is transferred within the organization or leaves it, the access and permissions need to be reviewed and updated. The review might involve an approval workflow process, and the ID is suspended or deactivated on time.

Solution

Enterprises typically use an on-premises directory such as an active directory, Lightweight Directory Access Protocol (LDAP) directory, or cloud directory as a centralized identity store. Onboarding enterprise users in bulk to the cloud is achieved by connecting their internal or external user directory (an Identity Provider (IdP) directory) with the cloud. This pattern is called identity federation and is described in the following diagram:

Figure 3.4 – Identity federation

This pattern is supported by the underlying Security Assertion Markup Language (SAML) or OpenID Connect (OIDC) technical protocol. Federation enables single sign-on (SSO) to cloud accounts and applications. In this pattern, clients can use their own enterprise identity with an associated password to log in to the cloud. For enterprises, this makes it convenient to centrally manage federated access to multiple cloud accounts and business applications. In this model, they can also manage and assign access to cloud resources based on the group membership in the IdP directory.

Cloud identity pattern

We will look into the following example.

Problem

How do we manage the provisioning of users centrally across cloud and non-cloud environments?

Context

Certain organizations may not have a scalable user registry to support a federation pattern. In some cases, the directory might be fragmented across different departments or might not support underlying technical protocols for the identity federation pattern. Also, the existing user directory may not support user profiles centrally. The current implementation might store user profiles separately along with applications.

Solution

A cloud identity solution is used to implement automated user provisioning for cloud-based applications. This solution, also called Identity as a Service (IDaaS), enables enterprises to spend less on enterprise security by relying on a centralized directory to deal with the provisioning and management of users across cloud and on-premises applications. A cloud identity allows users to work from any location and any device, providing SSO with one set of credentials to multiple applications.

The benefits of a cloud identity solution or IDaaS include the following:

• A centralized identity management system that hosts user profiles and credentials, making it easy to manage access to applications at one place and having visibility through a single dashboard.
• Cloud identity is usually backed by cloud directory services that support the storage of user profiles and associated credentials in the cloud. The user details can be accessed through a LDAP and shared across applications or organizations.
• Cloud directory services securely manage user profiles and their associated credentials and password policy inside a cloud environment. A directory service within a cloud means that applications hosted on the cloud do not need to use their own user repository or existing (legacy) user repository.
• A cloud directory service facilitates the sharing of network capabilities with a complete spectrum of users for secure collaboration, such as a central identity hub for connecting with suppliers, partners, and customers. This pattern can be leveraged to create bulk users for the cloud. Cloud directory management APIs can be leveraged to bulk import users.
• Bringing in cloud scale availability and scale for identity management to cater to spikes or on-demand capacity to address new cloud projects.
• Most enterprise-grade IDaaS implementations come with 24/7 support and centralized monitoring of the infrastructure, with overall increased productivity.
• Quicker onboarding of new users and projects, especially when an enterprise acquires another company or when additional business units need to be onboarded to the cloud.
• User records can be provisioned by or to external identity repositories by using identity management feeds.
• Cloud identity solutions can interface with many types of identity repositories, such as Active Directory, LDAP v3, relational databases, SOAP services, a message queue, and SAP. As shown in the following diagram, users can be automatically added to, modified in, and deleted from cloud identity services through integration with these other identity repositories by defining an inbound connection. Users can also be added to, modified in, and deleted from external repositories by using an outbound connection, as shown in the following diagram:

Figure 3.5 – A cloud identity solution

• Configuration can be done to enable identity data or fed to include all or specific attributes, groups, roles, and account information, to flow between the identity repositories and a cloud identity solution.
• Automation is set up in the form of workflows or assembly lines that include actions configured to execute specific identity feeds.
• A cloud identity solution provides a full user and application life cycle by creating, updating, removing, or suspending user profiles.
• Accommodates full app life cycle management by enabling companies to add or remove applications from their organization in a central location.
• Cloud identity comes with provisioning connectors that create users on target cloud and third-party applications. We can synchronize all or a subset of users to one or more supported apps.
• There are multiple patterns for an on-premises or internal user directory with a cloud directory used by the cloud identity solution. Synchronization makes a copy of the ID and forwards it to cloud identity management. On a scheduled basis, changes in the directory are pushed from on-premises to the cloud. Note that synchronization alone does not support SSO but only replicates the identities from one repository to another.
• With synchronization alone, a user will have to log in again to access cloud services or applications. A cloud identity, with automated provisioning or federation of the identity to the cloud, can support SSO. With a workflow to push the identity to specific applications, the user needs to log in to the cloud identity and then can use SSO to sign in to cloud platforms.

User group management patterns

We will look into the following example.

Problem

How do we manage IAM for users as a group?

Context

Enterprises need an easy way to create a user group. They also need to manage the membership of that group, such as adding and removing users. The administrator of the group should be able to change and update the attributes of the group.

Solution

In this pattern, as shown in the following diagram, admins can add or remove users from a group. Group attributes, such as names and other details, can be modified:

Figure 3.6 – A user group

A group makes access management easier. Once a group is assigned to a role, all the users in the group get the same access privileges defined in the role.

Service accounts

We will look into the following example.

Problem

How do we create and maintain an identity for services and applications?

Context

Like users, applications or services require unique identification. Based on an identity, a cloud admin can allow or deny access to specific resources and services for an application.

Solution

This is achieved, as shown in the following figure, through the concept of service identity or a service account:

Figure 3.7 – A service account

A service account can be attached to any application or resource. Services IDs can also be added to a group, and one or more roles can be specified for that identity. An application or service uses this identity to interact with other applications, APIs, or services, or to invoke any API. A service identity replaces a user identity for application-to-service or service-to-service interactions. Typically, administrators and DevOps team members create the service ID as well as associated credentials, which are also referred to as the API key that is used for authentication.

User de-provisioning

We will look into the following example.

Problem

We need a robust and secure mechanism to remove a user’s access to cloud applications and resources.

Context

When a user leaves a company or switches their role, they need to be de-provisioned or their permissions to specific projects or resources should be immediately revoked. The administrator also needs to ensure that the user’s other identity-related details are removed, such as their password or login profile, access keys, Secure Shell (SSH) keys, and signing certificates, their multi-factor authentication (MFA) devices are deactivated, they are removed from groups, and their user profile is completely deleted.

Solution

Manual deletion or deactivation of a user can be done through an IAM console or by leveraging IAM APIs. As shown in the following diagram, user de-provisioning or removing cloud access for a user can be automated through integration with a cloud identity solution:

Figure 3.8 – User de-provisioning

The de-provisioning enterprise user workflow can be triggered from an HR system. This will ensure that cloud access to an employee who has left an organization is immediately removed. The process typically involves a workflow that takes approvals from the supervisors and different system owners. If the process isn’t automated, there is a greater chance of a step in the workflow being missed. The periodic auditing of this process is also an important aspect to remove any unused or dangling credentials.

Authentication patterns

Authentication is an IAM function that establishes an identity when attempting to access a cloud resource. Within hybrid environments, you need to plan for authenticating different types of users and identities. You need a way to uniquely identify and authenticate a user to allow them access to a cloud platform. An authentication solution should also be able to authenticate users based on a range of identity providers.

Authentication functions recognize a subset or combination of the following identity providers:

• A cloud directory
• A social identity provider (such as Google or Facebook)
• An enterprise-hosted identity provider
• A cloud-hosted identity provider

Once logged in or authenticated by an identity provider, a cloud user should be able to use the identity context (IAM token) to access cloud runtimes or services without having to log in again. This is also referred to as an SSO requirement.

Similarly, the cloud user may have multiple active sessions with services on the cloud. The solution should allow the user to log out from each session separately or log out from all sessions using a single page or by running a single command (single sign-off). Single sign-off is harder to achieve because of the various client agents through which a user could be accessing resources or applications.

The authentication solution needs to support multi-protocol to enable virtually any IT resource to connect in their “native” authentication language.

Logging in with user ID and credentials

We will look into the following example.

Problem

How can a user log in to the cloud and access any resource, runtime, or service using their user ID and password?

Context

With authentication, a cloud user can log in to the cloud with their user ID and password.

Solution

As shown in the following diagram, cloud IAM allows users to sign in to the cloud using their user ID and password. IAM users can use the console to create, change, or delete a password:

Figure 3.9 – Logging in with user ID/credentials

With the password, a user can sign in through the URL for their account.

The IAM administrator for an account can set the policies related to login, such as controlling how many times a user can try to log in before the account is locked. Also, as part of password policy management, the admin can enforce the need to have strong passwords that meet an organization’s compliance needs.

Application access key or API key

We will look into the following example.

Problem

How can a user log in to the cloud through a Command-Line Interface (CLI) or by leveraging APIs using their ID but also create different credentials for each application or tool?

Context

A user needs an application access key for use with a CLI or their application when their user account is created, or soon afterward. For better security, the access key should be issued for only a specific number of uses or for a defined time period and duration. Users also need the capability to rotate their application access key at regular intervals or any time they feel it has been compromised.

Solution

A cloud user can also create an access key that they use to log in to cloud-hosted services or applications. This is mainly a requirement when using a CLI or logging in to the cloud through an application with a user ID. In this pattern, the cloud supports requests from the user for an access key. As shown in the following diagram, the user can request an application access key or API key:

Figure 3.10 – Logging in with an API key

If a user wants to log in to the cloud through an app or command-line tools, then they can use an API key in place of a user ID and password.

SSH keys

We will look into the following example.

Problem

Users need a passwordless method to authenticate and log in to a cloud server from their client machines.

Context

Users need a safer authentication to the server, which is performed without passing a password over a network. If user IDs and passwords are shared over the internet, an enterprise runs the risk of interception by man-in-the-middle attacks.

Solution

Cloud users can generate SSH keys to authenticate and log in from their client machines to cloud servers or services. SSH keys help to identify an SSH server through public-key cryptography. The following diagram illustrates how a user uses an SSH key to log in to cloud IAM:

Figure 3.11 – Logging in with an SSH key

As shown in the preceding diagram, the steps involved are as follows:

1. Create an SSH key pair.
2. Upload a public key to the cloud.
3. Associate a public key with VMs.
4. Log in from a client using a private key.

The main advantage of SSH keys is that authentication to the server is performed without passing a password over a network. SSH keys prevent interception, man-in-the-middle attacks, or attempts to crack passwords through brute-force attacks.

Authentication with SSH keys adds additional IAM admin responsibility to keep track of active keys and their usage. If the keys are not deleted once a user leaves an enterprise or project, they can continue to access VM instances, which is a high-security risk.

SSO

We will look into the following example.

Problem

Once logged in, a cloud user needs to access other runtimes, services, or resources without having to log in again.

Context

Ideally, a user, once logged in to the cloud, should be able to access all services and resources that they have access to without having to re-enter credentials. With SSO, the cloud user can use one set of credentials to log in to multiple services and applications. This provides an improved user experience and helps in credential life cycle management, such as resetting a password and not having to remember passwords for multiple services.

Solution

SSO incorporates a federated-identity approach by using a single login and password to create an authentication token that can be accepted by multiple target applications. Once a user is authenticated through a centralized authentication server, SSO generates a browser-based encrypted session cookie. When the user logs into the cloud, cloud IAM checks for a valid session cookie. The user details are read from the valid session cookie, and the user is authenticated to the targeted cloud. The SSO pattern allows enterprises to enforce security policies in one place.

The following diagram shows how enterprise SSO facilitates the storage and transmission of user credentials to provide sign-in to the cloud:

Figure 3.12 – SSO

The SSO pattern uses a standards-based authentication model. These standards include SAML and OIDC. The same standards apply to SSO for cloud applications as well. These will be discussed in detail in the next chapter. SSO combined with multi-factor authentication lowers the risk of security breaches.

Multi-factor authentication

We will look into the following example.

Problem

How do we provide an additional layer of security for authentication in addition to credential-based authentication?

Context

Enterprises require this extra layer of security to protect logins to cloud-based applications and lower the risk of security breaches – that is, enterprises need to implement authentication with more than a username and password. The username and password-based authentication method is not a strong method, as passwords can be stolen or cracked using brute-force attacks.

MFA makes the method stronger, with steps that make it hard for hackers or criminals to get access to cloud services or resources.

Compared to credential-based authentication, MFA provides a better way to secure digital assets and transactions over the internet through an additional layer of security. MFA also helps organizations maintain compliance with authentication processes and procedures. The MFA authentication model is shown in the following diagram:

Figure 3.13 – MFA

MFA combines two of the following factors for authentication:

• Something you know: This could be a username and password
• Something you have: A mobile, USB, or a hardware security key or smart card to verify your identity
• Something you are: Biometrics data such as fingerprint, iris scan, or some other data that proves you are who you say you are

Adding this secondary factor to your username/password protects your privacy, and it’s remarkably easy for most people to set up.

Typically, a One-Time Password (OTP), CAPTCHAs, or patterns are used as the secondary authentication mechanism along with credentials. Many enterprises use time-based one-time-passwords (TOTPs). One widely used implementation of TOTP is the use of a virtual authenticator app such as the Google Authenticator app with smartphones.

The usage of security questions is an alternative method for providing MFA. In this pattern, a user fills out security questions from a predefined list and defines the answer. At the time of authentication, the predefined security questions appear on the login screen, and by providing the defined answer along with the credentials, the user is authenticated.

In this advanced model, clouds support MFA with a chip and Personal Identification Number (PIN), which is a conventional method for the authentication of financial transactions. This authentication mechanism can be used for machines/services in a network to log on to the cloud. The asymmetric encryption technology uses public and private keys to encrypt and decrypt data with a chip and PIN mechanism.

Single logout

We will look into the following example – a Single Logout (SLO) is a solution pattern that is difficult to achieve.

Problem

A cloud user signed into multiple active sessions or services in the cloud needs to have a way to log out from each session separately or through a single command.

Context

The user could be logged into multiple cloud services and applications. In the absence of SSO, the user needs to log out of these sessions separately.

Solution

The SLO pattern is supported by certain clouds. While the web-based connected cloud services can be logged out of through this pattern, the pre-requisite is that the cloud supports SSO integrated with an IdP.

As shown in the following diagram, a typical logout request follows your typical SAML message structure, with an ID, lifetime data, and information about its origin and destination:

Figure 3.14 – SLO

This pattern follows the following steps:

1. A user initiates the logout process by clicking on the cloud URL.
2. The cloud terminates the user’s session and triggers it by sending a logout request to the IdP.
3. Upon receiving a logout request, the IdP first identifies all connected cloud services that are part of the current session and performs the logout one by one.
4. After each connected service terminates the user’s session, the IdP terminates the user session and sends the logout response.
5. The logout response typically includes a status code that informs the end user whether SLO has completed entirely or partially.

Physical authentication pattern

We will look into the following example.

Problem

How do we enable only approved employees with a valid business justification with physical access to a data center?

Context

Physical authentication is used by cloud providers to authenticate users needing access to a data center. The physical security of data centers is important. The implementation and usage of physical security are subject to governance, compliance, and audit.

Solution

Only approved employees with valid business justification are granted access. The principle of least privilege is followed while processing such access requests. The access is provided only for a timed window to restricted areas and the individual’s activities are monitored. As shown in the following diagram, access cards (physical identity cards) and biometrics are used for authentication:

Figure 3.15 – Physical authentication

Biometric authentication is based on either fingerprint recognition, iris recognition, or face recognition, with one or more of those chosen. The physical security, implementation, usage, and governance policies of data centers are subject to compliance and audit.

Authorization patterns

The solution patterns for authorization are discussed in the following sections.

Access control pattern

We will look into the following example.

Problem

How do we control user access by determining their privileges and provide access to a heterogenous cloud environment consisting of services and resources?

Context

An administrator of a cloud for an enterprise should also be able to define common control rules and customize them as needed. There is also a need to enable granular access to specific cloud resources and services.

The problem to be solved is to authorize a user and provide specific access to cloud resources, services, and applications. The solution should manage access to cloud resources by different types of users as well as services.

The IAM administrator should be able to define and enforce security policies. The policy should apply the principle of least privilege, which gives users only the required permission to execute an intended action.

The solution needs to be able to grant fine-grained access control or a specific permission on specific services or resources for cloud users.

An effective authorization design should adhere to policy administration and offer an easy entitlement checking mechanism, for the enforcement point (such as a cloud service) to decide whether to provide access or not to a service or a resource that it manages.

Solution

Clouds achieve an authorization function by defining an access control model or pattern that consists of users, policy, and resources.

User and user group

As we already discussed in the user management patterns, there are different types of users for the cloud. Authorization needs to define the access control model for each type of user. Users can be either individuals or a group. Individual users can again be either a human user or a service account.

Policy

To define access for users and service accounts, you must create a policy that connects an identity to a resource by specifying one or more permissions for that identity. A set of such permissions is defined as a role.

So, a policy connects the user and resource through a role. A policy can specify a set of policy conditions under which access is allowed or denied for a user to a resource. The administrator who defines the policy can attach one or multiple policy conditions when the user is assigned a specific role for a cloud resource. A policy condition provides a way for access control decisions to be made based on a dynamically changing context, not just fixed rules. If a user is not assigned any role, the user does not have any privilege to access anything on the cloud.

Resource and resource groups

A resource is any cloud resource whose access needs to be managed by cloud IAM, which can be either infrastructure resources such as compute, storage, or networks, platform resources such as messaging, caching, or a data service, or application resources. A resource group is a group of related resources for a solution or a set that needs to be managed together. A cloud resource is uniquely identified by a cloud resource name. Clouds organize the resources in a hierarchy or inside a cloud account. A policy can be applied to a group of resources or at different hierarchical levels, and it is possible for resources to inherit policies.

The cloud access control model or pattern consists of three important elements, as discussed previously and shown in the following diagram:

Figure 3.16 – Access control pattern

A typical resource hierarchy defined by the clouds is given in the following diagram:

Figure 3.17 – The resource hierarchy

The resource hierarchy has multiple levels, starting with an enterprise or organization at the top. The next level is typically departments or organizational or management units. Some clouds also have the notion of account groups or folders at this level. Then, we have the account or projects level. From a cloud consumer perspective, each of these levels helps aggregate spending on cloud services and resources. This is mainly leveraged for billing and chargeback as well as rolling up the cloud expenses to the organization level. From an IAM perspective, the platform roles apply at the organization and account levels and are grouped under different areas. Services and related resources are created under an account or project. IAM access control provides cloud consumers with a single view of all the resources that a customer owns organized in a hierarchy, with access control applied to objects at each level.

Platform roles

A role is defined to specify exactly what actions (for example, create, read, update, or delete) can be performed on an object. Permissions defined at a cloud level or cloud platform level are called platform roles. Most clouds define predefined platform roles of owner, administrator, editor, operator, and viewer. An IAM administrator can select these predefined roles and assign them to any specific user or group. Platform roles or permissions are typically grouped into areas such as administration, IAM, billing, support, security, hardware, software, and network.

Service roles

Cloud services can define service-specific roles, such as reader, writer, and manager roles. For each object type, several default roles are defined to meet typical customer needs. Consistent role names are used across all cloud services, but each service still defines the exact actions for a role. Clouds also support the creation of “custom roles” to fit an enterprise’s specific needs by combining specific actions to be supported for a specific service or resource.

The cloud can leverage any of the following access control patterns to enforce a policy for a user or resource:

• Mandatory access control (MAC)
• Discretionary access control (DAC)
• Entitlement/task-based access control
• Role-based access control (RBAC)
• Attribute-based access control (ABAC)

A cloud service typically invokes a cloud IAM API to retrieve the entitlement (allowed actions) for a user. The entitlement information allows a service to make an access control decision on a request for access to a cloud service or resource.

Governance and administration patterns

Governance and administration patterns cover the operational aspects of identity management – specifically provisioning digital identities for the cloud and applications, securing them, and ensuring the processes are rightly governed to meet audit and compliance risks.

Identity governance and administration pattern

We will look into the following example.

Problem

Enterprises need a way to report and audit all the user activities in the cloud. This will include reporting across user management, authentication, and authorization functions. Identity governance is a key aspect of cloud security. Without this capability, a badly provisioned user or user entitlement can put entire enterprise cloud resources at risk.

Context

Enterprises need to have IAM reporting and governance because of the following reasons:

• Reporting helps gain higher visibility of users’ activities
• Analyzing IAM data helps to quickly identify possible security issues
• IAM reports help them to comply more effectively with audit and regulatory requirements

The key set of activities to be covered includes the following:

• User management reports:
  • User identities and group or role membership
  • A list of users with administration rights
  • Custom roles and users assigned more than default or special privileges
  • A user’s login and password policies
  • API keys, service accounts, and their usage
  • A list of restricted users and restrictions, such as cloud portal access from specific IP addresses – for example, a customer’s enterprise network
• A report on user credentials and authentication:
  • Listing all the credentials belonging to a user and their creation and update history.
  • A user’s authentication history, including when they were authenticated, how (using what credential), and the result of the authentication. The report should contain all the users, all the credentials of each user, and the authentication history of each user.
  • User accounts and a credentials audit report.
• A report on authorization and roles:
  • List all the users and objects (account, projects, services, and resources)
  • Admin can review when what access is provisioned for an user, all the actions that they can perform, and the history of when the access was granted through a role assignment
  • List the events related to entitlement retrieval and the policy decision events for specific or all users/cloud resources
  • Ensuring Separation of Duties (SoD) control, which prevents a user from having both the creation and approval rights for a task or ensuring that at least two individuals are responsible for a task
  • A review of the assignment of roles to users and service accounts across projects and resource groups – for example, a developer having access to multiple projects or both development and production environments

Solution

All clouds have an IAM console that provides an integrated portal through which consumers can control and manage access to cloud services and resources for their users. While IAM admins can manage a user’s permission on a cloud platform (platform roles) as well as role assignments for the services through a console, all the IAM management functions are available via an API. IAM provides a single dashboard through which consumers can get reports on users, authentication, and authorization. This pattern is discussed in the following figure:

Figure 3.18 – Resource hierarchy

The Who has access to what under what conditions? report is often required for audit and compliance. This can be requested through the IAM console or generated by leveraging the cloud IAM APIs. In the case of enterprises that use a cloud identity solution or have federated their internal identities to use the cloud, data is compiled from reports from the cloud as well as the cloud identity solution. Identity governance activities go beyond reporting to take automated administrative actions. These actions can include identifying, checking for compliance and violations, as well as rectifying any issues related to or arising from the following:

• Identity life cycle management
• Password or credentials management
• Enforcement of the least privilege principle
• Role modeling, harvesting, and management
• Policy enforcement and SoD
• Certification for continued access
• Review of IAM configuration and settings
• Analysis of activity logs and user behavior

Audit and compliance are areas of focus. Both the cloud provider and the cloud consumer are required to work together to prove to an auditor that the controls put in place meet an organization’s security policy. A risk officer can validate implemented controls for gaps from a regulatory and industry compliance perspective and report deviations. Compliance standards such as HIPAA, PCI/DSS, and NERC are mandatory for specific industries, and an automated report helps organizations efficiently demonstrate compliance to these standards.

Privilege Access Management (PAM) is used to lower a security risk and make compliance tasks easy by responding to critical aspects of any government or industry IT security regulation and providing proof of compliance for audit purposes.

PAM provides a central management console that enables quick, streamlined management of all users across multiple or disparate systems, including and especially hybrid cloud environments. PAM as a single point of control gains time, efficiency, and oversight over all privileged users active in a hybrid cloud environment. A PAM solution pattern generates an unalterable audit trail for any privileged operation, so the IT security team can track, view, or replay the actions of any privileged user.

IAM creates audit logs for all successful and unsuccessful authentication attempts by users. Logs are also created for privileged access to a cloud platform, services, and resources. Cloud providers use security information and event management (SIEM) to monitor and analyze logs and report any security incidents. They share the subset of their monitoring and audit reports with their clients, based on mutual contract agreements.

Known uses

The following table provides examples of each cloud IAM pattern and how it is implemented by different cloud service providers:

Table 3.1 – IAM patterns and known uses

Related patterns

IAM patterns for applications will be discussed in the next chapter.

Summary

In this chapter, we discussed IAM, which is the core component for managing identity across a hybrid cloud. We captured the important patterns for operationalizing IAM for users of a cloud platform. We included the key patterns for user management, authentication, authorization, governance, and administration.

In the next chapter, we shall discuss how to tackle the same problems and solution patterns to manage identity in cloud applications.