Policy-Driven IAM: How SBB Embedded Identity into Enterprise Self-Service [Intermediate]

Hello and welcome to my talk about policy-driven IAM. SBB stands for the Swiss Federal Railways and we try to embed identity in enterprise self-service. Self-services are very popular today. When we order cloud resources, we take them for granted.

However, when it comes to IAM and especially workforce or enterprise IAM, we still rely heavily on manual processes, access reviews and so on. Today, I will talk about our journey toward automation of IAM resources and I'll take you on a way that we did with SBB in our company. What can you expect today?

Of course, I will show some of our self-services on our portals as an example. I will then switch to security. Self-services and IAM, it's still not really common. I will tell something about our SBB architectural blueprint, self-service guardrails, our policy framework and finally, I will talk about a principle that we call inversion of control or shift of responsibility, where we try to give responsibility back from our IAM teams to the business owners.

First, a few words about SBB, the Swiss Federal Railways. Eighty percent of our population in Switzerland is our customer. SBB is one of the largest employers in Switzerland in the field of custom software development. We have quite a lot of applications and we have and we run them in a heterogeneous IT environment ranging from modern business applications in multi-cloud environments, but we also have mission-critical software in on-prem or OT environments. This is our environment. My name is Christian Egli.

I'm the lead IAM architect at SBB, responsible for workforce and enterprise IAM, but also for the customer and OT part. Today, I will focus on workforce IAM. I will start with the dilemma that we face every day with our teams. On the one hand, we have to provide a secure infrastructure and secure services. Risk mitigation compliance is our daily business, and that must be there. On the other hand, we have seen it. We have thousands of applications, thousands of application owners. We have the developers behind these teams, and they need to implement fast business value.

They make a lot of pressure on us. They don't want to be hindered by IAM and borders and frontiers and gates. They want to be fast. Traditionally, we try to solve this problem in a way that we try to improve security with minimal business friction. Some years ago, we started shifting emphasis, and we put much more accent on business enablement. Business is faster today. We have self-services. We have automation. What was interesting in this journey is that at the same time, we increased business value, speed for the business. We were also able to raise our security to a new level.

That's introduction stage motivation, and I can start with some identity self-services that we have in our portals. When we think about self-services, we have to think about how software is developed today.

Of course, our software developers at SAP, they use AI. They have agents as well, but when they start, they need some infrastructure where the software is built and run.

Normally, our developers, they order these resources in an IT self-service portal. Everything is self-service.

Databases, compute resources, storage, everything is self-service. Within minutes, we have an infrastructure where we can run our software. Then it comes to IAM and application owners, software developers, they need to integrate our identity providers. They need permissions. They need credentials. They need certificates.

Normally, at least it was like that at SAP. They ordered these resources via tickets, and it took sometimes days and sometimes even weeks because our IAM teams are overloaded. We have too many tickets, too many requests. That's why we investigated a lot in automation in self-services.

Today, we are ready to have self-services for these resources as well, and we show you first of all one screenshot of our internal developer portal. You can see that there's only a short list of what developers can order at SAP. On the left side, compute resources. On the right side, already on top level, we can order app registration, integration with our identity providers, credential management system that not only orders wall spaces, but we have everything in a self-service that goes together with the credentials. We can rotate credentials.

We can integrate them seamlessly in our multi-cloud environment. In a self-service, developers are happy today with that. Another example is our API management platform. We want every API at SAP to be registered on this platform. This platform is fully integrated with our IAM identity providers, and people can not only publish the APIs with clear policy guidelines, but they can also apply for an API, and everything goes and works in a self-service. When you hear that, I know this is critical.

Normally, permissions are not granted in a self-service way in IAM teams. So, I have to speak about security, and I will start with the architectural blueprint that we use for all our self-services that we have at SAP BIM. When our application owners or developers order something, they communicate with our so-called consumer layer. This is the developer portals that you saw before, or it's also APIs, so they get their resources also in an infrastructure-as-code manner. That's the only thing they interact with.

Below, we have an automation layer, and at the core, a policy and guardrail layer, where we do all our security checks. We have policies, and once the policy enforcement is done at this policy layer, then we provide the resources to our consumers at the top level. Important is a side layer. We call it implementing cost-cutting concerns, logging, audit, monitoring, and the important thing is here, every request on the consumer layer, every order that is done by our application owners, by our developers, are locked.

The same is true for every policy decision in the policy and guardrail layer, so we have a complete audit trail of every source that is ordered in our self-service portals. This is the architectural blueprint, and I'll now make it concrete and make some examples on how we implement the self-services for concrete IAM resources. At the moment, we try to create a workflow for ordering AI agents in a self-service. I don't have a finished graphical user interface yet, so it's more or less the same thing as the creation of a single sign-on app registration with one of our identity providers.

And where do we start? We start with our corporate directives. That's the piece, our Konzernweisungen in German, and we try to map or to translate these corporate directives into concrete guardrails and policies. So we have, for example, we want to have clear owners, we want to manage the lifecycle, we want a complete audit trail through permissions and everything that goes together with these resources, and we translate these directives into clear policies and implement them in our policy and guardrail layer that you have seen before with the architectural blueprint.

Then we go on and create the workflow with clear constraints for all these resources, and then we design the graphical user interface and today our consumers, application owners, are quite happy that they can order all these resources either through the graphical user interface or infrastructure as codeways. And what is interesting, they don't even notice how narrow they are constrained through our policy framework. They only operate in a very narrow corridor that is safe, and they have not much possibilities to do something that is not compliant with our company directives.

In this process, we have a principle that we call an inversion of control or shift of responsibility, and I will try to explain that with a concrete example from the Microsoft Graph API. When we develop an application, it is often necessary to get some centrally managed resources.

We need, for instance, to get the group members, we need some information about the user in the application, or we have to send email, and some of these resources or permissions are, for instance, provided through the Microsoft Graph API.

So how did it work previously, a few years ago, when some application owner needed one of these permissions, sending an email, reading group members from the groups, they created a ticket with the IAM team, the IAM operations team, then contact the application owner, asked for a justification for this permission, then reminded this application owner of this privilege, all the obligations they have that come together with this permission, and then if everything went well, they granted the permission and documented everything for audit.

The important thing with this process was that it was the IAM team that granted the permission, so the responsibility finally stayed with the IAM team. So let's have a look at how we do that today. Today we have a self-service portal with a catalogue of non-critical permissions, and the application owners can check or click the permissions that they need for their application. Once this is done, they are redirected to a so-called Terms of Use page, and then they have to agree to the terms that we want them to do.

So we tell them, for instance, that they can use this permission only in the context of their application, that they have to respect the least privilege principle, and at the end, they have to accept all the risks that are associated with the permissions they get. And only if they consent to this screen, they can enter a justification or a reason, and then they get this permission directly in a self-service.

And the interesting point for us is that instead of IAM teams that grant the permission and take responsibility for this permission, it is the application owners that take the permissions by themselves. Responsibility is there where there must be with the application owners that know their resources, they know the risks that are associated with these permissions, and everything is at the right place. We use this shift of responsibility pattern also elsewhere. I've previously shown this, our API management platform where all our APIs are listed, and here we use exactly the same pattern.

On the one side, we have a self-service for publishing APIs with clear guardrails, with security models that are mandatory for API providers, and on the other hand, we have consumers that may request access to an API, and it's finally, again, the API provider that grants the permission to the consumers. As an IAM team, we provide the infrastructure, the processes behind, we grant the permission on the level of the IDP, but we don't grant permission by ourselves.

Responsibility stays there with the application owners that know their business, that know the risks that are associated with their resources, and permissions are at the right place. To make a short summary, what do we need to implement secure self-service processes?

Of course, we need APIs for all IAM resources that we provide to our customers, and of course, we also publish all these APIs in our API management platform. We need strict policies for each resource type. We need a clearly defined authorization system for each resource type, audit trails, traceability for everything, and that is really important for us. We don't want to just have an IAM portal, but we want to integrate all our services into overarching IT processes at SAP.

You have seen we have self-services for quite a number of resources already, mainly in the non-human identity part, but we are by far not finished yet. What is missing at the moment is we have policies as code, but currently we don't have a unified view for our management, a dashboard or KPIs that we can show. It's a pity because we have tens of thousands of app registrations already that we manage through these self-services. We have 100,000 credentials that we manage through these self-services in our processes.

We have thousands of APIs, and we have still the same small IAM team that is able to manage resources as 10 years ago in manual processes, and we cannot show that to our management what we have improved during the last years. And of course, we still have quite a lot of manual processes for all the critical resources, so we do not do everything as a self-service, and we will never do everything as a self-service at SAP as well. I have started with the IAM dilemma, and I've told you that we focused heavily on the right side of business enablement during the last years.

We made our customers happy. Developers, application owners are happier, they're faster and more efficient. And at the same time, we made also our CISO happier because we were able to raise our security level to a new level. We now have guardrails instead of gates. We have security by design, policies as code, and we have a governance that scales. So the automation, we are ready to scale the whole processes also through Zero Trust. We have more and more fine-grained policies, and we have more and more policies to manage. And finally, that is a side effect that is quite nice.

We have, through these automation processes, clean data. And this is important for all the AI tooling that comes now along that we want to use at SAP as well. I'll stop with some closing remarks. We are codifying compliance by turning rules into code. We have self-services, and we have the self-service designed in a way that business assumes responsibility and risk. And we have a trusted automation so that we can sleep well normally. So I'll skip the remaining slides, and thank you for your attention.

Of course, our sessions are hybrid, and we have some online questions. One question is, what tools do you use for policy interpretation and enforcement across your stack? We don't have a policy language defined yet. So for each resource, we have our own policies that we implement by ourselves at the moment. So if you have any questions to him, you can just approach him, and feel free to do that.

Thank you, Christian. Thank you.