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