Name: Beyond Backup: Immutable Recovery for Okta and the Multi-IdP World
Uploaded: 2026-01-15T10:46:11.200Z
Duration: 30 min 8 s
Description: Beyond Backup: Immutable Recovery for Okta and the Multi-IdP World

Transcript for "Beyond Backup: Immutable Recovery for Okta and the Multi-IdP World": Everyone. Thank you for joining us here for Beyond Backup, immutable recovery of Okta in a multi IDP world. My name is Carl Norwich. I'm the director of go to market for new product innovation here at Rubrik, and I'm joined by somebody I've known for a couple years now, and we've had an opportunity to share ideas and talk about Shop here. Wayne, you wanna introduce yourself real quick? Sure. Hi, everybody. My name is Wayne Smiley. I'm a principal solution engineer at Okta, and I cover our tech partners. Yeah. Alright. So Wayne and I are gonna walk you through a new offering that Rubrik has that's specifically focused on Okta. However, it does address multiple IDPs in a singular platform. And this is a, obviously, a, you know, co webinar, if you will, between the two companies because we see unique value in partnering in these regards. So in that light, what I'm gonna do real quickly is I'm gonna hand the floor over to Wayne. He's gonna talk a bit about some things that he wants to update you on the Okta side that are pertinent both from an Okta perspective, but also an Okta Rubric perspective. And then we'll, from there, pivot more indirectly to what we're talking about here in terms of being able to back up and recover your Okta environment. Wayne, with that, let me get you to first slide here. Go ahead, sir. Thank you very much. So I know that Carl's going to talk quite a bit about backing up Okta and things like that. But before we do that, I want to talk about one other integration that Okta has with Rubrik and how all this works together. Look, let's be honest. We all know that breaches are happening all the time. This is an old step, but still still relevant that seventy eight percent of all companies experience some sort of breach in 2022, for example. And most of these breaches actually come out of stolen credentials. So what this has done is it's made us need to rethink security around identity a little bit. So we've gone beyond just the authentication. We know that Okta does a great job of authenticating users and making sure they are who they say they are. But what happens as things change over time? What happens when they go to do something else? What do we do then? What really happens is that there's kind of a gap over time. When somebody logs in, know that the user's okay and everything's fine, but over time that can change. Things can change. Things can happen. So let me give you an example with Okta and Rubrik. We're using something called Shared Signal Framework, which is an open source standard to keep data consistent and constantly moving between the two the two different systems. A good example of this. Let's say somebody with Rubrik is going to pull some data out of a system and that system has social security numbers, something along those lines. They can, in the background, tell Okta, 'Hey, before I give this information out, in real time, while this is all going on, I want you to do a multi factor authentication request for this user to confirm again they are still who they say that they are.' That can happen and off they go. Pretty frictionless, pretty easy, but really a major change in security and a major advantage for that. So we don't do this just with Rubrik. We actually do it with lots of companies. And this slide's a little bit outdated. There are a lot more. But the point of knowing all this and why this matters so much is that that shared signal framework can do things like, if a machine has been compromised, we can do universal logout as well and other things similar along those lines as well. And I've already mentioned this, but this is basically how it all works together. And you can see here that they can come in from anything, go through Rubric, and then talk to Okta, and Okta can shift its its posture on that particular user if if anything happens. So anyway, with that, let me turn it back over to Carl, and let's let's dig into the backup side of things. Appreciate it, Wayne. Alright. Let's get into it here. So, you know, shifting gears a little bit here, is that obviously everything's kinda wrapped around this idea of security. Everything Wayne discussed is what is Okta doing to make sure that you could do additional checks and multi factor authentication for things that are high risk. And the reason all that is, I heard this recently, is that right I talked to a CISO at a Black Hat actually, when you may not have heard this, 70% of their phishing tests fail. Meaning, like, do a phishing test with their internal users, 70% failure rate, which was kind of terrifying. And I think what we can take away from that is users are going to do users things, no matter what we try to do from the operations and security side. Now, that's one thing that we'll talk a little bit about. Certainly Wayne talked about how we secure our states. But secondarily is that if the goal of the bad actor, whether it be a state agency, whether it be gang or the otherwise, is they've started to figure out that if they want to cause pain and business disruption, they attack the IDP. That kind of makes sense because the IDP is the focal point for authentication of your applications and machines, and of course users and even customers in some cases. So we're seeing a staggering increase in the direct attacks on the IDP, whether they get other things in the process or whether they're purposely just targeting that. The other aspect of this that brings a little bit of complexity and Wayne and I had a little bit of a sidebar about this, but I mean, the reality is that we love in a perfect world, everyone's shipped a 100% to Okta, but you may have reliances on AD still, Purebros driven application authentication and the alike. Then because of that, you find that about 75% of organizations out there have more than one IDP in house. So you have to not only protect obviously Okta, which we're talking primarily about today, but all of them are your gold jewels in terms of authentication clearly, or you wouldn't have them in the first place, right? Yeah. You know, Karl, one of the things we talk about, sorry to interrupt you, is that over 50% of our customers use Office three sixty five, which means they're obviously by definition using probably three IDPs at that point. On prem AD, Azure, and Okta as well. Absolutely. I mean, yeah. I mean, you've seen a lot of different displays. You just can't get away from Kerberos. We're trying. We'll get there eventually. I think the world is trying. Companies are getting there, right? But for now, this is just a practical world we live in. We live in a highly volatile environment in terms of attackers, and we're living in a somewhat dispersed world in terms of identity providers. Right? It's just kind of the reality. So let's kind of shift over to like, what is Rubrik's lane here? Right? Because what I do is I need new product innovation. A lot of times I'm working with vendors like Okta, and it's a really important for us on the provider side when we're partnering here is that we're not overlapping. We need to understand the responsibility of the vendor that we're partnering with and make sure that for you, the customers out there, that we're bringing very implicit value and filling in what we call a white space. What is not being filled by other providers out there? So the way to think about how does Rubrik partner with Okta and where are we providing value, not overlapping is really, I think this is a great slide for that. Is if you think about Okta's doing, where their engineer focuses and everything else as it should be, is all around, how do I secure identities? How do I become the best provider from an IDP perspective I possibly can be? Again, Wayne just went over some things they're doing creatively by partnering with third parties like us. And at the end of the day, if you're relying upon Okta, obviously, service availability and a traditional BCDR mindset is really on top of mind. Right? Is that and Wayne, I don't want to steal your thunder, but it sounded like even the AWS is that it was a little bit of a blip. But I mean, Okta in and of itself is really focused on those things. Is that fair to say? Sure. I mean, and and you can bring up a perfect example of that. So AWS had an outage recently and Okta was pretty well unaffected. There were a couple of small things, but the reality of it is that most of things worked exactly the way they supposed to. Where you saw massive outages around the world, and this is because Okta takes the service availability extremely seriously. We are head to shoulders above our competitors when it comes to that sort of thing. It's really, really important to us. And I think that's a really strong point, but obviously that leaves room for things like backup, which obviously Carl's going to talk to you more about. Yeah, no, absolutely. And so that's really the line, right? Is that, you know, let's just be pragmatic too, as engineers, is that if Okta went away and I had all your backups, it doesn't really matter because the platform's gone to begin with. So, I mean, there's some pragmatic things there, but with all that being said, all that preface there is that where can we bring additional value? Is it, if we think about what they're providing is that you lack some granular rollback, retention, get air gapping. I mean, you can certainly sandbox, which I'd encourage you to do just for good operational cadence and testing as well. And also we'll talk a bit more about this is that, at the core of Okta, there's a general term called a relational database or this idea of dependencies, which we'll talk more about. But the net net here is that there's a partnership opportunity here where we can bring better value together. And that's where we wanna focus on, but that line clearly is availability, bringing a world class identity provider to market, certainly on opt in, we support them and we're actually a customer as well. We cannot nod as a corporate entity, but we wanna really laser focus on where our roots are, is that where can we bring a better backup or after the fact, if you will. All right. So I wanna talk a little bit about this. I poked at it a little bit because the audience that we're having right now, Wayne, I'm sure they're thinking about us like, Hey, how do you pull data? How do you do this? And everyone's kind of like, I've talked to a lot of providers. I'm sure you have too, is that our customers should say, they kind of stitch their own thing together sometimes because there's APIs that can make polls, they can grab their groups, they can grab their users, and that may be to some extent functional. The complexity comes where Rubrik really has a lot of experience here because there's some similarities here with things like Salesforce, for example, Entra, for another example, Jira and others, is this idea of interdependency mapping. What do I mean by that? What I mean is, is if we imagine just a chain real quickly here on the screen that we have, we have a user. A user's gonna get a unique object ID effectively. Believe that's what you guys called as well, right, Ryan? Yeah. Close enough. Yeah. Close enough. So what we're gonna do here is that I wanna have that as a part of a group. So instead of literally moving in there like a traditional database, I'm gonna point or create a pointer between a group and a user. And then from a group, I wanna enforce a policy. So I'm gonna point a policy back to a group and so on and so forth. So it's the idea that I have all these disparate things that are pointing to one another with metadata effectively saying this one points to that, this gives them permission here and so on. And it makes for a very dynamic engineering cycles for the Okta team to get things faster to market is more modern. But here's the rub. Imagine this web of things is that I incidentally are a bad actor goes in and deletes a group. They disable it, they delete it, it's And you say, and you don't realize the first day a day or even a few hours. And things have changed around in this web of different pointers. I have different users now. I have different policies and so on, but I go and I restore a group to yesterday while everything is today. Things tend to break. Things are out of sync. This is a really important thing to understand and think about when you're considering how am I gonna do on operational recovery. And again, the vein of this is really twofold. Instantial operator deletion, which again, Opt has done a good job of saying, hey, you need to disable first as Wayne educated me recently before I can delete. Or a bad actor, getting a credential exactly to what Wayne said and starts blowing stuff away. You need to think about how am I gonna functionally and quickly operationally recover opt in. This is the big crux of it. This idea of independency mapping and the relationships amongst all these different objects. So with that, what Rubrik wants to bring to market is trying to fill in that gap, but also bring enterprise grade backup and recovery functionality to the marketplace, just like we've been doing for the last eleven years. So first thing we wanna do is we wanna assure or guarantee your ability to recover. I'll talk more about architecturally how we do this, but if you're not familiar with Rubrik as a brand, we've made our bread and butter, so to speak, on this idea of data resilience, always making sure the data is available for recovery, regardless of what has taken place. We're gonna talk more about dependency aware rollback, but how nice would it be if you needed to do one of these recovery again, whether it be mass, whether it be minor, whether it be micro, whether be a bad actor, whether it be incidental operator. What if you had a system that told you exactly what you had to recover to make it an operational production ready recovery? And then lastly, of course, all the compliance reporting that's required for the SOX and otherwise, is that we wanna bring that enterprise grade wrapper of all the Fortune 500 and others that we deal with all over the world to bear on being able to provide that same type of solutioning for Okta. And let Okta focus on identity and access management and make it a great partnership. And if you overlap this Venn diagram here, at the end of the day, you're really gonna have a world class solution that's fully end to end. Now, the other thing that I mentioned when I opened here, and I think Wayne acknowledged as well, that the reality is, is that you have disparate IDPs for the most part, at least the majority of customers out there do. And the thing that really makes Rubrik different is, is that we don't just stop with Okta. We can give you a full identity resilience conversation around active directory. Likewise, what I just mentioned with dependency understanding, dependency mapping and recovery, we have those same services for Entra ID as well. And I believe that at the time of this recording, we're the only provider in the marketplace that can support all three in one platform, one solution. So this really is meant to be your one stop shop here. All right. So just a little bit deeper into this, and then we'll talk a bit about architecture, but this is a little bit of a repeat, but first thing I want to mention here is this idea of immutability. Is that what we do is we secure the data in a way that it can't be molested in any way whatsoever by operators or by bad actors. And again, that's how Rubrik's made its bread and butter. I'll talk architecturally how we achieve that here in a moment. Our first iteration of the product supports users, groups, applications, policies, and from there, we'll be fast following additional objects that are within your Okta tenant, eventually supporting all the critical objects within your Okta tenant for a full tenant recovery. Secondarily, if you haven't again experienced Rubrik at any point in time, is that one of the things that we really hung our hat on in early days and have really leaned into is this idea of granular rollback and easy searchability, very Google like in nature. Being able to give you the ability to type in a couple of characters with a wild card and it's gonna present all those options. Because if you have a lot of groups, for example, or you have a very dynamic user base, it makes it so that you can quickly both identify them, but also do that granular recovery that may be necessary in the scenario that you may be. But of course, we're gonna give you the mass recovery functionality as well for the tenant as is necessary or as the situation demands. And lastly, this idea of dependency aware orchestration. So again, back to the example here where you see in our screen, which is a snapshot of the product here, is that you wanna go and do a recovery of a particular group. For example, there could be downstream impacts and because of all those pointers, right? The metadata is pointing back to it that you're gonna break stuff. We have a dependency aware engine that's core to our system that we have years of experience with because we support Salesforce, because we support Jira, because we support Entre. We understand this to begin with. Our framework was built specifically for this. So when you need to go through and do a group recovery, for an example, the system is gonna coach you and tell you exactly what else do you need to recover to make sure it's a production ready and operational ready recovery, taking all of the mistakes and all the guesswork out of the recovery of something is typically known as being very tedious. And that, again, that's not an Okta thing. That's a design thing by this type of data mapping. You know, one thing I was gonna say, Carl, the granular world back to me, I've always thought is the greatest thing. Back when I was an AD administrator, you know, dinosaurs were roaming IT still. One of the things we used to say is stuff like that can help you deal with everyday disasters. Right? Somebody makes a boo boo and at least you can easily use something like this to go back and fix it without just causing a massive amount of pain in order to do so. I think that's a really big Yeah. And you're right. I mean, it's all the backlog because those little tedious things pile up. They take time out of your day and time is finite, right? And the good news is the back when you're administering AD, it's more or less the same. So you could still technically go do it right now if you wanted to go back to the future. That's okay. No, thank you. So yeah, I mean, the grain is clearing your backlog, making it easier and more operational is certainly there. And again, the big boogeyman that I don't like being hyperbolic, but we do have consider is the big deletions that may be malicious in nature. It can address both of those things. Of course. All right. So how do we achieve this? First of all, this gives a good idea of just the mapping of the solution in the first place. Now, the first thing I should mention is this is a full SaaS to SaaS solution. Commercially, when you write us a check, so to speak, based on our user subscription, is that it's all encompassing. Meaning that accounts for the storage that's required, the compute that's required, and of course, they're capturing the backups. There's nothing ancillary that you need to provide us that has incremental cost to you. Everything including the storage. And that's very much by design, both from an experience perspective, the way you consume it. But secondly, we have to own the data, that landing spot to give you that immutability. If I'm simply writing data to an S3 target that you provided me or something of that nature, I no longer control the underlying APIs. So what's really important to understand here is that this framework was built specifically for this type of data workload. This is the same framework that supports our Salesforce offering, our Jira offering, and the alike. So for us, was like, hats off to my CTO, Nitro and others as they saw this coming. So instead of writing one offs for every relational data source that we wanna support in the future, they wrote a framework or a system that was designed for it. So we can just write into the APIs of the various providers that we wanna support. Now, this is hosted in Azure and is written in a Blob store. But the reason I bring all of that up is that there's APIs inside a Blob or object, just generally, whether it be S3 or Blob or any of the others. And there's one particular that we're leveraging. It's called an object API lock. That gives you effectively the same look and feel of immutability. And what we do is that every time you write a backup, whether it be the first full or the incrementals that will obviously follow thereafter, is that we engage that object locking API so that the data secure, not even the hypervisor or hyperscaler, pardon me, wrong vernacular. Hyperscaler can go and delete that data. Every on a cadence, go and we double check and compare your retention, which can be whatever you'd like it to be, whether it'd be a month, whether it be ninety days, whether it be a year, whether it be two years, that's really up to you and what you need for it to suit your need. We go in and we check, is this thing gonna need to expire in this next window? And then we'll reset that API object lock on each of the objects So to make sure that the data is always secured, leveraging that very secure API. So rest assured when the data is at rest in our system, it is locked and we're leveraging that technology to do that. Now, I should mention is that the way that we connect here, the way that we connect Rubrik Security Cloud back to your tenant is that we are, don't have, Wayne Smiley does not have credentials to log into our framework and log into that Blob Store, nor do you the customer. Remember this is a full SaaS to SaaS solution. So as if you're Wayne, I think you opened with this. If somebody stole credentials, right? Or administrative, they wouldn't even be able to use your credentials to go log into our framework, go directly mess with the data in any way, in any direct fashion whatsoever. So there's layers and layers of support here that are all oriented around this idea of zero trust or assume breach. So this is a bit about the architecture, and this is how we achieve this assured ability to recover, which is really the outcome that we wanna make sure that you walk away with here. All right. So I guess in closing here, the biggest things I want you to take away here is that again, our first offering is to support policies, apps, users, groups. The solution itself is gonna give you the immutable backup, the orchestration engine for recovery. And the other thing I wanna mention here is SLA based backups. That if, and Wayne, you're gonna laugh at this because you just dazed yourself, so I'm gonna take advantage of it a little bit. That's fine. Go ahead. There's no concept of a backup job in Rubrik. Our entire platforms from day one, from one dot o code, has always been around this idea of a SLA based backup. Meaning, you simply tell us, wanna back up this often. I wanna keep it for this long. Point us at your tenant. Your hands off as an operator. We handle the rest. Retries, failure retries, all the alike. So you can expect that here as well. So once you deploy us, which will all be done through, was it OIN or ONI? Pardon me. The marketplace. OIN. OIN, thank you. Sorry about that. You got it. You got it right the first time. I got it right the first time. There you go. We'll have a connector there. It's gonna connect to our tenant. You provided some one time credentials. We handle cycling certificates, everything that you possibly need. You set up the backups and now you can go to sleep at night resting easy. And know that at the backstop here is that you're going to be able to do restore dependencies. You're going be able to do mass restorations. And then ultimately, if you are multiple IDPs and you choose to move forward to Verbrik, is that we could be a one stop shop for all of your different identity providers in place, one platform. So does this mean I'm not going to get 120 meg Capes in the mail? I'm confused. I'm sorry. No, no. We've modernized. Now we send USB keys. Oh, okay. Fair enough. Right. So this is a bit of the NASCAR slide. I'll leave this up here for a moment, but again, over 3,000 customers trust Rubrik with their identity protection. Obviously, we're just ramping up with Okta, but we expect that to ramp extremely quickly. My guys, I run I do run a sales team. My guys, when we were at Oktane were mad at me because we weren't able to quite sell the product yet because there was so much interest. You can anticipate us very much quickly leveling off here. But in general, identity is not new to Rubrik whatsoever. We've been doing it for many, many years along with data. We want to bring that value that Rubrik's brand is known for in terms of data security and an assured ability to recover now to Okta, which we're really thrilled about. So if you want to learn more, we'll leave this link and the lead behind. We have a dedicated team that only focuses on this relationship with Okta that can talk more deeply. We're also engaging directly with Okta representatives in the field because as we are kind of going to market together to some extent, obviously, as you see Wayne is here, we're happy to give you more information, give you demos and hopefully meet any of your needs. Any closing remarks, Wayne? No, no, I think this is great. I think I'm really excited about this and I look forward to it. All right. Thank you so much for making the time Wayne. Thank you. Appreciate it Carl. All right. Thanks to everyone.