Принудительное применение виртуальной сети с правилами администратора безопасности в Диспетчере виртуальная сеть Azure
В этой статье вы узнаете, как правила администраторов безопасности обеспечивают гибкое и масштабируемое применение политик безопасности с помощью таких средств, как группы безопасности сети. Во-первых, вы узнаете о различных моделях применения виртуальной сети. Затем вы узнаете об общих шагах по обеспечению безопасности с помощью правил администратора безопасности.
Принудительное применение виртуальной сети
Только при использовании групп безопасности сети (NSG) широко распространенная принудительность виртуальных сетей в нескольких приложениях, командах или даже во всех организациях может быть сложной задачей. Часто существует балансирующий акт между попытками централизованного применения в организации и передачой детализированного гибкого контроля командам.
Правила администратора безопасности направлены на устранение этой скользящей шкалы между применением и гибкостью в целом путем консолидации плюсов каждой из этих моделей при снижении недостатков каждого из них. Центральные группы управления устанавливают железнодорожные линии безопасности с помощью правил администратора безопасности, сохраняя место для отдельных команд, чтобы гибко определить безопасность по мере необходимости с помощью правил NSG. Правила администратора безопасности не предназначены для переопределения правил NSG. Вместо этого они работают с правилами NSG, чтобы обеспечить принудительное применение и гибкость в организации.
Модели принудительного применения
Рассмотрим несколько распространенных моделей управления безопасностью без правил администратора безопасности, а также их преимущества и минусы:
Модель 1. Централизованное управление группами управления с помощью групп безопасности сети
В этой модели центральная группа управления в организации управляет всеми группами безопасности сети.
| Плюсы | Минусы |
|---|---|
| Центральная группа управления может применять важные правила безопасности. | Операционные издержки высоки, так как администраторы должны управлять каждой NSG, так как число групп безопасности сети увеличивается, бремя увеличивается. |
Модель 2. Управление отдельными группами с группами безопасности сети
В этой модели отдельные команды в организации без централизованной группы управления управляют собственными группами безопасности сети.
| Плюсы | Минусы |
|---|---|
| Отдельная команда имеет гибкий контроль над настройкой правил безопасности на основе требований к службе. | Центральная группа управления не может применять критические правила безопасности, такие как блокировка рискованных портов. Отдельная команда также может неправильно настроить или забыть присоединить группы безопасности сети, что приводит к уязвимостям. |
Модель 3 — группы безопасности сети создаются с помощью Политика Azure и управляются отдельными командами.
В этой модели отдельные команды по-прежнему управляют группами безопасности сети. Разница заключается в том, что группы безопасности сети создаются с помощью Политика Azure для задания стандартных правил. Изменение этих правил приведет к активации уведомлений аудита.
| Плюсы | Минусы |
|---|---|
| Отдельная команда имеет гибкий контроль над настройкой правил безопасности. Центральная группа управления может создавать стандартные правила безопасности и получать уведомления при изменении правил. |
Центральная группа управления по-прежнему не может применять стандартные правила безопасности, так как владельцы NSG в командах по-прежнему могут изменять их. Уведомления также будут подавляющими для управления. |
Принудительное применение сетевого трафика и исключения с правилами администратора безопасности
Давайте применим основные понятия, описанные до сих пор, к примеру сценария. Администратор сети компании хочет применить правило безопасности для блокировки входящего трафика SSH для всей компании. Применение этого типа правила безопасности было сложно без правила администратора безопасности. Если администратор управляет всеми группами безопасности сети, то затраты на управление высоки, а администратор не может быстро реагировать на потребности групп продуктов изменить правила NSG. С другой стороны, если группы продуктов управляют собственными группами безопасности без правил администратора безопасности, администратор не может применять критически важные правила безопасности, оставляя потенциальные риски безопасности открытыми. Использование правил администратора безопасности и групп безопасности может решить эту дилемму.
В этом случае администратор может создать правило администратора безопасности для блокировки входящего трафика SSH для всех виртуальных сетей в компании. Администратор также может создать правило администратора безопасности, чтобы разрешить входящий трафик SSH для определенных виртуальных сетей, которым требуется исключение. Правило администратора безопасности применяется в компании, и администратор по-прежнему может разрешать исключения для определенных виртуальных сетей. Это делается с помощью порядка приоритета для каждого правила.
На схеме показано, как администратор может достичь следующих целей:
- Принудительное применение правил администратора безопасности в организации.
- Разрешить исключениям для команды приложений обрабатывать трафик SSH.
Шаг 1. Создание экземпляра диспетчера сети
Администратор компании может создать сетевой менеджер с корневой группой управления фирмы в качестве области действия этого экземпляра диспетчера сети.
Шаг 2. Создание групп сети для виртуальных сетей
Администратор создает две группы сети — все сетевые группы, состоящие из всех виртуальных сетей в организации, и группу сети приложений, состоящую из виртуальных сетей для приложения, нуждающегося в исключении. Все сетевые группы на приведенной выше схеме состоят из виртуальной сети 1 в виртуальную сеть 5, а в группе сети приложений есть виртуальная сеть 4 и виртуальная сеть 5. Пользователи могут легко определять обе сетевые группы с помощью динамического членства.
Шаг 3. Создание конфигурации администратора безопасности
На этом шаге два правила администратора безопасности определены со следующей конфигурацией администратора безопасности:
- Правило администратора безопасности для блокировки входящего трафика SSH для всех сетевых групп с более низким приоритетом 100.
- Правило администратора безопасности, разрешающее входящий трафик SSH для группы сети приложений с более высоким приоритетом 10.
Шаг 4. Развертывание конфигурации администратора безопасности
После развертывания конфигурации администратора безопасности все виртуальные сети в компании имеют правило входящего трафика SSH, применяемое правилом администратора безопасности. Отдельная команда не может изменить правило запрета, только определенный администратор компании может. Виртуальные сети приложений имеют правило трафика SSH для входящего трафика и правило входящего трафика SSH (наследуемое от правила всех групп сети). При использовании меньшего числа приоритета для правила входящего трафика SSH для группы сети приложений правило вычисляется сначала. Когда входящий трафик SSH поступает в виртуальную сеть приложений, правило администратора безопасности с более высоким приоритетом разрешает трафик. Если в подсетях виртуальных сетей приложений есть группы безопасности сети, этот входящий трафик SSH будет оцениваться следующим образом на основе групп безопасности сети, заданных командой приложений. Методология правил администратора безопасности, описанная здесь, позволяет администратору компании эффективно применять политики компании и создавать гибкие рельсы безопасности в организации, которая работает с группами безопасности.
Следующие шаги
Узнайте, как блокировать порты высокого риска с помощью правил администратора безопасности
Ознакомьтесь с часто задаваемыми вопросами о диспетчере виртуальная сеть Azure