The Proper Care and Feeding of Non-Human Identities

Thank you. Yeah, you did pronounce the name correctly. It is tu. And I'm gonna talking about non-human identities. My name is Brian ierson and I recently joined tu as product officer. The robots are coming they're already here, actually, at least for those of you working with identity governance administration, you could be living with them already. Let's start with a little identity theory. We identify things because we place value on them individually. I have identity in numerous contexts because I like to think that I am valuable as an individual. Let's talk about this camera.

The manufacturer values this camera because they want to sell it and make the customer happy. The camera has a model number, a product batch identifier, and a serial number among other things. The batch identifier helps to determine if there was a production problem. If too many cameras from a certain batch turn out to be defective, the serial number is assigned because the manufacturer provides a warranty that lasts for a certain period.

Also, the customer is probably entitled to some level of post-sale support, depending on how much the customer values, the camera, he or she may assign additional identifiers. If I only own one camera, I will just refer to this camera as the camera. If I have a photographer and own a bunch of camera, I may refer to this as the digital SLR or some other name to distinguish it from other cameras that I own.

However, if I'm an organization that owns a lot of cameras, I may assign it in asset tag so that I can track it in my inventory, the larger the organization, the more formal these processes will need to be. Now, let's think of another example. The simple pencil does the manufacturer care about each individual pencil, probably not. Pencils are pretty much commodities and one that can easily be substituted for another. It would be too costly for manufacturer assigned serial numbers, pencil.

However, the product batch probably matters because the manufacturer will wanna track defects. Should they be discovered in the future? The batch number may, may, may not be stamped on each pencil, but it almost certainly would be stamped on the package. The way we identify people and things is almost entirely dependent on how we value them. Whether as individuals or sets as the name implies identity is the key to identity governance administration. IGA uses explicitly defined identities to manage accounts across all integrated it systems.

What would it be like if we didn't explicitly construct identity for managing accounts in order to make decisions about which accounts could be authorized to perform certain action, we would need to have an idea of, to whom an account belongs. We would perform the correlation on the apply based on account names or other attributes that may be available with accounts. This is brought with challenges because it's hard to enforce naming standards across the heterogeneous environment and not all it systems can provide additional attributes that could be used for an identification purposes.

Then we have the problem of non-standard accounts, the accounts that are used for administration or other purposes. How do we tell who's responsible for these accounts? We really need an external database for tracking these relationships between people and accounts. And that is perhaps one of the most important things that IGA provides. Identity provides context for account ownership, capturing all the information needed to explain why an account exists and what the account should be authorized to allow.

Given the importance of identity, provide context for account ownership is just maing that so many organizations decide to ignore non-standard accounts with their IGA deployments. I certainly understand that these accounts are more difficult to manage than standard accounts because of their atypical lifecycle policies. For example, many system accounts cannot or should not be deleted because they're critical to set up a recovery of the it system. Examples of these are root accounts on Linux systems or administrator accounts and window systems.

However, these are the very accounts that present the most access risk to organization. What are my most important critiques of how IGA is often done today is that many vendors and their customers have lost sight of why IGA tools are necessary. It's not simply to automate the work of IAM administrators, but to help the organization efficiently manage access risks that arise from operating distributed heterogeneous information systems managing non centered accounts may not be the highest IGA priority, but it should certainly be as high priority as managing standard accounts.

Instead, some IB IAM leaders may try to play the numbers game and declare victory because 90 to 95% of accounts are being managed without mentioning they are ignoring the highest risk accounts. If you fail to act on non-standard accounts until auditors ask about privilege access, you are derelict in your duty for access risk management. Every organization should have a taxonomy of account types. In addition to standard accounts, consider these four account types to be a starting point for your organization's IA IGA account taxonomy. I implore you to avoid creating too many account types.

The criteria for determining if you need an additional account type should be dependent entirely on the extent to which account life cycles may differ within the same it system. Look at the operational account type here. This account type easily covers service accounts and other types of accounts that may be used strictly for software installation or maintenance. You could certainly put this account type into two account types, but if the account life cycles are identical, then you're just making more work for your organization without adding value.

One area where I have seen organizations get into trouble with account type categories is when they incorporate identity properties into account types. For example, some organizations may specify guest accounts, secondary accounts or accounts assigned to business partners as separate account types. These are typically organizations with weak identity foundations. As I mentioned earlier, identity should be providing the context to accounts, not the account types or metadata. Now that I have the housekeeping out of the way, let's dive into our discussion nonhuman identities.

If you pay attention to tub, you will hear us talk about postmodern IGA and the importance of maintaining business side abstractions alongside the record, keeping that is done on the it side, the it side represents the quote unquote real digital world of the managed environment. This is the world of assets or it systems that are providers of accounts, permissions, and resources. What IGA is doing for the it site is maintaining a faithful representation. What exists in the real digital world for auto purposes, as well as tracking trans cracking transactions.

It's nearly impossible to understand the context of transactions on the it side, why accounts, resources, or permissions are being created associated or removed with this information alone. The business context for the it side is provided by entities and transactions on the business side users also known as identities represent people or things that are owners of accounts provided by assets. Every account provided by a managed asset should be owned by exactly one identity for control purposes.

In our information model, identity gets its context through affiliation with one or more organization. Context for accounts provided by assets is provided by a chain that starts with an ownership entity that links the account with an identity. And the identity is contextualized through its affiliation with an organization. When an account entry is created in the IGA tool, it is paired with an ownership entry that records its account type and the identity that owns the account. The ways that these relations with work will be illustrated in the next few slides.

One approach for managing the life cycle of nonstandard accounts is simply to rely on human identities. Notice that we have a single human identity on the left here, and two assets on the right, providing some accounts. Every account has a corresponding ownership entry that records the account type and then references the identity is its owner. I mentioned previously that we have a constraint on account ownership that limits accounts to a single owner. There is no constraint on many accounts, a human identity can own.

So in this case, our human identity is identified as the owner of all five accounts. This can work. It does work for some organizations. I must advocated for this model before I was exposed to all the nasty implications. Let's talk about some of those implications. First from the identity perspective processes operating on the business side of IGA must be aware of it specific needs of various account types.

For example, if the human identity here is assigned in entitlement, that happens to be mapped to a permission provided by asset a the IGA tool must figure out which account that is owned by the identity to be assigned to that permission, to reduce complexity. We might need to ask the requester of the entitlement assignment to target one of the three accounts owned by the identity. This is starting to make access requests much more complex than they need to be by breaking through the abstraction layer that the business side of the IGA is supposed to provide.

In addition, identity, life cycle processes are more complex than they need to be since they must take the various account types into consideration. If the human identity is separated from the organization, we need to iterate through the various accounts that the identity owns to determine what to do with them. I mentioned previously that system accounts could not be deleted. So we would probably need to spin up a workflow to transfer ownership of the account to another identity.

This can be tricky, especially for something like an operational account, because there is really no context available as to why the account exists in the first place. How do we know the right identity for this account? How is the person behind this identity supposed to know why this account exists?

Thus, we arrive at what I have found to be the more sustainable alternative to be using non-human identities for ownership of most types of non-standard accounts. In this case, we have added two non-human identities on the business side while keeping the topology of the it side, the same instead of the human identity, owning all the accounts.

Each non-human identity owns the operational system accounts, which were the most troublesome accounts for the previous example notes that the administrative account remains associated with the human identity because that account's lifecycle needs to be coordinated with the owner's identity lifecycle ownership of the operational and system accounts. Now provide the context that was missing. In the previous example, it also allows us to maintain the wall of abstraction between the business and it sides.

Since we are focused entirely on identity lifecycle operations, and do not need to concern our business type processes with account lifecycle considerations. The context for these troublesome non-standard accounts is provided by the non-human identities. But where does this context come from?

The easiest way that I have found to explain the context of running non-human identities is to tell people that these identities are like contingent employees, contractors, business partners, whatever these users are related to the organization in some way, like the way human users are also related to the organization, a more flexible approach to governing identities involves the use of an organization structure and then modeling affiliations with these organizations.

This allows for multiple identity life cycles to operate across the organization structure, even allowing multiple simultaneous relationships between individual users and potentially multiple organizations. For example, let's say there is an institution of higher education where a user can simultaneously be an employee, a member of the faculty, a student, and a parent of a student. All these relationships with may confer, certain privileges or constraints can be captured by these affiliations.

Simultaneously this model easily extends to non-human identities without requiring any unnatural changes to the overall governance approach. In this example, I have introduced an organization called applications as being subordinate to the self company organization. This organization has decomposed further into multiple individual applications, also representatives, organization entities, which each with specific owners, the human users in this example are affiliated with built company as employees or contractors.

The non-human identities are affiliated with separate applications as modules, meaning that the identities represent modules of the applications, all this language describing organizational units and affiliations as arbitrary, we are creating a vocabulary for the topology of relationship to help business users understand and navigate the various contexts. This allows us to modify model non-human identify identities on the far right of this diagram. As modules of specific applications.

These identities are integrated into the reporting hierarchy as to coordinate to human identities, which allows us to trace responsibility for these identities to a human in the organization. This is optional as it may be acceptable as this trace responsibility for these identities to the owners of applications. In this example, we are supporting something like a dual pronged accountability responsibility relationship that involves multiple users. This can help if the non-human identity becomes an orphan.

When a supervisor I ID is separated from the organization, there is nothing in this model that mandates one governance approach over another. Instead, the organization can model overall governance. However they prefer through configuration without customization paneling non-human identities in this way allows us to make use of the same well known ID lifecycle patterns that we've, that have proven effective for human identities.

The four patterns are shown here, authoritative source sponsorship and exploration delegated administration, and self-registration identity life cycle processes operate exclusively on affiliations with affiliations operating like state machine. These processes also provide for the creation of identities. For those cases, when a new affiliation is needed for an identity that does not exist, an identity life process operates on affiliations as if they were part of a state machine with affiliations representing various states of the relationship modeled by the identity lifecycle process.

Almost every organization will have multiple identity lifecycle processes that represent the various types of relationships that need to be maintained. In the simplest case, there are likely be identity based cycle processes for employees and contractors. Identities never really go away. We just stop caring about them when they reach certain states. That's why we always model identity lifecycle processes with negative states, such as a separated employee or inactive contractor.

An identity lifecycle process has exclusive control or a set of affiliations so that the process can maintain the integrity of those affiliations. No stretching is necessary to extend this identity lifecycle process model to non-human identities and the application module example that we explored moments ago, all that is necessary to handle the creation and maintenance of these identities is an identity lifecycle process that controls a set of affiliation states in relation to organization entities.

Then we just select the most suitable identity lifecycle pattern when constructing the process and apply them to transitions between our desired states. In the simplest case, we might just support active module and inactive module and apply a delegated administration pattern to allow the owner of an application, to establish active modules and then transition those models to inactive state when they're no longer needed. These are by no means the only choices.

The key takeaway here is that IGA tools with a robust identity lifecycle process model can easily handle an organization's needs for governance over non-human identities. The final aspect of governance over non-human identities is deciding how to approach access reviews or certifications. Access certification is the foundation of periodic reviews, reviews that are performed regularly because your auditors or regulators demand them organizations with immature IGA deployments, start out with resource driven certifications and then eventually migrate to manage your certifications.

Once they're entitlements possess enough metadata, there are no special considerations here. Once non-human identities are incorporated into the ecosystem, except that non-human identities need to be integrated with the organizational reporting hierarchy to support manager certification. If this is not the case, then a separate certification may be necessary to handle a review of non-human identity, entitlements, alongside manager and certifications. I had to cover a lot of territory quickly today.

So I hope the highlights were enough to get you thinking about how to incorporate non-human identities into the management of nonstandard accounts. The most essential recommendation here are the first two don't put off management of non-standard accounts and use non-human identities to provide better context for these accounts. The rest can really be considered quality of life recommendations, ways to avoid unnecessary pain on your journeys with that. I thank you for hanging in there with me today. Any questions.