Как правильно реализовать безопасность доступа к данным на MySQL?

Question

[inheaven]

Привет!


Есть несколько табличек с важными записями. Есть пользователи, группы и подразделения. Нужно организовать механизм безопасности доступа к данным. Чтобы пользователи могли читать и редактировать только свои записи, своей группы или своего подразделения. Что-то наподобие безопасности на файловой системе. Сложность в том, что один объект — запись в табличке может быть назначена для нескольких пользователей, групп или подразделений.


Например делать ли отдельную таблицу с правами, или добавить колонку. Вот только не понятно что туда писать, как правильно закодировать значение прав, чтобы потом можно было быстро делать выборки. Какие бывают подходы, как правильно реализовывать, что почитать?


Язык Java, база MySQL.

Comments

[inheaven]

Я вижу это примерно так.

Создается таблица ключей безопасности, которые раздаются пользователям и группам:

security_key
_________________
security_key1, user1
security_key1, user2
security_key2, group1
security_key3, group2

и потом ко всем требуемым таблицам добавляется поле:

record
__________________
record1, security_key1
record2, security_key1
record3, security_key2
record4, security_key3

и соответственно если нужно сделать выборку по всем записям для user1, я ищу все ключи которыми он может пользоваться и уже по ним делаю фильтрацию.

Тут сложности в создании, изменении, удалении, объединении ключей. На сколько такой подход корректен?

Answer 1

[pwlnw]

Если групп немного без тенденций к росту, можете изобразить ограничивающие VIEW и раздать доступ пользователям туда.

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

Третий способ -«трехзвенка». дополнительная серверная программа, с которой общаются клиентские приложения. Она делает все проверки на удобном вам языке.

Comments

[inheaven]

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

[pwlnw]

Как знаете. Есть опасность, что вы вместо предметной области увлечетесь унификацией.

Answer 2

[pwlnw]

Если групп немного без тенденций к росту, можете изобразить ограничивающие VIEW и раздать доступ пользователям туда.

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

Третий способ -«трехзвенка». дополнительная серверная программа, с которой общаются клиентские приложения. Она делает все проверки на удобном вам языке.

Answer 3

[pentarh]

В MySQL вам это сделать не удастся. Без гранта на SELECT, CALL не выполняется. Вообще там привилегии через жопу сделаны. Пример. Делаем 1 таблицу и одну процедуру с селектом из этой таблицы. Юзеру даем грант ТОЛЬКО на выполнение процедуры. Результат: процедура не выполняется, т.к. нет гранта на SELECT внутри процедуры. Полный бред…

mysql> create database t;
Query OK, 1 row affected (0.00 sec)

mysql> use t
Database changed
mysql> CREATE TABLE `testtable` (
-> `id` int(11) NOT NULL,
-> `name` varchar(255) NOT NULL
-> ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
Query OK, 0 rows affected (0.06 sec)

mysql> DELIMITER $$
mysql> CREATE
-> PROCEDURE testproc ()
-> SQL SECURITY INVOKER
-> BEGIN
-> SELECT * FROM testtable;
-> END$$
Query OK, 0 rows affected (0.00 sec)

mysql> grant usage on t.* to testuser@localhost identified by 'qwe';
Query OK, 0 rows affected (0.01 sec)
mysql> grant execute on procedure t.testproc to testuser@localhost;
Query OK, 0 rows affected (0.01 sec)
mysql> exit
Bye

# mysql -u testuser -p
mysql> use t
Database changed
mysql> select * from testtable;
ERROR 1142 (42000): SELECT command denied to user 'testuser'@'localhost' for table 'testtable'
mysql> call testproc();
ERROR 1142 (42000): SELECT command denied to user 'testuser'@'localhost' for table 'testtable'

Comments

[pwlnw]

>SQL SECURITY INVOKER
Можно узнать, вы эти буквы осознанно написали?

[pentarh]

Ага. Не вижу никакого смысла в DEFINER. Это какое то sudo получается. От кого процедуру определять? От рута? Нет. Держать еще одного юзера@хост специально для этой процедуры? Чего это за новости… я как то definer'a грохнул за неактуальностью, все его процедуры и нагнулись раком у других юзеров.

[pwlnw]

Но ведь DEFINER и служит именно для описанной ситуации.
Поэтому не стоит вводить в заблуждение. В Mysql это сделать удастся.