L’auto-transfert est mauvais.
Permettre aux utilisateurs de transférer leurs e-mails en dehors d’Exchange Online est mauvais, en particulier s’ils ne conservent pas une copie des messages transférés dans leur boîte aux lettres. En plus de retirer les e-mails des contrôles imposés par les politiques de gouvernance des données, cela crée un risque que des informations confidentielles circulent en dehors de l’organisation, notamment lorsque qu’un attaquant pirate une boîte aux lettres et configure le transfert sans le consentement du propriétaire de la boîte aux lettres. Cela est fait pour comprendre le trafic reçu par l’utilisateur piraté en vue de lancer une attaque de compromission par e-mail commercial.
Dans cette série en deux parties, je vais d’abord expliquer comment restreindre les utilisateurs d’OWA à créer des adresses d’auto-transfert en utilisant le RBAC. Le deuxième article décrit d’autres blocages applicables à tous les clients pour empêcher les fuites d’e-mails de l’organisation.
Qui fait de l’Auto-transfert ?
Le transfert est une fonction du serveur, donc une fois qu’un utilisateur configure une adresse de transfert dans OWA, tout e-mail entrant dans la boîte aux lettres est transféré. Pour vérifier si le courrier est actuellement transféré, exécutez la commande :
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]
Vous pouvez prendre des mesures pour résister aux attaques en formant les utilisateurs, mais il est préférable de couper la possibilité de transférer les e-mails. Nous pouvons le faire en créant une nouvelle stratégie d’attribution de rôle utilisateur qui n’inclut pas les paramètres de cmdlet nécessaires à un utilisateur pour créer un auto-transfert.
Comment Configurer une Adresse d’Auto-transfert
L’option OWA pour transférer automatiquement les messages depuis Exchange Online (ou sur site) se trouve dans la section Courrier des Paramètres OWA (Figure 1).
Une fois une adresse de transfert automatique configurée, OWA informe l’utilisateur dans ce qu’on appelle maintenant le Gestionnaire de Compte OWA dans la barre de menus (Figure 2).
Contrôle d’Accès Basé sur les Rôles et Exchange
Le nouveau OWA vante une interface améliorée, et le mécanisme de Contrôle d’Accès Basé sur les Rôles (RBAC) qui existe depuis Exchange 2010 soutient cette nouvelle apparence étincelante, tout comme il le fait pour le Centre d’Administration Exchange (EAC).
RBAC fonctionne en permettant l’accès aux cmdlets PowerShell et à leurs paramètres. Si vous ne pouvez pas exécuter un cmdlet ou transmettre une valeur dans un paramètre, vous perdez l’accès à une fonctionnalité. La stratégie d’attribution de rôle appliquée à une boîte aux lettres est composée d’un ensemble de rôles, chacun contrôlant l’accès à une ou plusieurs fonctionnalités. Des clients comme OWA utilisent RBAC pour savoir quand une fonctionnalité est disponible pour un utilisateur. Si leur boîte aux lettres est bloquée pour une fonctionnalité car la politique assignée n’inclut pas le bon accès, l’utilisateur ne voit pas la fonctionnalité. C’est un système simple et efficace. Du moins, en théorie.
Vous pouvez créer et attribuer des stratégies d’attribution de rôle utilisateur à travers la section Autorisations de l’EAC. L’interface utilisateur fonctionne bien si vous voulez exclure une grande partie des fonctionnalités comme la possibilité de sélectionner des étiquettes de rétention personnelles. Elle ne vous permet pas de restreindre les fonctionnalités de manière plus chirurgicale, comme autoriser les personnes à gérer les listes de distribution qu’elles possèdent tout en supprimant la possibilité de créer de nouvelles listes. PowerShell doit être utilisé pour effectuer ce type de modifications.
Créer un nouveau rôle RBAC
RBAC pour Exchange Online fonctionne en restreignant les utilisateurs à pouvoir exécuter des cmdlets jusqu’au niveau des paramètres. Les administrateurs peuvent exécuter tous les cmdlets et tous les paramètres en raison des rôles qu’ils détiennent. Les utilisateurs normaux ont un ensemble de rôles attribués plus restreint, donc ils peuvent faire moins. Par exemple, pour configurer une adresse de transfert automatique en PowerShell, vous exécutez le cmdlet Set-Mailbox en utilisant une commande comme suit :
Set-Mailbox -Identity Kim.Akers -ForwardingSmtpAddress [email protected] -DeliverToMailboxAndForward $True
Par conséquent, pour empêcher les utilisateurs de créer une adresse de transfert automatique, nous devons supprimer la capacité d’exécuter le cmdlet Set-Mailbox avec le paramètre ForwardingSmtppAddress.
La première étape pour mettre en place un bloc avec RBAC est de créer un nouveau rôle de gestion en utilisant le rôle existant MyBaseOptions comme modèle. Cela signifie que toutes les options prises en charge dans MyBaseOptions, y compris la capacité de configurer une adresse de transfert automatique, sont héritées par le nouveau rôle.
New-ManagementRole MyBaseOptions-NoForward -Parent MyBaseOptions
Désactiver les paramètres de cmdlet dans un rôle
Nous ne voulons pas supprimer tout l’accès à Set-Mailbox car ce cmdlet est utilisé pour gérer d’autres paramètres comme la définition d’une notification d’absence, mais nous voulons désactiver l’accès aux paramètres utilisés dans l’option OWA. Voici comment supprimer les deux paramètres du cmdlet dans les options autorisées dans le nouveau rôle de gestion.
Set-ManagementRoleEntry MyBaseOptions-NoForward\Set-Mailbox -RemoveParameter -Parameters DeliverToMailboxAndForward, ForwardingSmtpAddress
Création d’une stratégie d’attribution de rôle
Nous avons maintenant un rôle personnalisé et devons le combiner avec les autres rôles que les utilisateurs reçoivent généralement dans une stratégie d’attribution de rôle utilisateur pour créer une nouvelle stratégie. Cette commande crée une nouvelle stratégie d’attribution de rôle utilisateur qui combine les rôles de base et notre rôle personnalisé.
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"
Remarque : Si les rôles de base ont été mis à jour, ces modifications sont reportées dans la nouvelle stratégie. Vous pouvez vérifier les attributions en ouvrant la stratégie dans l’EAC (Figure 3).
L’approche alternative consiste à mettre à jour la stratégie d’attribution de rôle utilisateur par défaut via l’EAC pour qu’elle ressemble à la Figure 3. L’inconvénient est qu’un tel changement affectera chaque boîte aux lettres à laquelle la stratégie est assignée (souvent chaque boîte aux lettres dans l’organisation). Vous ne voudrez peut-être pas le faire, c’est pourquoi une nouvelle stratégie pourrait être la meilleure option.
Application de la nouvelle stratégie d’attribution de rôle utilisateur
Les stratégies d’attribution de rôle utilisateur sont appliquées aux boîtes aux lettres en exécutant le Set-Mailbox cmdlet. Ici, nous attribuons la stratégie à une boîte aux lettres.
Set-Mailbox -Identity James.Ryan -RoleAssignmentPolicy PolicyWithNoEmailForward
Il faut un peu de temps avant que la nouvelle stratégie soit effective. Lorsque c’est le cas, l’utilisateur ne pourra pas définir une adresse de réacheminement car OWA notera que la stratégie ne comprend pas les paramètres de cmdlet nécessaires et supprimera l’interface utilisateur (Figure 4).
PowerShell facilite l’attribution de politiques à un grand nombre de boîtes aux lettres en une seule fois. Ici, nous trouvons l’ensemble des boîtes aux lettres ayant une adresse d’auto-transfert et leur attribuons la nouvelle politique. En même temps, nous supprimons l’adresse d’auto-transfert existante pour empêcher tout autre message de circuler en dehors de l’organisation. Il s’agit d’une étape importante car l’attribution de la politique désactive la capacité de définir de nouveaux transferts. Cela ne supprime pas les adresses de transfert existantes.
Get-Mailbox -RecipientTypeDetails UserMailbox -Filter {ForwardingSmtpAddress -ne $Null} |
Set-Mailbox -RoleAssignmentPolicy "PolicyWithNoEmailForward" -ForwardingSmtpAddress $Null -DeliverToMailboxAndForward $False
À ce stade, il serait probablement judicieux d’envoyer une note polie aux propriétaires des boîtes aux lettres concernées pour leur annoncer la bonne nouvelle que les e-mails resteront à l’intérieur de l’organisation.
En guise de dernière vérification, pour découvrir quelles boîtes aux lettres ont notre nouvelle politique, exécutez :
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
Si nécessaire, un administrateur peut réinitialiser l’auto-transfert sur la boîte aux lettres en exécutant Set-Mailbox (exemple ci-dessous) ou en mettant à jour la boîte aux lettres via EAC. Les autorisations basées sur les rôles (RBAC) ne s’appliquent pas dans ces contextes administratifs.
Set-Mailbox -Identity Kim.Akers -ForwardingSmtpAddress [email protected] -DeliverToMailboxAndForward $True
Partie Un de la Solution
Empêcher les utilisateurs d’OWA de créer des adresses d’auto-transfert est une bonne première étape pour empêcher le transfert automatique des messages en dehors de l’organisation. Cependant, c’est seulement la première étape. D’autres clients et applications ont leurs propres moyens d’automatiser le transfert, il est donc important d’adopter une approche cohérente du problème.
La prochaine étape consiste à envisager quels autres obstacles peuvent être érigés pour arrêter la redirection automatique. C’est dans l’article 2 de cette série.
Source:
https://petri.com/stop-owa-users-autoforwarding-email/