Top Considerations for Serverless Security

Top Considerations for Serverless Security

In recent years, serverless computing has led to growth in the ecosystem of new solutions that provide visibility, real-time tracking, deployment frameworks, and application security. As awareness of serverless security is also on the rise, so does the natural fear, uncertainty, and doubt in regard to the potential for more security problems.

The process of technological evolution will inevitably have security concerns, but these are not cause for a standstill. The ideal approach is to address these security concerns with equally evolved advancement. It is important to understand serverless computing and look at the serverless security concerns, such as insecure third-party dependencies, multi-tenancy, and others.

This post will cover some of the best practices you need to be aware of in properly securing your serverless functions.

What Is Serverless Computing?

The Cloud Native Computing Foundation (CNCF) defines serverless computing as a concept of building and running applications that do not require server management, allowing you to manage your application deployments at the service deployment level rather than the server deployment level. It differs from traditional architectures because it is managed by a third party, is natively event-driven, and exists within a stateless container.

Using serverless architecture, a series of functions, such as business logic, user authentication, databases, and other components needed for specific activities, will be deployed to a platform and then executed, scaled, and billed in response to the exact demand needed at the moment.

For example, instead of a long-running email service, with serverless computing, you only need to trigger the serverless email function to send an email.

Use Cases

Serverless architecture has been developed over the years since it was proposed, and it has many positive characteristics and use cases. However, it also has its own limitations; namely, because of its stateless and lightweight qualities. Serverless computing can perform very well in some scenarios but may not perform well in others. For best results, it should be considered when the workload is as follows:

  • Is asynchronous and concurrent, with components that can be deployed and scaled independently.
  • Involves unpredictable service usage or has near-zero demand.
  • Entails transient, stateless applications that are insensitive to cold start times.
  • Is highly dynamic in terms of the need for rapid development iterations.

Security Concerns

Although cloud vendors provide security services and some basic security policies, you often need to spend money to purchase related services, and some policies still need to be configured yourself. Regarding the security of serverless architecture, be sure to pay attention to some of the following areas of concern:

  • Vendor security: serverless functions are executed on the provider’s infrastructure, which must be trusted.

  • Multi-tenancy: functionality in serverless services typically runs on a shared infrastructure that runs code for multiple customers; this can be a problem when sensitive data is involved.

  • Injection attacks: in an injection attack, unauthorized or unexpected content or data are injected into the application stream. In the serverless model, an injection attack can come from malicious events that cause a serverless function to execute on bad data.

  • Encryption: serverless functions can often invoke databases and other privileged resources; if the connection is not encrypted, data can be compromised.

  • Secrets misconfiguration: to access different resources, developers may enter access keys, tokens, and passwords directly into the function; failing to protect these secrets is a risk.

  • Functional permissions: usually, serverless functions are granted the same permissions as a server would get. However, serverless functions require only minimal privileges to execute, and overconfiguring privileges exposes the function to potential risk.

  • Component vulnerability: features often rely on third-party libraries and a supply chain of components. If there is a known (or unknown) vulnerability in one of these components, the serverless function could be exploited.

Top Considerations for Securing Serverless Functions

To manage serverless security is to have proper controls and strategies in place. Although cloud computing server security policies may be effective for Virtual Machine instances in the cloud, serverless computing requires additional levels of control, granularity, and visibility. The following list outlines the top areas that engineers should consider to ensure a secure serverless architecture:

Reduce Serverless Permissions

A risk of serverless computing is having functions with more permissions than needed. With serverless systems, the attack surface can be significantly reduced by implementing a least-privilege model for all deployed functions. In the development phase of the function, you can set up automatic checks in the staging environment, reducing the number of permissions. By analyzing function behavior, you can also view the privileges used by the function in production. With this visibility, the administrator can tweak policies to reduce the configured permissions.

Implement Authentication

All functions that invoke a service, whether the service is within the same cloud provider or not, must require access control and authentication to help limit risk. Cloud providers, like AWS, provide best practices on how to implement serverless authentication, and administrators should follow these practices.

Cloud Platform Provider Controls

Cloud computing providers also have a variety of built-in services that can help you identify potential misconfiguration. For example, AWS Trusted Advisor is an option for running AWS Lambda.

Log Function Activity

Since serverless functions are event-driven and stateless, you will usually miss most activities when viewing real-time activities. Your serverless functions operate independently, and this can cause problems, such as insufficient exception tracing. By using a cloud computing provider (or third-party) logging and monitoring service for serverless functions, audit trails can be used to assist with debugging and threat detection.

Security Scanning

You should use a fully automated scanning feature that includes checking and monitoring all open-source components used by the system. For example, if you use AWS Lambda, you can use WhiteSource’s serverless integration to scan and monitor deployed functions. WhiteSource will automatically identify all open-source components and dependencies, and then check them against its database of open-source repositories for security vulnerabilities and licenses. Once detected, you can apply automated policies, define workflows, and collaborate on information across your team.

General Security Practices

Finally, here are some of the best general practices and rules that you should follow to build secure serverless applications:

  1. Keep your codebase organized by distinguishing resource definitions from functions. You can use different resources as parameters instead of hard-coded strings, and you can minimize the size of the package by sharing code.

The following two examples show a good codebase organization structure. The first shows functions using a common shared library:

Functions of the shared library

The second example is provided by the serverless stack:

Shared resources

  1. Follow the principle of least privilege and limit the roles in identity and access management (IAM) to a single functional level.

  2. Use services, such as AWS SSM Agent, to manage the keys that are platform-specific with AWS.

  3. A single serverless function can only perform one task. If the output of a function needs further processing, save the output to a data storage provider. This save action can trigger another function; do not use the current function to call another function.

  4. Use remote connections as little as possible. No matter how complicated they are, most of the functions should locally process their input and then return the corresponding result. Note that a remote connection will not only increase latency but may also cause problems during debugging and expansion.

  5. Use dependencies as little as possible. It is best to place them in the shared layer mentioned above and continuously perform security scans.

Conclusion

In this roundup, you have learned about top security principles and techniques to help you avoid common serverless security risks and ensure the safety and reliability of your application. However, because an organization’s serverless environment is unique, each approach to serverless security will vary.

The serverless environment is always the most important consideration; whether the environment needs deployment configurations, permissions models, or logging tools, out-of-the-box solutions will provide organizations with the best protection when security features are customized to the specific environment.

Because of the vast amount of options available, adopting a unique approach using out-of-the-box solutions can be daunting. Suborbital, a platform for simplifying the deployment environment for web services, ensures that software engineers have the tools they need to safely build useful functions. This is made possible by the unique security properties of WebAssembly’s sandboxing architecture, which uses a deny-by-default approach to executing code. This helps ease securing serverless services by only granting capabilities to functions as needed. With Suborbital, software engineers are free to focus on what really matters—writing serverless functions without worrying about serverless security. Learn how this is possible by requesting early access today.

Cover photo by Cristina Gottardi on Unsplash