Scenario di sicurezza end-to-end di Microsoft Fabric

La sicurezza è un aspetto fondamentale di qualsiasi soluzione di analisi dei dati, soprattutto quando comporta dati sensibili o riservati. Per questo motivo, Microsoft Fabric offre un set completo di funzionalità di sicurezza che consentono di proteggere i dati inattivi e in transito, nonché di controllare l'accesso e le autorizzazioni per gli utenti e le applicazioni.

In questo articolo verranno illustrati i concetti e le funzionalità di sicurezza di Fabric che consentono di creare in tutta sicurezza la propria soluzione analitica con Fabric.

Background

Questo articolo presenta uno scenario in cui siete un ingegnere dei dati che lavora per un'organizzazione sanitaria negli Stati Uniti. L'organizzazione raccoglie e analizza i dati dei pazienti originati da vari sistemi, inclusi i record sanitari elettronici, i risultati del lab, le attestazioni assicurative e i dispositivi indossabili.

Si prevede di costruire una lakehouse usando l'architettura medallion in Fabric, costituita da tre livelli: bronzo, argento e oro.

• Il livello bronzo archivia i dati non elaborati man mano che arrivano dalle origini dati.
• Il livello silver applica controlli e trasformazioni di qualità dei dati per preparare i dati per l'analisi.
• Il livello oro fornisce dati aggregati e arricchiti per la creazione di report e la visualizzazione.

Mentre alcune origini dati si trovano nella rete locale, altre si trovano dietro firewall e richiedono l'accesso sicuro e autenticato. Esistono anche alcune origini dati gestite in Azure, ad esempio database SQL di Azure e Archiviazione di Azure. È necessario connettersi a queste origini dati di Azure in modo da non esporre i dati alla rete internet pubblica.

Si è deciso di usare Fabric perché può inserire, archiviare, elaborare e analizzare in modo sicuro i dati nel cloud. È importante farlo rispettando al tempo stesso le normative del settore e dei criteri dell'organizzazione.

Poiché Fabric è un Software as a Service (SaaS), non è necessario effettuare il provisioning di singole risorse, ad esempio risorse di archiviazione o calcolo. Tutto ciò che serve è una capacità di Fabric.

È necessario configurare i requisiti di accesso ai dati. In particolare, è necessario assicurarsi che solo l'utente e i colleghi ingegneri dei dati abbiano accesso ai dati nei livelli bronze e silver della lakehouse. Questi livelli sono la posizione in cui si prevede di eseguire la pulizia, la convalida, la trasformazione e l'arricchimento dei dati. È anche necessario limitare l'accesso ai dati nel livello oro. Solo gli utenti autorizzati, inclusi gli analisti dei dati e gli utenti aziendali, devono avere accesso al livello oro. Richiedono questo accesso per usare i dati per vari scopi analitici, ad esempio la creazione di report, l'apprendimento automatico e l'analisi predittiva. L'accesso ai dati deve essere ulteriormente limitato dal ruolo e dal reparto dell'utente.

Connettersi a Fabric (protezione in entrata)

Prima di tutto si configura la protezione in entrata, che riguarda il modo in cui l'utente e altri utenti accedono e hanno accesso a Fabric.

Poiché Fabric viene distribuito in un tenant di Microsoft Entra, l'autenticazione e l'autorizzazione vengono gestite da Microsoft Entra. Si accede con l'account organizzazione Microsoft Entra (account aziendale o dell'istituto di istruzione). Si consideri quindi il modo in cui gli altri utenti si connetteranno a Fabric.

Il tenant di Microsoft Entra è un limite di sicurezza delle identità sotto il controllo del reparto IT. Entro questo limite di sicurezza, l'amministrazione degli oggetti Microsoft Entra (ad esempio gli account utente) e la configurazione delle impostazioni a livello di tenant vengono eseguite dagli amministratori IT. Come qualsiasi servizio SaaS, Fabric isola logicamente i tenant. I dati e le risorse nel tenant non possono mai essere accessibili da altri tenant, a meno che non vengano esplicitamente autorizzati a farlo.

Ecco cosa accade quando un utente accede a Fabric.

Articolo	Descrizione
	L'utente apre un browser (o un'applicazione client) e accede al portale di Fabric.
	L'utente viene immediatamente reindirizzato all'ID Microsoft Entra e deve eseguire l'autenticazione. L'autenticazione verifica che sia la persona corretta che esegue l'accesso.
	Al termine dell'autenticazione, il front-end Web riceve la richiesta dell'utente e distribuisce il contenuto front-end (HTML e CSS) dalla posizione più vicina. Instrada inoltre la richiesta alla piattaforma di metadati e alla piattaforma di capacità back-end.
	La piattaforma di metadati, che risiede nell'area principale del tenant, archivia i metadati del tenant, ad esempio aree di lavoro e controlli di accesso. Questa piattaforma garantisce che l'utente sia autorizzato ad accedere alle aree di lavoro e agli elementi di Fabric pertinenti.
	La piattaforma di capacità back-end esegue operazioni di calcolo e archivia i dati. Si trova nell'area di capacità. Quando un'area di lavoro viene assegnata alla capacità di Fabric, tutti i dati che risiedono nell'area di lavoro, incluso il data lake OneLake, vengono archiviati ed elaborati nell'area di capacità.

La piattaforma di metadati e la piattaforma di capacità back-end vengono eseguite in reti virtuali protette. Queste reti espongono una serie di endpoint sicuri a internet in modo che possano ricevere richieste da utenti e altri servizi. Oltre a questi endpoint, i servizi sono protetti da regole di sicurezza di rete che bloccano l'accesso da una rete internet pubblica.

Quando gli utenti accedono a Fabric, è possibile applicare altri livelli di protezione. In questo modo, il tenant sarà accessibile solo a determinati utenti e quando vengono soddisfatte altre condizioni, ad esempio la posizione di rete e la conformità dei dispositivi. Questo livello di protezione è denominato protezione in ingresso.

In questo scenario si è responsabili delle informazioni sensibili sui pazienti in Fabric. L'organizzazione ha quindi imposto a tutti gli utenti che accedono a Fabric di eseguire l'autenticazione a più fattori (MFA) e che devono trovarsi nella rete aziendale. La protezione dell'identità utente non è sufficiente.

L'organizzazione offre anche flessibilità per gli utenti consentendo loro di lavorare ovunque e di usare i propri dispositivi personali. Poiché Microsoft Intune supporta bring-your-own-device (BYOD), i dispositivi utente approvati vengono registrati in Intune.

Inoltre, è necessario assicurarsi che questi dispositivi siano conformi ai criteri dell'organizzazione. In particolare, questi criteri richiedono che i dispositivi possano connettersi solo quando hanno installato il sistema operativo più recente e le patch di sicurezza più recenti. Per configurare questi requisiti di sicurezza, usare l'accesso condizionale Di Microsoft Entra.

L'accesso condizionale offre diversi modi per proteggere il tenant. È possibile:

• Concedere o bloccare l'accesso in base al percorso di rete.
• Bloccare l'accesso ai dispositivi eseguiti in sistemi operativi non supportati.
• Richiedere un dispositivo conforme, aggiunto o MFA per tutti gli utenti.
• E altro ancora.

Nel caso in cui sia necessario bloccare l'intero tenant di Fabric, è possibile usare una rete virtuale e bloccare l'accesso alla rete internet pubblica. L'accesso a Fabric è quindi consentito solo dall'interno di tale rete virtuale sicura. Questo requisito è configurato abilitando i collegamenti privati a livello di tenant per Fabric. Garantisce che tutti gli endpoint di Fabric si risolvano in un indirizzo IP privato nella rete virtuale, incluso l'accesso a tutti i report di Power BI. (L'abilitazione degli endpoint privati influisce su molti elementi di Fabric, quindi è consigliabile leggere attentamente questo articolo prima di abilitarli).

Proteggere l'accesso ai dati all'esterno di Fabric (protezione in uscita)

Successivamente, si configura la protezione in uscita, che riguarda l'accesso sicuro ai dati dietro firewall o endpoint privati.

L'organizzazione dispone di alcune origini dati che si trovano nella rete locale. Poiché queste origini dati sono protette da firewall, Fabric richiede l'accesso sicuro. Per consentire a Fabric di connettersi in modo sicuro all'origine dati locale, installare un gateway dati locale.

Il gateway può essere usato dai flussi di dati e dalle pipeline di dati di Data Factory per inserire, preparare e trasformare i dati locali e quindi caricarli in OneLake con un'attività di copia. Data Factory supporta un set completo di connettori che consentono di connettersi a più di 100 archivi dati diversi.

Si compilano quindi flussi di dati con Power Query, che offre un'esperienza intuitiva con un'interfaccia con poco codice. È possibile usarli per inserire dati dalle origini dati e trasformarli usando una qualsiasi delle oltre 300 trasformazioni dati. Si compila e si orchestra un processo di estrazione, trasformazione e caricamento complesso (ETL) con pipeline di dati. I processi ETL possono aggiornare i flussi di dati ed eseguire molte attività diverse su larga scala, elaborando petabyte di dati.

In questo scenario sono già presenti più processi ETL. Prima di tutto, sono disponibili alcune pipeline in Azure Data Factory (ADF). Attualmente, queste pipeline inseriscono i dati locali e lo caricano in un data lake in Archiviazione di Azure usando il runtime di integrazione self-hosted. In secondo luogo, è disponibile un framework di inserimento dati in Azure Databricks scritto in Spark.

Ora che si usa Fabric, è sufficiente reindirizzare la destinazione di output delle pipeline di Azure Data Factory per usare il connettore lakehouse. Inoltre, per il framework di inserimento in Azure Databricks, si usano le API OneLake che supportano il driver ABFS (Azure Blog Filesystem) per integrare OneLake con Azure Databricks. (È anche possibile usare lo stesso metodo per l'integrazione OneLake con Azure Synapse Analytics usando Apache Spark).

Sono disponibili anche alcune origini dati in database SQL di Azure. È necessario connettersi a queste origini dati usando endpoint privati. In questo caso, si decide di configurare un gateway dati di rete virtuale (VNet) e di usare i flussi di dati per connettersi in modo sicuro ai dati di Azure e caricarli in Fabric. Con i gateway dati della rete virtuale, non è necessario effettuare il provisioning e gestire l'infrastruttura (come è necessario fare per il gateway dati locale). Questo perché Fabric crea in modo sicuro e dinamico i contenitori nella Rete virtuale di Azure.

Se si sviluppa o si esegue la migrazione del framework di inserimento dati in Spark, è possibile connettersi alle origini dati in Azure in modo sicuro e privato dai notebook e dai processi di Fabric con l'aiuto di endpoint privati gestiti. Gli endpoint privati gestiti possono essere creati nelle aree di lavoro di Fabric per connettersi alle origini dati in Azure che hanno bloccato l'accesso a una rete internet pubblica. Supportano endpoint privati, ad esempio database SQL di Azure e Archiviazione di Azure. Gli endpoint privati gestiti vengono sottoposti a provisioning e gestiti in una rete virtuale gestita dedicata a un'area di lavoro Fabric. A differenza delle Reti virtuale tipiche di Azure, le reti virtuali gestite e gli endpoint privati gestiti non si trovano nel portale di Azure. Ciò è dovuto al fatto che sono completamente gestiti da Fabric e si trovano nelle impostazioni dell'area di lavoro.

Poiché si dispone già di molti dati archiviati negli account Azure Data Lake Storage (ADLS) Gen2, è ora necessario connettere solo carichi di lavoro di Fabric, ad esempio Spark e Power BI, ad esso. Inoltre, grazie ai collegamenti di OneLake ADLS, è possibile connettersi facilmente ai dati esistenti da qualsiasi esperienza di Fabric, ad esempio pipeline di integrazione dei dati, notebook di progettazione dei dati e report di Power BI.

Le aree di lavoro di Fabric con un'identità dell'area di lavoro possono accedere in modo sicuro agli account di archiviazione di ADLS Gen2, anche quando la rete pubblica è stata disabilitata. Ciò è reso possibile dall'accesso all'area di lavoro attendibile. Consente a Fabric di connettersi in modo sicuro agli account di archiviazione usando una rete backbone Microsoft. Ciò significa che la comunicazione non usa la rete internet pubblica, che consente di disabilitare l'accesso alla rete pubblica all'account di archiviazione, ma consente comunque a determinate aree di lavoro di Fabric di connettersi.

Conformità

Si vuole usare Fabric per inserire, archiviare, elaborare e analizzare in modo sicuro i dati nel cloud, mantenendo al contempo la conformità alle normative del settore e ai criteri dell'organizzazione.

Fabric è parte dei servizi principali di Microsoft Azure ed è disciplinato dalle Condizioni di Microsoft Online Services e dall'Informativa sulla privacy di Microsoft Enterprise. Anche se le certificazioni si verificano in genere dopo l'avvio di un prodotto (disponibile a livello generale), Microsoft integra le procedure consigliate per la conformità fin dall'inizio e per tutto il ciclo di vita dello sviluppo. Questo approccio proattivo garantisce una solida base per le certificazioni future, anche se seguono cicli di controllo stabiliti. In termini più semplici, viene assegnata la priorità alla creazione della conformità fin dall'inizio, anche quando la certificazione formale arriva in un secondo momento.

Fabric è conforme a molti standard di settore, ad esempio ISO 27001, 27017, 27018 e 27701. Fabric è anche conforme a HIPAA, fondamentale per la privacy e la sicurezza dei dati sanitari. È possibile controllare l'Appendice A e B nelle offerte per la conformità di Microsoft Azure per informazioni dettagliate sui servizi cloud inclusi nell'ambito delle certificazioni. È anche possibile accedere alla documentazione di controllo da Service Trust Portal (STP).

L'adeguamento è una responsabilità condivisa. Per rispettare le leggi e le normative, i provider di servizi cloud e i loro clienti entrano in una responsabilità condivisa per garantire che ognuno faccia la propria parte. Quando si considerano e si valutano i servizi di cloud pubblico, è fondamentale comprendere il modello di responsabilità condivisa e capire quali attività di sicurezza vengono gestite dal provider di servizi cloud e quali dal cliente.

Trattamento dei dati

Poiché si gestiscono informazioni riservate sui pazienti, è necessario assicurarsi che tutti i dati siano sufficientemente protetti sia da inattivi che in transito.

La crittografia dei dati inattivi offre la protezione dei dati per i dati archiviati (inattivi). Gli attacchi contro i dati inattivi includono i tentativi di ottenere l'accesso fisico all'hardware in cui sono archiviati i dati e quindi compromettere i dati su tale hardware. La crittografia dei dati inattivi è progettata per impedire a un utente malintenzionato di accedere ai dati non crittografati, garantendo che i dati siano crittografati quando sono su disco. La crittografia dei dati inattivi è una misura obbligatoria necessaria per la conformità ad alcuni degli standard e delle normative del settore, ad esempio l'International Organization for Standardization (ISO) e Health Insurance Portability and Accountability Act (HIPAA).

Tutti gli archivi dati di Fabric vengono crittografati da inattivi usando chiavi gestite da Microsoft, che forniscono protezione per i dati dei clienti e anche i dati e i metadati di sistema. I dati non vengono mai salvati in modo permanente nell'archiviazione permanente in uno stato non crittografato. Con le chiavi gestite da Microsoft, è possibile sfruttare la crittografia dei dati inattivi senza il rischio o il costo di una soluzione di gestione delle chiavi personalizzata.

I dati vengono crittografati anche in transito. Tutto il traffico in ingresso verso gli endpoint di Fabric dai sistemi client applica almeno Transport Layer Security (TLS) 1.2. Inoltre, negozia TLS 1.3, quando possibile. Il protocollo TLS offre autenticazione avanzata, riservatezza dei messaggi e integrità (abilitando il rilevamento di manomissioni, intercettazioni e falsificazioni di messaggi), interoperabilità, flessibilità degli algoritmi e facilità di distribuzione e di utilizzo.

Oltre alla crittografia, il traffico di rete tra servizi Microsoft instrada sempre attraverso la rete globale Microsoft, una delle più grandi reti backbone del mondo.

Crittografia della chiave gestita dal cliente (CMK) e Microsoft Fabric

Le chiavi gestite dal cliente (CMK) consentono di usare le proprie chiavi per crittografare i dati inattivi. Per impostazione predefinita, Microsoft Fabric cripta i dati inattivi usando le chiavi gestite dalla piattaforma. In questo modello, Microsoft è responsabile di tutti gli aspetti della gestione delle chiavi e i dati inattivi su OneLake vengono crittografati utilizzando le sue chiavi. Dal punto di vista della conformità, i clienti potrebbero avere l'obbligo di utilizzare la chiave gestita dal cliente per crittografare i dati a riposo. Nel modello chiave gestita dal cliente, il cliente assume il controllo completo della chiave e usa le chiavi per crittografare i dati inattivi.

Se è necessario usare la chiave gestita dal cliente per crittografare i dati inattivi, è consigliabile usare i servizi di archiviazione cloud (ADLS Gen2, AWS S3, GCS) con la crittografia chiave gestita dal cliente abilitata e accedere ai dati da Microsoft Fabric usando i collegamenti OneLake. In questo modello i dati continuano a risiedere in un servizio di archiviazione cloud o in una soluzione di archiviazione esterna in cui è abilitata la crittografia dei dati inattivi tramite chiave gestita dal cliente ed è possibile eseguire operazioni di lettura sul posto da Fabric rimanendo in conformità. Dopo aver creato un collegamento, all'interno di Fabric è possibile accedere ai dati da altre esperienze di Fabric.

Ecco alcune considerazioni relative al'uso di questo modello:

• Usare il modello descritto qui per i dati con requisiti di crittografia dei dati inattivi usando la chiave gestita dal cliente. I dati che non hanno questo requisito possono essere crittografati inattivi usando chiavi gestite dalla piattaforma e quei dati possono essere archiviati in modo nativo in Microsoft Fabric OneLake.
• Fabric Lakehouse e il database KQL sono i due carichi di lavoro all'interno di Microsoft Fabric che supportano la creazione di collegamenti. In questo modello in cui i dati continuano a risiedere in un servizio di archiviazione esterno in cui è abilitata la chiave gestita dal cliente, è possibile usare collegamenti all'interno di Lakehouse e database KQL per inserire i dati in Microsoft Fabric per l'analisi, ma i dati vengono archiviati fisicamente all'esterno di OneLake in cui è abilitata la crittografia chiave gestita dal cliente.
• Il collegamento a ADLS Gen2 supporta la scrittura e l'uso di questo tipo di collegamento, è anche possibile scrivere i dati nel servizio di archiviazione che verranno crittografati inattivi usando la chiave gestita dal cliente. Durante l'uso della chiave gestita dal cliente con ADLS Gen2, si applicano le considerazioni seguenti per Azure Key Vault (AKV) e Archiviazione di Azure.
• Se si usa una soluzione di archiviazione di terze parti compatibile con AWS S3 (Cloudflare, Qumolo Core con endpoint pubblico, Public MinIO e Dell ECS con endpoint pubblico) ed è abilitata la chiave gestita dal cliente, il modello descritto in questo documento può essere esteso a queste soluzioni di archiviazione di terze parti. Usando il collegamento compatibile con Amazon S3, è possibile inserire i dati in Fabric usando un collegamento da queste soluzioni. Come per i servizi di archiviazione basati sul cloud, è possibile archiviare i dati in una risorsa di archiviazione esterna con la crittografia chiave gestita dal cliente ed eseguire operazioni di lettura sul posto.
• AWS S3 supporta la crittografia dei dati inattivi usando chiavi gestite dal cliente. Fabric può eseguire letture sul posto nei bucket S3 usando il collegamento S3. Le operazioni di scrittura tramite un collegamento a AWS S3 non sono tuttavia supportate.
• Google Cloud Storage supporta la crittografia dei dati usando chiavi gestite dal cliente. Fabric può eseguire letture sul posto su GCS. Tuttavia, le operazioni di scrittura che usano un collegamento a GCS non sono supportate.
• Abilitare il controllo per Microsoft Fabric per tenere traccia delle attività.
• In Microsoft Fabric l'esperienza di Power BI supporta la chiave gestita dal cliente.
• Disabilitare la funzionalità di memorizzazione nella cache dei collegamenti per collegamenti compatibili con S3, GCS e S3. poiché i dati memorizzati nella cache vengono salvati in modo permanente in OneLake.

Residenza dei dati

Quando si gestiscono i dati dei pazienti, per motivi di conformità l'organizzazione ha imposto che i dati non debbano mai lasciare il limite geografico Stati Uniti. Le principali operazioni dell'organizzazione si svolgono a New York e alla sede centrale di Seattle. Durante la configurazione di Power BI, l'organizzazione ha scelto l'area Stati Uniti orientali come area principale del tenant. Per le operazioni è stata creata una capacità di Fabric nell'area Stati Uniti occidentali, più vicina alle origini dati. Poiché OneLake è disponibile in tutto il mondo, si è preoccupati se è possibile soddisfare i criteri di residenza dei dati dell'organizzazione durante l'uso di Fabric.

In Fabric si apprenderà che è possibile creare capacità multi-geografiche, ovvero capacità che si trovano in aree geografiche diverse dall'area principale del tenant. Si assegnano le aree di lavoro di Fabric a tali capacità. In questo caso, il calcolo e l'archiviazione (incluso OneLake e l'archiviazione specifica dell'esperienza) per tutti gli elementi nell'area di lavoro si trovano nell'area multi-geografica, mentre i metadati del tenant rimangono nell'area principale. I dati verranno archiviati ed elaborati solo in queste due aree geografiche, assicurando così che vengano soddisfatti i requisiti di residenza dei dati dell'organizzazione.

Controllo di accesso

È necessario assicurarsi che solo l'utente e i colleghi ingegneri dei dati abbiano accesso completo ai dati nei livelli bronze e silver della lakehouse. Questi livelli consentono di eseguire la pulizia, la convalida, la trasformazione e l'arricchimento dei dati. È necessario limitare l'accesso ai dati nel livello gold solo agli utenti autorizzati, ad esempio analisti di dati e utenti aziendali, che possono usare i dati per vari scopi analitici, ad esempio report e analisi.

Fabric offre un modello di autorizzazione flessibile che consente di controllare l'accesso a elementi e dati nelle aree di lavoro. Un'area di lavoro è un'entità logica a protezione diretta per il raggruppamento di elementi in Fabric. I ruoli dell'area di lavoro vengono usati per controllare l'accesso agli elementi nelle aree di lavoro. I quattro ruoli di base di un'area di lavoro sono:

• Amministratore: può visualizzare, modificare, condividere e gestire tutto il contenuto nell'area di lavoro, inclusa la gestione delle autorizzazioni.
• Membro: può visualizzare, modificare e condividere tutto il contenuto nell'area di lavoro.
• Collaboratore: può visualizzare e modificare tutto il contenuto nell'area di lavoro.
• Visualizzatore: può visualizzare tutto il contenuto nell'area di lavoro, ma non modificarlo.

In questo scenario vengono create tre aree di lavoro, una per ogni livello di medaglia (bronzo, argento e oro). Se un utente crea un’area di lavoro, gli viene assegnato automaticamente il ruolo Amministratore.

Si aggiunge quindi un gruppo di sicurezza al ruolo Collaboratore di queste tre aree di lavoro. Poiché il gruppo di sicurezza include i colleghi tecnici come membri, è in grado di creare e modificare gli elementi di Fabric in tali aree di lavoro, ma non possono condividere elementi con altri utenti. Non possono nemmeno concedere l'accesso ad altri utenti.

Nelle aree di lavoro bronze e silver, l'utente e i colleghi tecnici creano elementi Fabric per inserire dati, archiviare i dati ed elaborare i dati. Gli elementi di Fabric comprendono una lakehouse, una pipeline e i notebook. Nell'area di lavoro gold si creano due lakehouse, più pipeline e notebook e un modello semantico Direct Lake, che offre prestazioni di query rapide dei dati archiviati in una delle lakehouse.

Si esamini quindi attentamente il modo in cui gli analisti dei dati e gli utenti aziendali possono accedere ai dati a cui sono autorizzati ad accedere. In particolare, possono accedere solo ai dati rilevanti per il proprio ruolo e reparto.

La prima lakehouse contiene i dati effettivi e non applica autorizzazioni per i dati nell'endpoint di analisi SQL. La seconda lakehouse contiene collegamenti alla prima lakehouse e applica autorizzazioni granulari per i dati nell'endpoint di analisi SQL. Il modello semantico si connette alla prima lakehouse. Per applicare le autorizzazioni appropriate ai dati per gli utenti (in modo che possano accedere solo ai dati rilevanti per il proprio ruolo e reparto), non si condivide la prima lakehouse con gli utenti. Al contrario, si condivide solo il modello semantico Direct Lake e il secondo lakehouse che applica le autorizzazioni per i dati nell'endpoint di analisi SQL.

Si configura il modello semantico per l'uso di un'identità fissa e quindi si implementa la sicurezza a livello di riga nel modello semantico per applicare regole del modello per gestire i dati a cui gli utenti possono accedere. Si condivide quindi solo il modello semantico con gli analisti dei dati e gli utenti aziendali perché non devono accedere agli altri elementi nell'area di lavoro, ad esempio le pipeline e i notebook. Infine, si concede l'autorizzazione di creazione per il modello semantico in modo che gli utenti possano creare report di Power BI. In questo modo, il modello semantico diventa un modello semantico condiviso e un'origine per i report di Power BI.

Gli analisti dei dati devono accedere alla seconda lakehouse nell'area di lavoro gold. Si connetteranno all'endpoint di analisi SQL di tale lakehouse per scrivere query SQL ed eseguire analisi. Di conseguenza, si condivide tale lakehouse con essi e si fornisce l'accesso solo agli oggetti necessari (ad esempio tabelle, righe e colonne con regole di maschera) nell'endpoint di analisi SQL lakehouse usando il modello di sicurezza SQL. Gli analisti dei dati possono ora accedere solo ai dati rilevanti per il proprio ruolo e reparto e non possono accedere agli altri elementi nell'area di lavoro, ad esempio le pipeline e i notebook.

Scenari di sicurezza comuni

Nella tabella seguente sono elencati gli scenari di sicurezza comuni e gli strumenti che è possibile usare per eseguirli.

Scenario	Strumenti	Direzione
Sono uno sviluppatore ETL e voglio caricare grandi volumi di dati in Fabric su larga scala da più sistemi e tabelle di origine. I dati di origine sono locali (o altri cloud) e si trovano dietro firewall e/o origini dati di Azure con endpoint privati.	Usare il gateway dati locale con pipeline di dati (attività Copy).	In uscita
Io sono un Power User e voglio caricare i dati in Fabric dai sistemi di origine a cui ho accesso. Poiché non sono uno sviluppatore, è necessario trasformare i dati usando un'interfaccia con poco codice. I dati di origine sono locali (o altri cloud) e si trovano dietro i firewall.	Usare il gateway dati locale con Dataflow Gen 2.	In uscita
Io sono un Power User e voglio caricare i dati in Fabric dai sistemi di origine a cui ho accesso. I dati di origine si trovano in Azure dietro endpoint privati e non voglio installare e gestire l'infrastruttura del gateway dati locale.	Usare un gateway dati della rete virtuale con Dataflow Gen 2.	In uscita
Sono uno sviluppatore che può scrivere codice di inserimento dati usando notebook Spark. Voglio caricare i dati in Fabric dai sistemi di origine a cui ho accesso. I dati di origine si trovano in Azure dietro endpoint privati e non voglio installare e gestire l'infrastruttura del gateway dati locale.	Usare i notebook di Fabric con endpoint privati di Azure.	In uscita
Ho molte pipeline esistenti in Azure Data Factory (ADF) e pipeline Synapse che si connettono alle origini dati e caricano i dati in Azure. Ora voglio modificare tali pipeline per caricare i dati in Fabric.	Usare il connettore Lakehouse nelle pipeline esistenti.	In uscita
Ho un framework di inserimento dati sviluppato in Spark che si connette alle origini dati in modo sicuro e li carica in Azure. È in esecuzione in Azure Databricks e/o Synapse Spark. Voglio continuare a usare Azure Databricks e/o Synapse Spark per caricare i dati in Fabric.	Usare l'API OneLake e Azure Data Lake Storage Gen2 (driver Azure Blob File System)	In uscita
Voglio assicurarmi che gli endpoint di Fabric siano protetti dalla rete internet pubblica.	Come servizio SaaS, il back-end di Fabric è già protetto dalla rete internet pubblica. Per una maggiore protezione, usare i criteri di accesso condizionale di Microsoft Entra per Fabric e/o abilitare i collegamenti privati a livello di tenant per Fabric e bloccare l'accesso alla rete internet pubblica.	In entrata
Voglio assicurarmi che Fabric sia accessibile solo dalla rete aziendale e/o dai dispositivi conformi.	Usare i criteri di accesso condizionale in Microsoft Entra per Fabric.	In entrata
Voglio assicurarmi che chiunque acceda a Fabric debba eseguire l'autenticazione a più fattori.	Usare i criteri di accesso condizionale in Microsoft Entra per Fabric.	In entrata
Voglio bloccare l'intero tenant di Fabric dalla rete internet pubblica e consentire l'accesso solo dall'interno delle reti virtuali.	Abilitare i collegamenti privati a livello di tenant per Fabric e bloccare l'accesso alla rete internet pubblica.	In entrata

Contenuto correlato

Per altre informazioni sulla sicurezza del servizio Fabric, vedere le risorse seguenti.

• Sicurezza del servizio Microsoft Fabric
• Panoramica della protezione di OneLake
• Nozioni e licenze di Microsoft Fabric
• Domande? Provare a chiederle alla community di Microsoft Fabric.
• Suggerimenti? Contribuire con idee al miglioramento di Fabric.