Разграничение прав пользователей БД
С точки зрения работы с базами данных, проблема становится актуальной в нескольких случаях. Первый очевиден: как только работать с информацией начинает больше, чем один человек. Второй обычно связан с желанием закрыть информацию от посторонних глаз. Сравнительно новым можно считать защиту персональных данных, определяемую законодательством.
Важность темы определяется тем, что она должна предусматриваться и разрабатываться уже на первом этапе построения БД.
Сразу договоримся, что, как и любой вопрос, связанный с защитой, разграничение прав доступа не может иметь однозначно идеального решения. А речь идет именно о защите, пускай в первую очередь от непреднамеренной порчи информации.
Некоторый парадокс состоит в том, что любые права в итоге будут реализовываться программно.
Администрирование прав (тоже, кстати, право) должно осуществляться удобно и является естественной функцией крупной системы.
Важно, чтобы....
Доступ к этим материалам предоставляется только зарегистрированным пользователям!
Значительная часть СУБД не имеет встроенных возможностей шифрования и/или парольной защиты данных, что обусловливает их потенциальную кражу в файл-серверной и локальной версии хранения. Кража может иметь смысл не только в качестве источника получения информации, но и для изучения ее построения. В последующем возможно несанкционированное изменение.
Доступ к этим материалам предоставляется только зарегистрированным пользователям!
В ряде случаев подобную таблицу можно связать или основывать на уже имеющемся перечне людей (кадры, бухгалтерия, клиенты). Здесь для этой цели введено поле user_main_id.
Таблица прав
| Наименование | Поле | Примечание | Комментарий |
| user_id | I(1-4) | Код | |
| r1 | L(1) | Право 1 (есть или нет) | |
| r2 | L(1) | Право 2... | |
| ... | L(1) |
Для предотвращения редактирования прав из внешней программы можно ввести дополнительное поле, сохраняющее в зашифрованном виде контрольную сумму всех полей, а проверку производить при каждом обращении к праву. Это отнимет минимум ресурсов при максимальной безопасности.
Нарушение правил нормализации неочевидно, так как поля всегда хранят информацию (истину или ложь).
Естественно, что разобраться с большим списком прав будет сложно даже для разработчика.
Поэтому организуем сервисную таблицу-справочник, которая может и не хранится с остальными файлами, а находиться в его системной папке.
Таблица пояснений к правам
| Наименование | Поле | Примечание | Комментарий |
| r_id | I(2) | Код права | Поиск путем вычленения номера из имени поля таблицы прав |
| r_name | C(40) | Наименование | |
| r_descr | M(10) | Описание | Поле ценно тем, что может содержать как пояснения, так и задумки для последующей реализации. Все равно оно никому недоступно |
Некоторые примеры разграничения прав
- Доступ на просмотр за счет блокирования пунктов меню и перехода к формам или отчетам
- Редактирование прекрасно реализуется за счет введения в формы специальной кнопки.
Доступ к этим материалам предоставляется только зарегистрированным пользователям!
Пункты 1–3 уже создают несколько десятков, а то и сотен прав. В принципе понятно, что в обычную таблицу БД такой объем вставить нельзя. Но не сразу становится очевидным решение.
Таблица
| Наименование | Поле | Примечание | Комментарий |
| user_id | I(1-4) | Код пользователя | Размер поля может изменяться в достаточно широком диапазоне в зависимости от назначения БД |
| r_id | I(2) | Код права |
Если в таблице будет найдено право с соответствующим номером, то оно у пользователя есть. В предыдущем примере 100 прав займут 100 байт, а здесь (по максимуму) — 600 байт (6*100 записей), но обычно большинству предоставляется существенно меньше прав и объем хранения будет примерно одинаков. При расширении списка в соответствии со сказанным выше, выгода от такой технологии станет существенной как по объему, так и по скорости и удобству.
Кроме того, мы можем добавить еще одно поле, означающее уровень права и сделать систему гораздо более сложной и гибкой. В предыдущем примере надо было бы делать поле права не логическим, а числовым.
Copyright © 1993–2023 Мацкявичюс Д.А. Все права защищены.
Никакая часть сайта не может быть воспроизведена никаким способом без письменного разрешения правообладателя и явной ссылки на данный ресурс.
