Il primo articolo di questa serie ha trattato il modo di rimuovere la capacità degli utenti OWA di creare indirizzi di autoforwarding. Questo contribuisce molto a fermare l’inoltro delle email al di fuori di un’organizzazione, ma OWA è solo una parte del problema. Abbiamo anche bisogno di affrontare gli altri modi in cui i messaggi possono essere inoltrati automaticamente a indirizzi esterni.
Ad esempio, le regole di Outlook possono inoltrare i messaggi. È possibile utilizzare PowerShell per esaminare ogni casella di posta alla ricerca di regole di inoltro, ma questo potrebbe richiedere molto lavoro che dovremmo fare continuamente. Esaminiamo alcuni metodi più robusti per bloccare l’inoltro automatico in uscita.
Blocco per domini
Il blocco per dominio è un metodo efficace per impedire l’inoltro automatico dei messaggi. Il blocco viene implementato utilizzando il cmdlet Set-RemoteDomain (o, nell’EAC modificando l’impostazione del dominio remoto in Mail Flow). Questo comando impedisce l’autoforwarding delle email a qualsiasi dominio, tranne quando esistono impostazioni esplicite per consentire l’inoltro a un dominio.
Set-RemoteDomain -Identity Default -AutoForwardEnabled $False
Per verificare se un dominio consente l’autoforwarding, eseguire questo comando:
Get-RemoteDomain |?{$_.AutoForwardEnabled -eq $True}| Format-Table DomainName, AutoReplyEnabled
DomainName AutoReplyEnabled
---------- ----------------
Contoso.com True
Ricerca dei messaggi persi
Gli amministratori possono verificare se un messaggio è bloccato eseguendo una traccia del messaggio utilizzando PowerShell o l’interfaccia grafica di tracciamento dei messaggi nel Centro conformità (Figura 1).
Dato il numero di messaggi che passano attraverso un tenant ogni giorno, è più facile trovare gli eventi di rilascio con PowerShell. Poiché il comando Get-MessageTrace può elaborare molte informazioni, è saggio limitare il periodo di tempo utilizzato per recuperare gli eventi dei messaggi il più possibile. Questo codice cerca i messaggi rifiutati per un periodo di due ore.
Get-MessageTrace -StartDate "11-Feb-2020 17:36" -EndDate "11-Feb-2020 19:37" | Get-MessageTraceDetail | ?{$_.Event -eq "Drop" -and $_.Data -Match "BlockAFToExternalUser"} | Select MessageID, Date, Event, Detail, Data
Usa una regola di flusso di posta
La semplicità e la immediatezza del blocco dell’inoltro automatico ai domini remoti sono allettanti, ma è uno strumento troppo generico. Un altro approccio consiste nel creare una regola di flusso di posta per intercettare i messaggi di tipo “Auto-forward” inviati a destinatari esterni con un’azione di rifiuto del messaggio e l’invio di una notifica di recapito al mittente con una motivazione adeguata. Ad esempio, “Il tuo messaggio è stato bloccato per garantire la riservatezza della proprietà intellettuale dell’organizzazione.”
In alternativa, potresti recapitare il messaggio inoltrato automaticamente alla sua destinazione prevista, ma solo dopo aver applicato un’etichetta di sensibilità restrictive al messaggio in modo che il destinatario non abbia il diritto di leggerlo. L’intenzione qui è far capire al destinatario che non dovrebbe cercare di visualizzare i contenuti della nostra organizzazione. Sperabilmente il destinatario si lamenterà con il mittente, il quale potrebbe rendersi conto di stare compiendo un’azione malvista dall’organizzazione.
Attenzione a Power Automate
Dopo aver eretto tutti questi ostacoli per impedire agli utenti di inoltrare i contenuti al di fuori dell’organizzazione, ci siamo scontrati con il problema che Power Automate ignora allegremente le restrizioni imposte dalle regole di flusso di posta, dai blocchi di dominio o dall’eliminazione degli indirizzi di inoltro automatico dalle caselle di posta. Questo problema è stato documentato da Vasil Michev qualche tempo fa, ma Microsoft non ha fatto nulla per migliorare la situazione.
Aggiornamento (settembre 2020): Power Automate ora inserisce x-headers nei messaggi che possono essere utilizzati per bloccare questo traffico utilizzando regole di trasporto.
Ad esempio, puoi creare un nuovo flusso per inoltrare messaggi quando nuovi elementi arrivano in una cartella utilizzando le template fornite da Microsoft. ho preso una template standard, la collegai alla mia posta, l’ho modificata per monitorare la cartella Archivio, e scelto di inviare copie a un indirizzo esterno (Figura 2).
Il risultato fu che ogni volta che Power Automate eseguiva il flusso, ogni nuovo messaggio messo nella cartella Archivio fu inoltrato all’indirizzo esterno. I messaggi appaiono nel log della tracciatura dei messaggi, ma sono come messaggi normali.
Theinsieme di eventi di audit catturati da Power Automate e integrate nel log di audit di Office 365 è piuttosto scadente e non si ottiene molta aiutonell’indagine da li. L’unico thing visibile nel log di audit è che l’utente ha creato un flusso utilizzando ilOpenApiConnectionconnectore.
Le etichette di sensibilità potrebbero essere la soluzione
Il filo conduttore comune è che i messaggi inoltrati automaticamente possono essere letti dal destinatario. Per fermare questo, dobbiamo impedire al destinatario di aprire e accedere al contenuto del messaggio, e l’unico modo per farlo è l’uso di messaggi protetti.
S/MIME is one approach, but sensitivity labels are a better long-term solution because Microsoft is investing heavily to increase the usefulness of these labels across Office 365. The simple fact is that only those authorized to open protected messages can access their content, so when the messages are forwarded by rules, autoforwarding addresses, or Power Automate, the external recipient won’t be able to read them.
Chiamata organizzazione
La decisione se gli utenti possono inoltrare email è una decisione che dovrebbe essere presa come parte della strategia di governance dei dati dell’organizzazione. È facile costruire barriere all’inoltro se decidete che la posta deve rimanere all’interno del tenant, ma se lo fate, ricordate di comunicare la politica agli utenti.