Thank you.
Yeah. Welcome everyone. And great to have you here on our talk. We decided to pick that topic because we really get this question a lot. We as mesh cloud yeah. Are more in the cloud business and in the cloud governance business, but identity and access management is one of the main aspects. And that's why we want to show some approaches that we have seen, and that we have implemented with our customers to give you an idea of the different ways and different possibilities you have to, to implement a multi-cloud identity and access management.
Before we start a quick introduction, Rebecca, do you wanna go ahead and I will figure out how that works. Yeah,
Sure. So hi folks, it's lovely to see all your nice faces at least half of them, at least, but I'll take it. My name is Rebecca and I'm a leading product management at mesh cloud. And in my role, I have contact to various organizations adopting and expanding into cloud and all the lovely challenges that come with it.
Yeah. I'm Christina I'm co-founder of mesh cloud and CRO and happy to join Rebecca on stage today and to share our story with you.
So yeah.
What is mesh cloud mesh cloud, as I mentioned is a cloud governance platform and the idea.
So when we talk about cloud, we mean cloud infrastructure in that case, and we integrate all the large cloud providers and then yeah, establish across cloud governance across these different platforms and identity and access management obviously is a core part of this because people have to somehow get access to these clouds and get access to the cloud environments they work with and the organizations at the same time, they need to control how that access is provided, if it's okay that they, that they do access these environments and how to basically keep an overview on what is going on there in a world that is very dynamic because if we look at the cloud, we have a lot of environments, we have a lot of change.
We have changing teams and all these things, and we somehow need to handle this very dynamic environment with the processes that we have in place.
So let's have a look at the most challenging things. When we look at multi-cloud identity and access management, and the first thing is mostly a result of the, of the other effects. It's a lack of agility. And I know this term is a bit over overused, but in the end, people go to the cloud to be faster.
And if they lose speed on their way, because of yeah, very complex identity and access management practices, they kind of not really reach their goal. So the idea of really getting access to a cloud environment, getting a credit card, going there, ordering some virtual machines or other services, if this completely gets lost, it's not really, it's not really the point of going to the cloud. So we need to find a way when implementing an identity and access management for the cloud that gives us this agility or that keeps that agility in place.
And one reason why it gets lost is because we are lacking automation. So, and there's a reason for that automating identity and access management in the cloud is quite hard. We have a lot of different systems in place. We have the different cloud providers. We have identity management systems. We have different processes that we need to handle authorization, authentication. We have yeah, strict regulation and a lot of industries. So we need to take care of regulated processes, existing processes.
We have like all these things that are already in place that have worked for other technologies that now need to be brought to another level and to be adapted to the cloud. And the complexity just rises, especially if we are looking at multi-cloud environments with multiple cloud providers in place, and we end up with a lot of complexities. So instead of, yeah, of course we don't want to just let people go and everyone can access whatever they want.
That's not possible. We all know that.
So we rather take the approach of kind of blocking the access and making it more complicated in order to stay in control. And in the end we still have like a missing transparency. We still have different cloud environments. If I look at large organizations, they have like a thousand, 2000 cloud environments in place. They do not really know who has access to them. If people leave the company, you don't know if they maybe still have access to one or the other cloud environment actually accessing data and being a real threat to the cloud landscape.
So it's really challenging to build a system that is nice for the user to use, but also good for the organization to stay in control of what they do.
So now that we are, we have established that there are some challenges out there. Why should we even care?
I mean, solving complex challenges, finding a solution, and then implementing the solution costs time and a lot of money. So let's focus on, on two aspects here.
Why, why people should care and how to also communicate it internally to make life easier to get budget.
So one thing is to reduce effort. So the amount of applications we have in an enterprise, but also the amount of environment is increasing constantly leading to a, to an ever increasing amount of permissions assignments. Another thing is that if you want to move to the cloud, you want to save time. But if you don't incorporate the cloud into your existing identity and access management strategy, you will lose the time you wanted to gain with going to cloud in the first place.
Another thing to consider is do you want your colleagues to spend their time creating innovative solutions? Or do you want to want your colleagues to stuck in authentication, redirect loop, setting back their passwords or inviting hundreds of users to cloud accounts one by one?
No, of course you don't. So another thing to keep in mind is to protect your business and a great identity and access management is not necessarily the most expensive one. It's the one that suits your requirements. So the best point to start is what is it I want to protect and what individual risks or general risks do I face and start there. And then arguing why identity and access management is important, will become much easier because humans learn best. By seeing examples. We've provided you two examples today, which we want to show you. And Christina will now start presenting you.
One of the examples called the liquids approach.
Yeah, so who's liquid liquid is a fantasy bank in financial services. So it's a traditional financial services institution. And as all financial services, institutions, liquids analyze strict regulations. So they have ma risk. They have well segregation of duties, all the things that they need to, to take care of, but they want to go to the cloud and they have a multi-cloud strategy. So they have been negotiating with other Azure and GCP for the last year. And they figured out a contextual basis to work together.
And now they really want to go into the cloud in order to accelerate their software delivery. So that's basically the goal of their cloud journey. Looking at liquid bank, they are aiming to build like a couple of hundred applications in the cloud and they really yeah. Want to use that as an accelerator. But of course they know that they need to take care of their compliance requirements. So basically if we look at this spectrum from agility and control, they need to find the balance.
They have compliance and control as a priority, but they need to find a way to really make it work in an agile and fast way and, and yeah. Manage to get their, their speed going. So how do they do that?
The current situation is that they have compliant IAM processes for traditional, for their traditional it landscape. They have existing processes for join mobile levers. They have segregation of duties, everything in place. And the goal is to extend these capabilities and to enable cloud use cases without compromising speed.
So we want to add the little cloud on top and we want to not lose time on the way. How do we do that?
Well, there's a couple of different things that we need to define. First of all, we need to understand who in this organization with multiple hundreds, thousands of employees can actually go to the cloud and what do they have to bring to get this access? Then a more technical question, how do identities get to the cloud? And then once the identities are in the cloud, how are actually the permissions provided to specific people to specific cloud environments?
And how do we integrate all these processes with the existing IM systems in order not to re-implement and reinvent the wheel for a new technology.
And the first step is really getting identities into the cloud. And there's a very nice German word that we face in a lot of customer organizations, which is the cloud fuel shine. So it's not just everybody that can go into the cloud. People need to be aware of the responsibilities that this means to them. So they need to go through a central cloud approval and this can be a consulting session. It can be a training session.
It can be a questionnaire, but it is basically a check central approval check, which qualifies them to use cloud technologies and to be aware of the responsibilities that they get there. Because one important factor when using cloud for speed is that people really want to leverage the entire services that they find in the cloud. So they need native access to these cloud environments. And this usually means a lot of freedom for them that they might not be used to in traditional it context.
So to get started, I need to get my cloud fuel shine, my cloud license.
Basically, I need to prove that I know what I'm doing and that I'm aware of the responsibilities that I have once I do that, my identity is synced to the cloud platform. So I'm eligible to use the cloud. So from the identity management system that I have centrally, the identity gets synced into, for example, Azure and GCP that we are using in our example here, that means that central processes and existing processes that are taken care of, of the central identity management system are still in place.
And we have the identities in the cloud that doesn't mean that people already have access to any cloud environments. It's really just the first step of getting started.
The second step is a bit more complicated. So how does that work? We have that guy here. He has done his cloud license. His cloud view are shine. We can call him Tom and Tom in order to get into the cloud. He has to register a use case because he has some plan there. He needs to build some kind of application. Let's say he needs to build the mobile app of liquid bank.
So he needs to register this cloud use case in a central, in a central Porwal. And when registering this cloud use case, it has to go through different approval steps. So he will get a risk assessment. He will get a security review, an architecture review, and well, the more of approvals he gets, the more capabilities. He also achieves that he can do things in the cloud.
So these approval steps there actually forwarded to the self-service Porwal and in the self-service Porwal Tom, who is like the team lead of his development team can create cloud tenants and provide permissions to these cloud tenants.
And in the beginning, he might only be able to do that for some sandbox accounts or for some dev environments that are not really critical or do not handle any critical data.
And the more approvals he gets in the first place in this, what we call regulatory onboarding, the more capabilities he unlocks kind of in the cloud self-service Porwal then of course, in, in the financial services context, production access is a very sensible thing. So to get production access, he needs to access an additional system and really use the central workflow in order to actually create a productive cloud environment. But that also goes through the self-service Porwal, it's basically unlocked there. And from there, the permissions are actually implemented in the cloud platforms.
And that's a very important factor because what we want is not only getting initial access to one of these cloud platforms, but we see it's written up their permission replications.
So we want to have a desired state model. We want to know what is the state of the permissions that we have actually defined. And what is the state of the permissions that is actually active in the cloud.
And these two states need to be the same and they need to be synchronized on a continuous basis in order to ensure not only a safe onboarding to the cloud, but also continuous compliance into continuous control of the permissions that you have there. And once this is done, Tom, he can basically access the clouds directly and then work in there and really enjoy his freedom and yeah, work on his application and focus on what he has to build there. So with this approach, liquid bank is trying to maximize the agility.
So they implement as much self-service as possible, but of course they keep control by having their regulatory onboarding and all the approval processes that are needed in between and kind of let him unlock one by one, the different capabilities that he can then leverage in the cloud. And with that, we will look at our second example, which looks a bit different.
Yeah, it does. So let's have a look at the app company. It's a medium sized company making money by developing and productizing applications for their customers. Most of the 120 employees are developers or designer engaged in various projects in, in, in the cloud, in this case, GCP. So depending on their amount of running contracts, they currently have the amount of environments fluctuates between 20 and 50, just GCP environments. What is really important to them and what drives their business is the time they need to complete a project.
Meaning the time to cloud is a key performance indicator for them because the time they need to set up an environment and invite all the developers into those environments, doesn't create any value to their customers. So they try to cut it down to a bare minimum. So the time it takes for a new project to ramp up is key for them.
But how do they do that? So the main differentiator we see in various organizations regarding speed and time to cloud is the level of self service they provide to their teams. So here the team lead defines the access. So they ramp up a new project to start working.
And the team lead defines the, the access necessary for the cloud environments that are part of this project. He can leverage standard roles that are defined across the organization, meaning he doesn't have to take care of, oh, if I provide this riot, is it compliant?
Do I get, do I need to follow a new approval process? No, he can rely and come back to those already compliant and best practice choices.
So while so he defines the team, lead defines the desired state, meaning who has access and role they have. And this desired state, he defines in the self service Porwal. And this desired state is replicated to GCP. In this case, over the life cycle of the project.
If someone leaves the project or joins the project, the desired state is adapted and continuously replicated to the cloud, which so this whole process is really key to speed because it's up to the team lead. And we see that this whole process is only a matter of minutes if you have the right things in place.
So, I mean, this level of self self service may seem unusual to some of you. This is why the app company has implemented some security guardrails to keep things in check and allow the self service. Because only if you have a certain level of security in place and enforced, you can grant your teams the ability to get things in self service and therefore reducing the time to cloud.
So we already established that standard roles are a key part here, but also companywide join a lever and mover processes are really important if you don't have a tool for it.
I mean, there, there, you also have organizational measures. You can put in place to follow these processes, but here the, the projects can rely on a central system, a single source of truth for, for the identity. So if someone, for example, goes on, parental, leave their user, all their users are deactivated and reactivated.
If the person returns the app company also sets on consistent authentication standards, specifying criteria, such as multifactor authentication to verify a user accessing an environment, then last button or least the central overview on cloud access, meaning they have a central place in the self-service Porwal where they can see who has access to which environment at which point in time, which is really important for them to keep an overview.
So, and all those four things combined enable the app company to, to empower their application teams, development teams, and operation teams, the level of self-service, they need to ramp up really quickly and reduce time to cloud flout.
Yeah. And with that, I guess we showed two quite different examples. One with people really having easy and fast access and one in a very compliant environment.
One thing that we've certainly learned is that you need to kind of keep together what your use case is, what you need the access for what is going on in the cloud environment and then who is actually accessing this cloud environment. But we have a couple of other takeaways that we want to wrap up on and keep together to, to let you leave the room with a couple of thoughts and, and yeah. Ideas in your heads.
So the first thing, if you really want to go to the cloud, and if you want to implement a meaningful and inefficient identity and access management for multi-cloud environments, time to cloud is key. You cannot implement a system that is not user-friendly because developers will find other ways to access their cloud environment.
So you need to bring user friendly access management together with yeah.
The, the control that you need. The second part is that you really need to look at the requirements of your organization. Not every organization is the same, not every organization has the same regulatory framework that they need to comply with. So you have to look at what your goals are, who's using the cloud. What level of knowledge do they have? Do they need a cloud fuel shine? Do they not need a cloud, fuel shine? All these things is something that you need to figure out for your organization and then build a model that really suits your organization and fits to what you need.
And then one thing that we really experience very often, you shouldn't only look at onboarding and how do you actually get initial permissions for the cloud? You need to have a thought of the entire life cycle.
Cloud projects are very dynamic.
They come, they go, people change in these projects, teams work on a cross functional basis. And it's very important that you have this desired state and you have like a continuous compliance for your access management in the cloud, because otherwise it might work for a couple of months, but after that things change and you cannot keep control anymore. So you have to be sure that what you have documented and what you have in place in terms of control mechanisms actually reflects what is going on in the cloud on a, on a technical basis.
And then if you are looking, and I guess most organizations that go to the cloud, they will end up with some kind of multi-cloud approach sometimes wanted and sometimes unwanted. But if you build your architecture, think about how you can build it in a way that it's cloud agnostic do not build a solution that works for one cloud.
And then once you integrate the other cloud, you have to put new people on it. You have to build a new architecture. And the people that actually use the cloud have to follow different approaches.
And they don't even know why mostly because in your organization, they're different silos, building their own solutions that do not really talk to each other. So when building an architecture, think about how you can later on integrate other cloud platforms or other systems that are relevant in order to have something that yeah, comes up with a user experience that is nice. And that really lets you achieve your goals that you're looking for to achieve in the cloud. And with that, we come to an end with our talk and I hope we have time for some questions. I'm not sure.
Thank you very much, Rebecca and Christina, that was a very brilliant, very mature and, and great approach towards moving through the cloud. Thank you very much. First of all, you're welcome.