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

Фундаментальное решение для архитекторов облачной безопасности заключается в том, насколько полагаться на облачные инструменты безопасности своего облачного провайдера, будь то 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. Не позволяйте стратегии безопасности блокировать вашу облачную безопасность сегодня

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

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

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

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

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

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

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

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