Secure Lambda functions and meet cloud compliance standards

Start with the AWS shared responsibility model

AWS' shared responsibility model is one of the first compliance aspects to consider. While AWS has multiple internal security protections in place, much of the responsibility to maintain a secure environment falls on application owners.

For instance, Lambda supports a number of compliance programs, including Service Organization Control, Payment Card Industry Data Security Standard, the Federal Risk and Authorization Management Program and HIPAA.

These certifications apply to AWS technology and internal processes and don't necessarily mean that your organization's applications are compliant, too. If an organization is subject to certain compliance programs, its cloud users must ensure that their own internal processes, as well as development and operational practices, comply with these standards.

Once you know what you're responsible for, review how your organization develops and operates software, as well as its internal processes. Follow these cloud compliance strategies in Lambda to ensure your organization is holding up its end of the bargain.

Assign Lambda permissions with AWS Identity and Access Management

Developers should carefully consider who can call a specific Lambda function. To address this, organizations can configure permissions with AWS identity and access management (IAM) and incorporate resource-based policies.

Manage IAM users and roles in your organization to grant only the necessary permissions. And configure resource-based policies from the perspective of a specific Lambda function, which further restricts who can invoke a particular function.

Developers should also be diligent when it comes to which operations the Lambda function has permission to execute. Use the Lambda execution IAM role to specify the AWS APIs a function can call, along with the AWS resources it can access. For example, you can block a Lambda function from or inserting records in a particular DynamoDB table or accessing a given S3 bucket.

Monitor function activity for visibility

Maintain strict controls on your Lambda functions. Know who executes functions and when. Visibility is an essential part of many compliance standards. Use these features to monitor and audit the activity in your Lambda functions:

CloudWatch metrics. Lambda functions can publish system metrics to CloudWatch, such as execution times, errors, number of invocations and concurrent executions. This information will tell your team when a particular function was executed and provide relevant data to troubleshoot potential issues.

CloudWatch filters. Metric filters identify text patterns in your function's logs and convert them into system performance data, while subscription filters export log data to Amazon cloud services such as S3 and Elasticsearch Service for further analysis.

AWS Config. This tracks configuration changes applied to AWS resources and compares them against configuration rules that you specify. For example, you can configure a rule that identifies when to grant public access to a Lambda function. With AWS Config, you can keep a record of configuration updates and received notifications if a rule is breached.

AWS CloudTrail. This records AWS API calls made from your account, such as API calls used to create, update and invoke Lambda functions. Use AWS CloudTrail to audit which entities have triggered Lambda functions in your account and which AWS APIs your Lambda functions have called.

VPC Flow Logs. Configure AWS Lambda functions to access resources deployed in an Amazon Virtual Private Cloud (VPC). This option is recommended when a particular deployment needs to be isolated from public network access. Use VPC Flow Logs to analyze traffic inside the VPC and to store it permanently in S3 for auditing and compliance purposes.

Encrypt data managed by Lambda functions

If you use Lambda with an AWS SDK, then your functions are transparently invoked with Secure Sockets Layer and Transport Layer Security encryption. However, the data that a function stores and manages is not encrypted by default. Here are some steps you can take to ensure deeper encryption:

Secure environment variables. Lambda supports the configuration of environment variables, which functions can access at runtime. Some of these variables might contain sensitive data, such as private keys or tokens. Encrypt these sensitive values with the AWS Key Management Service (KMS) so they are only visible to a specific function.

Store configuration values separately. In many cases, functions need to access configuration values, such as database endpoints or passwords, which vary according to environments or deployment stages. You should store these values outside the function. A good place to do this is in the AWS Systems Manager Parameter Store. Lambda functions can also be used to later decrypt values with KMS.

Encrypt storage. If you need to store data, your Lambda functions can use services such as DynamoDB, S3 or Relational Database Service -- all of which natively support encryption at rest and can be managed by KMS.

Limit logs. Lambda function logs are automatically stored in CloudWatch Logs, which supports encryption at rest with KMS. Don't log sensitive information.

Set up an AWS Web Application Firewall

If you invoke Lambda functions through a built-in AWS integration, such as Application Load Balancer or API Gateway, you can add further protection by configuring the AWS Web Application Firewall (WAF).

With AWS WAF, you can create rules that block potentially malicious requests from reaching Lambda functions. You can base these rules on IP, call rates, geolocation or patterns in HTTP headers and query strings. You can also create corresponding CloudWatch alarms to send your team notifications when a rule blocks a request.