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.

Resources

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.
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.
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.

Evaluate and define resource policies

Understand and determine what resource policies are necessary.

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.

Implement resource policies to prevent access unauthorized access.

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

Use dynamic authentication when accessing components and managed services.

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

Design smaller, single purpose functions

Create single purpose functions with their own IAM role.

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
- Examples
  - A large multipurpose function might need access to multiple AWS resources such as Amazon DynamoDB, Amazon S3, and Amazon SQS while single purpose invocations will not need access to all of them at the same time

Use least privilege access policies with your users and roles

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

Audit permissions used and remove unnecessary permissions where applicable.

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

Control network traffic at all layers

Use networking controls to enforce access patterns.

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

Use detective tools to audit your traffic.

The use of VPC Flow Logs can be used to audit traffic of your functions in order to see where their traffic is being sent to at a granular level.
VPC Flow Log record examples
Learn from your VPC Flow Logs

Block network access when required

Third-party tools enable you to disable outgoing internet traffic with exception to AWS services or allow-listed services.
Amazon Partner: PureSec FunctionShield