Cryptage pour les autosignatures d’Exchange Online
Lorsque j’ai écrit sur l’effet du chiffrement sur les produits d’autosignature ISV, j’ai fait remarquer que le service de transport Exchange peut appliquer des autosignatures (texte d’avertissement) aux messages sortants avec une règle même si les messages sont chiffrés. Cela s’explique par le fait qu’Exchange utilise les autorisations des super-utilisateurs de la gestion des droits pour décrypter les messages, appliquer la clause de non-responsabilité, puis les crypter à nouveau pour la livraison finale. Les questions affluent pour savoir s’il est facile de créer une règle de transport pour appliquer une autosignature comme celles générées par les produits ISV. La réponse est que c’est possible, mais cela demande un certain effort, surtout si vous voulez utiliser un texte HTML bien formaté dans la signature automatique. L’interface utilisateur du centre d’administration d’Exchange permettant de créer et de gérer les règles de transport n’est pas très conviviale lorsqu’il s’agit d’insérer du texte formaté complexe. Cependant, avec de la persévérance, il est possible de créer des autosignatures joliment formatées. En dehors de la difficulté de modifier le texte utilisé dans les autosignatures appliquées par les règles de transport, la plainte la plus courante est que les règles tamponnent tous les messages, y compris les réponses, de sorte que vous vous retrouvez avec plusieurs autosignatures dans un fil de courrier. C’est vrai, mais il est facile d’intégrer une exception dans la règle pour que l’autosignature ne soit appliquée qu’une seule fois.
Une fois que vous avez construit une règle de transport pour appliquer une autosignature, vous pouvez la combiner avec d’autres règles pour protéger les messages envoyés à toutes ou certaines destinations en appliquant un modèle de gestion des droits, y compris les modèles spéciaux Encrypt-Only ou Do Not Forward.
Un exemple de courriel chiffré
Un exemple est toujours utile. La capture d’écran ci-dessous montre un message protégé reçu par un utilisateur d’Outlook.com. Le message a une autosignature appliquée par une règle de transport. Le texte de l’autosignature est inséré dans le contenu du message, même si le message est protégé. Certains éléments Azure Active Directory (comme le prénom, le nom, le numéro de téléphone, etc.) sont utilisés dans la signature automatique. Le numéro de téléphone est vide, ce qui signifie qu’il n’a pas été renseigné pour l’utilisateur. Les extraits pertinents de la règle de transport (en utilisant Get-TransportRule) sont présentés ci-dessous.
Except If Subject Or Body Contains Words : {Ce message est la propriété de Redmond and Associates}. Apply Html Disclaimer Location : Append Apply Html Disclaimer Fallback Action : envelopper Apply Html DisclaimerText : Ce message est la propriété de Redmond and Associates Si vous recevez ce message par erreur, veuillez le supprimer immédiatement et nous informer au +353 1 991 17463 de sa délivrance. %%FirstName%% %%Last Name%% Téléphone : %%Numéro de téléphone%% Email : %%Email%% L’exception dans Except lf Subject Or Body Contains Words est importante, car elle empêche l’insertion de l’autosignature dans les réponses.
Pourquoi utiliser des produits d’autosignature tiers ?
S’il est relativement simple d’utiliser une règle de transport pour insérer des autosignatures, y compris pour les emails protégés, pourquoi les gens achètent et utilisent des produits d’autosignature tiers ? Les principales raisons sont la flexibilité et la facilité d’utilisation. Les produits tiers permettent de créer et de déployer beaucoup plus facilement des signatures automatiques attrayantes pour des groupes d’utilisateurs ciblés (ou pour l’ensemble de l’entreprise) sans avoir à se débattre avec l’interface utilisateur du centre d’administration Exchange ou avec PowerShell. Autant j’aime PowerShell, autant l’utiliser pour éditer du HTML n’est pas une expérience gratifiante. Les organisations qui ont besoin de modifier fréquemment les autosignatures (par exemple, pour annoncer des événements) ou de déployer une gamme d’autosignatures différentes pour différents groupes au sein de l’entreprise trouveront plus facile d’utiliser des produits d’autosignature spécialisés. L’inconvénient, comme je l’ai souligné dans l’article de Petri.com, est que le traitement côté serveur par ces produits ne peut pas traiter les messages protégés. Un add-in côté client doit injecter l’autosignature dans un message avant que le chiffrement ne soit appliqué par le client.
