Как реализовать безопасность на уровне строк для мультитенантного приложения SAAS

Изучив различные варианты создания архитектуры мультитенантной базы данных, я решил использовать 'Одна база данных и одни и те же таблицы для всех клиентов, но у нас есть tenant_id во всех таблицах, поэтому мы запрашиваем данные в соответствии с конкретным клиентом ' подход за счет простоты масштабирования и обслуживания / обновления.

Общий подход, кажется, состоит в том, чтобы просто включать WHERE tenant_id = $ID для каждого запроса, однако я узнал, что вы можете дополнительно изолировать данные и избавиться от необходимости включать предложение WHERE, реализовав безопасность на уровне строк.

Однако руководства, которые я нашел, о том, как это сделать, не очень ясны. Кажется, что все они реализуют безопасность на уровне строк на основе вошедшего в систему пользователя базы данных, что не будет работать в моем случае, поскольку у меня есть только один пользователь базы данных.

По сути, когда пользователь отправляет запрос API на наш сервер, он будет включать веб-токен JSON, который включает идентификатор в полезную нагрузку. Затем сервер запрашивает базу данных пользователей для этого идентификатора, чтобы получить orgId пользователя (также известный как tenant_id), а затем, когда сервер запрашивает базу данных в соответствии с запросом API, он установит $ID в WHERE orgId = $ID на это возвращенное значение orgId.

Как мне реализовать безопасность на уровне строк в этом сценарии?

Я искал другие темы и не считаю, что это повторяющийся вопрос.


person Jake    schedule 17.04.2019    source источник
comment
Привет, Джейк, в настоящее время я тоже использую подход tenant_id для аренды. Удалось ли вам реализовать «строковую безопасность»?   -  person kyw    schedule 27.05.2020


Ответы (1)


Обычно с такой настройкой нельзя использовать защиту на уровне строк.

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

Как прокомментировал a_horse_with_no_name, обходным путем может быть установка параметров конфигурации, таких как application_name, из вашего приложения и безопасности базового уровня строки для этого параметра.

person Laurenz Albe    schedule 17.04.2019
comment
Разве вы не можете определить политику RLS, которая использует значение параметра конфигурации? Конечно, приложение должно будет убедиться, что свойство инициализировано должным образом при установке соединения. - person a_horse_with_no_name; 17.04.2019
comment
Вы правы, это можно сделать. Напишите это в ответе, и я проголосую за. Исправлю свой ответ с замечанием. - person Laurenz Albe; 17.04.2019