Policy Based Authorization Architecture Considerations

My name's Graham Williamson. I'm an Analyst with KuppingerCole and this presentation is actually BA based on market compass update I did last year on policy based access management. And I was absolutely blown away. I'd done it, it was an update from a document done two years earlier and I was blown away by what had happened in between the, just in two years. This whole area is accelerating, guys, and we are gonna have to get used to that. And I'm just gonna go through a couple of points that I think are important in terms of helping avoid the tiers.

Okay, so we're gonna look at the issue, the strategy that we need to take as terms of a, a corporate strategy and then the way forward, what's happening? Well, feedback's not really kept up with technology developments, and this is primarily in the area of cloud, okay? We were all very happy with the traditional way that we have done things, but when it came to cloud, particularly cloud native, we've been left to devise our own solutions.

In many cases, the infrastructure, we are DeVol, we are actually deploying across complex infrastructure environments, sometimes multi-cloud environments, and that makes things very difficult. But what it does do is help in that devolution of the access control decisions to the business unit. So I think there's a, there's a light at the end of the tunnel here, and of course we've already talked about with Matthias presentation in terms of the complication of governments when it comes to diverse, diverse deployments.

Came up with this picture basically to, to indicate how we have to choose where we are, okay? So from the traditional space where we are basically on premise, but probably got some, some hybrid environment, you know, we're all happy with that.

We, it's a mature solution. It's, it's, it's doing a good, good job. It's a single instance solution and we, we've got good control, but as we move into a more modern environment where we're doing cloud native, and let's face it, a lot of organizations are now moving into their sp I'll tell you a very quick story. I did a job for a, a university in Australia and they had a, a student admin system that was huge and they, one of the components of that system did enrollment. While in Australia, you do enrollments one week in February and one week in May. That's about it.

But during those times, they restricted anything else that could happen in the student admin system so that all of the cycles could go to actually enrolling students. They even went to say, well, Monday's Medical, Tuesdays, the engineering, and so on and so forth, you know, to to, to spread it off, moved it into the cloud cuz it scaled, but because it was a monolithic de deploy, it just, the cost went through the roof. So cloud native is important for us so we can separate out the various components of our replication so that we can just scale what we need to scale.

And so cloud native is something we, we've gotta get used to, but we then need to be able to control the access, access management to that. Okay? We're in the traditional space.

We, we basically had a, a, a user over here. Let's see, see, oh, look at that. The user is attempting to, to access a REVO resource. Could be a database, could be an application. It's got a policy enforcement point attached to it. The request comes to the decision point that looks at the information here and then the response comes back, is it is gonna be approved or is it gonna be denied? The situation in cloud native is somewhat different. We've got users over here attempting to, to, to, to access a, a resource component, okay?

And there's an API there that's talking to, could be a service mesh type situation, but is coming to an open policy agent, okay? So totally different world.

Sorry, Done something wrong. Check one, two, check one, two. Are we okay?

1, 2, 3. You're doing a great job guys. It's really good. You've noticed how he turns out the volume up and down when I'm talking down, it's silent. They're good.

Okay, so here what happens is, oops, I didn't want to do that. I haven't quite finished with this one. We've got adjacent data store here and a a re policy store. So the re code defines the policies that we're going to be using and then this OPA cycle basic comes here, looks at the, the policy checks with the data and says whether it's going to be allowed or not, right?

And, and obviously the, the databases back here is are feeding the Jason data array. The issue that then jumps to mind is how do we put that all together? Obviously we don't need the whole ad in that data store, we just need the components of the resource over here. Those needed to access us. If you leave this up to the, the, the DevOps to make these decisions, you're gonna lose that control over the policy. Okay?

So we, we need to do, we need to be a little bit bit smarter here, okay? So let's go to the strategy. How do we keep control? First off is decide what your requirement is and those requirements are gonna change depending upon the use cases, okay? In some cases, your large corporation, you don't have many dev DevOps stuff, so it's not gonna be too important. You're going to be happy taking your applications, doing the lift and shift into a VM on the cloud environment and using the, the controls you've had in place for many years.

However, if you've got a DevOps component, you're now faced with, how are you gonna make sure that the data going down to that container, the CCAR that's doing the authentication for it, is consistent with what you're doing back in your, in, in the on-prem or, or the corporate environment, right? You need to make sure that we've got some consistency there. If you're an sme, you're probably using SaaS apps, okay? So SAPs SaaS apps are great, they do a lot for us, but we need to make sure that we control the identity, how we manage our identities.

Again, the same university I talked about earlier, they had what this was going back five years, they had eight different synchronizations happening every night to eight different SaaS apps out in the, the cloud environments. Each one of those is an attack vector. So you need to be, if you're using a lot of SaaS apps and sme, make sure that you are controlling like it's best to have a single cloud environment that all of them are access via SAML or skim or something like that. Or you could be a, a startup. If you're a startup, you're basically a lot of SaaS usage.

You might be doing cloud native. So again, depending upon which environment you are in this loss more than this, of course you need to, that's the starting point. Understand where you are coming from.

Now this, this actually Martin asked me to put this in, so I did the policy lifecycle. Understanding how policies go through a lifecycle is is the, the, the, the overall topic of the slide, but it changes depending upon what we've got. We might have a mix of environments with our legacy applications across on-prem and, and, and cloud apps. We might be SaaS app user, okay? So typically course grained using a single idp or we could be cloud native as we've talked about with, with a fragmented deployment, right?

And that fragmentation might be across multiple cloud environments and, and you know that that should screen problems with you. You've got AWS does it different from Azure, does it different from Google? Like you need to, to to, to have some sort of control on that service mesh is, is is touted as being the future where we have a single services environment that's doing all of our authentication for us. And the various applications could be a monolithic application or it could be a, a cloud native. A application will suck on that. A services mesh for the decisions that it needs. Okay?

So your your policy life cycle is going to be different depending upon what environments you're going to be operating in. What we need to focus though is on having some unification. We need to make sure that the number one, we've got agile response of course, but our policy life cycles for each environment need to be unified so that we are using similar tools and and capabilities.

So if, if my manager has given me access to three different applications, that app, that needs to be consistent regardless of whether those applications are on-prem, in cloud, cloud native or what have you. And so our policy-based access control environments need to be controlled via the policy, the governance tools, governance strategy that's put in place at a corporate level. Okay? So way forward. Please don't do nothing when you walk outta here, let's say I'm gonna do something right, not nothing. Last slide I would suggest we take, and this is where the architecture bit comes in, okay?

I love architecture. We need to develop what sort of solutions that we're gonna be putting in place. I like doing an entity relationship diagram for our environment. Okay? So did an interesting job for an agency in, in Singapore and we, we took them their nine major corporate applications.

So looked at what each of those needed in terms of authentication and what sort of data needed to be provided and we put it into an entity relationship diagram and all of a sudden a lot of the things became more obvious, okay, as to what the solution needed, your business processes, you need to understand your business processes. I love business process mapping. And I can remember it was actually another university in Australia where two groups got to fisticuffs because they couldn't agree on what the actual business process was for enrolling a student.

So you need to understand what the, how, how the business works and the technology configurations. Again, I've seen one in, in was lovely the, this corporate environment. They had various places around the, the buildings a three poster of what their technology environment was, what was supported, what's been deprecated. And so you knew that if you wanted to do an application that you needed to use Windows server 2016, that was the corporate requirement. They had good control over what technology they were using. And then of course choose the development environments that you need.

We've mentioned, I've mentioned DevOps a couple of times. Please elevate your DevOps if you're doing development software development to status in the company where they're respected and give them the tools they need that's going to give you the control on what needs to be done. I'll shut up there if there's any questions, I'm sure Mattis will have them for me. Actually there are no questions Okay. In the chat that puts the blame on you. Are there any questions in the room to Graham for this talk about Yeah, his, his his take on, on policy based access. Other questions?

Okay, then a question, question from my side. Okay. What do you expect for the next two years to happen? We have this seen, this acceleration of of, of all of this just going on. We have seen OPA coming up and out of the blue. Nobody expect, I did not expect it. What do you expect for the next two years?

Okay, as I said, I think we, we've definitely got con got to control that cloud native OPA is very different from Exactl for instance. So in the legacy environment we had good protocols that we could deploy in the cloud native, we don't, we have a framework. OPPA gives us a good framework of how to manage our policies and the data associated with those policies. But you've gotta do the heavy lifting of deciding what data's gonna be put there and how are those policies that are going to be put in the reg code consistent with the policies we're using in the rest of the organization.

If you don't do that, there's tears to come. Okay? And there's a final last minute entry in the, in the chat. So should we allow DevOps to be involved in policies by elevating them or should we cut them out?

No, we need, you've gotta use your DevOps people there, but if you provide them the tools, so for instance, I've seen some very good tools that allow, they give visibility to the, to the policies and allow the DevOps people to choose a standard policy for that particular requirement that they might be putting in place. Okay? So they can go down and say, oh, well that's, it must be consistent because I'm reusing one that we've already got.

If they need to make a change to the policy to do that, now you need to make sure that that's approved in terms of, doesn't muck up anything else that you might want to do by giving them the tools so they can click on that policy, the system itself will do all the deployment. You can't expect your DevOps to know where all of the deployments are happening, you know, is far too complicated, complicated now. So you're gonna automate that C I C D pipeline, so please give your DevOp a pat on the back and, and make sure they've got the tools they need.

Great, thank you very much Graham.