Поделиться
Не «если», а «когда»: управленческие ошибки, которые делают бизнес уязвимым
Владимир Маракшин
директор департамента стратегического развития компании «Киберпротект»
У большинства компаний есть мониторинг, регламенты, несколько средств защиты и пройденные аудиты. Но в реальном инциденте часто выясняется, что устойчивость была только на бумаге. Владимир Маракшин, директор департамента стратегического развития компании «Киберпротект», объясняет, где именно бизнес теряет киберустойчивость — и почему это происходит задолго до первой атаки.
Почему защита и устойчивость — не одно и то же
Защита — это предотвращение угроз. Устойчивость — это умение компенсировать воздействия, которые уже пробили защиту. Между ними есть принципиальное управленческое различие. Если бизнес исходит из того, что инфраструктуре ничего не угрожает, он заранее снижает готовность к реальному инциденту: нет средств, которые обеспечат 100% защиту от инцидента. Поэтому рабочий вопрос звучит не «если что-то случится», а «когда это случится?». И «что мы делаем дальше?».
Важно понять: защита от инцидента и работа с последствиями — это не взаимоисключающие меры. Нельзя выбрать что-то одно и считать проблему закрытой. Организовать защиту без устойчивости — опасно: стоит злоумышленнику пробить периметр, и нет ответа на вопрос «что дальше?» Выстроить устойчивость без защиты обычно дороже: придётся компенсировать слишком широкий спектр сценариев. В правильной логике работают оба слоя.
Где чаще всего ломается инфраструктура
В средней или крупной компании уязвимости, как правило, концентрируются в двух зонах.
Первая — внешний периметр. Уязвимости в CRM, ERP и других системах, которые по разным причинам оказались доступны извне. Частая причина — слабые политики удалённого доступа и игнорирование базовых мер: второй фактор не включён или используется не во всех критичных сценариях доступа, внутренние сервисы опубликованы без защищённого доступа. Принцип минимального доступа — один из самых простых и один из самых игнорируемых.
Вторая зона — платформы управления внутренней инфраструктурой. Средства консолидации мощностей, платформы виртуализации, IDM-системы. Это популярная цель для злоумышленников, которые хотят минимальных затрат при максимальном эффекте. Если удаётся взломать платформу, которая управляет, например контейнеризацией или виртуализацией, — одним действием можно остановить тысячи виртуальных машин. Потери от нескольких часов простоя часто оказываются выше того, что заранее закладывали на профилактику.
Тенденция к централизации инфраструктуры понятна и логична: это снижает стоимость администрирования и упрощает контроль. Но чем плотнее объединяются сервисы — тем выше цена компрометации любого из них. Логическую изоляцию важно сохранять: нет никакой пользы от того, что система управления производственным оборудованием находится в одной подсети с системой поддержки продаж. Зато есть риск — уязвимость в одной системе потянет за собой другую.
Заблуждение: «наша компания никому не интересна»
Есть отдельный тип недооценки рисков — он связан не с инструментами, а с отношением бизнеса к самому себе. «Мы небольшие, конкуренции особой нет, ни с кем не конфликтуем — кто будет на нас тратить усилия?»
Это опасная логика. Злоумышленник смотрит не на масштаб компании и не на её репутацию. Он смотрит на то, насколько она защищена и можно ли на ней заработать: шифрование данных с последующим вымогательством не всегда требует таргетированной атаки на конкретную жертву.
Веерный фишинг работает именно так: не нужно заранее знать конкретную компанию. Достаточно собрать базу контактов, подготовить письмо с правдоподобным содержимым — например, со сведениями о контрагенте, с которым получатель работает. Или запустить сканирование по широкому диапазону сетей в поисках уязвимостей. Если дыра нашлась — злоумышленник входит внутрь, а потом разбирается, что за компания и что здесь можно взять. Геополитический фактор добавляет ещё один слой риска, который тоже нельзя сбрасывать со счетов.
Иллюзия контроля
Есть тип управленческого самообмана, который сложно распознать изнутри. Компания прошла аудит, внедрила мониторинг, прописала регламенты, назначила ответственных — и возникает ощущение, что устойчивость обеспечена. Это ощущение ложное.
Регламенты без учений и процессы без проверки работоспособности создают иллюзию безопасности. Прописанная ответственность исполнителей не заменяет проведённые учения. Зелёная галочка в мониторинге не означает, что кластер высокой доступности переключится при сбое так, как вы ожидаете. Огромное количество резервных копий не поможет, если никто не проверял, можно ли из них восстановиться.
Ложное чувство безопасности возникает, когда инструмент установлен, но никто не проверял, как он работает в реальном сценарии восстановления. Всё выясняется не в отчёте, а в реальном инциденте.
Два заблуждения, которые дорого обходятся
Иллюзия контроля порождает неверные управленческие решения. Два из них встречаются особенно часто — и оба становятся понятны только после того, как что-то пошло не так.
Первое: «Избыточная инфраструктура нерациональна и дорога». Это заблуждение часто рассеивается после первого серьёзного сбоя — когда финансовые потери от простоя оказываются несопоставимо выше стоимости той самой избыточности. До сбоя оно кажется вполне разумным аргументом на совещании по бюджету.
Второе: «У нас есть средство X — оно закрывает все задачи». Зачастую нет. Работает комплекс: технические средства, регламенты и регулярная верификация их работоспособности в связке. Выбрать одно средство и считать задачу решённой — значит переложить ответственность на продукт и ослабить управляемость процесса.
Ранние сигналы: инфраструктура слабеет до инцидентов
Оба заблуждения объединяет одно: они мешают замечать, что инфраструктура уже слабеет. Иногда это видно задолго до серьёзного инцидента.
Самый простой маркер — нерешённые причины сбоев. Сервис был недоступен два часа и потом восстановился. Никто не пострадал, процесс не был критическим. Но никто не смог ответить, почему это произошло. Проблема появилась и ушла сама собой, все «поехали» дальше.
Одна из распространённых реакций в таких ситуациях — искать виновного сотрудника. Но это не обязательно вопрос компетентности. Возможно, инфраструктура архитектурно не позволяет дать ответ: нет нужного мониторинга, нет логов, нет изоляции, которая помогла бы локализовать проблему. Если инциденты накапливаются, а время их решения растёт — это системный сигнал, а не случайность. Причину стоит искать даже тогда, когда инцидент кажется мелким.
Чтобы не полагаться на интуицию, достаточно трёх показателей: время реакции на инцидент, время его решения и понесённые потери — финансовые, временные, репутационные. Каждый из этих параметров играет важную роль в выявлении проблем и служит основой для анализа рабочих процессов. Если негативная динамика затрагивает все три, это сигнал взять паузу и оценить общую картину.
Решения, которые созревают в риски
Некоторые архитектурные и управленческие решения поначалу выглядят рационально. Риск материализуется позже — иногда через несколько лет.
Первый случай — технический долг. Компания может ускорить трансформацию сейчас и отложить часть задач на потом. Однако должно быть понимание, когда именно вернутся к отложенным задачам. Технический долг может дойти до точки, где адаптировать инфраструктуру становится слишком дорого, а реструктуризация равнозначна новому циклу архитектурного проектирования с нуля.
Второй случай — слепое следование трендам. Популярный технологический стек — это хорошо. Можно снизить стоимость поддержки и облегчить найм. На уровне базового стека это касается и платформ управления инфраструктурой — важно заранее понимать, как вы будете эксплуатировать этот слой через три–пять лет. Каждый компонент должен проходить проверку: зачем мы его используем и как он будет работать через три-пять лет? Если ответа нет — компонент выбран по принципу «все так делают», а не по принципу применимости к конкретной задаче.
Третий случай — горизонтальное масштабирование как универсальный ответ на рост. Добавить серверов, докупить дисков, нанять больше людей — это работает до определённой точки. В какой-то момент следующий шаг горизонтального масштабирования обходится на порядок дороже, чем все предыдущие вместе взятые. Десять новых пользователей вдруг стоят столько, сколько первые десять тысяч. Это не повод для паники, если компания заранее понимает пределы своей инфраструктуры. Реальная проблема возникает лишь тогда, когда эти границы оказываются неожиданными, а план действий отсутствует.
Инфраструктуру, как правило, проектируют на три-пять лет — под конкретные объёмы: пользователей, заявок, транзакций. Если эти объёмы приближаются к плановому потолку, а архитектура не меняется — компания узнает об этом в самый неудобный момент. Потолок часто можно оценить заранее — если следить за метриками нагрузки и динамикой изменений.
Три роли, которые должны быть в связке
В устойчивости обычно участвуют три функции. Руководитель ИТ, руководитель по информационной безопасности — и роль, которую стоит выделить отдельно: ответственный за непрерывность и устойчивость бизнеса. Эта роль может находиться в ИТ-функции, может быть частью ИБ, может быть выделена самостоятельно. Такой контур нужен, даже если роль не выделена в отдельную должность.
Именно она связывает воедино три вещи: риски, сценарии эксплуатации инфраструктуры и потребности бизнеса. Без этого связующего звена регламенты остаются в одном месте, технические средства — в другом, а бизнес-приоритеты — в третьем. Когда наступает реальный инцидент, все три не совпадают.
План аварийного восстановления — это документ, который появляется именно из этой связки. Если его нет, компания в кризисной ситуации полагается на изобретательность исполнителей и удачу. Это не стратегия.
Управляемый кризис
Киберустойчивость — не набор инструментов и не стопка регламентов. Даже при использовании современных платформ управления инфраструктурой, таких как «Кибер Инфраструктура», систем резервного копирования «Кибер Бэкап» компании «Киберпротект», она формируется только там, где архитектура, процессы и ответственность работают как единая система.
Компании, которые строят долгосрочные планы, заранее закладывают ответ на вопрос «что мы будем делать, когда что-то случится». Разница между «когда» и «если» — это разница между управляемым кризисом и неуправляемой катастрофой.
Короткая ссылка
