Going back to the early 2000's and the telco's wanting to upsell their customer's services, once the telco's had created IBoR and keychains, they realized that they could now see a given identity had a credential in different service directories, and could even look-up the what groups the customers credentials were a member of. What they did not really know was what those groups gave as entitlements to the customer. As an example, if customer Bay Li had wireless services since they existed in the wireless customer directory and were members of group 400min and vmail, how much did we really know about what Bay Li had as a service? The group 400min sounds like they had a 400 min rate plan, but was that prepaid, postpaid, did it include caller line ID, call waiting etc. What's more, the rate plan changed giving the members of the group and additional 100 min "free" so it actually is no longer 400min but now 500min, although changing the group name never happened. This kicked off projects to create and maintain a centralized product catalogue.
Almost every IAM engagement, it includes a statement to implement "roles-based access". A goal, without a plan, is just a wish... and in most cases, the team is not even in sync on what they consider roles-based access or what they mean by the term. This is because the RBAC model is layered. A single application role, been something entirely different from a business role. Ironically, if you ask for clarification, you usually get this look like "#$#@ and this is the consultant?"
In most cases what they unknowingly referring to is business roles. The utopian world of least privilege, least effort and full compliance, and so often trying to get there without datastores or building the foundation. So I will start... yes on the opposite end.
For example, let's use a Database as the "in application" side (Single Entitlement). In a single database role, you may grant members the ability to update and read one table named [updateme], but only read table [readme]. This is a 2 entitlement application role. Neither considered privileged by the owner of such data in such tables. (please note, write access does not mean privileged access necessarily, else my ability to write an email or add my name to the team potluck is also privileged).
These two application entitlements are usually used by data entry staff for the application [Database1]. This application role is mapped to a directory group that we name [Database1_dataentry], along with 10 other application roles for the same database, similarly for 20 other databases and 100 other apps. If I look in the directory, I can see the name of the group and the credentials that are members of this group, but other than the name, do I know what this group grants access to? Not unless you go to the database side and look at what the role contains.
So if Betty now asks for access to the group [Database1_dataentry] , how do you know if this is least privilege and appropriate? How does Betty know what group to ask for? On the other hand, if Betty asks for write access to table [updateme] and read access to [readme], how do I know how to provision Betty in group [Database1_dataentry]? If an incident requires you to know who has write access to table [updateme], how will you establish this? Perhaps Betty's manager is asked to certify Betty's access to [Database1_dataentry], how do they know what that group grants access to? To automate the provisioning of access, what workflow do you use?
There is no technical limit to how many levels between a single entitlement and business role, but many companies limit their entitlement catalogue to 3-5 levels. We could go lower than the table to the field or some other flag level, like PII. We could also add levels between IT roles and business roles or include levels above business roles when you bring in persona's and wish to know for a given credential if the identity is both employee and customer.
In our example above, let's say 5 different teams have a need to be members of [Database1_dataentry] and all data entry staff also need access to a different system where they collect data to enter. This system to collect data to enter access is granted through the [Dataentry] group in the same directory. I could nest [Dataentry] and [Database1_dataentry] into a 3rd group, create a multipurpose group or do it in the catalogue by creating an "IT role" The flexibility in scheme, workflow and fact that an entitlement catalogue can span many directories is one reason why nesting is not ideal. All 5 teams may now be members of this IT role.
One team is contractors and other permanent employees, and the contractors need access to a time system while employees need access to a benefits system. Both teams have the "IT role" of [Data Entry]. We can now create a business role including the other access needed for each team which is the "IT role"+ say time system access and call it [Contractors Data Entry]. This is now a business role.
Usually, role mining works either top-down, bottom-up or hybrid. Top down mean you look at the persons job function, then determine what entitlements they need access to. Bottom up, is the approach above, where you first create the entitlement level, then the application role level, then the IT role etc. Note, top down does not mean you only build business roles and ignore the other layers, which is a common misunderstanding, that results in "business roles" being nothing but a consolidation of unknown entitlements and rather than a clearer understanding of access level, a hidden one.
A note: Your entitlement catalogue is where technical and business description exists, along with ownership and accountability, workflows etc. You will need to establish and entitlement lifecycle management, onboarding, retirement, transfer etc process. You will also want flags for things like PII, Privileged etc that you may wish to query on. So how do you now know who has privileged access?
No comments:
Post a Comment