Marcas e Bloqueios de Recursos

As marcas de recursos são pares nome-valor de metadados anexados aos recursos, grupos de recursos e assinaturas do Azure. Diferentemente das estruturas de pastas, as marcas permitem categorizar um único recurso em várias dimensões simultaneamente. Por exemplo, uma VM pode ter as marcas Environment=Production, Team=Backend, CostCentre=CC-042 e Project=Phoenix ao mesmo tempo, permitindo a filtragem independente por qualquer uma dessas dimensões.

Normalmente, as organizações definem uma taxonomia de marcas padrão que abrange várias dimensões. As marcas financeiras (CostCentre, BudgetOwner) permitem alocar custos. As marcas operacionais (Environment, Criticality, Owner) facilitam a filtragem e os alertas. As marcas de ciclo de vida (AutoShutdown, ExpiryDate) permitem a automação. As marcas de segurança (DataClassification, Compliance) dão suporte às ferramentas de segurança. Definir a taxonomia antes de implantar os recursos evita um conjunto de marcas inconsistente e impossível de consultar.

As tags podem ser aplicadas através do portal do Azure, da CLI, de modelos ARM, do Bicep e do Terraform. O comando az tag gere tags nos recursos, enquanto az group update aplica tags aos grupos de recursos. Ao utilizar Azure Policy com o efeito Modify ou Append, pode adicionar ou exigir tags automaticamente no momento da criação do recurso — garantindo que todos os recursos novos tenham uma tag CostCentre, sem depender de que os programadores se lembrem de a adicionar manualmente.

É comum pensar, incorretamente, que as tags de um grupo de recursos são automaticamente propagadas para os recursos que ele contém. Isso não acontece — as tags de recursos do Azure não são herdadas dos escopos principais. Se aplicar a tag Environment=Production a um grupo de recursos, as VMs e as bases de dados desse grupo não receberão automaticamente essa tag. Para impor uma etiquetagem consistente, utilize uma Azure Policy com a definição incorporada Inherit a tag from the resource group, que copia automaticamente a tag do grupo de recursos para todos os recursos nele contidos.

As tags são especialmente úteis quando combinadas com o Azure Cost Management. Na vista de análise de custos, pode agrupar as despesas por qualquer chave de tag — por exemplo, consultar a despesa mensal total por CostCentre para identificar qual departamento consome mais recursos da nuvem. Também pode filtrar por Environment=Production para excluir as despesas de desenvolvimento dos orçamentos de produção. O Azure Cost Management exige que a tag tenha sido aplicada antes do período de faturação para que apareça nos dados de custos.

Os bloqueios de recursos protegem os recursos do Azure contra eliminação ou modificação acidental, independentemente das permissões RBAC do utilizador. Um utilizador com direitos de Owner ou Contributor pode continuar impedido de eliminar ou modificar um recurso bloqueado. Os bloqueios são aplicados ao nível do recurso, do grupo de recursos ou da subscrição e propagam-se para baixo — um bloqueio num grupo de recursos protege todos os recursos nele contidos.

O Azure suporta dois tipos de bloqueio. CanNotDelete (bloqueio contra eliminação) permite que os utilizadores leiam e modifiquem o recurso, mas impede a sua eliminação. Este é o bloqueio mais comum — aplicado a bases de dados de produção, contas de armazenamento e VNets para evitar a remoção acidental. ReadOnly impede todas as operações de escrita e eliminação, fazendo com que o recurso se comporte como se a função Reader tivesse sido atribuída a todos. ReadOnly é mais restritivo e pode interromper processos automatizados que atualizam as propriedades dos recursos.

Para eliminar ou modificar um recurso bloqueado, o utilizador deve primeiro remover o bloqueio — o que requer a permissão Microsoft.Authorization/locks/delete (disponível, por predefinição, para as funções Owner e User Access Administrator). A remoção do bloqueio, a modificação do recurso e a eventual reaplicação do bloqueio podem ser integradas num fluxo de trabalho de gestão de alterações, garantindo que os recursos protegidos continuam a poder ser modificados através de um processo controlado e com um registo de auditoria.

Um bloqueio aplicado a um escopo principal (subscrição ou grupo de recursos) é herdado por todos os recursos subordinados. Não é possível substituir um bloqueio num escopo inferior — se um grupo de recursos tiver um bloqueio CanNotDelete, não será possível eliminar recursos individuais nele contidos, mesmo que não tenham um bloqueio aplicado diretamente. Adicionar um bloqueio CanNotDelete ao nível do recurso, além de um bloqueio principal, não altera o comportamento; o bloqueio principal já fornece essa proteção.

Os bloqueios ReadOnly podem causar falhas inesperadas em processos automatizados. Algumas operações do Azure que parecem ser apenas de leitura exigem, na realidade, acesso de escrita às propriedades dos recursos nos bastidores. Por exemplo, a apresentação das chaves de acesso de uma conta de armazenamento é bloqueada por um bloqueio ReadOnly, porque a ação de listar as chaves modifica o registo de auditoria da conta. O aumento da capacidade de uma VM, o reinício de um App Service e a ligação de um disco a uma VM em execução também são bloqueados. Teste os bloqueios ReadOnly em ambientes que não sejam de produção antes de os aplicar a recursos críticos.

A combinação de tags e bloqueios cria um padrão de governação poderoso. Pode utilizar uma tag como Protected=true para marcar os recursos que devem ter bloqueios CanNotDelete e, em seguida, executar um Runbook do Azure Automation que consulta os recursos com essa tag e cria o bloqueio caso esteja em falta. Este padrão de governação com autorrecuperação garante que, mesmo que um administrador remova acidentalmente um bloqueio, este seja reaplicado automaticamente de acordo com a agenda do runbook.

Teste a sua compreensão dos conceitos do Microsoft Azure Fundamentals (AZ-900) abordados nesta lição.

Nesta lição, aprendeu que: as tags de recursos são pares de metadados nome-valor que permitem a alocação de custos, a filtragem e a automatização em qualquer dimensão; as tags não são herdadas dos grupos de recursos principais e devem ser impostas através de Azure Policy; e os bloqueios de recursos (CanNotDelete e ReadOnly) protegem os recursos contra alterações acidentais, independentemente das permissões RBAC. De seguida, exploraremos os Azure Blueprint para agrupar artefactos de governação.