At face value, it’s a simple question. But it’s one that most organizations struggle to answer. This question is a restatement of what identity is. Yet after twenty years of various identity management platforms and approaches, many organizations do not have a satisfactory answer to this question.
To provide appropriate services, you need to know for whom you are providing services. In an enterprise environment, you will often have several populations; employees, contractors, vendors, business partners, customers, and increasingly, bots. Each of these populations will have their own authoritative sources or systems that define each person’s relationship to the organization.
Why is it important to understand the relationship of an identity to the organization? Consider the on-boarding of a new employee into an organization. The new employee was hired to support a business function. That person will need the right access to support that role. Fairly straightforward to understand on the first day of employment, but that person’s relationship to the organization begins to change after that first day. Can you track how that relationship changes? An example of this is as someone changes jobs and departments. Is that change in relationship reflected in the “authoritative system” you have been provided access to?
To get insights into the relationships of these people, involve the stakeholders in the business to certify that the person is the appropriate person on an ongoing basis. The stakeholder with the most significant insight often is the supervisor or manager of that person.
Now that we have established how to determine who are the right people, we move on to what is the right access for these people. We can think of access as “what can I do when I log into this app/system/database/site?” Now we have two things to consider. First, what is the location of these things I am logging into? Secondly, how is access modeled there?
Understanding what is in the environment involves an inventory of all systems whether they are on-premises or hosted by third parties (e.g., SaaS). Once inventoried, then the question becomes how to model these systems. Currently, most systems maintain their own mechanisms to manage their user objects and authorization schemas. The authorization schemas often rely on a static assignment of access controls based on the notion of group memberships. To work with this data, you will need to normalize it, which abstracts the underlying complexity.
Once the access model has been normalized, the question arises about the right access. Who determines that? Attempts to define correct access within the IT or security ranks will miss the subtlety of the context of these entitlements. The applications and systems that these entitlements exist on serve to support business functions of the enterprise. To understand how these entitlements serve the business, you need to involve the business!
How do you engage non-IT users within the business about the context of entitlements that need to be managed and protected? A framework wherein business users can review and provide governance over entitlements requires automated certification mechanisms to be successful. To certify the access in their business context, simplifying the access entitlements by bundling them based on how they map to the functions that the RIGHT people are doing to serve the business. This is key to scaling this solution across the enterprise.
So far, we have progressed from establishing the relationship of the right people to the organization into understanding the context of the right access to the overall mission of the enterprise. Now we need to consider how data is protected. Historically, the business data that IT organizations were concerned about resided in structured systems such as the classic RDBMS (relational database management system). Often the applications that accessed the data provided the security layer through their internal authorization models. Privileged users (e.g., DBAs) still access the data directly, but there are tools to mitigate that risk (i.e., Privileged Access Management solutions). Today, 80% of data is file-based and resides in both on-premises and cloud-based repositories, with inconsistent access control facilities.
To tackle this problem, we need to focus our efforts on data that poses a risk to the organization. A spreadsheet coordinating the department’s weekly potluck is different from a document detailing pricing strategy for an upcoming product. Categorization of the data is the first step; you need to focus efforts on data that present risk to the organization itself. Once the sensitive data has been identified, an understanding of how access is granted to the data is the next step. Often ACLs on data access are poorly understood in a mature environment. Consider how access is being effectively granted through nested Active Directory groups.
The challenge in addressing this is again the lack of understanding of the business context of this data. The other challenge with securing data versus users and their access is the overall volume of the data itself. To scale across the enterprise, owners within the organization, need to be identified to provide governance of this data. Many organizations will be dealing with terabytes if not petabytes of sensitive data. A successful solution will be based on scaling the concept of data ownership outside of the IT pillar and into the rest of the organization. In the end, this is business data that is being protected.
To answer the original question on an ongoing basis requires a solution that actively engages all stakeholders especially those outside of the IT, infrastructure, and security pillars. An effective solution must be designed to present the decisions in a clear and business oriented manner so that the proper due diligence can be exercised.
Fundamentally, identity governance is a business process and should be supported as such with a platform that targets business users with its user experience and flexibility.