L’inoltro automatico è negativo
Consentire agli utenti di inoltrare le proprie email al di fuori di Exchange Online è negativo, specialmente se non tengono una copia dei messaggi inoltrati nella propria casella di posta. Oltre a rimuovere le email dai controlli imposti dalle politiche di governance dei dati, si crea un rischio che le informazioni riservate viaggino al di fuori dell’organizzazione, incluso quando un attaccante entra nel sistema di posta elettronica e imposta l’inoltro senza il consenso del proprietario della casella di posta. Questo viene fatto per comprendere il traffico che l’utente hackerato riceve in preparazione per eseguire un attacco di compromissione dell’email aziendale.
In questa serie in due parti, prima esamino come limitare gli utenti di OWA dall’creare indirizzi di inoltro automatico utilizzando RBAC. Il secondo articolo descrive alcuni altri blocchi che si applicano a tutti i client per impedire la fuoriuscita di email dall’organizzazione.
Chi sta inoltrando automaticamente?
L’inoltro è una funzione del server, quindi una volta che un utente imposta un indirizzo di inoltro in OWA, qualsiasi email che arriva nella casella di posta viene inoltrata. Per scoprire se attualmente le email vengono inoltrate, eseguire il comando:
Get-Mailbox -RecipientTypeDetails UserMailbox -Filter {ForwardingSmtpAddress -ne $Null} -ResultSize Unlimited | Format-Table DisplayName, ForwardingSmtpAddress, DeliverToMailboxAndForward -AutoSize
DisplayName ForwardingSmtpAddress DeliverToMailboxAndForward
----------- --------------------- --------------------------
Vasil Michev (Technical Guru) smtp:[email protected] True
Ståle Hansen smtp:[email protected] True
Eoin Redmond smtp:[email protected]
Puoi prendere misure per resistere agli attacchi istruendo gli utenti, ma è meglio impedire la possibilità di inoltrare email. Possiamo farlo creando una nuova policy di assegnazione dei ruoli utente che non includa i parametri del cmdlet necessari a un utente per creare un inoltro automatico.
Come impostare un indirizzo di inoltro automatico
L’opzione OWA per il reindirizzamento automatico dei messaggi da Exchange Online (o locale) si trova nella sezione Posta delle Impostazioni OWA (Figura 1).
Dopo aver impostato un indirizzo di reindirizzamento automatico, OWA informa l’utente nel cosiddetto Manager Account OWA nella barra dei menu (Figura 2).
Controllo di accesso basato su ruoli e Exchange
Il nuovo OWA vanta un’interfaccia potenziata e il meccanismo Controllo di accesso basato su ruoli (RBAC) che è esistito sin dalla versione Exchange 2010, supporta quell’aspetto brillante, proprio come fa con il Centro di amministrazione di Exchange (EAC).
RBAC funziona consentendo l’accesso ai cmdlet di PowerShell e ai loro parametri. Se non è possibile eseguire un cmdlet o passare un valore in un parametro, si perde l’accesso a una funzione. La politica di assegnazione del ruolo applicata a una casella di posta è composta da un insieme di ruoli, ognuno dei quali controlla l’accesso a una o più funzioni. Client come OWA utilizzano RBAC per sapere quando una funzione è disponibile per un utente. Se la loro casella di posta è bloccata da una funzione perché la politica assegnata non include il giusto accesso, l’utente non visualizza la funzione. È un sistema semplice ed efficace. Almeno, lo è in teoria.
È possibile creare e assegnare le policy di assegnazione dei ruoli utente attraverso la sezione Permessi di EAC. L’interfaccia utente funziona bene se si desidera escludere una grande quantità di funzionalità come la capacità di selezionare tag di conservazione personalizzati. Non consente di ridurre le funzionalità in modo più mirato, ad esempio consentire alle persone di gestire elenchi di distribuzione di loro proprietà mentre si rimuove la capacità di creare nuovi elenchi. È necessario utilizzare PowerShell per apportare questo tipo di modifiche.
Crea un nuovo ruolo RBAC
RBAC per Exchange Online funziona basandosi sulla restrizione degli utenti per poter eseguire cmdlet fino al livello dei parametri. Gli amministratori possono eseguire tutti i cmdlet e tutti i parametri a causa dei ruoli che detengono. Gli utenti normali hanno un insieme più ristretto di assegnazioni di ruoli, quindi possono fare meno. Ad esempio, per configurare un indirizzo di autoforward in PowerShell, si esegue il cmdlet Set-Mailbox utilizzando un comando come:
Set-Mailbox -Identity Kim.Akers -ForwardingSmtpAddress [email protected] -DeliverToMailboxAndForward $True
Pertanto, per impedire agli utenti di creare un indirizzo di autoforward, è necessario rimuovere la capacità di eseguire il cmdlet Set-Mailbox con il parametro ForwardingSmtpAddress.
Il primo passo per implementare un blocco con RBAC è creare un nuovo ruolo di gestione utilizzando il ruolo esistente MyBaseOptions come modello. Ciò significa che tutte le opzioni supportate in MyBaseOptions, compresa la capacità di configurare un indirizzo di autoforward, vengono ereditate dal nuovo ruolo.
New-ManagementRole MyBaseOptions-NoForward -Parent MyBaseOptions
Disabilitazione dei parametri del cmdlet in un ruolo
Non vogliamo rimuovere tutti gli accessi a Set-Mailbox perché questo cmdlet viene utilizzato per gestire altre impostazioni come impostare una notifica di fuori sede, ma vogliamo disabilitare l’accesso ai parametri utilizzati nell’opzione OWA. Ecco come rimuovere i due parametri dal cmdlet nelle opzioni consentite nel nuovo ruolo di gestione.
Set-ManagementRoleEntry MyBaseOptions-NoForward\Set-Mailbox -RemoveParameter -Parameters DeliverToMailboxAndForward, ForwardingSmtpAddress
Creazione di una policy di assegnazione ruolo
Abbiamo ora un ruolo personalizzato e dobbiamo combinarlo con gli altri ruoli che gli utenti ricevono tipicamente in una policy di assegnazione ruolo utente per creare una nuova policy. Questo comando crea una nuova policy di assegnazione ruolo utente che combina i ruoli di base e il nostro ruolo personalizzato.
New-RoleAssignmentPolicy -Name PolicyWithNoEmailForward -Roles MyContactInformation, MyRetentionPolicies, MyMailSubscriptions, MyTextMessaging, MyVoiceMail, MyDistributionGroupMembership, MyDistributionGroups, MyProfileInformation, MyBaseOptions-NoForward -Description "User role assignment policy that restricts the assignees from being able to autoforward email outside the organization"
Nota: Se i ruoli di base sono stati aggiornati, tali modifiche vengono trasferite nella nuova policy. È possibile verificare le assegnazioni aprendo la policy in EAC (Figura 3).
L’approccio alternativo è aggiornare la policy di assegnazione ruolo utente predefinita tramite EAC in modo che assomigli alla Figura 3. Il downside è che tale modifica influenzerà ogni casella di posta a cui è assegnata la policy (spesso ogni casella di posta nell’organizzazione). Potresti non voler fare questo, ecco perché una nuova policy potrebbe essere la scelta migliore.
Applicare la nuova policy di assegnazione ruolo utente
Le policy di assegnazione ruolo utente vengono applicate alle caselle di posta eseguendo il cmdlet Set-Mailbox. Qui assegniamo la policy a una casella di posta.
Set-Mailbox -Identity James.Ryan -RoleAssignmentPolicy PolicyWithNoEmailForward
Ci vuole un po’ prima che la nuova policy sia effettiva. Quando lo sarà, l’utente non potrà impostare un indirizzo di inoltro poiché OWA noterà che la policy non include i parametri del cmdlet necessari e soffocherà l’interfaccia utente (Figura 4).
PowerShell facilita l’assegnazione di policy a un grande numero di caselle di posta in una sola volta. Qui troviamo insieme le caselle di posta che hanno un indirizzo di autoforward e assegnamo loro la nuova policy. Allo stesso tempo, rimuoviamo l’indirizzo di autoforward esistente per impedire che altri messaggi fuoriescano dall’organizzazione. Questo è un passaggio importante perché l’assegnazione della policy disabilita la possibilità di impostare nuovi forward. Non fa nulla per rimuovere eventuali indirizzi di forwarding esistenti.
Get-Mailbox -RecipientTypeDetails UserMailbox -Filter {ForwardingSmtpAddress -ne $Null} |
Set-Mailbox -RoleAssignmentPolicy "PolicyWithNoEmailForward" -ForwardingSmtpAddress $Null -DeliverToMailboxAndForward $False
A questo punto, sarebbe probabilmente una buona idea inviare una nota gentile ai proprietari delle caselle di posta interessate per comunicare loro la buona notizia che le email rimarranno all’interno dell’organizzazione.
Come controllo finale, per scoprire quali caselle di posta hanno la nostra nuova policy, eseguire:
Get-mailbox -RecipientTypeDetails UserMailbox | ?{$_.RoleAssignmentPolicy -eq "PolicyWithNoEmailForward"} | Format-Table DisplayName, RoleAssignmentPolicy
DisplayName RoleAssignmentPolicy
----------- --------------------
Kim Akers PolicyWithNoEmailForward
Vasil Michev PolicyWithNoEmailForward
Ståle Hansen PolicyWithNoEmailForward
Eoin Redmond PolicyWithNoEmailForward
Se necessario, un amministratore può reimpostare l’autoforward sulla casella di posta eseguendo Set-Mailbox (esempio qui sotto) o aggiornando la casella di posta tramite EAC. RBAC non si applica in questi contesti amministrativi.
Set-Mailbox -Identity Kim.Akers -ForwardingSmtpAddress [email protected] -DeliverToMailboxAndForward $True
Parte Uno della Soluzione
Bloccare agli utenti di OWA la creazione di indirizzi di autoforwarding è un buon primo passo per impedire il forward automatico dei messaggi al di fuori dell’organizzazione. Tuttavia, è solo il primo passo. Altri client e applicazioni hanno i propri modi per automatizzare il forwarding, quindi è importante affrontare il problema in modo coerente.
Il passo successivo è considerare quali altre barriere possono essere erette per fermare il reindirizzamento automatico. Questo è presente nell’articolo 2 di questa serie.
Source:
https://petri.com/stop-owa-users-autoforwarding-email/