for our tour of entitlement and access management. We're gonna go through terminology, are back, verse a back, revisiting the entitlement matrix
and then examine access management. The cloud provider verse cloud customer responsibilities.
Authorization is the permission to do something. It's different than authentication.
Access control is what allows or denies the expression of the authorization.
Hopefully, this makes sense. It starts with the authorization. This is the permission to do something, and then you get entitled to have that authorization based on who you are. Your identity, as well as other attributes associated with that identity
and access control, is the final call. By evaluating the entitlement and authorisation rules that are in place,
the access control gives you that final go no go decision that allows or denies the action that you're trying to perform.
Role based access control has been a round for a long time. It's a very traditional method of structuring things and then are back here. Entitlements are defined based on pre assigned roles. Other words, static attributes. Maybe you need to belong to a certain group, and if you do,
then you are allowed to perform certain actions.
A back is attribute based access control. It's much newer approach, and in this paradigm, entitlements are evaluated more dynamically at run time, and they can look at attributes that are dynamic to your particular session as well. This gives you a lot more granularity and flexibility in what you can build out,
and as a result of this flexibility is the preferred approach for a cloud.
For example, you can create a back rules that not only require you have certain static attributes, you belong to a group, for example, or you have a certain role assigned to you.
But they can also evaluate to include more dynamic attributes, such as What is the device that you're connecting from? What is the network that you are using? Have you provided multi factor authentication for this particular session?
We covered entitlement matrix previously, but I wanted to modify that matrix that we looked at in the earlier module to include an example of where we're employing the A back approach as well as our back. Because the two can work together, it's just the more you use a back the finer grain control you have and the greater security you can have.
So in this example. I added a row at the very, very bottom for deleting backups,
and we give anybody who has the backup operator role the ability to perform this action. But we're also gonna have some attribute based access controls to get the appropriate entitlements to perform the delete backup activities. Their particular session needs to have completed multi factor authentication,
and we're also going to restrict them to a theoretical i p address range, which would indicate they're working within a trusted network.
And by adding these additional constraints were really locking down. How much damage? Somebody who may be compromised is one of these backup operator accounts could cause, because even if they do have the ability to get into one of these accounts, they want to start deleting the backups. But we're really putting the screws on them to make sure that
the FAA is taking place. And there Onley in certain trusted I P ranges.
That's going to make it much, much more difficult for an attacker to create this kind of damage if they're using the broad general Internet access and if they only have a user name and password, somebody who does have the backup operator role. They still won't be effective because there are additional hurdles that they need to go through.
Little get access management, cloud provider verse, cloud customer rules and responsibilities. Starting with the provider side, the different authorization capabilities have to be configured in the cloud platform. So Samel open I d often do. I support Fido. Utf
all these types of things. It's the responsibility of the cloud provider to do that.
More importantly, once they've configured the different technologies and capabilities, the enforcement of those authorizations and access controls is their responsibility. So they need to make sure that whatever engine they're doing that gives the access control that's evaluating the entitlements, that it works and it does its job
and that there's no loopholes that could be easily worked around through
some sort of ah odd combination of events or belonging to multiple roles. Then, all of sudden, you have that you find this little backdoor that allows you to enter into a super user mode so that this is the responsibility of the cloud provider,
and they should really support a back. We talked about that more and more of them do. They may not call it attribute based access control.
It's always preferred over role based access control because of the additional level of flexibility that you can have in securing your environment. And as we know, the cloud environment is innate Lee more insecure than the traditional corporate network working within a defined perimeter.
However, the customer does have certain obligations as well. They need to define and configure the entitlements. So all those dials and knobs
that the cloud provider gave to them they mean nothing if the cloud customer themselves isn't setting up isn't integrating with a Federated identity system? Isn't creating entitlement matrixes themselves and establishing certain groups, creating rules defining those attributes based access control rules
that allow somebody to perform certain operations,
access specific data or denies them from performing those things
just like we've talked about with many other things, such as cloud storage? If you can figure as a cloud customer, you have the best. Your provider provides the best, most secure cloud storage option in the world. But then you kagle the setting to say, make this data public to the world while the whole world can see it,
and now you've opened up the door for a massive data leakage.
The same situation and thinking applies here in that if you've configured things so that any user has all broad, broad, very strong permissions, you've really left the door open for a lot of other problems. And then, additionally, the customer they need to map their federally that identity attributes to those provider access controls.
So when you get into the details of putting up Federated Identity,
you know what defines a user name or what defines the identity that may have a different name for an attribute that the cloud providers expecting then your identity system is providing. And so you have to do, Ah, a little work on the mapping there.
And of course, this is very important because if you do this wrong, you can also open up things very broadly. And you want to make sure, for example, that add men's
belonged to a group called Ad Mons. But if you mess up the mapping and say anybody should have the admin right, if they belong to a group star, which is a wild card, any group all of sudden there's there's a real problem there. In a discrepancy in the way you is a cloud customer have configured things, and it's really not the cloud providers
Let's do a little quiz on some of this information. Which of the following is an example of an A back attribute something that you could use and set up for your rules. If a user is logged on with MF a biometric data,
biometric authentication status or A and C
think about it a second. So the answer is D B. Biometric data is not something you would use for attribute based access control. Biometric data is it's just information. It's just data, right? What you really want is to know. Has this current session
Ben authenticated using biometric
uhm means or not. Now the biometric data is what's going to be used to enforce and evaluate the accurate authentication of the biometrics. But
the status for that particular session have they gone through the biometric authentication process or not? That's the attribute that you're going to be looking at and the same rings true for MF A right for for this particular scenario, let's let's say you wanna know. Has this users session
authenticated using MF A or did they just provide the user name and password
that wraps up this kind of short video. We went over the terminology, talked about role based access control versus attribute based access control and the subtle but very significant and powerful differences between the two.
The Entitlement Matrix Revisited. We looked at that one from pulling from the past and saw an example of how attributes based access control could be added into an entitlement matrix. And then we covered access management roles, responsibilities between the cloud provider and the cloud customer.