Fine-grained access control in DynamoDB - Step-by-Step Execution

Concept Flow - Fine-grained access control

User Request

↓

Check User Identity

↓

Evaluate Access Policy

↓

Apply Filter/Condition

↓

Return Allowed Data Only

↓

Deny Unauthorized Access

When a user requests data, DynamoDB checks their identity, applies fine-grained policies, filters data accordingly, and returns only what the user is allowed to see.

Execution Sample

DynamoDB

SELECT * FROM Orders WHERE CustomerID = :userID
-- Access policy allows only orders of the requesting user

This query returns only the orders belonging to the user making the request, enforcing fine-grained access control.

Execution Table

Step	Action	Input	Policy Check	Result	Output
1	User sends request	Request for Orders table	N/A	N/A	Request received
2	Identify user	UserID = 123	N/A	User identified	UserID=123
3	Evaluate policy	Policy: access only own orders	UserID matches CustomerID?	Yes	Access granted for matching items
4	Apply filter	Orders data	Filter CustomerID = 123	Filtered data	Orders with CustomerID=123
5	Return data	Filtered orders	N/A	Data returned	Only user's orders sent
6	End	N/A	N/A	N/A	Request complete

💡 Execution stops after returning only the orders matching the user's ID, enforcing fine-grained access control.

Variable Tracker

Variable	Start	After Step 2	After Step 4	Final
UserID	N/A	123	123	123
Access Policy	Defined	Checked	Applied	Enforced
Data Returned	N/A	N/A	Filtered orders	Filtered orders

Key Moments - 2 Insights

Why does the system filter data after identifying the user?

Because the policy depends on the user's identity, filtering ensures only data allowed for that user is returned, as shown in execution_table step 4.

What happens if the user tries to access orders of another customer?

The policy check in step 3 fails, so no matching data passes the filter, resulting in no data returned, enforcing access control.

Visual Quiz - 3 Questions

Look at the execution table, what is the UserID after step 2?

A N/A

B 123

C 456

D Unknown

💡 Hint

Check the 'UserID' variable in variable_tracker after step 2.

At which step does the system apply the filter to return only allowed data?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look at the 'Apply filter' action in the execution_table.

If the policy allowed access to all orders, how would the output at step 4 change?

A All orders would be returned

B No orders would be returned

C Only user's orders would be returned

D An error would occur

💡 Hint

Consider the 'Apply filter' step and what happens if no filter is applied.

Concept Snapshot

Fine-grained access control in DynamoDB:
- Checks user identity on each request
- Applies policies to filter data per user
- Returns only authorized data
- Prevents unauthorized data access
- Uses conditions on attributes like CustomerID

Full Transcript

Fine-grained access control means DynamoDB checks who you are and only lets you see data you are allowed to see. When you ask for data, DynamoDB looks at your user ID, checks the rules, filters the data to only your items, and sends back just those. If you try to see someone else's data, it won't show it. This keeps data safe and private by controlling access at a detailed level.

Practice

1. What is the main purpose of fine-grained access control in DynamoDB?

easy

A. To automatically backup data

B. To speed up query performance

C. To restrict access to specific items based on keys

D. To encrypt data at rest

Solution

1. Step 1: Understand fine-grained access control concept

   Fine-grained access control limits access to individual items or attributes in a DynamoDB table.

2. Step 2: Identify the main purpose

   This control is used to restrict access based on keys, ensuring users see only their data.

3. Final Answer:

   To restrict access to specific items based on keys -> Option C

4. Quick Check:

   Fine-grained access control = restrict by keys [OK]

Hint: Focus on access control by keys, not performance or encryption [OK]

Common Mistakes:

• Confusing access control with encryption
• Thinking it improves query speed
• Assuming it manages backups

2. Which IAM policy condition key is used to enforce fine-grained access control in DynamoDB?

easy

A. dynamodb:LeadingKeys

B. dynamodb:TableName

C. dynamodb:Attributes

D. dynamodb:EncryptionEnabled

Solution

1. Step 1: Identify IAM condition keys for DynamoDB

   DynamoDB uses specific condition keys in IAM policies to control access.

2. Step 2: Match condition key for fine-grained access

   The key dynamodb:LeadingKeys restricts access based on partition key values.

3. Final Answer:

   dynamodb:LeadingKeys -> Option A

4. Quick Check:

   Fine-grained access uses dynamodb:LeadingKeys [OK]

Hint: Remember 'LeadingKeys' controls item-level access [OK]

Common Mistakes:

• Choosing TableName which controls table-level access
• Confusing Attributes with keys
• Selecting unrelated encryption keys

3. Given this IAM policy snippet, which items can the user access?

{
  "Effect": "Allow",
  "Action": "dynamodb:GetItem",
  "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Orders",
  "Condition": {
    "ForAllValues:StringEquals": {
      "dynamodb:LeadingKeys": ["user123"]
    }
  }
}

medium

A. All items in the Orders table

B. Only items with partition key 'user123'

C. Items with any partition key except 'user123'

D. No items, because the policy is invalid

Solution

1. Step 1: Analyze the IAM policy condition

   The condition restricts access to items where the partition key matches 'user123'.

2. Step 2: Determine accessible items

   Only items with partition key 'user123' are accessible; others are denied.

3. Final Answer:

   Only items with partition key 'user123' -> Option B

4. Quick Check:

   Condition limits to 'user123' keys [OK]

Hint: Check the LeadingKeys value to find accessible items [OK]

Common Mistakes:

• Assuming access to all items
• Thinking policy denies all access
• Ignoring the condition block

4. You wrote this IAM policy to restrict access to items with partition key 'user456', but users still access other items:

{
  "Effect": "Allow",
  "Action": "dynamodb:GetItem",
  "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Orders",
  "Condition": {
    "StringEquals": {
      "dynamodb:LeadingKeys": "user456"
    }
  }
}

What is the likely error?

medium

A. Action should be dynamodb:Query instead of GetItem

B. Resource ARN is incorrect

C. Effect should be Deny instead of Allow

D. Condition should use ForAllValues:StringEquals with an array

Solution

1. Step 1: Check condition syntax for dynamodb:LeadingKeys

   The condition expects an array with ForAllValues:StringEquals, not a single string with StringEquals.

2. Step 2: Understand impact of incorrect condition

   Using StringEquals with a string causes the condition to be ignored, allowing broader access.

3. Final Answer:

   Condition should use ForAllValues:StringEquals with an array -> Option D

4. Quick Check:

   Use ForAllValues:StringEquals and array for LeadingKeys [OK]

Hint: Use ForAllValues:StringEquals with array for LeadingKeys [OK]

Common Mistakes:

• Using StringEquals with a string instead of array
• Incorrect ARN format
• Confusing action types
• Changing Effect to Deny unnecessarily

5. You want to allow users to read only their own orders in a DynamoDB table where the partition key is 'UserId'. Which IAM policy condition correctly enforces this fine-grained access control for user 'alice'?

hard

A. { "ForAllValues:StringEquals": { "dynamodb:LeadingKeys": ["alice"] } }

B. { "StringEquals": { "dynamodb:Attributes": ["alice"] } }

C. { "ForAnyValue:StringEquals": { "dynamodb:LeadingKeys": ["alice"] } }

D. { "StringLike": { "dynamodb:LeadingKeys": "alice*" } }

Solution

1. Step 1: Identify correct condition operator for exact key match

   For fine-grained access, ForAllValues:StringEquals with an array ensures all keys match exactly.

2. Step 2: Evaluate options for correct syntax and semantics

   { "ForAllValues:StringEquals": { "dynamodb:LeadingKeys": ["alice"] } } uses correct operator and array format; others use wrong keys or operators.

3. Final Answer:

   { "ForAllValues:StringEquals": { "dynamodb:LeadingKeys": ["alice"] } } -> Option A

4. Quick Check:

   Exact key match needs ForAllValues:StringEquals with array [OK]

Hint: Use ForAllValues:StringEquals with array for exact user keys [OK]

Common Mistakes:

• Using dynamodb:Attributes instead of LeadingKeys
• Using StringEquals without array
• Using StringLike which allows wildcards