Управление заявками на коленке. Продолжение.

Управление заявками на коленке. Продолжение.
Продолжим.
Понятно, что набор диспетчерами заявок во вновь рожденной системе был сизифовым трудом. Поэтому была сделана небольшая веб-форма для набора заявок и пользователям под соусом ускорения обработки заявок, было предложено общаться через эту форму. В результате ее заполнения, генерировалось электронное письмо с обратным адресом диспетчерской, которое шло руководителю, указанному в форме. Руководитель в произвольном формате должен был согласовать данное письмо просто ответив на него. Дальше диспетчер копированием вводил заявку в табличку Sharepoint’а. Этот шаг был необходим по нескольким причинам:
1.    Зачастую сотрудник не знал к какому именно ресурсу (точное название) ему необходимо подключиться или формулировал заявку не верно. Поэтому диспетчер корректировал заявку.
2.    Иногда одна заявка, например «создание учетной записи», трансформировалась в несколько заявок, формирующих типовой набор прав;
3.    Банальная фильтрация «мертвых душ» и грубых ошибок заполнения.
До сих пор в электронных заявках пишется фраза "Предлагаем согласовывать заявки на предоставление доступа к информационным  ресурсам в электронном виде..."
Примерно через пол года был сформирован и заморожен актуальный список информационных ресурсов. Пользователям, сначала было рекомендовано, оформить заявку на создание информационного ресурса, с определением его параметров (опять через веб-форму). После пары недель ожидания и напоминаний, заявки на ресурсы не созданные должным образом перестали приниматься. После чего постепенно были решены все вопросы даже по ресурсам, от администрирования которых все отказывались.
Последним «усовершенствованием» оказалась заявка на блокировку учетной записи. Эта заявка должна использоваться при увольнении или переводе сотрудников. Сейчас, когда мы получаем заявку на создание учетной записи, мы просим указывать в цели подключения ФИО сотрудника, вместо которого нанят новый. Это помогло за последний год эффективно проработать механизм блокировки увольняющихся или переводящихся.

Что мы имеем в результате:
1.    все заявки за последние 4 года, с возможностью поиска и фильтрации;
2.    возможность выдать новому сотруднику все права, которые имел его предшественник;
3.    возможность выдать ИТ менеджеру все заявки оформленные сотрудниками его предприятия;
4.    актуальный, автоматически поддерживаемый, перечень информационных ресурсов;
5.    удовлетворение от проделанной работы.
Что омрачает радость:
1.    риск подделки заявок – увы, заявку может заполнить кто угодно и за кого угодно. От этого пока спасает достаточно длинная (не менее 3-х человек) цепочка согласования;
2.    риск невозможности использования заявок в случае необходимости обращения в суд;
3.    периодические попытки запустить систему, разработанную уважаемой компанией систему.

В данный момент назрела необходимость создания IDM для автоматизации части базовых функций по предоставлению прав. Об этом уже писал . Механизм реализации пока не прозрачен, поэтому откладывается. Заказывать новую систему, не вижу смысла, тк "молоко еще не остыло". Писать столь сложную систему самостоятельно - нет времени и желания. Может космический разум подскажет достойное решение?
Alt text

Не ждите, пока хакеры вас взломают - подпишитесь на наш канал и станьте неприступной крепостью!

Подписаться

Сергей Солдатов

REPLY-TO-ALL is a double language blog (English/Russian) run by three information security practitioners. Want to discuss information security problems? This is the place.