Разграничение прав пользователей БД

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

Важность темы определяется тем, что она должна предусматриваться и разрабатываться уже на первом этапе построения БД.

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

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

Администрирование прав (тоже, кстати, право) должно осуществляться удобно и является естественной функцией крупной системы.

Важно, чтобы

Гибкость
просмотр, редактирование (в т.ч. удаление и добавление), 
	Право добавления записей обязано рассматриваться как важнейшее. В качестве примера возьмем названия компаний.
		Нерадивый (или просто плохо обученный) оператор совершенно элементарно может ввести несколько "одинаковых" названий, различающихся единичными символами.
		Решить проблему программно невозможно
Фиксация действий
Контрольный код
Шифрование паролей (обратимое и необратимое)
Шифрование данных

Значительная часть СУБД не имеет встроенных возможностей шифрования и/или парольной защиты данных, что обусловливает их потенциальную кражу в файл-серверной и локальной версии хранения. Кража может иметь смысл не только в качестве источника получения информации, но и для изучения ее построения. В последующем возможно несанкционированное изменение.

Таблица пользователей
НаименованиеПоле  ПримечаниеКомментарий
user_idI(1-4)Код пользователяРазмер поля может изменяться в достаточно широком диапазоне в зависимости от назначения БД
user_nameC(??)Имя пользователя
passwordI/CПарольИмеет смысл только хранение в необратимо зашифрованном виде
pos_idI(4)Должность
user_main_idI(1-4)Код пользователя в главной таблице людей

В ряде случаев подобную таблицу можно связать или основывать на уже имеющемся перечне людей (кадры, бухгалтерия, клиенты). Здесь для этой цели введено поле user_main_id.

Таблица прав
НаименованиеПоле  ПримечаниеКомментарий
user_idI(1-4)Код
r1L(1)Право 1 (есть или нет)
r2L(1)Право 2...
...L(1)

Для предотвращения редактирования прав из внешней программы можно ввести дополнительное поле, сохраняющее в зашифрованном виде контрольную сумму всех полей, а проверку производить при каждом обращении к праву. Это отнимет минимум ресурсов при максимальной безопасности.

Нарушение правил нормализации неочевидно, так как поля всегда хранят информацию (истину или ложь).

Естественно, что разобраться с большим списком прав будет сложно даже для разработчика. Поэтому организуем сервисную таблицу-справочник, которая может и не хранится с остальными файлами, а находиться в его системной папке.
Таблица пояснений к правам
НаименованиеПоле  ПримечаниеКомментарий
r_idI(2)Код праваПоиск путем вычленения номера из имени поля таблицы прав
r_nameC(40)Наименование
r_descrM(10)ОписаниеПоле ценно тем, что может содержать как пояснения, так и задумки для последующей реализации. Все равно оно никому недоступно

Некоторые примеры разграничения прав

  1. Доступ на просмотр за счет блокирования пунктов меню и перехода к формам или отчетам
  2. Редактирование прекрасно реализуется за счет введения в формы специальной кнопки. Это – хороший стиль, предохраняющий от непреднамеренной порчи данных. Кроме того, можно запретить редактирование
  3. Добавление и/или удаление записей. Не надо забывать, что стирание содержимого полей может оказаться не менее болезненным.
  4. Распечатка отчетов может оказаться как способом хищения информации, так и значительной составной частью расходов за счет тонера и бумаги.
  5. Совершение электронных проводок.
  6. Исправление "чужих" записей или транзакций.
  7. Смена пароля. Можно дополнить обязанностью сменить пароль.
  8. Администрирование прав, редактирование напрямую (специальный интерфейс), суперадминистратор.

Пункты 1–3 уже создают несколько десятков, а то и сотен прав. В принципе понятно, что в обычную таблицу БД такой объем вставить нельзя. Но не сразу становится очевидным решение.

Таблица
НаименованиеПоле  ПримечаниеКомментарий
user_idI(1-4)Код пользователяРазмер поля может изменяться в достаточно широком диапазоне в зависимости от назначения БД
r_idI(2)Код права

Если в таблице будет найдено право с соответствующим номером, то оно у пользователя есть. В предыдущем примере 100 прав займут 100 байт, а здесь (по максимуму) – 600 байт (6*100 записей), но обычно большинству предоставляется существенно меньше прав и объем хранения будет примерно одинаков. При расширении списка в соответствии со сказанным выше, выгода от такой технологии станет существенной как по объему, так и по скорости и удобству.

Кроме того, мы можем добавить еще одно поле, означающее уровень права и сделать систему гораздо более сложной и гибкой. В предыдущем примере надо было бы делать поле права не логическим, а числовым.


Copyright © 1993–2020 Мацкявичюс Д.А. Все права защищены.
Никакая часть сайта не может быть воспроизведена никаким способом без письменного разрешения правообладателя и явной ссылки на данный ресурс.