Thank you. Thank you very much. Coming a call for having us for the second time in a row, still remote, but still very much, you know, before a very identity aware audience that KAA call manages to attract.
Now, the subject of today's discussion is the governance in, in the era of automation. I'll talk a little bit about, about, about the topic, but before I do that, I just want to introduce my colleague and myself. I am the director of clean access management at Phillip Morris international. And I look after both the access management transformation program, as well as the support services for access management across Phillip Morris. So here Ji want to introduce yourself quickly?
Hi, all my name is LAN I'm. The, the manager in privilege access management workspace, and also automation of IG workspace is what I take care of in privilege. Phillip S international.
Thank you S so the, the, the topic today is of implementing identity governance in, in a situation where you have large workloads of applications moving to cloud based past or infrastructure as a service platforms like Amazon web services or Microsoft Azure.
We, when, when we started looking at this, they were, we, we were undertaking a major shift to the cloud with some of our on-prem applications, moving to the cloud in various flavors, the flavors being obviously lift and shift, which is a pure play, you know, lifting an application, putting into the cloud as is with infrastructure with all the three layers application database, all of that, you know, as is moving the legacy to the cloud. So to say, and then there, there are, there's a whole spectrum of integrations.
They could be repurposing the infrastructure layer rep repurposing the database, repurposing the application layer to whole wholesale customization of the application.
So these are, there were various integration patterns to the cloud that the cloud migration program within, within PMI had kind of identified. And our job was to make sure that how do we make IGA work with that governance work with that?
And the, the, the problem started the, the, the problem that we faced was that when we actually migrate applications to the cloud, for which access control is already in place and access governance is already in place. When we move to cloud based platforms, the paradigm changes ever so slightly, and the provisioning takes time because new, it has to start with a new tenant on the cloud. And what used, what used to take five or five days today is less than a couple of hours with the automation that we have implemented.
So we'll talk about, talk a little about that, but before we go into that, what, what is the problem there, right, in the sense that when workloads move to the cloud, you need to create a tenant.
You need to create a product in the cloud. You need to create an environment to the cloud, to which the product gets migrated, right? An application gets migrated now, the, when it gets, when it gets migrated, you, you, you have to provide an additional layer of security roles, access, and all of that, which is the infrastructure layer for that particular tenant and product.
And that provisioning while on the platform layer can take very little time, but actually linking that to application roles that basically support the whole maintenance of the product. I mean, that takes some time.
Then the other bit is that when we are talking about integration patterns that involve auto scaling, when we are talking about integration patterns that involve not just access to the product environment, but also peripheral services, like big bucket Atlassian, your collaboration services that basically been around has been around that your configuration management services, all of that, that support the product in the cloud, you know, S3 buckets for data storage and all of that, you know, that access model becomes all the more difficult and managing access.
And to ensure that we are retaining traceability, we are ensure, you know, we are, we are, we are able to demonstrate the execution of controls to our auditors and all of that, that becomes very challenging. And, and then the, you know, we are also looking at, you know, when, when we actually do this, when we design this, we are also looking at implementing least privileged principles.
We are implementing an access model that is integrated across all, not just the main product, but also the peripheral services that support the product, all the, all the tools and technologies within the infrastructure service that the cloud provides like AWS, or, you know, what they provide, you know, it supports it like upstream. Like you have cognitive, like you have other services. As I mentioned before, like our code repositories, S3 buckets, Atlassian. So all of that basically combine to form her product. It's not just the application that has been migrated.
So combination of multiple services across which there has to be an access model in place, an access governance model, a request process in place, access request, process in place, access process in place, access work, and all of that, you know, has to basically work across all those components. And the last point being that when we actually designed this, it has to be observable in the sense that, you know, we are creating multiple, we are creating the automation scripts.
We are writing Lambda functions. We are writing, you know, we are implementing segregation between environments.
So all of this should be evidence about right. It should be, you know, we should be able to evidence it for integrity, confidentiality, and availability. And we should also be, we, we should also be able to audit, audit that.
I think, I think that was the kind of, you know, the summary of the four challenges that we faced in embarking on this journey. If you go to the next slide, and this is the summary of the solution that we basically found out.
So as applications move to the cloud, as applications get migrated, as products had migrated to the cloud, you know, we had a central product registration Porwal that basically triggers a call to our IGS solution where the registration of the product happens through an API for API call and the product, the product Porwal directly also initiates to an independent process, the creation of a tenant in the infrastructure service concurrently, what the IG solution does is, or the, or the automation that we have deployed together with the IG solution, not just IG solution, but the Lambda functions that we have basically developed and Sonia's team have developed.
What they do is they trigger functions for creation of service, accounts, name spaces in our secrets world, and also the, the, the group creation for the specific roles that are required for the infrastructure teams within our IDP.
We create name spaces for, for, for management of secrets, for an Asper policy.
And, you know, those are also integrated into the pipeline execution of the pipeline. And then we also make sure that once the application is created within the IG solution, we also create concurrent roles that basically support, support access to the application. And all this process basically takes less than an hour from the trigger previously, sometimes from, from, from getting to the first box on the left, to getting to the last box, it takes about five days.
It usually take about five days, but I think we were able to kind of automate this process end to end, including the IGA process, the privilege access management process and the, the, the service con generation process. So once that is there, then we can actually expose the product to the application team to say your application roles already.
You can now access the solution and everything is in place.
Now, the key challenge was not actually, the key challenge was obviously designed that, but I think the key challenge here is that, you know, from, from our perspective to basically to show that this is integrated with the pipeline can be triggered as part of a TeleForm script, it can be triggered on an even base basis. For example, in this case, registration of the product on the product registration, Porwal, it is observable. So there are about six random functions that basically underpin this particular solution.
So if any particular function fails, we are able to observe and trace that issue to that. And we are able to go, go ahead and remit remediate that, and it is reversible in the sense that, like it flows from the front to the back to the center, from the registration of the product to creation of the product, to creation of the roles, to providing access to the infrastructure and application teams.
It can also be reversed in the sense that if we actually, deprovision a certain set of roles within the IGS solution, you know, we can have the concurrent effect to basically even, you know, Deion the product, or deprovision a set of roles. Deprovision a set of personas and it can actually go back, go backwards. The process can work backwards as well.
Now, the last point in terms of reversibility, that is something that we are still working on. We have not really perfected that because that requires a few more components to companies to work in this particular process. But the first two, we are pretty much there in terms of our ability to ability to shorten the timelines for onboarding of products, which is when you're talking about thousands and thousands of products out there that needs to be migrated to the cloud.
I mean, that, that basically accelerates.
So I am stops becoming a choke point and we are becoming, becoming the enabler of the program to say that, okay, you know, we, we, we have good news to deliver to say, okay, you know, at least we are out of the picture and we are not, we are not part of the problem anymore.
So that, that, that's basically the, the outcome of this particular analysis. But I talk about the really, really simple high level things, you know, I will let Sonia really deep dive into what this really means at, at a level deeper. Obviously we can't go into all the detail here.
So Sonia, you want to kind of take off, take over and explain a little bit about what under the covers, what does it look like? Sure.
Thanks UCH. So we want, we, I would like to present it in two different parts of the workflow that manager just mentioned. The key competence here is basically, you know, for automation perspective, we, and mainly talking about IGA solution perspective, we have an IGA solution. And we also, if, if the IGA solution is also going to manage example, service accounts or ad groups, then, then those group creation is also part of this process.
Now, if the organization decides that these service accounts are credentialed, that needs to be managed and maintained in a secrets management solution, then that becomes a third component. Now, once these three components are put together, then any tenant example, if it is AWSs or Terraform gen bid bucket, et cetera, it, it becomes the, the creation of these tenants also can be following that particular process.
So the basic key idea here is to get the standardization identified and organization should at first understand we, we, what we did was we found out at, in a particular, every single product on, on our AWS cloud platform, what is that we want to standardize from the personal level, what is that we want to standardize from the environment level and what is that we want to standardize from the, from the access level for under each of the personnel, we had got that standardized in, in a sense, one product or thousand products in the platform.
They follow the same kind of standardized approach with that. We entered into the automation process, and then it became easier for us to approach and have our automation to be a successful outcome.
Now, when I talk more about the level of access model, you can stop at the personal level. One can stop at the service level, or one can stop at the data level.
Also say, for example, we have a product called product a and a product can have multiple service accounts. And if that service account is, if there are multiple service accounts for the production and environment, then we have those service accounts also created and mapped. In this particular example, I'm taking a persona called owner. Now I have put your three level of access models. It's first level is a combination of the product, the persona, and the environment one can stop at this level.
So also just to bring that personal segregation or further, you can break the same persona and the same environment to various services example here, I've given it's AWS and Terraform. Now, what we also did was further, we broke down the access model and we have put your more like within AWS, whether an owner in the production enrollment would like to have a read permission, only permission or a rewrite permission.
Once we, once we get this standardized model, correct, what we also would be doing is, you know, taking this level, whatever level we would like to stop, take this also, and integrate with the privilege access management tool, but having this standardization is, is a key word for us to make sure that the outcomes are successful. And once we have this approach identified because IGA components are the ad groups, the service accounts, they form the foundation of any, any type tenant that would be linked to the IGA roles.
So the, the ad groups and service accounts are linked to IGA roles and the, and the ad group is linked to the tenants. And hence when someone requests for a role in the IG solution, they are granted the roles with approval mechanism. And in turn, they are given access to the application infrastructure, both access is granted. Now this is how we have come up with standardizing our persona model and also our enrollment, and also the access model.
What we would like to conclude by here is from other learning in our journey, the stress is more on what you want to standardize from personal level and what you wanna standardize at the access level and services and data level, as we just showed you before. Now, what we've achieved in this automation is basically, you know, the access model can, we can extend the same access model even to platform support as well, not just for the application support.
And with this, we, we do know, and we segregate with privilege access management tool as well, ensuring that the, the, the access model is extended only to the members with an enrollment where it is applicable for them to be used. But with this automation, we have reduced a lot of effort because the same approach when it was tried out manually, it was taking weeks and it was more of a manual work.
Now we have reduced a weeks of effort to a few hours of effort. We are able to reduce the scope of error in this particular process.
And we are able to have an efficient, when we think about our revocation process, decommissioning process, there will be additional components involved, but the path of getting this revocation is, would be straightforward is, is what we suppose would happen. But we do know which components getting created, what the standardization is there.
So we know that once we get our decommissioning process, right, straight, rightly then it can be implemented across all the applications where decommissioning should be applied now, right from the provisioning process, till the product get provisioned, right from the initiation process, till the product get provision at each and every level B roll creation, ad group creation, B 10 creation, every details of it is getting locked and audited so that we have the traceability on, on what, what activity was done.
And when it was done, this is what approach we have taken from, for us in the automation of IGA solution, across our cloud platform, by this, we would like to conclude our session and thank you very much for your time and listening to us. I hope we have provided you valuable insights. We would like to take. If you could, any questions, please, please let us know.
So thank you very much from our side. You're the.
