Security and Shared Responsibility Models
In the past years, application development has moved to Serverless Architecture so quickly that most of our customers are now focused on cloud-managed and serverless services as a first choice. Switching from the IT classic model to an IT serverless model for our clients is a significant transformation and comes with technical and cultural challenges. Part of disruptive cloud transformations is the journey to implement Serverless Architecture Best Practices for new projects or redesign legacy applications.
It is the architect's responsibility to provide the best recommendation for development modernization. When architecting cloud solutions, it is vital to have fundamental knowledge and understanding of cloud Well-Architected Framework. This framework provides the best practices, recommendations, and key cloud-native services to ensure successful project delivery and cloud operations.
AWS, Azure, and Google Cloud Platform public cloud providers built this framework on 5 Pillars: Operation Excellence, Security, Reliability, Performance Efficacy, and Cost Optimization.
Top risks & differences for classic and serverless applications
To understand serverless architecture, the first step is to understand the security responsibility of development teams. OWASP recommendations and Top Web Application Security Risks for serverless applications are evolving. As a result, Solution Architects, Developers, and IT Operation teams meet new challenges regarding changing roles, responsibilities, and accountabilities when it comes to secure environments and apps.
Here are some of the top risks for application development
When summarizing top risks for the serverless application, it is important to apply best practices for a serverless distributed architecture. Our focus should be on cloud service configuring, application deployment, and database encryption at rest and in-transit. Native cloud services provided IAM and managed policies to be implemented inside cloud environments for serverless services access and database encryption. Outside cloud provides, 3rd party connection like HTTP will need another solution since security methods inside the cloud cannot be transferred outside of the clouds. All the requests outside of the cloud environment should take place over a secure connection like HTTPS and should be monitored on Firewalls and API-managed services.
Serverless architecture is highly distributed and can be challenging for testing and monitoring. Therefore, it is important to enable function monitoring and authentication provided by native cloud services for unit and integration testing.
Shared Responsibility Models
Shared Responsibility Model for cloud provides and customers are also shifting responsibility to the development team. The following diagrams come from the AWS documentation, but it represents high-level principles adopted by AWS, Azure, and GCP cloud providers.
Here is the Shared Responsibility Model for Classic Solution
The Shared Responsibility Model for Classic Solutions Architecture is usually adopted during migration from on-premise data centers implementing lift-and-shift (rehosting and re-platforming) and repurchasing strategies. I often refer to those migration strategies as compute hosting that the cloud provides.
This model shows that cloud providers are responsible for the resources “of” the cloud with built-in security controls. Customers are building on those resources and security. Customers are in charge of “in” the cloud security of application code, database, storage, identity and access management (IAM), configuration and security of our virtual private networks, login and monitoring of our infrastructure, and internal and external connectivity.
Shared Responsibility Model for Serverless Solutions
The Shared Responsibility Model for Serverless is more adapted by Refactoring / Re-architecting migration strategies and new apps development. As a customer, we need to remember that we are in charge of the security of serverless application code, database, storage, login and monitoring, observability of all application transactions, and identity and access management (IAM).
With serverless development, there can be challenges with increased attack surface and the complexity of the attack due to a much larger set of input sources. The next challenge is to choose new tools which are providing insight into our serverless systems. We also need to understand that the dotted line around platform management, code encryption, network traffic, firewall-config, and operating system and network configuration is still our responsibility.
- Open Web Application Security Project® (OWASP) guidance:
- Cloud Security Alliance (CSA) guidance:
- PureSec develops a cloud-based cybersecurity platform: https://www.crunchbase.com/organization/puresec
- Shared Responsibility Model
- Architecting Secure Serverless Applications https://aws.amazon.com/blogs/architecture/architecting-secure-serverless-applications/