Identity management has traditionally focused upon human identities, however, non-human identities are growing at a faster pace. Non-human identities include IoT and mobile devices, digital secrets, service accounts, and social media accounts. Organizations control human and non-human entities accessing digital assets to protect business operations, safeguard data privacy, and ensure regulatory compliance.
In light of the several digital transformation initiatives, as well as expanding cloud and digital services, organizations must be protected against people, processes, and things. Identity access management (IAM) and identity governance and administration (IGA) must support non-human identities in addition to human identities, within processes, microservices, and containers. Currently, IAM and IGA solutions offer little support for managing these distinct identities. However, when properly provisioned and integrated, IAM and IGA solutions can leverage both human and non-human identities, and control their access and interactions with corporate assets on-premises and in the cloud.
Managing non-human identities requires a different approach
The focus for most IAM solutions has been managing customers, employees, privileged users, partners, and third-party contractors. Now, attention must be given to non-human identities. Problems arise when organizations try to manage human and non-human identities within a single IAM data structure. Some of the difficulties with this approach are the fact that non-human entities do not have first and last names and email addresses. The onboarding and life cycle management of non-human identities must be handled differently. During the on-boarding process, a device needs to be identified by its type, i.e., smartphone, thermostat, security camera, etc. The behavior of the device also needs to be tracked as it interacts with applications and other assets within the organization.
The 3 non-human identity types
Service account identities:
Service accounts are primarily used for administrative purposes; for example, when an HR application needs to communicate with the Office 365 email system. The service account gives the HR system admin permissions for provisioning user email addresses and mailboxes. The IAM system obtains the new on-boarded email records from the HR system and establishes the accounts within Office 365. Service account identities are comprised of the purpose, the owner responsible for the account, how long the account will be valid, and who can use the account. If an application accesses the account, its name must be included within the identity.
Device identities:
Device identity attributes include the device type, ID, purpose, owner, and operator. They also require separate management of their governance processes. The device life cycle of installation and onboarding, maintenance, and operations must be managed separately from human identities. Additionally, access, activity, and the communication the device sends out must be managed separately, as these entities are fundamentally different than an employee or customer.
Secrets identities:
Digital secrets include certificates, passwords, SSH keys, API keys, and license keys, etc. Secrets are highly privileged and are required for applications and services to interact. They have their own life cycles that must be managed and maintained. The life cycle determines how they are on-boarded into the secrets management system, how often they are rotated, and how they are requested. Secrets identity attributes can include the applications it gives access and authorization to, its purpose, rotation on-boarding and timeframe for new rotation, and connection perimeters.
Gaps created when managing non-human identities
Organizations that manage non-human identities by simply extrapolating the same processes they use for human identities face numerous challenges and inefficiencies. The problems with this approach are the manual processes, human errors, and the time required to onboard hundreds if not thousands of devices, service accounts, and secrets. Combining human and non-human identities within the same IAM data structure becomes cumbersome, inconsistent, and unacceptable for auditing purposes.
Legacy privileged access management (PAM) solutions are not suitable for hosting secrets associated with microservices, while new data structures must be built to hold and use secrets within cloud services. When secrets identities are not managed effectively within a modern PAM, DevOps processes, container orchestration, and automated deployments can potentially expose them. This can have far-reaching negative impacts.
While IAM systems can categorize human and non-human identities, they cannot separately collect several types of data for dissimilar identities. A data structure that includes 20 attributes—including first and last name, email address, and department—may be valid for a human identity. But when that same data structure includes 20 additional non-human attributes, the data structure becomes too unwieldy and inefficient.
Another problematic practice in managing non-human identities is hard-coding one-time credentials, certificates, and API keys within applications, devices, and microservices. This is a high-risk practice that can expose "keys to the kingdom secrets" to bad actors. All applications and devices should be required to automatically acquire the secrets they need for access and permissions from the PAM system.
Life cycle management of human and non-human identities can have many gaps due to multiple single-function tools for managing legacy passwords, privileged accounts, and deploying secrets. Additionally, an enterprise may lack the IGA processes that differentiate life cycle management for human and non-human identities.
A unified IAM and IGA platform, with separate data structures and processes, is the best practice for managing human and non-human identities. Another effective approach is having different modules within a unified IAM and IGA platform to manage the separate identities. There are four identity data structures or modules that should be separately provisioned within one IAM solution: humans, secrets, service accounts, and devices.
IAM and IGA systems and their processes need to be highly integrated to mitigate the gaps associated with access and authorization policies, connectivity between legacy and modern systems, and single-function tools. When recognizing the relevance of non-human identities, it is highly recommended that ways of managing access and securing the environment are also determined as a priority. Many companies that lack the domain expertise and experience, and do not want the responsibility, risk, costs, and time involved with in-house integration and management, need to seek outside assistance. However, it is important to assess their abilities as security integrators and managed security companies to address non-human identities as efficiently as human identities.
