Управлять ИТ‑инфраструктурой — сложно. Всегда есть фактор, который опасно не учесть. Не сделали резервные копии, администратор выполнил не ту команду (намеренно или случайно) — и масштабы аварии вырастают из небольшого огонька в пожар.

Для наглядности сравним ИТ‑инфраструктуру с историей из фильма «Парк Юрского Периода». Началось с вдохновляющей идеи — построить тематический парк с динозаврами, которых оживляют с помощью клонирования. Однако сбой в системе безопасности привел к хаосу и борьбе за выживание среди посетителей и динозавров. Возможно ли было предотвратить сбой и не подвергать жизни людей опасности? Безусловно, но по разным причинам (от беспечности руководства до жадности персонажа) катастрофа все‑таки случилась. В повседневной жизни риски аварий растут каждый день из‑за разных факторов. В таких условиях обеспечить бесперебойную работу ИТ‑инфраструктуры так же сложно и рискованно, как и управлять парком с динозаврами.

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

Планирование всему голова

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

В российских компаниях редко создают операционные отделы, в которых регулярно обновляются инструкции, закреплены обязанности сотрудников. Как правило, системные администраторы пытаются разобраться с потоком заявок и задач, а времени на систематизацию работы не остается. В итоге без системы и планов работаем от аварии к аварии. И никто конкретно не занимается этим вопросом. Поэтому, когда возникает проблема, все начинают метаться, в спешке пытаясь ее решить. Хотя можно было бы заранее, еще на этапе планирования ИТ-инфраструктуры задуматься: «Что делать, если случится авария?». И по этой теме у нас есть истории из практики.

Кейс №1

К нам обратилась региональная компания для проектирования системы планирования ресурсов (ERP). Компания вложила много времени и денег в выбор системы, оборудования. Нашей основной задачей было спланировать отказоустойчивую систему. Также требовалось кластеризовать СУБД, и при этом распределить хосты по разным дата-центрам для обеспечения катастрофоустойчивости.

Мы разработали отказоустойчивую архитектуру системы. Чтобы организация не потеряла данные и продолжала работать, архитектуру построили следующим образом: географически распределенный кластер серверов в случае аварии и выхода из строя одной ноды сервера (server node) автоматически и оперативно может переключить на другую. Архитектура также предполагала, что в целях обеспечения сохранности данных необходимо построить смежную систему резервного копирования.

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

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

Второй сервер в кластере автоматическим образом увидел, что сосед не отвечает, и несколько раз пробовал обратиться к нему, но безрезультатно. Кластерный арбитр решил, что основной узел вышел из строя. Запустил необходимые процессы, обнаружил незавершённую транзакцию, начал откатывать её назад. И в момент отката он израсходовал, в свою очередь, всю свою память. В этот момент снова заработал первый. Качели продолжались некоторое время, пока администраторы не обнаружили, что кластер встал. В итоге, когда сотрудник вернулся с перерыва, данные в СУБД было уже не восстановить. А системы резервного копирования, как вы помните, не было. Соответственно восстановить данные было невозможно, и пришлось начинать все почти с самого начала.

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

Кейс №2

За консультацией к нам обратился крупный заказчик в строительной отрасли (который активно работает по всей России). В ИТ-систему застройщика проник вирус-шифровальщик, парализуя весь функционал. О заражении вирусом узнали только тогда, когда он уже везде просочился. В одно не очень прекрасное воскресное утро, вирус уничтожил всё, что было связано с бекапами. Когда сотрудники пришли на рабочее место, на экранах компьютеров было сообщение в духе «переведите биткоины по такому-то адресу, может быть, мы вам поможем».

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

Как одно решение может перевернуть все

В «Парке Юрского Периода» ошибка (намеренное действие сотрудника) привело к катастрофическим последствиям. Эти же правила действуют и в ИТ-управлении: одно недоразумение или неправильно принятое решение может разрушить всю систему. Расскажем про подобные случаи из своего опыта.

Кейс №3

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

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

Когда мы начали работу, злоумышленники уже украли базу данных Active Directory с информацией об учетных записях и пользователях. Вирус также заразил сервера SAP. Из-за этого, как мы предполагаем, могли быть извлечены финансовые данные организации. Всего были поражены двадцать четыре сервера, причём вирус распространялся очень интересно – один из его модулей считывал то, что пользователь набирает на клавиатуре и фиксировал, чтобы далее использовать данные в своих целях.

Кейс №4

Банк среднего сегмента обратился за помощью к нашей команде, когда его почтовая инфраструктура была полностью уничтожена. Заказчик знал, кто это сделал (один из его сотрудников, которого недавно приняли на работу). Первый вопрос, который нам задали: «человек просто сглупил или причинил вред осознанно?». Мы установили, что молодой сотрудник случайно уничтожил всю почту банка, не осознавая последствий своих действий.

Как это было: в региональном отделении банка проводили замену оборудования. Новому сотруднику поручили вывести из эксплуатации старый почтовый сервер. Не имея опыта в подобных операциях, сотрудник выбрал неверную команду на PowerShell, предназначенную для удаления последнего почтового сервера в инфраструктуре организации (вместо конкретного сервера). Естественно, его прав доступа не хватило. Молодой специалист оказался пытливым и, поискав по «окрестностям», нашел учетные данные администратора в открытом текстовом файле. Логин и пароль оставили инженеры после другого проекта. Причем данная учетная запись имела максимальный приоритет внутри инфраструктуры (Enterprise-администратор).

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

Нас попросили решить эту проблему. Мы около двух недель поднимали новые почтовые сервера и восстанавливали данные, которые собирали из обрывков (выяснилось также, что практически не было резервных копий).

Кейс №5

К нам обратилась крупная торговая компания России. Так или иначе, каждый из нас хотя бы раз заходил в магазины этого заказчика. В компании перестали работать диски под корпоративным хранилищем данных. Объем хранилища – около 130 терабайт, в котором были все данные за много лет работы этого заказчика. Первый вопрос, который мы задали: «Есть ли у вас резервная копия?». И угадайте с первого раза, какой ответ мы получили? Верно, что резервных копий нет (как нет и процесса, ответственных). Руководство компании полностью полагалась на ИТ, ИТ посчитало, что оборудование настолько надежное и дорогое, что можно полностью расслабиться и не утруждать себя мыслями про резервные копии и т.д. Получилось, что систему ввели в эксплуатацию, она являлась критической для бизнеса (!), но фактически система существовала сама по себе . И, случился тот день, когда всё сломалось.

Мы посоветовали специализированные инструменты для восстановления данных. С их помощью ритейлеру удалось восстановить разметку хранилища: на каких дисках, и что хранилось. Это важно, потому что речь идет не просто об одном жестком диске, а о значительном объеме - целой «стопке». Используя результаты работы первой утилиты, при помощи второй утилиты они смогли восстановить сами данные. У истории получился счастливый финал, но, по факту, это прозвенел звоночек о том, что внутри компании есть огромные проблемы. Вероятно, что в нашем примере описан не частный случай, а общий подход, который может в любой момент поставить бизнес на грань катастрофы.

Кейс №6

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

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

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

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

Извечные вопросы: кто виноват и что делать?

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

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

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

3. Дешевле правильно спроектировать архитектуру системы на этапе планирования, чем вносить изменения после внедрения системы.

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

Что касается публичных кейсов. В 2023 году в результате масштабных утечек в банковской сфере были похищены личные данные огромного количества клиентов. В связи с этим в январе 2024 года Госдума приняла в первом чтении законопроект, который устанавливает оборотные штрафы за утечки персональных данных. Кроме того, Банк России планирует ввести личную ответственность топ-менеджеров банков, отвечающих за информационную безопасность, в случае утечек данных клиентов. В соответствии с пояснительной запиской к законопроекту, текущие меры несоразмерны последствиям от произошедших утечек. Эти инциденты позволяют злоумышленникам получать доступ к ФИО, банковским счетам, кредитным картам и другой чувствительной информации, что увеличивает риски для клиентов и поддерживает различные виды киберпреступности, такие как кражи личных данных и социальная инженерия.

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

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

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

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

Чек-лист здоровой ИТ-инфраструктуры

Зачем совершать свои ошибки и учиться на них, когда до нас их сделали уже несметное количество? Конечно, предугадать все аварии не получится. Но можно попытаться не допускать самых обидных и очевидных ошибок.

1. Регулярно создавать, хранить и проверять целостность резервных копий.

2. Использовать длинные и сложные пароли для учетных записей, обновлять пароли в соответствии с политиками безопасности, контролировать права доступа сотрудников.

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

4. Анализировать риски атак на инфраструктуру и возможные угрозы, разрабатывать планы аварийного восстановления.

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

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

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