Cómo cifrar el correo electrónico en Microsoft 365 y Google Workspace

Exchange Online y Gmail utilizan Transport Layer Security (TLS) cuando intercambian correo con otro servidor que lo admite. TLS cifra la conexión, de modo que el mensaje no puede leerse mientras viaja entre esos dos servidores. Gmail muestra un candado rojo abierto cuando un mensaje no se ha protegido con TLS.

De forma predeterminada, TLS es oportunista: si el otro servidor no lo admite, el correo puede entregarse sin él, a menos que un administrador exija TLS para ese dominio. Y, lo que es más importante, TLS termina en cada servidor. El mensaje se almacena de forma legible en los buzones del remitente y del destinatario, en los sistemas de registro en diario y de archivado, y en cualquier servidor que lo retransmita. Nuestra comparación entre el cifrado de transporte y el cifrado de mensajes explica la diferencia.

Para la correspondencia habitual, TLS es una base razonable. Para contratos, registros sanitarios o financieros, asuntos jurídicos y otros datos personales, la mayoría de las organizaciones quieren una protección que acompañe al propio mensaje.

Microsoft Purview Message Encryption

Microsoft Purview Message Encryption, incluido en algunos planes de Microsoft 365, permite a los usuarios aplicar una opción de cifrado en Outlook, y a los administradores aplicarla automáticamente mediante reglas de flujo de correo. Los destinatarios ajenos a Microsoft 365 reciben un mensaje con un enlace y, a continuación, inician sesión o solicitan un código de acceso de un solo uso para leerlo en un navegador. Funciona bien para intercambios ocasionales con personas que no disponen de software de cifrado propio, pero utiliza un formato propio de Microsoft en lugar de PGP o S/MIME.

S/MIME en Outlook

Outlook admite S/MIME de forma nativa. Cada remitente necesita un certificado X.509 y una clave privada, y el certificado del destinatario debe estar disponible antes de poder cifrar un mensaje para él, normalmente a partir de un directorio o de un mensaje firmado anterior. Emitir y renovar certificados para cada usuario y dispositivo es el principal obstáculo; nuestra guía sobre la caducidad y renovación de los certificados S/MIME explica lo que esto supone a lo largo del tiempo.

PGP

Microsoft 365 no incluye compatibilidad integrada con OpenPGP. Los usuarios pueden instalar complementos de terceros, pero entonces las claves residen en dispositivos individuales y el cifrado depende de que cada usuario se acuerde de aplicarlo.

S/MIME alojado

Algunas ediciones de Google Workspace admiten S/MIME alojado. Los administradores lo activan y cargan los certificados de los usuarios, y Gmail cifra un mensaje cuando dispone del certificado del destinatario, normalmente después de recibir de este un mensaje firmado.

Cifrado del lado del cliente

El cifrado del lado del cliente de Gmail, disponible en determinadas ediciones Enterprise y Education, cifra el contenido de los mensajes en el navegador con claves guardadas en un servicio de claves externo que controla la organización. Es adecuado para organizaciones con requisitos estrictos de custodia de claves, pero exige configurar un proveedor de identidad y un servicio de claves, y los destinatarios externos necesitan una forma compatible de leer el mensaje.

El modo confidencial no es cifrado

El modo confidencial de Gmail puede desactivar las opciones de reenviar, copiar e imprimir, y establecer una fecha de caducidad. No cifra el mensaje para el destinatario con S/MIME ni con PGP, por lo que no debe confiarse en él para datos regulados. Al igual que Microsoft 365, Gmail no admite OpenPGP de forma nativa.

Las herramientas integradas están diseñadas en torno a los propios usuarios de cada plataforma. Las organizaciones suelen necesitar algo más cuando:

• los socios, los reguladores o los clientes exigen PGP, que ninguna de las dos plataformas ofrece;
• debe aplicarse la misma política en ambas plataformas, o en varios sistemas de correo tras una fusión;
• las claves y los certificados deben generarse, publicarse, buscarse y renovarse de forma centralizada, y no en cada dispositivo;
• los destinatarios sin PGP ni S/MIME necesitan alternativas, como un portal seguro o un PDF cifrado, elegidas mediante políticas.

En ese modelo, la plataforma de correo entrega los mensajes salientes a un servicio de cifrado en la nube mediante un conector de salida en Microsoft 365, o mediante una pasarela de salida o una regla de enrutamiento en Google Workspace. El servicio aplica la política, encuentra las claves y los certificados de los destinatarios y entrega el mensaje, mientras los usuarios siguen utilizando su cliente de correo habitual. Nuestra guía sobre la integración del cifrado de correo con Microsoft 365 y Google Workspace explica el enrutamiento, y nuestra página sobre cómo funciona el cifrado de correo electrónico en la nube recorre cada paso.

1. Clasifique lo que necesita protección. Identifique los tipos de mensajes, los destinatarios y las normativas que exigen cifrado a nivel de mensaje.
2. Enumere los requisitos de sus socios. Anote qué socios utilizan PGP, cuáles S/MIME y cuáles ninguno de los dos.
3. Imponga TLS donde sea posible. Exija TLS para los dominios de los socios importantes como medida básica.
4. Elija un método para cada grupo de destinatarios. Utilice las herramientas integradas cuando basten y enrute el resto a través de una pasarela que admita ambos estándares.
5. Haga una prueba piloto y luego amplíe. Empiece con un departamento o una regla, confirme la entrega y las respuestas con socios reales y, después, amplíe la política.

CloudPGP ofrece cifrado de correo electrónico PGP alojado en la nube y cifrado de correo electrónico S/MIME alojado en la nube detrás de Microsoft 365 y Google Workspace, de modo que ambos estándares pueden aplicarse mediante una política central sin complementos en los clientes.