Ressourcetags og ressourcelåse

Ressource-tags er navne-værdi-par med metadata, som du knytter til Azure-ressourcer, ressourcegrupper og abonnementer. I modsætning til mappestrukturer gør tags det muligt at kategorisere en enkelt ressource efter flere dimensioner samtidigt. En VM kan f.eks. have tagsene Environment=Production, Team=Backend, CostCentre=CC-042 og Project=Phoenix på én gang, så du kan filtrere efter hver af dimensionerne uafhængigt af hinanden.

Organisationer definerer typisk en standardiseret tagtaksonomi, der dækker flere dimensioner. Økonomiske tags (CostCentre, BudgetOwner) muliggør omkostningsfordeling. Driftstags (Environment, Criticality, Owner) understøtter filtrering og alarmering. Livscyklustags (AutoShutdown, ExpiryDate) muliggør automatisering. Sikkerhedstags (DataClassification, Compliance) understøtter sikkerhedsværktøjer. Hvis du definerer taksonomien, før du installerer ressourcer, undgår du et inkonsekvent taglandskab, der ikke kan forespørges effektivt.

Tags kan anvendes via Azure-portalen, CLI, ARM-skabeloner, Bicep og Terraform. Kommandoen az tag administrerer tags på ressourcer, mens az group update anvender tags på ressourcegrupper. Ved at bruge Azure Policy med effekten Modify eller Append kan du automatisk tilføje eller kræve tags, når ressourcer oprettes — så du sikrer, at alle nye ressourcer har et CostCentre-tag uden at være afhængig af, at udviklere husker at tilføje det manuelt.

En almindelig misforståelse er, at tags på en ressourcegruppe automatisk videreføres til ressourcerne i den. Det gør de ikke — Azure-ressourcetags nedarves ikke fra overordnede scopes. Hvis du giver en ressourcegruppe tagget Environment=Production, får de VM'er og databaser, der ligger i gruppen, ikke automatisk dette tag. Hvis du vil håndhæve ensartet tagging, skal du bruge den indbyggede Azure Policy-definition Inherit a tag from the resource group, som automatisk kopierer ressourcegruppens tag til alle ressourcer i den.

Tags er mest effektive, når de kombineres med Azure Cost Management. I visningen Cost Analysis kan du gruppere forbruget efter en vilkårlig tag-nøgle — du kan for eksempel se det samlede månedlige forbrug efter CostCentre for at se, hvilken afdeling der bruger mest cloud. Du kan også filtrere efter Environment=Production for at udelukke udviklingsforbrug fra produktionsbudgetter. Azure Cost Management kræver, at tagget blev anvendt før faktureringsperioden, for at det vises i omkostningsdataene.

Ressourcelåse beskytter Azure-ressourcer mod utilsigtet sletning eller ændring, uanset hvilke RBAC-tilladelser en bruger har. En bruger med Owner- eller Contributor-rettigheder kan stadig blive forhindret i at slette eller ændre en låst ressource. Låse anvendes på ressource-, ressourcegruppe- eller abonnementsniveau og nedarves nedad — en lås på en ressourcegruppe beskytter alle ressourcer i den.

Azure understøtter to låsetyper. CanNotDelete (slettelås) giver brugere mulighed for at læse og ændre ressourcen, men forhindrer sletning. Dette er den mest almindelige lås — den anvendes på produktionsdatabaser, lagerkonti og VNet'er for at forhindre utilsigtet nedtagning. ReadOnly forhindrer alle skrive- og slettehandlinger, så ressourcen opfører sig, som om alle kun havde rollen Reader. ReadOnly er mere restriktiv og kan forstyrre automatiserede processer, der opdaterer ressourceegenskaber.

Hvis en bruger vil slette eller ændre en låst ressource, skal vedkommende først fjerne låsen — det kræver tilladelsen Microsoft.Authorization/locks/delete (som standard tilgængelig for rollerne Owner og User Access Administrator). Fjernelse af låsen, ændring af ressourcen og eventuel genanvendelse af låsen kan indarbejdes i en ændringsstyringsarbejdsgang, så beskyttede ressourcer stadig kan ændres gennem en kontrolleret proces med et revisionsspor.

En lås, der anvendes på et overordnet scope (abonnement eller ressourcegruppe), nedarves af alle underordnede ressourcer. Du kan ikke tilsidesætte en lås på et lavere scope — hvis en ressourcegruppe har en CanNotDelete-lås, kan individuelle ressourcer i den ikke slettes, selv om de ikke har en lås anvendt direkte på sig. Hvis du tilføjer en CanNotDelete-lås på ressourceniveau ud over en overordnet lås, ændrer det ikke adfærden; den overordnede lås yder allerede beskyttelsen.

ReadOnly-låse kan forårsage uventede fejl i automatiserede processer. Nogle Azure-handlinger, der umiddelbart ser skrivebeskyttede ud, kræver faktisk skriveadgang til ressourceegenskaber i baggrunden. Det er for eksempel blokeret af en ReadOnly-lås at vise en lagerkontos adgangsnøgler, fordi handlingen med at vise nøgler ændrer kontoens revisionsspor. Skalering af en VM, genstart af en App Service og tilknytning af en disk til en kørende VM er også blokeret. Test ReadOnly-låse i ikke-produktionsmiljøer, før du anvender dem på kritiske ressourcer.

Ved at kombinere tags og låse får du et effektivt mønster til styring. Du kan bruge et tag som Protected=true til at markere ressourcer, der skal have CanNotDelete-låse, og derefter køre en Azure Automation Runbook, som søger efter ressourcer med dette tag og opretter låsen, hvis den mangler. Dette mønster for selvreparerende styring sikrer, at en lås automatisk anvendes igen inden for runbookens tidsplan, selv hvis en administrator ved en fejl fjerner den.

I denne lektion har du lært, at ressourcetags er metadata-par af navne og værdier, som muliggør omkostningsfordeling, filtrering og automatisering på tværs af alle dimensioner, at tags ikke nedarves fra overordnede ressourcegrupper og skal håndhæves via Azure Policy, og at ressourcelåse (CanNotDelete og ReadOnly) beskytter ressourcer mod utilsigtede ændringer uanset RBAC-tilladelser. Dernæst ser vi på Azure Blueprints til at samle styringsartefakter.