The Fundamentals of NHI Security

Read full article here: https://www.andromedasecurity.com/blogs/the-fundamentals-of-nhi/?source=nhimg

Non-human identities (NHIs) are a major risk as businesses use Cloud and SaaS. Breaches involving NHIs are increasing, making them a top priority for CISOs.

An NHI is a digital identity linked to an application or service. It allows the identity to take actions on target systems or resources. Developers and apps create NHIs quickly. This helps automate tasks and connect with third-party services. These identities are key for automation. They help integrate cloud services, SaaS platforms, and on-premises apps smoothly.

NHI Security Challenges

With more NHIs in modern systems, strong management and security are crucial. The main challenges that raise the need for better security include:

• Lack of NHI visibility: NHIs are dynamic and can be hard to track. It’s difficult to know how many NHIs exist or where they are across different platforms and cloud integrations. Many operate in the background, making it tough to monitor their use and permissions.

• Excessive and uncontrolled permissions: NHIs often have more privileges than they need, leading to significant security risks from potential privilege escalation.

• Ineffective lifecycle management: NHIs can become stale or inactive, with some accounts unused for years. This increases the potential attack surface. Human lifecycles are also tied to NHIs and must be managed together.

In this blog post, we discuss three key aspects of NHI security: entitlements, credentials, and client security. We explain how these elements affect your security plan, why entitlements matter, and share best practices for securing credentials and clients.

Note: In this article, “credential” refers to authentication secrets like API keys and access keys. “Provider” refers to a public cloud or SaaS provider.

The Elements of NHI for Security

When creating an NHI, you must manage and secure three elements: credentials, entitlements, and the client using it.

A client (application or workload) uses an NHI to act on resources with a set of entitlements (permissions). The client application authenticates with a credential to prove its identity

1- Credentials

NHIs must use supported authentication methods (username/password, access keys, API keys, key pairs, certificates) to authenticate and establish identity.

Advanced methods like multi-factor authentication and passwordless solutions are not supported for NHIs.

Managing credentials is crucial to reduce compromise risks. This can be owned by the enterprise or the cloud provider.

Best Practice: Use short-lived credentials to limit compromise chances.

2- Entitlements

NHIs have specific privileges that define their actions on systems or resources.

If an attacker compromises an NHI, they gain access to these privileges, expanding the potential attack surface.

The enterprise must assign only necessary privileges.

Sometimes, the entity needing the NHI provides a predefined role with the necessary privileges. In other cases, the enterprise decides and assigns the appropriate ones.

Best Practice: Apply the principle of least privilege to entitlements; it’s the enterprise's last line of defense.

3- Client Using the NHI

The client application or workload using the NHI must be secure from unauthorized access.

The responsibility for securing the workload or client application depends on who controls it. It could be the cloud provider, the enterprise, or a third party.

The key takeaway is that entitlements shape your attack surface. While securing all three elements is vital, if entitlements are limited to least privilege, the business impact of a credential or client compromise is minimized. The attacker faces significant constrain.

NHI Security Implications

An NHI can be used in four ways, based on who manages credentials, who controls entitlements, and where the client workload is located. Below we explore these use cases and their security implications.

Provider-managed NHI

Here, the enterprise creates an NHI for a cloud service, fully managed by the provider.

The three aspects of NHI security still apply:

• Credentials: The enterprise manages no credentials. The provider creates short-lived credentials and handles their lifecycle.

• Entitlements: The provider manages entitlements for the NHI.

• Client: The provider owns and manages the workload/application's security.

Example: In AWS, the AWSServiceRoleForBackup is a Provider-Managed NHI. It helps back up resources in AWS and has entitlements to list, read, and copy them for backup.

Shared ownership NHI

In shared ownership, both the provider and enterprise manage the NHI:

• Credentials - The enterprise manages no explicit credentials. The provider creates short-lived credentials within the workload

• Entitlements - The enterprise controls entitlement management, deciding what permissions are needed

• Client - While the workload runs in the cloud provider's environment, the enterprise secures access to it

Example: An EC2 instance with an instance profile in AWS or an Azure-managed Identity fits here. The application runs in the cloud provider's service, which manages temporary credentials, while the enterprise defines required permissions and secures the client VM.

Enterprise-managed NHI

When an enterprise fully manages the NHI, security looks like this:

• Credentials: The NHI needs explicit credentials, which the enterprise manages.

• Entitlements: The enterprise controls entitlement management and decides the required permissions.

• Client: There are two scenarios:

1. The application runs within the enterprise’s network, and the enterprise secures the workload.

2. The application runs externally in a third-party application. The enterprise shares credentials, and the third party secures the workload.

Example: An AWS IAM User with an Access Key or an Azure Service Principal with Key and Role assignment fits this category. The NHI can be used from anywhere to perform actions on the target system.

External (Third-party) Client NHI

In this case, a third party creates and manages NHI credentials. The enterprise manages entitlements. The third-party entity uses the NHI to perform actions in the enterprise’s cloud environment.

• Credentials: No explicit credential exists in the enterprise. A trust is established with the third party, which manages the NHI credentials.

• Entitlements: The enterprise controls entitlement management.

• Client: The third party owns the workload/application and collaborates with the enterprise to ensure security.

Example: A role-to-role trust between a third-party entity’s AWS account and a role in the enterprise’s AWS account exemplifies this. In Azure, a Service Principal in the customer’s Entra domain may trust a registered Application in a third-party domain.

Summary

To secure NHIs, manage credentials, entitlements, and clients/workloads. Credential and client breaches can happen and may be beyond the enterprise's control. To enhance security, follow these best practices:

• Use NHIs with short-lived credentials whenever possible. This reduces the need to manage credentials and the chance of compromise.

• Focus on entitlements as the most critical aspect. Maintain least privilege for entitlements