Comment chiffrer les e-mails dans Microsoft 365 et Google Workspace

Exchange Online et Gmail utilisent tous deux le protocole TLS (Transport Layer Security) lorsqu’ils échangent du courrier avec un autre serveur qui le prend en charge. TLS chiffre la connexion, de sorte que le message ne peut pas être lu pendant son transit entre ces deux serveurs. Gmail affiche un cadenas rouge ouvert lorsqu’un message n’a pas été protégé par TLS.

Par défaut, TLS est opportuniste : si l’autre serveur ne le prend pas en charge, le courrier peut être remis sans TLS, à moins qu’un administrateur ne l’exige pour ce domaine. Surtout, TLS s’arrête à chaque serveur. Le message est stocké sous une forme lisible dans les boîtes aux lettres de l’expéditeur et du destinataire, dans les systèmes de journalisation et d’archivage, ainsi que sur tout serveur qui le relaie. Notre comparaison entre chiffrement du transport et chiffrement du message explique la différence.

Pour la correspondance courante, TLS constitue un socle raisonnable. Pour les contrats, les dossiers médicaux ou financiers, les affaires juridiques et d’autres données à caractère personnel, la plupart des organisations souhaitent une protection qui accompagne le message lui-même.

Microsoft Purview Message Encryption

Inclus dans certains abonnements Microsoft 365, Microsoft Purview Message Encryption permet aux utilisateurs d’appliquer une option de chiffrement dans Outlook, et aux administrateurs de l’appliquer automatiquement au moyen de règles de flux de messagerie. Les destinataires extérieurs à Microsoft 365 reçoivent un message contenant un lien, puis se connectent ou demandent un code secret à usage unique pour le lire dans un navigateur. Ce service convient bien aux échanges occasionnels avec des personnes qui ne disposent d’aucun logiciel de chiffrement, mais il utilise le format propre à Microsoft plutôt que PGP ou S/MIME.

S/MIME dans Outlook

Outlook prend en charge S/MIME nativement. Chaque expéditeur a besoin d’un certificat X.509 et d’une clé privée, et le certificat du destinataire doit être disponible avant qu’un message puisse être chiffré à son intention, généralement à partir d’un annuaire ou d’un message signé reçu auparavant. L’émission et le renouvellement des certificats pour chaque utilisateur et chaque appareil constituent le principal obstacle ; notre guide sur l’expiration et le renouvellement des certificats S/MIME explique ce que cela implique dans la durée.

PGP

Microsoft 365 ne prend pas en charge OpenPGP de manière intégrée. Les utilisateurs peuvent installer des compléments tiers, mais les clés résident alors sur chaque appareil, et le chiffrement dépend de chaque utilisateur, qui doit penser à l’appliquer.

S/MIME hébergé

Certaines éditions de Google Workspace prennent en charge S/MIME hébergé. Les administrateurs l’activent et importent les certificats des utilisateurs, et Gmail chiffre un message lorsqu’il dispose du certificat du destinataire, généralement après avoir reçu de sa part un message signé.

Chiffrement côté client

Le chiffrement côté client de Gmail, disponible dans certaines éditions Enterprise et Education, chiffre le contenu des messages dans le navigateur à l’aide de clés conservées dans un service de clés externe contrôlé par l’organisation. Il convient aux organisations soumises à des exigences strictes en matière de garde des clés, mais il nécessite la configuration d’un fournisseur d’identité et d’un service de clés, et les destinataires externes doivent disposer d’un moyen compatible pour lire le message.

Le mode confidentiel n’est pas un chiffrement

Le mode confidentiel de Gmail permet de désactiver le transfert, la copie et l’impression, et de définir une date d’expiration. Il ne chiffre pas le message à l’intention du destinataire avec S/MIME ou PGP ; il ne faut donc pas s’y fier pour des données réglementées. Comme Microsoft 365, Gmail ne prend pas en charge OpenPGP nativement.

Les outils intégrés sont conçus pour les propres utilisateurs de chaque plateforme. Les organisations ont tendance à en atteindre les limites lorsque :

• des partenaires, des autorités de régulation ou des clients exigent PGP, qu’aucune des deux plateformes ne fournit ;
• la même politique doit s’appliquer aux deux plateformes, ou à plusieurs systèmes de messagerie après une fusion ;
• les clés et les certificats doivent être générés, publiés, recherchés et renouvelés de manière centralisée plutôt que sur chaque appareil ;
• les destinataires sans PGP ni S/MIME ont besoin d’alternatives, comme un portail sécurisé ou un PDF chiffré, choisies en fonction de la politique.

Dans ce modèle, la plateforme de messagerie transmet les messages sortants à un service de chiffrement cloud au moyen d’un connecteur sortant dans Microsoft 365, ou d’une passerelle sortante ou d’une règle de routage dans Google Workspace. Le service applique la politique, trouve les clés et les certificats des destinataires et remet le message, tandis que les utilisateurs conservent leur client de messagerie habituel. Notre guide sur l’intégration du chiffrement des e-mails avec Microsoft 365 et Google Workspace décrit le routage, et notre page consacrée au fonctionnement du chiffrement des e-mails dans le cloud en détaille chaque étape.

1. Classez ce qui doit être protégé. Identifiez les types de messages, les destinataires et les réglementations qui exigent un chiffrement au niveau du message.
2. Recensez les exigences des partenaires. Notez quels partenaires utilisent PGP, lesquels utilisent S/MIME et lesquels n’utilisent ni l’un ni l’autre.
3. Imposez TLS lorsque c’est possible. Exigez TLS pour les domaines de vos partenaires importants, à titre de socle.
4. Choisissez une méthode par public. Utilisez les outils intégrés lorsqu’ils suffisent, et acheminez le reste via une passerelle qui prend en charge les deux normes.
5. Lancez un pilote, puis étendez. Commencez par un département ou une règle, vérifiez la remise et les réponses avec de vrais partenaires, puis élargissez la politique.

CloudPGP fournit un chiffrement PGP des e-mails hébergé dans le cloud et un chiffrement S/MIME des e-mails hébergé dans le cloud en aval de Microsoft 365 et de Google Workspace, afin que les deux normes puissent être appliquées par une politique centrale, sans complément à installer dans les clients de messagerie.