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

МЕНЮ


Главная страница
Поиск
Регистрация на сайте
Помощь проекту
Архив новостей

ТЕМЫ


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

Авторизация



RSS


RSS новости


Введение

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

Правила межсетевого взаимодействия

Демилитаризованная зона (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)

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

Второй уровень сети

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

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

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

Последствия DDoS пограничного МЭ

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

Усложненная схема

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

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

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

Монолитная архитектура

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

Микросервисная архитектура

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

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

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

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

2 типа DMZ

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

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

APP -> внешние сети

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

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

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

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

Третий уровень, уровень данных

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

Отображение межсетевых экранов цветами

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

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

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

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

Идеальное межсервисное взаимодействие

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

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

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

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

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

Итог

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

Правила межсетевого взаимодействия

Источник: Хабр


Источник: m.vk.com

Комментарии: