Progettare identità e compliance in una soluzione Power Platform non è un livello di “hardening” applicato alla fine: sono vincoli architetturali che determinano scelte irreversibili come la region dell’environment e il modello di business unit. Un Solution Architect li mette sul tavolo durante la fase di envisioning, non in collaudo.

Autenticazione con Microsoft Entra ID

Power Platform delega sempre l’autenticazione a Microsoft Entra ID: non esiste un identity store separato per Dataverse. La leva di design principale è Conditional Access, che agisce sui cloud app Dataverse, Power Apps e Power Automate.

Scenario: l’utente chiede accesso ai dati aziendali solo da dispositivi gestiti e con MFA. Raccomandazione: policy di Conditional Access che richiede device compliant (Intune) + MFA, non controlli custom nell’app. La sicurezza va spinta al livello della piattaforma identità, non replicata nella logica applicativa (pilastro Security del Well-Architected Framework).

Per gli utenti esterni si distinguono due pattern che l’esame confonde spesso:

  • Collaboratori B2B / guest: partner che usano app model-driven o canvas interne. Si invitano come guest Entra ID, ricevono una licenza e una security role Dataverse. Restano identità governate dal tenant, tracciabili in audit.
  • Clienti / cittadini su Power Pages: identità esterne gestite tramite Entra External ID (ex Azure AD B2C). Non consumano licenze interne e non vanno mai modellati come guest B2B.

Autorizzazione: il modello Dataverse

Conditional Access dice se si entra; la security role Dataverse dice cosa si può fare. Il modello combina security role, business unit, team (Owner, Access e soprattutto Entra group team, che eredita l’appartenenza dai gruppi Entra ID), field-level security e hierarchy security.

Trade-off tipico: replicare la struttura organizzativa con molte business unit annidate offre isolamento forte ma rende complesse le condivisioni cross-BU. La Modern business unit con matrix data access consente di assegnare un ruolo in una BU diversa da quella dell’utente, riducendo la proliferazione di unità. Da preferire quando la collaborazione trasversale è la norma.

GDPR, Purview e data residency come design

Microsoft Purview è lo strato di governance trasversale. In fase di design serve per:

  • Classificazione dei dati: sensitivity label e data map per identificare dove risiedono i dati personali dentro Dataverse. La classificazione precede la scelta dei controlli, non la segue.
  • Audit: l’audit nativo di Dataverse alimenta Purview Audit, fornendo la tracciabilità richiesta dall’accountability GDPR (art. 5.2). Attivarlo dopo il go-live significa perdere lo storico.
  • Data Loss Prevention: le DLP policy di Power Platform classificano i connector (Business / Non-Business / Blocked) impedendo che un flow esfiltri dati personali verso destinazioni non approvate.

La data residency è il vincolo più insidioso: la region dell’environment è immutabile. Se il requisito impone dati nell’UE, la region va decisa alla creazione dell’environment. Una migrazione posticcia richiede di ricreare l’environment e migrare i dati — costo enorme evitabile con una decisione di 30 secondi all’inizio.

Data subject rights

I diritti dell’interessato (accesso, rettifica, cancellazione, portabilità) sono requisiti funzionali da inserire nel design. La cancellazione (right to erasure) implica valutare cascade behavior delle relazioni, record collegati in tabelle di audit e backup. Va progettato un processo — non improvvisato su richiesta legale.

Trappole tipiche d’esame

  • Requisito: utenti esterni su un portale rivolto ai clienti → soluzione: Power Pages con Entra External ID, non inviti guest B2B (i guest sono per collaboratori interni al perimetro aziendale, non per il pubblico).
  • Requisito: “i dati devono restare in Europa” emerso a metà progetto → soluzione: la region dell’environment è immutabile; va fissata alla creazione. Trattare la data residency come attività di chiusura costringe a ricreare e rimigrare l’environment.
  • Requisito: accesso solo da dispositivi conformi con MFA → soluzione: Conditional Access sui cloud app Power Platform/Dataverse, non logica di sicurezza custom nell’app né security role Dataverse (che governano i permessi sui dati, non le condizioni di accesso).
  • Requisito: impedire che un flow copi dati personali su servizi consumer → soluzione: DLP policy che classifica i connector, non controlli manuali nel flow.
  • Requisito: dimostrare chi ha visto/modificato dati personali per audit GDPR → soluzione: audit Dataverse + Purview Audit attivati dall’inizio; attivarli dopo un incidente non ricostruisce lo storico pregresso.

Il messaggio da portare all’esame: identità, compliance, GDPR e data residency sono input di architettura. Un Solution Architect che li tratta come checklist finale consegna una soluzione tecnicamente corretta ma non conforme e costosa da rimediare.