Как стать автором
Обновить

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

Уровень сложности Простой
Время на прочтение 6 мин
Количество просмотров 72K
Всего голосов 11: ↑9 и ↓2 +7
Комментарии 17

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

балансировщик нагрузки и веб сервер - это те сетевые устройства, в которых наверняка почти сразу будут найдены уязвимости

Позвольте не согласиться. Уязвимости в первую очередь будут найдены там, где разработчик/администратор не позаботился обрабатывать данные, которые приходят от пользователя/настроить сервис должным образом с учётом модели угроз. Это всё на L7, и может оказаться в любом сегменте.
То, что вы в целом описали - безусловно хорошо и правильно для базового понимания, только ваше "для самых маленьких" чем-то напоминает курс школьной физики с её ньютоновской механикой. С той разницей, что последняя достаточна для повседневных практических нужд. В отличие от.
Рекомендую вам в следующих материалах подробнее рассказать про Zero Trust, NGFW (IPS/IDS, WAF).

Рекомендую вам в следующих материалах подробнее рассказать про Zero Trust, NGFW (IPS/IDS, WAF)

К сегментации сети это не имеет отношения

Это всё на L7, и может оказаться в любом сегменте

По тексту я как раз и указал не только балансировщик, но и веб сервер именно по этому, про любой сегмент я как раз и указываю про то, что база и не должна быть в сегменте DMZ, на L7 для нее и останутся угрозы SQL-инъекций, которые к счастью легко решаются.

К сегментации сети это не имеет отношения

Отсюда следующий шаг - микросегментация, сегментация сервисов.

Не очень понятно зачем вы от балансировщика до сервера указываете HTTP? Вы там терминируете HTTPS?

Верно

А не рано?

Мне тоже кажется что сейчас смысл терминирования HTTPS нету.
Дополнительная нагрузка на декодирование оценивается в максимум 2-3 процента от загрузки CPU.

Если стоит WAF, тогда конечно надо декодировать, но потом можно опять в защищеном канале отправить.

А получается что весь трафик в сети ходит открытый. Зависит конечно от конкретной ситуации, но если уж стоит тэг «информационная безопасность» — по идее не сильно большая плата за дополнительную защиту.

Если нет обработки биометрии, то внутри контролируемой зоны нет смысла шифровать трафик, ФСБ явно не требует если модель внутреннего нарушителя не предусматривает в явном виде. Если даже и есть WAF, то лишняя перешифровка все равно проблемки вызывает у WAF, нужно серты подсовывать для MiTM.

Перешифровывать можно сертификатами из своего CA. Кроме дополнительной нагрузки на шифрование, по идее не должно быть проблем.

Если несколько приложений живут в одном DMZ то есть шанс что можно чужой трафик подслушать на коммутаторах.

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

Нагрузка от декодирования HTTPS сильно зависит от количества новых клиентов в единицу времени клиентов (когда кэширование параметров сессии не особо помогает). Иногда приходится юзать даже аппаратные акселераторы для терминирования TLS.

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

Ну я рисовал зная, что дальше WAF стоит по привычке, но даже если нет, какой минус?

Тяжело читать статью. Все время уговариваешь себя, что человек, не осиливший азы пунктуации не обязательно так же плохо разбирается в вопросах сегментации.

Местами вспоминается один персонаж, что-то в духе: "Мы стали более лучше одеваться".

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

"DMZ - сегмент сети"

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

Базы данных - то сегмент, то зона третьего уровня, то сегмент в милитаризованной зоне.

Ну ввели терминологию и подход к классификации - следуйте ему хотя бы приличия ради.

Если ДМЗ все же зона, то это ОНА, а не он. Ну и так далее и тому подобное, от начала и до конца кровь из глаз.

По существу, не про запятые. Для новичка статья так себе. Не то, что бы мысли в целом какие-то особо неверные, но с ясностью мышления и акцентами именно для новичка, явные проблемы.

"..балансировщик нагрузки и веб сервер - это те сетевые устройства, в которых наверняка почти сразу будут найдены уязвимости".

Новичок сидит и думает. Ага, они (ну или он, веб сервер) имеют доступ к серверу приложений, в котором тоже наверняка будут найдены уязвимости, а у того есть доступ к базе, а в ней тоже наверняка уязвимости... В чем же фишка, сквозной пробой всего и вся от гланд до заднего прохода. Фишка несомненно есть и крайне простая и даже вскользь упомянута в статье, но крайне мутно.

ДОС на пограничный ФВ не самая большая беда. И если учесть, что ДМЗ делаются далеко не всегда на стыке публичных сетей с частными, а в т. ч. в пределах одной, допустим, корпоративной сети, заради разделения и безопасного инф. обмена частей сети с разным уровнем доверия/критичности, где ДОС маловероятен или вообще невозможен, все же два независимых ФВ делают и логика там ближе к чистой ИБ, чем к нагрузочным моментам.

На счет терминации HTTPS замечание другие комментаторы сделали верное. При чем тут обязательно комплайнс законодательный и ПД? А инфраструктура сетевая только из ФВ одних состоит? А она не может быть порутана? А не может так оказаться, что дальше самого внешнего ФВ злоумышленнику и не понадобится, он трафик ваш расшифрованный будет слушать и свой профит иметь (а ваша организация ущерб, отличный от последствий несоблюдения законодательства о ПД).

А если в ДМЗ не один веб сервер? И его порутать не смогли, а порутали соседний в той же зоне и ваш расшифрованный трафик перехватили атакой уровня L2? А уже с этого поимели и прямой профит и возможности продвинутся дальше по инфраструктуре?

На счет того, что к сегментации не имеют отношения разные там Zero Trust и вякие модные технологии в духе цисковских оверлеев и их механизмов безопасности.

Коллега! Еще как имеют. Потому что сегментация в классических сетях - это способ изоляции на базе топологии. Она (сегментация) не самоцель, у нее есть задачи, о которых вы написали крайне мало и сумбурно. Так вот, эти задачи могут решаться и несколько иначе. Или гибридно. Отчасти топологией построения, отчасти другими средствами.

И применение конкретных технологических погремух влияет на сегментацию, вопреки вашему комментарию.

15 или 20 лет назад, например, хочешь сегментации и тем более микросегментации (с контролируемым уровнем изоляции, а не просто так!) - нет вариантов особых, плоди Vlan, L3 сегменты, разделенные файрволами. Сейчас можно сделать одну большую плоскую сеть и эту самую микросегментацию получить + гибкая фильтрация + глубокий анализ и еще хз что.

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

А сейчас, выскажу возможно спорный для кого-то момент. Ваша картинка напоминает классические той же циски. На самой границе внешних сетей - роутер, потом файрвол. Так-то да. Тру роутер как роутер всегда обойдет роутер, сделанный из файрвола по функциям маршрутизации. Но всегда ли это нужно? Учитывая, что статья для новичков? В серьезной корп. сети, где всякие BGP с провайдерами, разветвленная филиальная сеть, миллион туннелей через Инет и хитрости динамической маршрутизации, наверное такая схема оправдана. А в обычной сети, где рулит новичок, этого всего не будет.

И пусть он или совместит внешний роутер с файрволом вопреки классической картинке или помнит, что если у него есть филиалы, подключенные не через Инет, а через выделенные каналы, какие-то другие части сети, свой, приватный WAN - ему нужен ЕЩЕ один роутер, назовем его опорный, который к данному, нарисованному, отношения не имеет и должен быть отдельный, спрятанный в т.ч. за какой-то ФВ. И когда он это поймет, то ну его нафик. На границу сети он поставить ФВ, который у вас на рисунке идет вторым и пусть этот ФВ выполняет простейшую маршрутизацию, обеспечивает дефолт через провайдера. А роутер спрячет за него и будет строить на нем внутренние коммуникации.

Возможно мелко плаваю как тех. специалист, но в достаточно большом Холдинге с филиальной структурой по стране, почти нигде не сделано по данной картинке. Везде на самой границе что-то специфически ИБшное, а не просто роутер с грубой предфильтрацией АЦЛ.

Но это ладно, может они/мы лохи. Но вот новичку я бы точно советовал как у вас нарисовано - не делать.

По поводу всех вами указанными новомодными погремухами, для всех финансовых организаций действует ГОСТ 575801.1-2017, а конкретно его мера:

СМЭ.15

Реализация сетевого взаимодействия и сетевой изоляции на уровне не выше третьего (сетевой) по семиуровневой стандартной модели взаимодействия открытых систем, определенной в ГОСТ Р ИСО/МЭК 7498-1, внутренних вычислительных сетей финансовой организации и сети Интернет

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

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

А если в ДМЗ не один веб сервер? И его порутать не смогли, а порутали соседний в той же зоне и ваш расшифрованный трафик перехватили атакой уровня L2?

Для этого разрабатывается защита на уровне L2 и к межсетевому экранированию не имеет отношения, следовательно в статье этого нет.

ДОС на пограничный ФВ не самая большая беда. И если учесть, что ДМЗ делаются далеко не всегда на стыке публичных сетей с частными, а в т. ч. в пределах одной, допустим, корпоративной сети, заради разделения и безопасного инф. обмена частей сети с разным уровнем доверия/критичности, где ДОС маловероятен или вообще невозможен, все же два независимых ФВ делают и логика там ближе к чистой ИБ, чем к нагрузочным моментам.

Не понял поток мыслей, наверное, вы писали про то, что каждая ИСПДн/направление бизнеса/ЮЛ в группе компаний/либо огромные связные наборы сетей/ либо еще по какой методике защищаемые разными межсетевыми экранами сегменты, для удобства защищаются разными МЭ. Оно?

Каждый сам решает как ему лучше, что у него будет на границе хоть группы внутренних сетей: МЭ, коммутатор либо роутер; внешних: роутер, средство защиты от ddos, мэ. Не важно крупная или мелкая компания - в компаниях каждого размера компаний бывает обычное межсетевое экранирование и каждый сам решает.

Возможно мелко плаваю как тех. специалист, но в достаточно большом Холдинге с филиальной структурой по стране, почти нигде не сделано по данной картинке. Везде на самой границе что-то специфически ИБшное, а не просто роутер с грубой предфильтрацией АЦЛ.

Но это ладно, может они/мы лохи. Но вот новичку я бы точно советовал как у вас нарисовано - не 

Судя по всему, вы сами не понимаете почему у вас так, а не как у меня и постулируете ваше решение как верное решение абзацами выше, причем не советуете делать так, хотя в начале пишите, что все указанное это спорный момент

Ну ок, прицепились к второстепенному, что и было мной отмечено, как спорное. Еще 31й или 239й приказ фстэк вспомните, мало ли есть каких ведомственных ограничений.

Статья сырая по факту и слабая. Мнение. Имею право. Не готовы к критике, в т.ч жесткой - не публикуйтесь, делов-то. Встречный совет, в ответ на предложение свою написать.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории