Зачем объединять инструменты безопасности? Одна платформа может снизить расходы до 80 %

По данным консалтинговой компании Gartner, крупные предприятия используют в среднем 45 инструментов безопасности, а более крупные компании – даже 50-60.

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

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

⇢ У каждого вендора свой интерфейс, API и поддержка, а значит, даже простое изменение распадается на несколько шагов в разных системах.

⇢ Данные об инцидентах раздроблены, инструменты отслеживают только свой срез реальности, а корреляции между ними часто нет.

⇢ Расходы растут не только с лицензиями, но и с объёмом логов, платежами и операционной нагрузкой на команды.

⇢ Интеграции между инструментами создают технический долг, который замедляет и разработку, и реакцию на инциденты.

#1. Сложность и цена, которую вы за неё платите

Как только компания достигает определённого размера и операционной зрелости, её архитектура безопасности и производительности часто состоит из набора отдельных специализированных инструментов: CDN, WAF, защита от DDoS, DNS или балансировка нагрузки и защита от ботов. Каждый из них поставляет и обслуживает другой провайдер.

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

Данные компании Forrester показывают, что за последние пять лет 52 % ИТ-команд взяли на себя ответственность за защиту удалённых и гибридных сотрудников, 46 % добавили публичные облачные приложения, а 53 % – область комплаенса и аудитов. Каждая новая ответственность обычно означает ещё один инструмент и ещё один процесс.

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

Техническая сложность напрямую влияет и на эксплуатацию. Каждый поставщик использует свой формат данных, свою структуру записей и свой способ взаимодействия между системами, что требует создания интеграционных слоёв, поддержки инструментов конфигурации и постоянной доработки интеграций при изменениях программных интерфейсов. Если поставщик меняет свой API, готовая интеграция может развалиться. Исследования показывают, что 48 % руководителей в области инфраструктуры считают сложную интеграцию главным препятствием при внедрении новых технологий.

Всё это напрямую отражается в растущих расходах на безопасность вашей компании и её бизнеса. Цену лицензии вы ясно видите в счёте. Но последствия так называемого security tool sprawl, раздробленной среды безопасности, возникшей без единой архитектуры, проявляются не только технически, но и финансово.

Раздробленный стек безопасности попросту создаёт спираль расходов. Отдельные поставщики решают похожие задачи под разными названиями и в разных пакетах. Защита от DDoS, управление ботами, балансировка нагрузки или защита API часто встречаются в разных продуктах, но каждый раз как отдельно оплачиваемая функция. Организация платит не за одну целостную модель безопасности, а многократно за частичные возможности, которые не полностью интегрированы между собой. Результат – не более высокий уровень защиты, а более сложная эксплуатация и растущий счёт.

С каждым новым поставщиком прибавляются не только лицензии, но и операционные расходы. Данные перемещаются между разными платформами, что увеличивает egress-платежи (плату за исходящую передачу данных из облачных сервисов). Интеграции требуют дополнительных инструментов, обслуживания и людей. На практике общие расходы на стек безопасности часто оказываются на десятки процентов выше самих лицензий, а соответствующего роста защиты организация не получает. По данным компании Nonasec, за security sprawl организации без нужды платят на 30-50 % больше, чем должны были бы.

#2. Пробелы в покрытии, или когда каждый видит только своё

Каждый инструмент безопасности видит только свой срез реальности, а атакующие никаких границ между поставщиками не соблюдают. CDN отслеживает трафик, WAF охраняет прикладной уровень, защита от DDoS – объёмные аномалии, DNS-система – запросы, а балансировка нагрузки – распределение трафика между серверами. Но если эти инструменты ничто не объединяет, возникает раздробленная картина. Атака может начаться в одном слое, проявиться в другом, а общего контекста и единой корреляции событий нет. Снаружи инструменты выглядят как надёжная защита, на деле же это изолированные сигналы без общей логики.

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

По последним данным, 49 % организаций считают проблемой дублирование инструментов, 46 % выявляют пробелы или сбои между ними, а 41 % напрямую связывают плохую интеграцию с повышенным риском безопасности. Фрагментация, таким образом, означает не только операционную сложность, но и реальное ослабление защиты: правило может действовать на одном слое и не действовать на другом, реакция может быть быстрой в одной части инфраструктуры и запоздалой в другой. Атакующий использует именно эти рассогласования.

Фрагментация несёт и риски безопасности. По данным The Sequence, 49 % организаций считают проблемой дублирование функций инструментов, а 41 % связывают плохую интеграцию с повышенным риском инцидентов. Каждая новая точка интеграции, по их оценке, – потенциальное слабое место и дополнительное осложнение при разборе инцидента. Не говоря уже о том, что решение инцидента через несколько служб поддержки на практике удлиняет время устранения и умножает негативное влияние атаки на бизнес.

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

Самое частое проявление – усталость от оповещений (alert fatigue). По исследованию Ponemon Institute, средний центр операций безопасности получает примерно 17 000 оповещений о вредоносном ПО в неделю, при этом реально проверяется менее 20 % из них, а остальное – когнитивный шум. Больше инструментов, значит, больше оповещений и более рассеянное внимание, а не обязательно более высокий уровень защиты.

Одна платформа как решение

Консолидация поставщиков не означает упрощения в ущерб безопасности. Это скорее архитектурный ответ на растущую сложность и стоимость среды безопасности. По данным ADAPT CIO Edge Research, 68 % технологических лидеров планируют консолидировать своих поставщиков. Gartner к тому же прогнозирует, что к 2027 году 70 % организаций сократят число cloud-native-поставщиков максимум до трёх. Консолидация становится стандартной стратегией, а не исключением.

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

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

Как это решает Cloudflare

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

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

Конкретные цифры показывает случай компании Baselime: после миграции в среду Cloudflare её годовые расходы снизились с более чем 700 000 долларов (примерно 14,3 миллиона крон) до примерно 118 000 долларов (2,4 миллиона крон), то есть на 83 %. Помимо экономии резко снизилась операционная нагрузка и уменьшилась задержка при обработке пользовательских запросов.

Меньше инструментов, больше контроля

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