Об электронном документообороте заявок на предоставление доступа

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

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

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

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

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

• отсутствуют средства «формализации» содержания, из-за чего велика трудоемкость формирования заявок и создается много некорректных заявок;
• необходимы «ручное» определение согласующих для каждой заявки и организация процесса согласования;
• у согласующих отсутствуют средства организации экспертизы заявок;
• автоматизация процесса обработки и исполнения заявок сложна по причине отсутствия четкой структуры их содержания.

Поэтому в Банке была разработана и внедрена специализированная система, которая позволяет:

• вести учет задач, находящихся в Банке в эксплуатации;
• формировать заявки на предоставление доступа с использованием Web-интерфейса в электронном виде выбором необходимых ролей в задаче;
• автоматически определять маршруты согласования заявок в соответствии с информацией в актах приема-сдачи задач в эксплуатацию;
• выполнять электронное согласование заявок;
• получать информацию о стадии обработки заявок (от момента создания до передачи на исполнение), вести их архив.

Данная система имеет трехуровневую структуру, состоящую из архива программ и программной документации (далее – АПиПД), Реестра задач и Системы согласования заявок. Каждый из перечисленных уровней решает свою задачу и получает информацию с предыдущего уровня.

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

В информационный архив входят:

• стандарты, методические, справочные и иные материалы, касающиеся АИС ВТБ;
• документация на программные продукты, поставляемая их разработчиками;
• документация по сопровождению жизненного цикла прикладного программного обеспечения в Банке (технические задания, проектные решения, руководства, протоколы испытаний, акты приема-сдачи и вывода из эксплуатации);
• лицензии на использование программных продуктов, приобретенных в розничной продаже;
• копии лицензионных соглашений,  договоров  на использование программных продуктов и копии платежных документов;
• справочная информация о материалах АПиПД.

Программный архив формируется из программных продуктов и включает:

• исполняемые модули;
• исходные тексты программ.

Основные функции АПиПД:

• ведение логической структуры АИС ВТБ;
• хранение программной документации;
• организация поиска и предоставление доступа к программной документации;
• предоставление ограниченного доступа к исходным текстам и исполняемым модулям программ.

Логически структура АИС ВТБ представлена в АПиПД в виде дерева, на верхнем уровне которого находятся системы, далее располагаются подсистемы, далее комплексы задач и затем задачи.

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

Информирование пользователей АИС ВТБ о находящихся в эксплуатации задачах и наборах полномочий, предоставляемых в рамках тех или иных ролей, возлагается на Реестр задач. Данное программное обеспечение функционирует в рамках корпоративного портала, базируется на АПиПД и расширяет его атрибутный состав для целей организации предоставления доступа.

Основные функции Реестра задач:

• ведение списка задач Банка, принятых в эксплуатацию, предоставление интерфейса для их поиска;
• информирование работников Банка о назначении задач АИС ВТБ, их ролевой структуре и функциях ролей;
• возможность автоматизированного формирования заявки на предоставление/исключение полномочий в АИС ВТБ;
• снижение количества обращений пользователей в отдел поддержки пользователей и ошибок при самостоятельном оформлении.

Реестр задач состоит из двух основных модулей – публичного и административного. Административный модуль предназначен для:

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

Публичная часть Реестра задач предназначена для:

• предоставления пользователям информации о принятых в эксплуатацию задачах;
• поиска задач;
• формирования заявок на предоставление/исключение доступа к задачам.

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

Для формирования заявки на предоставление доступа работник Банка в  публичной части Реестра задач находит задачу, указывает одну или несколько ролей из списка ролей задачи (в случае предоставления доступа), при необходимости добавляет в заявку других работников своего структурного подразделения.

У работника также имеется  возможность заполнить текстовое поле «Ограничение прав доступа», используемое при необходимости указать ограничение по набору данных в задаче. Например, для задачи «Система управления интернет-сайтом» и роли «Редактор» в поле «Ограничение прав доступа» может быть указан раздел сайта, в котором работник получает роль «Редактор».

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

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

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

Заявки, сформированные в Реестре задач, попадают в Систему согласования заявок, в которой организуется их электронное согласование уполномоченными лицами Банка.

Функции Системы согласования заявок:

• организация электронного согласования заявок на предоставление / исключение полномочий в АИС ВТБ;
• автоматизация определения маршрута согласования;
• оперативное информирование руководства и работников подразделений Банка о состоянии направленных ими заявок (от момента создания до передачи на исполнение);
• ведение архива заявок, оперативное получение уполномоченными работниками Банка информации по заявкам в виде отчетов;
• повышение эффективности контроля за предоставлением доступа пользователей к АИС ВТБ.

Доступ пользователей к Системе согласования заявок, также как и к АПиПД и Реестру задач, осуществляется через корпоративный портал Банка.

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

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

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

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

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

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

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

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

Авторство и подлинность принятых решений обеспечиваются применением электронной цифровой подписи (ЭЦП) с использованием сертифицированных средств.

Каждое решение, принятое по заявке в процессе ее согласования, заверяется ЭЦП работника, принявшего решение. При этом подписывается электронное представление заявки, которое имеет вид xml-документа. Формат xml-документа для каждого типа заявки задан соответствующей xsd-схемой и обеспечивает однозначное восстановление заявки и принятых решений только на основании содержащихся в документе данных без привлечения сторонних источников. xsd-схемы хранятся в базе данных вместе с историей их изменения и также подписываются ЭЦП.

Отображение заявки в браузере пользователя производится посредством xslt-преобразования xml-представления заявки. Перед использованием xslt-преобразования для него должна быть проверена ЭЦП, что гарантирует соответствие данных в заявке и отображения на экране. Шаблоны xslt-преобразований заверяются ЭЦП.

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

Если заявка находится в статусе «отклонена» или «согласована» производится проверка всех ЭЦП. При этом заявка является действительной при выполнении  любого из следующих условий:

1) все ЭЦП пользователей, необходимые в соответствии с маршрутом согласования, являются подлинными;

2) принадлежность ЭЦП пользователей проверяется, но для некоторых ЭЦП закончился срок действия сертификата, либо сертификат отозван, и при этом является подлинной архивная ЭЦП.

Архивная ЭЦП выполняет в Системе согласования заявок функции метки времени и проставляется при переходе заявки в статус «отклонена» или «согласована».

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

Стать автором BIS Journal