Runtime protection
Runtime protection involves safeguarding your Lambda functions while they are executing. This is crucial for preventing unauthorized activities, data leaks, and other security vulnerabilities during the function’s life cycle.
Filesystem
Lambda functions operate in a read-only filesystem. However, the /tmp directory is an exception and is writable. Its read-only nature serves as a security feature by reducing the attack surface. However, the writable /tmp directory comes with its own set of security considerations.
First, it is important to note that the /tmp directory is not encrypted and is shared across invocations in the same execution environment. Given this, sensitive data should never be stored in this directory. If your function requires sensitive files to be stored temporarily, consider using encrypted S3 buckets instead.
When writing temporary data, such as session tokens or files, exercise caution. Always validate the data before writing it to the filesystem and adhere to the principle of least privilege when setting file permissions. Use secure, random generators for any temporary tokens and set them to expire after a short period. If you must use temporary files, consider encrypting them before writing and ensure they are securely deleted, or even securely wiped, as soon as they are no longer needed.
In-memory data
Lambda functions can retain state in memory between invocations, a feature commonly referred to as warm starts. While this can offer performance benefits, it also introduces security risks, especially if sensitive data is stored in memory. To mitigate these risks, it is crucial to clear sensitive variables from memory as soon as they are no longer needed. This action minimizes the potential for memory leaks or unauthorized memory access. Moreover, avoid using global or static variables for storing sensitive information, as these can persist across multiple invocations.
Error handling
Errors can be a significant security risk if they are not handled correctly. For instance, revealing too much information in error messages can expose your system to attackers. Lambda functions should be designed to handle errors gracefully, logging the necessary information for debugging without exposing sensitive system details. DLQs can also be used to capture unprocessed events, which can then be analyzed for security implications.