Managing Non-Human Identity Explosion in the Public Cloud
- By Eric Kedrosky
- Sep 15, 2020
With digital transformation comes the move to the cloud. What many businesses don’t realize is that it requires a retooling of their security strategy from the ground up. In particular, the explosion in the number of non-human identities in the public cloud is a risk that businesses simply can’t ignore. In fact, most businesses don’t even plan for non-human identities, let alone secure them, and that is where an organization can get into significant trouble. However, the good news is organizations can safeguard their cloud environments by taking the necessary steps. Let’s first start with the basics.
What are Non-human Identities?
Non-human identities are identities that act on behalf of a person. They can be pieces of code, such as AWS Lambda functions, or pieces of compute, such as Azure VMs or other public cloud services. Regardless of how you define them, they are extremely useful and often represent the vast majority of identities found in cloud deployments. They do, however, present some unique challenges that are critical to keep in mind.
Why Should We be Concerned with Safeguarding All Identities, Human and Non-human?
Before digital transformation, the network formed the security perimeter for on-premises environments. That is no longer the case. In the cloud, human and non-human identities form the security perimeter and as such, need to be managed effectively.
Examining the Challenges
The first challenge is complexity. Even for organizations born in the cloud, trying to make sense of these identities can be confusing and overwhelming. This commonly leads to cloud misconfigurations, some of which can be absolutely critical.
It is common for an average cloud deployment to have hundreds, if not thousands or more non-human identities. From a management and governance perspective, this creates a rather difficult challenge and if left unchecked can cause a lot of problems such as failure to comply with least privilege and/or separation of duties requirements as well as attesting to what, where and how they can manipulate an entire cloud environment.
Lastly, from a security perspective, the nature of how identities are used makes determining the chain of events for “who did what” very difficult. For a malicious actor, this is a great way to mask their identity and blend in with the cloud environment. Because of this, any way you look at them, non-human identities can take many forms which can be both extremely powerful and pose significant risks in the public cloud.
Data breaches are detrimental to a business. That is a no brainer, but what is worse is when they could have been easily prevented. An important lesson to be learned is that good security comes from good operations. With all the high-profile breaches in the past few years, it is surprising how this simple lesson is overlooked. When analyzing those breaches, as well as helping customers of all sizes in their cloud journey, there are consistent and avoidable mistakes that suddenly appear when it comes to non-human identities.
The Three Most Common Mistakes in Securing Non-human Identities
The first common mistake is allowing overly permissive identities, where the instance, function, etc. has far too many permissions on its own as well as inheriting even more permissions as it is used within and/or across clouds. What started as a function that can do very little in its own account, it now has full admin privileges across the cloud. How does that happen? For reasons explained above, these identities and their usage can get quite complex, quite quickly and as a result, misconfigurations can commonly occur.
A more concerning reason is that these identities are often intentionally over privileged. Why? This is actually the typical scenario while working to create a locked down identity that can do only what it is supposed to do. However, this can be difficult if something breaks and now the business is impacted. Far too often DevOps teams are told to “get it working now” and “go back and fix it later.” In turn, they do what is asked of them and give the identity the wide open “*” privilege, and the crisis is managed, the business is happy, life goes back to normal and the DevOps team goes onto the next task; never to return to fix it later.
This leads to the next common mistake, what I like to call “lost” identities. These are identities that have either been created or modified and then forgotten. They just sit there in the cloud environment, still very much alive but with nothing to do. That is until someone finds it and decides to use it, which leads to the next mistake.
The third most common mistake is that these identities are often used for unintended purposes … or better said “it made that thing work, so I’ll use it for this thing as well.” While true, it worked, but at what cost? Did it just give full access to sensitive data? Do you even know that it has this access? Does anyone know that it has this access? The answer to the last two questions is commonly “no.” Even worse is when a bad actor finds one and uses it for their ends. What a great way to hide their actions. So, if good security is based on good operations then let’s learn from these common mistakes to ensure that your non-human identities are provisioned and managed appropriately, throughout their entire lifecycle.
Spoiler alert, there is no such thing as a silver bullet … no matter what some people say. The truth is that it takes good old-fashioned blood, sweat and tears to effectively manage and secure your cloud environment. That said, there are some best practices within Identity and Data Governance that should be followed to help make that task manageable. While some may say “I hate best practices”; it is important to remember the power is in the context. Best practices exist to point you in the right direction and when applied in the context of your business, they can be extremely powerful.
Best Practices for Securing Non-human Identities
The first best practice is the need to identify all of the non-human identities that truly exist in the cloud environment -- not what your admin team says it should be, not what your audit team has checked off on their spreadsheets, but what actually exists. Next, you need to know and understand what each and every one of their effective permissions are.
This means that you need to know exactly what each identity can do, within and across the cloud environment. Again, this isn’t what your teams think they can do, but what they actually can do. It is important to know, with absolute certainty, if these identities took any unintended actions.
It is critical to understand what data these identities can access inside the cloud environment. Much like in the previous example, it is important to be aware if and/or what has been done to this data. On top of that, given how fast things move in the cloud and the myriad of teams with their hands in it, you need to have this awareness at all times. Only at this point, can you truly attest the ability to manage non-human identities and secure each cloud environment.
Non-human identities represent both an extremely powerful function as well as a complex risk in the public cloud, requiring constant attention. By effectively managing non-human identities, which form part of the new boundary for cloud security, it not only strengthens the information security model, but enables organizations to be able to move at the speed of the cloud.