Корпоративный каркас Azure: рекомендуемая система управления подписками

Примечание.

Шаблоны Azure для предприятий теперь интегрированы в Microsoft Cloud Adoption Framework. Содержимое этой статьи теперь доступно в Методологии готовности платформы. Эта статья считается устаревшей с начала 2020 г. Перед использованием нового процесса ознакомьтесь со следующими материалами: Обзор методологии готовности, Целевые зоны Azure и Рекомендации по использованию целевых зон.

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

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

• "Я обеспокоен сохранением контроля над данными; как я могу убедиться, что данные и системы соответствуют нормативным требованиям?"
• "Как узнать, что обеспечивает тот или иной ресурс, чтобы учесть его и правильно добавить в счет?"
• "Я хочу убедиться, что все развертывания или другие действия в общедоступном облаке ставят безопасность на первое место. Как я могу этому посодействовать?"

Перспектива пустой подписки без какой-либо защиты пугает. Этот пробел может помешать перемещению в Azure.

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

Требования управления

При перемещении в Azure необходимо заблаговременно рассмотреть вопрос управления, чтобы обеспечить успешное использование облака на предприятии. К сожалению, нехватка времени и волокита, связанная с созданием комплексной системы управления, приводят к тому, что некоторые рабочие группы сразу идут к поставщикам, не привлекая ИТ-отдел предприятия. Такой подход может оставить предприятие уязвимым, если управление ресурсами осуществляется неправильно. Характеристики общедоступного облака — гибкость, динамичность и стоимость на основе использования — важны для бизнес-групп, которым нужно быстро удовлетворять потребности клиентов (внутренних и внешних). Но ИТ-отделу предприятия нужно убедиться в эффективности защиты данных и систем.

При строительстве здания, чтобы создать базовую структуру, используется каркас. Каркас обеспечивает общую структуру и предоставляет точки крепления, на которые можно устанавливать другие постоянные системы. Корпоративный каркас ничем не отличается: это набор гибких элементов управления и возможностей Azure, обеспечивающих структуру среды, и привязок для служб на основе общедоступного облака. Он предоставляет строителям (ИТ-отделам и бизнес-группам) основу для создания и присоединения новых служб, учитывающих скорость доставки.

В основе каркаса лежат рекомендации, полученные при сотрудничестве с клиентскими организациями различных размеров. Мы работали с разными клиентами: от небольших организаций, разрабатывающих решения в облаке, до крупных многонациональных предприятий и независимых поставщиков программного обеспечения, которые переходят на использование рабочих нагрузок облака и разрабатывают решения в нем. Корпоративный каркас обладает гибкостью, предназначенной для поддержки как традиционных рабочих нагрузок ИТ, так и гибких рабочих нагрузок. Например, его преимуществами могут воспользоваться разработчики, создающие SaaS-приложения на основе возможностей платформы Azure.

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

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

Определение иерархии

Основой шаблонов является иерархия и связь регистрации Соглашение Enterprise (EA) с подписками и группами ресурсов. Регистрация определяет форму и использование служб Azure в вашей компании с точки зрения контракта. В рамках Соглашения Enterprise можно дополнительно разделить среду на подразделения, учетные записи, подписки и группы ресурсов, чтобы они соответствовали структуре вашей организации.

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

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

Подразделения и учетные записи

Ниже приведены три стандартных шаблона для регистрации Соглашения Enterprise.

• Функциональный шаблон.

  

• Шаблон подразделения.

  

• Географический шаблон.

  

Несмотря на то что каждый из этих шаблонов имеет свое место, шаблон подразделения все чаще используется благодаря гибкости при создании модели затрат организации, а также отражению диапазона контроля. Группа Microsoft Core Engineering and Operations создала подмножество эффективных шаблонов подразделений, смоделированных на федеральном и местном уровнях, а также на уровне штата. Дополнительные сведения см. в статье Организация подписок и групп ресурсов.

Группы управления Azure

Теперь корпорация Майкрософт предоставляет еще один способ моделирования иерархии: группы управления Azure. Группы управления гораздо более гибкие, чем отделы и учетные записи, и могут быть вложены до шести уровней. Группы управления позволяют создавать иерархию исключительно для эффективного управления ресурсами; она отличается от иерархии выставления счетов. Группы управления могут отражать иерархию выставления счетов и зачастую предприятия начинают именно с этого. Однако возможности групп управления используются для моделирования организации, объединения связанных подписок (независимо от их расположения в иерархии выставления счетов) и назначения общих ролей, политик и инициатив. Некоторыми примерами могут служить:

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

• Внутренние службы и внешние службы. Требования, политики и роли для внутренних служб предприятия и служб, ориентированных на клиентов, зачастую отличаются друг от друга.

Тщательно продуманные группы управления, наряду с Политикой Azure и ее инициативами, являются основой эффективной системы управления.

Подписки

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

• Приложения/Службы. Подписки представляют приложение или службу (портфель приложений).
• Жизненный цикл. Подписки представляют жизненный цикл службы, например Production или Development.
• Подразделение. Подписки представляют подразделения организации.

Первые два шаблона являются наиболее часто используемыми, и мы настоятельно рекомендуем их использовать. Шаблон "Жизненный цикл" подходит для большинства организаций. Для этого варианта мы рекомендуем назначить две базовые подписки: Production и Nonproduction, а для дальнейшего разделения — использовать группы ресурсов.

Группы ресурсов

Azure Resource Manager позволяет организовывать ресурсы в предметные группы для управления, выставления счетов или обеспечения естественного сходства. Группы ресурсов — это контейнеры ресурсов, которые имеют общий жизненный цикл или какой-либо атрибут, например All SQL servers или Application A.

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

• Рабочие нагрузки традиционных ИТ чаще всего группируются по элементам в рамках одного жизненного цикла, например приложения. Группирование по приложениям позволяет управлять отдельными приложениями.

• Рабочие нагрузки гибких ИТ, как правило, сосредотачиваются на облачных приложениях для внешних клиентов. Группы ресурсов часто отражают уровни развертывания (например, уровень Интернета или уровень приложений) и управления.

Примечание.

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

Стандарты именования

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

Совет

Для соглашений об именовании:

• Просматривайте и применяйте рекомендации по именованию и маркировке Cloud Adoption Framework всегда, когда это возможно. Это руководство поможет выбрать информативный стандарт именования, также в нем приведено множество примеров.
• Используйте политики Resource Manager для обеспечения соблюдения стандартов именования.

Помните, что впоследствии изменить имена будет сложно, поэтому уделите несколько минут сейчас, чтобы избежать трудностей в будущем.

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

Теги ресурсов

Теги ресурсов тесно связаны со стандартами именования. Поскольку ресурсы добавляются к подпискам, чрезвычайно важно логически классифицировать их для таких целей, как выставление счетов, управление и эксплуатация. Дополнительные сведения см. в статье Использование тегов для организации ресурсов в Azure.

Внимание

Теги могут содержать личную информацию и могут подпадать под действие положений GDPR. Тщательно планируйте управление тегами. Общие сведения о регламенте GDPR см. в соответствующем разделе на портале Microsoft Service Trust Portal.

Существует много вариантов использования тегов, помимо выставления счетов и управления. Они часто используются как часть службы автоматизации (см. раздел ниже). Если не предусмотреть заранее, это может привести к конфликтам. Рекомендуется определить все распространенные теги на уровне предприятия (например, ApplicationOwner и CostCenter) и применить их при развертывании ресурсов с помощью службы автоматизации.

Политика и инициативы Azure

Политика и инициативы Azure — это еще одна основа каркаса. Они помогают управлять рисками путем применения правил (с эффектами) к ресурсам и службам в подписках. Инициативы Azure — это коллекции политик, предназначенных для достижения единой цели. Политики и инициативы Azure присваиваются области ресурсов, в которых они затем и начинают действовать.

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

Распространенные примеры использования политик Resource Manager

Политики и инициативы — это мощные инструменты Azure. Политики предоставляют компаниям элементы управления рабочими нагрузками традиционных ИТ и обеспечивают необходимую для бизнес-приложений стабильность. Они также допускают развертывание гибких рабочих нагрузок (например, разработку клиентских приложений) без дополнительных рисков для предприятия. Ниже перечислены наиболее распространенные шаблоны использования политик.

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

• Избегать публичной демонстрации серверов. Политика Azure может запретить развертывание определенных типов ресурсов. Общепринятый подход — создать политику, запрещающую создание общедоступного IP-адреса в определенной области, чтобы избежать нежелательного открытия сервера к воздействиям в Интернете.

• Управление затратами и метаданные. Теги ресурсов часто используются для добавления важных данных о выставлении счетов в ресурсы и группы ресурсов, такие как CostCenter и Owner. Эти теги являются очень полезными для точного выставления счетов и управления ресурсами. Политики могут применять приложение тегов ресурсов для всех развернутых ресурсов, что упрощает управление ими.

Распространенные варианты использования инициатив

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

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

• Нормативно-правовая инициатива. Предприятия часто группируют политики, общепринятые для нормативных требований (например, HIPAA), что позволяет эффективно отслеживать управление и соответствие этим элементам контроля.

• Типы ресурсов и номера SKU. Создание инициативы, которая ограничивает типы ресурсов, которые можно развернуть, а также номера SKU, которые можно развернуть, могут помочь управлять затратами и гарантировать, что ваша организация развертывает только ресурсы, которые у вашей команды есть набор навыков и процедуры для поддержки.

Совет

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

Назначение политик и инициатив

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

Примеры, демонстрирующие применение политик и инициатив к ресурсам в Azure, доступны в azure-policyрепозитории GitHub.

Управление удостоверениями и доступом

При внедрении общедоступного облака необходимо задаться такими вопросами: "Кто должен иметь доступ к ресурсам?" и "Как контролировать этот доступ?" Управление доступом к порталу Microsoft Azure и ресурсам крайне важно для долгосрочной безопасности ресурсов в облаке.

Чтобы защитить доступ к ресурсам, необходимо сначала настроить поставщика удостоверений, а затем — роли и доступ. Идентификатор Microsoft Entra, подключенный к локальная служба Active Directory, является основой удостоверения в Azure. Однако идентификатор Microsoft Entra не совпадает с локальная служба Active Directory, и важно понять, что такое клиент Microsoft Entra и как он связан с регистрацией. Просмотрите управление доступом к ресурсам в Azure, чтобы получить четкое представление об идентификаторе Microsoft Entra и локальная служба Active Directory. Чтобы подключить и синхронизировать локальный каталог с идентификатором Microsoft Entra, установите и настройте средство Microsoft Entra Подключение локально.

В первоначальном выпуске Azure были лишь базовые элементы управления доступом к подписке: пользователи могли получить роль администратора или соадминистратора. В этой классической модели доступ к подписке подразумевал доступ ко всем ресурсам на портале. Отсутствие детализированного контроля приводило к созданию избыточного количества подписок, необходимых, чтобы обеспечить адекватный контроль доступа для соглашений Azure. Больше такое увеличение числа подписок не требуется. Управление доступом Azure на основе ролей (RBAC) позволяет назначать пользователям стандартные роли, которые предоставляют общий доступ (например, "Владелец", "Участник", "Читатель") и даже создать свои собственные роли.

При реализации RBAC Azure настоятельно рекомендуем следующее.

• Контролируйте роли администратора и соадминистратора подписки, пользователи с этими ролями имеют множество разрешений. Если пользователю необходимо управлять классическими развертываниями Azure, просто добавьте учетную запись владельца подписки в качестве соадминистратора.
• Используйте группы управления для назначения ролей в нескольких подписках и уменьшайте время управления ими на уровне подписки.
• Добавьте пользователей Azure в группу (например, Application X Owners ) в Azure Active Directory. Используйте синхронизированную группу, чтобы предоставить необходимые права для управления группой ресурсов, содержащей это приложение.
• Придерживайтесь принципа предоставления минимальных привилегий, необходимых для выполнения предстоящей работы.

Внимание

Рассмотрите возможность использования Microsoft Entra управление привилегированными пользователями, многофакторной проверки подлинности Azure и возможностей условного доступа Microsoft Entra для повышения безопасности и повышения видимости административных действий в подписках Azure. Эти возможности берутся из допустимой лицензии Microsoft Entra ID P1 или P2 (в зависимости от функции) для дальнейшего защиты удостоверения и управления ими. Microsoft Entra PIM обеспечивает jit-административный доступ с рабочим процессом утверждения, а также полный аудит активаций и действий администратора. Многофакторная проверка подлинности Azure — это еще один важный инструмент, позволяющий включить двухфакторную проверку для входа на портал Microsoft Azure. В сочетании с элементами управления условным доступом Microsoft Entra вы можете эффективно управлять риском компрометации.

Планирование и подготовка к управлению удостоверениями и доступом в сочетании с рекомендациями Azure Identity Management — одна из лучших стратегий снижения риска. В идеале она должна быть обязательной для каждого развертывания.

Безопасность

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

Microsoft Defender для облака

Microsoft Defender для облака обеспечивает единое представление о состоянии безопасности ресурсов в среде в дополнение к расширенной защите от угроз. Defender для облака — это открытая платформа, позволяющая партнерам Майкрософт создавать программное обеспечение, которое подключается к и расширяет возможности. Базовые возможности службы Defender для облака уровня "Бесплатный" предоставляют оценку уровня безопасности и рекомендации для его повышения. Платные уровни обеспечивают дополнительные и ценные возможности, такие как JIT-доступ и адаптивные элементы управления приложениями (allowlists).

Совет

Defender для облака — это мощный инструмент, который регулярно совершенствуется благодаря новым возможностям обнаружения угроз и защиты предприятия. Мы настоятельно рекомендуем всегда включать Defender для облака.

Блокировка ресурсов Azure

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

Комплект безопасности DevOps для Azure

Комплект средств безопасности DevOps для Azure (AzSK) представляет собой набор скриптов, инструментов, расширений и средств автоматизации, первоначально созданных собственной ИТ-командой корпорации Майкрософт и выпущенных на GitHub с открытым исходным кодом. AzSK поддерживает сквозную подписку Azure и потребности в ресурсной безопасности для команд в полном объеме, используя расширенную автоматизацию и плавную интеграцию безопасности в рабочие процессы DevOps, помогая обеспечить безопасность операций по шести направлениям:

• защита подписки;
• включение безопасной разработки;
• интеграция безопасности в CI/CD;
• непрерывный контроль;
• мониторинг и оповещения;
• облачная система управления рисками.

AzSK — это широкий набор средств, скриптов и сведений, которые являются важной частью комплексной Системы управления Azure, и его включение в каркас имеет решающее значение для поддержки целей управления рисками в организации.

Управление обновлениями Azure

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

Мониторинг и оповещения

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

• Журналы действий описывают все операции, выполняемые с ресурсами в подписке.
• Метрики — это числовая информация, которая выпускается из ресурса и описывает производительность и работоспособность этого ресурса.
• Журналы диагностики выдаются службой Azure. Они содержат подробные и своевременные данные о работе этой службы.

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

Общие возможности

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

• Панели мониторинга позволяют агрегировать просмотры мониторинга и объединять данные между ресурсами и подписками, что дает общее представление о телеметрии ресурсов Azure. Вы можете создавать и настраивать свои собственные представления и делиться ими с другими. Например, можно создать панель мониторинга, состоящую из различных фрагментов для администраторов баз данных, для предоставления информации обо всех службах баз данных Azure, включая БД SQL Azure, БД Azure для PostgreSQL и БД Azure для MySQL.

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

Базовый мониторинг

• Azure Monitor. Служба Azure Monitor — это единая базовая платформа для мониторинга ресурсов Azure. Интерфейс портала Microsoft Azure для Azure Monitor обеспечивает централизованную точку перехода для всех функций мониторинга в Azure, включая возможности глубокого мониторинга Application Insights, Log Analytics, средства мониторинга сетей, решения управления и сопоставления служб. С помощью Azure Monitor можно визуализировать, запрашивать, маршрутизировать, архивировать метрики и журналы, поступающие из ресурсов Azure на всей облачной инфраструктуры, а также совершать действия над ними. Помимо портала, можно получать данные с помощью командлетов PowerShell в Azure Monitor, кроссплатформенного интерфейса командной строки или REST API Azure Monitor.

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

• Работоспособность служб Azure. Эта функция идентифицирует любые проблемы в работе служб Azure, которые могут повлиять на приложения, а также помогает спланировать периоды запланированного обслуживания.

• Журнал действий описывает все операции с ресурсами в подписках. Он предоставляет журнал аудита для определения что, кому и когда для всех операций создания, обновления и удаления ресурсов. События в журнале действий платформы хранятся и доступны для запросов в течение 90 дней. Можно принимать журналы действий в Log Analytics для более длительных периодов хранения и более глубокого анализа запросов и анализа по нескольким ресурсам.

Глубокий мониторинг приложений

• Application Insights позволяет собирать специфические данные телеметрии приложения и отслеживать производительность, доступность и использование приложений в облаке или локальной среде. Инструментируйте приложения с помощью пакетов средств разработки с поддержкой нескольких языков, в том числе .NET, JavaScript, Java, Node.js, Ruby и Python. События Application Insights попадают в одно хранилище данных Log Analytics, которое поддерживает мониторинг инфраструктуры и безопасности, чтобы вы могли коррелировать и агрегировать события во времени с помощью богатого языка запросов.

Глубокий мониторинг инфраструктуры

• Log Analytics. Эта служба играет ключевую роль в мониторинге Azure. Она собирает данные телеметрии и другие данные из разных источников и предоставляет язык запросов и механизм аналитики, которые позволяют анализировать работу приложений и ресурсов. Вы можете напрямую взаимодействовать с данными Log Analytics с помощью поиска по журналам и представлений. Кроме того, можно воспользоваться средствами анализа в других службах Azure, которые хранят свои данные в Log Analytics, например Application Insights или Microsoft Defender для облака.

• Сетевой мониторинг. Службы сетевого мониторинга Azure позволяют получить представление о потоке сетевого трафика, производительности, безопасности, подключениях и узких местах сети. Тщательно спланированный проект сети должен включать настройку служб мониторинга сети Azure, такую как Наблюдатель за сетями и ExpressRoute Monitor.

• Решения по управлению. Решения по управлению представляют собой упакованные наборы логики, аналитических данных и предопределенных запросов Log Analytics для приложения или службы. Они полагаются на Log Analytics как основу для хранения и анализа данных событий. Пример решений по управлению содержат контрольные контейнеры и аналитику Базы данных Azure SQL.

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

Совет

Перед созданием отдельных предупреждений создайте и поддерживайте набор общих групп действий, которые можно использовать во всех оповещениях Azure. Это позволит централизованно поддерживать жизненный цикл списков получателей, методов доставки уведомлений (электронных писем, номеров телефонов для SMS-уведомлений) и веб-перехватчиков для внешних действий (модулей Runbook со службой автоматизации Azure, Функций Azure и Azure Logic Apps, ITSM).

Управление затратами

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

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

Возможности портала Microsoft Azure

Это средства предоставления мгновенной информации о стоимости, а также способности принятия мер.

• Затраты на ресурсы подписки: на портале представление "Управление затратами Майкрософт" позволяет быстро изучить затраты и сведения о ежедневных расходах по ресурсам или группе ресурсов.

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

• Бюджеты и группы действий Azure. Анализ бюджета и принятие соответствующих мер до недавнего времени выполнялись по большей части вручную. Теперь, с появлением бюджетов и собственных API-интерфейсов Azure, можно создавать действия, которые выполняются, когда затраты достигают порогового значения. Например, можно завершить работу группы ресурсов test, когда она израсходует 100 % своего бюджета.

• Помощник по Azure. Иметь представление о затратах — это только половина дела; что делать с этой информацией — совершенно другое. Помощник по Azure предоставляет рекомендации по действиям, которые необходимо предпринять для экономии средств, повышения надежности или даже повышения безопасности.

Внешние средства управления затратами

• Azure Consumption Insights для Power BI. Хотите создать собственные визуализации для вашей организации? В таком случае пакет содержимого Azure Consumption Insights для Power BI предназначен именно для вас. Используя этот пакет содержимого и Power BI, можно создавать собственные визуализации для представления своей организации, делать более глубокий анализ затрат и добавлять другие источники данных для дальнейшего обогащения.

• API-интерфейсы потребления Azure. Эти интерфейсы предоставляют программируемый доступ к расходам и данным об использовании в дополнение к информации о бюджетах, зарезервированных экземплярах и расходах в marketplace. Эти API-интерфейсы доступны только для регистраций Enterprise и некоторых подписок Web Direct, кроме того, они дают возможность интегрировать ваши данные о расходах в свои собственные инструменты и хранилища данных. Вы также можете получить доступ к этим API-интерфейсам через интерфейс командной строки Azure.

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

• Активное отслеживание затрат. Организации, которые являются опытными пользователями Azure, постоянно отслеживают затраты и при необходимости предпринимают действия. Некоторые организации даже назначают людей, в чьи обязанности входит выполнять анализ и предлагать изменения в использовании, и эти люди более чем окупаются при первом же найденном неиспользуемом кластере HDInsight, который был запущен вот уже несколько месяцев.

• использовать Azure Reserved VM Instances; Еще одним ключевым принципом клиента для управления расходами в облаке является использование правильного средства для работы. Если у вас есть виртуальная машина IaaS, которая работает без перерывов, то использование зарезервированного экземпляра значительно сэкономит средства. Поиск правильного баланса между автоматизацией выключения виртуальных машин и использованием зарезервированных экземпляров требует опыта и анализа.

• Эффективное использование автоматизации. Многие рабочие нагрузки не должны выполняться каждый день. Отключение виртуальной машины в течение четырех часов каждый день может сократить затраты на 15 %. Служба автоматизации быстро окупит себя.

• Использование тегов ресурсов для визуализации. Как упоминалось в другой части этого документа, использование тегов ресурсов позволит лучше анализировать затраты.

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

Автоматизировать

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

Некоторые инструменты могут помочь вам с автоматизацией: от наших собственных средств (служба автоматизации Azure, Сетка событий Azure и Azure CLI) до средств сторонних производителей (например, Terraform, Jenkins, Chef и Puppet). К основным инструментам автоматизации относятся служба автоматизации Azure, Сетка событий Azure и Azure Cloud Shell.

• Служба автоматизации Azure позволяет создавать модули Runbook в PowerShell или Python. Эти модули позволяют автоматизировать процессы, настраивать ресурсы и даже применять исправления. Служба автоматизации Azure имеет расширенный набор кроссплатформенных возможностей, которые являются неотъемлемой частью развертывания, но слишком обширны, чтобы можно было здесь подробно их перечислить и описать.
• Сетка событий Azure. Это полностью управляемая система маршрутизации событий, позволяющая реагировать на события в среде Azure. Подобно тому как служба автоматизации Azure является соединительной тканью в опытных облачных организациях, сетка событий Azure — соединительная ткань хорошей автоматизации. Используя Сетку событий Azure, вы можете создать простое бессерверное действие для отправки сообщений электронной почты администратору всякий раз, когда создается новый ресурс, и зарегистрировать его в базе данных. Эта же Сетка событий может уведомлять, когда ресурс удаляется, и удалять элемент из базы данных.
• Azure Cloud Shell — это интерактивная оболочка на основе веб-браузера для управления ресурсами Azure. Она обеспечивает полную среду для PowerShell или Bash, которая запускается по мере необходимости (и поддерживается для вас), чтобы получить согласованную среду для запуска сценариев. Azure Cloud Shell предоставляет доступ к уже установленным дополнительным инструментам для автоматизации среды, включая Azure CLI, Terraform и множество других средств для управления контейнерами, базами данных (sqlcmd) и т. п.

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

• Управление затратами. Активный поиск возможностей и инструментов для автоматического перераспределения ресурсов, масштабирования и отключения неиспользуемых ресурсов.
• Эксплуатационная гибкость. Благодаря инструментам автоматизации (наряду с шаблонами и инструментами DevOps) можно добиться того уровня повторяемости, который увеличивает доступность, повышает безопасность и позволяет вашей команде сосредоточиться на решении бизнес-задач.

Шаблоны и инструменты DevOps

Как сказано ранее, ваша цель как организации должна заключаться в предоставлении ресурсов с помощью шаблонов и сценариев, контролируемых источником для минимизации интерактивной конфигурации среды. Такой подход инфраструктуры как код (IaC), а также дисциплинированный процесс DevOps для непрерывного развертывания, может обеспечить согласованность и уменьшить смещение между средами. Практически каждый ресурс Azure можно развертывать с помощью шаблонов JSON Azure Resource Manager в сочетании с PowerShell или кроссплатформенным интерфейсом командной строки Azure, такими как Terraform by HashiCorp, который имеет поддержку и интеграцию первого класса с Azure Cloud Shell.

В статье Рекомендации по использованию шаблонов Azure Resource Manager (и не только) представлен разбор рекомендаций и уроков по применению подхода DevOps к шаблонам Azure Resource Manager с использованием цепочки инструментов Azure DevOps. Потратьте время и усилия на разработку основного набора шаблонов, характерных для требований вашей организации, а также для разработки конвейеров непрерывной поставки с цепочками инструментов DevOps (например, Azure DevOps, Jenkins, Bamboo, TeamCity, Concourse), особенно для среды контроля качества. Существует большая библиотека шаблонов быстрого запуска Azure на GitHub, которую можно использовать в качестве отправной точки для шаблонов, и вы можете быстро создавать конвейеры доставки на основе облака с помощью Azure DevOps.

В качестве рекомендаций для подписок на производство или группы ресурсов можно отметить использование RBAC Azure для запрещения доступа интерактивным пользователям по умолчанию и использование автоматических конвейеров непрерывной доставки на основе принципов обслуживания для предоставления всех ресурсов и доставки всего кода приложения. Ни один администратор или разработчик не должен прикасаться к порталу Microsoft Azure для текущей настройки ресурсов. На этом уровне DevOps предпринимаются согласованные усилия и используются все концепции каркаса Azure, что обеспечивает единообразие и безопасность среды, которая будет соответствовать потребностям вашей организации в плане масштабирования.

Совет

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

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

Основная сеть

Заключительным компонентом эталонной модели каркаса Azure является основная возможность получения организацией доступа к Azure, в безопасном режиме. Доступ к ресурсам может быть внутренним (внутри корпоративной сети) или внешним (через Интернет). Пользователи в вашей организации могут случайно помещать ресурсы в расположения, не предназначенные для этих ресурсов, подвергая их опасности вредоносного доступа. Как и в случае локальных устройств, предприятия должны добавить соответствующие элементы управления, чтобы гарантировать, что пользователи Azure принимают правильные решения. Для управления подписками мы определяем основные ресурсы, обеспечивающие базовые элементы управления доступом. К основным ресурсам относятся следующие.

• Виртуальные сети представляют собой объекты контейнеров для подсетей. Хоть это и не является обязательным условием, их часто используют при подключении приложений к внутренним корпоративным ресурсам.

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

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

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

• Группы безопасности — это широкий набор правил, которые предоставляют возможность разрешать или запрещать входящий и исходящий трафик для ресурсов Azure. Группы безопасности объединяют правила безопасности, которые можно дополнить тегами служб (они определяют общие службы Azure, например Azure Key Vault и Базу данных SQL Azure) и группами безопасности приложений (они определяют структуру приложения, например веб-серверы или серверы приложения).

Совет

Используйте теги службы и группы безопасности приложений в группах безопасности сети, чтобы:

• улучшить удобочитаемость правил, что очень важно для понимания их влияния;
• включить эффективную микросегментацию в более крупной подсети, уменьшая ее емкость и повышая гибкость.

Виртуальный центр обработки данных Azure

Azure предоставляет как внутренние возможности, так и возможности от сторонних производителей из нашей расширенной партнерской сети, которые позволяют создать эффективную стратегию обеспечения безопасности. Что еще более важно, корпорация Майкрософт предоставляет методики и рекомендации, доступные в Виртуальном центре обработки данных Azure (VDC). При переходе от одной рабочей нагрузки к нескольким, использующим гибридные возможности, VDC предоставляет инструкции по обеспечению гибкой сети, которая будет расширяться по мере увеличения рабочих нагрузок в Azure.

Следующие шаги

Управление крайне важно для успешной работы Azure. В этой статье рассматривается техническая реализация корпоративного каркаса, но только затрагивается более широкий процесс и связи между компонентами. Политики управления действуют сверху вниз и определяются целями бизнеса. Естественно, в создании модели управления для Azure участвуют представители ИТ-отдела, но, что более важно, в нем должны активно участвовать представители руководителей бизнес-групп, а также специалисты по безопасности и управлению рисками. В конечном счете задача корпоративного каркаса — уменьшить бизнес-риски и помочь в выполнении миссии и достижении целей организации.

Теперь, когда вы узнали о принципах управления подписками, ознакомьтесь с рекомендациями по обеспечению готовности к работе в Azure, чтобы понять, как это работает на практике.