La lliçó anterior va deixar les identitats de Contoso Airlines creades i governades, però amb una mancança deliberada: Contoso-Desarrollo existeix i encara no pot fer absolutament res, mentre que la Marta Ríos és Propietària de tot perquè va ser qui va crear la subscripció. Ni una cosa ni l'altra són acceptables. Avui muntes el sistema que decideix què pot fer cada identitat sobre cada recurs: el control d'accés basat en rols d'Azure, o RBAC. I a la segona meitat resols el problema que arrosseguem des del mòdul 2: app-contoso-reservas-pro guarda avui una clau de compte d'emmagatzematge i una cadena de connexió als seus ajustos d'aplicació. En acabar la lliçó, l'aplicació s'autenticarà contra sttarjetascontosopro i db-reservas sense ni una sola contrasenya enlloc, gràcies a les identitats administrades. És, probablement, la millora de seguretat amb millor relació esforç/benefici de tot el curs.

1. Com autoritza Azure: la tríada de l'assignació de rol
2. Àmbits i herència per la jerarquia
3. Rols integrats imprescindibles
4. El parany: Col·laborador no dona accés a les dades
5. Rols personalitzats: «Operador de Reservas de Contoso»
6. Denegació d'assignacions
7. Mínim privilegi aplicat als grups de Contoso
8. Diagnosticar per què algú no té accés
9. Identitats administrades: què són i què eliminen
10. Assignades pel sistema davant d'assignades per l'usuari
11. El flux del testimoni: IMDS per dins
12. Contoso sense contrasenyes: emmagatzematge i base de dades
13. Errors Comuns i Consells
14. Exercicis
15. Conclusió

Quan algú crida l'API d'Azure Resource Manager, passen dues coses en ordre: Entra ID autentica (qui ets?) i RBAC autoritza (pots fer això?). Una assignació de rol és sempre la unió de tres elements, i si en falta un no hi ha accés.

L'entitat de seguretat és a qui (usuari, grup, entitat de servei o identitat administrada); la definició de rol és què (una col·lecció d'operacions permeses a Actions i restades a NotActions); i l'àmbit és on (el nivell de la jerarquia sobre el qual s'aplica).

Fer servir --assignee-object-id amb --assignee-principal-type en lloc de --assignee estalvia una consulta extra a Graph i, sobretot, evita la fallada intermitent de les assignacions a identitats acabades de crear, la propagació de les quals al directori triga uns segons.

RBAC s'hereta cap avall per la jerarquia d'Azure Resource Manager que vas veure a 01-05: grup d'administració (mg-contoso) → subscripció (Contoso Airlines - Producció) → grup de recursos (rg-contoso-reservas-pro) → recurs (app-contoso-reservas-pro).

Qui és Lector a la subscripció és Lector a tots els seus grups de recursos i a tots els recursos de dins. Els permisos són acumulatius i només sumen: no existeix la «denegació per rol», així que donar Lector en un grup de recursos a qui ja és Col·laborador de la subscripció no li treu res.

El grup d'administració es reserva per a rols transversals de govern (Lector per a auditoria) i abasta totes les subscripcions; la subscripció, per a administració de plataforma; el recurs, per a excepcions puntuals difícils de mantenir. Contoso assigna gairebé tot a nivell de grup de recursos, que coincideix amb el cicle de vida de cada càrrega de treball. I sempre a grups d'Entra ID, no a persones: amb quatre grups i quatre grups de recursos hi ha 16 combinacions possibles i cap no es refà quan algú canvia d'equip; amb assignacions individuals, cada alta i cada baixa és una revisió manual de tota la subscripció. Hi ha un límit dur que a més ho obliga: 4.000 assignacions de rol per subscripció, i les empreses que assignen a persones l'assoleixen.

Azure porta més de 400 rols integrats. Aquests són els que es fan servir cada dia:

La diferència entre Propietari i Col·laborador es redueix a una sola cosa, però enorme: Propietari pot assignar rols, és a dir, pot donar-se a si mateix i a qualsevol qualsevol permís. Per això és el rol que menys gent ha de tenir i el candidat número u per a PIM (04-01).

Aquest és el punt que més confusió genera en tot RBAC, i convé entendre'l amb el cas concret.

En Diego Salas és Col·laborador de rg-contoso-reservas-pro. Amb aquest rol pot veure sttarjetascontosopro, canviar-ne el nivell d'accés, la redundància i el tallafoc, i fins i tot eliminar el compte d'emmagatzematge sencer amb les targetes d'embarcament de dos anys a dins. I no pot llegir ni un sol blob del contenidor tarjetas-embarque.

No és un error de configuració: Azure té dos plans. El pla de gestió (management.azure.com) crea, configura i esborra recursos. El pla de dades (<compte>.blob.core.windows.net, <vault>.vault.azure.net) llegeix i escriu el contingut. Col·laborador cobreix el primer per complet i el segon gens.

La conseqüència no és una molèstia, és la base del mínim privilegi: la Marta Ríos pot administrar la infraestructura sense poder llegir les dades personals dels passatgers, cosa que l'RGPD agraeix i que a més redueix el dany si li roben la sessió. I hi ha un matís important: mentre existeixin claus de compte, un Col·laborador les pot llegir (listKeys) i amb elles accedir a les dades, saltant-se tot l'anterior. Per això Contoso desactivarà l'autenticació per clau —ho veuràs a l'apartat 12— i per això les claus i les SAS del mòdul 2 desapareixeran.

Contoso-Operaciones necessita una cosa que cap rol integrat no ofereix: reiniciar l'aplicació web quan es penja i consultar mètriques, sense poder canviar la configuració ni esborrar res. Això és un rol personalitzat.

Cada bloc importa:

• Actions: operacions del pla de gestió permeses, amb el format Proveïdor/tipusRecurs/operació. Aquí, llegir llocs, reiniciar-los, intercanviar ranures (per promoure preproduccion) i consultar mètriques.
• NotActions: es resten d'Actions. config/list/action retorna els ajustos de l'aplicació, que inclouen cadenes de connexió: la resta ho deixa explícit i documentat.
• DataActions / NotDataActions: l'equivalent per al pla de dades, buides a propòsit, perquè operacions no necessita llegir targetes d'embarcament. I AssignableScopes: on es pot assignar el rol; limitar-lo al grup de recursos de producció impedeix aplicar-lo per error a tota la subscripció.

Abans de crear un rol personalitzat, busca si ja n'existeix un d'integrat: az role definition list --query "[?contains(roleName,'Website')].roleName" -o tsv. Els personalitzats s'han de mantenir quan Azure afegeix operacions noves, i aquest manteniment és real. El límit és de 5.000 rols personalitzats per inquilí, però el problema pràctic arriba molt abans, en forma de catàleg impossible de gestionar.

Existeix un mecanisme que bloqueja operacions encara que un rol les permeti: la denegació d'assignacions, que sempre guanya davant de qualsevol concessió. No es pot crear directament per CLI ni pel portal; la generen serveis d'Azure com Blueprints o les implementacions administrades d'aplicacions. Es menciona aquí perquè, si algun dia veus un accés denegat sent Propietari, sàpigues on mirar: az role assignment list-deny.

Regla pràctica de Contoso: Propietari només mitjançant PIM i amb aprovació, Col·laborador en producció només per a infraestructura, i tothom qui «només necessita mirar» rep Lector. El 90 % de les peticions d'accés es resolen amb Lector més un rol de dades concret.

Quan algú diu «no puc», segueix aquest ordre:

Si la CLI no aclareix res, al portal hi ha Control d'accés (IAM) → Comprovar accés, que mostra l'accés efectiu d'una identitat sobre aquest recurs amb l'origen de cada permís. I si l'accés s'ha perdut, el registre d'activitat diu qui va retirar l'assignació i quan: filtra per l'operació Microsoft.Authorization/roleAssignments/delete.

Quatre causes expliquen gairebé tots els casos: (1) el rol és de gestió i l'operació és de dades —apartat 4—; (2) l'àmbit és més estret del que es creia; (3) l'assignació es va fer en una altra subscripció; (4) l'assignació és correcta però el testimoni de l'usuari és anterior i cal tancar la sessió i tornar a entrar. La propagació de RBAC triga fins a cinc minuts, i de tant en tant una mica més.

Ara el segon problema. app-contoso-reservas-pro té avui, als seus ajustos d'aplicació, una clau de sttarjetascontosopro i una cadena de connexió amb usuari i contrasenya de db-reservas. Aquests secrets existeixen com a mínim en quatre llocs: la configuració de l'aplicació, el fitxer .env del portàtil d'en Diego, l'historial del repositori i un correu de fa vuit mesos. No han rotat mai. Si algun es filtra, l'atacant llegeix les targetes d'embarcament de tots els passatgers.

Una identitat administrada és una entitat de servei d'Entra ID el cicle de vida i les credencials de la qual els gestiona Azure: el recurs obté testimonis sense que existeixi una contrasenya que algú pugui copiar, escriure en un fitxer o filtrar. No hi ha credencial per rotar perquè no hi ha credencial. És gratuïta i està disponible a App Service, Functions, VMs, VMSS, Container Apps, AKS, Data Factory, Logic Apps i pràcticament tota la resta.

Contoso fa servir l'assignada pel sistema per a app-contoso-reservas-pro, perquè és una aplicació única. Per a vmss-api-disponibilidad-pro, on les instàncies es creen i es destrueixen amb l'escalat automàtic, fa servir una assignada per l'usuari anomenada id-contoso-api-pro: els permisos es concedeixen una vegada a la identitat i totes les instàncies els hereten, presents i futures. Si a més desplegaràs amb Bicep (05-06), l'assignada per l'usuari evita el problema de l'ou i la gallina: es crea primer, se li donen permisos i després s'associa als recursos.

L'essencial d'aquest flux: la petició del testimoni viatja a 169.254.169.254, una adreça link-local no encaminable que només respon dins de la mateixa màquina virtual o instància. Cap atacant extern no pot demanar aquest testimoni perquè no pot arribar a aquest punt de connexió; i com que tot passa dins del recurs, no hi ha secret per transmetre. A App Service el mecanisme és equivalent, exposat mitjançant les variables IDENTITY_ENDPOINT i IDENTITY_HEADER, que l'SDK fa servir automàticament.

Primer s'activa la identitat i es desa el seu identificador d'objecte:

Després se li concedeix accés a les dades, amb el rol més estret possible i en l'àmbit més estret possible —el contenidor, no el compte:

Aquesta darrera línia és la que converteix l'exercici en una millora real: amb --allow-shared-key-access false, les claus de compte i les SAS del mòdul 2 deixen de funcionar, i l'únic accés possible passa per identitats d'Entra ID amb el seu rol. Abans d'executar-la cal assegurar-se que cap procés heretat no les fa servir, perquè el tall és immediat.

Per a db-reservas, la base ja té autenticació només amb Entra ID sobre el grup Contoso-DBA-Reservas (03-02). Falta crear l'usuari de l'aplicació, executant això connectat com a administrador d'Entra ID:

El nom de l'usuari és exactament el del recurs d'App Service, que és com es diu la seva identitat administrada. Fixa't que no se li dona db_owner: llegir, escriure i executar procediments és tot el que l'aplicació necessita, i amb això no pot alterar l'esquema.

Al codi, tot això es redueix a una classe. DefaultAzureCredential prova en ordre les credencials disponibles —variables d'entorn, identitat administrada, Azure CLI, Visual Studio— de manera que el mateix codi funciona al portàtil d'en Diego i en producció sense canvis ni secrets:

L'equivalent en Python és literalment el mateix patró: DefaultAzureCredential() es passa com a paràmetre credential de BlobServiceClient, i no apareix cap clau enlloc. Compara les dues cadenes de connexió: la del mòdul 3 duia usuari i contrasenya; aquesta no duu res. No hi ha secret per rotar, filtrar ni revocar. Els secrets que sí que continuen existint —claus d'APIs de tercers, el certificat de la passarel·la de pagament— són el tema de la lliçó següent.

• Donar Col·laborador i esperar accés a les dades. És la incidència número u. Els rols de dades són uns altres (apartat 4).
• Assignar Propietari «perquè no molesti», o assignar rols a persones i no a grups, o pujar a l'àmbit de subscripció per comoditat. Els tres són la mateixa peresa i els tres es paguen el mes dotze.
• Deixar les claus de compte actives després de passar a identitat administrada. Si allow-shared-key-access continua a true, la porta antiga continua oberta i qualsevol Col·laborador la pot fer servir.
• Crear un rol personalitzat abans de buscar l'integrat. N'hi ha més de 400; gairebé sempre n'existeix un que serveix, i el personalitzat s'ha de mantenir.
• Oblidar que la identitat assignada pel sistema mor amb el recurs. Si recrees l'aplicació, les seves assignacions de rol queden òrfenes. I tingues paciència amb la propagació: RBAC triga fins a cinc minuts, i el testimoni de l'usuari fins que torni a iniciar sessió.
• Consell: crea una sola instància de DefaultAzureCredential i reutilitza-la. Una per petició dispara la latència i pot provocar limitació de sol·licituds.
• Consell: revisa trimestralment az role assignment list --all buscant assignacions òrfenes (les identitats esborrades apareixen com a GUID sense nom) i elimina-les.

El projecte «Contoso Millas» (centro-coste=CC-2077) té rg-contoso-millas-pro i rg-contoso-millas-dev. Hi participen: tres desenvolupadors que despleguen a desenvolupament i necessiten diagnosticar producció; un analista que només consulta mètriques i costos; una aplicació web que llegeix i escriu blobs a stmillascontosopro; i la Marta Ríos, que administra la infraestructura.

1. Indica entitat, rol i àmbit per a cada cas, en format de taula.
2. Quina d'aquestes quatre entitats no ha de ser un usuari, i què ha de ser?
3. Quina assignació posaries sota PIM i per què?

Contoso necessita un rol «Soporte de Reservas de Contoso» que permeti llegir qualsevol recurs del grup de producció, reiniciar màquines virtuals i obrir tiquets de suport, però mai llegir secrets de Key Vault ni dades de blobs.

1. Escriu el json de la definició amb Actions, NotActions, DataActions i AssignableScopes.
2. Per què DataActions buit ja impedeix llegir blobs, encara que no aparegui res a NotDataActions?
3. Quina ordre faries servir per esbrinar el nom exacte de l'acció de reinici d'una VM?

L'API de Disponibilitat corre a vmss-api-disponibilidad-pro i guarda en un fitxer de configuració la clau de stoperacionescontosopro i la contrasenya de cosmos-contoso-tarifas-pro.

1. Quin tipus d'identitat administrada correspon aquí i per què no l'altra?
2. Enumera els passos, amb les ordres, per eliminar tots dos secrets.
3. Un desenvolupador diu que «en local no funcionarà perquè no hi ha identitat administrada». Què li respons?

Solució 1:

1. Grup Contoso-Millas-Desarrollo: Col·laborador a rg-contoso-millas-dev i Lector a rg-contoso-millas-pro. Analista: Lector més Lector de Cost Management a la subscripció. Aplicació web: Col·laborador de dades de Blob Storage al contenidor de stmillascontosopro, mai al compte sencer. La Marta, a través de Contoso-Infraestructura: Col·laborador a la subscripció, apte via PIM.
2. L'aplicació web: ha de ser una identitat administrada, no un usuari ni una entitat de servei amb secret. Cap aplicació no necessita una contrasenya a Azure.
3. Les de la Marta, i qualsevol Propietari o Administrador d'accés d'usuari: són les que permeten escalar privilegis, i amb PIM no existeixen en repòs. L'accés de Lector de desenvolupament sobre producció no ho necessita: és de només lectura i el seu ús és quotidià.

Solució 2:

1. Actions: */read, Microsoft.Compute/virtualMachines/restart/action, Microsoft.Support/*. NotActions: Microsoft.KeyVault/vaults/secrets/read, Microsoft.Storage/storageAccounts/listKeys/action (crítica: sense ella, */read no la inclou però convé deixar-la explícita, i evita obtenir claus si s'ampliessin les accions). DataActions: []. NotDataActions: []. AssignableScopes: l'identificador de rg-contoso-reservas-pro.
2. Perquè el pla de dades denega per defecte: només es concedeix el que apareix explícitament a DataActions. NotDataActions serveix per restar d'un conjunt concedit, i aquí no n'hi ha cap. Sense DataActions, no hi ha accés a dades, punt.
3. az provider operation show --namespace Microsoft.Compute --query "resourceTypes[?name=='virtualMachines'].operations[].name", o la mateixa ordre filtrant per restart.

Solució 3:

1. Assignada per l'usuari (id-contoso-api-pro). En un conjunt d'escalat les instàncies neixen i moren constantment; amb identitat assignada pel sistema, cada instància tindria el seu propi identificador i caldria assignar-li permisos en crear-se, cosa inviable amb escalat automàtic. Amb l'assignada per l'usuari els permisos es concedeixen una vegada i totes les instàncies els hereten.
2. Crear la identitat (az identity create -g rg-contoso-reservas-pro -n id-contoso-api-pro); associar-la al conjunt (az vmss identity assign --identities); assignar-li Col·laborador de dades de Blob Storage sobre el contenidor de stoperacionescontosopro i Col·laborador de dades integrat de Cosmos DB sobre la base catalogo (amb az cosmosdb sql role assignment create, que és el sistema RBAC propi de Cosmos); desactivar l'accés per clau a l'emmagatzematge amb --allow-shared-key-access false i deshabilitar les claus de Cosmos amb --disable-key-based-metadata-write-access; i finalment eliminar el fitxer de configuració i purgar el secret de l'historial del repositori.
3. Que sí que funciona: DefaultAzureCredential recorre una cadena de proveïdors i, si no troba identitat administrada, fa servir la sessió d'Azure CLI (az login) o la de Visual Studio Code. El codi és idèntic en local i en producció; l'únic que canvia és d'on surt el testimoni. N'hi ha prou de donar al seu usuari el rol de dades corresponent a l'entorn de desenvolupament.

Ja saps com autoritza Azure. Una assignació de rol és sempre una tríada —entitat de seguretat, definició de rol i àmbit— que s'hereta cap avall per la jerarquia grup d'administració, subscripció, grup de recursos i recurs, amb permisos que només sumen. Coneixes els rols integrats que es fan servir de debò i la diferència decisiva entre Propietari i Col·laborador: assignar rols. I tens clar el parany que més incidències genera: Col·laborador no dona accés a les dades, perquè el pla de gestió i el pla de dades són universos separats, de manera que en Diego pot esborrar sttarjetascontosopro sencera i no pot llegir ni un sol PDF de dins. Has escrit el rol personalitzat «Operador de Reservas de Contoso» entenent Actions, NotActions, DataActions i AssignableScopes, saps que existeix la denegació d'assignacions i has repartit els permisos dels quatre grups de Contoso amb mínim privilegi real, a més d'un procediment ordenat per diagnosticar per què algú no té accés.

A la segona meitat has eliminat el problema d'arrel. Les identitats administrades són entitats de servei les credencials de les quals les gestiona Azure, distingeixes les assignades pel sistema —una per recurs, moren amb ell— de les assignades per l'usuari —compartides, amb permisos preassignables, obligatòries a vmss-api-disponibilidad-pro—, i entens el flux del testimoni contra el punt de connexió local IMDS a 169.254.169.254, no encaminable des de fora. Amb això, app-contoso-reservas-pro accedeix a sttarjetascontosopro amb el rol Col·laborador de dades de Blob Storage i a db-reservas com a usuari extern amb db_datareader i db_datawriter, s'ha desactivat l'accés per clau compartida i DefaultAzureCredential fa que el mateix codi funcioni al portàtil i en producció sense ni un sol secret.

Però no tots els secrets desapareixen així. Contoso continua tenint la clau de la passarel·la de pagament, el testimoni del proveïdor de dades meteorològiques, el certificat TLS de contosoairlines.example i unes quantes cadenes de connexió de sistemes heretats, avui repartides entre ajustos d'aplicació, el repositori i un document compartit. A la lliçó següent, Azure Key Vault, centralitzaràs tot això a kv-contoso-pro dins de rg-contoso-seguridad-pro, amb eliminació temporal, protecció contra purga, permisos per RBAC i punt de connexió privat, i faràs que l'aplicació els llegeixi amb la mateixa identitat administrada d'avui mitjançant referències @Microsoft.KeyVault(...). És el moment en què les contrasenyes desapareixen també del desplegament.