Each of these technologies uses a different method to address the security issues surrounding non-human identities. In fact, they may all be required – and work together – for a comprehensive plan to secure workload access within your organization.

The Paradox of Nonhumans, Machines, and Workloads Versus Users

When considering this emerging space, it’s natural to draw parallels and lessons from the field of user identity. But there is a critical difference between users and the interplay of non-human, machine, and workload identities. 

Typically, a user has a one-to-one relationship with an account within a service.When you login to, say, Salesforce, there is one account that is associated with you. (There may be a few outliers to this rule, like specialized administrator or developer accounts. But go with us here.) Others don’t use this account. As you move about the organization, travel, or perform other tasks, you use this one account. When you leave the organization, the account is deactivated. You have a single identity that is represented in multiple places.

But when you have a client workload that is accessing a service, this relationship doesn’t hold. A client workload has an identity, but the workload itself may scale and run in many places. The workload can be terminated and then spun up again somewhere else. 

On the other hand, service accounts (non-human identities) exist within server workloads independently of workload identities. They persist regardless of the existence of any particular workload identity. To add to the complexity, multiple workload identities can use a single service account, as the service account represents a set of authorizations within the server workload.

And when a developer or DevOps professional leaves your organization, it’s likely that none of these service accounts are deactivated. The workloads continue to function, carrying out their tasks even in the absence of their original creators or handlers.

Non-Human Identity Management (NHIM): Governance for Service Accounts

Definition

Non-human identity management focuses on the governance and monitoring of accounts typically not tied to human users, such as service accounts. Tools similar to cloud infrastructure entitlement management (CIEM) fall under this category, providing visibility and control over these non-human entities.

Key Characteristics & Benefits

• Service Account Focus: Primarily deals with managing identities for service accounts in cloud or SaaS environments.
• Governance and Monitoring: Provides detailed insights into service account usage patterns and permissions.

Security Risks

• Insufficient Access Control: While NHIM provides visibility, it lacks mechanisms for access management.

Management Risks

• Visibility Without Control: Monitoring without the ability to enforce strict access controls maintains the current cycle of manual remediation and credential rotation for service accounts.
• Lifecycle Management: Deprovisioning and rotating service accounts – and, more importantly, the downstream workloads that use service accounts – isn’t fully automated

Examples

• CIEM Implementation: Using CIEM and similar tools to monitor and audit service account activities in a cloud environment, identifying and mitigating risks associated with overprivileged accounts.
• SaaS-to-SaaS Connectivity: Governing the relationship among connected SaaS tools, typically via a user provisioning cross-SaaS permissions.

Machine Identity Management (MIM): Establishing Trust for Machines

Definition

Machine identity management involves assigning and managing digital identities for various types of machines, including servers, IoT devices, and software applications. These identities, typically in the form of certificates, are used to authenticate and secure their communications.

Key Characteristics & Benefits

• Identity Provisioning: Certificates are created centrally via a certificate authority and securely distributed to endpoints.
• Well-Understood Technology: MIM has been around for over a decade, so its strengths and weaknesses are well documented.
• Broad Applicability: MIM can be used across diverse devices and software, providing a foundational layer of trust.

Security Risks

• Certificate Compromise: Certificates are a stored secret. If certificates or their private keys are compromised, attackers can impersonate legitimate devices.
• Lack of Access Control: While MIM ensures the authenticity of machines, it does not manage the access rights or permissions of these identities.

Management Risks

• Lifecycle Complexity: Managing certificate issuance, renewal, and revocation across numerous devices can be operationally challenging.
• Scalability Issues: As the network grows, the complexity and overhead of managing certificates increase exponentially.
• Architectural Shift: Certificate management does not work as well with the dynamic, ephemeral architecture of cloud services or third-party cloud services.

Examples

• Internet of Things Security: Unique certificates are assigned to IoT devices to ensure secure communication within a smart home ecosystem.
• Server Authentication: TLS certificates are used to authenticate servers in a data center, ensuring secure intra-network communications.

Workload Identity and Access Management (WIAM): Bridging Workloads and Nonhumans

Definition

Workload identity and access management provides access management based on identity, bridging the gap between machine identities and service accounts. WIAM leverages the principles of machine identity to authenticate workloads and applies dynamic, policy-driven access controls with credential management to eliminate secrets in your environment.

Key Characteristics

• Identity-Based Access Management: Ensures that access from workloads to nonhuman service accounts is governed by identity-based policies.
• Dynamic Policy Enforcement: Provides real-time, fine-grained control over workload interactions.
• Secretless Access or Just-in-Time Secrets: Injects credentials in real time, automating the management of credentials used to access nonhuman service accounts.
• Flexibility: Works across clouds, on-premises environments, and SaaS applications, and can use various forms of identity, including machine identity certificates.

Security Risks

• Policy Misconfiguration: Inaccurate or overly permissive policies can expose workloads to unauthorized access.

Management Risks

• Integration: Integrating WIAM with existing development frameworks and tools can require additional upfront planning.
• Policy Updates: Maintaining up-to-date policies requires automation or ongoing vigilance and adjustments as the environment evolves.

Examples

• Secure CI/CD Pipeline: WIAM can manage access among services in a CI/CD pipeline, eliminating stored secrets.
• Secure Access to Sensitive Data: WIAM can verify identity, check workload posture, and validate that a workload should be granted access to sensitive information such as customer records, patient data, or proprietary code.

Summary: How Nonhuman, Machine, and Workload Identity Management Complement Each Other

Non-human identity management, machine identity management, and workload identity and access management each serve distinct purposes within an organization’s security architecture. Machine identity management provides foundational trust for a broad array of machines and software but lacks access management capabilities. Non-human identity management offers governance and visibility for service accounts, similar to CIEM tools, but also lacks access control. Workload identity and access management bridges the gap by providing dynamic, identity-based access management for workloads without specifically managing service accounts.

Cybersecurity architects and security engineers can create a robust and comprehensive security framework by understanding and leveraging these tools appropriately. Each approach has its strengths and limitations, and they are not mutually exclusive. Instead, they complement each other, offering layered security that enhances the overall resilience of an organization’s IT infrastructure.