Governance come abilitatore, non come freno
Il ruolo del Solution Architect su Power Platform non è “chiudere” la piattaforma, ma progettare un sistema di controlli proporzionati al rischio che consenta ai maker citizen di produrre valore restando dentro guardrail chiari. Il framework di riferimento è l’Azure Well-Architected Framework, in particolare i pilastri Operational Excellence (osservabilità, automazione, gestione del ciclo di vita) e Security (isolamento dei dati, minimo privilegio). La domanda-guida per ogni decisione è: dato questo requisito di rischio e questa maturità organizzativa, qual è il livello minimo di controllo che lo soddisfa senza bloccare la produttività?
Inventario e osservabilità: il CoE Starter Kit
Il Center of Excellence (CoE) Starter Kit è la baseline raccomandata per ottenere visibilità prima di introdurre restrizioni. Fornisce:
- Inventario automatico di app, flow, connection, custom connector e maker tramite i flow di sincronizzazione (Cloud Flows che interrogano le admin API / connettori Power Platform for Admins e Dataverse).
- Monitoring & adoption: dashboard Power BI su utilizzo, orphaned resources, app inattive, top maker.
- Governance components: Compliance Center, richieste di approvazione per app “business critical”, archiviazione automatica di risorse inutilizzate.
Trade-off di deployment: il CoE Kit gira su Dataverse nell’environment “CoE” dedicato e richiede un service account (idealmente un’identità applicativa / service principal, non un utente nominale) con licenza per-app o premium. La scelta di service principal vs utente premium impatta continuità operativa (un utente che lascia l’azienda spezza i flow) e costo: per Operational Excellence si privilegia l’identità applicativa e le connection reference gestite.
Managed Environments: governance premium
Per organizzazioni mature, i Managed Environments aggiungono controlli nativi che il CoE Kit da solo non offre: weekly digest, sharing limits (limitare a quanti utenti/gruppi un maker può condividere un’app), data policies granulari, maker welcome content e solution checker obbligatorio in fase di import. Il trade-off è di licenza (richiedono piani premium per gli utenti dell’environment) contro riduzione del carico amministrativo. Raccomandazione tipica da architetto: Managed Environments sui perimetri produzione e su quelli che toccano dati sensibili; environment personali/di dev lasciati più aperti per non soffocare la sperimentazione.
DLP: separare business e non-business
Le Data Loss Prevention (DLP) policies classificano i connettori in tre gruppi: Business, Non-Business e Blocked. La regola cardine: connettori di gruppi diversi non possono coesistere nella stessa app o flow. Questo impedisce, ad esempio, che un flow legga da Dataverse (business) e pubblichi su Twitter/X o un webhook arbitrario (non-business) nello stesso data flow, evitando esfiltrazione.
Design delle policy
- Gerarchia: policy a livello tenant (default) + eccezioni per environment specifici. Una policy tenant-wide restrittiva con override mirati è più manutenibile di decine di policy per-environment.
- Endpoint filtering & connector action control: oltre a classificare il connettore, si possono bloccare singole azioni (es. consentire GET ma non POST su HTTP) o filtrare per URL/host. Utile quando bloccare l’intero connettore HTTP sarebbe troppo grezzo.
- Custom connector patterns: classificare i custom connector per URL pattern per evitare che diventino un bypass.
Il trade-off è granularità vs manutenibilità: policy troppo fini generano attrito operativo e falsi positivi; troppo grezze lasciano superficie di rischio.
Allineamento all’Operational Excellence
Il vero anti-pattern è introdurre DLP a valle, quando app e flow sono già in produzione. Una nuova policy si applica retroattivamente: un flow che diventa non conforme viene sospeso e le app mostrano errori ai loro utenti. La pratica corretta è: impact analysis prima (il CoE Kit offre il DLP Editor e report di impatto), comunicazione ai maker, finestra di grazia e rollout progressivo per environment (dev → test → prod).
Trappole tipiche d’esame
- Requisito: impedire che i dati Dataverse finiscano su servizi social/consumer, senza bloccare la produttività → classifica Dataverse e i connettori aziendali come Business, i connettori consumer come Non-Business; NON bloccare tutto. La separazione dei gruppi impedisce già la coesistenza nello stesso flow.
- Requisito: serve inventario e adoption tracking prima di decidere le restrizioni → distribuisci il CoE Starter Kit per ottenere visibilità; le DLP arrivano dopo, guidate dai dati, non a priori.
- Trappola: una DLP restrittiva viene applicata e flow di produzione si fermano → esegui impact analysis con il DLP Editor del CoE Kit, applica la policy per environment con rollout graduale e finestra di grazia; mai policy tenant-wide “big bang” su ambienti live.
- Requisito: limitare quanto i maker condividono le app e forzare il solution checker → attiva i Managed Environments sull’environment di produzione, non affidarti solo a controlli manuali o al CoE Kit.
- Requisito: il service account del CoE si rompe quando un dipendente lascia → usa un’identità applicativa (service principal) con connection reference, non un utente nominale, per continuità operativa.