Безопасная многопользовательская аренда в приложении MySQL

Question

У меня есть веб-служба JSP / MySQL , где пользователи взаимодействуют с «процессами» - они могут загружать данные, настраивать, просматривать отчеты и т. Д. Для данного процесса. Они также могут создавать новые процессы или запускать отчеты, сравнивающие несколько процессов.

В настоящее время идентификатор процесса указан в URL (параметр GET), поэтому любой пользователь может взаимодействовать с любым процессом. Меня попросили добавить безопасность и мультитенантность к этому сервису. Для простоты предположим, что каждый арендатор имеет полный доступ к набору процессов, но процессы могут быть доступны нескольким арендаторам.

Мой предпочтительный подход:

• Добавление пользовательской таблицы (PK_User_Id, password_hash, name и т. Д.)
• Добавить таблицу доступа (FK_User_Id, FK_Process_Id)
• Страница входа SSL, на которой хранится идентификатор Tenant_Id в сеансе
• Страница выбора процесса, которая позволяет вам выбрать Process_Id, к которому у вас есть доступ, и сохранить его в сеансе
• Почти каждая страница будет создавать свои SQL-запросы на основе идентификатора процесса сеанса
• «Кросс-процессные» страницы, такие как «Создать», «Выбрать» и «Сравнить», вместо этого будут использовать идентификатор пользователя сессии

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

Он хочет, чтобы я также использовал встроенные в ROLES ANSI SQL (приложение должно оставаться независимым от БД) для создания роли БД для каждого пользователя. Роль будет детализировать, к каким таблицам она имеет доступ, какие строки в общих таблицах и т. Д. Таким образом, при входе в систему Соединение будет «безопасным», и ошибка разработчика не может вызвать проблем.

• Возможно ли это?
• Есть ли такая вещь, как DB-независимые "роли", которые работают с MySQL?
• Могут ли роли указывать, что вам разрешено добавлять строки в таблицу, если первичным ключом является 'foo'?
• Достаточно ли безопасна моя система по отраслевым стандартам?

Answer 1

Вот что я делаю для мультитенанта MySQL с одной базой данных, чтобы обеспечить конфиденциальность данных:

1. Создание пользователя mysql для каждого арендатора
2. Добавление столбца tenant_id вкаждая таблица
3. Использование триггера для автоматического помещения текущего пользователя mysql в столбец tenant_id на INSERT
4. Создание представления для каждой таблицы, в котором отображаются только те строки, в которых tenant_id = mysql_user (не включая tenant_idстолбец в представлении)
5. Ограничить пользователя mysql арендатора доступом только к этим представлениям

Поскольку приложение использует пользователя mysql арендатора, нет никаких шансов, что они могут случайно получитьданные другого арендатора.

Мне удалось преобразовать большое однопользовательское приложение mysql в мультитенант за выходные с минимальными изменениями.Я задокументировал дизайн здесь: https://opensource.io/it/mysql-multi-tenant/

Answer 2

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

Answer 3

1. вместо этого используйте PostgreSQL, поскольку он поддерживает реальные схемы, в отличие от MySQL

2. , если вам нужно использовать MySQL, выполните следующие действия:

   • сделать одного пользователя mysql для каждого арендатора
   • добавить индексированный столбец к каждой таблице, tenant VARCHAR (16) NOT NULL
   • добавить триггер для каждой таблицы, который устанавливает владельца в mysqlимя пользователя подключения ВКЛЮЧЕНО ДО ВСТАВКИ
   • создайте представление для каждой таблицы, в котором задается WHERE tenant = имя пользователя подключения mysql.НЕ включайте столбец арендатора в список выбора.
   • предоставьте разрешение пользователю арендатора для представлений, но не для таблиц

И теперь пользователь может толькоувидеть собственную информацию арендатора.