Автор: Александр Колодяжный, руководитель проекта, отдел ИТ-аудита, блок внутреннего аудита, ПАО «МТС», член Ассоциации «Институт внутренних аудиторов»1
1. Введение
В данной статье мы рассмотрим описание и оценку контролей, реализуемых для базовых процессов эксплуатации ИТ-инфраструктуры (далее – ИТ). Обращаю внимание, что перечень описанных ниже процессов не является полным, это лишь базовые процессы, с которых можно начать ИТ-аудит эксплуатации инфраструктуры предприятия.
Расширенный список ИТ-процессов можно сформировать, например, на основании практик ITIL2/ ITSM3.
К базовым процессам относятся:
-
дублирование ключевых ИТ-модулей предприятия;
-
резервное копирование ключевых ИТ-модулей предприятия;
-
мониторинг ИТ- и ИБ-метрик (смежный процесс: в зависимости от настроек удовлетворяет потребности ИТ и ИБ).
Процессы удобно масштабируются как на уровень всего предприятия, так и на уровень отдельной информационной системы (далее – ИС), контроли, описанные ниже, актуальны на всех уровнях. В статье проведен анализ и оценка контролей в масштабе предприятия.
2. Процесс дублирования (обеспечение отказоустойчивости) ключевых ИТ-модулей
К ключевым ИТ-модулям предприятия можно отнести серверы, базы данных, сетевое оборудование, а также иное оборудование и сервисы, выход из строя которых приведет к недоступности предоставляемых ИТ-услуг на предприятии.
Цель указанного процесса – исключение риска недоступности сервисов и информационных систем предприятия в результате возникновения нештатной ситуации.
Для минимизации указанного риска необходим контроль наличия дублирующего компонента ключевых ИТ-модулей предприятия.
Показателем качественно реализованного процесса является отсутствие на предприятии ключевых ИТ-модулей без соответствующего дублирующего компонента.
Показателем НЕкачественно реализованного процесса является обнаружение хотя бы одного ключевого ИТ-модуля без соответствующего дублирующего компонента.
Агрессивность метрики показателя качества контроля (обнаружение хотя бы одного ключевого ИТ-модуля без соответствующего дублирующего компонента) обусловлена архитектурой ИТ. Как правило, ключевые ИТ-модули являются частью взаимосвязанного комплекса технических средств (далее – КТС), например, ИС. В случае выхода из строя одного из ключевых модулей (например, сервера приложений, СУБД4, сетевого оборудования) недоступным окажется весь КТС (информационная система).
Оценить качество реализации процесса можно на основании анализа архитектуры дублирования ключевых ИТ-модулей предприятия. В качестве примера возьмем ИС, состоящую из сервера приложений и сервера СУБД. Необходимо проанализировать технологию, обеспечивающую дублирование на уровне сервера приложений и на уровне сервера СУБД. Ключевым показателем в описанном примере будет наличие/ отсутствие дублирующих компонентов для сервера приложений, сервера СУБД, а также данных сервера СУБД, на которые перейдет вся нагрузка в случае возникновения нештатной ситуации на основных компонентах.
Личный опыт и подводные камни:
В качестве источника данных для проведения анализа архитектуры дублирования ключевых ИТ-модулей необходимо использовать документацию КТС (например, схему реализации). Ускорить процесс изучения поможет интервью с архитектором, владельцем, администратором КТС. Также рекомендуется изучить инциденты, связанные с недоступностью КТС в прошлом на предмет причины некорректной отработки системы дублирования ключевых ИТ-модулей.
Одной из распространенных ошибок, допускаемых при оценке качества реализации процесса, является поверхностный анализ процесса из-за непонимания архитектуры КТС. На примере ИС, описанной выше (сервер приложений / сервер СУБД), могут быть реализованы дублирующие компоненты на уровне сервера приложений и на уровне сервера СУБД, но на уровне данных дублирование может отсутствовать. Подробности на схеме ниже:
На схеме 1 серверу 1 присвоен статус «дублирование обеспечено». Указанная оценка будет некорректной поскольку данные не дублируются. В случае возникновения нештатной ситуации вся нагрузка перейдет на дублирующий сервер с развернутой на нем СУБД, но данных в СУБД не будет, а, следовательно, работоспособность ИС восстановлена не будет. Корректная оценка статуса дублирования сформирована на схеме 2: серверу 2 «дублирование НЕ обеспечено».
3. Процесс резервного копирования ключевых ИТ-модулей
Резервное копирование ключевых ИТ-модулей (далее – РК) предприятия необходимо на случай, если нештатная ситуация все-таки произошла, и все реализованные процессы ИБ и ИТ, направленные на обеспечение непрерывности предоставляемых ИТ-услуг предприятия, сработали некорректно или не сработали вовсе.
Цель указанного процесса – исключение риска потери данных информационных систем предприятия в результате возникновения нештатной ситуации на ключевых ИТ-модулях и дублирующих компонентах.
Рассмотрим контроль, реализация которого необходима для минимизации указанного риска в рамках процесса резервного копирования ключевых ИТ-модулей:
-
контроль наличия резервных копий ключевых ИТ-модулей предприятия;
-
возможность восстановить работоспособность на момент времени, указанный владельцем КТС (ИС).
Показателем качественно реализованного процесса является наличие резервных копий для всех ключевых ИТ-модулей предприятия, обеспечивающих возможность восстановления работоспособности на момент времени, указанный владельцем КТС (ИС).
Показателем НЕкачественно реализованного контроля является отсутствие резервных копий хотя бы для одного ключевого ИТ-модуля предприятия, а также отсутствие возможности восстановления работоспособности на момент времени, указанный владельцем КТС (ИС).
Агрессивность метрики показателя качества контроля обусловлена архитектурой ИТ. Если для восстановления работоспособности вам потребовались файлы резервного копирования, значит, все остальные инструменты поддержания работоспособности не выполнили свою функцию должным образом и резервная копия является последней возможностью восстановить работоспособность ИТ-услуги.
Оценить качество реализации процесса можно на основании анализа схемы РК ключевых ИТ-модулей предприятия. В качестве примера возьмем информационную систему, состоящую из двух серверов: сервера приложений и сервера СУБД. Необходимо проанализировать схему РК указанной ИС. Ключевым показателем в описанном примере будет наличие/ отсутствие резервных копий, необходимых для восстановления работоспособности ИТ-модулей на момент времени, указанный владельцем КТС (информационной системы), в случае возникновения нештатной ситуации.
Личный опыт и подводные камни:
В качестве источника данных для проведения анализа схемы РК ключевых ИТ-модулей можно использовать документацию по КТС, а также интервью с владельцем, архитектором, администратором КТС.
Одной из распространенных ошибок, допускаемых при оценке качества реализации процесса, является отказ от обсуждения схемы РК с владельцем КТС (ИС). Владелец, как правило, не посвящен в тонкости процесса РК (для него есть два статуса реализации процесса РК: процесс реализован или процесс не реализован), он может уточнить свое видение процессов, пояснить: какая часть данных, обрабатываемых в КТС, является критичной, сколько времени может быть недоступен КТС при восстановлении данных из резервной копии, данные за какой период могут быть потеряны без существенной деградации сервиса. При этом даже в случае реализованного процесса РК нужно понимать, что если процесс резервного копирования запускается один раз в сутки в 02.00, то в случае аварии в 01.59 будет потерян прогресс всех обработанных данных за последние 23 часа 59 минут. Подробнее на схеме ниже:
Для построения корректной системы резервного копирования необходимо уточнить у владельца КТС, какой прогресс обработанных данных он готов безвозвратно потерять при аварии (24 часа, 1 час, 5 минут, вообще не готов терять информацию). На основании ответа владельца КТС разрабатывается и внедряется РК КТС (информационной системы).
4. Процесс мониторинга ИТ- и ИБ-метрик
Грамотно настроенный процесс мониторинга позволяет реализовать превентивные меры по предотвращению аварийных ситуаций и инцидентов ИБ, приводящих к недоступности предоставляемых ИТ-услуг на предприятии.
Цель указанного процесса – исключение следующих рисков:
-
недоступность сервисов и информационных систем предприятия в результате возникновения нештатной ситуации за-за отсутствия оперативного реагирования;
-
компрометация данных предприятия в результате отсутствия оперативного реагирования.
Показателем качественно реализованного процесса является наличие разработанных и обновляемых метрик ИТ и ИБ, поставленных на мониторинг.
Показателем НЕкачественно реализованного процесса является отсутствие мониторинга разработанных и обновляемых метрик ИТ и ИБ.
Оценить качество реализации процесса можно на основании анализа метрик, разработанных для ИТ и ИБ. Необходимо провести анализ процесса формирования и актуализации метрик. Ключевым показателем для оценки качества реализации процесса будет наличие метрик, сформированных для ИТ и ИБ, а также периодическая актуализация сформированных метрик.
Личный опыт и подводные камни:
Как правило, разрабатывается общий (базовый) набор метрик ИТ (например, доступности, свободных ресурсов оборудования, работоспособности) и метрик ИБ (например, попытки подключения к ресурсу неавторизованных пользователей, попытки скачать из информационной системы информацию ограниченного доступа, количество попыток ввода неверного пароля). В случае необходимости для отдельной ИС могут быть разработаны дополнительные индивидуальные метрики ИТ и ИБ. Необходимо проверить наличие и процесс актуализации вышеописанных метрик.
Одной из распространенных ошибок, допускаемых при оценке качества реализации процесса, является отказ от обсуждения метрик с владельцем КТС. Кроме реализованных базовых метрик необходимо уточнить у владельца, что он считает существенным в своем КТС. Например, владелец КТС может указать на определенные таблицы в СУБД, содержащие критически важную информацию, обращения к которым должны быть поставлены на мониторинг.
Также рекомендуется изучить инциденты, связанные с недоступностью КТС в прошлом, на предмет реализации метрик, позволяющих применять превентивные меры по предотвращению похожих инцидентов в будущем.
5. Вывод
В статье намеренно не используются сложные технические описания и формулировки. Пусть вас не смущает простота изложенного материала, т.к. пренебрежение значимостью указанных процессов может привести к необратимым последствиям.
Кейсы эксплуатации ИТ-инфраструктуры, описанные в статье, приводят к временной недоступности сервисов предприятия, а в некоторых случаях – к невозможности восстановить работоспособность ИТ-услуги полностью. Также в случае некорректной реализации указанных процессов велика вероятность потери данных ИС предприятия.