CompTIA Cloud+ CV0-003 Exam: Basics of Identity and Access Management

Objective: Given a scenario, configure identity and access management.
Security personnel spend a great deal of time ensuring that only authorized users are able to gain access to an organization’s cloud environment. This means that a high priority is placed on identity and access management, the process of verifying a user and ensuring that the user is provided with the correct level of access to the cloud services.
In this guide you will learn the essentials of identity and access management. This will include the concepts of privileged access management, account lifecycle management, and access control. You will also learn about directory services, federation, and multifactor authentication (MFA), key components to allowing users access to your cloud environment.
This guide will also discuss certificates, including providing an understanding of public key infrastructure (PKI) and key management.

Topics:
- Identification and Authorization
- Directory Services
- Federation
- Certificate Management
- Multifactor Authentication (MFA)
- Single Sign-On (SSO)
- Public Key Infrastructure (PKI)
- Secret Management
- Key Management

1. What types of identities can be assigned to a role?
2. True or false: A CA is a form of directory services.
3. Name a protocol that is associated with federation.
4. True or false: A valid factor for MFA is something that a person is.

1. User accounts and cloud resources (or instances)
2. False
3. SAML1.1, SAML2, OAuth2, OpenID Connect, WS-Trust, or WS-Federation
4. True

Identification and Authorization
Identification occurs when a user provides some sort of value, such as a username, to indicate who he or she is. By itself, identification isn’t enough to grant access to the system; the process of authentication must also be used. Authentication occurs when the user proves the identity by using another piece of information, such as a password or an access token.
After a user has been identified and authenticated, that user is granted access to resources within the system. When an authenticated user is either allowed or denied access to resources based on some sort of rule, this is the process of authorization.
In this section you will learn more about the process of identification and authorization. The chapter includes the various methods and techniques that are employed in a cloud environment to identify and authorize user accounts.

Before diving into different components of identification and authorization, you should be aware of a few terms that will be used:
- User account: Users in your organization (and, in many cases, customers) will need to log in to your cloud infrastructure or specific resources in your cloud infrastructure. This access typically requires each user to be assigned a unique user account.
- Roles: A role is a way to grant user accounts access to cloud resources. Most cloud environments also allow you to assign a cloud resource to a role. For example, you could add a virtual machine to a role that would allow the virtual machine to access a database resource. Roles relate to role-based access control (or RBAC).
- Groups: A group is a collection of user accounts. You can assign permissions to a group and manage which user accounts have these permissions by adding and removing user accounts to the group. A group may sound like a role, but there are some important differences. Only user accounts can be a member of a group (not cloud resources) and group assignment is normally directly tied with the user account, whereas a user (or resource) can temporarily take on a role to gain more access to another resource.

Privileged Access Management (PAM)
Through privileged access a user is granted rights that allow for escalated access to a resource. This access is not something granted to a regular user account in most cases but is reserved for individuals who need to have more administrative control over a resource.
Privileged access management (also referred to as PAM) is the process of administering the privileged access. The goal is to enforce a security principle called least privilege. This means providing only the access that an individual needs to perform the tasks that the user is responsible for.
A cloud-based example of PAM is the access provided to use and manage virtual machines. For instance, access to AWS EC2 instances are managed by AWS policies, like AmazonEC2FullAccess and AmazonEC2ReadOnlyAccess.
Note that for the Cloud+ exam you won’t be asked specific questions about how PAM is implemented on specific cloud environments, so this example is designed solely to enhance your understanding of this topic.

Logical Access Management
To understand the concept of logical access management (also called logical access control), first consider a related topic: traditional physical access management. An example of physical access management is requiring a person to have a key to enter a building, a room, or a storage container. To be able to access the storage container, which is placed in a room, a person would need a key for both the storage container and a key for the room. Of course, to enter the room, the person must also have a key to enter the building. As the manager of the building, you manage access to the objects by either providing or removing the keys.
Logical access management provides a similar methodology to providing access to cloud-based resources. You may have one method to authenticate when accessing the entire cloud infrastructure and additional authentication methods to access individual resources within the cloud infrastructure. As with physical keys, an administrator can manage this access by adding or removing the logical access method.

Account Lifecycle Management
The concept of account lifecycle management is that there should be systems in place to handle each of the primary stages of a user account. These stages are:
- Creation: This stage must include specific procedures for an account to be created. User data must be gathered, the account creation must be authorized using a system that prevents compromise, and the account privileges must be clearly defined.
- Updates: In some cases, a user account may need to be updated. If the user takes a new role in the organization, processes must be put in place to either grant more privileges or remove unnecessary privileges.
- Deactivation or deletion: When a person no longer needs an account—for example, the person leaves the organization—there must be a procedure in place to either deactivate or delete the account. For security reasons, many organizations choose to deactivate accounts because there may be the need to review the account at a later date. Additionally, a new user account may need the same type of account as the one being deactivated, so deleting the account is not advisable because the old account can then be used as a template to create the new account.

Provision and Deprovision Accounts
Provisioning an account means creating or activating the account. Deprovisioning an account is deactivating or deleting the account. Also see the preceding “Account Lifecycle Management” section.

Access Controls
Access controls allow user accounts to gain access to a resource in your cloud infrastructure. There are several different types of access controls that you should be aware of, including role-based, discretionary, nondiscretionary, mandatory, and rule-based. The rest of this section covers these different types of access controls.

Role-Based
With role-based access control (normally referred to as RBAC), users are assigned a role, which defines what a user is able to do. A role normally mirrors an organizational role. For example, you could have a role named “database administrator” that would provide an account with the privileges to perform administrative tasks on the databases within the organization.

There are several advantages of RBAC, including the following:
- An administrator can easily add a user to a role or remove a user from a role.
- Roles can normally be temporarily deactivated. Deactivating may be necessary when a security breach has made the system vulnerable.
- Roles can be modified. When this happens, all user accounts associated with the role are also immediately modified.

Discretionary
Discretionary access control (normally referred to as DAC) leaves the job of securing a resource to the user rather than the administrator. It is also related to the user account identity and the groups that the user account belongs to. With DAC, a resource (normally called an object when discussing DAC) is owned by a user account, and the user account decides who can access the object.
A common example of DAC is how file permissions work on Linux systems. Each file is owned by a user account and has three sets of permissions: the user owner of the file, the group owner of the file, and all other user accounts. The owner of the file can change any of these three sets of permissions to allow or deny access to the file.
The primary advantage of DAC is that regular users are granted more control and don’t need elevated privileges to change the access to resources that the user owns. The primary disadvantage of DAC is that regular users may not understand how the access control works and may unintentionally provide more access to an object than they intended.

Nondiscretionary
The method of nondiscretionary access control involves creating rules that govern which user accounts are provided access to resources. These rules can be associated with not only the user account but also other features like when the access is attempted and from where the user attempts the access. In other words, a nondiscretionary rule might state that a user can access a database only from 9 a.m. to 5 p.m., Monday through Friday, and only while logged in to a specific network.
Note that role-based access control (RBAC) and mandatory access control (MAC) are both considered nondiscretionary access control methods.

Mandatory
Mandatory access control is one of the highest forms of nondiscretionary access control. In systems that employ MAC, a policy is used to determine which accounts can access which resources. This policy defines identities, resources, and rules that determine which identities can access which resources.

Directory Services
In their simplest form, directory services are designed to store information about an organization or system. A simple but very powerful example of a directory service is Domain Name System (DNS), which stores IP addresses to host name mappings. When a user needs to access a system using an IP address but knows only the host name, a DNS server can be queried to look up the required information in its directory of information.

DNS doesn’t have anything to do with identity and access management, but it does serve to provide a simple example of a directory service as well as highlight some of the features of a directory service. Other features of a directory service normally include the following:
- Hierarchical naming model to provide the ability to segment different collections of data
- Robust search capability to enable for searching of items within the directory using different types of searches
- Distributed data model so not all the data needs to be stored on a single server
- The capability to replicate data to multiple servers to avoid a single point of failure
- Data stored in a way that optimizes reading the data, not writing the data, because data is read much more often in a directory service than it is written
- An extensible schema, which is a component of a directory service that defines what data can be stored in the directory service
Note that for identity and access management the directory service doesn’t, by itself, perform any identification or authorization functions. It can provide information that can be used to aid in these processes, but the directory service itself just provides information.

Lightweight Directory Access Protocol (LDAP)
LDAP is a protocol that is used by directory services that are typically used on Linux-based systems to store enterprisewide information, such as user account data. In relation to identity and access management, LDAP is one of the most commonly used directory service protocols. On Linux systems, OpenLDAP and Red Hat Directory Service are common directory services that utilize LDAP.
LDAP is also a key component of Microsoft’s Active Directory (AD) product. AD makes use of the protocol to provide controlled access to the data stored within AD.

Federation
You may have accessed an organization’s website and then been provided different methods of logging in to the system. For example, the figure below shows the login screen for developer.cisco.com.


Federation Login Example

As you can see, you can log in to developer.cisco.com using several different types of accounts, including GitHub, Google, and Facebook. None of these login methods are organizations that Cisco owns or has any control over. However, these organizations have provided a certain level of trust as well as a method to allow other organizations to have the capability to authenticate a user.
In a sense, GitHub, Google, and Facebook have become identity providers. They provide a service that organizations like Cisco can use to identify and authenticate users. This service provides Cisco’s customers with more options and prevents users from having to create yet another user account and password.
Several commonly used protocols are associated with federation identity management, including
- SAML1.1
- SAML2
- OAuth2
- OpenID Connect
- WS-Trust
- WS-Federation

Certificate Management
Consider a situation in which you want to log in to your bank’s website and transfer some money. You open a web browser, type in the URL of your bank (or use a browser bookmark), and then log in to the bank. But how do you know that it is really your bank?
It is possible that your browser has been directed to a website that isn’t your bank. This redirection may have been done by an individual or group that is trying to steal your login information to gain access to your bank account. You may have even seen this attempt in action. The figure below shows a message that your web browser will display if it appears that the server you are trying to connect to really isn’t the correct server.


Invalid Certificate Warning

This discussion brings up another question: how does your web browser know that you are potentially communicating with a rogue server? The answer is by its certificate.
When you communicate using the HTTPS protocol (note that this does not apply to HTTP; the S must be in the URL), your browser knows that it must verify the validity of the web server’s certificate. It does this by querying a certificate authority (CA), which is a trusted third-party organization that can look at a web server’s certificate and verify that it is really the correct web server. You can look at your browser’s settings and see a list of the CAs that your browser uses.


List of CAs on a Google Chrome Browser

You can find more details about the certificates and how they are managed in the “Public Key Infrastructure (PKI),” “Secret Management,” and “Key Management” sections later in this guide.

Multifactor Authentication (MFA)
MFA is a method of authenticating a user that requires more than one way of verifying the identity of that user. For example, a regular authentication method would be to have the user provide a username and a password. With MFA, the user would also be required to provide another item that proved the identity of that user.

The factor in MFA is the other item that is required to authenticate the user. This factor can be something from one of three categories:
- Something that the user has: This could be a physical object, such as a bank card, a physical key, or a USB stick that contains a unique token.
- Something that the user knows: This can be another password, a PIN, or some other bit of information that only the user should know.
- Something that the user is: This can include a biometric-based scan for a fingerprint, voice print, iris (eye), palm, and so on.

A newer category, somewhere the user is, has somewhat recently become a valid factor in MFA. This could be a factor that is verified by GPS, for example.
Another similar term that you may encounter is two-factor authentication. This is the simplest form of MFA because it requires only two factors to properly authenticate a user account. However, MFA in general can require more than two factors—for example, three factor with password, PIN from token, and fingerprint scan.

Single Sign-On (SSO)
SSO is a technique in which once a user has logged in to an environment, the user won’t be asked to provide the account credentials to access other components in the environment until a timeout period has been reached. For example, you may log in to your company’s cloud infrastructure and then access different elements of the cloud (database services, virtual machines, and so on) without being asked for your account information. After a period of time—for example, 12 hours—further access to this environment would require going through the authentication method again.
The primary advantage of SSO is that it makes it easier for the user to work in an environment without having to provide authentication information repeatedly across multiple internal sites or services. Disadvantages of SSO include the complexity of administrating the environment and the trust placed in users that they will physically secure the device that they used to access the environment. For example, if a user logs in to an environment that supports SSO and then loses control of the device (for example, someone steals the user’s mobile device), the attacker may gain unauthorized access to the environment for a period of time.

Security Assertion Markup Language (SAML)
SAML is the technology that allows for SSO. It is a standard that allows for exchanging data related to authentication and authorization between systems. Complete details of SAML are beyond the scope of the Cloud+ certification exam, but you should realize its purpose in enabling SSO within an infrastructure.

Public Key Infrastructure (PKI)
As mentioned in the “Certificate Management” section earlier in this guide, digital certificates are used to verify the identity of servers (primarily web servers, but other things can use certificates, such as VPN connections). Note that these certificates are also commonly called SSL/TLS certificates in context to HTTP services and functions, and they are based on the public key infrastructure (PKI).
PKI is a standard that defines how digital certificates are created, revoked, managed, stored, used, and distributed. It utilizes a pair of cryptographic keys (public and private), which not only allows the creation and verification of certificates but also provides a way to encrypt the data that is transported between the client and the server.

For the Cloud+ certification exam, you won’t need to know all of the details of PKI, but you will need to know some key terms:
- Digital certificate: A unique value that contains a collection of data that is used to identify an entity (that is, a server). For example, think of certificates in your browser store.
- CA: Certificate authority; an entity that validates, signs, and issues the digital certificates. For example, Verisign CA or GeoTrust CA are public CAs; also, an organization may have an internal Microsoft Root CA for certificate signing.
- Public key: A unique cryptographic key that is publicly shared. Data encrypted by the public key can be decrypted only by the corresponding private key.
- Private key: A unique cryptographic key that is never shared. It is used to decrypt data that was encrypted by the corresponding public key.
- CRL: Certificate revocation list; a list that defines the certificates that the CA no longer considers valid. For example, a certificate that was deemed to be no longer secure but is valid can be declared as void in the CRL.
- CSR: Certificate signing request; a request to a CA to generate a digital certificate. The CSR must contain specific information, including the public key for the organization, and must be “signed,” a process verifying that the organization making the CSR possessed the private key.

Secret Management
Secret management just means that you should have some secure means to protect your private keys. Doing so may include ensuring that your private keys are stored in folders or directories that are secured by passwords, but in a high security cloud environment, it will likely mean using a tool that stores this information.
Most cloud vendors provide the means to store private keys securely. For example, AWS offers a product called AWS Secrets Manager, Google offers Cloud Key Management, and Azure has Key Vault. Some third-party organizations also will allow you to store and manage your private keys, such as HashiCorp’s Vault and PKI Secrets Engine.
It is important to note that most of these tools not only store the private keys but also manage the process of creating and revoking the keys, which means they also manage the public keys for your organization. In other words, these tools help manage the certificate lifecycle.

Key Management
See the preceding “Secret Management” section.

Quiz:
1. Which of the following is not considered a part of the account lifecycle management? A.Creation B.Updates C.Verification D.Deactivation
2. _____ access control leaves the job of securing a resource to the user rather than the administrator. A.Role-based B.Discretionary C.Nondiscretionary D.Mandatory
3. Which of the following is not considered a feature of directory services? A.Hierarchical naming model B.Distributed data model C.Security enhanced model D.An extensible schema
4. Which of the following is considered a directory service? (Choose two.) A.DNS B.Federation C.Multifactor authentication D.LDAP
5. _____ is the protocol that allows for SSO. A.MFA B.LDAP C.SAML D.PKI

Answers:
1. Verification
2. Discretionary access control
3. Security enhanced model
4. DNS and LDAP
5. SAML