Transcript for:
Role-Based Access in EPM Policies

in this nugget we are going to learn why role based access is an important element in building and maintaining EPM policies the two competing methodologies used to build EPM policy are individual policies or role-based access with individual policies each user is assigned a unique set of policies containing the applications and tasks that they are permitted to execute or El elate role-based access is where policies are assigned to an identified role and all users in that role are permitted to execute or Elevate the associated applications and tasks when choosing between them individual policies may seem like the better choice as it more closely follows the principle of least privilege what makes rule-based access the better choice well it's the thing that allows us to scale imagine if you will something simple like managing a file server if you granted users access on a file by file basis individual by individual it would quickly become unmanageable in contrast assigning access to a role reduces the administrative effort keeps policies to a minimum and supports the joiners movers and levers process to avoid privilege creep what if there are no pre-existing roles in the organization what if it's always been that these are users with admin rights and these are the ones that don't well let's start with that binary option as the role but tailored to the rights required and protected from abuse and exploitation at a later point we can then start to split out the use cases into more specific roles based on the commonalities of the users accessing those permissions let's now look at the methods you can use to identify and Target roles the simplest method is to utilize pre-existing group membership that are assigned based on function for example developers Operations Security Etc if the specific spefic role cannot be established based on one group then consider using a collection to combine groups for example dynamically create the role of Dev Ops if the user is a member of both the developers and operations groups if the user role cannot be established based on group membership then consider using conditions to match policy for instance you could Target remote workers based on availability of network resources or the connection type you could go way beyond that simple l to match any condition or characteristic that can resolve to true or false by utilizing scripts matching criteria for policies is cumulative which allows you to combine conditions in groups in a single policy or across different policies in this example we have a developer connecting in from home we assign the tailored developer policy based on group membership and in addition any remote worker rules that we may want to enforce while the user is not in the office which we can establish based on conditions all within the confines of our risk reduction policies while still providing flexible Discovery and exception handling mechanism that allows us to deal with the unexpected thank you for watching you should now have a better understanding of role-based access and its benefits