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

Фундаментальное решение для архитекторов облачной безопасности заключается в том, насколько можно полагаться на собственные облачные инструменты безопасности своего поставщика облачных услуг, будь то AWS, GCP, Azure или любого другого поставщика. «Как можно больше» — это желание облачных инженеров, в то время как специалисты по безопасности, как правило, отдают предпочтение сторонним поставщикам систем безопасности. Многие специалисты по безопасности внедряли и работали с инструментами управления уязвимостями, защиты от вредоносного ПО или предотвращения потери данных в течение многих лет; почему бы не использовать те же инструменты в облаке? Это столкновение культур, и следующие шесть тезисов призваны помочь перейти от принятия архитектурных решений, основанных на эмоциях, к принятию решений, основанных на фактах.

Тезис 1: Поставщики облачных услуг не являются ни благотворительными организациями, ни супергероями — они гении маркетинга

Поставщики облачных услуг знают, как привлечь хорошую прессу. В 2021 году Microsoft пообещала инвестировать в безопасность 20 миллиардов долларов в течение следующих пяти лет. Должны ли ИТ-отделы внедрять систему безопасности Microsoft и ничего больше? Вот три мысли:

1. Когда речь заходит об облачных службах безопасности, бесплатного обеда не будет. Компании инвестируют, чтобы обеспечить (более высокую) окупаемость. Поставщики облачных услуг, тратящие большие суммы на создание услуг, должны рефинансировать их за счет доходов клиентов.
2. Поставщики систем безопасности работают на рынке уже несколько десятилетий и постоянно совершенствуют свое программное обеспечение. Напротив, поставщики облачных услуг разрабатывают проект с нуля или приобретают существующих поставщиков, а это дорогостоящие инвестиции, необходимые для того, чтобы наверстать упущенное, прежде чем они смогут внедрять инновации.
3. Инвестиции Microsoft в 4 миллиарда долларов в год не так уж далеки от инвестиций традиционных поставщиков: Symantec сообщила о доходе более 4 миллиардов долларов в 2019 году, McAfee сообщила о 1,6 миллиарда долларов в 2020 году, а Fortinet сообщила о 4 миллиардах долларов в 2022 году. Однако доходы и инвестиции — это не одно и то же. . «Инвестиции» – это расплывчатый термин. Он охватывает все: от проектирования до маркетинга, приобретений и «бесплатного» обучения и консультирования клиентов, возможно, даже определенные эксплуатационные расходы.

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

Тезис 2: Облачные службы безопасности создают или ухудшают привязку к облаку

Облачные инструменты безопасности могут препятствовать перемещению рабочих нагрузок от одного облачного провайдера к другому (блокировка). Такая привязка к облачным провайдерам может нарушать нормативные требования или противоречить ИТ-стратегиям, подчеркивая необходимость иметь возможность менять облака с управляемыми усилиями. Блокировка может осуществляться разными способами:

• Инструменты безопасности, связанные с рабочими нагрузками, проверяют и защищают виртуальные машины (ВМ) и контейнеры, просматривая их во время выполнения и проверяя рабочие нагрузки перед развертыванием. Типичными примерами являются защита от вредоносного ПО или сканирование уязвимостей. Использование облачных инструментов для этих целей подразумевает необходимость выбора альтернативных инструментов и их интеграцию при смене облака. Кроме того, эти инструменты могут вызвать дополнительную работу и сложности для групп приложений из-за потенциальных проблем совместимости (например, вызванных агентами, работающими на виртуальных машинах).
• Функции безопасности, специфичные для облачных поставщиков, устраняют риски, характерные для конкретного облака. При смене облака старые правила и инструменты в этой области устаревают. Например, при замене функций Azure на AWS Lambda ИТ-отделы должны разработать и настроить совершенно новые решения для AWS Lambda, независимо от того, работает ли их текущая реализация функций Azure с облачными инструментами или инструментами поставщиков безопасности.
• Общие инструменты безопасности — это решения без тесной интеграции или взаимодействия с приложениями или конкретным облаком. Ярким примером является корпоративный инструмент управления информацией о безопасности и событиями (SIEM). Он может работать в любом облаке или локально. Однако предположим, что компания выбрала облачное решение SIEM и теперь переносит всю свою рабочую нагрузку на другого поставщика облачных услуг. В этом случае компания должна заменить свои облачные инструменты общей безопасности новыми для идентификации и новыми для реализации решениями безопасности. Напротив, инструменты сторонних поставщиков безопасности, работающие на виртуальных машинах или контейнерах, требуют меньших усилий по миграции и, таким образом, подразумевают меньшую привязку к облачному поставщику.

Тезис 3: Включение всего — не стратегия безопасности

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

Тезис 4: Сравнивайте модели обслуживания и затрат, а не бесконтекстные цифры

Сравнивать преимущества, первоначальные и текущие затраты двух или более ИТ-решений всегда было непросто: сравнение облачных сервисов и стороннего программного обеспечения добавляет еще одно измерение. Для решений по обеспечению безопасности первой задачей является понимание того, какие угрозы и риски рассматриваются рассматриваемыми решениями и насколько они всеобъемлющи. Решение по предотвращению потери данных учитывает только электронную почту или HTTP-трафик? Способно ли решение обрабатывать зашифрованные сообщения или вложения электронной почты?

Во-вторых, компании должны понимать операционные процессы и связанные с ними затраты на их реализацию с помощью конкретного решения. Может ли младший ИТ-специалист настраивать правила брандмауэра и управлять ими, или вам нужны два старших архитектора безопасности? Для решения DLP решающее значение имеет соотношение ложных срабатываний. Если инструмент генерирует только десять инцидентов в день, затраты на персонал будут ниже, чем при 1000 ложных срабатываний.

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

Таким образом, понять затраты и выгоды сложно, но упомянутые категории и визуализация на рисунке 2 обеспечивают полезную структуру.

Тезис 5: Различие решений для основных рабочих нагрузок и нишевых тем

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

Тезис 6: Не позволяйте стратегии безопасности блокировать безопасность вашего облака сегодня

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

При создании новой облачной среды решающее значение имеют три этапа:

• Завершение проектирования и реализации облачной настройки (без функций безопасности),
• Подготовка инструментов безопасности для новой облачной среды и
• Развертывание приложений в новой облачной среде.

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

В действительности внедрение инструментов безопасности часто заканчивается позже, чем настройка облачной среды. Типичными причинами этого являются:

• Структурные ограничения. Дизайн облака имеет тенденцию меняться в ходе проекта, что требует адаптации инструментов безопасности.
• Сторонние инструменты безопасности. Для их развертывания на виртуальных машинах или контейнерах требуется зрелая облачная среда; Кроме того, при установке (нового) программного обеспечения в новой среде обычно требуются дополнительные усилия.

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

Тактические и стратегические решения, облачные и сторонние инструменты обеспечения безопасности, а также многие другие аспекты имеют значение. Разработка архитектуры безопасности для облачных сред — сложная задача. Это интересно для большинства архитекторов безопасности и утомительно для других. В любом случае эти шесть тезисов могут помочь преодолеть столкновение культур между специалистами по облачным технологиям и безопасности при выборе между облачными решениями и решениями сторонних поставщиков безопасности.