Criteri dati

La prevenzione della perdita dei dati (DLP) è un aspetto fondamentale per mantenere la sicurezza e la conformità dei dati all'interno dell'ecosistema Microsoft Power Platform.

Puoi creare criteri di dati che agiscono come barriere per ridurre il rischio per gli utenti di esporre involontariamente i dati dell'organizzazione. Un componente fondamentale di Power Apps, Power Automate e Microsoft Copilot Studio è l'uso di connettori per enumerare, popolare, inviare ed estrarre dati. I criteri sui dati nell'interfaccia di amministrazione di Power Platform consentono agli amministratori di controllare l'accesso a questi connettori in vari 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 loro livello più elementare, sono rappresentazioni fortemente tipizzate di interfacce di programmazione delle applicazioni 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 dispone il testo dell'API Power Platform in un connettore, diventa più facile per gli autori e i citizen developer utilizzare l'API nelle app, i flussi di lavoro e chatbot con poco codice. Ad esempio, il connettore Power Platform for Admins V2 è la rappresentazione dell'API Power Platform e vediamo che l'azione "Ottieni consigli" viene semplicemente trascinata nel flusso:

In questo articolo sono menzionati diversi tipi di connettori e ciascuno dispone di funzionalità all'interno dei criteri dei dati.

Connettori certificati

I connettori certificati si riferiscono a connettori che sono stati sottoposti a rigorosi processi di test e certificazione per garantire che soddisfino gli standard Microsoft in termini di sicurezza, affidabilità e conformità. Questi connettori forniscono agli utenti un mezzo affidabile per l'integrazione con altri servizi Microsoft e servizi esterni, il tutto mantenendo 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. Pur offrendo flessibilità e opzioni di personalizzazione, i connettori personalizzati richiedono un'attenta considerazione per garantire che siano conformi ai criteri sui dati e non compromettano la sicurezza dei dati.

Ulteriori informazioni sulla creazione e la gestione dei connettori personalizzati.

Connettori virtuali

I connettori virtuali sono connettori visualizzati nei criteri dei dati affinché gli amministratori possano controllarli, tuttavia non sono basati su un'API RESTful. La proliferazione di connettori virtuali è derivata dal fatto che i criteri sui dati sono uno dei controlli di governance più popolari in Power Platform. Si prevede che molti di questi tipi di funzionalità di "accensione" emergano come regole all'interno dei gruppi ambientali.

Sono previsti diversi connettori virtuali per la governance di Microsoft Copilot Studio. Questi connettori facilitano la possibilità di disattivare varie funzionalità di Copilot e chatbot.

Esplora i connettori virtuali e il loro ruolo nella prevenzione della perdita di dati in Microsoft Copilot Studio.

Connessioni

Quando un autore sta creando un'app o un flusso e ha bisogno di connettersi ai dati, può utilizzare uno dei tipi di connettore sopra indicati. Quando un connettore viene aggiunto per la prima volta a un'app, viene stabilita una connessione utilizzando i protocolli di autenticazione supportati da quel particolare connettore. Queste connessioni rappresentano una credenziale salvata e vengono archiviate nell'ambiente che ospita l'app o il flusso. Per altre informazioni sull'autenticazione ai connettori, vedi 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 ad azioni specifiche di un connettore, si verificano impatti sia sull'esperienza del produttore 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 ha bloccato l'uso del connettore MSN Meteo, un autore non può salvare il flusso o l'app che lo utilizza e riceve invece un messaggio di errore che informa che il connettore è stato bloccato dal criterio.

Le esperienze in cui un'app o un flusso viene eseguito in base a una pianificazione predefinita, ad esempio ogni giorno alle 3:00, vengono spesso definite esperienze di runtime. Continuando con l'esempio precedente, se la connessione è stata disattivata dal processo in background descritto di seguito, il risultato è che l'app o il flusso fornisce un messaggio di errore che informa che la connessione a MSN Meteo è interrotta e necessita di una risoluzione. Quando il produttore tenta di aggiornare la propria connessione per risolverlo, riceve un errore nell'esperienza in fase di progettazione che indica che il connettore è bloccato dai criteri.

Processo per le modifiche ai criteri

Quando vengono creati nuovi criteri sui dati o quando i criteri esistenti vengono aggiornati, viene attivato un processo specifico all'interno dell'ecosistema di servizi Power Platform che aiuta a far sì che tali criteri vengano applicati all'intero insieme di risorse che un cliente ha a disposizione nel tenant. Il processo include i seguenti passaggi.

1. La configurazione dei criteri dei dati viene salvata a livello di gestione del cliente.
2. Le configurazioni vengono applicate a cascata in ogni ambiente nel tenant del cliente.
3. Le risorse in ogni ambiente (come app, flussi e chatbot) controllano periodicamente la disponibilità di configurazioni di criteri aggiornati.
4. Quando viene rilevata una modifica alla configurazione, ogni app, flusso e chatbot viene valutato per verificare se viola i criteri.
5. Se si verifica una violazione, l'app, il flusso o il chatbot vengono messi in uno stato sospeso o quarantena in modo che non possa funzionare.
6. Le connessioni vengono scansionate. Se il criterio blocca l'intero connettore, la connessione viene impostata su uno stato disabilitato in modo che non possa funzionare.
7. Qualsiasi risorsa in esecuzione e che tenta di utilizzare una connessione inattiva fallisce in fase di runtime.

Importante

L'imposizione del runtime si basa sullo stato della connessione. Se non è ancora disattivato o non è stato ancora scansionato, la connessione può ancora essere eseguita in fase di runtime senza errori.

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. Maggiore è il numero di app, flussi e chatbot di cui dispone un cliente, maggiore sarà il tempo necessario affinché le modifiche ai criteri abbiano pieno effetto. Nei casi più estremi, il tempo di latenza per l'applicazione completa è di 24 ore. Nella maggior parte dei casi è entro un'ora.

Vedi anche

Gestire i criteri di prevenzione della perdita dei dati (DLP)