Настройка архитектуры целевой зоны Azure в соответствии с требованиями
В рамках руководства по целевой зоне Azure доступны несколько эталонных вариантов реализации:
- Целевая зона Azure с помощью Azure Виртуальная глобальная сеть
- Целевая зона Azure с традиционным концентратором и периферийными устройствами
- Фундамент целевой зоны Azure
- Целевая зона Azure для небольших предприятий
Эти варианты помогут вашей организации быстро приступить к работе с конфигурациями, которые обеспечивают концептуальную архитектуру целевой зоны Azure и рекомендации по проектированию.
Эталонные реализации основаны на рекомендациях и обучении команд Майкрософт от взаимодействия с клиентами и партнерами. Это знание представляет сторону "80" правила 80/20. Различные реализации принимают на себя технические решения, которые являются частью процесса проектирования архитектуры.
Так как не все варианты использования одинаковы, не все организации могут использовать подход реализации точно так же, как он был предназначен. Необходимо понять рекомендации при определении требования к настройке.
Что такое архетип целевой зоны в целевых зонах Azure?
Архетип целевой зоны описывает, что должно быть верным, чтобы целевая зона (подписка Azure) соответствовала ожидаемым требованиям к среде и соответствию требованиям в определенной области. Вот некоторые примеры.
- Политика Azure назначения.
- Назначения управления доступом на основе ролей (RBAC).
- Централизованно управляемые ресурсы, такие как сеть.
Рассмотрим каждую группу управления в иерархии ресурсов, так как она вносит вклад в выходные данные архетипа конечной зоны из-за того, что наследование политики работает в Azure. Думайте о том, что применяется на верхних уровнях иерархии ресурсов при проектировании более низких уровней.
Существует тесная связь между группами управления и архетипами целевой зоны, но только группа управления не является архетипом целевой зоны. Вместо этого она входит в состав платформы, которая используется для реализации каждого архетипа целевой зоны в вашей среде.
Эту связь можно увидеть в концептуальной архитектуре целевой зоны Azure. Назначения политик создаются в промежуточной корневой группе управления, например Contoso, для параметров, которые должны применяться ко всем рабочим нагрузкам. Дополнительные назначения политик создаются на более низких уровнях иерархии для более конкретных требований.
Размещение подписок в иерархии групп управления определяет результирующий набор назначений Политика Azure и управления доступом (IAM), которые наследуются, применяются и применяются к определенной целевой зоне (подписке Azure).
Для обеспечения целевой зоны необходимы дополнительные процессы и средства, необходимые централизованно управляемые ресурсы. Некоторыми примерами могут служить:
- Параметры диагностики для отправки данных журнала действий в рабочую область Log Analytics.
- Параметры непрерывного экспорта для Microsoft Defender для облака.
- Виртуальная сеть с управляемыми IP-адресами для рабочих нагрузок приложений.
- Связывание виртуальных сетей с распределенной защитой от отказов в обслуживании (DDoS).
Примечание.
В эталонных реализациях целевой зоны Azure политики Azure с DeployIfNotExists Modify эффектами используются для развертывания некоторых из предыдущих ресурсов. Они следуют принципу проектирования управления на основе политики.
Дополнительные сведения см. в разделе "Внедрение защищений, управляемых политикой".
Встроенные архетипы для концептуальной архитектуры целевой зоны Azure
Концептуальная архитектура включает примеры архетипов целевой зоны для рабочих нагрузок приложений, таких как corp и online. Эти архетипы могут применяться к вашей организации и соответствовать вашим требованиям. Вы можете внести изменения в эти архетипы или создать новые. Ваше решение зависит от потребностей и требований вашей организации.
Совет
Чтобы просмотреть архетипы целевой зоны в акселераторе целевой зоны Azure, ознакомьтесь с группами управления в акселераторе целевой зоны Azure.
Также может потребоваться создать изменения в другой точке иерархии ресурсов. При планировании иерархии для реализации целевых зон Azure для вашей организации следуйте рекомендациям в областях проектирования.
Следующие примеры архетипа целевой зоны из концептуальной архитектуры помогают понять их назначение и предполагаемое использование:
| Архетип целевой зоны (группа управления) | Назначение или использование |
|---|---|
| Корпорация | Выделенная группа управления для корпоративных целевых зон. Эта группа предназначена для рабочих нагрузок, которым требуется подключение или гибридное подключение к корпоративной сети через центр в подписке подключения. |
| Миграция по сети | Выделенная группа управления для целевых зон в сети. Эта группа предназначена для рабочих нагрузок, для которых может потребоваться прямое входящее или исходящее соединение с Интернетом, или для рабочих нагрузок, которые могут не требовать виртуальной сети. |
| Песочница | Выделенная группа управления для подписок, которая будет использоваться только для тестирования и исследования. Эти подписки будут безопасно отключены от корпоративных и подключенных целевых зон. В песочницах также действует менее ограничивающий набор политик, назначенных для тестирования, исследования и настройки служб Azure. |
Сценарии, в которых может потребоваться настройка
Как упоминалось, мы предоставляем общие архетипы целевой зоны в концептуальной архитектуре целевой зоны Azure. Они являются корпоративными и онлайн. Эти архетипы не исправлены и не являются единственными разрешенными архетипами целевой зоны для рабочих нагрузок приложений. Возможно, вам потребуется адаптировать архетипы целевой зоны в соответствии с вашими потребностями и требованиями.
Прежде чем адаптировать архетипы целевой зоны, важно понимать понятия, а также визуализировать область иерархии, которую мы рекомендуем настроить. На следующей схеме показана иерархия по умолчанию концептуальной архитектуры целевой зоны Azure.
Выделены две области иерархии. Один находится под целевыми зонами, а другой находится под платформой.
Настройка архетипов целевой зоны приложения
Обратите внимание, что область, выделенная синим цветом под группой управления "Целевые зоны ". Это наиболее распространенное и безопасное место в иерархии, чтобы добавить дополнительные архетипы для удовлетворения новых или более требований, которые нельзя добавить в качестве дополнительных назначений политик в существующий архетип с помощью существующей иерархии.
Например, может потребоваться создать новое требование для размещения набора рабочих нагрузок приложений, которые должны соответствовать требованиям к индустрии карт оплаты (PCI). Но это новое требование не требуется применять ко всем рабочим нагрузкам в пределах всего вашего имущества.
Существует простой и безопасный способ удовлетворения этого нового требования. Создайте новую группу управления с именем PCI под группой управления "Целевые зоны " в иерархии. Вы можете назначить больше политик, таких как инициатива политики соответствия нормативным требованиям Microsoft Defender для облака для PCI версии 3.2.1:2018 новой группе управления PCI. Это действие формирует новый архетип.
Теперь вы можете поместить новые или переместить существующие подписки Azure в новую группу управления PCI , чтобы она наследовала необходимые политики и сформировать новый архетип.
Другой пример — Microsoft Cloud для суверенитета, который добавляет группы управления для конфиденциальных вычислений и выравнивается для использования в регулируемых отраслях. Microsoft Cloud для суверенитета предоставляет инструменты, рекомендации и меры безопасности для внедрения общедоступного облака с соответствующими элементами управления суверенитетом.
Совет
Необходимо знать, что следует учитывать и что происходит при перемещении подписок Azure между группами управления в отношении RBAC и Политика Azure. Дополнительные сведения см. в статье "Переход существующих сред Azure в концептуальную архитектуру целевой зоны Azure".
Настройка архетипов целевой зоны платформы
Вы также можете настроить область, выделенную оранжевым цветом под группой управления платформы . Зоны в этой области называются целевыми зонами платформы.
Например, у вас может быть выделенная команда SOC, требующая собственного архетипа для размещения рабочих нагрузок. Эти рабочие нагрузки должны соответствовать требованиям Политика Azure и назначения RBAC, отличающимся от требований группы управления управления.
Создайте группу управления безопасностью под группой управления платформой в иерархии. Для него можно назначить необходимые Политика Azure и назначения RBAC.
Теперь вы можете поместить новые или переместить существующие подписки Azure в новую группу управления безопасностью , чтобы она наследовала необходимые политики и сформировать новый архетип.
Пример адаптированной иерархии целевой зоны Azure
На следующей схеме показана адаптированная иерархия целевой зоны Azure. В нем используются примеры из предыдущей схемы.
Что необходимо учесть
Рассмотрим следующие моменты, когда вы думаете о настройке реализации архетипов целевой зоны Azure в иерархии:
Настройка иерархии не является обязательной. Стандартные архетипы и иерархии, которые мы предоставляем, подходят для большинства сценариев.
Не создавайте иерархию организации, команды или отделы в архетипах.
Всегда старайтесь создавать существующие архетипы и иерархию в соответствии с новыми требованиями.
Только создайте новые архетипы, когда они действительно необходимы.
Например, новое требование соответствия, например PCI, требуется только для подмножества рабочих нагрузок приложений и не требует применения ко всем рабочим нагрузкам.
Создайте только новые архетипы в выделенных областях, показанных на предыдущих схемах.
Избегайте выхода за пределы иерархии четырех слоев, чтобы избежать сложности и ненужных исключений. Разверните архетипы горизонтально, а не по вертикали в иерархии.
Не создавайте архетипы для сред, таких как разработка, тестирование и рабочая среда.
Дополнительные сведения см. в статье "Как обрабатывать целевые зоны разработки и тестирования и рабочей рабочей нагрузки" в концептуальной архитектуре целевых зон Azure?
Если вы поступаете из среды браунфилда или ищете подход к размещению подписок в группе управления целевыми зонами с политиками в режиме принудительного применения "только аудит", просмотрите сценарий: переход среды путем дублирования группы управления целевой зоной