Ссылки на другие части
Все статьи цикла:
-
Трехуровневая архитектура (эта статья);
Введение
Цель статьи: показать базовый подход к сегментации сети компании при разработке новых либо модернизации текущих автоматизированных систем.
В статье рассмотрим:
-
Правила межсервисного взаимодействия.
![Правила межсетевого взаимодействия Правила межсетевого взаимодействия](https://habrastorage.org/getpro/habr/upload_files/c6e/5cf/265/c6e5cf2656456f68c1e8eab0a130e169.jpg)
Демилитаризованная зона (DMZ, уровень I)
Начнем рассмотрение принципов межсетевого экранирования и сегментации сети со следующей схемы:
-
Пограничный маршрутизатор — соединяет нашу корпоративную сеть с пограничным межсетевым экраном, фильтрует трафик по ACL на 3-м уровне модели OSI;
-
Межсетевой экран — защищает сеть на 4-м уровне модели OSI, «терминирует» соединения;
-
Балансировщик нагрузки — ПО, выполняющее распределение нагрузки между веб серверами, расшифрование HTTPS трафика;
-
Веб сервер — первичный сервер реализующий обработку входящих запросов.
Зона (зона безопасности) — набор сегментов сети содержащих серверы одного назначения, например, сегменты содержащие только базы данных, или сегменты содержащие только персональные рабочие станции, и т.д.
DMZ — сегмент сети, предназначенный для размещения сетевых устройств взаимодействующих с внешними сетями, в частности с сетью интернет.
Логическая схема одноуровневой сети:
![Первый уровень Первый уровень](https://habrastorage.org/getpro/habr/upload_files/f37/dd4/fa7/f37dd4fa7f66c7578f763f31351aca32.jpg)
На картинке стрелка означает наличие сетевого доступа с IP адресом источника от того сетевого устройства от которого стрелка отходит, и с IP адресом назначения того сетевого устройства к которому стрелка направлена. Двухсторонняя стрелка соответственно будет означать наличие двух правил межсетевого экранирования в таблице правил межсетевого экранирования.
Давайте посмотрим как будут выглядеть правила межсетевого экранирования при прохождении обоих межсетевых экранов уровня сети:
![Правила межсетевого экранирования Правила межсетевого экранирования](https://habrastorage.org/getpro/habr/upload_files/05f/f0e/574/05ff0e5747be2dc4bf2aab2dd3453057.jpg)
Где HTTP — это транспортный протокол TCP и порт стандартный — 80-й.
Как видим правила 2, правила могут быть как и идентичными, так и более широкими у того межсетевого экрана из-за которого трафик выходит, а более точечными за межсетевым экраном который трафик принимает. Так проще писать правила на межсетевом экране из-за которого трафик выходит, достаточно написать одно правило и если серверов много, то множество дублирующих правил писать не потребуется. То есть допустимы и такие правила:
![Максимально широкие правила Максимально широкие правила](https://habrastorage.org/getpro/habr/upload_files/0e8/555/964/0e85559649ab064e5427e9b6b5a31b23.jpg)
Вот мы заодно рассмотрели и как понять какое правило межсетевого экранирования требуется написать.
С точки зрения практической безопасности, бОльшую роль играет тот факт, что балансировщик нагрузки и веб сервер — это те сетевые устройства, в которых наверняка почти сразу будут найдены уязвимости, а в случае нахождения уязвимостей удаленного выполнения кода (RCE) злоумышленник сможет получить высокие права в операционной системе. В таком случае если бы на сервере была база данных, то злоумышленник достаточно быстро смог бы до нее добраться.
Так же веб сервер выполняет первичную проверку данных на соответствие каким-то правилам и стандартам: как внутренним так и общеизвестным, например, XML проверяются по
После первичной проверки, данные можно передавать веб приложению, выполняющее основную логику сервиса и размещенное на отдельном сервере:
![Второй уровень сети Второй уровень сети](https://habrastorage.org/getpro/habr/upload_files/ed4/627/a1d/ed4627a1dcee4657875c527fac6ae224.jpg)
Схема для удобства упрощена до 3-х серверов:
-
Сервер с балансировщиком нагрузки;
-
Сервер с веб сервером;
-
Сервер с веб приложением.
Обратим внимание на пунктирную линию, она показывает следующее: все что за демилитаризованной зоной, является милитаризованной зоной, защищаемой другим межсетевым экраном. Отдельный межсетевой экран важен по следующей причине: если из сети интернет будет перегружен пограничный межсетевой экран, то вся сеть перестанет работать, он не сможет пропускать через себя трафик сегментов второго уровня. Если у нас 2 межсетевых экрана, то внутреннее взаимодействие при отказе пограничного межсетевого экрана сохранится:
![Последствия DDoS пограничного МЭ Последствия DDoS пограничного МЭ](https://habrastorage.org/getpro/habr/upload_files/67e/359/ceb/67e359ceb5dc18be6c83b472250b9ae6.jpg)
Чтобы больше понять что же такое сегмент, а что такое зона, усложним схему: представим, что наша компания разрешает аутентификацию пользователей через внешнего провайдера аутентификации, пускай это будет
Как видим, пунктирный прямоугольник логически объединяет все сетевые сегменты уровня 2 — сегменты приложений, в данном примере в каждом из сегментов по одному серверу.
В демилитаризованной зоне у нас так же 2 сетевых сегмента, в исходном размещено 2 сервера, в новом — 1.
Давайте вернемся к упрощенной схеме с одним сервисом. Давайте взглянем на наше монолитное приложение с огромным количеством строк кода в разрезе сервера:
![Монолитная архитектура Монолитная архитектура](https://habrastorage.org/getpro/habr/upload_files/9b2/0a0/349/9b20a03491f878e0a97a7e4490eff4f7.jpg)
Мы видим, что на серверах могут быть размещены какие-то файлы необходимые для работы приложений, могут быть запущены сами приложения. Давайте представим, что у нас не одно монолитное приложение, а множество маленьких приложений и все они вместе решают всё ту же задачу, только размещены на разных серверах:
![Микросервисная архитектура Микросервисная архитектура](https://habrastorage.org/getpro/habr/upload_files/c3d/ee2/dfd/c3dee2dfd9c45e263ba6ded4b5094451.jpg)
Теперь у изначального сервиса может в единственном сетевом сегменте приложений быть уже N серверов.
Мы можем разрабатывать наши сервисы так:
-
Один DMZ только для входящих соединений из внешних сетей;
-
Другой DMZ только для исходящих соединений.
Такая хитрость позволит уменьшить возможные векторы атаки на нашу базу данных, но увеличит количество серверов и правил межсетевого экранирования:
![2 типа DMZ 2 типа DMZ](https://habrastorage.org/getpro/habr/upload_files/be4/77b/b26/be477bb26e4a2a5dcb33ab4f8da5421b.jpg)
Как видим на картинке у нас есть DMZ 1 и DMZ 2. Например, в случае компрометации балансировщика, злоумышленник не сможет атаковать серверы в DMZ 2 из-за отсутствия правил разрешающих трафик, злоумышленнику сначала придется найти уязвимость в веб приложении в сегменте приложений, получить высокие привилегии в операционной системе сервера с веб приложением и только потом он сможет атаковать серверы в DMZ 2.
В таком случае становится возможным разрешить исходящие доступы во внешние сети из сегментов уровня 2 — APP минуя DMZ, так как особо демилитаризованная зона не дает какой-либо защиты:
![APP -> внешние сети» title=»APP -> внешние сети» width=»1482″ height=»482″ data-src=»https://habrastorage.org/getpro/habr/upload_files/bbf/eac/997/bbfeac99767232112cb183f9dae5aeb6.jpg» data-blurred=»true»/></p>
<div><figcaption>APP -> внешние сети</figcaption></div>
</figure>
<p>При этом стоит предполагать, что доступ открывается на известные DNS имена, а не на IP адреса либо во весь интернет. IP адрес может быть выдан нескольким владельцам, один из которых окажется злоумышленником То есть создавать можно только точечные доступы до доверенных сервисов в сети интернет.</p>
<h2>Сегмент баз данных (DB, уровень III)</h2>
<p><a class=](https://habrastorage.org/r/w780q1/getpro/habr/upload_files/bbf/eac/997/bbfeac99767232112cb183f9dae5aeb6.jpg)
В процессе работы с данными, их необходимо где-то хранить, это могут быть различные базы данных SQL и no-SQL, файловые хранилища, каталоги LDAP, хранилища криптографических ключей, паролей и т.д.
Так мы переходим к зоне третьего уровня — DB.
![Третий уровень, уровень данных Третий уровень, уровень данных](https://habrastorage.org/getpro/habr/upload_files/0d5/c6e/b57/0d5c6eb578481d194b353175ce308248.jpg)
На картинке не нарисован третий межсетевой экран, давайте представлять, что пересечение прямоугольника показывающего границы сегмента сети = пересечение межсетевого экрана, то есть считаем, что любое перемещение трафика между сегментами это прохождение трафика через межсетевой экран. Упрощенная схема:
![Третий уровень, уровень данных (без сетевых устройств) Третий уровень, уровень данных (без сетевых устройств)](https://habrastorage.org/getpro/habr/upload_files/1b8/f8a/7c0/1b8f8a7c0387d6900e492118388e74c6.jpg)
Если есть желание отображать межсетевые экраны, их можно рисовать так:
![Отображение межсетевых экранов цветами Отображение межсетевых экранов цветами](https://habrastorage.org/getpro/habr/upload_files/cfe/c3d/753/cfec3d7531abb6cd548685dd928190fe.jpg)
Так мы не сильно нагружая картинку показываем за каким межсетевым экраном какие сегменты находятся. Изображать можно и как-то иначе, например, выделяя сегменты определенным цветом.
Межсервисное взаимодействие
Межсервисное взаимодействие — взаимодействие серверов разных сервисов между собой. Такое взаимодействие должно предусматривать правила взаимной аутентификации серверов между собой и правила межсетевого экранирования.
Идеальная ситуация если в организации между серверами сервисов взаимодействие происходит всегда через демилитаризованную зону:
![Идеальное межсервисное взаимодействие Идеальное межсервисное взаимодействие](https://habrastorage.org/getpro/habr/upload_files/850/889/914/850889914447415c569edfd290305e42.jpg)
Теперь представим, что мы достаточно безопасно настроили каждый сервер и приложения, мы доверяем администраторам, у нас имеются средства защиты серверов, двухсторонняя усиленная аутентификация и т.д. Так же в случае если в организации объявить такую политику, то администраторы, архитекторы сервисов вместо разработки сервисов по объявленной политике, в DMZ будут размещать безусловные прокси серверы, которые просто будут проксировать трафик между сегментами DMZ 1 и DMZ 2 без какой-либо проверки. То есть политика будет исполняться лишь формально.
В таком случае, логичным будет разрешить такие взаимодействия:
![Межсервисное взаимодействие с учетом рисков Межсервисное взаимодействие с учетом рисков](https://habrastorage.org/getpro/habr/upload_files/10c/af5/93e/10caf593e0ca2650ac2d2fa3c3c1a1d9.jpg)
То есть мы разрешаем условно любые взаимодействия между зонами DMZ и APP всех сервисов внутри компании.
При этом, доступ в базу данных чужого сервиса нельзя разрешать ни в коем случае.
Итог
В итоге мы получаем такой перечень основных базовых правил определения возможности предоставления сетевого доступа:
![Правила межсетевого взаимодействия Правила межсетевого взаимодействия](https://habrastorage.org/getpro/habr/upload_files/711/1f1/f55/7111f1f558ae35589acef85e7b3d4440.jpg)
Бонус
Если вы дочитали до конца, Вам может быть интересен проект Network-segmentation-cheet-sheet
![](https://habrastorage.org/getpro/habr/upload_files/ba3/95d/c82/ba395dc82b891c2695a8d9a3cb57e9f9.jpg)
ссылка на оригинал статьи https://habr.com/ru/articles/588705/
Добавить комментарий