Cloud security is our top priority. That is undeniable. It is important and it is needed. When you’re designing serverless architectures, the best practices that apply while securing any other cloud architecture still apply.
One benefit of serverless architectures is that when you leverage Amazon Web Services (AWS) managed services, you shift the burden of the shared responsibility model toward AWS. You have the same security issues, but AWS manages more of them on your behalf. For AWS Lambda specifically, you aren’t responsible for the operating system or network configuration where your functions run.
So let’s discuss about three general best practices that you are responsible for:
- Follow the principle of least privilege
- Protect data at rest and in transit
- Audit your system for changes, unexpected access, unusual patterns, or errors.
In other words, only let in people you invite, lock up your private stuff, and make sure no one is doing anything unexpected while visiting. This means how to protect the data that comes into or resides inside the house.
When you are setting the permissions with IAM policies, remember that to only give the necessary permission to complete a task. You can achieve this by specifying least-privilege permissions, commonly known as the activities that can be performed on specified resources under specific circumstances.
How you want to know that I have already given only the necessary permissions? Well, there are 2 approach for this, and it's totally up to you on which approach you want to choose.
Begin with broad permissions and over the time you can strive to grant fewer permissions as your use case develops. Always check and keep cutting the permissions that you do not need. But don't forget afterwards to cut out the permissions that you do not need.
You can start with granting permission that you think you only need. If you are not sure, then just don't put it yet. Try, do and check. This approach will need you to have a debugging skills to check on the logs. The reason is, you might encounter not enough permissions when doing something. Then, add the permission for the things that you do not have permission with.
So which one do you want to choose? Up to you. I personally will go with the first approach as it will take me faster time to develop or do something. I will have less time encountering not enough permission issue.
Other than that, you can use the AWS managed policies that grant permissions for many common use cases. They are available in your AWS account. You can also use IAM Access Analyzer to help you generate least-privilege policies based on your access activity. When you want to move to production, you can use IAM Access Analyzer policy validation to help you do the validation and giving you actionable recommendations to help you author secure and functional policies.
One of the most fundamental ways to protect data at rest is by encrypting it. AWS offers several encryption options, including server-side encryption (SSE) and client-side encryption. With SSE, data is encrypted and decrypted automatically by AWS services, while with client-side encryption, data is encrypted and decrypted on the client-side using an encryption key.
Use AWS KMS
AWS Key Management Service (KMS) is a fully-managed service that makes it easy to create and control encryption keys. AWS KMS can be used with other AWS services to provide secure and easy-to-use encryption features.
Use S3 Bucket Policies
S3 bucket policies can be used to control access to data stored in S3. Bucket policies can be used to deny or allow access based on conditions such as IP address, time of day, or request type.
HTTPS (HTTP Secure) is a protocol for secure communication over the internet. HTTPS is used to encrypt data sent between the client and server and helps prevent eavesdropping and tampering.
Use AWS Certificate Manager
AWS Certificate Manager (ACM) is a service that makes it easy to provision, manage, and deploy SSL/TLS certificates for use with AWS services. ACM provides a simple way to secure traffic between AWS services and applications.
Use VPC Endpoints
Virtual Private Cloud (VPC) endpoints provide a secure and private connection between AWS services and VPCs. VPC endpoints can be used to route traffic directly between AWS services without the need for an internet gateway or NAT gateway.
For additional information, when it comes to passing data to Lambda functions, you have three options:
|1||Environment variables||Scoped to a single function|
|2||AWS Systems Manager Parameter Store||Can be shared across multiple applications|
|3||AWS Secrets Manager||Can be shared across multiple applications|
Choose whatever fits your use case!
Another crucial component of safeguarding a serverless architecture is auditing your system for changes, unexpected access, unusual patterns, or errors. In order to identify any odd or suspect activity that can point to a security threat or a system fault, this process entails monitoring and analysing numerous system logs and data.
To check your system for modifications, unauthorised access, odd patterns, or mistakes in AWS, you can use a variety of tools and services, such as:
This service keeps a thorough record of all activities that take place in your AWS account. Every API activity in your account, including API calls, AWS Management Console sign-in events, and AWS service activity, may be tracked and recorded using CloudTrail.
AWS Config is a service that offers a comprehensive list of AWS resources, configuration change notifications, and configuration history. You can keep tabs on modifications to your AWS resources and track compliance with your policies using AWS Config.
Amazon CloudWatch is a monitoring service that offers metrics and logs for AWS applications and resources. Lambda functions, API Gateway, and other AWS services can all have logs and metrics collected and monitored by CloudWatch.
AWS GuardDuty is a threat detection service that employs machine learning to examine data from numerous sources, such as DNS logs, CloudTrail logs, and VPC flow logs. GuardDuty can be used to find numerous threats, such as botnets, compromised credentials, and reconnaissance.
By using these tools and services, you can monitor and analyze various system logs and metrics for your serverless application to detect any unexpected access, unusual patterns, or errors that could indicate a security threat or a system error. This helps you identify potential security risks and take proactive steps to remediate them before they become a bigger problem.
The key point is that security best practices don’t change with serverless. Make yourself aware of how you can take advantage of AWS managed services to reduce the security burden you have to manage. Think about security end to end at each integration point in your distributed architecture.