DynamoDB+Cognito多租户应用：跨用户细粒度权限控制实现问询

Great question—you’re already off to a solid start using dynamodb:LeadingKeys to lock down student access to their own records. Let’s break down each of your questions with practical solutions, plus share resources to expand your knowledge beyond basic owner-only access.

1. Can a Global Secondary Index (GSI) with tutors as the hash key enable read-only access for tutors? #

Short answer: Yes, but you’ll need to adjust your GSI design since DynamoDB GSI hash keys require scalar values (not lists like your tutors array). Here’s how to make this work:

• Refactor the GSI structure: Instead of using the tutors list directly as the hash key, create a GSI where each entry maps a single tutor’s Cognito sub to a student’s record. For example, add a tutor_sub attribute to each GSI entry (you can populate this by duplicating student records once per assigned tutor, or use a DynamoDB Stream to auto-populate the GSI).
• Project only necessary attributes: Configure the GSI to project only the attributes tutors need access to (e.g., course_name, seminar_reviews) to keep it efficient and minimize costs.
• Update your IAM policy: Allow tutors to Query the GSI with a condition that matches their Cognito sub to the GSI’s hash key, and restrict access to specific attributes using dynamodb:Attributes.

Example policy snippet for tutors:

{
  "Effect": "Allow",
  "Action": ["dynamodb:Query"],
  "Resource": ["arn:aws:dynamodb:REGION:ACCOUNT_ID:table/STUDENT_COURSES/index/TUTOR_INDEX"],
  "Condition": {
    "StringEquals": {
      "dynamodb:LeadingKeys": ["${cognito-identity.amazonaws.com:sub}"],
      "dynamodb:Attributes": ["course_name", "seminar_reviews"]
    }
  }
}

This lets tutors query the GSI to pull up all student records they’re assigned to, with read-only access to the specified attributes.

2. If indexes only enable read access, what other methods exist to grant write permissions based on non-hash key attributes? #

IAM’s native DynamoDB conditions are limited for write operations (like PutItem or UpdateItem) when working with non-hash key attributes—since IAM evaluates policies before DynamoDB processes the request, it can’t inspect existing item attributes to validate permissions. Here are your best options:

• Lambda Custom Authorizers: Use an API Gateway custom authorizer (or a Lambda function invoked before the DynamoDB request) to fetch the target student record, check if the requesting user is in the tutors list, and return an allow/deny decision. This gives you full control over write permissions based on any attribute.
• Data Model Refactoring: Split write-accessible data into a separate table where you can use hash key-based IAM conditions. For example, if tutors need to update seminar_reviews, create a SEMINAR_REVIEWS table with a composite hash key like student_id#tutor_sub. This lets you use dynamodb:LeadingKeys to restrict writes to tutors assigned to that student.
• DynamoDB Streams + Lambda (Post-Write Enforcement): While not ideal for proactive control, you can use a stream to monitor writes and roll back any changes made by unauthorized users. This is a fallback if other methods aren’t feasible.

3. Can I concatenate owner and read-only Cognito IDs into the hash key, then parse it in an IAM policy? #

Technically possible, but not recommended—this will complicate your data model, harm query efficiency, and create maintainability headaches:

• DynamoDB’s dynamodb:LeadingKeys condition requires exact matches, so users would need to know the full concatenated key (e.g., ABC-1234567#Cognito-sub-1#Cognito-sub-2) to query their records, which is impractical.
• Concatenated keys can lead to hot partitions if certain users/tutors are part of many records, hurting performance.
• IAM policies have limited string manipulation capabilities, so parsing the concatenated key to check for a user’s sub would require messy StringContains or Like conditions that are error-prone and less secure.

Stick with clean hash keys and use GSIs or custom authorizers instead—they’re more scalable and easier to maintain.

Additional Resources for Advanced Fine-Grained Access Control #

To go beyond basic owner-only access, check out these resources:

• AWS DynamoDB Fine-Grained Access Control Docs: Covers deep dives into dynamodb:Attributes, dynamodb:LeadingKeys, and GSI-specific permissions, with examples for multi-tenant scenarios.
• AWS Blog: Building Fine-Grained Access Control for Amazon DynamoDB: Walks through real-world use cases like shared access between users, including how to combine IAM with Cognito for complex permission models.
• IAM for DynamoDB Guide: Explains how to integrate Cognito Identity Pools with DynamoDB permissions, including best practices for least-privilege access.

内容的提问来源于stack exchange，提问作者Harry