Managing Identities in the Cloud

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

9 hours 59 minutes
Video Transcription
Let's go over managing identities in the cloud and start out by a planning the identity management,
then reviewing some of the federation patterns that are used a free form in the hub and spoke
and wrap up looking at the process and architectural decisions that you're gonna have to make as you adopt Federated Identity Management approach
When you're planning identity management, there's certain things that the cloud providers need to offer and then the cloud customers need to figure out themselves.
And it starts with the cloud providers offering the identity service that supports customers to use their own identities. So this could be an internal identity system. And then, on top of that,
the cloud providers need to provide a standards based federation services. This would be the sample, the open I D o off combination or some of the other ones that we didn't touch on earlier.
And so this is a building block from which you can tie into and integrate with the cloud provider using the Federated Approach for identity.
And on the flip side, the cloud customers need to determine how to manage the identities themselves. How do they want to do it Where do they want the men and entities managed? What will be the authoritative source for identities associated with individuals in their company or their organization?
Then they're gonna have to decide on the architectural models to employ
that will support the situation that they're working with, making it that balance of security as well as ease to manage. And finally, there's the technologies that they want to support. There are a variety we covered three earlier on two options for authentication and two options for authorization. And there's some others.
Then there are also a handful proprietary implementations
that you'll probably encounter with different cloud providers. You're gonna have to draw the line and determine what are the ones you want to support. And what are the circumstances You're willing to support the different technologies for Federated Services. Keep in mind Federation is enabling technology to support scaling.
This way, the cloud customers avoid having to create different accounts in a variety of different cloud systems.
If you don't go this route, you can easily lose control of identity and access management. It's very likely you will still have a few non Federated identities with each cloud provider in fact, these are local identities they serve is the administrator of accounts for the initial set up as well as for trouble shooting problems with the Federated Link.
In other words, these air the back door When things aren't working for some reason, you're going to use those local Mon Federated accounts with the cloud provider. Otherwise, you want to stick with The Federated counts as much as possible for as many individuals and entities as possible.
Authoritative sources. The basis for your identity management. It contains that combination of user names, passwords, group memberships and so forth, and it will often be an internal directory server such as Microsoft Windows Active director. Once you have that figured out, there are two common architecture patterns for connectivity between the identity providers
and the service providers that rely on the identity provider.
We'll start out looking at the free for model depicted here. This approach has a few disadvantages over the hub and spoke model, which we will cover shortly. For starters, you're authoritative source needs to be connected to all of the cloud providers. That implies some level of direct exposure to the Internet in order to support users outside of your network.
You'll need a have a VPN link established so that those cloud users
can connect to the authentication source. This means you're you're loud ing them to connect into your corporate network. And finally, there's potential that you have multiple authoritative servers. For example, you may have multiple domain controllers. You may have an HR system for individuals employee information,
and then you have another one that's managed for just user
operating system controls and authentication. And each of these will need to connect to the providers. And as you can see on the diagram, it gets very complex. When you have this web of multiple providers on one side, identity providers on the top. And then there's multiple service providers on the bottom,
and each one needs to talk to each other. You get a lot of lines, a lot of cross
lines, and it creates a lot of complexity To simplify things. We can look at the hub and spoke pattern where the identity providers sink to some sort of a centralized broker. That broker is going to be cloud based, and it acts as the identity provider for all the other service providers that you're gonna be integrating with. So the internal identity providers
they become and start acting as the authoritative sources
and the internal identity providers feed the identity broker. And this avoids the disadvantages that come with the free form. But at the same time, you do have a synchronization taking place. So there are inevitably some scenarios you want to make sure and determine. Is this a one way sink or a two way? One way is going to be a lot simpler thing to manage
as faras reconcile ing any discrepancies? If
the information about a particular user gets changed in two places and you're doing a synchronization, you need to have some rules in there. How am I gonna reconcile this difference and resolve the conflict between the discrepancy and information between the different sources? Who is gonna be the authority that is going to overrule the other?
And if we look at the open I d authentication example that we explored in the prior video,
you can see all the players coming together and really, this is a reflection of the hub and spoke model. We had the authoritative source just a single source for simplicity, sitting on the corporate network that was synchronizing information, kind of a one way street over to the identity provider. In the real world, you probably not gonna actually send the password itself
in clear text. Rather, it will be some sort of a
hash of the passwords that's going out to the identity provider, and that identity provider is residing in the cloud. Then we have the relying party in their multiple, different relying parties. That's the reason I chose this image with multiple servers so they could represent many, many different SAS providers and so forth. And there's a trust relationship between those two is
the relying party communicates with the identity provider, in this case,
the identity providers also carrying the role of the identity broker. Let's recap and expand on some of the questions you'll need to ask yourself once going with federation as well as the architectural decisions you're gonna make. You want to know how the identities, theatric ations, devices and other services are going to be managed.
So far, we've really only been providing examples using individuals.
But keep in mind all these concepts also apply when we have identities for applications, maybe their service to service communication and certain applications are going to trust certain services and provide information to certain services.
But there will be other services that aren't going Teoh to be more concrete. Let's say we have an HR system, and it is
been configured in such a way that it will tell the payroll system. Here is the Social Security number for our employees. However, there needs to be a trust between the two, and then the two need to have some sort of an identity when they're communicating at the same time. Let's say somebody compromises, Ah, different system.
I don't know. Maybe it's ah salesforce dot com CRM system.
And that system then makes a connection to the HR system and says, I want to get the Social Security number for all these employees. Well, at that point, the probably the authentication in the first place isn't gonna go because there's really no reason the two should be talking.
And then finally, of course, authorizations going to fail because it's going to say you shouldn't have or need to access this kind of information. So that's an example where we've
we have entities. These entities have identities But these aren't individuals. These are human beings and the same. My mindset rings true for devices as well as other services that could be running internally you don't want. Also ask yourself how well identity provisioning change. What is the formal process to support new cloud providers?
And both of these questions provide a great opportunity to revisit any existing processes
that may be inefficient or flat out broken. In fact, when you're defining the process for supporting new cloud providers, there's a certain sequence of actions you want to make sure happen and take place consistently as you're bringing aboard new cloud providers. This is mapping the attributes what in one Federated system is considered a user name versus another? Sometimes
I've seen situations where you have a user name that's internal to your own company.
But the Federated System you don't want the I d. The identity to be that internal user name that individuals use when logging into their operating system. So you say, Well, we're gonna use our email that will become the I D. When we're authenticating with these different third parties, ask providers
you're gonna want to make sure there's logging and security monitoring in place,
even going through the exercise of building out an entitlement matrix to really lock down. Who could do what under which scenarios outlining some break fix scenarios as well so that your support staff has the ability to resolve and troubleshoot issues.
And, of course, they're going to be performing those activities and going through those scenarios when there are incidents which implies you have some sort of an incident response plan who's going to deal with
and managed to the troubleshooting an escalation process and put a finer point on the last question D provisioning an entitlement change. This can be complicated, so you wanna walk through this situation as well. When employees leaves and you deactivate their account in the authoritative source, you want to make sure that
the access this individual would have to the various SAS services or past services or so forth
eyes also declined. So this could be a matter of setting rules within the different Federated providers that relying parties and making sure that they re check on on incremental on a recurring basis to ensure that authentication can be performed. And then when they do that, the authentication process will determine that this
individual's account is no longer active, and so they should not be able to use these additional
third party services. Moreover, entitlement change. Maybe they move from one group to another, and you need to get that reflected out there. It can be complicated in some situations, and depending on the underlying technology you have, it could be a pretty simple process. But it's something you'll definitely want to think through and ask that kind of question to be thorough in your analysis
when your on boarding new cloud services.
All right, let's take some of our knowledge and go with a quick question here. Which federation protocol is the best one to support? Olaf, Open I. D. Samel Security assertion Markup language
X a CML. This is the Extensible access control markup language. Not something that we spoke about one of the big three popular. But it is something that may show up on your CCS K exams. So just be aware that it is a
policy enforcement type of ah solution that fits in the same category as these other products we've looked at
or s C. I am also something we didn't talk about the system for cross domain identity management, and it's also it's a standard for exchanging identity information between domains. So you'll want to be somewhat familiar with that one. Which one is the best to support and then finally answer F. It depends on the use case in the constraints.
I don't think this is a particularly difficult answer to discern
it really does depend on the use cases and constraints. Obviously, if the technologies aren't supported by a cloud provider than you can't use those. And at the same time there are the technologies that your own organization has decided that they want to support, so you're not going to use those under those circumstances. In this video, we went over planning identity management.
We covered the federation patterns freeform hub and spoke.
And then we revisited and went through a checklist of the process and architectural decision making and questions you're gonna want to ask yourself when setting up Federation
Up Next