Как может Субъект только читать и записывать в свои собственные объекты?

Похоже, что в RBAC субъект создает сессию с активной ролью(ями), которые затем используются для определения прав и действий, которые могут быть выполнены. Это, похоже, подходит большинству нашей организации, пока не дойдете до субъектов с ролью клиента. Клиенты должны иметь возможность читать только то, что они владеют, в отличие от других ролей, которые могут иметь права чтения/записи (или другие действия) на объекты одного и того же типа.

Я не уверен, как лучше всего реализовать это с использованием RBAC. Должна ли сессия также содержать субъект? Несколько ссылок предполагают, что нет.

Примечание: возможно, я слишком пуристичен, но я проверяю, что могу упустить. Я рассматривал вариант с PostgreSQL, где пользователь является ролью, а активная роль в сессии — это пользователь. Каковы мои варианты ограничения роли только для просмотра объектов не по типу, а по праву собственности?

Вы сталкиваетесь с ограничениями RBAC. В дополнение к учету возможностей, как предложил Авраам Мавридис, рассмотрите возможность использования контроля доступа на основе атрибутов (ABAC), который расширяет возможности RBAC, включая дополнительные атрибуты (метаданные), такие как атрибуты пользователя (местоположение, допускаемость, гражданство) и метаданные ресурсов (классификация, право собственности…).

XACML — это стандарт OASIS, реализующий ABAC. С помощью XACML вы можете легко написать правило о взаимосвязи, которое говорит:

• доступ к ресурсу разрешен только в том случае, если идентификатор запрашивающего равен идентификатору владельца.

Еще лучше, вы можете переписать правило в отрицательной форме, так как быть владельцем может быть недостаточно для доступа к ресурсу, но не будучи владельцем, достаточно для отказа в доступе:

• отказать в доступе к ресурсу, если идентификатор запрашивающего не равен идентификатору владельца.

Я думаю, это можно реализовать с использованием возможностей. Каждый субъект имеет набор пар (O, R), где O — это объект, а R — это права. Например, если Customer1 может читать file1, и читать и записывать file2, у вас может быть такой список возможностей:

Customer1={
  (file1, { read }),
  (file2, { read, write })
}

Если у многих клиентов есть одни и те же права, вы можете использовать группы, чтобы ограничить объем хранилища, используемого для сохранения этой информации.

Но затем вы должны быть уверены, что субъекты не могут модифицировать список возможностей.

Что вы можете сделать, так это определить контейнер определенного типа; назначить подмножество его объектов с правами, равными уровню доступа/разрешения субъекта. Звучит тривиально, но я знаю, что это работает. Это можно визуализировать в виде матрицы контроля доступа; другая роль при попытке доступа к объекту другого уровня доверия получит ошибку разрешения.

Смотрите это
https://www.owasp.org/images/d/d5/Acm.png

или лучше найдите матрицу контроля доступа OWASP в Google.

Для консистентности в системе RBAC все ресурсы должны содержать информацию о праве собственности. Объект состояния сессии обычно содержит информацию, используемую для обеспечения правил контроля доступа. Сессии создаются (или модифицируются) при аутентификации и деаутентификации. Правила, определяющие, кто имеет право аутентифицироваться и к каким ресурсам у них есть доступ, контролируются суперпользователем. Логично думать, что все сессии могут быть изменены только системой на основе намерений суперпользователя. Обычный пользователь никогда не должен иметь возможность изменять состояние сессии и изменять первичный ключ своей учетной записи пользователя.

Теперь давайте рассмотрим сценарий. Сотрудник в данный момент вошел в систему. Его увольняют руководство. Суперпользователь удаляет эту учетную запись, и его состояние сессии должно быть немедленно уничтожено, а его привилегии должны быть отозваны. Суперпользователь владеет объектом сессии и уничтожает его по запросу. Пользователь не контролирует, когда он вошел в систему; если бы это было так, он мог бы повредить другие данные, принадлежащие данной учетной записи пользователя.