Сегментация сети для самых маленьких |
||
МЕНЮ Главная страница Поиск Регистрация на сайте Помощь проекту Архив новостей ТЕМЫ Новости ИИ Голосовой помощник Разработка ИИГородские сумасшедшие ИИ в медицине ИИ проекты Искусственные нейросети Искусственный интеллект Слежка за людьми Угроза ИИ ИИ теория Внедрение ИИКомпьютерные науки Машинное обуч. (Ошибки) Машинное обучение Машинный перевод Нейронные сети начинающим Психология ИИ Реализация ИИ Реализация нейросетей Создание беспилотных авто Трезво про ИИ Философия ИИ Big data Работа разума и сознаниеМодель мозгаРобототехника, БПЛАТрансгуманизмОбработка текстаТеория эволюцииДополненная реальностьЖелезоКиберугрозыНаучный мирИТ индустрияРазработка ПОТеория информацииМатематикаЦифровая экономика
Генетические алгоритмы Капсульные нейросети Основы нейронных сетей Распознавание лиц Распознавание образов Распознавание речи Творчество ИИ Техническое зрение Чат-боты Авторизация |
2021-11-17 17:00 Введение Цель статьи: показать базовый подход к сегментации сети компании при разработке новых либо модернизации текущих автоматизированных систем. Демилитаризованная зона (DMZ, уровень I) Начнем рассмотрение принципов межсетевого экранирования и сегментации сети со следующей схемы:
Зона (зона безопасности) - набор сегментов сети содержащих серверы одного назначения, например, сегменты содержащие только базы данных, или сегменты содержащие только персональные рабочие станции, и т.д. DMZ - сегмент сети, предназначенный для размещения сетевых устройств взаимодействующих с внешними сетями, в частности с сетью интернет. Логическая схема одноуровневой сети: На картинке стрелка означает наличие сетевого доступа с IP адресом источника от того сетевого устройства от которого стрелка отходит, и с IP адресом назначения того сетевого устройства к которому стрелка направлена. Двухсторонняя стрелка соответственно будет означать наличие двух правил межсетевого экранирования в таблице правил межсетевого экранирования. Давайте посмотрим как будут выглядеть правила межсетевого экранирования при прохождении обоих межсетевых экранов уровня сети: Где HTTP - это транспортный протокол TCP и порт стандартный - 80-й. Как видим правила 2, правила могут быть как и идентичными, так и более широкими у того межсетевого экрана из-за которого трафик выходит, а более точечными за межсетевым экраном который трафик принимает. Так проще писать правила на межсетевом экране из-за которого трафик выходит, достаточно написать одно правило и если серверов много, то множество дублирующих правил писать не потребуется. То есть допустимы и такие правила: Вот мы заодно рассмотрели и как понять какое правило межсетевого экранирования требуется написать. С точки зрения практической безопасности, бОльшую роль играет тот факт, что балансировщик нагрузки и веб сервер - это те сетевые устройства, в которых наверняка почти сразу будут найдены уязвимости, а в случае нахождения уязвимостей удаленного выполнения кода (RCE) злоумышленник сможет получить высокие права в операционной системе. В таком случае если бы на сервере была база данных, то злоумышленник достаточно быстро смог бы до нее добраться. Так же веб сервер выполняет первичную проверку данных на соответствие каким-то правилам и стандартам: как внутренним так и общеизвестным, например, XML проверяются по DTD, а сами полезные данные, на соответствие форматам данным, например, проверка того, что в поле для чисел пользователь вписал действительно числа, а не только символы. Грубо говоря, в демилитаризованной зоне размещается то, что не жалко потерять, что потенциально может быть легко скомпрометировано. Давайте пойдем дальше и перейдем к сегменту приложений (APP). Сегмент приложений (APP, уровень II) После первичной проверки, данные можно передавать веб приложению, выполняющее основную логику сервиса и размещенное на отдельном сервере: Cхема для удобства упрощена до 3-х серверов:
Обратим внимание на пунктирную линию, она показывает следующее: все что за демилитаризованной зоной, является милитаризованной зоной, защищаемой другим межсетевым экраном. Отдельный межсетевой экран важен по следующей причине: если из сети интернет будет перегружен пограничный межсетевой экран, то вся сеть перестанет работать, он не сможет пропускать через себя трафик сегментов второго уровня. Если у нас 2 межсетевых экрана, то внутреннее взаимодействие при отказе пограничного межсетевого экрана сохранится: Чтобы больше понять что же такое сегмент, а что такое зона, усложним схему: представим, что наша компания разрешает аутентификацию пользователей через внешнего провайдера аутентификации, пускай это будет Единая система идентификации и аутентификации (ЕСИА). В таком случае? у нас появляется еще один сервис помимо того, что у нас уже имеется - сервис аутентификации: Как видим, пунктирный прямоугольник логически объединяет все сетевые сегменты уровня 2 - сегменты приложений, в данном примере в каждом из сегментов по одному серверу. В демилитаризованной зоне у нас так же 2 сетевых сегмента, в исходном размещено 2 сервера, в новом - 1. Давайте вернемся к упрощенной схеме с одним сервисом. Давайте взглянем на наше монолитное приложение с огромным количеством строк кода в разрезе сервера: Мы видим, что на серверах могут быть размещены какие-то файлы необходимые для работы приложений, могут быть запущены сами приложения. Давайте представим, что у нас не одно монолитное приложение, а множество маленьких приложений и все они вместе решают всё ту же задачу, только размещены на разных серверах: Теперь у изначального сервиса может в единственном сетевом сегменте приложений быть уже N серверов. Мы можем разрабатывать наши сервисы так:
Такая хитрость позволит уменьшить возможные векторы атаки на нашу базу данных, но увеличит количество серверов и правил межсетевого экранирования: Как видим на картинке у нас есть 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 всех сервисов внутри компании. При этом, доступ в базу данных чужого сервиса нельзя разрешать ни в коем случае. Итог В итоге мы получаем такой перечень основных базовых правил определения возможности предоставления сетевого доступа: Источник: Хабр Источник: m.vk.com Комментарии: |
|