Введение
Цель статьи: показать базовый подход к сегментации сети компании при разработке новых либо модернизации текущих автоматизированных систем.
В статье рассмотрим:
Правила межсервисного взаимодействия.
Демилитаризованная зона (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 всех сервисов внутри компании.
При этом, доступ в базу данных чужого сервиса нельзя разрешать ни в коем случае.
Итог
В итоге мы получаем такой перечень основных базовых правил определения возможности предоставления сетевого доступа:
Комментарии (17)
Dmitry3A
12.11.2021 05:12Не очень понятно зачем вы от балансировщика до сервера указываете HTTP? Вы там терминируете HTTPS?
Protos Автор
12.11.2021 05:12Верно
sergeyns
12.11.2021 14:12А не рано?
Dmitry3A
12.11.2021 17:06Мне тоже кажется что сейчас смысл терминирования HTTPS нету.
Дополнительная нагрузка на декодирование оценивается в максимум 2-3 процента от загрузки CPU.
Если стоит WAF, тогда конечно надо декодировать, но потом можно опять в защищеном канале отправить.
А получается что весь трафик в сети ходит открытый. Зависит конечно от конкретной ситуации, но если уж стоит тэг «информационная безопасность» — по идее не сильно большая плата за дополнительную защиту.Protos Автор
12.11.2021 18:51Если нет обработки биометрии, то внутри контролируемой зоны нет смысла шифровать трафик, ФСБ явно не требует если модель внутреннего нарушителя не предусматривает в явном виде. Если даже и есть WAF, то лишняя перешифровка все равно проблемки вызывает у WAF, нужно серты подсовывать для MiTM.
Dmitry3A
12.11.2021 19:34Перешифровывать можно сертификатами из своего CA. Кроме дополнительной нагрузки на шифрование, по идее не должно быть проблем.
Если несколько приложений живут в одном DMZ то есть шанс что можно чужой трафик подслушать на коммутаторах.
После опубликования сноудном деталей прослушки, гугл например вообще всё стал шифровать. Даже вопрос не ставится шифровать или нет. в каком-то смысле это даже легче.
athacker
15.11.2021 15:43Нагрузка от декодирования HTTPS сильно зависит от количества новых клиентов в единицу времени клиентов (когда кэширование параметров сессии не особо помогает). Иногда приходится юзать даже аппаратные акселераторы для терминирования TLS.
С точки зрения ИБ таки да, выгоднее использовать шифрованные соединения везде, но в ряде нагрузок это может создавать серьёзные проблемы с производительностью. Можно также сравнить пропускную способность сетевых устройств, которые понимают L7 на шифрованном трафике и на нешифрованном -- она сильно отличается.
Protos Автор
12.11.2021 18:52Ну я рисовал зная, что дальше WAF стоит по привычке, но даже если нет, какой минус?
casperrr
16.11.2021 02:38Тяжело читать статью. Все время уговариваешь себя, что человек, не осиливший азы пунктуации не обязательно так же плохо разбирается в вопросах сегментации.
Местами вспоминается один персонаж, что-то в духе: "Мы стали более лучше одеваться".
Ну что это такое, коллега? Вы отчеты руководству или служебные письма так же пишите, как статьи? Пожалейте их глаза и нервы.
"DMZ - сегмент сети"
"Чтобы больше понять что же такое сегмент, а что такое зона, усложним схему". Больше понять... Рифма напрашивается нецензурная в духе министра Лаврова.
Базы данных - то сегмент, то зона третьего уровня, то сегмент в милитаризованной зоне.
Ну ввели терминологию и подход к классификации - следуйте ему хотя бы приличия ради.
Если ДМЗ все же зона, то это ОНА, а не он. Ну и так далее и тому подобное, от начала и до конца кровь из глаз.
По существу, не про запятые. Для новичка статья так себе. Не то, что бы мысли в целом какие-то особо неверные, но с ясностью мышления и акцентами именно для новичка, явные проблемы.
"..балансировщик нагрузки и веб сервер - это те сетевые устройства, в которых наверняка почти сразу будут найдены уязвимости".
Новичок сидит и думает. Ага, они (ну или он, веб сервер) имеют доступ к серверу приложений, в котором тоже наверняка будут найдены уязвимости, а у того есть доступ к базе, а в ней тоже наверняка уязвимости... В чем же фишка, сквозной пробой всего и вся от гланд до заднего прохода. Фишка несомненно есть и крайне простая и даже вскользь упомянута в статье, но крайне мутно.
ДОС на пограничный ФВ не самая большая беда. И если учесть, что ДМЗ делаются далеко не всегда на стыке публичных сетей с частными, а в т. ч. в пределах одной, допустим, корпоративной сети, заради разделения и безопасного инф. обмена частей сети с разным уровнем доверия/критичности, где ДОС маловероятен или вообще невозможен, все же два независимых ФВ делают и логика там ближе к чистой ИБ, чем к нагрузочным моментам.
На счет терминации HTTPS замечание другие комментаторы сделали верное. При чем тут обязательно комплайнс законодательный и ПД? А инфраструктура сетевая только из ФВ одних состоит? А она не может быть порутана? А не может так оказаться, что дальше самого внешнего ФВ злоумышленнику и не понадобится, он трафик ваш расшифрованный будет слушать и свой профит иметь (а ваша организация ущерб, отличный от последствий несоблюдения законодательства о ПД).
А если в ДМЗ не один веб сервер? И его порутать не смогли, а порутали соседний в той же зоне и ваш расшифрованный трафик перехватили атакой уровня L2? А уже с этого поимели и прямой профит и возможности продвинутся дальше по инфраструктуре?
На счет того, что к сегментации не имеют отношения разные там Zero Trust и вякие модные технологии в духе цисковских оверлеев и их механизмов безопасности.
Коллега! Еще как имеют. Потому что сегментация в классических сетях - это способ изоляции на базе топологии. Она (сегментация) не самоцель, у нее есть задачи, о которых вы написали крайне мало и сумбурно. Так вот, эти задачи могут решаться и несколько иначе. Или гибридно. Отчасти топологией построения, отчасти другими средствами.
И применение конкретных технологических погремух влияет на сегментацию, вопреки вашему комментарию.
15 или 20 лет назад, например, хочешь сегментации и тем более микросегментации (с контролируемым уровнем изоляции, а не просто так!) - нет вариантов особых, плоди Vlan, L3 сегменты, разделенные файрволами. Сейчас можно сделать одну большую плоскую сеть и эту самую микросегментацию получить + гибкая фильтрация + глубокий анализ и еще хз что.
Все, что у вас на ваших веселых картинках - это про нее. Изоляция за счет структуры сети, способа соединения ее частей. И даже без модных оверлеев, чисто появление какой-то хитрой железки для хитрой инспекции, на способ сегментации может повлиять. Вот не умеет она иначе работать, включи ее именно так и никак по-другому.
А сейчас, выскажу возможно спорный для кого-то момент. Ваша картинка напоминает классические той же циски. На самой границе внешних сетей - роутер, потом файрвол. Так-то да. Тру роутер как роутер всегда обойдет роутер, сделанный из файрвола по функциям маршрутизации. Но всегда ли это нужно? Учитывая, что статья для новичков? В серьезной корп. сети, где всякие BGP с провайдерами, разветвленная филиальная сеть, миллион туннелей через Инет и хитрости динамической маршрутизации, наверное такая схема оправдана. А в обычной сети, где рулит новичок, этого всего не будет.
И пусть он или совместит внешний роутер с файрволом вопреки классической картинке или помнит, что если у него есть филиалы, подключенные не через Инет, а через выделенные каналы, какие-то другие части сети, свой, приватный WAN - ему нужен ЕЩЕ один роутер, назовем его опорный, который к данному, нарисованному, отношения не имеет и должен быть отдельный, спрятанный в т.ч. за какой-то ФВ. И когда он это поймет, то ну его нафик. На границу сети он поставить ФВ, который у вас на рисунке идет вторым и пусть этот ФВ выполняет простейшую маршрутизацию, обеспечивает дефолт через провайдера. А роутер спрячет за него и будет строить на нем внутренние коммуникации.
Возможно мелко плаваю как тех. специалист, но в достаточно большом Холдинге с филиальной структурой по стране, почти нигде не сделано по данной картинке. Везде на самой границе что-то специфически ИБшное, а не просто роутер с грубой предфильтрацией АЦЛ.
Но это ладно, может они/мы лохи. Но вот новичку я бы точно советовал как у вас нарисовано - не делать.
Protos Автор
29.11.2021 17:12По поводу всех вами указанными новомодными погремухами, для всех финансовых организаций действует ГОСТ 575801.1-2017, а конкретно его мера:
СМЭ.15
Реализация сетевого взаимодействия и сетевой изоляции на уровне не выше третьего (сетевой) по семиуровневой стандартной модели взаимодействия открытых систем, определенной в ГОСТ Р ИСО/МЭК 7498-1, внутренних вычислительных сетей финансовой организации и сети Интернет
Не считаю, что понимание сегментации сразу на уровне L7 является базой, так же понимание того, что один межсетевой экран может все роутеры, межсетевые экраны, умные коммутаторы, заменить, тоже всем новичкам ни к чему.
Если у вас есть желание рассказать об этом, вы можете написать свою статью, не забудьте расписать сегментацию сразу в контейнеризации, она же тоже сейчас у всех есть.
Protos Автор
29.11.2021 19:46А если в ДМЗ не один веб сервер? И его порутать не смогли, а порутали соседний в той же зоне и ваш расшифрованный трафик перехватили атакой уровня L2?
Для этого разрабатывается защита на уровне L2 и к межсетевому экранированию не имеет отношения, следовательно в статье этого нет.
Protos Автор
29.11.2021 19:56ДОС на пограничный ФВ не самая большая беда. И если учесть, что ДМЗ делаются далеко не всегда на стыке публичных сетей с частными, а в т. ч. в пределах одной, допустим, корпоративной сети, заради разделения и безопасного инф. обмена частей сети с разным уровнем доверия/критичности, где ДОС маловероятен или вообще невозможен, все же два независимых ФВ делают и логика там ближе к чистой ИБ, чем к нагрузочным моментам.
Не понял поток мыслей, наверное, вы писали про то, что каждая ИСПДн/направление бизнеса/ЮЛ в группе компаний/либо огромные связные наборы сетей/ либо еще по какой методике защищаемые разными межсетевыми экранами сегменты, для удобства защищаются разными МЭ. Оно?
Каждый сам решает как ему лучше, что у него будет на границе хоть группы внутренних сетей: МЭ, коммутатор либо роутер; внешних: роутер, средство защиты от ddos, мэ. Не важно крупная или мелкая компания - в компаниях каждого размера компаний бывает обычное межсетевое экранирование и каждый сам решает.
Protos Автор
29.11.2021 19:59Возможно мелко плаваю как тех. специалист, но в достаточно большом Холдинге с филиальной структурой по стране, почти нигде не сделано по данной картинке. Везде на самой границе что-то специфически ИБшное, а не просто роутер с грубой предфильтрацией АЦЛ.
Но это ладно, может они/мы лохи. Но вот новичку я бы точно советовал как у вас нарисовано - не
Судя по всему, вы сами не понимаете почему у вас так, а не как у меня и постулируете ваше решение как верное решение абзацами выше, причем не советуете делать так, хотя в начале пишите, что все указанное это спорный момент
casperrr
29.11.2021 19:30Ну ок, прицепились к второстепенному, что и было мной отмечено, как спорное. Еще 31й или 239й приказ фстэк вспомните, мало ли есть каких ведомственных ограничений.
Статья сырая по факту и слабая. Мнение. Имею право. Не готовы к критике, в т.ч жесткой - не публикуйтесь, делов-то. Встречный совет, в ответ на предложение свою написать.
up40k
Позвольте не согласиться. Уязвимости в первую очередь будут найдены там, где разработчик/администратор не позаботился обрабатывать данные, которые приходят от пользователя/настроить сервис должным образом с учётом модели угроз. Это всё на L7, и может оказаться в любом сегменте.
То, что вы в целом описали - безусловно хорошо и правильно для базового понимания, только ваше "для самых маленьких" чем-то напоминает курс школьной физики с её ньютоновской механикой. С той разницей, что последняя достаточна для повседневных практических нужд. В отличие от.
Рекомендую вам в следующих материалах подробнее рассказать про Zero Trust, NGFW (IPS/IDS, WAF).
Protos Автор
К сегментации сети это не имеет отношения
По тексту я как раз и указал не только балансировщик, но и веб сервер именно по этому, про любой сегмент я как раз и указываю про то, что база и не должна быть в сегменте DMZ, на L7 для нее и останутся угрозы SQL-инъекций, которые к счастью легко решаются.
up40k
Отсюда следующий шаг - микросегментация, сегментация сервисов.