Как сделать разграничение прав доступа в базе данных аксесс

Добавил пользователь Евгений Кузнецов
Обновлено: 04.10.2024

После установки ACCESS пользователь получает право доступа ко всем объектам БД (становится членом группы Admins с именем Admin). Поскольку по умолчанию пароль в этой учетной записи не указывается, его не нужно вводить для входа в систему.

Члены группы Admins (администраторы) имеют право на модификацию БД. Пока не будет задана регистрация входа в систему всех членов рабочей группы, ACCESS будет разрешать вход в систему используя предопределенную регистрационную запись Admin. Чтобы задать регистрацию входа в систему и тем самым устранить произвольный доступ к ней, следует установить пароль для администратора в регистрационной записи Admin. В противном случае при каждом запуске ACCESS администратор будет регистрироваться как пользователь Admin без указания пароля.

Чтобы регистрировался вход в систему необходимо выполнить последовательность действий:

Запустить ACCESS, указав рабочую группу, и открыть БД.

В подменю Защита меню Сервис активизировать команду Пользователи и группы (Рисунок 4).


В открывшемся диалоговом окне перейти на вкладку Изменение пароля, ввести в поле Новый пароль задуманный пароль и подтвердить его в поле Подтверждение. Поле Текущий должно остаться пустым. Затем - кнопка ОК.

При вводе пароля вместо введенных символов отображаются звездочки (*). Пароль может иметь длину от 1 до 14 знаков и включать любые символы, кроме 0 кода ASCII. Следует помнить, что при вводе пароля различаются строчные и прописные символы.


В поле Имя следует ввести имя пользователя, а в поле Пароль - пароль. После нажатия кнопки ОК программа продолжит процесс запуска, если пароль введен правильно.

Удалить пароль можно, выполнив последовательность действий:

В подменю Защита меню Сервис активизировать команду Пользователи и группы.

В открывшемся диалоговом окне перейти на вкладку Пользователи и, удостоверившись, что в поле Имя указано правильное имя пользователя, нажать кнопку Снять пароль.

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

4. Учетные записи.

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

По умолчанию создается учетная запись Admin, а также учетные записи групп Admins (Администраторы), Users (Пользователи) и предоставляются права доступа ко всем объектам.

Учетная запись администратора включена в рабочую группу Admins. Администратор имеет право доступа ко всем объектам, созданным в этой группе. Кроме администратора может быть указан владелец БД. В системе обеспечения безопасности ACCESS владельцы объектов имеют особый статус. По умолчанию пользователь, создавший объект, становится владельцем объекта и прав на работу с ним.

Администраторы и владельцы наделены особыми правами:

Администратор БД всегда может получить права доступа ко всем объектам, созданным членами данной рабочей группы;

Владелец БД всегда может открыть БД;

Владелец объекта наделен полными правами доступа к этому объекту.

Так как регистрационная запись Admin одинакова для всех копий ACCESS, для защиты БД необходимо включить нового пользователя в группу Admins или заменить администратора Admin.

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

Запустить ACCESS, выбрав рабочую группу и открыть любую БД

В подменю Защита меню Сервис активизировать команду Пользователи и группы.

В открывшемся диалоговом окне перейти на вкладку Пользователи и нажать кнопку Создать.

В появившемся диалоговом окне в поле Имя ввести имя учетной записи (пользователя), а в поле Код - уникальный код записи. Затем - кнопка ОК.

Имя пользователя может иметь длину от 1 до 20 символов и включать буквы, цифры, пробелы и другие символы за исключением символов: " \ [] ^| <> + = ; , ? * и управляющих символов (с кодами ASCII от 00 до 31). Кроме того, имя записи не может начинаться с пробела.

После возвращения в окно Пользователи и группы выбрать в списке Имеющиеся группы группу Admins и нажать кнопку Добавить. Группа Admins будет помещена в список Участие в группе, что обеспечит ввод учетной записи в группу Admins. В завершение нажать ОК.

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

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

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

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

В открывшемся диалоговом окне (Рисунок 6) в поле Имя указывается имя группы, а в поле Код - уникальный код (любая комбинация символов длиной от 4 до 20 знаков).


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

Удаление учетной записи или группы из рабочей группы осуществляется следующим образом:

Запустить ACCESS с выбранной рабочей группой и открыть БД.

В подменю Защита меню Сервис активизировать команду Пользователи и группы.

В открывшемся диалоговом окне перейти на вкладку Пользователи (при удалении учетной записи пользователя) или Группы (при удалении учетной записи группы).

В списке Имя выбрать выбрать имя пользователя или группы для удаления, нажать кнопку Удалить, затем подтвердить удаление, нажав кнопку Да.

Закрыть окно Пользователи и группы.

После создания учетных записей пользователей и групп взаимосвязь между ними можно проследить, нажав кнопку Отчет о защите. При этом появляется диалоговое окно, в котором можно выбрать необходимые сведения (Рисунок 6.7.) и вывести их на печать.

На своей практике веб-разработки я очень часто сталкивался с ситуациями, в которых заказчики ставили конкретную цель, а именно о разделении частей админки относительно доступности тем или иным пользователям. При этом разработка данного модуля велась в контексте расширяемой системы, а то есть с нефиксированым числом модулей, к которым организовуется доступ, ну и, соответственно, неограниченным числом пользователей системы.

Что ж, сама по себе данная тема довольно грузная, и требует определённого времени на анализ и постанувку задачи.

Давайте с самого начала обсудим архитектуру модульной системы на выбранной нами псевдо-системе.

Все модули представлены ввиде подключаемых к главному документу (индекс-файлу) вставок. Запрос модуля происходит из строки запроса QUERY_STRING, и название подключаемого модуля передаётся в качестве аргумента act. В некотором месте индекса файла происходит изъятие и обработка данного параметра. После, если у пользователя достаточно прав для доступа к модулю в контексте чтения, происходит проверка существования указанного в строке запроса модуля, и если таковой существует, то происходит его подключение к индекс файлу.

Я не просто так упомянул о "контексте чтения", так как наша системе предполагает существование двух контекстов работы с системой, а именно - чтение и запись. При этом под чтением предполагается непосредственный доступ к модулю и к тем его частям, которые не предполагают внесение изменений в структуру данных в БД. Под записью же предполагается непосредственное внесение изменений в информацию, хранимую в базе данных.

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

Значение do буду фиксированными, данная переменная будет принимать следующие значения:

  • main - главная часть модуля (доступно в контексте чтения)
  • config - раздел настройки модуля (доступно в контексте записи)
  • create - произвести некоторые действия, по добавлению информации в БД (доступно в контексте записи)
  • delete - доступ к разделу, предоставляющему возможности удалить некоторую информацию, в контексте данного модуля (доступно в контексте записи)
  • edit - доступ к редактированию информации в контексте модуля (доступно в контексте записи)

В целом, этот список можно увеличить, при этом всё зависит лишь только от масштабов проекта и его потребностей в функционале.

Теперь непосредственно о модулях. Кроме физического существования некоторого модуля в контексте файловой системы проекта, модуль так же должен быть добавлен в особую таблицу БД, которая будет содержать информацию о всех существующих модулях в системе. Добавление и изменение данных данной таблицы, обычно, производится непосредственно в контексте модулей, а то есть во время их инсталяции в системе. Однако это уже углубление в принципы посмотроения расширяемых систем, о чём мы как-то в другой раз поговорим, и посему, мы ограничимся ручным обновлением и добавлением данных о модулях.

Так, запись о модуле системы будет содержать следующую информацию: английский идентификатор названия модуля, который будет идентичен значению переменной среды GET - act (относительно него будет производится непосредственно запрос модуля), русский идентификатор модуля, который будет использоватся в списке модулей.

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

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

Что ж, давайте рассмотрим эту особую структуру. Она будет следующей: [ module_indefier : [0 | 1]+ \: [0 | 1]+ \;] *

То есть идёт список из пар: имя модуля ":" права чтения "," права записи ";". При этом данная метка обновляется в момент внесения изменений о правах доступа пользователя к системе. Если в системе появляется информация о модуле, который не вошёл в данную метку, то стоит просто произвести процедуру редактирования, и данные сохранятся автоматически.

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

Я не буду добавлять ничего лишнего в неё, но лишь то, что будет использоватся в контексте темы данной статьи. Таблица пользователей будет содержать следующие поля: идентифицатор пользователя (числовой счётчик), логин, пароль (хеш оригинального пароля), профиль безопасности пользователя (идетификатор группы пользователя, относительно прав в системе), и всё. Мне кажется этой информации нам с вами вполне хватит, для реализации поставленной задачи, а уже все остальные надстройки я предоставляю возможность сделать самим.

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

Далее описан класс для внедрения функций проверки прав доступа пользователей к модулям системы.

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

Используя данную функцию, мы подразумеваем, что во время авторизации пользователя в системе в переменной среде $_COOKIE была установлена переменная `site_hash`, состоящая из идентификатора пользователя в системе и хеша для проверки аутентичности его в системе. Функция просто изымает значение идентификатора, возращая его значение на выходе.

На выходе данная функция возвращает идентификатор профиля безопасности текущего пользователя в системе.

Производится запрос к БД, относительно прав пользователя на произведение действий чтения/записи в контексте переданного в качестве параметра модуля.

Осталось лишь описать процедуру формирования переменной в среде $_COOKIE, и тему статьи можно будет считать расскрытой.

Процедура авторизации будет выглядеть ввиде внесения личных данных пользователя (логин и пароль) в специальную форму, после отправки которой произойдёт обработка данных, переданных пользователем, по-методу функции checkAuthData(), и, в случае корректности данных, будет произведено сохранение данных о пользователе ввиде куки записи на период установленный пользователем, либо в отсутствии заданного значение на период по-умолчанию.

Для проверки аутентичности данных хранимых в переменной среде $_COOKIE, мы будем использовать функцию EatCookie(), которая будет производить валидацию данных, возвращая булевый результат проверки (истина - ложь).

Я не привожу форму для отправки, так как это не часть теории программирования, указав лишь идентификаторы полей.

  • `ulogin` - логин пользователя
  • `upasswd` - пароль пользователя
  • `stime` - время сессии, устанавливаемое пользователем (от 1 до 5 часов)
  • `auth` - имя кнопки отправки

Вот, в целом и всё. Осталось лишь пробовать, экспериментировать, ошибатся и находить решение, что я всецело и оставляю вам.

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Сенченко П. В.

В статье представлена реализация программного алгоритма разграничения полномочий доступа к объектам форм приложений в среде MS ACCESS, внедрение которого в программный код приложения расширяет возможности настройки пользовательских систем без привлечения разработчиков.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Сенченко П. В.

Реализация многоуровневой модели разграничения доступа в базах данных под управлением системы управления базами данных Microsoft SQL Server

Technology of differentiation of powers of access to objects of forms of appendices in MS ACCESS environment

In article realization of program algorithm of differentiation of powers of access to objects of forms of appendices in MS ACCESS environment which introduction in a program code of the appendix expands opportunities of adjustment of the user systems without attraction of developers is submitted.

Технология разграничения полномочии доступа к объектам форм приложений в среде MS ACCESS

Томский государственный университет систем управления и радиоэлектроники

В существующих программных комплексах, в основу которых положено работа с базами данных, отдельное место отводится организации защиты данных от несанкционированного доступа и персонификации доступа к ним. В предложенной статье рассматривается вариант технологии разграничения полномочий доступа к объектам форм приложений, созданных в среде СУБД MS Access.

В большинстве, рассмотренных автором информационных систем, направленных на автоматизацию учрежденческой деятельности [1, 2, 3], механизм разграничения полномочий сводится к определению прав доступа непосредственно к объектам базы данных, а также к заданию статичного интерфейса системы для определенных заранее групп пользователей. И если права доступа могут быть изменены администратором системы средствами конкретной СУБД, то динамическая перенастройка пользовательского интерфейса в этих системах невозможна.

Так, с помощью стандартных средств доступа к данным в СУБД MS Access можно осуществить раздачу полномочий к объектам базы данных первого уровня: таблицам, запросам, формам, модулям, макросам, отчетам [4]. Однако при работе с различными приложениями часто возникает необходимость ограничения доступа пользователей непосредственно к объектам форм - полям ввода и элементам управления.

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

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

Описание технологии разграничения полномочий

Для повышения уровня защиты информации в СУБД MS Access, в системе регистрируется новый пользователь, которому даются все права администратора БД [4], при этом у внутрисистемного пользователя Admin убираются все полномочия на использование объектов базы данных, в том числе на занесение новых пользователей, что позволяет обеспечить невозможность несанкционированного доступа в систему с использованием существующих в настоящее время программ взлома mde - файла.

Кроме того, в разрабатываемой системе, можно предусмотреть дополнительную функцию определения группы конкретного пользователя. Так при создании программного комплекса Контроль организационно-распорядительной деятельности (ПК КОРД, разработка НИИ Автоматики и электромеханики г. Томск) [5] в базу данных добавлена таблица Who I am, расположенная в файле user_can.mdb на компьютере пользователя и содержащая код группы пользователя для конкретного сеанса работы. Перечень кодов и соответствующих групп расположен в отдельной таблице, доступ к которой имеет только администратор БД. Были определены соответствующие коды групп (таблица 1).

Классификатор групп пользователей_Таблица 1

Код Место установки Имя рабочей группы Имя пользователя (по умолчанию)

1 Приемная Приемные Priem user

50 Рабочие места сотрудников Users User

51 Руководители подразделений Control contr user

52 Дирекция Дирекции Dir user

91 Руководитель Руководитель Ruk user

102 Канцелярия Канцелярия Kanc user

1002 Отдел информатизации Admins Admin user

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

Для определения перечня объектов форм создается мета-база, содержащая наименование формы, наименование объекта, атрибут доступа к объекту, а также атрибут отображения объекта на экране (рис. 1).

[s Level_acc : таблица

Имя поля Тип данных

Рис. 1 Структура мета-базы

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

Ниже приведен фрагмент программного кода на языке Visual Basic, в котором реализована функция разграничения уровня доступа к объектам форм. Public Function level_ac(frm As Form)

'frm- имя формы приложения поступающее на вход функции ' описание переменных Dim BASu As Database,TABu As Recordset, levs As String, Dim levs1 As String, i As Long, cou As Long Dim this_us As String, str_sql As String 'определение текущего пользователя системы

this_us = CurrentUser 'создание SQL-запроса на выборку записей об объектах базы данных str_sql + frm.Name +.

Set BASu = CurrentDb()

Set TABu = BASu.OpenRecordset(str_sql, DB_OPEN_DYNASET) If TABu.RecordCount <> 0 Then TABu.MoveLast cou = TABu.RecordCount TABu.MoveFirst For i = 1 To cou

levs = TABu![name_form] ' - имя формы из мета-базы levs1 = TABu![Name_control]' - имя объекта формы из мета-базы If frm.Name = TABu![name_form] Then ' проверка возможности доступа пользователя к объекту формы ' если доступ запрещен - запретить использование объекта If TABu![acccess] = True Then

Forms(levs).Controls(levs1).Enabled = True Else

Forms(levs).Controls(levs1).Enabled = False End If

' проверка возможности отображения пользователю объекта формы ' если доступ запрещен - не выводить объект на экран If TABu![Vissible] = True Then

Выделяются следующие роли пользователей по отношению к базам данных и серверу баз данных (SQL Server):

Возможности данных ролей описаны в Таблице 1.

Возможности Администратор сервера баз данных Администратор базы данных* Пользователь базы данных Business Studio
Возможности с использованием локального или удаленного доступа
Доступ к базе посредством программы + + +
Возможность модификации данных в базе посредством программы + + +
Конвертация базы данных + +
Возможность доступа к данным сторонними средствами - внешними построителями отчетов, анализа данных + +
Добавление пользователей +
Удаление пользователей + +
Доступ** к объектам базы независимо от горизонтальных прав + +
Возможность дать пользователю права администратора базы данных +
Обслуживание базы данных средствами программы + +
Модификация структуры базы данных с помощью MetaEdit + +
Возможности с использованием только локального доступа
Создание и восстановление базы данных +
Удаление базы данных + +
Создание резервной копии базы данных (Backup) + +

* - только для соответствующей базы.

** - права "Чтение" и "Редактирование прав" (см. Горизонтальные права).

Доступ к базе данных посредством программы означает для пользователя возможность входа в базу данных и не влияет на права доступа к справочникам и объектам базы данных. Однако администратор базы данных всегда имеет доступ к ряду классов База.Администрирование. Описание разграничения прав доступа пользователей к объектам базы данных приведено в главах Права пользователя, Горизонтальные права.

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

При входе в систему вы указываете имя и пароль, подтверждая таким образом свои права на работу с базой.

Уровень доступа описывает права пользователя в системе. В настоящее время поддерживается 3 уровня доступа:

  • superuser - обладает неограниченными правами.
  • руководитель - не имеет доступа к подразделам Настройки и Пользователи, не может изменять и удалять данные в подразделе Управляющие.
  • сотрудник - не имеет доступа к подразделам Настройки и Пользователи и к разделу Конфигурации, не может изменять и удалять данные в подразделах Управляющие, Предприятия и Процедуры.

Добавление новой учетной записи

Зайдите в программу под учётной записью superuser.



В разделе Конфигурация, подразделе Пользователи нажмите Создать.



В открывшемся окне обязательно заполните поля, выделенные красным. Обратите внимание на выпадающий список Уровень доступа. Нажмите Сохранить.



Изменение свойств учетной записи

Зайдите в программу под учётной записью superuser.

В разделе Конфигурация, подразделе Пользователи дважды кликните по нужному пользователю.



В открывшемся окне измените данные и нажмите Сохранить.



Изменение собственного пароля пользователя

Все пользователи могут сами изменить пароль к своей учётной записи.

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

Кликните иконку Вспомогательные действия и справочная информация | Смена пароля.

В открывшемся окне введите новый пароль в оба поля и нажмите Сохранить.



Изменение паролей пользователей

Зайдите в программу под учётной записью superuser.

В разделе Конфигурация, подразделе Пользователи выберите нужного пользователя и нажмите Сменить пароль.



В открывшемся окне введите новый пароль в оба поля и нажмите Сохранить.

Читайте также: