SEC 2: How do you manage your Serverless application’s security boundaries?
Defining and securing your Serverless application’s boundaries ensures isolation for, within, and between components.
Evaluate and define resource policies: Resource policies can restrict inbound access to managed services. Consider using resource policies to restrict access to your component based on the source IP address/range, geolocation, function event source, version, alias, queues, etc.
Use temporary credentials between resources and components: Credentials and permissions policies should not be shared between any resources in order to maintain a granular segregation of permissions.
Control network traffic at all layers: Apply controls for controlling both ingress and egress traffic, including data loss prevention. Functions deployed to virtual private networks must consider network access restrict resource access.
Design smaller, single purpose functions: Grant automated or programmatic access to users or roles with only the minimum privileges needed in order to reduce the risk of unauthorized access. Creating smaller, single purpose functions enables you to keep your permissions aligned to least privileged access, and reduces the risk of compromise since the function will do less.
Evaluate and define resource policies
- Resource policies delineate who has fine-grained access to the resource and what actions they can perform on it. They are evaluated and enforced at AWS IAM level before each AWS service’s own authorization mechanisms are applied, when available.
- Certain resource policies can also be applied at the AWS Organization level, thus providing guardrail for what actions AWS Accounts within the organization root or organizational unit can do.
- Review your existing policies and how they’re configured, paying close attention to how permissive individual policies are. Your resource policies should only permit necessary callers.
- For AWS Lambda, use resource-based policies to provide fine-grained access to layers, and what AWS IAM identities and event sources that can invoke your function using a specific version or alias.
- You can combine resource policies with AWS Lambda event sources, for example, if being invoked by Amazon API Gateway, you can restrict the policy down to the Amazon API Gateway ID, HTTP method, and path of the request.
- For Amazon API Gateway, use resource-based policies to restrict API access to specific Amazon Virtual Private Cloud (VPC), VPC endpoint, source IP address/range, AWS Account or AWS IAM users.
- For Amazon SQS, use resource-based policies to provide fine-grained access to queues to certain AWS services and AWS IAM identities (users, roles, accounts).
- For Amazon SNS, use resource-based policies to restrict authenticated and non-authenticated actions to topics.
- For Amazon DynamoDB, use resource-based policies to provide fine-grained access to tables and indexes.
- For EventBridge, use resource-based policies to restrict AWS identities to send and
receive events including to specific event buses.
AWS Lambda Resource-based Policies
Amazon API Gateway Resource-based Policies
Amazon SQS Resource-based Policies
Amazon SNS Resource-based Policies
Amazon DynamoDB Resource-based Policies
EventBridge Resource-based Policies
Amazon S3 Bucket Policy examples
Use temporary credentials between resources and components
- Serverless frameworks ensure that AWS resources are provisioned with AWS IAM roles unique per function.
- AWS SAM automatically creates unique IAM roles for every AWS Lambda function you create. AWS Lambda assumes IAM roles, exposes, and rotates temporary credentials to your functions, enabling your
application code to access AWS services without hard-coding credentials.
AWS SAM Policy templates
Control network traffic at all layers
- Ingress traffic to AWS Lambda functions isn’t permitted by default. For egress, you can use security groups to permit your AWS Lambda function to communicate with other AWS resources; for example, an AWS Lambda function connecting to an Amazon ElastiCache cluster.
- Routing tables can be used to configure routing to different networking appliances
to filter or block access to certain locations, if necessary. Network ACLs can be used to block access to CIDR IP ranges or ports.
Working with Network ACLs in Amazon VPC
- Third-party tools enable you to disable outgoing internet traffic with exception to
AWS services or allow-listed services.
Amazon Partner: PureSec FunctionShield
Design smaller, single purpose functions
- Create single purpose AWS Lambda functions to better allow for the creation of AWS IAM roles that are specific to your access requirements.
Using an AWS IAM Role to Grant Permissions to Applications
- Create AWS IAM policies with the least possible number of privileges granted to a user or role.
In the unlikely event of misused credentials, credentials will only be able to perform limited interactions.
AWS IAM Best Practices: Least Privilege Principle
Amazon Partner Blog: Least Privilege Principle
- With AWS IAM, use AWS IAM Access Advisor to review when was the last time an AWS service was used from a specific IAM user or role. Using this information, you’re able to remove IAM policies and access from your IAM roles.
- With AWS CloudTrail, use AWS CloudTrail Event History to review individual actions your AWS IAM Role has performed in the past. Using this information, you can detect which permissions
were actively used and decide to further remove permissions.
AWS IAM Access Advisor
Automate analyzing permissions using AWS IAM Access Advisor
Viewing Events with AWS CloudTrail Event History