4 mins to read
This article explains the importance of securing human and non-person identities as more organizations implement serverless within their public cloud architectures.
A growing number of organizations today are experimenting with serverless computing frameworks — the process of allocating and provisioning servers, services, and computing resources is given to a cloud provider, like Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform (GCP). According to a O’Reilly survey of 1,500 respondents in multiple industries, 40% of organizations have adopted serverless architecture. According to this group, the top reason for adopting serverless is reduced operational costs and automatic scaling.
A serverless framework enables your organization to outsource server-related tasks to a cloud provider. You can quickly run your code using serverless without the burden of handling time-consuming, laborious operations and administrative tasks. By leveraging a serverless architecture, developers can instead focus their attention on building and running applications — the job you hired them to do — contributing to the organization’s innovation and critical business functions. However, with this ease of use, your environment exponentially increases the number of non-person identities leading to security risks.
Using Serverless Identities Introduces New Challenges
With every major advancement in software development and technology operations comes a shift in security risk management. With the shift to serverless, security professionals must adapt and find new ways of hardening, defending, and governing their applications. On the upside, they no longer have to worry about securing the underlying infrastructure as the CSP takes care of that traditional IT Application and Infrastructure Security.
Traditionally, organizations protected their apps by relying on infrastructure and network-based security tools. They inspected traffic with a firewall, detected malicious activity with an intrusion detection system, or protected applications with runtime application self-protection (RASP) technology. Even with containers, organizations could still rely on the underlying infrastructure’s security measures to a certain degree. This is no longer the case with serverless applications and other non-person identities.
Serverless Security
The concept of a serverless application presents one of the biggest paradigm shifts ever seen when it comes to application security. A serverless application consists of distributed cloud services working together. Looking at a common example: a change with an AWS S3 bucket triggers a Lambda Function to run a piece of code that makes modifications to the DynamoDB table. In this architecture, the non-person identities assigned to the serverless functions or applications are now the new perimeter. Instead of focusing on network inspection and access control lists, the serverless model shifts security focus to identities, effective permissions, and data access. Through automation, policies are set, baselines established, then monitored for anomalies in behavior, including privilege and access.
At first glance, serverless applications may seem relatively harmless. But take a closer look, and you’ll find there are some important security risks that can derail an application, leading to a misconfigured non-human identity and possible data breach.
Different Types of Non-Human Identity (Serverless) Security Risk
One of the top risks associated with serverless applications is lack of visibility into effective permissions – the actual resulting permission that an identity has towards a resource. Therefore, you must manage visibility into access and permissions to execute least privilege and least access policies. Just one overly-permissive permission serverless function can be disastrous and costly. This is why you need to implement a robust identity and data security platform, which provides end-to-end visibility. You will receive alerted when a serverless function drifts and enforce appropriate control policies.
Toxic Combinations
An often missed risk, one with serious consequences, with serverless applications is toxic combinations, where the totality of an identity’s permissions an over-privileged state. The result is that a malicious actor can take advantage of this and stealthily perform actions, such as escalate privileges, and/or access resources and data that the function was not intended to. Teams must find those risks and eliminate them, then write policies for those roles that enforce least privilege.
Separation of Duties (SoD)
Another risk with serverless applications has to do with SoD. SoD refers to the principle that no user should gain enough privileges to misuse resources on their own. Whether unintentional or malicious, privilege escalation can lead to increased risk. Teams must eliminate redundant identities and divide responsibilities among team members, lessening the likelihood that any single identity will have enough privilege and access to compromise the environment.
Least Access and Least Privilege
Another serverless application risk has to do with violations to least access and least privilege. Changes are, you have a number of identities with access to more resources than they need. A user with an account, role, or piece of compute can escalate their access and privilege, for example, by adding a policy that increases permissions at their disposal. Within that permission, s/he can create a new user that further escalates their permission to that role, and so on. Organizations must enforce least access and least privilege for human and non-person identities.
Serverless Misconfigurations
In addition, developers need to pay careful attention to serverless misconfigurations. Oftentimes, out-of-the-box settings configurations are not sufficient. It is necessary to update the settings to match the organization’s security and compliance requirements. Applying the wrong configuration can and has led to data breaches. For example, check out the Capital One Lambda data breach’s details.
Managing Effective Permissions in Serverless Applications (aka Non-Person Identities)
Remove Serverless Dormant Non-person identities. Serverless applications or non-person identities don’t just appear out of thin air. Developers who create components, e.g., Lambda functions and associated non-person identities, must ensure to delete them when no longer needed. By not deleting them, you have an army of dormant non-person identities in your environment, increasing costs and security risks. What’s worse, you can’t even see this hidden risk.
A non-human identity, serverless function, will need administrative access to execute these tasks. They will also need special permission to create S3 buckets for function deployments, submit certain templates, create log groups, create REST APIs, and so on.
All of these responsibilities need to be carefully tracked and monitored for security purposes. After all, the last thing you want is a non-human identity spinning up a data store, like an S3 bucket, without your knowledge. Once you deploy a serverless application, you must ensure further identity and data security monitoring.
Conclusion
As you can see, there’s a lot to consider when deploying cloud security for non-human Identities, like serverless architectures. If you’re not careful, serverless Identities can open the door to many risks — negating the time and cost-saving benefits for which you are using them.
Read the latest news and insights
09.19.2022
Understand the difference between fact and fiction...
03.10.2021
When you think of identity management in an enterprise...
