Отправляет email-рассылки с помощью сервиса Sendsay
  Все выпуски  

Microsoft Access - программирование и готовые решения


Выпуск 79. Материалы для начинающих (26 урок)

Подписка: "Access 2000 - программирование и готовые решения"
Дата:       11.06.2007
Автор:     Парусников Алексей (aka Palarm)
Сайт:        http://www.accessoft.ru под редакцией с http://www.leadersoft.ru/
Новые материалы: защита через файл рабочей группы
На сайте AccesSoft публикуются статьи, посвященые вопросам, связанным с разработкой и продвижением приложений Access. Вы так же можете ознакомиться с готовыми программами, получить исходный код, купить программу, связаться с автором для решения вопроса о доработке программы под Ваши требования.


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

      Прежде чем приступать к защите базы с помощью файла рабочей группы, следует определиться: будем защищать обе части приложения (файл с данными и файл объектов) или только файл с данными? Защищать интерфейсную имеет смысл, если Вы хотите ограничить доступ пользователей к макросам и запросам (запретить их редактирование). Про формы и отчеты речь не идет, ведь само собой разумеется, что база будет предъявлена пользователю в формате mde. Если же это не является проблемой,  например, все запросы прописаны в свойствах форм и отчетов – то достаточно будет установить защиту только на серверную часть. В этом случае базу будет проще администрировать.

      Для установки защиты используют специальный мастер. Открываем файл данных – Сервер.mdb. Затем Сервис – Защита – Мастер. Откроется диалоговое окно, где первым делом предлагается выбрать: создать или изменить текущий файл рабочей группы. Нам нужно «Создать». Жмем далее. В открывшемся окне в поле «Имя файла» автоматически прописывается путь к файлу рабочих групп – по умолчанию, в том же каталоге, что и Сервер.mdb. Обратим внимание на поле «Код рабочей группы». Это уникальный идентификатор группы из случайно набранной буквенно-цифровой комбинации.

Его обязательно нужно сохранить!

      Дело в том, что при потере или порче файла рабочих групп доступ к базе станет не возможен (насчет хакерских методов промолчу). В конце все процедуры мастер предложит Вам создать отчет о проделанной работе  - там среди прочего и будет этот код. Также оставим галочку «создать ярлык для защищенной базы». В предыдущей части статьи говорилось об этом ярлыке. Речь шла о том, чтобы запускать базу через него, а не подключать созданный mdw ко всем проектам Access. Раз уж мастер взялся за дело, пусть он и делает ярлык. Жмем далее.

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

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

      На этой вкладке предлагается группе Users назначить ограниченные права. Смысл тут в том, что как уже говорилось в первой части статьи, все базы Access в действительности уже подключены к стандартному файлу рабочих групп, просто права у всех пользователей (группа Users) полные, как у администратора. А при «установке защиты» создается новый файл группы или изменяется стандартный. Вообще, в любом файле групп всегда будут присутствовать как минимум две группы: Admins и Users. Это и понятно: во всякой системе защиты «входящий» в простейшем случае должен быть опознан как простой пользователь или администратор. Удалить эти два понятия никак нельзя, иначе теряет смысл защита – как узнать, кто пришел? Хотя начинающие разработчики иногда пытаются удалить «юзеров», а те не удаляются…

      Заметим, мастер предупреждает, чтобы не отдавали «юзерам» права без особой надобности, ведь раз такая группа есть во ВСЕХ группах, то назначая ей права, вы автоматически назначаете эти права по умолчанию для всех файлов mdw. Говоря проще, если дать группе Users полные права, то для обхода защиты достаточно создать новый файл mdw и зайти под именем пользователя группы Users. Поэтому чаще всего эту вкладку также проезжаем.

      Теперь добрались до создания своих админов и юзеров. По умолчанию там уже есть админ – можете заменить его на своего, если ему не доверяете. Для этого выбираем в списке слева «Добавить пользователя», задаем ему имя (например Пупкин), пароль и жмем «Добавить пользователя в список». Теперь можно прогнать старого админа – выделяем его и жмем «Удалить пользователя из списка». Теперь наш Пупкин автоматически стал админом (потому как других все равно нет). Чтобы убедиться в этом, переходим на следующую вкладку и видим, что в группе Admins (администраторы) присутствует наш человек. Жмем далее.

      Теперь осталось только указать, куда сохранить резервную копию незащищенной базы. Это на случай, если вдруг вы передумаете и решите вернуть все «как было». Access создает копию базы, только меняет у нее расширение на .bak. Видимо для того, чтобы никто не догадался, что это не защищенная база. Жмем готово.

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

В результате всего получилось следующее:

  1. Появился новый файл рабочих групп - Security.mdw (в Access 2002 он по умолчанию называется Secured.mdw)
  2. Все объекты базы Сервер.mdb (таблицы) «прошились» через файл рабочих групп
  3. Появилась копия базы – Сервер.bak
  4. На рабочем столе появился ярлык подключения к базе – Сервер.lnk

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

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

      Если пользователей достаточно много, то имеет смысл создать группы, чтобы объединить их. В каждой группе может быть несколько пользователей. Права доступа группы автоматически назначаются членам группы. Тем самым упрощается администрирование базы данных. Переходим на вторую вкладку и создаем необходимые нам группы. Затем возвращаемся на первую. Здесь мы видим, что в списке групп кроме стандартных admins и users появились новые. Чтобы зачислить в них наших пользователей, выберем из списка пользователя, выделим группу и жмем добавить. Обратим внимание, что наш админ Пупкин должен обязательно присутствовать в группе администраторов (admins). Иначе он не будет админом. Соответственно, всех остальных это не касается.

      После создания пользователей и распределения их по группам осталось задать им пароль входа – это делается на последней вкладке.

Пароль пользователя может изменить только сам пользователь, то есть тот, кто зайдет в программу под его именем!

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

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

IF CurrentUser = “1” Then …

Но такой вариант не дает доступа к данным через формы, но ничто не мешает пользователю «залезть» напрямую в Сервер.mdb.

Изменять уровень доступа может только администратор (admin) – член группы admins!

      То есть для изменения уровня доступа для пользователей необходимо зайти в серверную часть программы под именем администратора (в нашем случае «Пупкин»). Затем выбрать: Сервис – Защита – Разрешения. Можно устанавливать доступ для группы, а можно для каждого пользователя отдельно. В случае с группами при создании нового пользователя, чтобы назначить ему права доступа, достаточно поместить его в соответствующую группу. Поэтому мы будем ставить доступы для групп.

      Для этого на вкладке «Разрешения» нужно переключиться на «группы» и в списке «Пользователь и группы» выбрать необходимую группу. В поле со списком «Тип объекта» выбрать необходимый тип объекта базы данных. В списке «Имя объекта» выбрать объект и в списке «Разрешения» проставить уровень доступа к объекту.

Не экспериментируйте с правами доступа администратор (admin) – иначе Вы, как администратор, может закрыть базу от самого себя!

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

При потере или порче файла рабочих групп Security.mdw доступ к базе данных станет не возможным!

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

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

  1. Дата создания – дата и время создания записи.
  2. Дата изменения – дата и время изменения записи.
  3. Изменил – имя пользователя, изменившего запись.

      Запись делается при помощи перехвата события формы «Внесены изменения»

Private Sub Form_Dirty(Cancel As Integer)
      [ДатаИзменения] = Date + Time
      [Изменил] = CurrentUser
End Sub

      А дату создания можно аналогично задать в таблице как дату по умолчанию: Date()+Time() Чтобы данные отображались в расширенном формате, нужно будет установить в таблице формат поля как dd.mm.yy.hh.nn

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

P.S. Дополнение к статье от Leadersoft.ru Однажды руководитель компании, занимающейся финансовыми вопросами сделал запрос по электронной почте с заявкой вскрыть пароль к базе данной защищенной system.mdw. База эта была разработана ими, но они потеряли пароль и теперь не имеют доступа к файлу mdb. Мне показалась работа эта простой, за нее обещали хорошо заплатить, особых условий не было, но нужно было сделать все за неделю. Но вот, что произошло http://help.leadersoft.ru/tabid/126/EntryID/6/Default.aspx

 


В избранное