Amazon Web Services Feed
Architecting Secure Serverless Applications
Introduction
Cloud security at AWS is our top priority, and we have a deep set of cloud security tools consisting of more than 200 security, compliance, and governance services and key features. It’s why a broad set of customers — from enterprises, to the public sector, to startups — continue to rely on the capabilities we provide to ensure their workloads are secure.
In this series of blog posts, we will outline the controls that AWS Serverless services expose, while illustrating how their native capabilities can be used to meet security and compliance needs.
In this introductory post, I’ll talk about the value proposition of serverless architectures, drawing specific attention to changes shared security model for serverless applications. I will also call out specific personas – Developers, DevOps engineers, and Compliance teams — who have an interest in ensuring that serverless applications are deployed and managed securely.
What is serverless?
Serverless is the native architecture of the cloud that enables you to shift more of your operational responsibilities to your cloud provider, such as AWS, increasing your agility and innovation. Serverless allows you to build and run applications and services without thinking about servers. It eliminates infrastructure management tasks, such as server or cluster provisioning, patching, operating system maintenance, and capacity provisioning. You can build serverless architectures for nearly any type of application or backend service, and they handle everything you require to run and scale your application with high availability.
There are four benefits of serverless:
- No server management
- Flexible scaling
- Pay for value
- Automated high availability
Shared security model
Security and compliance are shared responsibilities between AWS and you, the customer. You benefit from a datacenter and network architecture that is built to meet the requirements of the most security-sensitive organizations, while AWS is responsible for protecting the infrastructure that runs all of the AWS cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the AWS compliance programs. Your responsibilities are determined by the AWS services you use as well as other factors, including the sensitivity of data, company requirements, and applicable laws and regulations. This is known as “security in the cloud.”
In the serverless model, customers are free to focus on the security of application code, the storage and accessibility of sensitive data, observing the behavior of their applications through monitoring and logging, and identity and access management (IAM) to the respective service.
Pay particular attention to the dotted box around Platform management, Code encryption, Network traffic, Firewall config, and Operating system and network configuration. While AWS assumes these responsibilities for serverless architectures, you still need to address them for non-serverless architectures.
Security personas
If you have spent time designing and operating server-based applications, consider the following to better understand how serverless changes your security practices:
- Compliance teams need to understand how AWS assumes more of the security responsibilities in serverless applications, whether a service is covered by a compliance standard, and whether any additional configuration must be implemented to ensure compliance.
- DevOps teams need to employ available protective and detective controls to securely deploy and manage serverless applications.
- Developers and their teams need to understand how best to utilize least privilege and use sensitive data in their applications.
The series ahead
In upcoming blog posts, we’ll address topics, such as:
- How users are authenticated and authorized
- How to address the risk of data loss
- How to deal with code injection
- How to address data exfiltration
- How to escalation of privileges, and denial of service
As well, each post will address the concerns of each persona for the relevant services.