Конфликты и саботаж системных администраторов

Конфликты и саботаж системных администраторов

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

 

 

 

1. Введение

2. Бесконтрольность администраторов чревата авариями и саботажем

3. В случае аварии быстрый анализ всех журналов затруднен

4. Заключение

 

 

Введение

Роль системного администратора в информационной системе переоценить сложно — он царь и бог. Однако, бывает, ошибается, как и все люди. Чем опасна ситуация, когда администратор не очень хорошо исполняет свои обязанности, мы уже неоднократно писали (например, в обзоре Аудит действий ИТ-департамента при помощи Wallix AdminBastion).

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

 

Бесконтрольность администраторов чревата авариями и саботажем

Мы разберем случай, о котором рассказал нам технический эксперт компании «АйТи Бастион» Дмитрий Михеев. В одной крупной компании было три службы технической поддержки, расположенных в разных часовых поясах. Они могли работать в разное время, но «режимы» их пересекались — в этом случае было сложно определить, кто именно из администраторов что и когда сделал. Иногда они могли параллельно взяться за реализацию задач, например обновлять программное обеспечение, и только потом обнаружить, что эту задачу в то же самое время делает другая группа.

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

Хотя иногда у администраторов из нашей истории и случались накладки, но аварий не было. Проблемы начались в тот момент, когда в такое совместное управление была передана сложная система — SAP на базе БД Oracle. Обнаружилось, что в этой системе повторное выполнение задач, которое иногда случается при параллельном администрировании, может привести к непредсказуемым результатам. Выяснилось это в самый неподходящий момент — произошел сбой базы данных. Причем восстановление из резервной копии устранить проблему не помогло — система перешла в некорректное состояние, разобраться в котором в короткий срок не удалось. В момент возникновения проблемы администрированием базы данных и системы занимались несколько человек из разных команд, и оказалось непросто установить, какие именно действия привели к падению приложения, в каких системах возникло противоречие и какие данные являются правильными, а какие нужно исправлять. В результате на устранение ошибки потребовались много времени, и ущерб от простоя оказался значительным. 

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

 

В случае аварии быстрый анализ всех журналов затруднен

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

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

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

В частности, решения подобного типа разрабатывает компания Wallix. Она предлагает специальные устройства, которые перехватывают сетевые сессии удаленного управления и записывают их в собственную память для последующего анализа. При этом фиксируются не только текстовые протоколы удаленного управления, такие, как telnet или SSH, но и графические — RDP, VNC. Более подробно функции данного устройства можно посмотреть в Обзоре Wallix AdminBastion 4.1. В результате у администраторов появляется возможность зафиксировать все параллельные сеансы администрирования и восстановить действия коллег, найти в них ошибки и исправить. Фактически подобная система является своеобразной защитой от ошибок, которые при необходимости можно быстро обнаружить и исправить.

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

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

 

Заключение

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

Подпишитесь
в Facebook

Я уже с вами
Telegram AMПодписывайтесь на канал "Anti-Malware" в Telegram, чтобы первыми узнавать о новостях и эксклюзивных материалах по информационной безопасности.

RSS: Новые статьи на Anti-Malware.ru