макросегментация VN для регулируемой отрасли
-
Привет всем, Мы настраиваем Cisco SD-Access для регулируемой среды, соответствующей требованиям HIPAA, и нам нужен совет по сегментации VRF и настройке безопасности. В качестве устройства слияния мы используем брандмауэр. Этот же брандмауэр контролирует доступ к серверам центра обработки данных (восток-запад в ЦОД и север-юг), общим службам и границе Интернета. Мы планируем создать отдельные VRF в структуре SD-Access, чтобы обеспечить изоляцию и соответствие различных сегментов (макросегментация). Вот что мы рассматриваем. Корпоративные пользователи (1 VRF включает все IDF, например IDF VRF)
Критические пользователи (например, Finance VRF, IT VRF)
Гости
CCTV
Контроль доступа
Система управления зданием
HVAC
IoT VRF (отдельные VRF для каждой системы IoT)
Медицинское оборудование поставщиков VRF (отдельные VRF для каждого поставщика) Любое устройство в VRF, которое необходимо подключить к серверам центра обработки данных или к Интернету, будет проходить через брандмауэр, что обеспечит соблюдение политики безопасности. Мы также будем контролировать любую межсетевую коммуникацию через брандмауэр. Заранее благодарю. Буду признателен за любой совет! Можно ли создать столько VRF (около 20+) в SD-Access для макросегментации? В этой развертке у нас также есть Cisco ISE. Мы знаем, что SGT предназначен для бокового контроля в пределах одного VRF, а не для связи между северной и южной частями, поэтому в нашем случае брандмауэр является лучшим вариантом. -
Привет! Звучит как хороший проект. Несколько моментов для рассмотрения. Самый большой сайт SDA Fabric, который я видел, имеет около 90 виртуальных сетей уровня 3 (L3VN). Вы должны убедиться, что пограничные узлы могут справиться с таким масштабом. Проверьте спецификацию Catalyst Center, например, 9200L поддерживает только одну L3VN.
Использование большого количества L3VN увеличивает административную нагрузку на сетевого администратора, например, больше BGP-пирингов между BN и fusion, больше конфигураций fusion routing, больше L3VN в CatC и т. д. Это не плохо, просто нужно иметь это в виду. Если клиенту действительно нужно около 20 L3VN, то это нормально, но если их количество можно сократить, скажем, до 10 (или любого другого числа), то в долгосрочной перспективе это обычно упрощает работу. TLDR, придерживайтесь разумного минимума.
SGT можно использовать для меж-VRF политики, если это необходимо. Необходимо включить распространение SGT на BN в направлении fusion, а fusion должен отправить SGT обратно (некоторые устройства fusion, не относящиеся к Cisco, могут отбрасывать SGT). Однако FW имеет значительно больше возможностей по сравнению с SGACL на коммутаторе, например, FW имеет проверку приложений, распознавание состояния, IPS/IDS, гарантированную регистрацию пакетов и т. д. С уважением, Джером -
Это один из вариантов использования. Но если цель состоит в том, чтобы заблокировать доступ между подсетями, реализация не будет простой, поскольку для трафика внутри VRF потребуется масштабируемый и поддерживаемый способ сопоставления IP-подсети с SGT. Если подсети сопоставляются 1:1 с VLAN, вы можете настроить сопоставление VLAN-SGT на пограничных узлах, но я не помню, есть ли возможность автоматизировать это с помощью DNAC.
В качестве альтернативы, если вы ослабите требование «между IP-пулами», вы просто назначите SGT по порту или по сеансу AAA (с точностью до MAC), и это рекомендуемый и простой подход. -
@techno.it
написал:
Просто для лучшего понимания: может ли SGT блокировать связь между двумя пулами IP-адресов в пределах одного VRF? Да. Может блокировать между устройствами в одной VLAN, между двумя устройствами в разных подсетях одного VRF или между устройствами в разных VRF. Для устройств в разных VRF вам нужно будет спроектировать и настроить распространение SGT на уровне передачи данных от BN до Fusion. Я описываю все эти варианты использования в
BRKENS-2819
, если вы хотите с ними ознакомиться. С уважением, Джером -
Ну... раз вы уже решили использовать SDA, то настоятельно рекомендуем заключить договор с PSO на проектирование и внедрение вашей системы.
~20 VRF не является проблемой для SDA. Скорее, потребуются значительные усилия по проектированию в целом и ручной настройке со стороны FW. -
Спасибо
@jedolphi@
[Andrii Oliinyk]
за информацию Хотелось бы узнать, возможно ли контролировать трафик между двумя VLAN в пределах одного VRF с помощью SGT Если SGT
действительно может справиться с этим требованием , мы сможем максимально сократить количество VRF в нашей сети. -
«Если возможно контролировать трафик между двумя VLAN в пределах одного VRF с помощью SGT»,
то по замыслу он активен в пределах одного VRF до тех пор, пока пакет не покинет Fabric. Насколько я знаю, он также доступен с Extranet. -
Для лучшего понимания: может ли SGT блокировать связь между двумя пулами IP-адресов в пределах одного VRF?
-
Для большей ясности, например, я могу пометить устройства в VLAN 10 как «SGT 10», а устройства в VLAN 20 как «SGT 20» в пределах
одной и той же виртуальной сети
и применить запрет. Но допустим, я хочу сделать исключение для группы хостов в VLAN 10 и VLAN 20, чтобы разрешить им обмениваться данными. Как это можно сделать? -
тогда ваш подход к разработке SGT должен быть более сложным, и, возможно, вам придется пометить интересующие вас хосты новыми SGT, чтобы определить для них различные политики коммуникации.
-
С экстрасетью трафик не может покидать BN, верно? Я полагаю, что распространения SGT в VXLAN будет достаточно, не так ли?
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти