Uso di Flow per la governance dei dati direzionale
In alcune situazioni aziendali, possono essere presenti dati provenienti da origini esterne attraverso i connettori e questi dati vengono inseriti in servizi che contengono informazioni aziendali importanti. Quando si parla di criteri di prevenzione della perdita dei dati (DLP), di solito è necessario che entrambi i connettori comunichino reciprocamente. Il punto è assicurarsi che i connettori comunichino solo in una direzione e che i preziosi dati aziendali non finiscano accidentalmente a terze parti. Questa è la gestione del flusso di dati, vale a dire assicurarsi che i dati vadano solo dove devono andare. Questo processo si chiama governance dei dati direzionale.
Al momento, i criteri DLP non gestiscono automaticamente la governance dei dati direzionale. È tuttavia possibile utilizzare Power Automate per intercettare e arrestare eventuali flussi che tentano di inviare i dati aziendali verso destinazioni esterne.
Ecco un esempio: si supponga che la propria organizzazione voglia utilizzare SharePoint per tenere traccia dei dati di Twitter. Il problema qui è che le informazioni private potrebbero passare da SharePoint a Twitter.
Per assicurarsi che i dati fluiscano solo nella direzione corretta, si iniziano a creare criteri DLP nell'interfaccia di amministrazione di Power Platform. In questi criteri si raggruppano insieme i connettori SharePoint e Twitter come dati aziendali. In questo modo, si lascia che gli utenti creino i flussi usando entrambi i connettori, ma ci si assicura anche che i propri dati restino al sicuro e non finiscano accidentalmente nelle mani sbagliate.
Il primo passaggio per applicare la governance dei dati direzionale consiste nel creare dall'interfaccia di amministrazione di Power Platform criteri DLP che includono i connettori di SharePoint e Twitter nel gruppo Dati aziendali. L'uso di questa configurazione consente agli autori di creare flussi che includono entrambi i connettori.
Successivamente, si passerà a Power Automate Maker Portal e si eseguirà l'accesso usando l'account amministratore per poter creare il flusso di governance. L'obiettivo consiste nel creare un flusso pianificato che verrà eseguito ogni ora.
Un trigger di ricorrenza verrà aggiunto automaticamente al flusso. A questo punto si aggiungerà un'azione Inizializza variabile al flusso. Assegnare il nome previousTimestamp alla variabile, quindi includere un'espressione
ticks(addMinutes(utcNow(),-60)). Questa espressione calcola il numero di tick a partire dai 60 minuti precedenti. Questa espressione viene inserita per verificare se sono stati creati o modificati flussi dall'ultima esecuzione del flusso, avvenuta 60 minuti prima.
Aggiungere un'altra variabile denominata isFlowAction di tipo booleano e con valore predefinito false. Questa variabile verrà usata successivamente nel flusso quando si rileva che un flusso include un'azione Twitter.
Usare quindi il connettore Power Platform for Admins e l'azione Elenca ambienti come amministratore che fornirà al flusso l'elenco completo degli ambienti del tenant. Successivamente riprodurre in ciclo ogni ambiente in modo che sia possibile cercare i flussi che includono azioni Twitter.
Dopo aver elencato tutti gli ambienti, si aggiungerà il connettore Flow Management e si userà l'azione Elenca flussi come amministratore che fornirà un elenco di tutti i flussi di un determinato ambiente.
L'azione Elenca flussi come amministratore richiede il nome di un ambiente come parametro di input. Usare la colonna Nome restituita dalla chiamata Elenca ambienti come amministratore. Quando si specifica questo input, viene automaticamente aggiunta un'azione Applica a ogni che consentirà di eseguire l'iterazione di tutti gli ambienti.
Poiché si è interessati solo all'esplorazione dei flussi modificati di recente, si aggiungerà una condizione al flusso e si confronteranno i tick del timestamp dell'ultima modifica del flusso rispetto a quelli della variabile definita in precedenza nel flusso. Per eseguire questa attività, usare un'espressione per calcolare i tick del timestamp dell'ultima modifica. L'istruzione completa è
ticks(items('Apply_to_each_2')?['properties']?['lastModifiedTime']) is greater than previousTimestamp.
Quando si rileva che un flusso è stato modificato negli ultimi 60 minuti, si vorrà verificare che non appartenga all'amministratore. Questa verifica consente di evitare un errore quando si tenta di aggiungere l'amministratore come comproprietario di un flusso in un passaggio successivo. Per determinare se il flusso corrente appartiene all'amministratore, usare il connettore Utenti di Office 365 e l'azione Recupera profilo personale (V2). Questo passaggio restituirà informazioni sull'utente che ha stabilito una connessione al connettore, che in questo caso è l'amministratore. Successivamente, aggiungere l'azione Utenti di Office 365 al ramo Se sì.
A questo punto, si aggiungerà un'altra condizione che verificherà se l'ID oggetto Autore (dell'azione Elenca flussi come amministratore) non corrisponde all'ID (dell'azione Recupera profilo personale (V2)). Nel ramo Se sì aggiungere l'azione Modifica ruolo proprietario flusso come amministratore che appartiene al connettore Microsoft Flow for Admins. Questa azione consente di aggiungere l'utente amministratore come comproprietario del flusso e consente di estrarre la definizione del flusso, operazione consentita ai comproprietari del flusso. La definizione del flusso verrà recuperata in un passaggio successivo, ma, per il momento, occorre specificare le opzioni Nome ambiente e Nome flusso correnti, nonché i dettagli relativi all'utente amministratore, ad esempio l'indirizzo e-mail, il nome visualizzato e l'ID. Questi valori sono accessibili dall'azione Recupera profilo personale (V2).
Dopo aver aggiunto l'account amministratore come comproprietario del flusso, è possibile chiamare l'azione Ottieni flusso come amministratore dal connettore Flow Management.
Gli input per l'azione Ottieni flusso come amministratore includono il Nome ambiente e il Nome flusso correnti. L'output di questa azione include la definizione del flusso che consentirà di determinare se è presente un'azione Twitter.
Per verificare se viene usata un'azione Twitter, aggiungere una condizione al flusso e verificare se il nome dell'API azione (dall'azione Ottieni flusso come amministratore) corrisponde a shared_twitter. Dopo aver aggiunto questa condizione, viene applicato un ciclo Applica a ogni in quanto l'attributo del nome API azione è incluso in una matrice visto che ogni flusso può avere più azioni.
All'interno del ramo Se sì, aggiornare la variabile isFlowAction in modo che sia impostata su true poiché è stato rilevato un flusso che include un'azione Twitter. Questa variabile verrà usata successivamente nel flusso per determinare se è necessario disabilitare un flusso e inviare un messaggio e-mail al proprietario del flusso.
All'esterno della variabile Applica a ogni che consente di eseguire l'iterazione di tutte le azioni nel flusso aggiungere un'altra condizione. Questa condizione verificherà se il valore della variabile isFlowAction è true.
Nel ramo Se sì aggiungere il connettore Microsoft Flow for Admins e selezionare l'azione Disabilita flusso come amministratore. Questa azione consentirà di disabilitare il flusso in modo che le informazioni non possano essere inviate a Twitter. Per chiamare questa azione, includere Nome ambiente e Nome flusso correnti.
Quando si disabilita il flusso di un utente, si vorrà inviare all'utente un messaggio e-mail per comunicargli che il flusso non è più in esecuzione. Per ottenere l'indirizzo e-mail del proprietario del flusso, usare il connettore Utenti di Office 365 e usare l'azione Recupera profilo utente (V2) per restituire l'indirizzo e-mail del proprietario. Per ottenere l'indirizzo e-mail, sarà necessario aggiungere ID oggetto autore, che può essere recuperato dall'azione Elenca flussi come amministratore.
Inviare un messaggio e-mail al proprietario del flusso usando il connettore Office 365 Outlook e l'azione Invia un messaggio e-mail (v2). Usare le informazioni restituite dall'azione Recupera profilo utente (V2) per inviare questo messaggio e-mail, inclusi gli attributi Posta e Nome. È anche possibile inserire il nome del flusso aggiungendo l'attributo Nome visualizzato flusso incluso nell'output di Elenca flussi come amministratore.
Poiché vengono riprodotti a ciclo continuo tutti i flussi nel tenant, sarà necessario impostare di nuovo la variabile isFlowAction su false in modo che sia possibile cercare altri flussi che potrebbero includere un'azione Twitter. È ora possibile salvare il flusso amministrativo.
Per testare il flusso, accedere a Power Automate Maker Portal usando un account diverso. A questo punto, si passerà alla creazione di un flusso che include un trigger SharePoint e un'azione Twitter. Questo scenario non verrà bloccato dai criteri DLP, ma dovrebbe essere rilevato dal flusso amministrativo creato.
È ora possibile eseguire il flusso Rilevamento azioni Twitter creato in precedenza come amministratore. Durante l'esecuzione di questo flusso, viene rilevata una modifica recente a un flusso che include un'azione Twitter. Di conseguenza, verrà inviato un messaggio e-mail al proprietario del flusso.
Se si esamina il flusso da SharePoint a Twitter, si noterà che è stato disabilitato dall'amministratore.
Tuttavia, il recupero delle informazioni da Twitter e il loro invio a SharePoint non violano le regole di governance. Di conseguenza, è possibile creare un altro flusso usando l'account dell'autore del flusso che include un trigger Twitter e un'azione SharePoint. Quando si esegue il flusso di governance di rilevamento delle azioni Twitter, il flusso rimane funzionante e non viene disabilitato poiché si tratta di un caso d'uso consentito.
