Михаил Кречетов, Step Logic: практическое введение в безопасность гибридных облаков

МИХАИЛ КРЕЧЕТОВ: Да, традиционная ИТ-инфраструктура меняется. ЦОДы эволюционируют от традиционной к модели будущего – гибридным облакам. Причем, запустился этот процесс не сегодня - приставки «as a Service» появились в обиходе еще в середине нулевых годов, а пандемия ускорила всеобщий переход к облачным технологиям.

Гибридное облако сегодня – это способ решения проблем, которые связаны, в первую очередь, с недостатком собственных мощностей. Кроме того, внедрение гибридного облака позволяет значительно снизить затраты, ведь собственный ЦОД всегда обходится дороже. Но самое главное, переход в облака способствует реализации принципа глобальной доступности. Классический ЦОД зависит от географии: местоположения резервных ЦОДов и каналов связи между ними. Однако «географическая» катастрофоустойчивость даже в пределах одного региона не дает полной гарантии того, что ИТ-сервис будет бесперебойно выполнять бизнес-предназначение. Именно поэтому основным драйвером для перехода в облака является обеспечение глобальной доступности и резервирование бизнес-процессов. Единственный тормоз этого процесса пока - предубеждение об отсутствии эффективных механизмов защиты новых технологий.

МИХАИЛ КРЕЧЕТОВ: Это не так. Сама эволюция классических ЦОДов постепенно подталкивала к реализации концепции «Инфраструктура как сервис». Фактически физический ЦОД уже давно стал частным облаком. При переходе в гибридное облако заказчики, которые смогли реализовать такую концепцию, скорее всего не изменят подход к пониманию собственной инфраструктуры. В определенном смысле им сейчас проще, ведь они давно осознали и приняли тот факт, что полностью программно-определяемая инфраструктура требует других подходов с точки зрения безопасности. Реально тяжело тем, кто до сих пор продолжает считать ЦОДы неким «мастодонтом», состоящим из железа и кабелей, которые нужно контролировать, спускаясь все ниже и ниже по шкале детализации процессов без попыток абстрагирования.

МИХАИЛ КРЕЧЕТОВ: По большому счету концепция безопасности не сильно поменялась, поэтому об отказе от традиционализма в области защиты облачных сред речи пока не идет. Все базовые механизмы обеспечения информационной безопасности, как для физических, так и для облачных инфраструктур, одинаковы: межсетевое экранирование периметра, защита от вторжений извне, аналитика событий информационной безопасности, защита конечных рабочих станций.

Но есть и новые риски, важнейший из которых глобальная доступность. Мы не знаем, какое устройство подключено в данный момент к нашей сети. Если, скажем, оно подключалось 30 минут назад, то за эти полчаса в неконтролируемой зоне с ним могло произойти все, что угодно. Поэтому сегодня облачная безопасность невозможна без реализации принципа "нулевого доверия" (Zero Trust), который гласит: не доверяем никому, пускаем извне только после предварительной проверки и только к тем ресурсам, которые явно заданы. Кстати, американский институт по стандартизации NIST в августе прошлого года выпустил регламентирующий документ, который описывает последовательность шагов при реализации Zero Trust. К сожалению, автоматизированные решения, реализующие модель «нулевого доверия», пока достаточно дорогие, и это тормозит внедрение концепции на глобальном уровне.

МИХАИЛ КРЕЧЕТОВ: В целом, есть три основных подхода к реализации модели Zero Trust. Первый способ - через микросегментацию. Фактически STEP LOGIC говорит об этом в течение последних 5–6 лет: отделяйте агнцев от козлищ, то есть контролируйте потоки трафика восток-запад (горизонтальные коммуникации) внутри своей инфраструктуры. Тогда можно создать практически отдельный межсетевой экран для каждого приложения.

Второй подход - через глобальную идентификацию: проверку учетных данных, прав доступа при каждом обращении субъекта к объекту.Михаил Рожков, PARMA TG: Большинство наших BPM-проектов выходят за рамки отдельных процессов и организаций 3.5 т

Третий метод – комбинированный, предполагает реализацию Zero Trust специальным средством на базе сетевых технологий. Однако наиболее эффективным методом является комбинация всех перечисленных подходов. Например, использование решения Cisco Secure Workload (предыдущее название - Tetration) в сочетании с платформой идентификации Cisco Identity Services Engine (ISE) с прикрученной двухфакторной идентификацией Google. На сегодняшний момент это наиболее проработанная модель Zero Trust.

Вообще, модель применения Cisco Secure Workload многогранна. Существует самое безопасное решение, которое только возможно, — программный сенсор, встраиваемый в каждый компонент виртуальной инфраструктуры (например, виртуальную машину). Подобная схема называется агентской. Иногда, правда, возникают проблемы с невозможностью запуска агентов на части компонентов, причем они вовсе не технические, а скорее организационные. В таком случае на помощь приходит так называемая безагентная схема – аппаратные сенсоры, которые позволяют анализировать трафик путем интеграции с компонентами инфраструктуры, например, с ADC, или даже с AWS VPC.

Cisco Secure Workload может автоматически обнаруживать и сопоставлять соответствующие политики и приложения. В решении этот процесс называется сопоставлением зависимостей приложения (также известный как ADM) – и это как раз один из шагов построения ZTA, да и в остальном, платформу можно охарактеризовать как практический инструмент для организации микросегментации и модели нулевого доверия в точном соответствии с описанным в стандартах требованиями.

МИХАИЛ КРЕЧЕТОВ: Это так. Но без автоматизированных средств разобраться, что происходит не то, что внутри облачных инфраструктур, но даже внутри классических ЦОДов, невозможно. Если погружаться в эту пучину данных вручную, вы никогда не внедрите Zero Trust. Можно потратить несколько лет, а потом обнаружить недокументированный объект, - их, честно говоря, у каждого заказчика хватает. По нашему опыту, главная причина торможения внедрения адекватных средств ИБ заключается как раз в непонимании целостности и связности потоков трафика.

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

МИХАИЛ КРЕЧЕТОВ: Да, это очень серьезный аспект. Об этом можно судить по нормативным документам, принимаемым на Западе, - там за вопросами доступности данных следят гораздо более зорко, чем в России. В последнее время, например, были сильно ужесточены требования к идентификации субъекта. Почему?

Объяснение простое: вредоносное программное обеспечение чаще всего использует определенную технику, связанную с применением краденых учетных данных. Причем, чем выше учетка по своему сервисному положению, тем лучше для решения поставленной задачи. В большинстве случаев задействуются даже не учетные данные пользователей, а именно сервисные записи - забытые, пароль к которым не менялся много лет. По данным ИБ-аналитиков, это наиболее популярный путь эксплойта, который применялся в 2020 - 2021 годах.

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

МИХАИЛ КРЕЧЕТОВ: Да, конечно. Более того, думаю, что разграничение ответственности в облачных средах – это настоящий бич средств защиты. Сегодня это очень тяжелый и непонятный процесс. Почему так? В собственном ЦОДе служба эксплуатации, ИБ, кабели, турникеты и т.д.– это контролируемая зона, ее можно детализировать. Но когда мы начинаем части сервисов переносить в облако, то появляется новая прослойка - облачный провайдер, который отвечает за доступность сервиса. Вроде бы, проблем нет. В классической парадигме IaaS он не поднимается выше «железа» и платформы виртуализации, а в парадигме платформы - не выше прикладного уровня. То есть с точки зрения инфраструктуры, все уровни определены. А вот для информационной безопасности все оказывается гораздо сложнее.

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

МИХАИЛ КРЕЧЕТОВ: На мой взгляд, тут стоит воспользоваться помощью провайдера управляемых сервисов ИБ (Managed Security Service Provider, MSSP). Это сторонняя организация, которая, с одной стороны, сотрудничает с поставщиком вычислительных ресурсов, а с другой - контактирует с заказчиком, и может помочь ему выстроить правильную модель безопасности для конкретных условий. Это сильно упростит миграцию сервисов в облако и дальнейшую жизнь компании в гибридной среде. Я бы сказал, что MSSP выполняет роль некоторого долгоиграющего интегратора, который предоставляет услуги безопасности.

МИХАИЛ КРЕЧЕТОВ: В первую очередь, это зависит от размера и, как ни странно, зрелости самого заказчика. В идеальном процессе заказчик должен самостоятельно, возможно, с привлечением внешних аудиторов, определить свою политику информационной безопасности, четко описать задачи облачной безопасности при миграции. Если он сможет это сформулировать самостоятельно, значит, и внедрение соответствующих средств будет ему по силам.

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

МИХАИЛ КРЕЧЕТОВ: ЦОДы массово переходят на программно-определяемый периметр. Кто этот переход совершил, тот сможет переехать в облако, образно говоря, за две минуты: сервис просто мигрирует на новую платформу и живет там. Естественно, visibility периметра от этого страдает. Но при реализации концепции Zero Trast и управления идентификацией мы можем четко детерминировать все потоки извне и внутри. И тогда степень visibility гибридной среды будет едва ли не лучше, чем в классических ЦОДах, так как там не было возможности уйти на больший уровень детализации, чем линия «север-юг» (Enterprise DC – Cloud DC).

МИХАИЛ КРЕЧЕТОВ: Предположим, у нас есть условный удаленный пользователь, который подключается к корпоративному ресурсу. Раньше оставалось неизвестным, какие процессы он запускает внутри инфраструктуры. Сейчас в рамках Zero Trust отслеживаются все детали: географическое перемещение пользователя (он ведь может уехать в отпуск на остров с пальмами), подключение к определенному ресурсу, запуск конкретного приложения. Детальная матрица безопасности позволяет определить, разрешено ли это взаимодействие, или он не должен запускать это приложение? И вообще почему он находится на острове с пальмами?.. Раньше мы об этом не задумывались, а современные механизмы безопасности дают такую информацию.

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

МИХАИЛ КРЕЧЕТОВ: Безопасность процесса постоянной разработки и развертывания, которая обозначается аббревиатурой CI/CD (Continuous Integration, Continuous Delivery — непрерывная интеграция и доставка) – это один из краеугольных камней ИБ гибридного облака. И разработчики, и девопсеры могут выдать в продакшн сервис, недостаточно проверенный с точки зрения безопасности.

МИХАИЛ КРЕЧЕТОВ: Да, здесь непросто найти правильный баланс. Поэтому важно сфокусироваться на безопасности самого процесса разработки. Это в дальнейшем сильно сэкономит средства, которые будут тратиться на наложенную безопасность.

Если мы на этапе разработки и развертывания сервиса учтем все риски и нивелируем возможные угрозы, то, в принципе, сможем ограничиться наложенными средствами ИБ только для определенного контура, скажем, для критически значимого фронтального приложения. Но при этом вопросы безопасности бекэнда должны быть полностью решены.

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

И возвращаясь к первому вопросу, теперь мы можем указать четыре аспекта, которые отражают технологическую новизну облаков, по сравнению с традиционными ИТ-инфраструктурами: разграничение ответственности, микросегментация, глобальная идентификация и защита DevOps и CI/CD.

МИХАИЛ КРЕЧЕТОВ: Пожалуй, это единственный сегмент ИБ, где еще остаются «белые пятна». Контейнеры хостятся на одном сервере, операционной системе и с одним и тем же сетевым интерфейсом. Как отличить один контейнер от другого? Универсального средства пока нет. Учимся применять существующие решения ИБ, например, уже упоминавшуюся платформу Cisco Secure Workload. Цель – с помощью горизонтального контроля видимости нивелировать вероятность распространения угроз внутри самих контейнеров.

Второй путь минимизации рисков – разработчики. Этот вопрос мы обсудили ранее. Технологии безопасности стали осваивать территорию, которая ранее была исключительно вотчиной DevOps: они учатся правильно ограничивать пространство и т.п. Сейчас идет этап накопления практического опыта, который должен в обозримом будущем закончиться созданием специальной концепции контейнерной безопасности. Вот тогда можно будет уверенно сказать, что полностью стерлась разница между классической и облачной инфраструктурой, все стало облаком.

МИХАИЛ КРЕЧЕТОВ: Если заказчики уже осуществляют контроль между приложениями на нижнем уровне, им проще внедрить концепцию Zero Trust. Для остальных случаев применение технологий микросегментации - это наиболее простое и дешевое решение для отделения приложений внутри самой инфраструктуры. Отличный подход – комбинация микросегментации с надежной и хорошей платформой управления уязвимостями.

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

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

В целом, для создания защищенной гибридной среды, удобной для ИТ-штата, нужны три основных блока: безопасная разработка кода, безопасные процессы DevOps, классическая защита облака.

МИХАИЛ КРЕЧЕТОВ: К сожалению, единого документа, регламентирующего применение средств безопасности в гибридных инфраструктурах, у нас пока нет. Нет его, кстати, и на Западе. Единственное требование регулятора, которое мы должны неукоснительно соблюдать, - хранение всех данных в пределах Российской Федерации. Но здесь важна активность самого облачного провайдера. Например, Яндекс.Облако, стремясь завоевать рынок, весной получили соответствующие заключения ФСТЭК о том, что на их инфраструктуре можно размещать, как государственные информационные системы (ГИС), так и компоненты систем, обрабатывающих персональные данные граждан. «Ростелеком» также движется в этом направлении.

В целом, при отсутствии специальных требований регулятора к гибридному облаку приходится использовать требования, сформулированные в отношении ГИС, КИИ и регулирования персональных данных, а также приказы ФСТЭК с их новой моделью угроз. Со всем этим, в принципе, можно взлететь. Но требуется больше. Например, требования к строгости усиленной аутентификации до сих пор четко не сформулированы.

У отечественной нормативной базы есть одна особенность: нам указывают на то, ЧТО нужно делать, но почти не говорят о том, КАК. Поэтому наши документы, скажем, приказ о защите КИИ, можно применять абсолютно к любой среде, хоть гибридной, хоть классическому ЦОДу и это открывает большой простор для творчества. В то же время постоянно возникает вопрос: а правильно ли мы делаем?

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

МИХАИЛ КРЕЧЕТОВ: Наиболее часто встречающаяся проблема – отсутствие у заказчиков понимания сетевых потоков. В этом случае мы помогаем продвинуться в концепции микросегментации, отделить потоки друг от друга. Еще один популярный запрос - подготовка к процессу перехода в облако. На первом этапе это, как правило, внедрение систем управления глобальным доступом и уязвимостями, далее – реализация защиты внутренних сред, микросегментация.

МИХАИЛ КРЕЧЕТОВ: В первую очередь, это финансовый сектор. Банкам критически важно получить отказоустойчивую высокодоступную инфраструктуру. Чаще всего они строят некий симбиоз частных облаков на чужих вычислительных мощностях. Также ощутимый запрос на облачные вычисления существует в авиастроении.

На самом деле, для банков переход в облака не является самоцелью. Изначально в связи с переводом огромного количества сотрудников на удаленку возникла задача построить надежный сервис. Первичной была идея микросегментации, а размазывание сервиса по облакам начали реализовывать уже после того, как зачатки облачных структур были реализованы в основных ЦОДах.

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

МИХАИЛ КРЕЧЕТОВ: Во-первых, заказчик должен самостоятельно или с привлечением внешних подрядчиков проанализировать активы и устранить теневую составляющую – Shadow IT. Это очень важно для дальнейшей реализации защиты с применением концепции нулевого доверия.

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

Был, например, случай, когда у одного из заказчиков жил себе спокойно в течение нескольких лет незарегистрированный DNS-сервис. Обнаружилась эта никому не известная машина в тот момент, когда мы начали процесс микросегментации, причем, было очевидно, что там огромное количество DNS-реквестов. Понятно, что мы попытались этот информационный поток выключить… Дальнейшее расследование показало, что это основной сервис пересылки DNS-запросов, о котором, никто не знал и ни в какой документации он не был отражен. Конечно, это был шок! Вот почему надо заново составить таблицу активов: обновить ее и найти все «скелеты в шкафу», а они есть в каждой инфраструктуре, увы! – особенно, если она связана с разработкой ПО.

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

Следующий шаг - формирование специфических защитных мер. Они зависят от проведенной ранее оценки рисков. Можно выстроить безопасный шлюз доступа Secure Access Service Edge (SASE), который обеспечивает быстрый и безопасный доступ всех пользователей ко всем приложениям за счет унификации или ограничиться внедрением модели нулевого доверия, но обязательно с усовершенствованием идентификации. После этого можно начинать переход в подготовленное безопасное облако, либо собственными силами, либо с помощью подрядчика.

МИХАИЛ КРЕЧЕТОВ: Некую тестовую pre-production среду компании привыкли крутить в облаке. В частности, такие возможности предлагает «большая тройка» гиперскейлеров: AWS, Google Cloud, Microsoft Azure. У китайских коллег есть своя облачная платформа, заточенная под предоставление сервисов. Конечно, протестировав облачные механизмы там, полученный опыт легко перенести в свою гибридную инфраструктуру. Правда, есть в этой ситуации один важный момент, который, к сожалению, наши компании нередко упускают.

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

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

МИХАИЛ КРЕЧЕТОВ: Именно так. Развитие ИБ идет постоянно, и для профильных специалистов переход в облака не стал ушатом холодной воды, неожиданно опрокинутым на голову. Мы подходили к этому планомерно, и также стараемся двигаться дальше в несколько изменившейся парадигме. Периметр размывается все больше, и в дальнейшем просто не останется собственных ЦОДов в их классическом нынешнем понимании. Они станут местом для хранения ключевой конфиденциальной информации, а все те данные, которые должны быть высокодоступными, размажутся по глобальной информационной среде.

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