Управление и безопасность изменений при аутсорсинге

Управлять – это значит вести предприятие к его цели,
извлекая максимум возможностей из имеющихся ресурсов.
А. Файоль

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

Аутсорсинг (out – внешний, source – источник) – способ оптимизации деятельности предприятий за счет сосредоточения усилий на основном предмете деятельности и передачи непрофильных функций и корпоративных ролей внешним специализированным компаниям.

Не все так просто

Однако часто при аутсорсинге гармонии в отношениях достичь не удается.

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

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

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

Как следствие всех этих проблем:

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

Теоретическое решение

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

• формализации процессов создания и накопления заявок на изменения и разработке регламента их обращения в организации (формализация общения);
• сопоставлении требований функциональных подразделений с понятиями и терминами ИТ-специалистов (унификация общения);
• контроле корректности всех изменений в настройках информационной системы.

Процедура первая – формализация

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

Процедура вторая – унификация

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

Организовать такое понимание можно в два этапа. Во-первых, для этого используется формализованный язык электронных заявок, требования в которых сформулированы в терминах, понятных не связанному с ИТ сотруднику (например, “предоставить доступ/лишить доступа к информации”). Правда, для формализации заявок необходимо провести немалую работу: выявить все значимые ресурсы информационной системы и присвоить им однозначные, но понятные имена.

Второй этап – перевод требований в предметную область ИТ-специалиста. Эта задача ничуть не легче, но она тоже решаема. Зная, что скрывается за приведенным в примере понятием “система управления проектами”, мы можем понять, что для доступа к ней сотрудника требуется:

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

Вот так формализованная заявка может стать однозначно интерпретируемой инструкцией для администратора.

Процедура третья – контроль

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

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

О чем не стоит забывать

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

Кроме того, надо понимать, кому делегируются права на внесение заявок на управление изменениями в ИС. Не всегда оказывается возможным возложить это на начальника подразделения или его заместителя – им может быть просто не до того. Но если пользователям разрешается самим составлять подобные заявки, то, прежде чем поступить на согласование к ответственным лицам, заявка должна быть утверждена непосредственным руководителем сотрудника. Его утверждение будет гарантировать, что этот доступ – действительно служебная необходимость, а не просто прихоть сотрудника.

Практическая реализация

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

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

Агенты системы отслеживают все происходящие в информационной системе
изменения.

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

Ограничения

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

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

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

Однако администраторы, особенно если речь идет о внешних администраторах, обычно начинают управлять именно индивидуальным доступом сотрудников к ресурсам ИС. Сильнее всего это проявляется, когда речь заходит о каких-то особых правах конкретного сотрудника. Дело в том, что в такой ситуации значительно проще дать именно этому сотруднику дополнительные права, чем создавать “вырожденную” группу, включив в нее лишь одну учетную запись. Кроме того, это самый простой способ исполнить пожелание, выраженное в заявке.

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

Начинать формализовать процессы управления информационной системой можно в принципе и до принятия “типизированного” подхода, но удобства управления для функциональных подразделений это сводит на нет. Сравним для примера две гипотетические заявки, соответствующие разным подходам. В первом случае (типизированный доступ): “прошу предоставить Иванову права на доступ в соответствии с должностными обязанностями руководителя группы А”. Во втором – набор заявок: “Прошу предоставить Иванову права на доступ к файловому серверу группы A”, “… права на работу с корпоративным электронным почтовым ящиком” и т. д., и т. п. Инструкции же и в том и в другом случае будут одинаковыми.

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

Итоги

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

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