What are Non-Human Identities (NHIs), and how do we secure them?

When discussing cybersecurity, we often say that humans are the weakest links in the information technology chain. That social engineering scams, credentials leaks, and human mistakes cause the most breaches every year. So then, why would you be so concerned with Non-Human Identities (NHIs) when, frankly, they are the opposite of humans? Well, I'm here to tell you that it's essential to understand NHIs and how to secure them to keep your cloud environment vulnerability-free. 

Non-Human Identities (NHIs) are digital identities associated with non-human entities, such as apps, serverless functions, IoT devices, and other automated systems. As companies use more and more complex cloud computing capabilities, they tend to move towards automation tools, and that’s where NHIs come into play. They make automating processes much easier, but because environments grow and the number of NHIs grows as well, they can become hard to manage.  

In the following image, you can see service accounts and managed identities, along with their security score, workload, permissions, and the cloud to which they belong. In a multi-cloud environment such as this one, a centralized dashboard is the key to visibility, and visibility is the first step towards security in the cloud.  

It all starts from this dashboard. And in this article, we will look at best practices to secure NHIs and provide actionable insights to improve your cloud security posture today. 

Follow the Least Privilege Principle 

To allow service identities to perform the actions we want them to, we must grant them the necessary permissions. Sometimes, it can become confusing what kind of permissions they need, so assigning broader roles to get rid of that annoying error you're getting is, while very wrong, not out of the question in complex environments, where developers scramble to meet deadlines. Let’s look at an example. 

When you create a Lambda function in AWS, you need to provide a Lambda execution role, which is an IAM role that specifies the permissions your serverless function has to access services and resources in AWS. It is recommended that you assign minimum permissions.  

For example, if you want your Lambda function to write to CloudWatch logs, there is no reason to assign a highly privileged role; AWSLambdaBasicExecutionRole is enough. By granting the least privileged role possible, you’re reducing the attack surface in your cloud environment. 

To follow the Least Privilege Principle, follow this checklist: 

1. Analyze what permissions your Non-Human Identity needs and assign those. Do not use broad IAM roles such as AdministratorAccess in AWS or Owner in Azure and Google Cloud, but instead, go for granular permissions, either using managed policies or custom policies that you can tailor to your specific needs. 

2. Set permission boundaries. You can set permission boundaries for AWS roles, meaning that whatever permissions an IAM policy would define, they must fit within the boundary; if the boundary allows the role to have privileges over S3 and EC2, then the entity assigned that role will never have permissions over the IAM service, even if the IAM policy allows that. 

3. Monitor your NHIs activity to ensure that they behave as intended. By continuous logging and monitoring, you can identify suspicious behavior in your cloud environment. 

Manage credentials safely 

While your service accounts can’t fall into a phishing scam and email credentials, credentials still might not be managed properly. So let’s look at best practices to ensure proper protection of NHI secrets. 

Don’t use secrets in the code 

Avoid storing secrets in the code or config files, as these can be accessed or exposed. Instead, leverage secure secrets management solutions that provide centralized storage and encryption of credentials. Examples include: 

• AWS Secrets Manager,  
• Azure Key Vault, or  
• Google Cloud Secret Manager. 

Rotate secrets and keys 

Regularly rotate credentials to reduce the window of opportunity for attackers in case credentials are compromised. Automated rotation mechanisms provided by secrets management solutions like the ones mentioned earlier in this section can simplify this process and ensure that credentials are regularly updated without manual intervention.  

The NIS2 is crucial for implementing cybersecurity best practices and protecting critical infrastructure. Organizations can mitigate risks and contribute to a safer digital environment by adopting the mentioned requirements.

Update and patch often 

Keep NHIs up-to-date with security patches and software updates to address vulnerabilities and mitigate potential security risks. Constantly update to the latest platform versions, schedule patches and don’t delay them, install updates on operating systems, and so on. To do this as efficiently as possible, implement automated workflows for downloading, testing, and applying patches to minimize manual intervention and accelerate response times. 

Moreover, stay informed regarding emerging threats to patch zero-day vulnerabilities as they appear. We all remember Log4J, right? Well, companies took months and even years to fix the Log4Shell vulnerability, and exploits are still successful to this day, with an article from IBM reporting that in August of 2023, Log4Shell was still the most exploited vulnerability. 

You no longer only worry about who has access to your cloud environments but also what. Cyscale’s updated Identity view now allows you to understand exactly which non-human identities can access what cloud resources, streamlining non-human identity management. Besides users and groups, we strive to help you understand and manage permissions effortlessly. This new dashboard is your gateway to securing your cloud efficiently. Book a demo now to see where your company stands with cloud security.