DEV Community

Cover image for AWS re:Invent 2025 - Solving the Cloud Privilege Problem at Scale: A Fiserv Case Study (COP213)
Kazuya
Kazuya

Posted on • Edited on

AWS re:Invent 2025 - Solving the Cloud Privilege Problem at Scale: A Fiserv Case Study (COP213)

🦄 Making great presentations more accessible.
This project enhances multilingual accessibility and discoverability while preserving the original content. Detailed transcriptions and keyframes capture the nuances and technical insights that convey the full value of each session.

Note: A comprehensive list of re:Invent 2025 transcribed articles is available in this Spreadsheet!

Overview

📖 AWS re:Invent 2025 - Solving the Cloud Privilege Problem at Scale: A Fiserv Case Study (COP213)

In this video, a Fiserv representative shares their experience partnering with Sonrai Security to manage IAM challenges across thousands of multi-cloud accounts. After an SCP-related outage, they discovered Sonrai's automation capabilities at AWS re:Invent. The POC took 30 minutes to deploy via CloudFormation templates. Key features demonstrated include managing excessive permissions, zombie identity hunting, service controls for AI governance, third-party access visibility, and region management. The solution automated SCP deployment across 1,000+ accounts, saving over 1,000 hours and 38-40 lines of code per account, while providing centralized visibility and workflow automation that existing tools couldn't deliver.


; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

Thumbnail 0

Fiserv's Multi-Cloud IAM Challenge and the Path to Finding Sonrai Security

Welcome. I know it's happy hour and you have dinner plans, so I'll keep that in mind. The main reason I'm up here is to encourage you to visit booth 435 and check out Sonrai Security. Thank you.

That's the agenda. We've been partnered with Sonrai this past year, and this presentation is about that partnership and what we found valuable about it, and hopefully you can do something similar. It's going to be four simple steps. First, what was Fiserv's challenge? Why were we looking for a solution? Second, we're going to talk about tools and what it can feel like when you're trying to go through the process. Then we'll discuss the turning point—what was it that we did with Sonrai that actually made a difference and why we chose to move forward. And of course, the results.

Thumbnail 40

Fiserv is a financial services company. We're global and we probably touch every household in the United States, though I'm not sure if that's physically true. We have grown, merged, and continue to acquire and merge companies. Over the years, this has led to us becoming multi-cloud with thousands of accounts that we have to manage globally. Every time you bring another company together or buy another product, you have what I call a permissions tornado. IAM is difficult, and we know this because when AI is all the hype and we work in a regulated industry, you always have to prove that you have your cloud under control.

Thumbnail 70

One of the things we were trying to implement, especially with the rise of AI, was controls. Everyone wants to know what you're doing about AI. We actually tried to implement some controls and made an assumption about SCP inheritance that turned out to be incorrect. We actually took an outage, and this happened in the middle of last year right before AWS re:Invent. It just happened to be at re:Invent where I was looking for swag. In that process, I ran across Sonrai Security. There was something called a zombie hunter, and I was attracted to that. I walked up and we did some small talk, exchanging what we were doing. They said they automate creation and deployment of SCPs. At that point, I forgot about the t-shirt I was hunting for and the sticker. We exchanged numbers, had a second meeting, and did a POC with them, which went great.

There were a few CloudFormation templates, and I think it took about 30 minutes to set up. Ryan, my partner, set that up, and it took several days to do the analysis. When we saw the numbers, which we'll show you more of in a bit, it was clear there was more to this than just our immediate need. We said, let's continue this relationship and consider buying it. Then we had to address real questions. Do we need another tool? Why this tool? Don't we already have a tool that does that? Who's going to pay for it even after we get it up and running? Who's going to operate it? Is it a cyber tool? Is it a cloud infrastructure tool? What is it?

Thumbnail 220

For us, the fact that we did the POC, and I would encourage you to do a POC, is that we had our data right there for us to see and it was easy to do demos with other partners in our business and in particular leadership. When we worked out the fact that Sonrai offered something that we didn't have in any other tool in any other way, and it was even more than that, we decided to go ahead. The reason I brought all of that up is because this is what it feels like sometimes when everything's going on. You're in one more meeting, one more question, do we do it again? It's worth it if the solution fixes your need. That's why we did that.

Thumbnail 300

How Sonrai Security's Platform Delivers Automated IAM Control and Measurable Results

This is where I'm going to spend most of this time. I'm actually going to explain this.

I'm only going to explain enough for you to be interested to go to booth 435. Remember my agenda? At the top, what you'll see is the scope with a little dropdown menu. You can apply this at the root organization, any of your organizational units, or you can go down to individual accounts. Whatever scope you pick, those numbers will change to reflect what's based on that scope.

These are hero cards, I assume because you're a hero if you take action on those. The first one is IAM users and roles with excessive permissions. This is where we show you all the policies that were probably written with a wildcard. They're over-permissioned, but in particular, they're not in use. So they're being flagged not just for being over-permissive, but because they're simply not being used. You can take action by clicking on that button, and it will stage some things and do some things. I'm not going to tell you all the details—that's their job—but what it does is prevent them from being used. If someone tries to use them, it will set off an alert, and there's a workflow that you can take to give people that permission if they need it. What it does is quickly give you that layer of control.

The second one, the whole reason I was hunting those stickers, is the zombie hunters. Zombies represent identities which haven't been used. It's not about the permission itself, just that they're not being used. It's junk in your accounts. Much like the protection I mentioned, you can quarantine the zombies such that whenever something happens, like if it's a quarterly thing that runs, there's a workflow that gets triggered. Someone can then take action and reach out to you saying, "Hey, I see this alert. What is it? Do you really need it?" There's action, automation, and then also the workflow behind it. Those were the things that we didn't have in our system. We predate AWS Control Tower. We have our own control tower, so to speak, and this type of stuff wasn't built into that, at least not in this way.

The third one is the one that we were really looking for from the start. We have new services, new AI services coming out, and we can use this to turn them on or turn them off. It was nice to be able to see across thousands and thousands of accounts just how much we have in use and not in use, and then we can drill down to any level. Anytime we're working with one of our app dev teams, we can pull this up and get another view of the data that shows they have junk in there, over-permission stuff in there, and whether they need that service. We use that now as part of the AI Center of Excellence. When teams have an AI project, they can come, get approved, and then we use this to turn those services on for them.

The third parties feature was actually not something that was on there when we first looked at it. That was something they were adding. The nice thing about that is in a single place we can go and look in any account and see who's partnered with us. Hopefully it's all okay, but normally it's been vendors, SaaS vendors, people they have relationships with like Snowflake where you have database connections and things like that. But you can also drill down from there to see the policies. That's something again to try to go see all of that information. The natural way through a query or whatever would be a lot more difficult. Right here, just from this console, we can really drill down, and if we choose to take action, you can block it.

That takes me then to the regions. Regions is, just like it says, every time there are new regions. AWS brings up good examples like India. For a long time, there was only one region there. In banking, you need two for disaster recovery. We've always struggled with that other region. So when the regions come on, we can now say, "Hey, does this application actually need to be there?" We can control that that way. Down at the bottom, you'll see the services. If you click on the numbers across the bottom or in the service layer, it will tell you how many people are using it, and you can also drill into the sensitive permissions.

Thumbnail 630

This is what Sonrai Security has done for us. They have people all the time working in IAM. That's a full-time job, and they've made it very easy for us. We don't have to guess now. We take their sensitive permissions and you can choose to protect again. The key to all of that is when you take action in the far corner up there, you'll see the deploy button. It'll take you to see what is staged, and from there you can deploy it. I'll let them explain exactly how that works.

Thumbnail 670

I want to point out the lines of code and the hours saved. This essentially refers to the fact that if our policy is about 38 to 40 lines per account and we have over 1,000 accounts, that's lines of code that we didn't have to copy and paste, change the information, and deploy. If I just calculated an hour per account, we've saved over 1,000 hours. The numbers are probably a lot more than that, but it is a way for you to look at how this tool can pay for itself.

Thumbnail 680

With that, I have to go because I'm over time, but thank you, everyone. You can talk to me. The Sonrai Security guys are at booth 435. I appreciate your time.


; This article is entirely auto-generated using Amazon Bedrock.

Top comments (0)