Are you currently experiencing an attack?

Are you currently experiencing an attack?

Secure Authentication on Serverless

Serverless takes microservice architecture to its extreme; a single function can be its own service. This often leads to a large number of microservices, which greatly increases the potential attack surface. Thus, it is vitally important to consider security from the very beginning of the architectural design process.

Authentication and authorization are important pieces of the security puzzle. They have to be applied at every level of the architecture, because if the security mechanisms at one level fail, the lower levels have to hold.

If an API key gets stolen, but the serverless functions don’t have any critical permissions, it’s possible that an attacker couldn’t do anything harmful with the key. On the other hand, a user account with too many permissions can become very dangerous if that account is compromised and used by an imposter.

In a previous article, we discussed the basics of cloud identity and authentication. In this article, we’ll discuss the common types of access for serverless functions, the typical problems that arise with specific access types, and the top-tier cloud authentication services that are available to solve these problems.

Service Access in Serverless Systems

In serverless systems, there are four types of access—four categories of communication that must be secured. An individual service won’t necessarily include all four, but whichever categories that it does include must be well-protected. They are:

  • Intraservice: The internal services within a system (such as Lambda functions, step functions, and API gateways) access each other.
  • Outgoing: The internal services access external third-party services to obtain features or data that aren’t available internally.
  • Incoming: External services access services within the network.
  • End users: Customers or other external users access the internal system.

For each of these situations, cloud providers offer authentication solutions. Let’s discuss them.

Intraservice Access

Forming a system by combining serverless services brings many benefits. But every additional service requires you to consider its security.

A service with unnecessary permissions is a liability. Excessive permissions allow unnecessary access to services, data, or actions, and a bug could allow malicious users to exploit that service and leverage its permissions to compromise your system. Therefore, you must carefully consider the permissions needed by each service.

For example, if a service needs to call TransactGetItem() for a DynamoDB, but the serverless.yml contains something like this:

Effect: Allow
Action:
– ‘dynamodb:*'
Resource:
– ‘arn:aws:dynamodb:us-west-1:**:table/TABLE_NAME'

…then the administrator has mistakenly granted all permissions to the service, including the ability to call functions such as DeleteTable() or DeleteBackup().

Correctly managing intraservice access permissions can be an overwhelming task. Fortunately, each of the top-tier cloud providers offers native access management services to simplify this task. Azure has Azure Active Directory, AWS has AWS IAM, and Google Cloud Platform (GCP) offers Cloud IAM.

Of the four types of communication discussed in this article, intraservice access is the one that’s most often neglected. It’s tempting to assume that communication inside your perimeter will always be safe, and indeed, it usually is. Nevertheless, even for serverless functions operating wholly within your system, it’s still important to set up and enforce minimal-privilege permissions, and to remove them when they are no longer applicable. Ideally, they will never be needed at all—but if the need were ever to arise, you’ll be glad that these additional layers of security were there.

Outgoing Access

When your serverless function accesses an external third-party service, it usually requires some kind of access credentials. These credentials must be stored somewhere. Unfortunately, this storage is not always as secure as it needs to be. Even today, some web applications are storing secrets in text files, in databases, or hardcoded inside the function code.

Cloud providers offer services for securely storing secrets and credentials. Azure has Azure Key Vault, AWS offers AWS Secrets Manager, and GCP has Google Cloud Secret Manager.

For more information on this subject, see our article Keeping Secrets in the Cloud.

Incoming Access

SaaS (Software as a Service) is responsible for a large, and still growing, portion of web traffic today. Quite possibly, many functions within your network will be made available as SaaS to external users. Of course, access will be restricted, and each user will need proper credentials to gain that access.

But this raises the same problem discussed above: these secrets need to be stored somewhere. Obviously, you cannot control how your users store the access credentials that you give them. Therefore, you must assume that their credentials are not being stored securely, and that they are subject to compromise at any time.

This might seem like an intractable problem, but fortunately, there’s a solution: to grant temporary credentials. This ensures that even if these secrets were leaked, they would expire soon afterwards.

Again, the cloud providers offer services for this purpose. AWS IAM allows you to create temporary credentials, Google Cloud IAM has short-lived credentials, and Azure Active Directory allows you to configure expiration dates for its shared access signatures.

Designing serverless functions around temporary/expiring credentials can be a little more work, but it’s the best practice. Other recommendations are the same as were discussed earlier for intraservice communication: keep permissions minimal, only add them when needed, and don’t forget to remove them when they’re no longer required.

End Users and Customers

The challenges for this access type are similar to those for Incoming Access, but the solution is not. Whether in a B2B or (especially) B2C environment, few users would tolerate a requirement to constantly refresh or regenerate their credentials. Therefore, a different approach is required.

The top-tier cloud providers all offer a user authentication service: AWS Cognito, Azure Active Directory B2C, and Google Identity Platform. But third-party end-user authentication is also worth considering, because they come without vendor lock-in, and they often provide a much better developer experience. The most prominent third-party auth providers are Auth0 and Okta.

Of course, best practices should also be followed whenever possible. For end user access specifically, multi-factor authentication should be available to all users. Even better is to make it mandatory, at least for those verticals where this can be done without causing bad will among the user base.

Keeping Serverless Systems Secure

Robust authentication is an important security component for any serverless system. However, it is not the only component. An effective cloud security solution is also necessary.

Reblaze provides complete web security, including DDoS protection, ATO (Account Takeover) prevention, bot management, API security, and more. It offers comprehensive protection for serverless systems, along with other types of services, sites, and web applications.

To learn more or get a demo, feel free to contact us.

Get your price quote

Fill out your email below, and we will send you a price quote tailored to your needs

This website uses cookies to ensure you get the best experience on our website.