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