BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Adopting identity and access management in the cloud demands several shifts in thinking for infosec professionals. From a technical perspective, managing user identities in a cloud-based environment requires a careful approach to federation. But, for many, the bigger shift is the philosophical one -- that is, getting comfortable with giving up a degree of control.
In this video, expert Adam Gordon, lead editor of the Official (ISC)² Guide to the CBK, Fourth Edition, explains the implications and opportunities around using third-party services for identity and access management in the cloud.
CISSP® is a registered mark of (ISC)²
Transcript - Identity and access management in the cloud: Risk or reward?
The following video is an excerpt from the Official (ISC)² CISSP OnDemand Training.
Let's talk about integrating third-party identity services and what we need to do in order to do that. We'll quickly take a look at managing user accounts within a cloud-based application and directory solution and talk about an example of how identity management services can be applied.
When we think about managing user accounts within a cloud-based directory or application solution, we have to think about cloud identity, directory synchronization, federation potentially in federated identity. These are the building blocks of what we have to consider. We have to understand how the cloud-based identity is going to be created and managed for the user. That then has to be synchronized back into our local directory service, and we have to have some sort of directory synchronization mechanism that moves identity back and forth between the cloud and the on-premises or the actual enterprise or organization. And then federation may or may not come into this with regards to understanding how we will then trust or extend trust out to other entities, other organizations, vendors, suppliers, whoever may be on the other end of that federation solution.
So, as we bring all these things together in the form of identity and access management in the cloud, as a security professional, we have to be thinking about the fact that cloud extends the boundary, extends the border of our management area. It allows us to incorporate a third party that provides services to us that will typically host services for us, and we now have to think about sharing, sharing information, sharing user data, sharing access control, and sharing directory information and responsibilities, and allowing then some form of synchronization that moves that information back into the organization. It removes it from the organization into the cloud and back again, however you want to think about that.
A real-world example
An example of identity and access management in the cloud would be something like what you see on the screen in front of you, Amazon Web Services. The solution that is deployed currently through Amazon Web Services allows any and all of the code that you work with there to not be specified and not be secured in a way that is specific to Amazon. In other words, all the server-side code is managed without any long-term credentials being applied to the application. When you create user accounts, when you consume services through Amazon, you set up temporary credentials for authenticated customers and during the service time or lifetime of that service agreement. In other words, however long you pay for the services for to consume them from Amazon, those temporary credentials are made available through the Amazon Directory Service and are then bound to the instances and the application solutions that you are paying for, managing, and running. When you get rid of those systems, retire them, decommission them, or no longer operate on the platform, those credentials are removed from the Amazon system, and access to those solutions is removed as a result. So we're allowing individual customers to specify what their credentials will be on an ongoing basis through this temporary application of those credentials to services in a modular form.
This is what identity and access management in the cloud looks like, at least one element of what it would look like from a customer perspective, from the security providers' and security professionals' perspective. What we want to be focused on and what is a good takeaway from an example like this is understanding that we will be able to create the security credential, the identity as part of the provisioning process, but we have to do so and follow up on whatever the rules, and procedures, and in this case probably the checklist, if you will, of responsibilities that have to be met and obligations that have to be met in terms of information, provisioning of information, and then doing so through the proper APIs. And with the proper format, we have to follow up on those things as the customer understand them from the provider's perspective and make sure we then have in effect the playbook, right, the rules of engagement that allow us as security professionals to manage and drive the expectations and then to manage and drive the understanding of and ultimately the use of these systems. If we're able to focus on that, able to understand how to do that, it becomes easy to envision how we integrate and, as a result of that, consume third-party identity services.
Rethinking the control model
The trick for us at the end of the day is to understand as security professionals that we have to be open to the understanding of and the idea that ultimately we may lose an element of control. We may give up some element of control to a third-party vendor through partnership and through association with the cloud vendor we are indeed partnering in order to gain some advantage. We are effectively brokering this conversation about identity access into the cloud to broaden the approachability, to broaden the usability, and broaden the functionability or the functionality and the functions that we want to consume, all the access management of identity and access management in the cloud. And, as a result of that, we're gaining advantage, but we are giving away some element of control and sharing that element of control now where, before, it resided totally with us. As long as we're okay with that idea, as long as our architecture is going to be scaled to support that, as long as our documentation reflects that, sharing of responsibilities, that dual level of control that we now have to bring to bear and understand how to operate with, then we should be able to execute this kind of systems and integrate them without too much additional difficulty or concern. But, like any other system, we do have to understand the risk, the threat, and vulnerability associated with this, because we're removing our direct oversight and control from the architecture, from the implementation, from the day-to-day, moment-to-moment management and maintenance behind the scenes of these systems.
We are consuming in these systems, and we are managing day to day, moment to moment the identities created on behalf of us as the customer in this model, but we don't maintain the system and we don't manage the system. We are managing our little entity or portion of the system within the broader context of the system. And, as a result of that, the cloud vendor is actually maintaining the integrity of the system, is managing the implementation, managing the architecture, managing the updating, managing the risk, the liability, the threat, the vulnerability assessments. So we now have a split level of control, and, as a result of that, we have to now rely on them, whoever the vendor is, to take on the responsibilities of ensuring that the system is structured properly, is going to meet all the standards and requirements to operate identity and access management in the cloud safely and securely, and is going to be maintained at the appropriate level so that we don't expose our users, their data, their identity, and everything associated with it to unnecessary threat, or vulnerability, or risk because of a bad configuration choice, because of a missed opportunity to create a patch and put a patch into place that will address a threat or a vulnerability, or because of a misconfiguration or any combination of these things.
Increase trust, lower risk
So we now really have to focus even more so on the identity management aspects that involve understanding risk, understanding and assessing for threat and vulnerability, because we have to push the vendor to understand how to provide that information to us in a way that makes sense. And we now have to rely on the fact that the vendor will do a good job and exercise due care and exercise due diligence in order to facilitate that information and, most importantly, the positive outcomes we're looking for in this area. So it becomes a matter of sharing control, a matter of engendering trust and understanding how to use that trust within the confines and the context of the contractual relationship to ensure that we're holding the vendor accountable and that the vendor provides to us the data and the information we need to act responsibly. And, as a result of that partnership, we then can take advantage of identity and access management in the cloud, but we can do so in a way that makes sense for us, for our organization, and, of course, at the end of the day, minimizes risk and hopefully, as a result of minimizing risk, allows us to operate more securely.