ГЛАВНЫЙ поставщик облачной MySQL не предоставляет привилегию SUPER главному пользователю. Поставщик - Amazon RDS, но мой вопрос касается не конкретно Amazon RDS, а общего случая, когда владелец / администратор базы данных не имеет привилегий SUPER.
Отсутствие привилегии SUPER означает, что вы не можете использовать предложение DEFINER при создании хранимых процедур.
Это, в свою очередь, означает, что вы не можете заблокировать свои таблицы, чтобы они были недоступны для данного пользователя, в то же время предоставив этому же пользователю косвенный доступ через хранимую процедуру.
Есть ли альтернативный способ реализации той же стратегии безопасности «без прямого доступа к таблице» без SUPER?
Как первоначально было сказано, привилегия SUPER просто позволяет высокопривилегированному пользователю установить определитель в хранимых подпрограммах для пользователя, отличного от себя. Вы можете войти в систему как определяющий, чтобы создать хранимую процедуру, триггер или представление в другом контексте безопасности, но вам потребуется разрешить аутентификацию от имени этого пользователя, чтобы вы могли войти в систему при первом создании.
В Amazon RDS вы не можете заблокировать пользователя только на локальном хосте, поскольку у вас нет доступа оболочки к хосту. Таким образом, вы либо ограничиваете пользователя узлом или диапазоном, но вам придется сохранить это в своей программе, либо использовать узел с подстановочными знаками и подвергать пользователя потенциальной уязвимости безопасности.
Для MariaDB я нашел функция блокировки учетной записи. Хотя заблокированная учетная запись не может быть авторизована под учетной записью, она все равно может выполнять сохраненные процедуры. Таким образом, хост с подстановочными знаками может использоваться для предоставления доступа из любого места при входе в систему для создания подпрограммы (ов), а затем этот пользователь может быть заблокирован, позволяя ему выполнять сохраненные подпрограммы. только. Пользователь с высокими привилегиями, который выполняет блокировку, конечно, должен быть защищен иным образом.
Непоследовательность.
Вы не можете явно объявить DEFINER кроме вас самих, что, конечно, бессмысленно, так как вы уже определяете ... но вы все равно можете использовать SQL SECURITY DEFINER | INVOKER чтобы указать контекст безопасности, который процедура использует во время выполнения. Эта часть и ее аспекты безопасности ничем не отличаются от того, когда у вас есть SUPER привилегия. Единственное отличие состоит в том, что если вы хотите, чтобы определитель был конкретным (привилегированным) пользователем, чтобы процедура могла выполняться в контексте определителя от имени этого пользователя ... вы должны фактически войти в систему как DEFINER, чтобы объявить процедуру.