Сегментация в компьютерных сетях

Сегментация сети – почему это важно?

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

Для чего требуется сегментация сети?

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

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

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

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

Популярные методы выполнения сегментации сети

Если вы собираетесь использовать сегментацию сети, тогда вам потребуется обратить внимание на следующие ключевые задачи:

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

Решением первой задачи является использование технологии802.1x в корпоративных сетях — то есть использование дополнительного фактора (например, учетки в AD и сертификата) для получения доступа в сеть.

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

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

Ограничения традиционных методов сегментации

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

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

Поддержание сегментации сети становиться все более сложной в зависимости от динамики роста количества сотрудников и различных устройств — то есть сегментация это не единовременная операция, а постоянный и очень важный процесс. На данный момент также популярным подходом становится программно-определяемая сегментация сети, к примеру у Cisco это протокол TrustSec. Этот подход позволяет полностью уйти от IP-адресации и не мучаться с перекраиванием листов контроля доступа в случае смены VLAN-а или изменения топологии сети.

Источник

Сегментация сети для самых маленьких

Цель статьи: показать базовый подход к сегментации сети компании при разработке новых либо модернизации текущих автоматизированных систем.

1. Основные уровни: DMZ, APP, DB;
2. Правила межсервисного взаимодействия.

Демилитаризованная зона (DMZ, уровень I)

Начнем рассмотрение принципов межсетевого экранирования и сегментации сети со следующей схемы:

1. Пограничный маршрутизатор — соединяет нашу корпоративную сеть с пограничным межсетевым экраном, фильтрует трафик по ACL на 3-м уровне модели OSI;
2. Межсетевой экран — защищает сеть на 4-м уровне модели OSI, «терминирует» соединения;
3. Балансировщик нагрузки — ПО, выполняющее распределение нагрузки между веб серверами, расшифрование HTTPS трафика;
4. Веб сервер — первичный сервер реализующий обработку входящих запросов.

Зона (зона безопасности) — набор сегментов сети содержащих серверы одного назначения, например, сегменты содержащие только базы данных, или сегменты содержащие только персональные рабочие станции, и т.д.

DMZ — сегмент сети, предназначенный для размещения сетевых устройств взаимодействующих с внешними сетями, в частности с сетью интернет.

Логическая схема одноуровневой сети:

На картинке стрелка означает наличие сетевого доступа с IP адресом источника от того сетевого устройства от которого стрелка отходит, и с IP адресом назначения того сетевого устройства к которому стрелка направлена. Двухсторонняя стрелка соответственно будет означать наличие двух правил межсетевого экранирования в таблице правил межсетевого экранирования.

Давайте посмотрим как будут выглядеть правила межсетевого экранирования при прохождении обоих межсетевых экранов уровня сети:

Где HTTP — это транспортный протокол TCP и порт стандартный — 80-й.

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

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

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

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

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

Давайте пойдем дальше и перейдем к сегменту приложений (APP).

Сегмент приложений (APP, уровень II)

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

Схема для удобства упрощена до 3-х серверов:

1. Сервер с балансировщиком нагрузки;
2. Сервер с веб сервером;
3. Сервер с веб приложением.

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

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

Как видим, пунктирный прямоугольник логически объединяет все сетевые сегменты уровня 2 — сегменты приложений, в данном примере в каждом из сегментов по одному серверу.

В демилитаризованной зоне у нас так же 2 сетевых сегмента, в исходном размещено 2 сервера, в новом — 1.

Давайте вернемся к упрощенной схеме с одним сервисом. Давайте взглянем на наше монолитное приложение с огромным количеством строк кода в разрезе сервера:

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

Теперь у изначального сервиса может в единственном сетевом сегменте приложений быть уже N серверов.

Мы можем разрабатывать наши сервисы так:

1. Один DMZ только для входящих соединений из внешних сетей;
2. Другой DMZ только для исходящих соединений.

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

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

В таком случае становится возможным разрешить исходящие доступы во внешние сети из сегментов уровня 2 — APP минуя DMZ, так как особо демилитаризованная зона не дает какой-либо защиты:

При этом стоит предполагать, что доступ открывается на известные DNS имена, а не на IP адреса либо во весь интернет. IP адрес может быть выдан нескольким владельцам, один из которых окажется злоумышленником То есть создавать можно только точечные доступы до доверенных сервисов в сети интернет.

Сегмент баз данных (DB, уровень III)

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

Так мы переходим к зоне третьего уровня — DB.

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

Если есть желание отображать межсетевые экраны, их можно рисовать так:

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

Межсервисное взаимодействие

Межсервисное взаимодействие — взаимодействие серверов разных сервисов между собой. Такое взаимодействие должно предусматривать правила взаимной аутентификации серверов между собой и правила межсетевого экранирования.

Идеальная ситуация если в организации между серверами сервисов взаимодействие происходит всегда через демилитаризованную зону:

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

В таком случае, логичным будет разрешить такие взаимодействия:

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

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

Итог

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

Бонус

Если вы дочитали до конца, Вам может быть интересен проект Network-segmentation-cheet-sheet

Источник