Реализация хранения учётных записей, проверки подлинности и защиты от сбоев

В Конфигураторе подсистемы «1С:Предприятие» разделены функция создания набора пользовательских прав и функция создания пользователей. С одной стороны, возможно создать несколько типовых наборов пользовательских прав с различной широтой полномочий. Присвоение прав новой категории пользователей заключается в простой операции назначения для этой категории одного из типовых наборов прав. С другой стороны, при изменении полномочий для этой же категории пользователей нет необходимости в редактировании прав каждого отдельного пользователя — достаточно отредактировать текущий набор прав этой категории пользователей или присвоить ей новый набор прав. [17] В нашем случае пользователями являются: администратор, главный бухгалтер и ещё 5 бухгалтеров. (см. рисунок 3.19)

Рис 3.19 Определение пользователей

Далее определяем права для каждого конкретного пользователя. Администратору определим полные права, так как у него приоритет выше, чем у других пользователей. Главному бухгалтеру разрешаются все операции, за исключением внесения изменений в конфигурацию и её корректировки. Всем остальным пользователям разрешён только просмотр. (см. рисунок 3.17)

Рис 3.20 Свойства элемента прав

Так как прикладная подсистема использует SQL Server, все учётные записи для пользователей нашей системы соответствуют учётным записям SQL Server. Идентификатор учетной записи пользователя сопоставлен идентификатору пользователя в БД. (см. рисунок 3.21)

Рис 3.21 Сопоставление учётных записей системы и SQL Server

При определении прав пользователя используется два уровня зашиты. Первый уровень — проверка подлинности пользователя. Во время проверки определяется, имеется ли у пользователя право на подключение. Второй уровень системы безопасности — авторизация. При этом определяется, какие действия пользователь сможет выполнять с БД, после того как он пройдет проверку подлинности. Предусмотрены два вида проверки подлинности: средствами Windows и средствами SQL Server. Подключаясь к SQL Server, пользователь указывает вид проверки подлинности для данного соединения. Чтобы установить соединение, пользователь должен указать правильный идентификатор учетной записи (login identifier) пользователя, который определяет права доступа, далее проверяется, действительно ли идентификатор учетной записи пользователя, введенный при установке соединения, обеспечивает пользователю право на подключение.

Если при подключении указывается, что проверка подлинности выполняется средствами Windows, то для проверки того, зарегистрирован ли данный пользователь в этой сети, используются средства Windows Server 2003. SQL Server идентифицирует пользователя по имени его учетной записи, существующей в сети, и разрешает или запрещает этому пользователю устанавливать соединение, не требуя его отдельной регистрации как пользователя SQL Server. Такой тип соединения называется доверенным (trusted). При проверке подлинности средствами Windows используются механизмы защиты Windows Server 2003, в том числе такие средства, как защищенный режим проверки прав пользователя в сети и шифрование пароля, аудит, ограничение срока действия пароля, ограничение на минимальную длину пароля и блокирование учетной записи пользователя после нескольких неудачных попыток регистрации.

Если при подключении к серверу выбран режим проверки подлинности средствами SQL Server, то он сам проверяет подлинность пользователя, уточняя, имеется ли такая учетная запись с указанным именем и паролем на SQL Server. После того как SQL Server проверит подлинность пользователя, определяются права данного пользователя выполнять различные действия в размещенных на сервере БД. Сам по себе идентификатор учетной записи пользователя не дает зарегистрированному пользователю прав доступа к различным объектам БД. Он лишь позволяет перейти к следующему этапу — авторизации, или проверке прав пользователя. Такой механизм защиты гарантирует, что зарегистрированный пользователь не получит автоматически доступ ко всем БД на SQL Server, с которым он установил соединение. Приведём дерево решений системы проверки подлинности. (см. рисунок 3.22)

Рис 3.22 Дерево решений системы проверки подлинности

Как отмечалось ранее, для реализации программы была выбрана подсистема «1С: Предприятие 7.7 для SQL», которая непосредственно в своей работе использует SQL Server. Следовательно, обеспечение хранения данных, организацию целостности и защиту к сбоям берёт на себя прикладная подсистема.

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

Нами используются следующие методы обеспечения целостности и защиты к сбоям:

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

2) Дифференциальное резервное копирование БД. При дифференциальном резервном копировании БД копируются все изменения, произошедшие в файлах данных с момента последнего полного резервного копирования БД, включая все изменения, внесенные в БД при выполнении последнего дифференциального резервного копирования. Этот процесс включает в себя копирование всех изменений данных и объектов БД. Дифференциальное резервное копирование БД отражает только самые последние изменения данных; если какая-либо из записей была изменена более одного раза с момента последнего полного резервного копирования, то при дифференциальном копировании будет зарегистрировано только последнее из внесенных изменений (в отличие от резервной копии журнала транзакций, где отражается каждое изменение). Дифференциальное резервное копирование БД занимает меньше времени и места, чем полное, и позволяет сократить время восстановления БД.

3) Резервное копирование журнала транзакций. Резервное копирование журнала транзакций заключается в последовательной записи всех зарегистрированных транзакций с момента последнего резервного копирования журнала. Оно позволяет восстановить данные до состояния на определенный момент времени, например до введения ошибочных данных. Резервные копии журнала транзакций используются только в полной модели восстановления и в модели записи копирования. При использовании модели восстановления результатов импорта для операций, где все записи о внесенных изменениях регистрировались в журнале транзакций, изменения в файлах данных в результате этих операций регистрируются на странице, где размещается карта изменений при загрузке данных (Bulk Changed Map, BCM). В процессе резервного копирования журнала транзакций просматривается каждая страница ВСМ, и в резервную копию включаются все экстенты, где произошли изменения со времени последнего резервного копирования журнала транзакций. Использование модели восстановления результатов импорта позволяет за достаточно короткий срок создавать резервные копии при выполнении операций загрузки большого объема данных одновременно с созданием резервной копии журнала транзакций. Однако регистрируется не каждая отдельная операция, а только результирующие изменения данных, выполненные в ходе операции загрузки. Страницы ВСМ не используются в полной модели восстановления, так как в данном случае все операции по загрузке большого объема данных полностью регистрируются в журнале транзакций. Необходимое для резервного копирования журнала транзакций время варьируется в зависимости от скорости транзакций, используемой восстановительной модели и от объема операций с большим количеством регистрационных записей. В БД с очень высокой скоростью транзакций и полностью регистрируемых групповых операциях размер резервных копий журнала транзакций может быть больше, чем полная резервная копия БД, и может потребоваться более частое выполнение резервного копирования журнала транзакций с тем, чтобы регулярно сокращать неактивную часть журнала.

Если не определено иное, после завершения резервного копирования журнала транзакций SQL Server удаляет все виртуальные файлы журнала (Virtual Log Files, VLF), которые не содержат активную часть журнала, что позволяет повторно использовать их. Активная часть включает в себя любую часть журнала транзакций, содержащую активную транзакцию. Промежуток времени между операциями резервного копирования журнала транзакций зависит от объема транзакций, размера файла журнала транзакций, необходимого уровня отказоустойчивости и сроков восстановления. Выполнять резервное копирование можно часто, каждые 10-15 минут, или раз в 2-3 часа (возможен ещё больший период, если было выполнено всего несколько транзакций).

Если всё-таки в силу каких-либо обстоятельств произошёл сбой в работе программы предполагается использование двух типов восстановления

1) Автоматический процесс восстановления данных, который гарантирует логическую целостность данных в каждой БД после запуска SQL Server независимо от причины предшествующего останова — как после корректного завершения работы, так и после сбоя. При этом используется журнал транзакций. SQL Server использует информацию из активной части журнала транзакций в каждой БД и анализирует все транзакции, зарегистрированные с момента последней проверки целостности БД, а также определяет все подтвержденные транзакции и выполняет их повтор, то есть вносит соответствующие изменения в БД. Затем выделяет все неподтвержденные транзакции и отменяет их. Это гарантирует удаление всех неподтвержденных транзакций из БД, что является важной частью процесса автоматического восстановления, поскольку в БД могут храниться лишь частично обновленные данные. Этот процесс обеспечивает логическую целостность каждой БД. Затем автоматический процесс восстановления устанавливает контрольную точку, тем самым, отмечая, что в данный момент журнал транзакций находится в согласованном состоянии. Процесс восстановления начинается с БД master, которая содержит информацию, необходимую для открытия и восстановления всех остальных БД. Затем восстанавливается БД model и msdb. Далее восстанавливаются все пользовательские БД. В конце удаляется и снова создаётся БД tempdb. Пользователи не могут непосредственно контролировать автоматический процесс восстановления.

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