Pourquoi les organisations migrent leur chiffrement PGP et S/MIME vers le cloud

De nombreux déploiements PGP et S/MIME ont été construits il y a des années autour d’un serveur passerelle dédié installé dans le centre de données. Une fois en production, ce serveur devient une infrastructure dont l’entreprise dépend, mais que peu de personnes comprennent. Le maintenir en bon état implique :

• Les correctifs et les mises à niveau du système d’exploitation, du logiciel de chiffrement et de ses dépendances, souvent planifiés autour d’interruptions de la messagerie.
• La disponibilité : une passerelle unique constitue un point de défaillance unique pour le courrier sortant ; la résilience suppose donc une mise en cluster, un équilibrage de charge et un basculement testé.
• La garde des clés et des certificats : les clés privées nécessitent un stockage sécurisé, des sauvegardes et une procédure de récupération, parfois sur des modules de sécurité matériels.
• L’intégration aux annuaires : les recherches LDAP et la publication des clés doivent continuer de fonctionner au fil de l’évolution des annuaires, des domaines et des partenaires.
• La planification des capacités : la croissance du volume de courrier ou de la taille des pièces jointes oblige à acheter et à installer du matériel avant que la demande n’augmente.
• Les compétences spécialisées : lorsque l’ingénieur qui a construit le système s’en va, les modifications courantes deviennent risquées.

Aucune de ces tâches ne distingue l’organisation de ses concurrents. Elles servent simplement à assurer la circulation du courrier chiffré, et elles mobilisent les mêmes équipes que celles qui maintiennent tout le reste.

Moins d’infrastructure à maintenir

Le fournisseur exploite, met à jour et dimensionne le moteur de chiffrement. Les équipes internes gèrent le routage de la messagerie et la politique de chiffrement, plutôt que des serveurs, des systèmes d’exploitation et des clusters.

Une politique unique pour PGP et S/MIME

Un service qui gère les deux normes peut appliquer des règles par destinataire, par domaine ou selon le contenu, et choisir automatiquement PGP, S/MIME ou une autre méthode de remise. Les utilisateurs n’ont pas à décider comment chiffrer chaque message, ce qui élimine une source d’erreurs fréquente.

Un cycle de vie centralisé des clés et des certificats

Les clés des expéditeurs, la recherche des clés et certificats des destinataires et le renouvellement des certificats peuvent être gérés de manière centralisée plutôt qu’appareil par appareil. La gestion centralisée des clés PGP et S/MIME décrit les contrôles concernés, y compris les options de clés gérées par le client.

Des options pour les destinataires sans PGP ni S/MIME

Lorsqu’un destinataire ne dispose ni de clé ni de certificat, la politique peut prévoir la remise du message via un portail sécurisé ou sous la forme d’un document chiffré, au lieu de l’envoyer sans protection ou de le renvoyer à l’expéditeur.

Des preuves d’audit plus claires

La journalisation centralisée des décisions de chiffrement, de la génération des clés et des états de remise permet de montrer plus facilement aux auditeurs quels messages ont été protégés, et de quelle manière.

Compatible avec votre plateforme de messagerie actuelle

Microsoft 365, Google Workspace et les passerelles de messagerie sécurisées peuvent acheminer le courrier vers le service au moyen de connecteurs SMTP standard : les utilisateurs conservent donc Outlook ou Gmail. Pour les options propres à chaque plateforme, consultez notre guide expliquant comment chiffrer les e-mails dans Microsoft 365 et Google Workspace.

Passer au cloud ne modifie pas la cryptographie sur laquelle s’appuient vos partenaires. Un partenaire PGP a toujours besoin de votre clé publique, et vous avez toujours besoin de la sienne ; un partenaire S/MIME valide toujours votre certificat par rapport à une autorité de certification de confiance. Le chiffrement PGP des e-mails hébergé dans le cloud et le chiffrement S/MIME des e-mails hébergé dans le cloud reposent sur les mêmes normes ouvertes que les produits sur site.

L’expérience de vos utilisateurs change à peine, elle aussi : ils continuent de rédiger et de lire leurs e-mails comme avant, et la politique détermine quand le chiffrement s’applique.

La responsabilité ne se déplace pas non plus. Votre organisation décide toujours de ce qui doit être chiffré, de qui peut détenir des clés et de la durée de conservation des enregistrements. Un fournisseur met à disposition des contrôles et les exploite ; il ne rend pas, à lui seul, une organisation conforme.

Un service cloud n’est pas la bonne réponse pour toutes les organisations. Rester sur site, ou opter pour un modèle hybride, peut se justifier lorsque :

• la loi, un contrat ou une politique interne exige que les clés et le traitement des messages restent dans vos propres installations ;
• le système de messagerie est isolé d’Internet ;
• un investissement récent dans du matériel sur site a encore plusieurs années de vie utile devant lui, et l’équipe nécessaire à son exploitation est en place.

Même dans ce cas, il est utile d’examiner l’effort annuel total que représente l’exploitation du système. Les options de clés gérées par le client d’un service cloud peuvent répondre à de nombreuses exigences de garde des clés sans qu’il soit nécessaire de conserver les serveurs.

1. Faites l’inventaire. Recensez chaque domaine d’envoi, règle de chiffrement, paire de clés PGP, certificat S/MIME, partenaire et annuaire utilisé par le système actuel.
2. Décidez de ce qui sera migré. Choisissez les clés et certificats à importer et ceux à remplacer. L’importation préserve la confiance établie avec les partenaires ; le remplacement est l’occasion de retirer du matériel cryptographique faible ou proche de l’expiration.
3. Préservez les archives. Conservez les anciennes clés privées, de manière sécurisée, aussi longtemps que les messages chiffrés doivent rester lisibles.
4. Faites fonctionner les deux systèmes en parallèle. Acheminez un domaine, un département ou un groupe de partenaires via le nouveau service pendant que l’ancienne passerelle traite le reste.
5. Testez avec de vrais partenaires. Vérifiez le chiffrement, le déchiffrement, les signatures et les réponses dans les deux sens avant d’élargir le périmètre.
6. Basculez, puis mettez hors service. Transférez les routes restantes, puis retirez les anciens serveurs et éliminez leurs clés conformément à votre politique de conservation.

La section de notre page Cloud PGP consacrée à la migration depuis une solution PGP sur site et nos options de migration et de portabilité des clés détaillent les aspects techniques du transfert des clés.

• Où le courrier est-il traité, et où les clés sont-elles stockées ?
• Pouvons-nous importer nos propres clés, et les exporter si nous partons ?
• Quelles autorités de certification et quels annuaires sont pris en charge ?
• Quels journaux et rapports sont disponibles pour les audits ?
• Quelles alternatives de remise existent pour les destinataires sans PGP ni S/MIME ?
• Comment les destinataires sont-ils authentifiés lorsqu’ils utilisent un portail ?

Notre présentation des contrôles de sécurité du chiffrement des e-mails dans le cloud montre comment CloudPGP aborde plusieurs de ces questions, notamment où s’arrêtent ses responsabilités et où commencent les vôtres.