Don’t bore me with basics.

—Undisclosed system engineer

Someone actually said this as I was discussing the importance of proper identity and access management (IAM) for files stored in Amazon Web Services (AWS) S3. Some time later, it was discovered that this engineer’s company had leaked millions of customer records via an AWS S3 share that granted access to everyone in the world. Yes, IAM may be “basic,” but proper IAM is critical and cannot be dismissed.

As with all other security considerations in the cloud, IAM is a shared responsibility. As the customer, you are dependent on the provider for exposing robust controls not only for an identity service but also for entitlements and access controls (that is, identity, entitlement, and access, or IdEA). The most important concept you need to be familiar with regarding IAM in a cloud environment is federated identity. Federation will enable you to keep a consistent identity management approach across the multiple cloud platforms and services you use as a cloud consumer.

The cloud brings with it a need for changes to your existing IAM procedures with each provider, as each will have different controls exposed. You need to adopt these services with least privilege by design. IAM in the cloud requires a trust relationship between the customer and the provider and a clear understanding of the roles and responsibilities of each party.

Federation enables you to maintain control of authentication while delegating authorization to your CSPs based on your requirements. Cloud adoption of any significant size requires federation. Without federation, every user will require a user account in all services your organization uses.

This chapter focuses on the changes to IAM that have occurred as a result of using cloud services. Backgrounder information will take a deep dive into some of the standards covered in the CSA Guidance. As with all other backgrounders in this book, this information is included for your understanding of the technologies mentioned in the CSA Guidance; you won’t be tested on backgrounder information in the CCSK exam.

How IAM Works in the Cloud

Let’s begin this conversation with what doesn’t change with IAM in the cloud. You still have to map an entity (anything interacting with a system, such as a person, a system, or an agent) to an identity that has attributes (such as a group) and then make an access decision based on resulting permissions. You may know this process as role-based access control (RBAC). So, a user is a member of a group and therefore gets permission to use a resource.

Working with many providers brings complications with regard to IAM. Without something like federated IAM, you will ultimately have to manage dozens, if not hundreds, of different IAM systems. You may manage the settings in all these different locations to enforce IAM, but you will have to control this in environments that are owned and operated by a cloud provider, and what they expose to you may be limited.

From an operational perspective, you will have to create every user account not just once in your on-premises directory service (such as Active Directory), but dozens or hundreds of times. Who in your company is going to provision all these accounts? Worse yet, who is responsible for deprovisioning all these accounts? Consider a company that uses 100 Software as a Service (SaaS) products and is forced to lay off 1000 users in a cost-cutting measure. That’s 100,000 accounts that need to be disabled! How many people do you need to hire to do that?

Now consider the impact on your users in your environment. Your users have enough of a hard time remembering their corporate login details. Do you think they’ll be able to handle remembering 100 different passwords? One of two things will inevitably happen—they’ll use the same password in every SaaS system (not a great idea), or they’ll flood your help desk asking for password resets (also suboptimal).

With these scenarios alone, I’m sure you can see why federation is a must-have technology that is being forced on your company as a result of cloud. This is why the CSA Guidance says that IAM in the cloud is a “forcing function.” Wide-scale adoption of the cloud and the challenges faced from an IAM perspective will force companies to take action to address what will be (if it isn’t already) a significant pain point. Addressing this will likely require the adoption of federation.

On top of federation, adoption of the cloud gives your organization an opportunity to build new infrastructure and processes on modern architectures and standards used in cloud environments. I’ll be exploring some of these advancements and standards as part of this chapter.

IAM Terms

Many terms are associated with IAM, and they are not necessarily universal. Even the term “IAM” itself is not universal and is often referred to as “identity management” (IdM), or even “identity, entitlement, and access management” (IdEA). The following terms are used by the Cloud Security Alliance as part of the Guidance document. Remember them for your CCSK exam:

•   Entity Someone or something that has an identity.

•   Identity A unique expression of an entity within a given environment. For example, when you log onto a public web site, you usually do so with your e-mail address because this is globally unique. When you log into a work system, your username would be your identity.

•   Identifier A cryptographic token in a digital environment that identifies an identity (such as a user) to an application or service. Windows systems, for example, use a security identifier (SID) to identify users. In real life, an identifier could be a passport.

•   Attribute A facet (aspect) of an identity; anything about the identity and the connection itself. An attribute could be static (group membership, organizational unit) or highly dynamic (IP address used for your connection, your physical location). For example, if you log on with multifactor authentication, an attribute could be used to determine the permissions granted to your access (attribute-based access control).

•   Persona Your identity and attributes in a specific situation. You are you, but your persona will change based on context. For example, at work you may be an IT administrator; that’s your work persona. At home, your persona may be the parent of two children. In your hockey league, your persona may be the left winger and captain of your team. Your identity is who you are. Your persona takes context and attributes into account.

•   Role 1. A temporary credential that is inherited by a system within a cloud environment. 2. A part of federation; how your group membership within your company is granted entitlements in your Infrastructure as a Service (IaaS) provider. 3. The job you perform at work.

•   Authentication (Authn) The process of confirming your identity. Want to check into a hotel on a business trip? The first thing the front desk will ask for is your ID so they can authenticate that you are who you say you are. Of course in a digital world, we generally present a username and password to authenticate ourselves.

•   Multifactor authentication (MFA) The three factors in authentication: something you know, something you have, and something you are. For example, you may be authenticating with your username and password (something you know) and then be prompted for a time-based one-time password (TOTP) generated on your cell phone with Google Authenticator (something you have).

•   Access control A control that restricts access to a resource. This is the “access management” portion of IAM.

•   Accounting Logging and monitoring capabilities.

•   Authorization (Authz) The ability to allow an identity to do something. The hotel key you get after authorization allows you to access your room, the gym, laundry, and so on. In an IT analogy, you are authorized to access a file or system.

•   Entitlement The permissions you have to something. The CSA uses the term “entitlements” rather than “permissions,” but the meaning is the same. Entitlements determine what an identity is allowed to do by mapping an identity to an authorization. These can (and should) be documented as an entitlement matrix.

•   Single-sign-on (SSO) A token or ticket system used to authorize a user rather than having the user sign on to individual systems in a domain. Kerberos is an example of SSO in a Windows environment.

•   Federated identity management A key enabler of SSO across different systems that enables the action of authenticating locally and authorizing remotely.

•   Authoritative source The “root” source of an identity. A common example of this is a directory server (such as Active Directory). Alternatively, the payroll system could be the true authoritative source.

•   Identity provider The party that manages the identities and creates the identity assertions used in federation.

•   Relying party The system that consumes identity assertions from the identity provider. This is sometimes referred to as a “service provider.”

IAM Standards

There are numerous standards in the IAM world that you need to know about. I’m breaking this section into two parts: The first part covers what the CSA Guidance has to say on the standards, and the second part presents a series of backgrounders that will discuss each standard at a deeper level to improve your understanding.

For your CCSK exam, you may be tested on the following information regarding each standard:

•   Security Assertion Markup Language (SAML) This OASIS standard for federated identity management supports both authentication and authorization. Assertions are based on XML and are used between an identity provider and a relying party. These assertions can contain authentication, attribute, and authorization statements. SAML is widely supported by many cloud providers and many enterprise tools as a result. SAML is initially complex to configure.

•   OAuth This IETF authorization standard is widely used for web and consumer services. OAuth works over HTTP and is currently at version 2.0. There is no backward-compatibility between version 2.0 and its predecessor, OAuth 1.0. In fact, OAuth 2.0 is considered more of a framework and is less rigid than version 1.0. OAuth is most often used for delegating access control and authorization (delegated authorization) between services.

•   OpenID This standard for federated authentication is well supported for web services. Like OAuth, it runs over HTTP with URLs to identify identity providers. The current version is OpenID Connect 1.0 and is commonly seen in consumer services such as logging in to web sites.

The CSA Guidance mentions two other standards that aren’t as widely adopted. These are not discussed in a backgrounder because they won’t be commonly encountered. For your exam, just know that they exist:

•   eXtensible Access Control Markup Language (XACML) This is the standard for defining attribute-based access controls and authorizations. XACML is a policy language for defining access controls at a policy decision point (PDP) and passing them to a policy enforcement point (PEP). XACML can work with both SAML and OAuth, as it decides what an entity is allowed to do with a set of attributes as opposed to handling logins or delegation of authority.

•   System for Cross-domain Identity Management (SCIM) This standard deals with exchanging identity information between domains. It is used for provisioning and deprovisioning accounts in external systems and exchanging attribute information.

All of these standards can be used in federated identity systems. For the most part, all of them rely on a series of redirects that involve the web browser, the identity provider, and the relying party. Figure 12-1, from the CSA Guidance, denotes these redirections in effect by using OpenID as their example.

Figure 12-1   Federated identity example using OpenID. (Used with permission of Cloud Security Alliance.)

Federation involves both an identity provider and a relying party. Both of these components must have a trust relationship established to enable assertions from the identity provider to be consumed by the relying party. These assertions are used to exchange credentials.

For an example of federation in operation, consider a scenario of a user logging into a workstation and then accessing an internal web server that has a list of SaaS applications the user can log into. The user selects the desired SaaS application and is automatically logged on without having to provide a username and password. This is possible because the user’s identity provider will create an assertion and send that assertion to the relying party. The relying party will determine and implement the authorizations for the user based on the assertion that is created only after the trusted identity provider has authenticated the user. In other words, the local directory server authenticates the user and tells the relying party what authorization the user should have in the remote system. (For a more detailed understanding of how federation works, see the “Federation Backgrounder,” coming up next.)

Most, if not all, cloud providers will have their own IAM system, which may be referred to as “internal identities.” Your ability to have a federated identity relationship with a provider is dependent on the provider exposing some form of a federated identity connector. Although most providers expose some form of federation capability based on standards such as SAML, this is not always guaranteed (just like anything else offered by providers).

Providers may expose access to their IAM functionality using HTTP request signing. Although this was addressed back in Chapter 6, I’ll refresh your memory. HTTP request signing can use an access key as an identifier and a secret access key that is used to sign the request cryptographically. In the backend, the cloud provider will use their IAM system to determine the appropriate access controls that apply for the entity requesting to perform an action. This request signing may leverage standards such as SAML and/or OAuth, or it could use its own token mechanism.

As you consider which identity protocols to use, also consider the following from the CSA Guidance:

•   There is no “one-size-fits-all” standard when it comes to federation protocols. You have to consider the use case you’re trying to solve. Are you looking at users logging in via a web browser? You might want to look at SAML. Are you looking at delegated authorization? Then you might want to consider OAuth instead.

•   The key operating assumption should be that your identity is a perimeter in and of itself, and as such, any protocol used must be adequately secured to traverse the hostile network known as the public Internet.

Now that I have covered the basics as far as your CCSK exam is concerned, let’s dive a little deeper into federation itself and the protocols used to build federation between your organization and your cloud service providers. Again, as always, backgrounder information is for you, not for your CCSK exam.

Federation Backgrounder

Federated identity (federation) is the connection of two distinct organizations that have different internal structures using an agreed-upon standard. In this case, since we are dealing with identity management exclusively, I’ll just use the shorter term, federation. We are creating identity management that connects two distinct organizations using a standard such as SAML, OAuth, or OpenID Connect. The main reason why you would perform federated identity with a cloud service provider is to perform SSO. Wrapping all these key words together, when we talk about “federation,” we usually mean federated identity and SSO.

Federation isn’t just an option for companies that adopt cloud services; it’s a requirement. Without it, you’ll have mass confusion among your user base. Managing identities when using cloud services without federation is like herding cats—an impossible situation. And this goes beyond day-to-day identity management. Consider, for example, those times when managers need to confirm that their employees have appropriate privileges in accordance with their job functions. That’s already a difficult proposition, especially when you consider all of the locations where identities may exist internally. But what if you want to add dozens, or hundreds, of new identity stores? It’s simply an impossible task without federation. And then add in the problems created with various temporary users, such as contractors, who may continue to have access to your cloud services for years until discovered. I can’t overstate enough how much you are setting yourself up for massive failure regarding IAM if you don’t have federation in place.

As a consumer, the goal of federation is simply to authenticate your users locally and authorize them remotely. You are the identity provider (IP), and you manage all the accounts. The provider is the relying party (RP) (which is sometimes referred to as the service provider and may be denoted as RP/SP). Here’s the deal: You create the association between your identity provider and the cloud service provider in advance. How you do this depends on the provider and the protocol. Once that association is made, you can use assertions used by a protocol (usually SAML for users, but we’ll get to that later on). You generate the assertion (or token, if you will), and then that is consumed by the cloud provider. Because there is a pre-existing trusted association between you and the provider, the CSP will trust the assertion (assuming security checks within the assertion pass).

You can use internal Active Directory as an example of SSO that is made possible by Kerberos. In an Active Directory domain scenario, you log on (authenticate) in the morning with your username and password. When you successfully log on, your workstation receives a Kerberos ticket (there’s a whole bunch of mumbo-jumbo related to Kerberos, like ticket-granting tickets and such, but we don’t care about that—we care that we get some form of a ticket). When you go to access another server or any resources in the domain, are you asked for another logon? Nope. This is because your workstation automatically presents a Kerberos ticket on your behalf that says who you are (an identifier) and the groups (an attribute) that you are a member of. The resource server then looks up the access control list and determines what level of access you should have based on what your ticket says about you and your group memberships, or if you should be granted any access at all.

Alright, so now you may be asking yourself, why don’t we just use Kerberos instead of a different protocol to do our federation? Awesome question. The answer is that Kerberos doesn’t really work very well outside of the domain in which it’s set up. It’s an SSO solution for use within a domain, not a federation protocol for connectivity between different areas owned by different organizations.

How can federation be established with cloud providers? You can build your own connector (preferably standards-based), or you can use a broker that will make federation a little easier than doing it yourself. In this discussion, I’ll begin with the “roll-your-own” federation system then move on to cloud-based identity broker services.

Sticking with the Active Directory scenario, you could build your own federation connector by implementing Active Directory Federation Services (ADFS). ADFS is essentially a service installed on a domain controller. In addition to the ADFS implementation itself, you need to build a web server (such as IIS, Internet Information Services) and SQL servers (MSSQL). This drives up your costs significantly, because MSSQL is a pretty expensive license (and you need two of them to address one being a single point of failure). What’s pretty cool about this is that you could actually use ADFS in a cloud environment that supports Windows Server and even use it to connect to the SAML provider used by the IaaS system you’re using!

The web server needs to be built so your users can connect to the cloud services you have a federated connection with. Users would simply go to the internal web server, click the service they want to use, and, voila! They are automagically connected. Behind the scenes, the web browser uses an assertion that is in its memory. This assertion is consumed by the provider. Depending on the protocol used (likely SAML, since this is a user logging in with a browser), the identity and groups the user is a member of are read, groups are mapped to permissions on the provider side, and the user is authorized to access resources based on what the assertion says. The big deal here is that user accounts and passwords remain within your environment. An added bonus is that users have to log in to the system that you manage in order to get an assertion. If you disable the user’s account, you disable their access to all the cloud services with which you have federation implemented.

As for the usage of a cloud-based identity broker, all of the same principles discussed still exist, with the exception, of course, of having to build up your own infrastructure to support federation. So how, then, does this cloud-based system have access to the list of all of our users in our identity provider such as Active Directory? Well, this depends on the provider, but I’ve generally seen it happen in two ways: either copy your users from Active Directory to the identity broker, or install an agent in your domain. When someone wants to access a cloud service with which you have federation in place, they will connect to your cloud-based identity broker and log on there. Their username and password will then be sent down to the agent, and the agent in turn will check with your AD server to determine whether it’s a valid logon ID or not. If everything checks out, the user is presented with a screen showing the various federated links they can use. If you disable the account in Active Directory, the user cannot log on to the identity broker and can’t access any of your services.

Just a final note on using an identity broker: Always double-check to make sure the domain you’re installing this agent into and what risks this carries. If it’s implemented improperly, you could suddenly realize that you’ve accidentally opened up your Active Directory accounts to the outside world for brute-force attacks and other nasty surprises. You might even realize that you accidentally installed it in the production domain when you thought it was installed in development (it happens).

Now that you have a high-level understanding of the implementation of federation, let’s look at some of the enabling protocols, starting with the king of federation protocols—Security Assertion Markup Language.

Security Assertion Markup Language Backgrounder

SAML is the open standard protocol to use when you want to enable users to access cloud services using a web browser. Currently at version 2.0, SAML does both authorization and authentication. SAML has built-in security, but this doesn’t mean it’s a failsafe protocol (again, nothing is failsafe when it comes to security).

There are three components involved in SAML: The identity provider (your organization), aka IdP; the service provider (cloud provider), aka SP; and the principal (usually a human). SAML can be used in either an SP-initiated or an IdP-initiated scenario.

In an SP-initiated scenario, the user connects to the service in question and enters their e-mail address (identity). This is checked, and if there is a known SAML association, the user is redirected back to the IdP to get a token. When the token is passed to the workstation, it is then redirected back to the service and the token is presented. Figure 12-2, from the “OASIS Security Assertion Markup Language (SAML) V2.0 Technical Overview” document, demonstrates the steps involved with SP-initiated connections.

Figure 12-2   SP-initiated connection steps. (Source: OASIS.)

In the IdP-initiated scenario, the user goes to an internal web server, selects the desired service, and then gets a token and presents it to the desired service. Figure 12-3, from the same document, demonstrates the steps involved with IdP-initiated connections.

Figure 12-3   IdP-initiated connection steps. (Source: OASIS.)

Here’s an example of the some of the more interesting contents of a SAML assertion:

<saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>

<saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"> 3f7b3dcf-1674-4ecd-92c8-1544f346baf8

<saml:Conditions NotBefore="2004-12-05T09:17:05" NotOnOrAfter="2004-12-05T09:27:05">
<saml:AttributeValue xsi:type="xs:string">member</saml:AttributeValue>

From these strings, you can see the issuer (IdP) must be known to the relying party, the identity of the requestor (user) is always different (this is an option if so desired so usernames won’t be compromised if the assertion is intercepted), timestamps are used, and attributes are exchanged as part of the SAML assertion. Again, this is just some of the information and security within a SAML request. For a much more detailed explanation of SAML and all of its inner workings, consult the “OASIS Security Assertion Markup Language (SAML) V2.0 Technical Overview.”

In conclusion, SAML is primarily the standard that is used for users accessing a cloud provider with a web browser. So how do systems and mobile apps perform federation and SSO? That’s usually where OAuth and OpenID come in. Let’s look at those standards.

OAuth Backgrounder

OAuth is for the authorization (remember OAuth stands for AuthOrization) of users and systems. It is very lightweight in comparison to SAML and therefore is ideal for system-to-system communication over APIs using HTTP. Currently, version 2.0 is incompatible with OAuth 1.0.

The term “delegated authorization” has become fairly synonymous with OAuth. What does it mean in real life? Have you ever been to a web site that allows you to log on with Google, or Facebook, or LinkedIn, or myriad of other large web sites? When you do this, you are basically saying you want Google’s identity system to be the source from which you’ll be authorized to access the target web site. You don’t need a separate username and password to access the target site. You’ll click the Logon With Google button and you’ll be redirected back to Google to verify your wish to log on (and possibly share your information) to the target site. Once you click OK, you are redirected back to the target site and have access.

Here’s another example: Say you want to build an app called tweetermaster that schedules tweets for customers on a daily basis as the customer. In order for the tweetermaster app to post tweets on the customer’s behalf, it would have to be authorized by the user to be able to access Twitter and post on the user’s behalf. This is an example of how you could use OAuth for delegated authorization. In this scenario, you delegate authority to allow something do something on your behalf.

Figure 12-4, from the RFC 6749 documentation, demonstrates the delegated authorization flow with OAuth.

Figure 12-4    Delegated authorization with OAuth

OAuth has substantial use cases with APIs in both mobile and microservices implementations. OAuth 2.0 can use JSON Web Tokens (JWTs) as bearer tokens in an API environment. (When thinking of bearer tokens, you can think of the statement “give access to the bearer of this token.”) Figure 12-5 shows how JWTs can work with OAuth to allow access to resources.

Figure 12-5   JWTs usage in microservices

Finally, OAuth is related to OpenID in that OpenID Connect builds authentication on top of the authorization capability of OAuth. The next backgrounder will discuss OpenID and, more specifically, OpenID Connect (OIDC).

OpenID Connect Backgrounder

The latest version of the OpenID standard (version 3) is OpenID Connect (OIDC). Version 1.0 was released in 2005 and replaced with OpenID 2.0 in 2007. OIDC was released in 2014. As per the OIDC FAQ, the problem that OIDC solves is that it “lets app and site developers authenticate users without taking on the responsibility of storing and managing passwords in the face of an Internet that is well-populated with people trying to compromise your users’ accounts for their own gain.” In other words, the goal of OIDC is to centralize credentials used on a wide set of web sites to a smaller set of trusted identity providers.

OIDC is an authentication layer built on top of OAuth 2.0. This enables OIDC to address authentication and authorization requirements. OIDC is restricted to HTTP and uses JSON as a data format (OpenID 2.0 used XML). The addition of OIDC’s authentication layer on top of OAuth’s authorization capabilities allows for verification of the identity of an end user based on the authentication performed by an authorization server.

OIDC is an open identity standard backed by a number of significant companies such as Microsoft and Google, as well as agencies such as the National Institute of Standards and Technology (NIST) and other global governmental and nonprofit organizations. Apple has recently built its Sign In with Apple offering with OIDC.

With the creation of OIDC and its tight integration with OAuth 2.0, the lines are getting blurred as to the functionality that each standard brings. As long as you remember the following points, you’ll be able to make sense of all these competing standards:

•   SAML 2.0 does authentication and authorization for web users.

•   OAuth 2.0 does authorization and is lightweight.

•   OIDC 1.0 runs on top of OAuth 2.0 and provides lightweight identity and authentication services.

Managing Users and Identities for Cloud Computing

The identity part of identity and access management is all about registering, provisioning, propagating, managing, and finally deprovisioning identities. With those actions in mind, you probably shouldn’t be surprised to learn that identity management itself may actually be done outside of a directory service (such as Active Directory). The authoritative source of identities in your network may actually be the payroll system, for example: users are added to the payroll system, and their identities are then propagated to the directory server.

Thanks to these centralized directory services, it is no longer required to add accounts to every individual server and application in a traditional environment. Of course, users still have multiple accounts to support applications that are not integrated with these centralized directory services, so the dream of true SSO remains elusive, but there are, thankfully, fewer of these accounts than there used to be in the past.

In a cloud environment, both providers and consumers need to plan on how they will manage identities:

•   Cloud providers need to offer an identity service that supports customers to use their own identities, identifiers, and attributes. They should also offer federation services based on standards to enable customers to minimize the overhead associated with identity management when using their cloud offerings.

•   Cloud customers need to determine how they want to manage identities moving forward. This will require that customers determine the architecture models to use for identity management and the technologies that should be implemented to support integration with their current and future cloud providers.

As mentioned multiple times in this chapter, federation will be required as an enabling technology for cloud implementations of any substantial size. Without federation, you will lose control of IAM. This isn’t to say there won’t be any accounts created and managed in a provider’s internal IAM system. You will likely still have a limited amount of administrator accounts within the provider’s IAM system to support troubleshooting in the event of failure of the federated link, for instance.

To establish a federated link, the customer needs to determine what system will be the “authoritative source” to serve as the identity provider. This is usually a directory server. This identity provider then needs to perform the federation. There are two main approaches to creating this connectivity: use a free-form model that creates a separate connection between the identity provider and the various cloud services (as shown in Figure 12-6), or use the hybrid (hub-and-spoke) model that uses a central identity broker to connect to all the cloud providers (as shown in Figure 12-7).

Figure 12-6    Free-form model. (Used with permission of Cloud Security Alliance.)

Figure 12-7    Hub-and-spoke model. (Used with permission of Cloud Security Alliance.)

The free-form model comes with a few disadvantages compared to the hub-and-spoke model. First off, your authoritative source needs to be connected to the Internet to connect with all of the cloud providers. Second, in order to support users outside of your network, these users will need to VPN into the corporate network to access any cloud solution that has a federated link established. Finally, in an environment that may have multiple authoritative servers (such as multiple domains that are not joined for corporate purposes), each of these authoritative servers will need to connect to the providers, which multiplies the amount of connections required.

In the hub-and-spoke model, an identity broker can be cloud-based. Implementation of a cloud-based identity broker can facilitate the establishment of the federation with numerous cloud providers, and external users need not VPN into the corporate network to use federated links to your various providers.

Another option exists in running your directory server in a cloud environment itself (or by consuming a directory service from the provider). In this scenario, you could synchronize your internal directory server with the cloud-based directory server (or service). In turn, this cloud-based directory could serve the operating systems and applications (applistructure) in the cloud environment and act as an authoritative server for any federated links with other parties that rely on the cloud provider.

In addition to the big-picture deployment model considerations, the following process and architectural decisions need to be made:

•   How will identities for application code, systems, devices, and other services be managed? Most of the focus in this chapter has been on users accessing services. Services accessing services and other requirements may call for a different approach.

•   How will identity provisioning processes change when consuming cloud services, if at all? Identity provisioning is not limited to creating identities only; it also deals with changing permissions and, of course, deprovisioning identities. A provisioning system could take information from an HR database and then be used to provision access to various systems in addition to the directory server, such as web applications, database servers, and, most importantly for our discussion, cloud services. If provisioning systems today are inefficient, adopting cloud services may offer an opportunity to readdress and improve your provisioning systems.

•   Formal processes should be implemented when on-boarding new cloud providers and integrating them into your existing IAM environment. This includes establishing federation and the following considerations:

•   Building an entitlement matrix that is created using the granularity exposed by the provider. This may vary based on the service model (for example, SaaS versus IaaS).

•   Determining how attributes will be mapped between the identity provider and the relying party. This includes mapping internal groups (roles) to the groups in the provider environment.

•   Determining and enabling any monitoring and logging that need to be implemented to meet your security policies. Newer IAM implementations may offer new services that you may want to include in your policies, such as behavioral analytics.

•   Documenting any break/fix processes in case of failure of any of the federation (or other techniques) used for the relationship.

•   Updating current incident response plans related to identity takeovers to include the process for cloud providers. This may include steps required to engage the provider for their assistance, especially when dealing with a privileged account takeover.

•   Determining how accounts can be deprovisioned (or attributes changed) in the cloud environment.

Finally, providers need to determine which identity standards they will offer to customers. As you know, providers will generally offer some form of identity and access management system. Providers may enhance this with either custom or standards-based federation offerings. In the event of standards-based offerings, SAML will likely be requested by customers.

Authentication and Credentials

Authentication is always the responsibility of the identity provider. If you have federation in place, a system under your control acts as the identity provider. If you don’t have a federated link, the CSP acts as the identity provider. Authentication technically occurs any time an identity needs to be confirmed, such as when an entity proves who they are and assumes an identity, not just during logon.

As cloud services, by their very nature, have broad network access, simple usernames and passwords are insufficient to protect accounts. Multifactor authentication should always be offered by a cloud provider to enhance authentication security, especially for privileged accounts. The CSA Guidance calls this “strong authentication using multiple factors.”

Being authenticated with MFA can be used as an attribute. That said, using this as part of your access control (access management), you can enhance security by granting entitlements based on this attribute. This would be an example of an attribute-based access control (ABAC). Preferring ABAC over RBAC is generally recommended for cloud environments. Keep in mind, though, that adding attributes to access decisions will introduce complexities.

You know the factors involved with authentication: you know something, have something, or are something. With these in mind, the CSA Guidance calls out the following options for different factors above and beyond the simple factor of knowing a password:

•   Hard token This physical device shows a one-time password or can be plugged in to a computer. This is the best option when high security is required.

•   Soft token This serves the same purpose as a hard token in as much as it will display a one-time password, but it runs as software on a phone or computer. Unlike the hard token, any compromise (such as malware) of a user’s device may compromise the one-time passwords. This must be considered as part of a threat model. There are a multitude of applications that can offer soft tokens.

•   Out-of-band passwords These passwords are sent via a separate communication method, such as a text message (SMS). Threat models must consider that messages may be intercepted (especially SMS text messages).

•   Biometrics Unlike the other options presented that all involve a “something you have” factor, biometrics are a “something you are” factor. For cloud services, the biometric is a local protection and any biometric data is kept on the device, not sent to the provider. Biometric authentication may be an attribute that can be sent to the provider and used as part of ABAC.

Beyond the listed options, you might want to check out the FIDO Alliance for new MFA approaches, such a FIDO Universal 2nd Factor (U2F) authentication that will offer stronger security options in the future. As with all other technologies, it often takes some time between the creation of more secure solutions and industry adoption.

Entitlements and Access Management

The cloud impacts entitlements, authorizations, and access management in multiple ways. Following is a list of changes that you should be comfortable with before taking your CCSK exam:

•   Cloud providers will have authorizations specific to them. Some providers will offer more granular authorization options than others. Mapping entities to these authorizations (entitlements) will usually need to be performed by the consumer (unless the provider supports XACML, which is rare).

•   The cloud provider is always responsible for enforcing authorizations and access controls. Federation doesn’t change this. Federation enables the identity provider to control authentication and instruct the relying party regarding how to enforce authorization.

•   Attribute-based access control (ABAC) is the preferred model for cloud services because it offers greater flexibility and security than the role-based access control (RBAC) model. Attribute decisions can be based on anything regarding the user and the connection itself, such as MFA authentication, IP address, geographical location, and so on.

•   Cloud providers should offer granular attributes and authorizations to enable ABAC that enable customers to implement more effective security for cloud users.

Privileged User Management

Privileged accounts require the strongest authentication possible. Additionally, all actions taken by a privileged account should be recorded to obtain maximum visibility and therefore accountability for actions performed by these accounts. Having these accounts log on via a bastion host or a “jump box” may allow for tighter control of both authentication and monitoring of actions.

Chapter Review

This chapter addressed the recommendations for identity, entitlement, and access management as per the CSA Guidance. You should be comfortable with the following recommendations from the Guidance in preparation for your CCSK exam:

•   Organizations need to plan for IAM changes. This will require the development of plans and processes for managing identities and authorizations.

•   Implement federation services to maintain control of the authentication of users. Try to minimize the amount of identities held within individual cloud provider identity services.

•   Identity brokers may ease the effort associated with creating federation connections with a large amount of cloud service providers. Consider using them when appropriate.

•   Consumers should always retain control of the identity provider role when implementing federation.

•   Remember that the authoritative source of identities may not be your directory services. HR systems are often the authoritative source, and these identities are then replicated to a directory server, which can act as an identity provider.

•   Distributed organizations can leverage cloud-based directory services. Directory services can be installed on a cloud instance just like any other software. These cloud-based directory services can be used to serve multiple organization locations and support cloud services.

•   Because of the very nature of the cloud having broad network access, accounts should have MFA applied as an additional authentication control. This is especially true for privileged user accounts.

•   Any attribute about a user or their connection can be used as part of an attribute-based access control (ABAC). This is true for connections that are MFA authenticated as well.

•   Creating an entitlement matrix on paper and having the entitlements agreed upon with the business owner before implementing them technically will save everyone time and effort. If your cloud provider supports it, you may be able to copy these entitlements to the cloud provider to implement these settings.

•   ABAC is always preferable to RBAC for cloud deployments—use it!

•   Cloud providers usually offer internal identity services. They should offer federation using open standards (such as SAML) as well.

•   Federation protocols all have their own strengths and weaknesses. Choose your use cases and constraints first to determine appropriate standards to implement.

Questions

1.   Which of the following is an example of an attribute that can be used with ABAC?

A.   If the user logged on with MFA

B.   Biometric data

C.   Biometric authentication status

D.   A and C

2.   Why should multifactor authentication always be considered?

A.   It is a best practice according to the CSA Guidance.

B.   Cloud services can be accessed by anyone using a web browser.

C.   Cloud services have the essential characteristic of broad network access.

D.   MFA is not recommended because users who lose their phones will require manual effort to reset their accounts.

3.   Which of the following is the best federation protocol to implement and support?

A.   SAML

B.   OAuth

C.   OpenID

D.   There is no best protocol. You have to determine your use cases and constraints before selecting a protocol.

4.   What is the authoritative source of identity?

A.   The system from which identities are propagated

B.   HR system

C.   Directory services system

D.   Cloud provider’s IAM system

5.   When creating federated identity with an IaaS provider, which party is the relying party and which is the identity provider?

A.   The organization is the relying party and the IaaS provider is the identity provider.

B.   The organization is the identity provider and the IaaS provider is the relying party.

C.   The organization is both the identity provider and the relying party because it is reliant on the cloud provider to implement federation.

D.   The cloud provider is both the identity provider and the relying party in a federated model.

6.   Which standard uses the concepts of policy decision points (PDPs) and policy enforcement points (PEPs)?

A.   SAML

B.   OAuth

C.   XACML

D.   SCIM

7.   What is the difference between an identity and a persona?

A.   Your identity is your username; your persona is the group you are a member of.

B.   Your identity is your username; your persona is your identity and all other attributes associated with you in a specific situation.

C.   Your identity is used to authorize you; your persona is used to authenticate you.

D.   Your identity is used to authenticate you; your persona is used to authorize you.

8.   What is a role?

A.   A role is a part of federation. It is how your group membership within your company is granted entitlements in your IaaS provider.

B.   A role is the job you perform at work.

C.   A role is a temporary credential that is inherited by a system within a cloud environment.

D.   All of the above are correct.

9.   Which of the following is a factor in multifactor authentication?

A.   A secret handshake

B.   The color of your eyes

C.   A one-time password

D.   All of the above

10.   Which of the following protocols is XML-based and supports both authentication and authorization?

A.   SAML

B.   OAuth

C.   OpenID

D.   SCIM

Answers

1.   D. Everything about a user and their connection can be used as an attribute to determine access control. However, in the biometric model, actual biometric data is held within the device itself. The fact that biometrics were used is an attribute that can be used.

2.   C. Cloud services have the essential characteristic of broad network access. This is similar to the fact that it can be accessed by any browser (B), but C is the better response because not all access to a cloud service will always require a web browser. Of course, implementing MFA is a CSA best practice, but that alone is not the reason why it should be implemented. While loss of a cell phone with a soft-token MFA device will likely require manual effort to reset the MFA settings, it is not a valid reason to avoid the use of MFA, especially for privileged accounts.

3.   D. There is no “magic bullet” protocol for federation. You must always consider your requirements based on use cases and constraints.

4.   A. The authoritative source of identities can be any system. It is the system in which user accounts are created and then propagated out to others. This could be the directory server in some environments, or it could be the HR system in others. You never want the cloud service with which you are creating a federated link to be the authoritative source or the identity provider.

5.   B. The organization is the identity provider, and the IaaS provider is the relying party. You always want to retain the role of the identity provider when establishing federation.

6.   C. XACML uses the concepts of policy decision and policy enforcement points. XACML is used for more fine-grained access control decisions and can work with SAML or OAuth. XACML implementations are rare.

7.   B. Your identity is your username, and your persona is your identity and all other attributes in a specific situation.

8.   D. All the answers are correct. This is why the CSA Guidance says that “role is a confusing and abused term used in many ways.”

9.   D. The factors are something you know (secret handshake), something you have (one-time password), and something you are (eye color). Do these make sense from a technical perspective? Probably not, but they meet the criteria of the three factors all the same.

10.   A. SAML is XML-based and handles both authentication and authorization. OAuth only deals with “AuthOrization” (memory trick), and OpenID only deals with authentication. SCIM is a provisioning language.