The first edition was published in 2020, and with the pace of change being as brutal and unforgiving as it is, I started making notes for the second edition within a month of finishing the manuscript. The overall structure has remained the same, but I go far deeper into the different topics in the 2nd edition. There are also more visuals and a couple of new topics. This series of articles provides a summary of each of the chapters with some personal afterthoughts. Serverless Beyond the Buzzword 2nd edition can be purchased here: https://link.springer.com/book/10.1007/978-1-4842-8761-3
Written article continues below the video
Chapter 4 covers several critical security topics in a serverless context.
The cloud offers 24/7 security and operations, the cost of which is included in the service fees with economies of scale that are difficult to replicate for a single organisation. This is a great benefit and, for many smaller organisations, a higher level of security than they would be able to achieve on their own. This benefit goes even further with Serverless because the provider’s scope includes the security of operating systems, software, and other aspects. The challenge is that cloud services are still very configurable; this makes them flexible but easy to misconfigure.
Shared responsibility
All cloud service providers have the concept of shared responsibility, which means both the provider and the account owner are responsible for the security of the cloud account and the applications within it. At a high level, the more abstracted or managed a cloud service is, the more responsibility lies with the cloud service provider.
With Infrastructure as a Service (IaaS) or servers in the cloud, the provider is only responsible for network, hardware, and physical access. The organisation is responsible for maintaining the operating system and software, access permissions and firewall configuration, and the application code. With Platform as a Service (PaaS), such as containers and databases, the provider takes care of the operating system and platform, and sometimes the software. With Function as a Service (FaaS) or Serverless, the organisation is only responsible for the application code and access permissions. VPC and related configurations are optional, depending on where the microservices are launched.
The Principle of Least Privilege (PoLP)
This principle is about providing an entity with only the minimum permissions needed. It is a common security strategy not unique to Serverless but considerably more powerful in this architecture. Privilege means access or permission; it sets what a given user or service can access within an IT environment. While it is attractive and certainly easier to provide all microservices in a given solution full access to the other resources in the application, they should be limited to the specific resources and actions they need.
In a traditional monolithic solution, we achieve the Principle of Least Privilege by assigning the least number of permissions required to the entire application for it to perform its task. There is no way to provide a particular set of permissions to a part of the application. As such, all levels of access and all types of actions are provided to the entire application if any part of the application needs it.
Due to the distributed nature of Serverless architecture, we can provide each component with its own unique set of permissions. This means they can be far more fine-grained and minimal compared to server permissions.
Identity and Access Management (IAM)
For assigning permissions, AWS offers the IAM service. It enables you to control who is authenticated and authorised to use the various cloud resources within or associated with a given application.
IAM consists of three main parts:
- IAM Policy: Defines the list of actions that an entity can make. There are AWS-managed policies, such as broad read-only and view-only policies, and we can create policies with specific permissions.
- IAM Users: Accounts intended for humans. They can have individual policies or shared policies. Users can optionally be added to one or more IAM Groups where group-level policies can be applied.
- IAM Roles: Assumed by trusted entities such as users, applications, and AWS services. Roles are assigned individual policies.
Use appropriate services to store sensitive data
Sensitive data such as user credentials, API keys, and database credentials should not be stored in Lambda code, environment variables, or infrastructure templates where there is a high risk of exposure. If credentials end up in a publicly accessible repository or storage facility, even for a few seconds, they should be considered compromised and replaced immediately. One way to monitor for such occurrences is to use tools such as Amazon Macie to scan S3 buckets for sensitive data. For GIT repositories, a tool provided by AWS called git-secrets can be used to scan for sensitive information.
AWS security services
This chapter also covers several AWS services that can make it easier to manage security in the cloud.
- AWS Organizations is an account management service for consolidating multiple accounts into one organisation.
- Single Sign-On (SSO) is a cloud-based service that simplifies central management of SSO access to multiple AWS accounts and applications.
- AWS Config provides a detailed view of the configuration of AWS resources in an AWS account. We can use AWS Config to define rules that evaluate resource configurations for data compliance.
- Amazon GuardDuty is a threat detection service that continuously monitors the cloud environment looking for malicious and unauthorised activity.
- Firewall Manager offers centralised management of firewall rules and other security components for the organisation's accounts.-
... and many others. A detailed overview of ElectricEye is also provided, a third-party alternative for AWS Config that can implement highly effective detective controls.
Securing the environment
Chapter 4 describes a few strategies for improving security in the cloud and looks at how Serverless can help comply with privacy regulations.
Serverless microservice architectures give developers some unfair advantages for ensuring data privacy regulation compliance. Serverless architecture provides incredibly fine-grained control over the permissions of each microservice and the data it can access. From a privacy perspective, Serverless greatly lowers the amount of redundant access to data and provides better audit capability over the remaining access. Serverless architecture can enable just one microservice to access a particular database or storage facility. This microservice has exclusive access to the sensitive data stored there.
Check out the book's mini site for more information and ordering here: https://serverlessbook.co