The AWS Shared Responsibility Model
AWS uses a shared responsibility model to define the remit of application security consumers and the cloud provider (see Figure 4-3). The important thing here is the shift in security responsibility to AWS when using cloud services. This is increased when using fully managed serverless services, such as compute with AWS Lambda: AWS manages patching of the Lambda runtime, function execution isolation, and so on.
Serverless applications are made up of business logic, infrastructure definitions, and managed services. Ownership of these elements is split between AWS and the con‐ sumers of its public cloud services. As a serverless application engineer and AWS customer, you are responsible the for security of:
- Your function code and third-party libraries used in that code
- Configuration of the AWS resources used in your application
- The IAM roles and policies governing access control to the resources and func‐ tions in your application
Figure 4-3. The cloud security shared responsibility model: you are responsible for security in the cloud, and AWS is responsible for security of the cloud
Think Like a Hacker
With your foundational zero trust, least privilege security strategy and a clear delinea‐ tion of responsibility in place, the next step is to identify the potential attack vectors in your application and be aware of the possible threats to the security and integrity of your systems.
When you imagine the threats to your systems, you may picture bad actors who are external to your organization—hackers. While external threats certainly exist, they must not overshadow internal threats, which must also be guarded against. Internal threats could, of course, be deliberately malicious, but the more likely scenario is that the vulnerabilities are introduced unintentionally. The engineers of an application can often be the architects of their own security flaws and data exposures, often through weak or missing security configuration of cloud resources.
The popular depiction of a hacker performing an obvious denial of service attack on a web application or infiltrating a server firewall is still a very real possibility, but subtler attacks on the software supply chain are now just as likely. These insidious attacks involve embedding malicious code in third-party libraries and automating exploits remotely once the code is deployed in production workloads.
It is essential to adopt the mindset of a hacker and fully understand the potential threats to your serverless applications in order to properly defend against them.