Политика многоагентного IAM DynamoDB (обмен документами с другими пользователями)

Я пытаюсь создать приложение с несколькими арендаторами с DynamoDB и Cognito. В документации достаточно ясно, как реализовать мелкомасштабную авторизацию, чтобы пользователи могли получать доступ только к своим собственным записям, добавив условие к политике доступа IAM следующим образом:

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

Это отлично подходит для того, чтобы пользователи могли читать и записывать свои собственные записи, когда идентификатор пользователя Cognito является хеш-ключом строки, но Im борется с тем, как разрешить другим пользователям доступ только для чтения к некоторым записям.

Возьмем в качестве примера мою модель для ученика, который имеет несколько курсов:

{
    "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 преподавателя)

Если вышеприведенные условия политики применяются к роли пользователя IAM, пользователь может прочитать и записать этот документ, поскольку хеш-ключ (student_id) является идентификатором пользователя Cognito.

Идентификатор также напоминает, что преподаватели, перечисленные в документе, имеют доступ только для чтения к определенным атрибутам, но я не могу найти примеры того, как это можно сделать. Я знаю, что я не могу использовать dynamodb:LeadingKeys поскольку преподаватели не являются хэш-ключом таблицы. Можно ли это сделать, если я настрою глобальный вторичный индекс (GSI), который использует список преподавателей как хэш-ключ?

Если это можно сделать с помощью индекса, я предполагаю, что это позволит разрешить доступ только для чтения к этому индексу (поскольку параметр can not can write write). Есть ли какой-либо альтернативный способ разрешить доступ на запись на основе атрибута, который не является хеш-ключом?

В качестве альтернативы, я могу использовать более длинную строку в качестве хеш-ключа, объединяя атрибуты типа "owner": и "read-only": содержат списки идентификаторов Cognito и потребляют это в моей политике, чтобы создать только более мелкую грань, основанную только на моделях разрешений на хэш-ключ? Это предполагает, что политика может декодировать списки из строки, поскольку DynamoDB не позволяет хеш-ключу быть списком, объектом JSON или аналогичным.

Мне не удалось найти какие-либо ресурсы, которые рассматривают мелкомасштабный контроль доступа, не позволяя пользователям читать и записывать только свои собственные записи, поэтому, если кто-то может направить меня к кому-то, это будет отличным началом.

Ответы

Ответ 1

Вы можете легко ограничить доступ к определенным атрибутам (только атрибуты).

Однако для достижения более тонких шаблонов доступа вам необходимо:

  • задача управления доступом к разгрузке вашего кода (например, Lambda)
  • или вы могли бы оценить ваши шаблоны доступа (что обычно хорошо, однако это может быть немного сложнее) и моделировать ваши данные соответственно

Вообще говоря, при разработке приложений NoSQL вы всегда должны оценивать, как вы потребляете свои данные. Они, как правило, адаптируются для конкретного случая использования - в отличие от СУБД, которые допускают очень общие запросы независимо от них.

Там есть хороший пример моделирования реляционных данных в терминах DynamoDB, доступных здесь