Hi. My name's Todd Peterson. I'm on the team here at One Identity, and today, we're going to talk about a concept called privileged access governance. So let's turn to the board and get started. So as you probably know, there are a couple of disciplines in identity and access management. One would be the provisioning and governance discipline, things like request, fulfillment, or provisioning, and then the attestation of that provisioning action.
And the other would be privileged access management. That's things like managing the privileged passwords, making sure that they're not shared as much as they need to be, a delegation, giving people only the rights they need to do their jobs, and then session audit, watching what people do as they use that privileged password and do administrative activities. So in most organizations, the governance stuff is happening, you know, just fine, and the privileged access management stuff is happening just fine, but they're fairly disjointed. Let's talk about why that is and how we can overcome that.
So in a normal organization, you have a solution that's going to provide provisioning for everybody. You have requests, which leads to provisioning, which leads to attestation, which leads to more requests, and that normally applies on your on-prem applications, your cloud applications, your Active Directory, and all the normal stuff, you've got within your enterprise.
But then you have a privileged access management solution, and it requires you to request a password, request an account, set up that account, or that privilege access, and you also have the governance needs to attest to that access. So you often have duplicate governance tasks happening once for regular users with access to applications, but another time with privileged users and access to the privileged access management solution.
So when you look at the types of governance questions that need to be asked in both these scenarios they're slightly different. In the regular end user accessing in applications scenario, the governance questions are is this person supposed to have this access, who granted them that permission to have that access, and do I, as the line of business person, certify that that access is appropriate. That's fairly common. We're all used to that, and that's the normal attestation campaigns that we go through periodically all the time.
But we also have to do those things for privileged access, for administrative accounts, the root account, et cetera. But the questions are slightly different there. So who is the owner of the host? Who is the owner of that privileged account? Should that account even be privileged? Should this individual person actually have access to this privileged account? And should this person actually be a privileged user?
So it's the same, you know, is this correct, do I certify that it's correct. But the nuances are slightly different on a regular user accessing regular stuff, or a privileged user accessing privileged stuff. Governance is required for both, and you can't get away from it, but it's difficult to do in a unified manner across both, unless you have help. So let's talk about how we can do that.
So imagine if your privileged access management solution, so your password vault, your session audit, your delegation solutions, and your governance solution, your provisioning, your attestation, your workflow solution were talking to each other, were unified, were supporting each other. Then you would have this same process of request to provisioning, provisioning to attestation, and back to request, this cycle would continue, but it would take into account all of the regular things you're using, as well as your privileged access management solutions for both your regular end users and your privileged users.
So I, as an administrator, I have a regular end user account. I have an email account. I have access to expense reporting or whatever. That is taken care of in the enterprise governments. But I also have privileged access. I have permissions within published accounts. I have workflows that apply to me within the password vault.
You need to attest to those as well. So you can unify these solutions with One Identity Manager and Safeguard-- that's our provisioning and governance solution-- and our password vaulting and session audit solution. You get both. You get the ability to do a single pane of glass across everything, a single policy framework across both privileged users and regular users, a single unified attestation work flow. People don't have to work differently because they're doing an attestation on a privileged user than they do on a regular user, and you get full governance across the entire enterprise.
This scenario also applies to things like unstructured data, as well, so not only your regular users accessing applications, your regular users accessing unstructured data, but you're privileged users accessing privileged systems, and privileged credentials. So what you end up getting is enterprise governance across everything. You eliminate the guesswork in privileged access management, because the governance is actually taking care of it.
You govern the highest risk users and those assets that are the biggest target for bad guys. The things that need governance the most are now easy to govern in the same paradigm as everything else, and it streamlines a request and fulfillment process. You don't have to do things once because you have a password save, and another time because you have end users accessing other things. It's the same for everything.
Some of the benefits on top of that come to specifically for privileged account management are risk calculation. You can do heat maps that say this particular user, the risk associated with his permissions in this system are higher than others. We need to look at that. You can add identity and behavior analytics to find instances of the potential for somebody to do something bad, because their permissions are out of line with what they should be, and behavior analytics, which looks at actual incidents of people doing something wrong,
07:45
