 |
|
|
|
Они увольняются, а с «учетными записями» разбираться нам!
Они увольняются, Увольнение сотрудника для ИТ-службы – рутинная процедура, но регулярно что-нибудь важное забывается, оставляя брешь в системе безопасности Наступило время прощаться Вполне логично, что уволенный сотрудник уже не должен иметь доступа к информации на прежнем месте работы. Неотключенная учетная запись в любой из систем – это открытые ворота в вашу ИТ-инфраструктуру с надписью «Добро пожаловать», даже если с сотрудником расстались на положительной ноте. Увольнение сотрудника для ИТ по логике должно быть обычной и отлаженной рутинной операцией. Но такие события не случаются каждый день, и системные администраторы обычно не выделяют время на их регламентирование. Обязанность упорядочивания процесса должна ложиться на плечи ИТ-руководителя. А вот волшебная кнопка «Отключить учетные записи во всех системах» остается несбыточной мечтой для любого ИТ-специалиста. СЭД, CRM, VPN-доступы и ключи, адреса электронной почты и логины, выданные пользователю к различным, не связанным между собой системам, – вот неполный список мест, где пользователи имеют аккаунты. Выяснив, что существует необозримое море неотключенных учетных записей давно уволенных сотрудников, очень велик соблазн обозвать подчиненных саботажниками и начать махать саблей над головой. Призывать одуматься и как-то самоорганизоваться, почувствовать брешь в нашей безопасности. Ну и дать задачу срочно навести порядок везде, а самому спрятаться за большим монитором, чтобы не видеть взглядов коллег, которые пытаются понять, какая муха укусила их начальника. Вроде навести порядок несложно, но как поддерживать приемлемый уровень порядка на постоянной основе? Удалить нельзя сохранять Практика показывает, что запятая ставится после второго слова. Удаленные пользователи перемещаются в специальные папки уволенных сотрудников, где и хранятся достаточно долго. А еще удалять из многих систем учетные записи нельзя по причине технических ограничений или же бизнес-потребностей. Можно привести такой пример. Сотрудник за время работы обрастает контактами, и просто так удалить его вместе с почтой и почтовым адресом уже невозможно. По старой памяти контрагенты могут отправить сообщение по уже устаревшему адресу, а терять «важное письмо» не хотелось бы. В СЭД и других учетных системах документы или заказы привязываются к учетной записи. Чаще всего системный администратор, заблокировав учетную запись в Active Directory, начинает судорожно вспоминать, где еще есть записи и что надо заблокировать. Понятное дело, что не хотелось бы мириться с таким положением вещей в подразделении. При этом необходимо учитывать, что даже при наличии документа, описывающего где и что блокировать, выполнение его требований может не случиться вовсе. Как ни прискорбно, законы Мерфи работают, и скорее всего обходной лист подпишет тот, кто непосредственно выключать учетные записи не будет. Оставлять все в таком виде для руководителя, разумеется, неправильно, и требуется подстроить под себя процесс таким образом, чтобы все операции выполнялись без лишних напоминаний и имелась возможность осуществлять контроль. Последовательность – залог результативности При создании документа, требующего изменения бизнес-процесса, я следую такому рецепту: Детальный анализ бизнес-процесса как есть. Тут мои инструменты – ручка и блокнот, а также навыки общения и отношения с коллегами. Лучше начинать изучение с истоков процесса и инициирующих документов, если таковые есть. По результатам интервьюирования и наблюдения складывается общая картина выполняемых действий, и уже можно переходить на следующий этап. Поиск первопричины неэффективности или замена неправильных операций. Чаще всего несовершенство видно сразу, но иногда приходится обсудить несколько вариантов, прежде чем найти приемлемый. Тут даже без документарного закрепления действий можно попытаться выполнить процесс по обновленной схеме и убедиться в том, что изменения приводят к качественному улучшению. Главное, чтобы все задействованные лица видели смысл в выполняемых действиях и были заинтересованы в улучшениях. Создание регламентирующего документа. Оформление на бумаге документа, когда все стало понятно, уже не составляет большого труда. В нашем случае создаваемый регламент призван описать все необходимые действия ответственных лиц, связанных с процессом отключения или удаления, заведенных в ИС учетных записей для увольняющихся сотрудников. Главное – вдумчиво подобрать формулировки и подробно все расписать. Одним из элементов нового документа должен быть словарик с разъяснениями для сокращений, используемых в документе. Лучше всего вынести его в самое начало. Создаваемый документ лучше всего разбить на две части. В первой, текстовой, описываются подробно задействованные системы и выполняемые в них исполнителями действия. Вторая часть – это таблица, в которой приводится так называемый чек-лист. Она очень полезна при выполнении требований регламента. Таблица просто распечатывается, а в специальном поле исполнитель ставит отметку, выполнив очередной этап. Так можно избавиться от спешки и вероятности, если отвлекут текучкой, не вернуться к выполнению следующих пунктов. Ремоделирование процесса Самое логичное – проследить бизнес-процесс от самых истоков и пошагово изучить его. В нашем случае обходной лист – это обычный лист бумаги, который мимолетно появляется в ИТ-отделе и окончательно оседает в архивах бухгалтерии или отдела кадров при обмене на трудовую книжку. Подписавший его сотрудник ИТ-отдела может на самом деле ни за что не отвечать и никому не передавать информацию о увольнении сотрудника. Даже если правильно и вовремя подписан обходной лист, заблокировать по факту все учетные записи сразу нельзя, так как рабочий день не закончился и сотрудник будет продолжать работать еще несколько часов. Вывод такой – он не может быть документом, запускающим процессы отключения и удаления пользователей. Отправной точкой должно стать что-то другое. Проблема описанной ситуации заключается в том, что на какой-то момент времени в различных ИТ-системах оказывается непонятное количество различных неактуальных учетных записей, в том числе и тестовых, служебных. Вычистка и актуализация систем занимает много ресурсов – временных и человеческих. При этом через небольшое количество времени ситуация повторяется. В моей случае первыми об уходе сотрудника узнавали в кадровой службе, выписывали ему обходной лист и оправляли в путешествие по отделам. Как говорилось выше, обходной лист информационных следов в ИТ-подразделении не оставлял. Да и по времени разнился с вытекающими из него для нас действиями. Мне достаточно было попросить, чтобы, помимо бумаги, выдаваемой только сотруднику, формировалась заявка на отключение «логинов-паролей» с указанием даты и времени, когда необходимо провести блокировку. Она должна попадать в систему учета заявок пользователей, что позволяло прикрепить к ней конкретного исполнителя в ИТ-подразделении. Таким образом, происходило разделение на невзаимосвязанные процессы – обходной лист отдельно, работа с учетными записями отдельно. С точки зрения исполнения процесс свели к тому, что все операции производятся теперь только одним лицом в рамках контролируемого департаментом ИТ периметра. Это, конечно, потребовало обучения сотрудников работе с различными информационными системами, но и принесло свои плоды. Четкий контроль и выполнение всех технологических операций без делегирования их кому-то еще, где могут не сделать или забыть. А еще этот же сотрудник осуществляет контроль исполнения требований регламента для второстепенных учетных записей вне наших систем. До этого никто ни за что не отвечал, каждый ответственный за информационную систему блокировал пользователей так, как считал нужным, ведь все в отделе происходило «неформально», и виноватых найти не удавалось. Проверяем и в бой Прежде чем вводить в действие документ, он несколько раз откатывается на тестовой среде. Если все, что мы напридумывали, может оказаться не настолько правильным или поступившей информации для исполнителя может быть не достаточно, то сразу становится понятным, какие компетенции исполнителя задействованы и имеют адекватный уровень знаний, а каким еще предстоит научиться. Ну и даже после такого действия все равно возникло несколько интересных особенностей. Например, первоначально не учли, что если не очистить у заблокированной учетной записи в Active Directory поле «Руководитель», то уволенный пользователь будет все еще виден на портале на базе ShareРoint. После проверки документа необходимо довести до сведения его требования для всех участвующих лиц и дату, с которой необходимо осуществлять описываемое в нем. Право отказать Для того чтобы регламенты работали, важно было наделить подчиненных властью. И эту власть необходимо документально зафиксировать в приказах и распоряжениях высшего руководства. В данной ситуации было четко указано, что, если нет «заявки из кадров», обходной лист не подписывать, увольняющегося сотрудника с ним отправить обратно в кадры. Саму заявку могут видеть все в ИТ-подразделении, и подписать обходной лист может любой присутствующий сотрудник, так как сам по себе этот документ не требует выполнения дополнительных действий с учетными записями. Но информация об увольнении сотрудника все-таки должна поступить в ИТ-подразделение и быть исполнена. Постоянная тяга к совершенству Даже самый лучший регламент можно улучшить. Придуманные нами процессы надо регулярно пересматривать и искать оптимальный вариант. А еще – все течет и меняется. Поэтому на регулярной основе имеет смысл время от времени опрашивать исполнителей, все ли им понятно. Все ли пункты выполняются, или какая-либо из систем уже больше не используется, или появилась новая, где тоже требуется производить блокировки? Так регламент остается живым и рабочим документом, максимально соответствуя реалиям. *** Первоначально поставленная цель – сделать процесс управляемым и контролируемым, была достигнута. Фразы «Не знаю, почему», «Нам никто не сообщил об увольнении…» ушли в прошлое. Все стало прозрачнее, и ИТ-специалисты и другие отделы начали играть по правилам, которые документально закреплены. Все спорные вопросы решаются «языком документов», а не «по понятиям». Руководителю отводится простая задача – с некой периодичностью получать на руки общий список уволенных и делать выборочный контроль, чтобы убедиться, что улучшенный процесс и написанный регламент эффективно работают. |
СЕРГЕЙ БАРАМБА, ООО «БФТ», начальник отдела системных решений Департамента ИТ, Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
