El mòdul 3 va acabar amb una llista incòmoda: contrasenyes escrites a mà, secrets dins de cadenes de connexió i permisos amplis «perquè era el més ràpid». Avui comença la feina de tancar aquest deute, i comença pel lloc correcte. En una infraestructura clàssica, la seguretat es construïa sobre el perímetre: si eres dins la xarxa de l'oficina de Barcelona, eres de confiança. A Azure aquest perímetre no existeix —la Marta Ríos administra la producció des d'un portàtil en un aeroport i app-contoso-reservas-pro s'executa en un centre de dades on ningú de Contoso Airlines no ha entrat mai—, així que la identitat passa a ser el perímetre. Cada crida a l'API d'Azure, cada consulta a db-reservas i cada lectura d'un blob de sttarjetascontosopro s'autoritza en funció de qui la fa. I aquest «qui» el defineix un únic servei: Microsoft Entra ID. Tota la seguretat de la resta del mòdul —RBAC, identitats administrades, Key Vault, Defender for Cloud— es recolza en el que muntis avui.

Avís important: les decisions d'identitat d'aquesta lliçó (accés condicional, MFA obligatori, bloquejos geogràfics, rols privilegiats) afecten qui pot entrar als sistemes de l'empresa i tenen implicacions legals i de compliment. Abans d'aplicar qualsevol configuració d'aquest tipus en producció, l'ha de revisar un professional de seguretat o l'equip de compliance de la teva organització. Una política mal mesurada pot deixar fora tota la plantilla o obrir una porta que et pensaves tancada.

1. La identitat com a perímetre
2. Què és Microsoft Entra ID i en què es diferencia d'Active Directory
3. Inquilí, directori i subscripcions
4. Tipus d'identitat a Entra ID
5. Usuaris i grups de Contoso amb Azure CLI
6. Grups dinàmics per atribut
7. Autenticació: contrasenyes, MFA i sense contrasenya
8. Accés condicional: el motor de decisions
9. Privileged Identity Management i rols a demanda
10. Rols d'Entra ID davant de rols d'Azure: desfent la confusió
11. Entra External ID per als passatgers
12. Revisions d'accés i identitat híbrida
13. Errors Comuns i Consells
14. Exercicis
15. Conclusió

El model de confiança zero es resumeix en tres principis que convé tenir presents durant tot el mòdul:

• Verificar explícitament: autenticar i autoritzar amb tots els senyals disponibles (usuari, dispositiu, ubicació, risc), no només amb una contrasenya correcta.
• Mínim privilegi: donar el permís més petit que permet treballar, i durant el menor temps possible.
• Assumir la bretxa: dissenyar com si l'atacant ja fos a dins, segmentant i registrant-ho tot.

Traduït a Contoso: que en Diego Salas conegui la contrasenya de la base de dades no hauria de ser prou per llegir les reserves, i que un atacant robi les credencials del portal no li hauria de donar accés a la subscripció de producció. Els tres principis es materialitzaran en eines concretes: avui l'autenticació, a 04-02 l'autorització i les identitats sense contrasenya, a 04-06 les regles que ningú no es pot saltar.

Microsoft Entra ID (el servei que durant anys es va dir Azure AD; ja no facis servir aquest nom) és el servei d'identitat i accés del núvol de Microsoft. És el que autentica les persones que obren el portal d'Azure, les que fan servir Microsoft 365 i les aplicacions que criden APIs protegides.

L'error conceptual més estès és pensar que Entra ID és «Active Directory allotjat al núvol». No ho és: són productes diferents, amb protocols diferents i models diferents.

Conseqüència pràctica per a Contoso: l'AD local de l'oficina de Barcelona continua sent necessari per a les impressores, els recursos compartits i els equips units al domini; Entra ID no el substitueix. El que fa és coexistir amb ell i convertir-se en l'autoritat d'identitat per a tot el que viu a Azure i a internet. Com se sincronitzen és l'apartat 12.

Tres conceptes que es confonen cada dia:

• Inquilí (tenant): una instància dedicada d'Entra ID que pertany a una organització. Contoso en té un: contosoairlines.example, amb el seu identificador (GUID). És la frontera de la identitat.
• Directori: el contingut de l'inquilí —usuaris, grups, aplicacions, dispositius—. A la pràctica s'utilitzen com a sinònims.
• Subscripció: un contenidor de facturació i de recursos d'Azure. Contoso Airlines - Producció i Contoso Airlines - Desenvolupament són dues subscripcions diferents.

La relació clau: una subscripció confia en exactament un inquilí, i aquest inquilí autentica qui intenta entrar. Un inquilí, en canvi, pot tenir moltes subscripcions. Les dues subscripcions de Contoso confien en el mateix inquilí, i per això la Marta Ríos té una sola identitat per a totes dues, encara que els seus permisos en cadascuna siguin diferents.

Si mous una subscripció a un altre inquilí (operació real i ocasional en fusions), totes les assignacions de rol es perden, perquè apuntaven a identitats de l'inquilí anterior. Els recursos hi continuen sent; l'accés, no.

Tot el que es pot autenticar s'anomena entitat de seguretat (security principal). Hi ha quatre famílies:

Dos matisos que estalvien errors:

• Registre d'aplicació davant d'entitat de servei: el registre és la definició global de l'aplicació (el seu identificador, els seus permisos, els seus URI de redirecció); l'entitat de servei és la instància d'aquesta aplicació dins d'un inquilí concret, i és a ella a qui s'assignen rols. Una app registrada a Contoso i utilitzada per una altra empresa té un registre i dues entitats de servei.
• Grups de seguretat davant de grups de Microsoft 365: només els primers serveixen per assignar permisos d'Azure. I si un grup ha de rebre rols de directori, cal crear-lo amb isAssignableToRole activat; aquesta propietat no es pot canviar després i fa que només els administradors privilegiats puguin modificar-ne la pertinença.

Les identitats administrades són la peça que elimina les contrasenyes de les aplicacions, i mereixen la seva pròpia lliçó: es desenvolupen per complet a 04-02. Aquí n'hi ha prou de saber que existeixen i que són entitats de servei amb el cicle de vida gestionat per Azure.

Contoso organitza l'accés en quatre grups de seguretat. Contoso-DBA-Reservas ja existeix des de la lliçó 03-02, on es va designar com a administrador de Microsoft Entra ID de sql-contoso-reservas-pro.

--force-change-password-next-sign-in true és obligatori en qualsevol alta: la contrasenya que escrius tu no ha de sobreviure al primer inici de sessió. Fixa't també que --department no és decoratiu: es farà servir a l'apartat 6 per a la pertinença dinàmica.

La regla d'or, que es repetirà a 04-02: els permisos s'assignen a grups, mai a persones. Quan en Diego Salas canviï d'equip, el seu accés canvia amb un group member remove, no revisant cinquanta assignacions de rol repartides per dues subscripcions.

Un grup dinàmic calcula la seva pertinença a partir d'una regla sobre els atributs de l'usuari. Ningú no hi afegeix ni en treu ningú: quan Recursos Humans canvia el departament a l'alta, la pertinença es recalcula sola (en minuts, no instantàniament).

Compte amb dues coses: els grups dinàmics requereixen llicència Entra ID P1 i una regla mal escrita pot buidar el grup (i amb ell els permisos de mig equip) sense avisar. Contoso els fa servir per a pertinences àmplies i descriptives —«tot el departament de desenvolupament»—, i manté assignació manual en els grups amb privilegi real, com ara Contoso-Infraestructura.

La recomanació real, sense adorns: MFA per al 100 % dels usuaris i mètodes sense contrasenya resistents a phishing per a tothom qui tingui privilegis. L'SMS no és MFA de debò davant d'un atacant decidit, però és infinitament millor que res. Contoso aplica claus FIDO2 als quatre membres de Contoso-Infraestructura i Authenticator sense contrasenya a la resta.

Complements que convé conèixer: restabliment de contrasenya d'autoservei (SSPR), que treu al servei de suport el 30 % dels seus tiquets; protecció de contrasenyes amb llista de termes prohibits (contoso, airlines, reservas); i Protecció d'identitat (llicència P2), que puntua el risc de cada inici de sessió —viatge impossible, IP anònima, credencials filtrades— i alimenta les polítiques de l'apartat següent.

L'accés condicional és un motor de regles que s'avalua després de l'autenticació correcta i abans de concedir el testimoni d'accés. La seva estructura és sempre la mateixa: si es donen aquests senyals, aleshores exigeixo aquests controls.

Els controls de concessió habituals són: exigir MFA, exigir dispositiu conforme o unit a Entra híbrid, exigir aplicació client aprovada, exigir termes d'ús, o bloquejar directament. A més hi ha controls de sessió: freqüència d'inici de sessió i sessió de navegador no persistent.

Dues polítiques concretes de Contoso:

Política 1 — MFA obligatori per a administradors. S'aplica als rols de directori privilegiats (Administrador global, Administrador de seguretat, Administrador d'aplicacions) i a Contoso-Admins-Entra, sobre totes les aplicacions al núvol, exigint MFA i una freqüència d'inici de sessió de 8 hores.

Política 2 — Bloqueig geogràfic. Contoso Airlines opera a Espanya, Portugal, França i Itàlia, i el seu personal viatja a aquestes destinacions. Es crea una ubicació amb nom amb aquests països i es bloqueja l'accés des de qualsevol altre, aplicant-ho només als empleats (no als convidats, que es tracten a part). No és una mesura infal·lible —una VPN l'esquiva— però elimina de cop el soroll de fons d'intents automatitzats des d'altres continents.

La regla que mai no t'has de saltar: crea sempre un compte d'accés d'emergència (break-glass) i exclòs de totes les polítiques d'accés condicional. Dos comptes, de fet: sense MFA basada en telèfon, amb contrasenya llarguíssima guardada en sobre lacrat o caixa forta, amb rol d'Administrador global permanent, i amb una alerta que avisi tot l'equip si s'utilitza. El motiu és senzill: una política mal escrita, un proveïdor d'MFA caigut o una fallada de federació et poden deixar fora del teu propi inquilí sense cap manera d'entrar a arreglar-ho. Ha passat en organitzacions grans i no té solució ràpida.

Tota política nova es desplega primer en mode només informe, que l'avalua i en registra el resultat sense aplicar-la. Es revisen els inicis de sessió afectats durant una o dues setmanes, es corregeixen les exclusions necessàries i només aleshores s'activa. És el mateix patró «detectar abans que bloquejar» que veuràs a 04-04 amb el WAF i a 04-06 amb Azure Policy.

Que la Marta Ríos sigui Propietària de la subscripció de producció de manera permanent significa que, si li roben la sessió un dimarts qualsevol a les tres de la tarda, l'atacant també ho és. Privileged Identity Management (PIM), inclòs a Entra ID P2, canvia el model: els rols passen d'assignats a aptes (eligible), i qui els necessita els activa durant un temps limitat.

PIM funciona tant amb rols d'Entra ID com amb rols d'Azure (RBAC), i es complementa amb alertes (massa administradors globals, rols activats fora d'horari) i amb les revisions d'accés de l'apartat 12. Contoso l'aplica a Propietari, Administrador d'accés d'usuari i Administrador global: ningú no els té en repòs.

Aquesta és la confusió clàssica, i convé trencar-la ara mateix amb una frase: són dos sistemes de permisos completament separats que no s'hereten entre si.

L'exemple que ho aclareix: un Administrador global d'Entra ID no pot, per defecte, llegir un blob de sttarjetascontosopro. Mana sobre el directori, no sobre els recursos. (Es pot concedir aquest accés activant l'opció d'elevació d'accés, i això queda registrat —precisament perquè és excepcional.) I a l'inrevés: el Propietari de la subscripció de producció no pot crear usuaris ni canviar polítiques d'MFA. Els rols d'Azure i tot el seu model d'autorització són el tema complet de la lliçó 04-02.

Els milers de passatgers que es registren a Contoso Reserves no han de ser usuaris de l'inquilí corporatiu. Barrejar clients i empleats en el mateix directori és un error de disseny amb conseqüències immediates: les polítiques d'accés condicional pensades per a la plantilla s'aplicarien als clients, les llicències es dispararien i el llistat d'usuaris seria impossible de gestionar.

La solució és Microsoft Entra External ID en la seva configuració per a clients (CIAM), un inquilí separat dedicat a identitats externes:

Els usuaris B2B (convidats) són la tercera categoria, i no s'ha de confondre amb les anteriors: l'auditora externa de PCI DSS que apareixerà a 04-05 s'invita a l'inquilí corporatiu com a convidada, amb la seva pròpia identitat a la seva empresa, sense que Contoso gestioni la seva contrasenya.

Els permisos s'acumulen: algú entra en un projecte, rep accés, el projecte s'acaba i l'accés es queda. Les revisions d'accés (P2) automatitzen la neteja: cada trimestre, el responsable de Contoso-Infraestructura rep la llista de membres i ha d'aprovar o retirar cadascun, amb l'opció de retirar automàticament qui no rebi resposta. Contoso les programa sobre els quatre grups, sobre els convidats B2B i sobre els rols privilegiats de PIM.

I queda l'AD local de Barcelona. Microsoft Entra Connect (i el seu successor, Entra Cloud Sync) sincronitza usuaris i grups de l'AD local cap a Entra ID, de manera que cada empleat té una sola identitat. Hi ha tres models d'autenticació —sincronització de hash de contrasenya (el recomanat per senzillesa i resiliència), autenticació de pas a través i federació amb ADFS— i una regla d'or: la sincronització és unidireccional cap al núvol per als objectes d'usuari, així que l'AD local continua sent la font de la veritat i els canvis es fan allà. És una introducció deliberada: muntar Entra Connect és un projecte en si mateix i aquí només necessites saber on encaixa.

• No tenir compte d'accés d'emergència. És l'error que et pot deixar permanentment fora del teu inquilí. Crea'l avui, documenta on és la credencial i prova'l cada sis mesos.
• Activar una política d'accés condicional directament en producció. Fes servir sempre el mode només informe primer. Una política que exigeixi dispositiu conforme sense haver inscrit els dispositius bloqueja tota la plantilla en cinc minuts.
• Assignar permisos a persones i no a grups. Funciona el primer dia i és ingovernable el mes dotze.
• Confondre rols d'Entra ID amb rols d'Azure. Si algú «és administrador» i no pot llegir un blob, no és un error: són sistemes diferents (apartat 10).
• Registrar els clients a l'inquilí corporatiu. Fes servir Entra External ID; separar és molt més barat que migrar després.
• Tenir deu administradors globals permanents. L'objectiu és entre dos i quatre, i amb PIM cap en repòs.
• Crear un grup normal i descobrir després que el necessitaves assignable a rols. isAssignableToRole no es pot canviar: cal recrear el grup.
• Consell: activa el bloqueig intel·ligent i la protecció de contrasenyes abans que res; són gratuïts i aturen els atacs per força bruta més barroers.
• Consell: els registres d'inici de sessió d'Entra ID només es conserven 7 o 30 dies segons la llicència. Envia'ls a Log Analytics (07-02) des del primer dia; el dia que investiguis un incident, agrairàs tenir sis mesos d'historial.

El projecte «Contoso Millas» (centro-coste=CC-2077) arrenca amb: cinc desenvolupadors interns, dos consultors d'una empresa externa que hi treballaran sis mesos, un servei de l'aplicació que ha de llegir un blob, i uns 80.000 clients que consultaran les seves milles en un web públic.

1. Indica quin tipus d'identitat correspon a cadascun dels quatre col·lectius.
2. Quins grups crearies i quins serien dinàmics?
3. Quina mesura programaries per als consultors externs, sabent que el projecte dura sis mesos?

Contoso vol exigir MFA a tot el personal d'administració i bloquejar l'accés des de fora d'Espanya, Portugal, França i Itàlia.

1. Enumera els senyals i els controls de cadascuna de les dues polítiques.
2. Quines identitats exclouries obligatòriament i per què?
3. Descriu el procés de posada en marxa per no bloquejar ningú per error.

Explica la causa i la solució de cada situació:

1. La Marta Ríos és Administradora global i no pot descarregar una targeta d'embarcament de sttarjetascontosopro; el portal li diu que no té autorització.
2. Un desenvolupador que va deixar l'empresa fa quatre mesos continua apareixent amb accés a rg-contoso-reservas-dev.
3. Després d'activar la política de bloqueig geogràfic, la canalització de desplegament nocturna comença a fallar amb un error d'autenticació.

Solució 1:

1. Els cinc desenvolupadors, usuaris membre de l'inquilí corporatiu. Els dos consultors, usuaris convidats (B2B): mantenen la seva identitat a la seva empresa i Contoso no gestiona ni les seves contrasenyes ni les seves altes i baixes. El servei que llegeix el blob, una identitat administrada (04-02), mai un usuari amb contrasenya. Els 80.000 clients, un inquilí d'Entra External ID separat del corporatiu.
2. Contoso-Millas-Desarrollo amb els cinc interns i Contoso-Millas-Externos amb els dos consultors, separats perquè tindran permisos diferents i perquè el segon es revisa a part. El primer pot ser dinàmic per department i extensionAttribute de projecte; el d'externs, manual, perquè el privilegi i la temporalitat exigeixen control explícit.
3. Una revisió d'accés trimestral sobre el grup d'externs amb retirada automàtica si el revisor no respon, i addicionalment una data de caducitat a la invitació B2B. L'important és que la baixa no depengui que algú se'n recordi.

Solució 2:

1. Política d'MFA: senyals = pertinença a rols de directori privilegiats i a Contoso-Admins-Entra, sobre totes les aplicacions al núvol; controls = exigir MFA i freqüència d'inici de sessió de 8 hores. Política geogràfica: senyals = tots els usuaris membre, qualsevol aplicació, ubicació diferent de la ubicació amb nom «Països d'operació»; control = bloquejar.
2. Els comptes d'accés d'emergència, sempre i en totes dues polítiques. A més, les entitats de servei de les canalitzacions automatitzades, que no poden fer MFA i la IP d'origen de les quals és un agent allotjat per Microsoft en una regió qualsevol; per a elles es fan servir polítiques d'identitats de càrrega de treball amb IP de confiança, no les d'usuari.
3. Crear-les totes dues en mode només informe, esperar d'una a dues setmanes i analitzar als registres d'inici de sessió qui hauria estat bloquejat. Corregir exclusions, avisar la plantilla del canvi, activar primer la d'MFA (menys disruptiva) i una setmana després la geogràfica. I comprovar abans que el compte d'emergència funciona.

Solució 3:

1. No és una fallada: els rols d'Entra ID no atorguen accés a les dades dels recursos. Administrador global mana sobre el directori. Necessita el rol d'Azure Lector de dades de Blob Storage sobre el compte o el contenidor (04-02), o fer servir l'elevació d'accés, que queda registrada i és excepcional.
2. Falta govern del cicle de vida: la baixa de RRHH no es va propagar a Azure. Solució immediata, retirar l'assignació i deshabilitar el compte; solució estructural, sincronitzar altes i baixes des del sistema de RRHH, fer servir grups en lloc d'assignacions individuals i programar revisions d'accés periòdiques.
3. La canalització s'autentica amb una entitat de servei que la política, aplicada a «tots els usuaris», també avalua; el seu trànsit surt d'un agent allotjat fora dels països permesos. Solució: excloure explícitament aquesta entitat de servei o passar a agents autoallotjats amb IP fixa declarada com a ubicació de confiança. És el motiu de fons del mode només informe.

La identitat és el perímetre, i ja saps per què: a Azure no hi ha una xarxa de confiança dins la qual tot valgui, així que cada accés es decideix per qui el demana. Has vist que Microsoft Entra ID no és Active Directory al núvol sinó un servei diferent, pla, basat en OAuth 2.0, OpenID Connect i Microsoft Graph, que coexisteix amb l'AD local de Barcelona en lloc de substituir-lo. Distingeixes inquilí, directori i subscripció, i saps que una subscripció confia en un sol inquilí. Coneixes les entitats de seguretat —usuaris membre i convidats B2B, grups de seguretat i grups assignables a rols, registres d'aplicació i entitats de servei— i has creat els grups Contoso-Infraestructura, Contoso-Desarrollo, Contoso-Operaciones i Contoso-Admins-Entra al costat del ja existent Contoso-DBA-Reservas, amb la regla que governa tot el que ve: els permisos s'assignen a grups, no a persones.

En autenticació tens la recomanació real —MFA per a tothom i mètodes sense contrasenya resistents a phishing per a qui tingui privilegis—, l'accés condicional amb els seus senyals i controls, les dues polítiques de Contoso i l'advertiment que no admet excepcions: compte d'accés d'emergència exclòs de tot, i desplegament en mode només informe abans d'aplicar. Amb Privileged Identity Management entens per què ningú no ha de ser Propietari permanent i què significa activar un rol a demanda. I has desfet la confusió clàssica: els rols d'Entra ID manen sobre identitats i els rols d'Azure sobre recursos, sense herència entre ells. Tanquen la lliçó Entra External ID per als passatgers, les revisions d'accés que eviten l'acumulació silenciosa de permisos i Entra Connect com a pont amb l'AD local.

Ara existeixen identitats ben governades, però encara no diuen res sobre què pot tocar cadascuna: Contoso-Desarrollo continua sense permisos, i app-contoso-reservas-pro continua connectant-se a db-reservas i a sttarjetascontosopro amb secrets a la seva configuració. A la lliçó següent, RBAC i identitats administrades, muntaràs el sistema d'autorització d'Azure —la tríada entitat, rol i àmbit—, descobriràs per què el rol Col·laborador no deixa llegir un blob, crearàs el rol personalitzat «Operador de Reservas de Contoso» i donaràs a l'aplicació una identitat administrada amb què autenticar-se sense ni una sola contrasenya.