Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
I criteri dei dati sono un aspetto fondamentale della gestione della sicurezza e della conformità dei dati all'interno dell'ecosistema Microsoft Power Platform.
Creare criteri di dati che fungono da protezioni per ridurre il rischio che gli utenti espongono involontariamente i dati dell'organizzazione. Un componente fondamentale di Power Apps, Power Automate e Microsoft Studio Copilot è l'uso di connettori per enumerare, popolare, inviare e recuperare i dati. I criteri dei dati dell'interfaccia di amministrazione di Power Platform consentono agli amministratori di controllare l'accesso a questi connettori in diversi modi per ridurre i rischi nell'organizzazione.
Questa panoramica descrive alcuni concetti di alto livello relativi ai connettori e diverse considerazioni importanti da tenere in considerazione quando si impostano i criteri o si apportano modifiche ai criteri.
Connettori
I connettori, al livello più semplice, sono rappresentazioni fortemente tipate di interfacce di programmazione dell'applicazione RESTful, note anche come API. Ad esempio, l'API Power Platform fornisce diverse operazioni relative alle funzionalità nell'interfaccia di amministrazione di Power Platform.
Quando si esegue il wrapping dell'API Power Platform in un connettore, diventa più semplice per i creatori e gli sviluppatori cittadini usare l'API nelle app, nei flussi di lavoro e nei chatbot con poco codice. Ad esempio, il connettore Power Platform per amministratori V2 è la rappresentazione dell'API Power Platform e si noterà che l'azione Ottieni raccomandazioni è semplicemente trascinata e rilasciata nel flusso:
In questo articolo vengono menzionati diversi tipi di connettori. Ogni tipo ha funzionalità diverse all'interno delle politiche sui dati.
Connettori certificati
I connettori certificati sono connettori che Microsoft test e certificati per garantire che soddisfino gli standard di Microsoft per la sicurezza, l'affidabilità e la conformità. Questi connettori offrono agli utenti un mezzo affidabile per l'integrazione con altri servizi servizi Microsoft ed esterni, mantenendo al contempo l'integrità e la sicurezza dei dati.
Per ulteriori informazioni sui connettori certificati, vedi Linee guida per l'invio della certificazione.
Connettori personalizzati
I connettori personalizzati consentono ai produttori di creare i propri connettori da integrare con sistemi o servizi esterni non coperti dal set standard di connettori certificati. Anche se i connettori personalizzati offrono flessibilità e opzioni di personalizzazione, richiedono un'attenta considerazione per garantire la conformità ai criteri dei dati e non compromettere la sicurezza dei dati.
Ulteriori informazioni sulla creazione e la gestione dei connettori personalizzati.
Connettori virtuali
I connettori virtuali sono connettori visualizzati nei criteri di dati che gli amministratori possono controllare, ma non sono basati su un'API RESTful. La proliferazione dei connettori virtuali deriva dal fatto che le politiche sui dati sono uno dei controlli di governance più diffusi in Power Platform. Si prevede che molti di questi tipi di funzionalità di "accensione" emergano come regole all'interno dei gruppi ambientali.
Microsoft fornisce diversi connettori virtuali per la gestione di Microsoft Copilot Studio. Questi connettori facilitano la possibilità di disattivare varie funzionalità di Copilot e chatbot.
Informazioni sui connettori virtuali e sul relativo ruolo in prevenzione della perdita di dati in Microsoft Copilot Studio.
Importante
I criteri dei connettori avanzati (ACP) non supportano i connettori virtuali e non aggiungeranno il supporto in futuro. La particolare attenzione di ACP è quella di essere la funzionalità di governance più affidabile per i connettori certificati reali. I percorsi di transizione seguenti si applicano ai connettori virtuali:
- Copilot Studio connettori virtuali stanno evolvendo in regole di governance autonome e dedicate, separate dalle politiche sui dati e ACP.
- I connettori virtuali di Desktop Flow passano ai connettori certificati, a questo punto ACP li gestisce.
Connettori MCP (Model Context Protocol)
I connettori MCP (Model Context Protocol) sono una classe di connettori che forniscono più metadati per esporre endpoint API abilitati per MCP, noti come strumenti. I connettori MCP estendono le funzionalità tipiche del connettore e consentono esperienze più avanzate per l'intelligenza artificiale generativa in Microsoft Copilot Studio.
Molti dei connettori non bloccabili in Microsoft Power Platform ora supportano MCP. È possibile gestire e limitare questi connettori e i relativi server MCP tramite criteri di connettore avanzati.
Connessioni
Quando un autore compila un'app o un flusso e deve connettersi ai dati, può usare uno dei tipi di connettore descritti in precedenza. Quando un autore aggiunge prima un connettore a un'app, stabilisce una connessione usando i protocolli di autenticazione supportati dal connettore. Queste connessioni rappresentano una credenziale salvata e vengono archiviate all'interno dell'ambiente che ospita l'app o il flusso. Per altre informazioni sull'autenticazione ai connettori, vedere Connessione e autenticazione alle origini dati.
Fase di progettazione e fase di esecuzione
Quando un amministratore sceglie di limitare l'accesso a un intero connettore o a azioni specifiche di un connettore, influisce sia sull'esperienza di creatore che sull'esecuzione di app, flussi e chatbot creati in precedenza.
Le esperienze degli autori, spesso definite esperienze in fase di progettazione, limitano ciò con cui i produttori di connettori possono interagire. Se un criterio sui dati blocca l'uso del connettore MSN Weather, un creatore non può salvare il flusso o l'app che usa questo connettore. Ricevono invece un messaggio di errore che indica che il connettore è bloccato dai criteri.
Le esperienze in cui un'app è in esecuzione o un flusso viene eseguito in base a una pianificazione predefinita, ad esempio ogni giorno alle 3:00 di mattina, vengono spesso definite esperienze di esecuzione. Continuando con l'esempio precedente, se il processo in background descritto nella sezione seguente disattiva la connessione, l'app o il flusso fornisce un messaggio di errore che indica che la connessione MSN Weather è interrotta e richiede la risoluzione. Quando il produttore tenta di aggiornare la propria connessione per risolvere il problema, riceve un errore nell'esperienza in fase di progettazione che indica che il connettore è bloccato dalle politiche.
Processo per le modifiche ai criteri
Quando si creano nuovi criteri dati o si aggiornano i criteri esistenti, l'ecosistema di servizi Power Platform attiva un processo specifico. Questo processo consente di applicare tali criteri nell'intero set di risorse che un cliente ha nel tenant. Il processo include i seguenti passaggi.
- Salva la configurazione della politica sui dati a livello di gestione dei clienti.
- Configurazioni a catena fino a ogni ambiente nel tenant del cliente.
- Le risorse in ogni ambiente (come app, flussi e chatbot) controllano periodicamente la disponibilità di configurazioni di criteri aggiornati.
- Quando viene rilevata una modifica della configurazione, valutare ogni app, flusso e chatbot per verificare se viola i criteri.
- Se si verifica una violazione, inserire l'app, il flusso o il chatbot in uno stato di sospensione o quarantena in modo che non possa funzionare.
- Analizzare le connessioni. Se il criterio blocca l'intero connettore, impostare la connessione su uno stato disabilitato in modo che non possa funzionare.
- Tutte le risorse in esecuzione e che tentano di usare una connessione inattiva, un'azione, un trigger o un server MCP bloccato, hanno esito negativo in fase di esecuzione.
Considerazioni sulla latenza
Il tempo necessario per implementare in modo efficace i criteri sui dati varia da cliente a cliente in base al volume degli ambienti e delle risorse all'interno di tali ambienti. Più app, flussi e chatbot hanno un cliente, più tempo è necessario per rendere effettive le modifiche ai criteri. Nei casi più estremi, il tempo di latenza per l'applicazione completa è di 24 ore. Nella maggior parte dei casi, è entro un'ora.