Support for Deeper Security and Data Privacy Measures – Introduction to Serverless on AWS
Support for Deeper Security and Data Privacy Measures
You now understand how the individuality and granularity of services in serverless enable you to fine-tune every part of an application for varying demands. The same characteristics allow you to apply protective measures at a deeper level as necessary across the ecosystem.
Permissions at a function level
Figure 1-11 shows a simple serverless application that allows you to store orders and query the status of a given order via the POST /orders and GET /orders/{id}/ status endpoints, respectively, which are handled by the corresponding Lambda functions. The function that queries the Orders table to find the status performs a read operation. Since this function does not change the data in the table, it requires just the dynamodb:Query privilege. This idea of providing the minimum permissions required to complete a task is known as the principle of least privilege.
The principle of least privilege is a security best practice that grants only the permissions required to perform a task. As shown in Example 1-1, you define this as an IAM policy by limiting the permitted actions on specific resources. It is one of the most fun‐ damental security principles in AWS and should be part of the security thinking of every engineer. You will learn more about this topic in Chapter 4.
Figure 1-11. Serverless application showing two functions with different access privileges to the same data table
Granular permissions at the record level
The IAM policy in Example 1-1 showed how you configure access to read (query) data from the Orders table. Table 1-1 contains sample data of a few orders, where an order is split into three parts for better access and privacy: SOURCE, STATUS, and ADJUSTED.
Table 1-1. Sample Orders table with multiple item types
Per the principle of least privilege, the Lambda function that queries the status of an order should only be allowed to access that order’s STATUS record. Table 1-2 highlights the records that should be accessible to the function.
Table 1-2. STATUS records accessible to the status query function
To achieve this, you can use an IAM policy with a dynamodb:LeadingKeys condition and the policy details listed in Example 1-2.
Example 1-2. Policy to restrict read access to a specific type of item
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “AllowOrderStatus”,
“Effect”: “Allow”,
“Action”: [
“dynamodb:GetItem”,
“dynamodb:Query”
],
“Resource”: [
“arn:aws:dynamodb:…:table/Orders”
],
“Condition”: {
“ForAllValues:StringEquals”: {
“dynamodb:LeadingKeys”: [
“STATUS”
]
}
}
}
]
}
The conditional policy shown here works at a record level. DynamoDB also supports attribute-level conditions to fetch the values from only the permitted attributes of a record, for applications that require even more granular access control.
Policies like this one are common in AWS and applicable to several common services you will use to build your applications. Awareness and understanding of where and when to use them will immensely benefit you as a serverless engineer.