Utilizzare Microsoft SQL Server in modo sicuro con Power Apps
Ci sono diversi modi per connettere e autenticarsi su SQL Server con Power Apps. Questo articolo illustra i concetti che possono essere utili per scegliere come connettersi a SQL Server con un approccio alla sicurezza che soddisfi i requisiti per l'app.
Importante
La funzionalità Connessioni implicite sicure è stata rilasciata nel gennaio 2024. Microsoft consiglia vivamente a tutte le app che attualmente utilizzano connessioni implicite di convertirsi a connessioni implicite protette e di revocare le connessioni condivise con gli utenti finali.
Differenza tra connessioni esplicite, implicite e implicite protette
Viene creata una connessione a SQL Server ogni volta che si crea un'app utilizzando Power Apps per connettersi a SQL Server. Quando tali app vengono pubblicate e condivise con altri, sia l'app che la connessione vengono distribuite a tali utenti. In altre parole, l'app e la connessione sono entrambi visibili agli utenti con cui le app sono condivise.
Il metodo di autenticazione utilizzato per tali connessioni può essere esplicito o implicito. Possiamo anche dire che tale connessione è condivisa esplicitamente o implicitamente.
- Una connessione esplicitamente condivisa significa che l'utente finale dell'applicazione deve autenticarsi in SQL Server con le proprie credenziali esplicite. Di solito questa autenticazione avviene dietro le quinte come parte dell'handshake di autenticazione di Windows o di Microsoft Entra. L'utente non si accorge nemmeno quando avviene l'autenticazione.
- Una connessione implicitamente condivisa significa che l'utente utilizza implicitamente le credenziali dell'account che il creatore dell'app ha utilizzato per connettersi e autenticarsi a origine dati durante la creazione dell'app. Le credenziali dell'utente finale non vengono utilizzate per l'autenticazione. Ogni volta che l'utente finale esegue l'app, utilizza le credenziali con cui l'autore ha creato l'app.
- Una connessione condivisa implicitamente protetta si riferisce a uno scenario in cui l'utente finale dell'app utilizza implicitamente le credenziali dell'account che il creatore dell'app ha utilizzato per connettersi e autenticarsi a origine dati durante la creazione dell'app. Ciò indica che le credenziali dell'utente finale non vengono utilizzate per l'autenticazione. Ogni volta che l'utente finale esegue l'app, utilizza le credenziali con cui l'autore ha creato l'app. È importante notare che all'utente finale non viene fornito l'accesso diretto alla connessione e l'app consente l'accesso solo a un insieme limitato di azioni e tabelle.
I seguenti quattro tipi di autenticazione della connessione possono essere utilizzati con SQL Server per Power Apps:
| Tipo di autenticazione | Metodo di connessione Power Apps |
|---|---|
| Microsoft Entra integrato | Esplicito |
| Autenticazione di SQL Server | Implicito/implicito protetto |
| Autenticazione di Windows | Implicito/implicito protetto |
| Autenticazione di Windows (non condivisa) | Esplicito |
Rischi della condivisione della connessione implicita
Tutte le nuove applicazioni utilizzano automaticamente le nuove connessioni implicite protette. Tuttavia, con le app che usano le precedenti "connessioni implicite", sia l'app che le sue connessioni vengono distribuite agli utenti finali, significa che gli utenti finali possono creare nuove applicazioni basate su tali connessioni.
Se un autore utilizza connessioni implicite protette, significa che nessuna connessione è condivisa e nessun utente finale riceve l'oggetto di connessione. Ciò elimina il rischio che un autore utente finale riutilizzi una connessione per creare una nuova app. L'app funziona invece con una connessione proxy che riconosce l'app e comunica solo con quell'app specifica. La connessione proxy consente azioni limitate (creazione, lettura, aggiornamento, eliminazione) e l'accesso a tabelle specifiche nell'app definite al momento della pubblicazione dell'app. Pertanto, all'utente finale vengono concessi solo le azioni e l'accesso autorizzati.
La connessione implicita semplice precedente distribuisce effettivamente un oggetto di connessione all'utente finale. Ad esempio quando crei un'app che filtra i dati che non vuoi che gli utenti vedano. I dati filtrati sono presenti nel database. Ma tu fai affidamento sul filtro che hai configurato per assicurarti che gli utenti finali non vedano determinati dati.
Con le connessioni implicite precedenti, dopo aver distribuito questa app, gli utenti finali possono usare la connessione distribuita con la tua app in tutte le nuove app che creano. Nelle nuove app, gli utenti possono vedere i dati che hai filtrato nella tua applicazione. È importante utilizzare le nuove connessioni implicite protette.
Importante
Una volta che una connessione precedente condivisa implicitamente viene distribuita agli utenti finali, le restrizioni che potresti aver inserito nell'app che hai condiviso (come i filtri o l'accesso in sola lettura) non sono più valide per le nuove app create dagli utenti finali. Gli utenti finali avranno tutti i diritti consentiti dall'autenticazione come parte della connessione implicitamente condivisa. Pertanto, quando converti un'app per utilizzare connessioni implicite sicure, devi anche revocare le connessioni condivise con la tua app. Gli amministratori possono ottenere un report delle app con connessioni implicitamente condivise con il toolkit COE.
Sicurezza di client e server
Non puoi fare affidamento sulla sicurezza dei dati tramite filtri o altre operazioni lato client per essere sicuro. Le applicazioni che richiedono un filtraggio sicuro dei dati devono garantire che sia l'identificazione dell'utente che il filtraggio avvengano sul server.
Utilizza servizi come Microsoft Entra ID invece di fare affidamento sui filtri progettati all'interno delle app quando si tratta di identità e sicurezza dell'utente. Questa configurazione garantisce che i filtri sul lato server funzionino come previsto.
Le illustrazioni seguenti spiegano in che modo i modelli di sicurezza all'interno delle app differiscono tra i modelli di sicurezza lato client e lato server.
In un modello di app di sicurezza client, [1] l'utente si autentica solo per l'applicazione sul lato client. Poi [2] l'applicazione richiede informazioni sul servizio, e [3] il servizio restituisce le informazioni esclusivamente in base alla richiesta dei dati.
In un modello di sicurezza lato server, [1] l'utente prima si autentica al servizio in modo che l'utente sia noto al servizio. Poi, [2] quando viene effettuata una chiamata dall'applicazione, il servizio [3] utilizza l'identità nota dell'utente corrente per filtrare i dati in modo appropriato e [4] restituisce i dati.
Gli scenari di condivisione dipartimentali impliciti descritti sopra sono una combinazione di questi due modelli. L'utente deve accedere al servizio Power Apps utilizzando credenziali di Microsoft Entra. Questo comportamento è il modello dell'app di sicurezza del server. L'utente è conosciuto utilizzando l'identità Microsoft Entra sul servizio. Quindi, l'app è limitata all'insieme di utenti con cui Power Apps ha formalmente condiviso l'applicazione.
Tuttavia, la connessione condivisa implicita a SQL Server è il modello dell'app di sicurezza client. SQL Server sa solo che vengono utilizzati un nome utente e una password specifici. Qualsiasi filtro lato client, ad esempio, può essere ignorato con una nuova applicazione utilizzando lo stesso nome utente e password.
Per filtrare in modo sicuro i dati sul lato server, utilizzare le funzionalità di sicurezza integrate in SQL Server come sicurezza a livello di riga per le righe, e le autorizzazioni deny per oggetti specifici (come colonne) per utenti specifici. Questo approccio utilizza l'identità utente Microsoft Entra per filtrare i dati sul server.
Alcuni servizi aziendali esistenti hanno utilizzato un approccio in cui l'identità dell'utente viene catturata in un livello di dati aziendali più o meno nello stesso modo in cui lo fa Microsoft Dataverse. In questo caso, il livello aziendale può utilizzare o meno la protezione a livello di riga di SQL Server e negare direttamente le funzionalità. In caso contrario, spesso la sicurezza viene abilitata utilizzando stored procedure o viste.
Il livello aziendale (lato server) utilizza l'identità di un utente noto Microsoft Entra per richiamare una stored procedure come entità di SQL Server e filtrare i dati. Tuttavia, Power Apps attualmente non si connette alle stored procedure. Un livello aziendale può anche richiamare una vista che utilizza l'identità Microsoft Entra come entità di SQL Server. In questo caso, utilizza Power Apps per connetterti alle viste in modo che i dati vengano filtrati sul lato server. Per esporre le viste solo agli utenti potrebbero essere necessari flussi Power Automate per gli aggiornamenti.