Identity Access Management

00:00

hi and welcome to module to lessen 6.3.

00:04

And this lesson we're gonna talk about identity and access management

00:08

now I am is a lot more than just maintaining user name and password combinations. It's a comprehensive program that encompasses everything from provisioning to administration to enforcement. It's all of those things that we need to do to create access for a person,

00:25

to give that person access to a data set and into monitor that access to make sure that the access is correct going forward.

00:33

It works best when there's a single authentication source that to allow for a centralized management so you can use active directory or some other source like that as your source of record. On def, you you limited to a single authentication source instead of having,

00:47

you know, users who log in tow one thing using an actor director credential and then this other thing using a local account on the system itself,

00:56

you're gonna be able to manage that much easier

01:00

when it comes. I am provisioning provisioning refers to that initial request. You know, when it how How do people request access? How does that even happen? Um, HR change contributor that right? So when an employee gets hired on, there could be some some trigger that starts a workflow that that initiates this request. But

01:19

if a user needs

01:21

access, if existing user needs access to something, how does that existing user access or air send that request? So I am. You have to create policies around how that request comes in. What are the official ways that it can come in? Who validates that request, right? Just because the user request something doesn't mean that they actually need access to it. So you have to have someone who validates that

01:41

to make sure it's

01:42

it's legitimate and then approves that request. There should be some sort of a formal approval flow

01:48

also. Then there's the assignment peaks. So once the approval happens, then it's the actual mapping of roles to that individual identity that needs to occur, and finally, some sort of communication back to the inn user or back to the manager of the inn user toe. Let them know that, okay, this access is now now active.

02:07

Role based access is a term that is used a lot in I am and role based access just means that instead of assigning a privilege to each individual account, right, I got I have an account and I'm gonna have access to this and this and this and this and this. Instead of doing that, I'm gonna take my account under, put it inside a larger group,

02:27

and I'm going to assign that group

02:30

access to these things, right? It does a couple of things. One thing is there's less policies you have to write on the actual data source itself, Right? So if it's a file server and you want to write a policy to say who can have access to these files, you just point to a single group instead of pointing to 50 people that might be inside that group.

02:47

The other thing it does is it allows us to change your users access very easily. We just take the user and we put him in a group. We take him out of group, move them between groups, and that changes their access without having to write new policy on every single data server out there.

03:02

So let's say we have a new engineer that comes into the company that engineers in to be assigned to the engineering group. Pretty straightforward. You see, p a they're gonna go to finance. But what if we have, Let's say, a director of engineering while we can put them in multiple groups, you don't have to put individual user accounts into individual groups that could be spread across multiple.

03:21

Maybe our engineer, that we hired a few minutes ago

03:23

got promoted and became a director of engineering. So over time, we need to add them to that executive group. Or maybe they're gonna later they move into another department. We need to remove that group. We can just

03:34

at a remove membership into groups, and that's that's makes life a lot easier. And that's what role based access is all about

03:42

when it comes to enforcement of I am. We can put those enforcement points on each individual data set or each individual in point, if you will. So, for example, let's say we've got a marketing employee who's trying to get access to the financial database. Financial it database goes inquiries, the source of record. Let's say, in this case it's active directory.

04:00

It queries a couple things. Number one, it says, Hey, does this user name and password combination.

04:05

That's authentication. Does that actually apply as is correct? And then there's an authorization piece that says, What group is that in user in, Right. So the source of record replies back and says, Yes, that the user name and password is correct, and this individual is in the marketing group.

04:23

So at that point, the financial database could go through its authorisation procedure to say Okay, well,

04:28

is the marketing group available to access the financial data base? And the answer is no. So it blocks out access

04:34

that same employees might hit a generic file server that's just meant toe House files for all internal employees, the same back and forth. You know, authentication authorization happens. And in this case, ah, the server looks at his policy and says, Yep, you're allowed to do that. And then maybe there's a proxy server. Maybe the market employees trying to go to Facebook and you have

04:53

your proxy server configured to go back toe to the source of record, which is active Directory

04:58

says Yes. Used and passwords correct there in the marketing group, and you've got a policy on the proxy server that says yes marketing. People need to get to Facebook because they're the ones responsible for maintaining Facebook. Anybody else? If it would have been somebody in the engineering group, they would have been blocked.

05:13

And that's essentially I am and role based access enforcement in action.

05:18

I want you build all of this. You have to maintain all of this access, and that's what the I am program is about.

05:25

So you have to figure out what's going to trigger. Ah, change. And I recommend that HR processes all automatically trigger a change because a lot of things that happen are gonna go through HR, right. So we get a new employee that gets hired that new employees to be put, an ex group that contributor, a workflow

05:43

h Arkin start to process and send it off to the appropriate group

05:46

user moves from one department to another. That should be another HR process that triggers and goes out to the appropriate people.

05:53

There should be periodic attestation as well, because not every not every access change is gonna be triggered by an HR process. For example, I may have been hired on as an engineer, and I get access toe one system. Ah, project. Let's say I'm working on a certain project.

06:10

And three months into that project, they realized, Why don't they don't need me on that project anymore and I get moved to a different project.

06:15

While I didn't move departments, so there was never any HR notification. This was simply my manager who decided to take me off of this project, Put me on this one. But I certainly know no longer need access to that sensitive information that was involved in this one project. So in that case, a periodic act estacion can help us identify if the

06:34

level of access users have is still appropriate, so

06:38

it may be quarterly or annually. Some sort of access station on a regular basis is very helpful,

06:45

and approval should really fall to either the manager or the owner of the data. You can't rely on a charter to say this is an engineer. They need eight engineering access because HR is not. They don't have the visibility into the functions of the engineering department like the engineering manager would. It really should fall to the that

07:02

direct manager who's gonna know what access their people need

07:06

or to the data owner. If it's the you know, if it's a sensitive database, for example, whoever is marked as the owner of that data should decide who gets access to that data. So they should be able to approve or disapprove certain requests to that data access.