Thursday, March 15, 2012

IDM or not IDM

Не говорите, что эфир не существует! Только начал упорядочивать на бумаге порядок оформления заявок на доступ к информационным ресурсам, как Сергей затрагивает тему IDM!

Когда пришел на нынешнее рабочее место 3 года назад, здесь для согласования доступа к информационным ресурсам во всю использовались бумажные заявки. Заявки согласовывались около недели, терялись и не поддавались учету.

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

Следующим этапом перестали согласовывать заявки для ресурсов, которые не прошли процедуру регистрации (на которые не оформлена заявка на создание ресурса и не определен бизнесадминистратор).

Затем попытались категорировать ресурсы. Пара недель работы с администраторами толку не дали - результаты валяются в виде файла и не находят применения в реальной жизни (об этом нужно писать отдельно).

Потом появились заявки на блокировку учетных записей. Сделали их для борьбы с мертвыми душами. Но такой способ блокировки не был принят пользователями.

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

Что имеем сейчас:

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

А теперь давайте посмотрим, как мы подвержены рискам указанным тут:

  • Предоставление группой эксплуатации (ИТ) доступа, отличного от согласованного - какая ни была бы ИС - с IDM или без него, администратор всегда сможет дать доступ по высшему повелению или внутреннему позыву.
  • Предоставление доступа на основании «некорректного» согласования (доступ не согласован в установленном порядке) - ну для этого мы имеем историю заявок для определенной позиции. Кстати говоря, нельзя не упомнить здесь следующее - 90% сотрудников пишут заявку на доступ в Интернет, к внешней электронной почте и сменным носителям. Рассматривать все эти заявки - долго, поэтому на первую заявку мы с вероятностью 98% отвечаем отказом. Если человеку действительно надо - он упорствует и получает доступ. Вот такой фильтр.
  • Риски, связанные с использованием Избирательной модели управления доступом - решаем на коленке, через просмотр истории заявок для новых сотрудников
  • невозможность выявления некорректных прав пользователей - центральный сервер syslog собирает и хранит записи об изменениях в структуре АД, планируем делать ежедневный diff для АД и максимально автоматизировано сравнивать его с табличкой в шарепоинте
  • устаревание прав ввиду изменения бизнес-процессов Компании - почему мне не верится, что IDM может помочь "бороться" с любовью людей "переставлять мебель" спонтанно и быстро
  • некорректное совмещение критичных полномочий в информационных системах - но ведь мы не военное ведомство. У нас по сути групп доступа 2 - сотрудники имеющие доступ к коммерческой тайне и сотрудники не имеющие к тайне доступа... Неужели без IDM-ма не справимся с этими 2-мя группами?
  • избыточные полномочия пользователей в случае изменения их статуса в бизнес-процессах Компании - а вот этому посвятим следующий пост.

Что мы видим? Наняв человечка с минимальной квалификацией и хорошими штанами, выплачивая ему 7-15 т.р. в месяц мы можем получить естественно-интеллектуальную систему управления учетными записями. С больничными и отпуском есть проблема, но размер зарплаты позволяет нам организовать холодный или даже горячий резерв!

No comments: