Сегментация сети для самых маленьких
Цель статьи: показать базовый подход к сегментации сети компании при разработке новых либо модернизации текущих автоматизированных систем.
- Основные уровни: DMZ, APP, DB;
- Правила межсервисного взаимодействия.
Демилитаризованная зона (DMZ, уровень I)
Начнем рассмотрение принципов межсетевого экранирования и сегментации сети со следующей схемы:
- Пограничный маршрутизатор — соединяет нашу корпоративную сеть с пограничным межсетевым экраном, фильтрует трафик по ACL на 3-м уровне модели OSI;
- Межсетевой экран — защищает сеть на 4-м уровне модели OSI, «терминирует» соединения;
- Балансировщик нагрузки — ПО, выполняющее распределение нагрузки между веб серверами, расшифрование HTTPS трафика;
- Веб сервер — первичный сервер реализующий обработку входящих запросов.
Зона (зона безопасности) — набор сегментов сети содержащих серверы одного назначения, например, сегменты содержащие только базы данных, или сегменты содержащие только персональные рабочие станции, и т.д.
DMZ — сегмент сети, предназначенный для размещения сетевых устройств взаимодействующих с внешними сетями, в частности с сетью интернет.
Логическая схема одноуровневой сети:
На картинке стрелка означает наличие сетевого доступа с IP адресом источника от того сетевого устройства от которого стрелка отходит, и с IP адресом назначения того сетевого устройства к которому стрелка направлена. Двухсторонняя стрелка соответственно будет означать наличие двух правил межсетевого экранирования в таблице правил межсетевого экранирования.
Давайте посмотрим как будут выглядеть правила межсетевого экранирования при прохождении обоих межсетевых экранов уровня сети:
Где HTTP — это транспортный протокол TCP и порт стандартный — 80-й.
Как видим правила 2, правила могут быть как и идентичными, так и более широкими у того межсетевого экрана из-за которого трафик выходит, а более точечными за межсетевым экраном который трафик принимает. Так проще писать правила на межсетевом экране из-за которого трафик выходит, достаточно написать одно правило и если серверов много, то множество дублирующих правил писать не потребуется. То есть допустимы и такие правила:
Вот мы заодно рассмотрели и как понять какое правило межсетевого экранирования требуется написать.
С точки зрения практической безопасности, бОльшую роль играет тот факт, что балансировщик нагрузки и веб сервер — это те сетевые устройства, в которых наверняка почти сразу будут найдены уязвимости, а в случае нахождения уязвимостей удаленного выполнения кода (RCE) злоумышленник сможет получить высокие права в операционной системе. В таком случае если бы на сервере была база данных, то злоумышленник достаточно быстро смог бы до нее добраться.
Так же веб сервер выполняет первичную проверку данных на соответствие каким-то правилам и стандартам: как внутренним так и общеизвестным, например, XML проверяются по DTD , а сами полезные данные, на соответствие форматам данным, например, проверка того, что в поле для чисел пользователь вписал действительно числа, а не только символы.
Грубо говоря, в демилитаризованной зоне размещается то, что не жалко потерять, что потенциально может быть легко скомпрометировано.
Давайте пойдем дальше и перейдем к сегменту приложений (APP).
Сегмент приложений (APP, уровень II)
После первичной проверки, данные можно передавать веб приложению, выполняющее основную логику сервиса и размещенное на отдельном сервере:
Схема для удобства упрощена до 3-х серверов:
- Сервер с балансировщиком нагрузки;
- Сервер с веб сервером;
- Сервер с веб приложением.
Обратим внимание на пунктирную линию, она показывает следующее: все что за демилитаризованной зоной, является милитаризованной зоной, защищаемой другим межсетевым экраном. Отдельный межсетевой экран важен по следующей причине: если из сети интернет будет перегружен пограничный межсетевой экран, то вся сеть перестанет работать, он не сможет пропускать через себя трафик сегментов второго уровня. Если у нас 2 межсетевых экрана, то внутреннее взаимодействие при отказе пограничного межсетевого экрана сохранится:
Чтобы больше понять что же такое сегмент, а что такое зона, усложним схему: представим, что наша компания разрешает аутентификацию пользователей через внешнего провайдера аутентификации, пускай это будет Единая система идентификации и аутентификации (ЕСИА). В таком случае? у нас появляется еще один сервис помимо того, что у нас уже имеется — сервис аутентификации:
Как видим, пунктирный прямоугольник логически объединяет все сетевые сегменты уровня 2 — сегменты приложений, в данном примере в каждом из сегментов по одному серверу.
В демилитаризованной зоне у нас так же 2 сетевых сегмента, в исходном размещено 2 сервера, в новом — 1.
Давайте вернемся к упрощенной схеме с одним сервисом. Давайте взглянем на наше монолитное приложение с огромным количеством строк кода в разрезе сервера:
Мы видим, что на серверах могут быть размещены какие-то файлы необходимые для работы приложений, могут быть запущены сами приложения. Давайте представим, что у нас не одно монолитное приложение, а множество маленьких приложений и все они вместе решают всё ту же задачу, только размещены на разных серверах:
Теперь у изначального сервиса может в единственном сетевом сегменте приложений быть уже N серверов.
Мы можем разрабатывать наши сервисы так:
- Один DMZ только для входящих соединений из внешних сетей;
- Другой 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