Большинство дата-центров имеют традиционную защиту, которая предполагает участие в линии защиты только оборудования периметра.
Однако в мультиоблачной инфраструктуре, на которой построено большинство современных дата-центров, такой подход к обеспечению сетевой безопасности уже не актуален.
Приложения, работающие в такой инфраструктуре, представляют особый интерес для злоумышленников и требуют высокого уровня защиты.
При этом они постоянно совершенствуются, поэтому безопасность необходимо строить без ущерба для их динамичного развития.
Для решения проблем такого рода мы рекомендуем использовать микросегментацию и концепцию нулевого доверия.
Микросегментация: особенности и основные возможности
Микросегментация — это подход, позволяющий построить детальную защиту на уровне рабочей нагрузки.Проще говоря, микросегментация позволяет создать для каждого приложения отдельный межсетевой экран.
Ключевыми особенностями этого подхода являются адаптивность и динамичность политик безопасности, а также возможность автоматического формирования политик на основе анализа взаимодействия приложений, поскольку вручную поддерживать актуальность правил для сотен и тысяч микросегментов в сети сложно.
постоянно меняющаяся обстановка.
Микросегментация лежит в основе нулевого доверия: микросегментация для каждой рабочей нагрузки и детальные политики безопасности гарантируют, что приложение не получит больше доступа, чем ему необходимо.
Кроме того, изоляция микросегментов и полный контроль трафика ограничивают горизонтальное распространение угроз, уменьшая поверхность атаки.
Основные варианты микросегментации:
- на основе межсетевых экранов (М?) на уровне гипервизора.
В этом случае могут возникнуть проблемы совместимости с ИТ-инфраструктурой, т.е.
не всегда будет возможно защитить приложения, работающие на физических серверах или гипервизорах других производителей;
- в зависимости от конечного хоста (например, iptables или брандмауэра Windows).
Этот вариант обеспечивает защиту любого приложения в любой ИТ-инфраструктуре, но требует использования агентов.
Кому-то наличие другого агента на хосте может показаться недостатком, но это открывает дополнительные возможности для сбора информации о потоке непосредственно от источника.
От теории к практике
Рассмотрим абстрактный пример компании X. У нее есть собственный дата-центр, а кроме того, компания пользуется услугами облачного сервиса.В настоящее время используется традиционная сегментация.
Внутри сегмента серверы свободно взаимодействуют друг с другом.
В дата-центре защита реализована с помощью физических межсетевых экранов: Edge M? обеспечить контроль над коммуникациями север-юг, М? ядра контролируют трафик между сегментами.
В облаке виртуальные межсетевые экраны используются для контроля входящего и восточно-западного трафика.
Рисунок 1. Сетевая архитектура для традиционной сегментации Такая архитектура частично ограничивает горизонтальное продвижение, но если злоумышленник получит доступ к одному из достаточно больших сегментов, то под угрозой окажутся все приложения внутри него.
Еще одним существенным недостатком является трудоемкий процесс поддержания правил в актуальном состоянии.
Несколько фаерволов, десятки сегментов, тысячи правил.
В результате при внедрении нового приложения или изменении существующего требуется ручная корректировка большого количества правил.
Несколько корректировок + человеческий фактор = политики, заваленные повторяющимися и дублирующими правилами + другие ошибки конфигурации.
А о возможности проверять влияние правил на приложение перед их применением и говорить не приходится.
Другая проблема — недостаточная осведомленность о приложениях и их сетевых взаимодействиях.
Сбор данных с использованием Netflow (или другого протокола потока) не допускается существующей инфраструктурой, поскольку не все коммутаторы поддерживают его или имеют достаточно ресурсов для его работы.
Проблему поддержки Netflow можно решить, развернув TAP или настроив SPAN на каждом свитче, но в масштабах дата-центра это дорого, т.к.
необходимо будет внедрять устройства, генерирующие поток на основе сырого трафика.
Как можно решить вышеперечисленные проблемы? Один из вариантов — автоматизировать жизненный цикл политик приложений путем сбора обширной телеметрии с серверов и использования алгоритмических подходов (машинное обучение и т. д.).
Некоторые из наиболее полезных инструментов включают платформу Cisco Secure Workload (Tetration), предназначенную для комплексной защиты рабочих нагрузок в многооблачных центрах обработки данных.
Это позволяет:
- внедрить микросегментацию для реализации модели нулевого доверия на основе белого списка;
- устанавливать базовые показатели поведения рабочей нагрузки и заранее выявлять аномалии;
- обнаруживать распространенные уязвимости, связанные с программными пакетами, установленными на серверах;
- использовать проактивную защиту путем помещения контролируемых узлов в карантин при обнаружении уязвимостей и блокировки связи при обнаружении нарушений политики;
- Обеспечить целостное понимание общего состояния безопасности центра обработки данных.
Как это работает
Cisco Secure Workload решает проблемы безопасности гетерогенных мультиоблачных сред, обеспечивая сквозную защиту рабочих нагрузок.С помощью датчиков он собирает данные, которые затем используются при аналитической обработке потоков сетевого трафика и активных процессов, протекающих в системе контролируемого узла.
Мы можем активно изолировать затронутые серверы до того, как произойдет разрушительный инцидент, используя корректировку правил брандмауэра контролируемого хоста с последующей микросегментацией, анализируя базовое поведение и выявляя распространенные уязвимости.
Обеспечивается последовательная защита рабочих нагрузок на программных пакетах, виртуальных машинах, рабочих станциях и контейнерах.
Комплексный подход значительно уменьшает поверхность атаки и ускоряет обнаружение аномалий и подозрительного поведения.
Компоненты решения
Программные датчики: — это программное обеспечение, установленное на серверах под управлением операционных систем Linux или Microsoft Windows. Эти серверы могут быть как автономным решением, так и элементом среды виртуализации или контейнерного типа, расположенными в локальных центрах обработки данных или в любом общедоступном облаке.Загрузка ЦП, возникающая при запуске программного обеспечения датчика, по умолчанию ограничена несколькими процентами и контролируется для обеспечения соглашения об уровне обслуживания (SLA).
Датчики могут как собирать данные телеметрии, так и выступать в качестве элемента управления на контролируемом узле для задач сегментации.
Собираются следующие данные телеметрии:
- информация о трафике рабочей нагрузки: содержит информацию о том, когда начался поток трафика, как долго он был активен, а также конечные точки потока трафика, протоколы, порты и т. д.;
- изменчивость поведения: фиксирует любые изменения между пакетами, наблюдаемые в потоке, включая изменения времени жизни пакета (TTL), флагов TCP/IP и длины полезной нагрузки;
- информация о процессе: фиксирует процессы, запущенные на сервере, включая информацию о параметрах процесса, времени запуска и остановки, двоичном хеше процесса и т. д.;
- Пакеты программного обеспечения: создает список всех пакетов программного обеспечения, установленных на сервере, а также информацию о версии и распространителе.
По словам поставщика, Cisco Tetration способна собирать исчерпывающую телеметрическую информацию на скорости линии на необходимых портах, не увеличивая задержку пакетов и не влияя на производительность.
Примерами таких решений являются датчики:
- Коммутаторы платформы Cisco Nexus
- ЭРСПАН
- Контроллер доставки приложений (ADC) — F5, Citrix NetScaler
- Поток данных, передающихся по сети
- Журналы AWS VPC
Функции безопасной рабочей нагрузки Cisco
Рассмотрим возможности решения на конкретном примере подключения нового пользовательского устройства под управлением MS Windows к существующему дата-центру, управляемому ПО Cisco Secure Workload. Центр обработки данных включает в себя общие основные компоненты, такие как серверы приложений, серверы баз данных и балансировщик нагрузки.
Рисунок 2. Структура компании X
Начальная настройка
При входе в систему отображается начальный экран информационной панели, на котором представлены данные рабочего процесса от ранее существовавших датчиков.
Рисунок 3. Существующие сетевые потоки
Добавление нового агента
Список существующих модулей на вкладке «мониторинг», отражающий подключенные программные агенты.
Рисунок 4. Список существующих агентов Решением видится два варианта установки программного агента: с автоматической привязкой и без.
Для экономии времени рекомендуется использовать вариант с автоматической привязкой.
Для наглядности будем использовать его в дальнейшей работе компонентов решения.
Рисунок 5. Выбор метода установки Пример установки программного обеспечения датчика на MS Windows 2019. 
Рисунок 6. Установка с помощью PowerShell.
Определение пула
Cisco Secure Workload может запускать алгоритмы машинного обучения при любой рабочей нагрузке, но она должна иметь механизм, устанавливающий определенные границы.В связи с этим на платформе существует концепция под названием «обзор».
Он позволяет вам легко запрашивать изменения настроек, связанных с конкретными областями вашей инфраструктуры, обеспечивая гибкость по мере развития вашей организации.
Рисунок 7. Определение новой «области действия»
Картирование
Cisco Secure Workload может автоматически обнаруживать и сопоставлять соответствующие политики и приложения.Решение называет этот процесс сопоставлением зависимостей приложений (также известным как ADM).
Настроим процесс запуска ADM для одного из приложений.
Мы автоматически определим список разрешенных политик для приложения: для этого вам нужно создать новое рабочее пространство во вкладке «Сегментация».
Мы определяем политику сетевой безопасности.
Каждая политика представляет собой взаимосвязь между набором исходных и целевых рабочих нагрузок.
Рисунок 9. Определение существующей политики Во время запуска функций ADM Cisco Secure Workload использует неконтролируемое машинное обучение для анализа всех метаданных заданной области и пытается сгруппировать конечные точки в кластеры.
Обнаруженные существующие политики можно просмотреть на вкладке «Политика».
Рисунок 10. Список существующих политик Мы используем встроенные инструменты, чтобы понять необходимость существования политики.
Рисунок 11. Список агрегированных потоков Этот метод позволяет просматривать агрегированные потоки на протяжении всего выполнения ADM, даже если порт назначения является удаленным и существует только одна запись.
Графическое представление
Решение также обеспечивает графическое представление политик, состоящих из узлов и соединительных звеньев.Узлы на карте представляют участвующие политические стороны.
Ссылка на графике представляет одну или несколько политик между начальной и конечной точкой.
Границы политики сгруппированы по начальным и конечным точкам.
Нажав на край графика, мы можем изучить все аспекты политики, такие как услуги (порты), действия (разрешить/запретить) и протокол между потребителем и поставщиком.
Рисунок 12. Графическое представление политик В этом примере только узел load_balancers может открывать соединения с веб-серверами, и только веб-серверы могут взаимодействовать с базами данных.
Если нет конкретного разрешающего правила, будет применяться политика перехвата всех данных.
Пример добавления политик
Политики можно добавлять или редактировать вручную на вкладке «Политика», как показано ниже.
Рисунок 13. Добавление политик
Политический анализ
Анализ политики позволяет пользователю понять, какое влияние политика окажет на среду, прежде чем она будет развернута в рабочих нагрузках.Анализ политики безопасной рабочей нагрузки Cisco предоставляет информацию о потоке, включая информацию вплоть до IP-адреса и порта, из которого возник поток.
Рисунок 14. Выполнение анализа Анализ политики решает, разрешен ли активный поток, удален или отклонен на основе политики, обнаруженной в результатах ADM.
Обеспечение соблюдения политик
Мастер применения политик обеспечивает видимость и предсказуемость применяемых политик до их реализации в рабочих нагрузках.Он также предоставляет механизм выбора изменений политики, которые необходимо применить (или откатить), и просмотра потенциально затронутых рабочих нагрузок в рабочей области приложения.
Рисунок 15. Обеспечение соблюдения политик Функциональность применения политики принудительно передает настройки политики брандмауэра агенту.
Агент программирует свой собственный брандмауэр так, чтобы разрешать только определенный трафик.
Рисунок 16. Обеспечение соблюдения политик
Проверка примененных политик
На вкладке «Политика» отображаются правила политики, которые были перенесены в рабочую нагрузку.
Рисунок 17. Проверка политик
Результат внедрения микросегментации
В результате внедрения Cisco Secure Workload было произведено разделение на зоны (производство, разработка и т. д.), а внутри зон — по приложениям.Для каждой рабочей нагрузки с использованием хоста M? создан микросегмент. Движение с севера на юг по-прежнему контролируется пограничной полицией.
Перенос точки применения политики непосредственно на хост позволил контролировать трафик даже между частями одного приложения и реализовать концепцию нулевого доверия: разрешены только необходимые соединения, ненужные порты отключены.
В таких условиях горизонтальное перемещение за пределы скомпрометированного приложения блокируется, что уменьшает возможную зону воздействия.
Рисунок 18. Архитектура сети после внедрения микросегментации На рисунке 19 показан пример разделения на зоны – рабочие области.
Внутри рабочей области существуют кластеры — рабочие нагрузки, сгруппированные по общим свойствам (рис.
19) — и применяемые к ним политики.
Рисунок 19. Сегментация по зонам 
Рисунок 20. Сегментация по приложениям Благодаря внедрению системы Cisco Secure Workload стало возможным автоматизировать рутинные задачи и поддерживать актуальность политик.
Сейчас алгоритм работы с политиками выглядит так: с помощью механизма ADM система самостоятельно группирует рабочие нагрузки в кластеры и формирует белый список политик; затем администратор может утвердить или изменить выходные данные ADM. Если изменяется членство в кластере или рабочей области рабочей нагрузки, ADM перезапускается и выпускает обновленные политики, отражающие изменения потока.
В этом случае администратор всегда может определить свои собственные политики белого и черного списков.
Результирующая политика будет представлять собой упорядоченный список правил, применяемых сверху вниз: абсолютные политики, созданные администратором (рис.
21), политики по умолчанию, созданные как часть операции ADM (рис.
22), и всеобъемлющая политика, обычно с действие запрета (рис.
23).
Рисунок 21. Абсолютная политика 
Рисунок 22. Политики по умолчанию 
Рисунок 23. Политика «Уловить все» Прежде чем применять политики, автоматически создаваемые ADM, необходимо понять, как они повлияют на приложение.
Мы запускаем функцию анализа политик, чтобы протестировать их на реальном трафике, но фактически не применяем их (рис.
24).
В результате проверки транспортные потоки разделены на четыре категории:
- Разрешено – поток разрешен как сетью (завершен), так и политикой;
- Escaped – поток разрешен сетью (завершен), но в соответствии с политикой должен быть запрещен;
- Rejected – поток запрещен как сетью (не завершен), так и политикой;
- Mis-Dropped — поток запрещен сетью (не завершен), но в соответствии с политикой должен быть разрешен.
Рисунок 24. Анализ политики Если анализ не выявляет нарушений, политику можно применять.
Если выявляются потоки, нарушающие политику, это повод для расследования и возможность решить проблему сегментации до ее возникновения.
Использование агентов на хостах открывает дополнительные полезные возможности.
Например, вы можете провести инвентаризацию установленного программного обеспечения, а затем использовать эту информацию для выявления известных уязвимостей.
В результате получаем: идентификатор уязвимости CVE (рис.
25); пакеты, которые необходимо исправить (рис.
26); рабочие нагрузки, в которых установлены уязвимые пакеты (рис.
27).
Рисунок 25. Информация CVE 
Рисунок 26. Информация об уязвимых пакетах 
Рисунок 27. Информация об уязвимой рабочей нагрузке.
В качестве временного решения информацию об уязвимостях можно использовать для создания динамических политик, блокирующих возможность эксплуатации этих уязвимостей.
Мы используем идентификатор CVE в качестве фильтра для выбора уязвимых рабочих нагрузок (рис.
28).
Затем этот фильтр применяется как параметр политики фильтрации (рис.
29).
По мере устранения уязвимостей также будут меняться параметры динамической политики.
Рисунок 28. Создание фильтра 
Рисунок 29. Динамическая политика защиты от уязвимостей Еще одна интересная функция, доступная благодаря агентам, — это сбор сетевой статистики прямо из источника.
Агенты периодически экспортируют информацию о потоке (протокол IP, IP-адрес источника/назначения, порты L4, количество пакетов/байтов, флаги TCP и т. д.), информацию IP (TTL, флаги IP, параметры IP и т. д.) в сборщик.
и т. д.), информация TCP (порядковый номер, номер подтверждения, размер окна rcvd).
Кроме того, агенты собирают информацию о процессах, их владельцах и командах, используемых для запуска процессов.
В результате мы получаем полную и актуальную информацию обо всех сетевых взаимодействиях (рис.
30).
Рисунок 30. Статистика сети Помимо сетевой статистики, агенты могут собирать и экспортировать информацию, необходимую при расследовании инцидентов: успешные и неудачные попытки входа в систему, создание и удаление учетной записи, повышение привилегий, запуск ранее неиспользованных команд, изменение хеша исполняемого файла и другие аномалии.
Он отправляется в механизм криминалистики, где идентифицированные события сравниваются с заранее созданными правилами.
При обнаружении совпадения выполняется одно из следующих действий: Записать – событие сохраняется для дальнейшего анализа; Оповещение – о событии генерируется уведомление.
Визуализация доступна для каждого события (рис.
31).
Вы можете четко видеть родительский процесс, список порожденных дочерних процессов и тип учетной записи, под которой выполняется процесс.
Подробная информация доступна для каждого процесса (рис.
32).
Рисунок 31. Визуализация событий 
Рисунок 32. Детали процесса Но некоторые межсетевые экраны никуда не делись, поэтому возникает новая проблема: необходимо обеспечить согласованность политик, реализуемых на этих межсетевых экранах.
Теги: #информационная безопасность #ИТ-инфраструктура #мультиоблачная #Системное администрирование #облачные сервисы #облачная инфраструктура #Tetration Analytics #облачная безопасность #микросегментация #cisco secure
-
Сравнение Планов Базы Данных Списков Ячеек
19 Oct, 24 -
Шварцшильд, Карл
19 Oct, 24 -
Как Же Все-Таки Писать Эти Чертовы Дела?
19 Oct, 24
