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

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

 

Устройство системы безопасности

Таким образом, мы приходим к организационной схеме, изображенной на рис. 1.

Рис. 1. Организационная схема системы безопасности

 

База общей системы безопасности содержит тот самый абстрактный уровень, который позволяет свести к минимуму повторяемость кода. Что может быть вынесено на этот уровень:

a) добавление, удаление, изменение учётных записей;

b) добавление, удаление, изменение групп;

c) присвоение прав группам прав группам и пользователям;

d) контроль над подключениями;

e) фиксирование событий в журнале;

f) фиксирование ошибок клиентских частей в журнале;

g) централизованное управление обновлением клиентских частей приложений;

h) контроль версий клиентских частей приложений.

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

Давайте перейдём к непосредственному проектированию.

 

Единая политика учётных записей

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

- пользователь –Маша Ведро;

- учётная запись – vedro_m;

- пароль – не менее 7 символов.

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

 

Создание учётной записи

Ранее мы договорились, что наша система безопасности должна быть интегрирована с системой безопасности MS SQL Server. Проще говоря, создание учётной записи в административной утилите должно приводить к её создаю на сервере. Есть два способа это сделать: синхронный и асинхронный. Рассмотрим оба варианта.

 

Синхронный способ

1) Создаём учётную запись в административной утилите.

2) Передаём введённые параметры (имя учётной записи и пароль) в процедуру sp_addlogin.

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

4) Фиксируем факт создания учётной записи в журнале.

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

 

Асинхронный способ

1. Создаём учётную запись в административной утилите.

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

3. Через определённый промежуток времени на сервере срабатывает задание (job), которое берёт параметры из Т и посредством процедуры sp_addlogin создаёт учётную запись.

4. Задание фиксирует в журнале факт создания учётной записи.

Асинхронный способ позволяет избежать недостатков предыдущего способа. Мы можем дать администратору права только на процедуру, добавляющую записи в Т, и не включать его в роль securityadmin. Зато задание, владелец (owner) которого обладает полномочиями securityadmin, на шаге 3 выполнит все необходимые действия.

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

 

- - В таблицу помещается не сам пароль

- - а хэш от него

Set @pwdhash = pwdencrypt(@password)

- - Далее задание берёт хэш из таблицы Т

- - и передаёт его процедуре sp_addlogin

EXEC sp_addlogin @login. @pwdhash.

@encryptopt = ‘skip_ encryptopt’

 

 

Удаление учётной записи

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

1. Удаляем учётную запись из административной утилиты.

2. Удалённая запись помещается в таблицу Q.

3. Через некоторый промежуток времени запускается задание.

4. Задание выбирает все учётные записи, подлежащие удалению и меняет им пароли на случайные.

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

6. Факт удаления фиксируется в журнале.

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

 

Сеансы

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

1. Пользователь запускает приложение и вводит имя своей учётной записи и пароль.

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

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

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

Ваши приложения рассчитаны на работу через службу терминала или Citrix Metaframe, то для реального IP-адреса можно воспользоваться соответствующими программными интерфейсами (API). Например, Citrix предоставляет пакет Server SDK, куда входит документация и готовые примеры.

Даже когда Маша Ведро откроет терминальный сеанс, а в нём ещё один терминальный сеанс, а уже затем вашу программу, то клиентская часть всё равно определит IP-адрес компьютера Маши, а не IP-сервера терминалов.

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

1. Пользователь авторизуется в приложении.

2. Если для этой учётной записи уже существует сеанс, то он принудительно закрывается (только для данного приложения!).

3. Механизм регистрации создаёт новый сеанс для пользователя, который авторизовался на шаге 1.

Описанный алгоритм быстро отучает весь отдел продаж работать под учётной записью Маша Ведро.

Мы обсудили только случай, когда пользователь корректно завершает работу с программой. Давайте теперь рассмотрим ситуацию, когда приложение, к примеру, “повисло” или пользователь закрыл терминальный сеанс, не потрудившись выйти из программы. Как сервер узнает, что сеанс работы с программой больше не нужен? Существует два способа: с таймером и без таймера.

 

Способ с таймером

1. Пользователь авторизуется и получает код сеанса.

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

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

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

 

Способ без таймера

1. Пользователь авторизуется и подключается к серверу.

2. Запускается процедура регистрации сеанса, которая устанавливает для текущего процесса значение context_info равным уникальному коду сеанса. Вместе с кодом сеанса в таблицу сеансов помещаются значения spid и context_info.

3. Пользователь работает.

4. На сервере запущено задание, которое с заданной периодичностью проверяет для каждого активного сеанса наличие соответствующих процессов в sysprocesses. Если обнаруживается, что у незавершённого сеанса нет процесса с такими значениями spid и context_info, сеанс уничтожается.

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

Таблица Applications содержит параметры приложений, которые используют общую систему безопасности. О назначении полей этой таблицы будет рассказано далее.

Таблица Users хранит служебную информацию о пользователе (ФИО, флаг блокировки, дата последнего подключения и количество подключений). Вы можете расширить эту таблицу любыми полями (например, филиал, телефон и пр.). Обратите внимание, что идентификатор пользователя object_id фактически содержится в таблицу Object, которая объединяет в себе две сущности – пользователей и группы. Это сделано для того, чтобы членом группы можно было сделать не только пользователя, но и группу. Ведь с точки зрения наследования прав эти две сущности эквивалентны. О правах и группах мы поговорим позже.

Таблица Sessions предназначена для контроля пользовательских сеансов. Здесь есть всё, о чём мы уже упоминали: дата и время начала сеанса работы, дата и время завершения сеанса, имя хоста, IP-адрес, также ссылка на пользователя. CurrentSessions содержит только текущие подключения. Поле nofity_date используется для уведомления сервера о том, что сеанс всё ещё активен (способ с таймером), a status – для принудительного завершения сеанса работы. Таблицы EventLog и Events нужны для фиксации событий.

 

Что такое транзакция

 

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

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

■ Прием заказа. Для приема заказа от клиента программа ввода заказов должна:(а) выполнить запрос к таблице products и проверить наличие товара на складе; (б)добавить заказ в таблицу ORDERS;(в) обновить таблицу PRODUCTS, вычтя заказанное количество товара из количества товара, имеющегося в наличии; (г) обновить таблицу salesreps,добавив стоимость заказа к объему продаж служащего, принявшего заказ; и (д) обновить таблицу OFFICES, добавив стои­мость заказа к объему продаж офиса, в котором работает данный служащий.

■ Отмена заказа. Чтобы отменить заказ, принятый от клиента ранее, программадолжна: (а) удалить заказ из таблицы ORDERS;(б) обновить таблицу products,откорректировав количество товара, имеющегося в наличии; (в) обновитьтаблицу salesreps, вычтя стоимость заказа из объема продаж служащего; и (г) обновить таблицу offices, вычтя стоимость заказа из объема продаж офиса.

■ Перевод клиента. При переводе клиента от одного служащего к другому программа должна: (а) соответствующим образом обновить таблицу CUSTOMERS;(б) обновить таблицу orders,изменив имя служащего, ответственного за заказы данного клиента; (в) обновить таблицу salesreps,уменьшив план для служаще­го, теряющего клиента; и (г) обновить таблицу salesreps,увеличив план служащего, приобретающего клиента.

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

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

 

«Инструкции, входящие в транзакцию, рассматриваются как неделимое целое. Либо все инструкции будут выполнены успешно, либо ни одна из них не должна быть выполнена».

 

Как следует из рис. 12.1, СУБД должна подчиняться этому правилу, даже если во время выполнения транзакции произойдет ошибка в программе или аппаратный сбой. В любом случае СУБД должна гарантировать, что при восстановлении базы данных после сбоя “частичное выполнение транзакции” в ней отражено не будет.

 

 

Рисунок 12.1 ‒ Понятие транзакции в SQL

 

Инструкции COMMIT и ROLLBACK

В SQL обработка транзакций реализована с помощью двух инструкций:

■ Инструкция commitсообщает об успешном окончании транзакции. Она информирует СУБД о том, что транзакция завершена, все инструкции, входящие в состав транзакции, выполнены успешно и противоречия в базе данных не возникли.

■ Инструкция rollbackсообщает о неуспешном окончании транзакции. Она информирует СУБД о том, что пользователь не хочет завершать транзакцию; СУБД должна отменить все изменения, внесенные в базу данных в результате выполнения транзакции. Т.е. СУБД возвращает базу данных в состояние, в котором она находилась до начала транзакции.

■ Инструкции COMMIT и rollback являются такими же инструкциями SQL, как и select, insertили update.Ниже приведен пример успешной транзакции, изменяющей количество заказанного товара и стоимость заказа, а также корректирующей количество товара, имеющегося в наличии, вместе с объемами продаж служащего и офиса. Обычно такие изменения обрабатывает специальная программа, содержащая соответствующие формы и использующая для выполнения инструкций программный SQL:

 

В заказе с номером 113051 изменить количество товара с 4 на 10, что увеличивает стоимость заказа с $1458 до $3550. Это заказ на изделие QSA - XK 47, который был принят Ларри Фитчем (идентификатор служащего 108), работающим в Лос-Анд­желесе (идентификатор офиса 21).

 

UPDATE ORDERS

SET QTY = 10, AMOUNT = 3550.00 WHERE

ORDER_NUM = II3051

 

UPDATE SALESREPS

SET SALES = SALES - 1458.00 + 3550.00 WHERE

EMPL_NUM =108

 

UPDATE OFFICES

SET SALES = SALES - 1458.00 + 3550.00

WHERE OFFICE =21

 

UPDATE PRODUCTS

SET QTY_ON_HAND = QTY_ON_HAND +4-10 WHERE MFR_ID = 'QSA'

AND PRODUCT_ID = 'XK47'

 

... окончательное подтверждение вносимых изменений клиентом...

 

COMMIT WORK

 

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

 

В заказе с номером 113051 изменить количество товара с 4 на 10, что увеличивает стоимость заказа с $1458 до $3550. Это заказ на изделие QAS - XK 47, который был принят Ларри Фитчем (идентификатор служащего 108), работающим в Лос-Анд­желесе (идентификатор офиса 21).

 

UPDATE ORDERS

SET QTY = 10, AMOUNT = 3550.00

WHERE ORDER_NUM = 113051

 

UPDATE SALESREPS

SET SALES = SALES - 1458.00 + 3550.00

WHERE EMPL_NUM = 108

 

UPDATE OFFICES

SET SALES = SALES - 1458.00 + 3550.00

WHERE OFFICE = 21

 

UPDATE PRODUCTS

SET QTY_ON_HAND = QTY_ON_HAND +4-10 WHERE MFR_ID = 'QAS'

 

AND PRODUCT_ID = ’XK47’

 

... увы! Идентификатор производителя “ QSA ”, а не “ QAS ”...

 

ROLLBACK WORK