Most organizations use a lot of applications throughout their business operations. And those apps have different functions. However, even when an identity is authorized to have access to an application, it may not need—or should not have—access to the entirety of the app’s functionality. To use those specific functions, the user or identity must be entitled to do so.
What Are Entitlements?
An entitlement is what a user can do within an app, whether it is a permission, a role, a setting or an admin, all depending on the app’s definition. But most simply put, it is the ability for a user to do something. The user can be entitled to view, edit or delete data.
There are three terms that best help to define entitlements. They are:
Identity: who you are, often the user but could be a non-human identity within the app
Entitlement: this is an action that the identity is allowed to perform
Grant: identity plus entitlement
The Problem with Entitlements
While entitlements should act as a security function in the way it affects user controls, there are a lot of challenges with them—the biggest problem being there are too many entitlements. Cloud providers have made the entitlement process highly customizable, which is great for creating apps. But from a security point of view, it’s an entitlement overload. These public cloud platforms will have tens of thousands of entitlements. With such an entitlement overload, it is tough to know which entitlements are important, which allow deletion of data or which function in admin roles. It takes away from the benefits of least privilege.
The way entitlements are assigned also cause security problems. Some are statically assigned: all users within certain roles within the organization are assigned entitlements, for example. And those who are given entitlements are often over-provisioned, assigning everyone to the same role or same permissions. Should every single user be able to delete data, just because they work in the same department? Probably not, but without automation, it is very difficult to control how entitlements are granted.
Entitlement Management
Users might think they deserve to be given certain entitlements—or maybe even all the entitlements, but if pressed, they rarely know what type of access they should have. And once given access, they aren’t going to voluntarily give it up. That’s one reason entitlement management is necessary. Identities should be mapped to match entitlements for not only job function, but to follow least privilege policies and to ensure entitlements are time limited for need.
Entitlement management will provide the following capabilities:
- Maintain control over the access for the different applications, platforms and groups, determined by individual user
- Determine when users should automatically be assigned entitlements to certain resources, but set up so access is revoked when the user’s role changes or there are changes to the resources
- Decide if and when non-admin users can create access for limited-use users
Crafting Roles
The issue, then, is, within a IaaS or SaaS, how do you craft a good role? If you want to make a custom role in AWS, for example, you must consider how to set it up so the DevOps team can only do exactly what they need to do and nothing more.
The big public clouds have specific tools to help the security team build customized roles. In fact, the top ten SaaS will have very customizable roles, while the next tier of SaaS will a have a few built-in roles, which are good enough for most organizations. Built-in roles aren’t perfect, but they are a good starting point.
Because building customized roles is complicated – it requires looking at usage, overall privileges – and could end up being a dangerous security risk if done incorrectly, the recommendation is that customized roles should only be done for SaaS that are used often and are high risk. You won’t get the benefit of new features and products released by the SaaS; those will only benefit built-in roles.
Bottom line is maintaining entitlements is hard, and there is overhead to maintaining custom roles so you have to be really specific as a company when you do that. Before you create a custom role, you should have definitive answers to the following questions:
- Will the role be covered when new features are introduced by your SaaS?
- How often will you review these roles?
- How many people in the company need this entitlement?
- How do you plan to use your entitlements?
Monitoring Evolving Entitlements
All in all, monitoring and managing entitlements is a usage issue. Do people use the actual entitlements that are included (for example, does the user really need to be able to delete a database; if not, why should they have that entitlement)?
Also, as your business changes, what you’ll need from the SaaS will change. When the SaaS evolves, your entitlements management will have to evolve with it. Workflows of teams are always changing, too, so they won’t need the same level of entitlements anymore.
SaaS, workflows, and even users are dynamic, not static. Entitlements should also be dynamic, and it is up to the security team to ensure entitlements are regularly updated to meet the changing needs and business operations of the organization, as well as the upgrades and evolution of cloud applications.
