Часто задаваемые вопросы и ответы о целевой зоне Azure

В этой статье приведены ответы на часто задаваемые вопросы об архитектуре целевой зоны Azure.

Часто задаваемые вопросы о реализации архитектуры целевой зоны Azure см. в часто задаваемых вопросы о реализации в масштабе предприятия.

Что такое ускоритель целевой зоны Azure?

Ускоритель целевой зоны Azure — это интерфейс развертывания на основе портала Azure. Он развертывает реализацию, следующую определенным мнениям и представлениям, на основе концептуальной архитектуры целевых зоны Azure.

Какие рекомендуемые акселераторы и реализации для целевых зон Azure?

Корпорация Майкрософт активно разрабатывает и поддерживает акселераторы платформ и приложений и реализации в соответствии с принципами проектирования целевой зоны Azure и рекомендациями по проектированию.

Ознакомьтесь с руководством по развертыванию целевых зон Azure, чтобы узнать больше о рекомендуемой платформе и целевых зонах приложений.

Сведения о настройке развертывания целевых зон Azure в соответствии с вашими потребностями см. в статье "Настройка архитектуры целевой зоны Azure для удовлетворения требований"

Что такое концептуальная архитектура целевых зон Azure?

Концептуальная архитектура целевых зон Azure отражает решения, касающиеся масштабирования и зрелости. Он основан на уроках, извлеченных и отзывах от клиентов, которые приняли Azure в рамках своего цифрового имущества. Эта концептуальная архитектура может помочь вашей организации определить направление для проектирования и реализации целевой зоны.

Что такое целевая зона сопоставляет с Azure в контексте архитектуры целевой зоны Azure?

С точки зрения целевой зоны Azure целевые зоны являются отдельными подписками Azure.

Что означает управление на основе политик и как оно работает?

Управление на основе политик — это один из ключевых принципов проектирования архитектуры корпоративного масштаба.

Управление на основе политик означает использование Политики Azure для сокращения времени, необходимого для выполнения распространенных и повторяющихся рабочих задач в арендаторе Azure. Используйте многочисленные эффекты Политики Azure, такие как Append, Deny, DeployIfNotExists и Modify, для предотвращения несоответствия требованиям, либо ограничив создание или изменение несоответствующих ресурсов (согласно определению политики), либо развернув ресурсы или изменив параметров запроса создания или изменения ресурса, чтобы сделать их соответствующими. Некоторые эффекты, такие как Audit, Disabled и AuditIfNotExists, не выполняют действия и не препятствуют их выполнению, а отвечают лишь за аудит и ведение отчета о несоответствии.

Ниже приведены некоторые примеры управления на основе политик:

• Эффект Deny. Предотвращает создание или изменение подсетей, чтобы с ними не были связаны никакие группы безопасности сети.

• DeployIfNotExists Эффект. Создается новая подписка (целевая зона) и помещается в группу управления в развертывании целевой зоны Azure. Политика Azure включает Microsoft Defender для облака (прежнее название — Центр безопасности Azure) для этой подписки. Она также настраивает параметры диагностики для журнала действий, чтобы отправлять журналы в рабочую область Log Analytics в подписке управления.

  Вместо повторения кода или ручных действий при создании подписки определение политики DeployIfNotExists развертывает и настраивает их автоматически.

Что делать, если мы не можем или еще не готовы использовать политики DeployIfNotExists (DINE)?

У нас есть выделенная страница, которая проходит по различным этапам и параметрам, которые необходимо либо отключить" политики DINE, либо использовать наш трехэтапный подход для их внедрения в вашей среде.

См. руководство Введение ограничений, определяемых политиками.

Следует ли использовать Политику Azure для развертывания рабочих нагрузок?

Если отвечать коротко, то нет. Используйте Политику Azure для контроля, управления и обеспечения соответствия рабочих нагрузок и целевых зон. Она не предназначена для развертывания целых рабочих нагрузок и других средств. Используйте портал Azure или предложения "инфраструктура как код" (шаблоны ARM, Bicep, Terraform) для развертывания рабочей нагрузки и управления ей, а также для получения необходимой автономности.

Что такое целевые зоны Cloud Adoption Framework для Terraform (aztfmod)?

Целевые зоны Cloud Adoption Framework открытый код проект (OSS) (также известный как aztfmod) — это управляемый сообществом проект, принадлежащий и поддерживаемый за пределами основной команды целевой зоны Azure и организации Azure GitHub. Если ваша организация решит использовать этот проект OSS, следует учитывать поддержку, доступную по мере того как это обусловлено усилиями сообщества через GitHub.

Что делать, если в нашей целевой зоне уже были ресурсы, а позднее мы назначили определение Политики Azure, включающее их в свою область действия?

Ознакомьтесь со следующими разделами документации:

• Переход существующих сред Azure в концептуальную архитектуру целевой зоны Azure — раздел "Политика"
• Краткое руководство. Создание назначения политики для обнаружения ресурсов, не соответствующих требованиям, — раздел "Выявление несоответствующих ресурсов"

Как обрабатывать целевые зоны рабочей нагрузки dev/test/production в архитектуре целевой зоны Azure?

Дополнительные сведения см. в статье "Управление средами разработки приложений в целевых зонах Azure".

Почему требуется указывать регионы Azure во время развертывания ускорителя целевой зоны Azure и для чего они используются?

При развертывании архитектуры целевой зоны Azure с помощью портала акселератора целевой зоны Azure выберите регион Azure для развертывания. На первой вкладке Расположение развертывания определяется место для хранения данных развертывания. Дополнительные сведения см. в разделе Развертывание арендаторов с помощью шаблонов ARM. Некоторые части целевой зоны развертываются глобально, но их метаданные развертывания отслеживаются в региональном хранилище метаданных. Метаданные, относящиеся к их развертыванию, хранятся в регионе, выбранном на вкладке Расположение развертывания.

Селектор региона на вкладке "Расположение развертывания" также используется для выбора региона, который следует хранить в любом регионе, например рабочую область Log Analytics и учетную запись службы автоматизации при необходимости.

При развертывании сетевой топологии на вкладке "Топология сети" и "Подключение" необходимо выбрать регион Azure для развертывания сетевых ресурсов. Этот регион может отличаться от региона, выбранного на вкладке "Расположение развертывания".

Дополнительные сведения о регионах, используемых ресурсами целевой зоны, см. в разделе "Регионы целевой зоны".

Как включить больше регионов Azure при использовании архитектуры целевой зоны Azure?

Сведения о том, как добавить новые регионы в целевую зону или как переместить ресурсы целевой зоны в другой регион, см. в разделе "Регионы целевой зоны".

Следует ли создавать новую подписку Azure каждый раз или повторно использовать подписки Azure?

Что такое повторное использование подписки?

Повторное использование подписки — это процесс повторной отправки существующей подписки новому владельцу. Необходимо выполнить процесс сброса подписки на известное состояние очистки, а затем переназначить новому владельцу.

Почему следует повторно использовать подписки?

Как правило, рекомендуется, чтобы клиенты приняли принцип проектирования демократизации подписки. Однако существуют определенные обстоятельства, когда повторное использование подписки невозможно или рекомендуется.

При выполнении одного из следующих обстоятельств следует рассмотреть возможность повторного использования подписки.

• У вас есть Соглашение Enterprise (EA) и планируется создать более 5000 подписок на одну учетную запись владельца учетной записи EA (учетная запись выставления счетов), включая удаленные подписки.
• У вас есть Клиентское соглашение Майкрософт (MCA) или Соглашение с партнером Майкрософт MPA и планируется иметь более 5000 активных подписок. Дополнительные сведения об ограничениях подписки см. в статье "Учетные записи и области выставления счетов" в портал Azure.
• Вы являетесь клиентом с оплатой по мере использования.
• Вы используете спонсорство Microsoft Azure.
• Обычно создается:
  1. Эфемерные лабораторные или песочницы среды
  2. Демонстрационные среды для проверки концепции (POCs) или минимальных жизнеспособных продуктов (MVP), включая независимых поставщиков программного обеспечения (ISV) для демонстрации и пробного доступа клиента
  3. Учебные среды, такие как среды обучения MSPs/Trainer

Разделы справки повторно использовать подписки?

Если вы соответствуете одному из описанных выше сценариев или рекомендаций, вам может потребоваться повторно использовать существующие списанные или неиспользуемые подписки и переназначить их новому владельцу и назначению.

Очистка старой подписки

Сначала необходимо очистить старую подписку для повторного использования. Прежде чем он готов к повторному использованию, необходимо выполнить следующие действия в подписке:

• Удалите группы ресурсов и содержащиеся ресурсы.
• Удалите назначения ролей, включая назначения ролей управление привилегированными пользователями (PIM) в области подписки.
• Удалите определения контроль доступа на основе пользовательских ролей (RBAC) в области подписки.
• Удаление определений политик, инициатив, назначений и исключений в области подписки.
• Удалите развертывания в области подписки.
• Удалите теги в области подписки.
• Удалите все блокировки ресурсов в области подписки.
• Удалите все бюджеты Microsoft Cost Management в области подписки.
• Сброс Microsoft Defender для облака планов на бесплатные уровни, если для этих журналов не заданы требования организации. Обычно эти требования применяются через Политика Azure.
• Удаление журналов действий подписки (параметров диагностики) пересылки в рабочие области Log Analytics, Центры событий, учетные записи хранения или другие поддерживаемые назначения, если только требования организации не требует переадресации этих журналов во время активной подписки.
• Удалите все делегирования Azure Lighthouse в области подписки.
• Удалите все скрытые ресурсы из подписки.

Переназначение подписки

После очистки подписки можно переназначить подписку. Ниже приведены некоторые распространенные действия, которые могут потребоваться выполнить в процессе переназначения:

• Добавьте новые теги и задайте значения для них в подписке.
• Добавьте новые назначения ролей или управление привилегированными пользователями назначения ролей (PIM) в области подписки для новых владельцев. Как правило, эти назначения будут выполняться в группах Microsoft Entra вместо отдельных пользователей.
• Поместите подписку в нужную группу управления на основе требований к управлению.
• Создайте новые бюджеты управления затратами Майкрософт и задайте для новых владельцев оповещения при достижении пороговых значений.
• Задайте Microsoft Defender для облака планы на нужные уровни. Этот параметр следует применить с помощью Политика Azure после размещения в правильной группе управления.
• Настройте журналы действий подписки (параметры диагностики) пересылки в рабочие области Log Analytics, Центры событий, учетную запись хранения или другие поддерживаемые назначения. Этот параметр следует применить с помощью Политика Azure после размещения в правильной группе управления.

Что такое национальный целевой пояс и как он связан с архитектурой целевой зоны Azure?

Зоны государственного назначения — это компонент Microsoft Cloud для суверенитета, предназначенный для клиентов государственного сектора, которые нуждаются в расширенном контроле над суверенитетом. В качестве специализированной версии концептуальной архитектуры целевой зоны Azure зоны зоны ведения зоны присоединения выравнивает возможности Azure, такие как расположение служб, управляемые клиентом ключи, Приватный канал Azure и конфиденциальные вычисления. Благодаря этому выравниванию целевая зона создает облачную архитектуру, в которой данные и рабочие нагрузки обеспечивают шифрование и защиту от угроз по умолчанию.

Дополнительные сведения о национальной целевой зоне см. в рекомендациях по суверенитету для целевых зон Azure.