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

Потребности бизнеса

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

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

Объекты мониторинга

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

ИС решают следующие задачи:

• автоматизация бизнес-процессов – от обработки данных до управления производством;
• организация информационного взаимодействия между подразделениями и;
• обработка и анализ информации.

Система мониторинга ИС обязана отслеживать заданные параметры работы ее компонентов, выявлять неполадки и предлагать решения по их исправлению.

В ее задачи системы мониторинга входит:

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

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

Среди основных технических и организационных целей:

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

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

Для небольших компаний задача мониторинга ИС в локальной сети решается проще за счет меньшего количества объектов администрирования и наличия возможности воспользоваться облачными предложениями вместо дорогостоящей разработки собственной модели.

«Облако» или самостоятельная разработка

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

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

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

Преимущества облачной модели:

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

Минусы:

• низкая пропускная способность, провайдеры услуг редко могут обслужить более 300-400 серверов;
• открытый код и передача информации третьим лицам становятся серьезным риском, IТ-инфраструктура может стать доступной для хакеров.

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

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

Как создать свою систему

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

В противном случае возникают риски:

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

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

Регламент взаимоотношений

В организации в роли заказчика чаще выступает не владелец информационного ресурса в целом, а уполномоченное лицо, например, IТ-подразделение или ответственный сотрудник. После этого цепочка взаимодействий выглядит так: владелец – заказчик – подрядчик.

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

В регламенте согласовываются:

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

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

В ТЗ включают следующие разделы:

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

Исполнение заявки проходит в несколько этапов:

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

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

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

03.12.2019