Fine-grained access control in DynamoDB - Mini Project: Build & Apply

Fine-grained Access Control with DynamoDB

📖 Scenario: You are building a simple employee database for a company. Each employee record contains sensitive information like salary and department. You want to control who can see the salary based on their role.

🎯 Goal: Create a DynamoDB table with employee data, add a role-based access control configuration, write a query that only returns salary if the user role is 'manager', and finalize the policy to enforce this fine-grained access control.

📋 What You'll Learn

Create a DynamoDB table called Employees with EmployeeID as the primary key and attributes Name, Department, and Salary.

Add a variable called user_role to represent the current user's role.

Write a query that retrieves EmployeeID, Name, and Department for all employees, and includes Salary only if user_role is 'manager'.

Add a condition expression or policy statement that enforces this fine-grained access control.

💡 Why This Matters

🌍 Real World

Companies often need to protect sensitive employee data and allow only authorized roles to see certain information like salaries.

💼 Career

Understanding fine-grained access control is essential for database administrators and backend developers to secure data properly.

1

Create the Employees table with sample data

Create a DynamoDB table called Employees with EmployeeID as the primary key. Add three items with these exact values: {'EmployeeID': 'E001', 'Name': 'Alice', 'Department': 'HR', 'Salary': 70000}, {'EmployeeID': 'E002', 'Name': 'Bob', 'Department': 'IT', 'Salary': 85000}, and {'EmployeeID': 'E003', 'Name': 'Charlie', 'Department': 'Finance', 'Salary': 90000}.

DynamoDB

# Create the Employees table and add the three items
# Your code here

Hint

Use a list of dictionaries to represent the table and its items.

2

Add user role variable

Add a variable called user_role and set it to the string 'employee' to represent the current user's role.

DynamoDB

Employees = [
    {'EmployeeID': 'E001', 'Name': 'Alice', 'Department': 'HR', 'Salary': 70000},
    {'EmployeeID': 'E002', 'Name': 'Bob', 'Department': 'IT', 'Salary': 85000},
    {'EmployeeID': 'E003', 'Name': 'Charlie', 'Department': 'Finance', 'Salary': 90000}
]
# Add the user_role variable below
# Your code here

Hint

Just create a string variable named user_role with the value 'employee'.

3

Write query with conditional salary access

Write a list comprehension called visible_data that goes through each employee in Employees and creates a new dictionary with keys 'EmployeeID', 'Name', and 'Department'. Add the 'Salary' key only if user_role is 'manager'.

DynamoDB

Employees = [
    {'EmployeeID': 'E001', 'Name': 'Alice', 'Department': 'HR', 'Salary': 70000},
    {'EmployeeID': 'E002', 'Name': 'Bob', 'Department': 'IT', 'Salary': 85000},
    {'EmployeeID': 'E003', 'Name': 'Charlie', 'Department': 'Finance', 'Salary': 90000}
]
user_role = 'employee'
# Create visible_data list comprehension below
# Your code here

Hint

Use a dictionary unpacking inside a list comprehension with a condition on user_role.

4

Add fine-grained access control policy

Add a variable called access_policy that is a dictionary with a key Condition. Set Condition to a dictionary with key StringEquals mapping to another dictionary with key user:role and value 'manager'. This simulates a policy that allows salary access only if the user role is 'manager'.

DynamoDB

Employees = [
    {'EmployeeID': 'E001', 'Name': 'Alice', 'Department': 'HR', 'Salary': 70000},
    {'EmployeeID': 'E002', 'Name': 'Bob', 'Department': 'IT', 'Salary': 85000},
    {'EmployeeID': 'E003', 'Name': 'Charlie', 'Department': 'Finance', 'Salary': 90000}
]
user_role = 'employee'
visible_data = [
    {**{k: employee[k] for k in ('EmployeeID', 'Name', 'Department')}, **({'Salary': employee['Salary']} if user_role == 'manager' else {})}
    for employee in Employees
]
# Add access_policy dictionary below
# Your code here

Hint

Use nested dictionaries to represent the policy condition.

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