Эта статья является третьей в серии статей «Как взять под контроль вашу сетевую инфраструктуру».
Содержание всех статей серии и ссылки можно найти Здесь .
Говорить о полном устранении угроз безопасности нет смысла.
В принципе, мы не можем свести их к нулю.
Нам также необходимо понимать, что по мере того, как мы стремимся сделать сеть все более безопасной, наши решения становятся все дороже.
Вам необходимо найти компромисс между стоимостью, сложностью и безопасностью, который имеет смысл для вашей сети.
Разумеется, проектирование безопасности органично интегрировано в общую архитектуру, и используемые решения по обеспечению безопасности влияют на масштабируемость, надежность, управляемость.
сетевой инфраструктуры, что также необходимо учитывать.
Но напомню, что сейчас речь не идет о создании сети.
По нашему первоначальные условия мы уже выбрали дизайн, выбрали оборудование, создали инфраструктуру, и на этом этапе, по возможности, мы должны «жить» и находить решения в контексте выбранного ранее подхода.
Наша задача сейчас — выявить риски, связанные с безопасностью на сетевом уровне, и снизить их до разумного уровня.
Аудит сетевой безопасности Если ваша организация внедрила процессы ISO 27k, то аудит безопасности и изменения в сети должны органично вписываться в общие процессы в рамках этого подхода.
Но эти стандарты все же не о конкретных решениях, не о настройке, не о дизайне.
Нет четких советов, нет стандартов, подробно диктующих, какой должна быть ваша сеть, в этом сложность и красота этой задачи.
Я бы выделил несколько возможных проверок сетевой безопасности:
аудит конфигурации оборудования (укрепление безопасности) аудит проектирования безопасности аудит доступа аудит процесса Аудит конфигурации оборудования (укрепление безопасности) Похоже, что в большинстве случаев это лучшая отправная точка для аудита и повышения безопасности вашей сети.ИМХО, это хорошая демонстрация закона Парето (20% усилий дают 80% результата, а оставшиеся 80% усилий дают только 20% результата).
Суть в том, что у нас обычно есть рекомендации от поставщиков относительно «лучших практик» безопасности при настройке оборудования.
Это называется «закаливание».
Также на основе этих рекомендаций вы часто можете найти опросник (или создать его самостоятельно), который поможет вам определить, насколько конфигурация вашего оборудования соответствует этим «лучшим практикам» и в соответствии с результатом внести изменения в вашу сеть.
.
Это позволит вам довольно легко и практически бесплатно значительно снизить риски безопасности.
Несколько примеров для некоторых операционных систем Cisco. Усиление конфигурации Cisco IOS Усиление конфигурации Cisco IOS-XR Усиление конфигурации Cisco NX-OS Контрольный список базовой безопасности Cisco На основании этих документов может быть сформирован перечень требований к конфигурации для каждого типа оборудования.Таким образом, файлы конфигурации могут быть созданы для разных типов активного оборудования в вашей сетевой инфраструктуре.Например, для Cisco N7K VDC эти требования могут выглядеть так: Так .
Далее вручную или с помощью автоматизации можно «загрузить» эти файлы конфигурации.
Как автоматизировать этот процесс, будет подробно рассмотрено в другой серии статей об оркестровке и автоматизации.
Аудит проектирования безопасности Обычно сеть предприятия содержит в том или ином виде следующие сегменты: DC (демилитаризованная зона государственных услуг и центр обработки данных внутренней сети) доступ в Интернет VPN с удаленным доступом WAN-периферия Ветвь Кампус (Офис) Основной Названия взяты из Cisco БЕЗОПАСНЫЙ модели, но не обязательно, конечно, привязываться именно к этим названиям и к этой модели.
Все-таки хочется говорить о сути и не увязнуть в формальностях.
Для каждого из этих сегментов требования безопасности, риски и, соответственно, решения будут разными.
Давайте рассмотрим каждый из них отдельно, чтобы выявить проблемы, с которыми вы можете столкнуться с точки зрения проектирования безопасности.
Конечно, еще раз повторю, что данная статья ни в коей мере не претендует на полноту, чего нелегко (если не невозможно) добиться в этой поистине глубокой и многогранной теме, но она отражает мой личный опыт. Идеального решения не существует (по крайней мере, пока).
Это всегда компромисс.
Но важно, чтобы решение об использовании того или иного подхода принималось осознанно, с пониманием как его плюсов, так и минусов.
Дата центр
Самый критичный сегмент с точки зрения безопасности.И, как обычно, универсального решения здесь тоже нет. Все сильно зависит от требований сети.
Нужен ли брандмауэр или нет?
Казалось бы, ответ очевиден, но не все так однозначно, как может показаться.И на ваш выбор может повлиять не только цена .
Пример 1. Задержки.Если низкая задержка является существенным требованием между некоторыми сегментами сети, что справедливо, например, в случае обмена, то мы не сможем использовать межсетевые экраны между этими сегментами.
Трудно найти исследования по задержке в межсетевых экранах, но немногие модели коммутаторов могут обеспечить задержку менее или порядка 1 мкс, поэтому я думаю, что если для вас важны микросекунды, то межсетевые экраны не для вас.
Пример 2. Производительность.Пропускная способность топовых коммутаторов L3 обычно на порядок превышает пропускную способность самых мощных межсетевых экранов.
Поэтому в случае трафика высокой интенсивности вам также, скорее всего, придется разрешить этому трафику обходить фаерволы.
Пример 3. Надежность.В случае с приведенными примерами вам, скорее всего (как обычно), придется искать компромисс.Межсетевые экраны, особенно современные NGFW (Next-Generation FW), являются сложными устройствами.
Они намного сложнее, чем переключатели L3/L2. Они предоставляют большое количество сервисов и возможностей конфигурации, поэтому неудивительно, что их надежность значительно ниже.
Если непрерывность обслуживания имеет решающее значение для сети, то вам, возможно, придется выбирать, что приведет к повышению доступности — безопасность с помощью межсетевого экрана или простота сети, построенной на коммутаторах (или различных видах фабрик) с использованием обычных ACL.
Посмотрите на следующие решения: если вы решили не использовать межсетевые экраны внутри дата-центра, то вам нужно подумать о том, как максимально ограничить доступ по периметру.
Например, открыть из Интернета только необходимые порты (для клиентского трафика) и административный доступ к дата-центру можно только с переходных хостов.
На переходных хостах выполните все необходимые проверки (аутентификация/авторизация, антивирус, ведение журнала и т. д.).
можно использовать логическое разделение сети дата-центра на сегменты, аналогично схеме, описанной в PSEFABRIC. пример p002 .
При этом маршрутизация должна быть настроена таким образом, чтобы чувствительный к задержкам или высокоинтенсивный трафик шел «внутри» одного сегмента (в случае p002 — VRF) и не проходил через межсетевой экран.
Трафик между различными сегментами продолжит проходить через межсетевой экран.
Вы также можете использовать утечку маршрутов между VRF, чтобы избежать перенаправления трафика через брандмауэр.
Вы также можете использовать межсетевой экран в прозрачном режиме и только для тех VLAN, где эти факторы (задержка/производительность) не существенны.
Но нужно внимательно изучить ограничения, связанные с использованием данного мода у каждого вендора.
вы можете рассмотреть возможность использования архитектуры цепочки обслуживания.
Это позволит проходить через брандмауэр только необходимому трафику.
Теоретически выглядит красиво, но я никогда не видел такого решения в производстве.
Мы тестировали сервисную цепочку для Cisco ACI/Juniper SRX/F5 LTM около 3 лет назад, но тогда это решение показалось нам «сырым».
Уровень защиты
Теперь вам нужно ответить на вопрос, какие инструменты вы хотите использовать для фильтрации трафика.Вот некоторые функции, которые обычно присутствуют в NGFW (например, здесь ): брандмауэр с отслеживанием состояния (по умолчанию) брандмауэр приложений предотвращение угроз (антивирус, антишпионское ПО и уязвимости) URL-фильтрация фильтрация данных (фильтрация контента) блокировка файлов (блокировка типов файлов) дос-защита И тоже не все ясно.
Казалось бы, чем выше уровень защиты, тем лучше.
Но вам также нужно учитывать, что Чем больше вышеперечисленных функций межсетевого экрана вы используете, тем дороже он, естественно, будет (лицензии, дополнительные модули) использование некоторых алгоритмов может значительно снизить пропускную способность межсетевого экрана, а также увеличить задержки, см.
например здесь как и любое сложное решение, использование сложных методов защиты может снизить надежность вашего решения, например, при использовании межсетевого экрана приложений я столкнулся с блокировкой некоторых вполне стандартных рабочих приложений (dns, smb) Как всегда, вам нужно найти лучшее решение для вашей сети.
Невозможно однозначно ответить на вопрос, какие функции защиты могут потребоваться.
Во-первых, потому что это, конечно, зависит от данных, которые вы передаете или храните и пытаетесь защитить.
Во-вторых, на самом деле зачастую выбор средств защиты — это вопрос веры и доверия к вендору.
Вы не знаете алгоритмы, не знаете, насколько они эффективны, и не можете их полностью протестировать.
Поэтому в критических сегментах хорошим решением может стать использование предложений разных компаний.
Например, вы можете включить антивирус на брандмауэре, но также использовать антивирусную защиту (другого производителя) локально на хостах.
Сегментация
Речь идет о логической сегментации сети дата-центра.Например, разбиение на VLAN и подсети — это тоже логическая сегментация, но мы не будем ее рассматривать в силу ее очевидности.
Интересная сегментация с учетом таких сущностей, как зоны безопасности FW, VRF (и их аналоги применительно к различным производителям), логические устройства (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant,.
),.
Пример такой логической сегментации и востребованного на данный момент проекта ЦОД приведен на рис.Определив логические части вашей сети, вы сможете затем описать, как трафик перемещается между разными сегментами, на каких устройствах и какими средствами будет производиться фильтрация.
Если в вашей сети нет четкого логического раздела и правила применения политик безопасности для разных потоков данных не формализованы, это означает, что при открытии того или иного доступа вы вынуждены решать эту проблему, и с большой вероятностью вы будет решать это каждый раз по-разному.
Часто сегментация основана только на зонах безопасности FW. Тогда вам необходимо ответить на следующие вопросы: какие зоны безопасности вам нужны
какой уровень защиты вы хотите применить к каждой из этих зон
будет ли разрешен внутризоновый трафик по умолчанию?
если нет, какие политики фильтрации трафика будут применяться в каждой зоне
какие политики фильтрации трафика будут применяться для каждой пары зон (источник/назначение)
ТКАМ
Распространенной проблемой является недостаточность TCAM (тройной адресуемой памяти по содержимому) как для маршрутизации, так и для доступа.ИМХО, это один из самых важных вопросов при выборе оборудования, поэтому относиться к этому вопросу нужно с соответствующей степенью внимательности.
Пример 1. Таблица пересылки TCAM. Давайте рассмотрим Пало-Альто 7к брандмауэр Мы видим, что размер таблицы пересылки IPv4* = 32 КБ.При этом данное количество маршрутов является общим для всех ВСИС.
Предположим, что по вашему проекту вы решили использовать 4 VSYS. Каждый из этих VSYS подключен через BGP к двум MPLS PE облака, которые вы используете в качестве BB. Таким образом, 4 VSYS обмениваются между собой всеми конкретными маршрутами и имеют таблицу пересылки примерно с одинаковыми наборами маршрутов (но разными NH).
Поскольку каждый VSYS имеет 2 BGP-сессии (с одинаковыми настройками), то каждый маршрут, полученный через MPLS, имеет 2 NH и соответственно 2 FIB записи в Forwarding Table. Если предположить, что это единственный межсетевой экран в дата-центре и он должен знать обо всех маршрутах, то это будет означать, что общее количество маршрутов в нашем дата-центре не может быть больше 32К/(4*2) = 4К.
Теперь, если мы предположим, что у нас 2 дата-центра (с одинаковым дизайном), и мы хотим использовать VLAN, «растянутые» между дата-центрами (например, для vMotion), то для решения проблемы маршрутизации мы должны использовать маршруты хостов.
Но это значит, что на 2 дата-центра у нас будет не более 4096 возможных хостов и этого, конечно, может быть недостаточно.
Пример 2. ACL TCAM. Если вы планируете фильтровать трафик на коммутаторах L3 (или других решениях, использующих коммутаторы L3, например Cisco ACI), то при выборе оборудования следует обратить внимание на TCAM ACL. Предположим, вы хотите контролировать доступ на SVI-интерфейсах Cisco Catalyst 4500. Тогда, как видно из Эта статья , для управления исходящим (как и входящим) трафиком на интерфейсах можно использовать всего 4096 линий TCAM. Что при использовании TCAM3 даст вам около 4000 тысяч ACE (линий ACL).Если вы столкнулись с проблемой недостаточного TCAM, то в первую очередь, конечно, нужно рассмотреть возможность оптимизации.
Итак, в случае проблемы с размером Forwarding Table нужно рассмотреть возможность агрегации маршрутов.
В случае проблемы с размером TCAM для доступов, проведите аудит доступов, удалите устаревшие и перекрывающиеся записи, а также, возможно, пересмотрите процедуру открытия доступов (подробно будет рассмотрено в главе, посвященной аудиту доступов).
Высокая доступность
Вопрос в следующем: стоит ли использовать HA для межсетевых экранов или установить два независимых бокса «параллельно» и в случае отказа одного из них маршрутизировать трафик через второй? Казалось бы, ответ очевиден — использовать HA. Причина, по которой этот вопрос до сих пор возникает, заключается в том, что, к сожалению, теоретические и рекламные 99 и несколько десятичных процентов доступности на практике оказываются далеко не такими радужными.HA логически довольно сложная вещь, и на разном оборудовании, и у разных вендоров (исключений не было), мы ловили проблемы и баги и остановки сервиса.
Если вы используете HA, у вас будет возможность отключать отдельные узлы, переключаться между ними без остановки сервиса, что важно, например, при проведении апгрейдов, но при этом у вас есть далеко не нулевая вероятность того, что оба узла сломается при этом, а также то, что следующий апгрейд пройдет не так гладко, как обещает производитель (этой проблемы можно избежать, если иметь возможность протестировать апгрейд на лабораторном оборудовании).
Если вы не используете HA, то с точки зрения двойного сбоя ваши риски гораздо ниже (поскольку у вас 2 независимых межсетевых экрана), но поскольку.
сессии не синхронизированы, то при каждом переключении между этими межсетевыми экранами вы будете потерять трафик.
Можно, конечно, использовать межсетевой экран без сохранения состояния, но тогда смысл использования межсетевого экрана во многом теряется.
Поэтому, если в результате аудита вы обнаружили одинокие межсетевые экраны и задумались о повышении надежности своей сети, то HA, конечно, является одним из рекомендуемых решений, но следует учитывать и недостатки, связанные с этим.
при таком подходе и, возможно, конкретно для вашей сети, больше подойдет другое решение.
Управляемость
В принципе ХА это еще и про управляемость.Вместо того, чтобы настраивать два устройства по отдельности и решать проблему синхронизации конфигураций, вы управляете ими так, как если бы у вас было одно устройство.
Но возможно у вас много дата-центров и много межсетевых экранов, тогда этот вопрос встает на новом уровне.
И вопрос не только в настройке, но и в конфигурации резервного копирования обновления обновления мониторинг Ведение журнала И все это можно решить с помощью централизованных систем управления.
Так, например, если вы используете межсетевые экраны Пало-Альто, то Панорама такое решение.Продолжение следует. Теги: #информационная безопасность #Сетевые технологии #ИТ-инфраструктура #DevOps #процессы в ней #сетевая инфраструктура #сетевая архитектура #сетевая безопасность #сетевое проектирование #управление сетевым отделом
-
Центр Обработки Данных Космической Сети
19 Oct, 24 -
Создание Домашнего Медиацентра. Пролог
19 Oct, 24 -
Школьный Linux Для Niro
19 Oct, 24 -
Подкаст Unclesoky - Эпизод №30
19 Oct, 24 -
Безопасность Ядерного Оружия Для Гиков
19 Oct, 24 -
Первый Коворкинг-Офис В Киеве: Фото
19 Oct, 24
