Question

我正在尝试使用DynamoDB和Cognito创建一个多租户应用程序。文档非常清楚如何实现细粒度授权，以便用户只能通过向IAM访问策略添加条件来访问自己的记录，如下所示：

"Condition": {
                "ForAllValues:StringEquals": {
                    "dynamodb:LeadingKeys": [
                        "${cognito-identity.amazonaws.com:sub}"
                    ]
                 }
             }

这对于允许用户阅读和阅读非常有用。当Cognito用户id是该行的哈希键时，编写自己的记录，但我正在努力解决如何允许其他用户只读访问某些记录的问题。

以一个有多门课程的学生的模型为例：

{
    “student_id”: “ABC-1234567”,
    “course_name”: “Statistics 101”,
    “tutors”: [“Cognito-sub-1”, “Cognito-sub-2”],
    “seminar_reviews”: [ 
        {
            “seminar_id”: “XXXYYY-12345”
            “date”: “2018-01-12”,
            “score”: “8”,
            “comments”: “Nice class!”  
        },
        {
            “seminar_id”: “ABCDEF-98765”
            “date”: “2018-01-25”,
            “score”: “3”,
            “comments”: “Boring.”  
        }
    ]
}

（Cognito-sub-1是导师的Cognito id）

将上述政策条件应用于用户的IAM角色，用户可以阅读＆amp;写这个文档，因为哈希键（student_id）是用户的Cognito id。

我也希望文档中列出的教师对某些属性具有只读权限，但我找不到任何如何完成此操作的示例。我知道我不能使用dynamodb:LeadingKeys条件，因为教师不是表的哈希键。如果我设置使用导师列表作为哈希键的全局二级索引（GSI），是否可以这样做？

如果可以使用索引完成此操作，我认为这只允许对该索引的读访问（因为索引不允许写操作）。是否有任何替代方法允许基于非散列键的属性进行写访问？

或者，我可以使用更长的字符串作为哈希键，连接包含Cognito ID列表的”owner”:和”read-only”:等属性，并在我的策略中使用它来创建更细粒度的权限模型只基于哈希键？这假定策略可以解码字符串中的列表，因为DynamoDB不允许散列键是列表，JSON对象或类似的。

除了允许用户只读取/写入自己的记录之外，我还没有找到任何考虑细粒度访问控制的资源，所以如果有人能指导我，那将是一个很好的开始。

Answer 1

您可以restrict access to specific attributes轻松（只是属性）。

但是，为了实现更细粒度的访问模式，您必须：

将访问控制任务卸载到您的代码（例如Lambda）
或者您可以评估您的访问模式（这通常是一件好事，但是，它可能有点棘手）并相应地对您的数据建模

一般来说，在设计NoSQL应用程序时，您应该始终评估使用数据的方式。它们通常针对特定用例进行定制 - 与RDBMS不同，RDBMS允许非常一般的查询。

根据可用的DynamoDB建模关系数据有一个很好的例子here

DynamoDB多租户IAM策略（与其他用户共享文档）

1 个答案: