У меня будет несколько таблиц, используемых различными проектами на одном сервере mySql. Большая часть данных чувствительна и должна находиться за стенами разрешений. Однако многие таблицы конфиденциальных данных основаны на таблицах нечувствительных данных для информации о пользователе и отделе. Поэтому я вижу три варианта впереди меня, и я не уверен, кого выбрать.Управление просмотром кросс-базы данных, просмотром или разрешениями в MySql
Все в одной базе данных с разрешениями на уровне таблицы
Самый простой из всех решений, кроме того что я не контролирую разрешения на сервере базы данных, традиционно команда сервера только делает разрешения на уровне базы данных и получить их, чтобы его это политическая битва, в которой я, возможно, не могу повлиять на победу, и следить за всеми разрешениями было бы болью.
В нескольких базах данных, с разрешениями на уровне базы данных
можно разделить таблицы в зоне базы данных, поэтому отдел широко информация, как данные персонала, могут быть в своей собственной базе данных и инструментов, редактировать данные сотрудников может иметь ОБНОВЛЕНИЕ & INSERT доступ к базе данных отдела. Другие инструменты хотели бы получить доступ к частям списка персонала, в каталоге государственных служащих есть доступ SELECT к таблицам персонала, но парты таблиц персонала должны оставаться закрытыми, например, личные контактные данные, коды копирования или индексы выставления счетов. Мне нужно разбить таблицы сотрудников на общедоступные или приватные таблицы, но я снова застрял бы с разрешениями на уровне таблиц. Поэтому мне нужно было бы разбить базу данных отдела на разделенные отделом и частные базы данных отдела.
Перекрестные представления базы данных Я бы создал представления в базе данных, которая извлекает данные из других баз данных, к которым у учетной записи нет доступа. Поэтому я могу поместить всю информацию о сотрудниках в базу данных отдела, а затем создать представление в веб-базе данных, которое только вытаскивает столбцы, которые должны быть общедоступными (имя, отдел, расширение). Это позволило бы мне, фактически, иметь права SELECT на уровне столбцов без необходимости гашения с разрешениями. Меня беспокоит скорость. Исходная таблица, из которой извлекаются данные, будет полностью проиндексирована, но документация кажется противоречивой независимо от того, будут ли индексы индексироваться при запросе представления.
Кто-нибудь еще использовал любой из этих трех вариантов? У вас есть лучшие, о которых я не думал? Какие подводные камни вы видите за пределами того, что я указал на любой из вариантов?
Будут ли хранимые процедуры также пересекать барьер разрешений, что я могу настроить процедуры с высокой учетной записью, а затем просматривать данные с помощью низкой учетной записи? –
Да - одна из основных особенностей хранимых процедур заключается в том, что они позволяют лучше управлять привилегиями. Учетная запись, в которой хранимые процедуры определены ниже, будет лучше как локальная учетная запись - например, «sp_owner» @ «localhost» - чтобы уменьшить риск удаленного доступа пользователя к учетной записи, если они взломают пароль. Наиболее гибкая схема заключается в том, что ваши хранимые процедуры определяются как «create definer = current_user procedure ...», тогда решение о том, какая учетная запись определена ими, может быть отложена до момента загрузки. – Martin