Security and Fine Grained Access Control (FGAC) in DynamoDB

1. Fine Grained Access Control (FGAC) gives a DynamoDB table owner a high degree of control over data in the table.

2. The table owner can indicate who (caller) can access which items or attributes of the table and perform what actions (read / write capability).

3. FGAC is used in concert with AWS IAM, which manages the security credentials and the associated permissions.

4. FGAC can benefit any application where the end user (or application client) wants to read or modify the table directly. For instance, a developer of a mobile app named Acme can use FGAC to track the top score of every Acme user in a DynamoDB table.

5. FGAC allows the application client to modify only the top score for the user that is currently running the application.

6. Can use Fine Grain Access Control with JSON documents.

7. Can use FGAC to restrict access to data based on top-level attributes in the document.

8. You cannot use FGAC to restrict access based on nested attributes. For example, you have a JSON document for a person with ID, name, and a list of all of their friends. You could use FGAC to restrict access based on their ID or name, but not based on list of friends.

9. With FGAC, an application requests a security token that authorizes the application to access only specific items in a specific DynamoDB table. With this token, the end user application agent can make requests to DynamoDB directly. Upon receiving request, DynamoDB uses IAM to authenticate request and determine the capabilities allowed for the user (incl. API-level permissions through IAM service integration).

10. There is no additional charge for using FGAC. You only pay for the provisioned throughput and storage associated with the DynamoDB table.

11. Amazon recommend that you use the DynamoDB Policy Generator from the DynamoDB console to create an appropriate policy. You may also compare your policy to those listed in the Amazon DynamoDB Developer Guide to make sure you are following a recommended pattern.

Example Scenarios

Example Scenario 1: Allow users to Query a LSI, but prevent them from causing a table fetch to retrieve non-projected attributes.

You can restrict potentially expensive “fetch” operations by limiting the permissions to only projected attributes, using the "dynamodb:Attributes" context key.

Example Scenario 2: prevent users from accessing specific attributes.

The recommended approach is to follow the principle of least privilege, and Allow access to only specific attributes.

Alternatively, you can use a Deny policy to specify attributes that are disallowed. However, this is not recommended for the following reasons:

• With a Deny policy, it is possible for the user to discover the hidden attribute names by issuing repeated requests for every possible attribute name, until the user is ultimately denied access.
• Deny policies are more fragile, since DynamoDB could introduce new API functionality in the future that might allow an access pattern that you had previously intended to block.

Example Scenario 3: prevent users from adding invalid data to a table

The available FGAC controls can determine which items changed or read, and which attributes can be changed or read. Users can add new items without those blocked attributes, and change any value of any attribute that is modifiable.

Example Scenario 4: Grant access to multiple attributes without listing all of them.

IAM policy language supports a rich set of comparison operations, including StringLike, StringNotLike, and many others. Use them for this.

Example Scenario 5: Grant access based on a canonical user id instead of separate ids for the user based on the identity provider they logged in with.

Not possible without running a “token vending machine”. If a user retrieves federated access to your IAM role directly using Facebook credentials with STS, those temporary credentials only have information about that user’s Facebook login, and not their Amazon login, or Google login. If you want to internally store a mapping of each of these logins to your own stable identifier, you can run a service that the user contacts to log in, and then call STS and provide them with credentials scoped to whatever partition key value you come up with as their canonical user id.

Example Scenario 6: Get history of all DynamoDB API calls to perform security analysis or operational troubleshooting on my DynamoDB tables.

Use AWS CloudTrail, a web service that records AWS API calls for your account and delivers log files.

Limitations

Certain information cannot currently be blocked from the caller about the items in the table:

1. Item collection metrics.

   1. Caller can ask for the estimated number of items and size in bytes of the item collection.

2. Consumed throughput

   1. Caller can ask for the detailed breakdown or summary of the provisioned throughput consumed by operations.

3. Validation cases.

   1. In certain cases, caller can learn about the existence and primary key schema of a table when you did not intend to give them access. To prevent this, follow the principle of least privilege and only allow access to tables and actions that you intended to allow access to.

4. If you deny access to specific attributes instead of whitelisting access to specific attributes, the caller can theoretically determine the names of the hidden attributes if “allow all except for” logic.

   1. It is safer to whitelist specific attribute names instead.

Alternatives

To achieve same level of control without FGAC, a developer would have to choose from a few potentially onerous approaches. Some of these are:

1. Proxy: The application client sends a request to a brokering proxy that performs the authentication and authorization. Increases the complexity and total cost of ownership (TCO).

2. Per Client Table: Every application client is assigned its own table. Could potentially require a to create many tables, thereby making database management extremely painful.

3. Per-Client Embedded Token: A secret token is embedded in the application client. Difficult changing the token and handling its impact on the stored data.