Теги и блокировки ресурсов

Теги ресурсов — это пары имя-значение с метаданными, которые добавляются к ресурсам Azure, группам ресурсов и подпискам. В отличие от структуры папок, теги позволяют одновременно классифицировать один ресурс по нескольким измерениям. Например, VM может одновременно иметь теги Environment=Production, Team=Backend, CostCentre=CC-042 и Project=Phoenix, что позволяет независимо фильтровать ресурсы по любому из этих измерений.

Обычно организации определяют стандартную таксономию тегов, охватывающую несколько измерений. Финансовые теги (CostCentre, BudgetOwner) позволяют распределять затраты. Операционные теги (Environment, Criticality, Owner) помогают фильтровать данные и настраивать оповещения. Теги жизненного цикла (AutoShutdown, ExpiryDate) обеспечивают автоматизацию. Теги безопасности (DataClassification, Compliance) поддерживают инструменты безопасности. Определение таксономии до развёртывания ресурсов предотвращает появление непоследовательного набора тегов, по которому нельзя выполнять запросы.

Теги можно применять через портал Azure, CLI, ARM-шаблоны, Bicep и Terraform. Команда az tag управляет тегами ресурсов, а az group update — тегами групп ресурсов. Используя Azure Policy с эффектом Modify или Append, Вы можете автоматически добавлять теги при создании ресурсов или требовать их наличия — это гарантирует, что каждый новый ресурс будет иметь тег CostCentre, и разработчикам не придётся помнить о его добавлении вручную.

Распространённое заблуждение заключается в том, что теги группы ресурсов автоматически распространяются на содержащиеся в ней ресурсы. Это не так — теги ресурсов Azure не наследуются из родительских областей. Если Вы добавите к группе ресурсов тег Environment=Production, виртуальные машины и базы данных внутри этой группы автоматически не получат этот тег. Чтобы обеспечить единообразную маркировку, используйте встроенное определение Azure Policy Inherit a tag from the resource group, которое автоматически копирует тег группы ресурсов во все содержащиеся в ней ресурсы.

Теги наиболее эффективны в сочетании с Azure Cost Management. В представлении анализа затрат можно сгруппировать расходы по любому ключу тега — например, посмотреть общие ежемесячные расходы по CostCentre и определить, какой отдел потребляет больше всего облачных ресурсов. Также можно отфильтровать данные по Environment=Production, чтобы исключить расходы на разработку из производственных бюджетов. Azure Cost Management учитывает тег в данных о затратах только в том случае, если он был применён до начала расчётного периода.

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

Azure поддерживает два типа блокировок. CanNotDelete (блокировка удаления) позволяет пользователям просматривать и изменять ресурс, но запрещает его удаление. Это наиболее распространённый тип блокировки: его применяют к рабочим базам данных, учётным записям хранения и VNet, чтобы предотвратить случайное удаление. ReadOnly запрещает все операции записи и удаления, поэтому ресурс ведёт себя так, будто всем назначена только роль Reader. ReadOnly является более строгой блокировкой и может нарушить работу автоматизированных процессов, которые изменяют свойства ресурсов.

Чтобы удалить или изменить заблокированный ресурс, пользователь должен сначала удалить блокировку — для этого требуется разрешение Microsoft.Authorization/locks/delete, доступное по умолчанию ролям Owner и User Access Administrator. Удаление блокировки, изменение ресурса и её последующее восстановление при необходимости можно включить в сценарий рабочего процесса управления изменениями. Это позволяет изменять защищённые ресурсы контролируемым способом с сохранением аудиторского следа.

Блокировка, применённая в родительской области (подписке или группе ресурсов), наследуется всеми дочерними ресурсами. Переопределить блокировку в области нижнего уровня нельзя: если для группы ресурсов установлена блокировка CanNotDelete, отдельные ресурсы внутри неё нельзя удалить, даже если непосредственно на них блокировка не установлена. Добавление блокировки CanNotDelete на уровне ресурса вместе с родительской блокировкой ничего не меняет: родительская блокировка уже обеспечивает защиту.

Блокировки ReadOnly могут приводить к неожиданным сбоям в автоматизированных процессах. Некоторые операции Azure, которые на первый взгляд предназначены только для чтения, фактически требуют фонового доступа на запись к свойствам ресурсов. Например, получение списка ключей доступа учётной записи хранения блокируется ReadOnly, поскольку это действие изменяет журнал аудита учётной записи. Также блокируются изменение размера VM, перезапуск App Service и подключение диска к работающей VM. Протестируйте блокировки ReadOnly в средах, не относящихся к Production, прежде чем применять их к критически важным ресурсам.

Сочетание тегов и блокировок позволяет создать эффективную модель управления. Вы можете использовать тег, например Protected=true, чтобы пометить ресурсы, для которых должны быть установлены блокировки CanNotDelete, а затем запустить Azure Automation Runbook, который найдёт ресурсы с этим тегом и создаст блокировку, если она отсутствует. Такая модель самовосстанавливающегося управления гарантирует, что даже при случайном удалении блокировки администратором она будет автоматически восстановлена при следующем запуске Runbook.

Проверьте своё понимание концепций Microsoft Azure Fundamentals (AZ-900), рассмотренных в этом уроке.

В этом уроке Вы узнали, что теги ресурсов — это пары метаданных «имя — значение», которые позволяют распределять затраты, фильтровать данные и автоматизировать процессы по любому признаку, теги не наследуются от родительских групп ресурсов и должны принудительно применяться с помощью Azure Policy, а блокировки ресурсов (CanNotDelete и ReadOnly) защищают ресурсы от случайных изменений независимо от разрешений RBAC. Далее мы рассмотрим Azure Blueprints для объединения артефактов управления.