Proteggere il tuo portale Power Pages: un approfondimento su autorizzazioni e ambiti delle tabelle

By Mirko Peters · 2026-08-11

Bentornato sul blog del podcast! Quando crei applicazioni web rivolte ai clienti sulla piattaforma Microsoft Power Platform, la sicurezza non può essere un ripensamento. Power Pages è uno strumento straordinario per distribuire rapidamente portali esterni robusti, collegati direttamente a Dataverse. Ma da un grande potere derivano grandi responsabilità, in particolare quella di garantire che i dat

Automatically translated with AI from the original post. Read the English original

Titelbild: Securing Your Power Pages Portal: A Deep Dive into Table Permissions and Scopes

In questo post approfondiremo i concetti architetturali di sicurezza di base di cui abbiamo parlato nel nostro recente episodio. Se non l'hai ancora ascoltato, non perdere l'episodio Build Customer Portals with Power Pages and Dataverse, che illustra passo dopo passo come configurare l'ambiente, gestire le identità esterne e distribuire la prima soluzione di portale.

Vediamo nel dettaglio il funzionamento della sicurezza di Power Pages, partendo da come pianificare i confini dei dati e padroneggiare le autorizzazioni delle tabelle.

Introduzione alla sicurezza di Power Pages

Quando crei per la prima volta un sito Power Pages, la piattaforma ti mette a disposizione una superficie flessibile e altamente personalizzabile. Sotto questa superficie, però, c'è una pipeline diretta verso il tuo ambiente Microsoft Dataverse. Se le configurazioni di sicurezza non sono gestite correttamente, ogni singolo record del database potrebbe essere esposto tramite un endpoint non protetto o una visualizzazione elenco con ambito mal definito.

La sicurezza in Power Pages si basa su una strategia di difesa a più livelli. Al livello esterno ci sono i meccanismi di autenticazione, come Azure AD B2C, gli account locali o i provider di identità esterni, che garantiscono che gli utenti dimostrino la propria identità. Al livello interno ci sono i ruoli Web e le autorizzazioni delle tabelle Dataverse. Queste autorizzazioni stabiliscono con precisione cosa possono vedere, creare, aggiornare o eliminare le identità autenticate. Impostare tutto correttamente fa la differenza tra un portale aziendale sicuro e una violazione di dati massiccia che aspetta solo di accadere.

Pianificare i confini dei dati e le autorizzazioni delle tabelle

Prima di toccare un solo pulsante in Power Pages Studio, prendi una lavagna e mappa con cura i confini dei tuoi dati. Probabilmente sono i 15 minuti più critici dell'intero ciclo di vita del progetto del portale.

Inizia creando un inventario completo di ogni tabella Dataverse che intendi esporre agli utenti esterni. Per ciascuna tabella, definisci il numero minimo assoluto di azioni CRUD necessarie. Un cliente deve davvero poter eliminare una fattura, o dovrebbe avere solo accesso in lettura e aggiunta? Una volta definite le azioni, devi stabilire l'ambito delle righe per ogni tabella:

Ambito Contatto: l'utente può interagire solo con i record associati direttamente al proprio record Contatto.
Ambito Account: l'utente può interagire con i record associati a tutta la sua azienda o al suo Account.
Ambito Globale: l'utente può vedere tutti i record dell'intera tabella (di solito riservato agli articoli pubblici della Knowledge Base o ai metadati).

Definendo questi confini in anticipo, stabilisci una base di privilegio minimo prima ancora che venga costruita qualsiasi configurazione nell'ambiente di sviluppo.

Comprendere la differenza tra ambito Contatto e ambito Account

Uno dei punti di confusione più comuni per chi si avvicina a Power Pages è capire la differenza tra ambito Contatto e ambito Account. Scegliere l'ambito sbagliato può compromettere completamente l'esperienza utente, nascondendo dati aziendali rilevanti, oppure esporre inavvertitamente dati riservati a persone non autorizzate.

L'ambito Contatto è pensato per portali individuali in stile consumer. Se un utente accede e invia un ticket di supporto, un'autorizzazione con ambito Contatto garantisce che possa visualizzare solo i casi in cui è esplicitamente indicato come contatto principale o creatore. Se un altro utente della stessa identica azienda accede, non vedrà i ticket di supporto personali del collega.

D'altra parte, l'ambito Account è pensato per le architetture di portale B2B. In uno scenario B2B, vuoi che un Account Manager o un responsabile degli acquisti principale possa visualizzare tutti i casi, gli ordini e le fatture associati all'account aziendale di riferimento. Quando assegni un ambito Account a un'autorizzazione di tabella, il portale valuta l'account padre collegato al record Contatto dell'utente connesso e mostra poi tutti i record figli appartenenti a quella organizzazione. Mappare correttamente questa relazione in Dataverse è fondamentale per il successo di una soluzione B2B.

Definire i ruoli Web ed evitare la trappola del gruppo Authenticated Users

I ruoli Web sono il ponte tra gli utenti autenticati e le autorizzazioni di tabella di Dataverse. Per impostazione predefinita, Power Pages include un ruolo predefinito chiamato "Authenticated Users". È qui che molti amministratori cadono in una pericolosa trappola di sicurezza.

Per impostazione predefinita, qualsiasi utente che accede correttamente al portale viene automaticamente inserito nel ruolo Authenticated Users. Se assegni a questo ruolo predefinito autorizzazioni di tabella ampie, o peggio ancora autorizzazioni con ambito Global, ogni persona che si registra sul sito erediterà immediatamente questi privilegi eccessivi. Si tratta di un enorme anti-pattern di sicurezza.

Ti consigliamo invece di creare ruoli Web personalizzati e granulari, su misura per i profili utente specifici. Ad esempio:

CustomerUser: associato a un ambito Contatto per tabelle operative come Casi e Ordini, che consente agli utenti di monitorare le proprie interazioni.
AccountManager: associato a un ambito Account, che offre ai responsabili designati dell'organizzazione la visibilità sulle risorse dell'intera azienda.
KnowledgeBaseViewer: associato globalmente, ma limitato rigorosamente alle azioni di sola lettura sugli articoli di supporto pubblici.

Rimuovi sempre gli accessi predefiniti non necessari e assicurati che gli utenti siano assegnati esplicitamente a ruoli creati per uno scopo preciso, in base alla loro relazione con l'organizzazione.

Rafforzare la visibilità a livello di campo e proteggere i dati personali (PII)

Controllare l'accesso a livello di riga tramite gli ambiti delle tabelle è solo metà della battaglia. Devi anche prestare grande attenzione a quali dati sono visibili all'interno delle singole righe e degli elenchi. Esporre informazioni personali identificabili (PII) come numeri di telefono, indirizzi di casa, dati finanziari o note interne sui dipendenti può portare a gravi violazioni di conformità (come quelle al GDPR o al CCPA).

Quando crei elenchi e moduli di base in Power Pages, assicurati di ripulire le visualizzazioni da colonne sensibili. Il fatto che un campo sia nascosto nel layout del modulo lato client non significa che non possa essere ispezionato o recuperato tramite le API Web sottostanti se le autorizzazioni sono troppo ampie. Utilizza visualizzazioni separate e rafforzate (ad esempio una "PublicView" dedicata) che contengano esclusivamente colonne sicure e bonificate. Se alcune colonne devono restare nella tabella del database, valuta l'implementazione della sicurezza a livello di colonna in Dataverse per limitare completamente l'accesso a livello di motore del database.

Test di penetrazione delle autorizzazioni del portale

Non dare mai per scontato che il modello di sicurezza funzioni: devi dimostrarlo. Prima di promuovere qualsiasi soluzione di portale in un ambiente di test o di produzione, esegui test di penetrazione rigorosi sulle autorizzazioni di tabella e sulla logica di instradamento.

Configura account utente di test per ciascuno dei ruoli Web definiti. Accedi come CustomerUser standard e prova a visualizzare i dati appartenenti a un altro Contatto o Account. Prova la manipolazione diretta degli URL e la modifica dei GUID, sostituendo gli ID dei record nella barra degli indirizzi del browser, per verificare che il server blocchi correttamente le richieste non autorizzate. Inoltre, controlla i log diagnostici e di controllo del portale per verificare che i tentativi di escalation dei privilegi generino le risposte 403 Forbidden appropriate.

Conclusioni e best practice

Proteggere un portale Power Pages richiede una pianificazione attenta, il rigoroso rispetto del principio del privilegio minimo e una conoscenza approfondita delle autorizzazioni di tabella e degli ambiti di Dataverse. Abbandonando impostazioni predefinite pericolose come il ruolo Authenticated Users, limitando con cura l'accesso alle tabelle a livello di Contatto o Account e rafforzando la visibilità a livello di campo, puoi costruire un portale clienti sia altamente funzionale sia eccezionalmente sicuro.

Per approfondire ulteriormente questo argomento e vedere una guida all'implementazione completa, dalla A alla Z, che include la configurazione delle identità esterne, la progettazione dell'architettura della soluzione e la preparazione al go-live, ascolta il nostro podcast di approfondimento: Build Customer Portals with Power Pages and Dataverse. Grazie per la lettura e continua a seguirci per altri consigli da esperti su come padroneggiare Microsoft Power Platform!