How To Control Non-Human Identities
04 August, 2021, by Stephen Swann
It's a little known fact that machine identities now outnumber user identities. Indeed, by 2025, it is estimated that there will be 75 billion IOT devices in existence and many believe that number to be rather conservative!
So, can the identity management & governance systems that we use to manage people accommodate and control machine identities?
Before we answer that question, what do we mean by a machine identity? In this context, a machine identity could be any of the following:
- System (either physical or virtual)
- IOT Device (Cameras, Lamps, Smart Devices, A/V, etc.)
- Robot (think robotic process automation)
In short, any object that is connected to our infrastructure (no matter how loosely) and that is granted access rights to perform some function can be considered a machine identity. It wouldn't be unusual to consider a meeting room to have an "identity" nor for that meeting room to be assigned various entitlements such as tele-conference or video-conference capabilities; electronic whiteboard capabilities; audio-visual entitlements; etc. Each device and even the room itself may carry a sense of identity and entitlement.
When thinking of machine identities in that manner, it's easy to see how machine identities can proliferate around an organisation.
When we think of controlling our machine identities, we are not merely trying to establish an asset register. That ought to exist already, although interestingly, most identity management tools could probably act as an asset register quite easily.
Instead, we need to be considering the following:
- Do we have visibility of the machines and things in our infrastructure and wider ecosystem?
- Do we know what they can do and how they interact with each other?
- Do we know what information is being held by them?
- Do we know what happens when they are decommissioned?
The good news is that Identity Management & Governance tools have no concept as to whether an identity is human or non-human. As such, the management of machine identities should merely be an extension of existing processes.
That said, there are subtle differences between the identity types that will require some configuration changes to be applied. Let's consider the primary functions of an Identity Management platform:
The Data Model
Real people have names, email addresses, mobile phone numbers, office address, employee IDs, managers, start/end dates, organisational assignment, job functions, etc.
Machines & Things? They have a very different set of attributes as such:
- Machine Name
- Machine Type (i.e. Service, Application, Robot, Calendar, Phone, Room, etc.)
- Asset Register ID or CMDB ID
- Commissioned Date
NOTE: Mandatory attributes are in bold.
Machines and things could conceivably be associated with departments though many will likely be shared resources.
Ideally, you don't want to be replicating your Asset Register but the schema definition needs to be rich enough for you to understand what the machine is; where it is; what it's meant to do; and who owns it.
Machines appear all the time and it is unreasonable to expect that identities will be created in advance of the machine being connected to the infrastructure. As such, automated discovery may well be the only means of identifying them.
Within the enterprise, it may well be that many machines will have associated accounts held in an enterprise directory service such as Active Directory. But how do we know that the account with an ID of device_001 belongs to a Robot as opposed to a Smart Lamp? And what about those devices that don't have an associated account? Do we care about them? Should we care about them? How would we even know they existed?
Network scanning and device finger-printing may be options in your discovery toolkit, but running such scans is normally frowned upon and in any case, firewalls ought to restrict such activity.
Real people can look after their own identities (in theory). Machines, however, don't yet have that capability and therefore require an owner or "custodian".
The custodian should be responsible for validating that the machine is still required through periodic re-certification and should be the person we can turn to should issues arise with the machine or device.
We use the term custodian deliberately here though. We should not directly assign machine accounts to a real person because typical Identity Management solutions would disable such accounts when the owner leaves the organisation. That could be catastrophic! Instead, machine accounts should be assigned to machine identities and custodians identified for those machine identities. Custodian re-assignment business processes will be required to support a custodian leaving the organisation or changing their job function.
Modern Identity Management & Governance tools can certainly undertake the management of machine identities, and the process of doing so needn't be onerous.
Discovery and Custodianship are certainly the main pain points but that shouldn't put you off integrating machine management process into your Identity Management solution.