Управление чтением, представлениями или разрешениями кросс-базы данных в MySql

У меня будет несколько таблиц, используемых разными проектами на одном сервере mySql. Большая часть данных является конфиденциальной и должна находиться за стеной разрешений. Однако многие таблицы конфиденциальных данных основаны на таблицах неконфиденциальных данных для информации о пользователях и отделах. Итак, я вижу перед собой три варианта и не знаю, какой из них выбрать.

Все в одной базе данных с разрешениями на уровне таблиц

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

В нескольких базах данных с разрешениями уровня базы данных

Я могу разделить таблицы на зоны базы данных, чтобы информация всего отдела, например данные о персонале, могла находиться в его собственной базе данных, а инструменты, которые редактируют данные о персонале, могут иметь доступ ОБНОВЛЕНИЯ и ВСТАВКИ к базе данных отдела. Другие инструменты хотели бы получить доступ к частям списка сотрудников, общедоступный каталог персонала имел бы доступ SELECT к таблицам персонала, но части таблиц персонала должны были бы оставаться закрытыми, например, личная контактная информация, коды копирования или индексы выставления счетов. Мне нужно было бы разделить таблицы сотрудников на общедоступные или частные таблицы, но я снова застрял бы с разрешениями на уровне таблицы. Поэтому мне нужно было бы разделить базу данных отдела на общую базу данных отдела и частную базу данных отдела.

Представления между базами данных Я бы создал представления в базе данных, которая извлекает данные из других баз данных, к которым у учетной записи нет доступа. Таким образом, я могу поместить всю информацию о персонале в базу данных отдела, а затем создать представление в веб-базе данных, которое извлекает только те столбцы, которые должны быть общедоступными (имя, отдел, добавочный номер). Это позволило бы мне, по сути, иметь права SELECT на уровне столбца без необходимости возиться с разрешениями. Меня беспокоит скорость. Исходная таблица, из которой извлекаются данные, будет полностью проиндексирована, но документация кажется противоречивой, будут ли индексироваться столбцы при запросе представления.

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


person Tyson of the Northwest    schedule 05.03.2010    source источник


Ответы (1)


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

person Martin    schedule 06.03.2010
comment
Преодолеют ли хранимые процедуры барьер разрешений, чтобы я мог настроить процедуры с высокой учетной записью, а затем просмотреть данные с низкой учетной записью? - person Tyson of the Northwest; 08.03.2010
comment
да - одна из основных особенностей хранимых процедур заключается в том, что они позволяют лучше управлять привилегиями. Учетная запись, под которой определены хранимые процедуры, лучше использовать в качестве локальной учетной записи, например, 'sp_owner'@'localhost', чтобы снизить риск получения удаленным пользователем мощного доступа под этой учетной записью в случае взлома пароля. Наиболее гибкая договоренность заключается в том, что если ваши хранимые процедуры определены как процедура create definer=current_user ..., то решение о том, под какой учетной записью они определены, может быть отложено до времени загрузки. - person Martin; 09.03.2010