El primer artículo de esta serie discutió cómo eliminar la capacidad de los usuarios de OWA de crear direcciones de reenvío automático. Esto hace mucho para detener el reenvío de correos electrónicos fuera de una organización, pero OWA es solo una parte del problema. También necesitamos abordar las otras formas en que los mensajes pueden reenviarse automáticamente a direcciones externas.
Por ejemplo, las reglas de Outlook pueden reenviar mensajes. Es posible usar PowerShell para escanear cada buzón en busca de reglas de reenvío, pero eso podría requerir mucho procesamiento que tendríamos que hacer de manera continua. Consideremos algunos métodos más sólidos para bloquear el reenvío automático saliente.
Bloqueo por Dominios
El bloqueo por dominio es un método efectivo para detener los mensajes autoforwarded. El bloqueo se implementa utilizando el cmdlet Set-RemoteDomain (o, en EAC, editando la configuración de dominio remoto en Mail Flow). Este comando detiene el autoforwarding de correos electrónicos a cualquier dominio, excepto cuando existen configuraciones explícitas para permitir el reenvío a un dominio.
Set-RemoteDomain -Identity Default -AutoForwardEnabled $False
Para verificar si algún dominio permite el autoforwarding, ejecute este comando:
Get-RemoteDomain |?{$_.AutoForwardEnabled -eq $True}| Format-Table DomainName, AutoReplyEnabled
DomainName AutoReplyEnabled
---------- ----------------
Contoso.com True
Encontrar Mensajes Descartados
Los administradores pueden ver si un mensaje está bloqueado ejecutando un rastreo de mensajes usando PowerShell o la GUI de Rastreo de Mensajes en el Centro de Cumplimiento (Figura 1).
Dado el número de mensajes que pasan por un inquilino diariamente, es más fácil encontrar los eventos de caída con PowerShell. Debido a que el comando Get-MessageTrace puede procesar una gran cantidad de datos, es sabio restringir el período de tiempo utilizado para recuperar eventos de mensajes a un período tan limitado como sea posible. Este código busca mensajes caídos durante un período de dos horas.
Get-MessageTrace -StartDate "11-Feb-2020 17:36" -EndDate "11-Feb-2020 19:37" | Get-MessageTraceDetail | ?{$_.Event -eq "Drop" -and $_.Data -Match "BlockAFToExternalUser"} | Select MessageID, Date, Event, Detail, Data
Usar una regla de flujo de correo
La simplicidad y la franqueza de bloquear el reenvío automático a dominios remotos es atractiva, pero es un instrumento contundente. Otro enfoque es crear una regla de flujo de correo para interceptar mensajes de tipo “Reenvío automático” enviados a destinatarios externos con una acción para rechazar el mensaje y devolver una notificación de entrega al remitente con un motivo adecuado. Por ejemplo, “Su mensaje fue bloqueado para garantizar la confidencialidad de la propiedad intelectual de la organización“.
Alternativamente, podrías entregar el mensaje reenviado automáticamente a su destino previsto, pero solo después de aplicar una etiqueta de sensibilidad restrictiva al mensaje para que el destinatario no tenga derecho a leerlo. La intención aquí es dejar claro al destinatario que no debería intentar ver contenido de nuestra organización. Con suerte, el destinatario informará su molestia al remitente, quien tal vez se dé cuenta de que está haciendo algo mal visto por la organización.
Cuidado con Power Automate
Después de erigir todas estas barreras para evitar que los usuarios reenvíen contenido fuera de la organización, nos encontramos con el problema de que Power Automate ignora alegremente cualquier restricción impuesta por las reglas de flujo de correo, bloqueos de dominio o eliminación de direcciones de reenvío automático de buzones. Este problema fue documentado por Vasil Michev hace algún tiempo, pero Microsoft no ha hecho nada para mejorar la situación.
Actualización (septiembre de 2020): Power Automate ahora inserta encabezados x en los mensajes que se pueden utilizar para detener este tráfico mediante reglas de transporte.
Por ejemplo, puedes crear un nuevo flujo para reenviar mensajes cuando lleguen nuevos elementos a la carpeta utilizando plantillas proporcionadas por Microsoft. Tomé una plantilla estándar, la conecté a mi buzón, la modifiqué para monitorear la carpeta de Archivo, y opté por enviar copias a una dirección externa (Figura 2).
El resultado fue que cada vez que Power Automate ejecutaba el flujo, cualquier nuevo mensaje colocado en la carpeta de Archivo era reenviado a la dirección externa. Los mensajes aparecen en el registro de seguimiento de mensajes pero lucen como mensajes normales.
El conjunto de eventos de auditoría capturados por Power Automate y ingeridos en el registro de auditoría de Office 365 es bastante pobre y no se obtiene mucha ayuda al investigar allí. Lo único que se ve en el registro de auditoría es que el usuario creó un flujo usando el conector OpenApiConnection.
Las Etiquetas de Sensibilidad Podrían Ser la Solución
El hilo común es que los mensajes reenviados automáticamente pueden ser leídos por el destinatario. Para detener esto, necesitamos evitar que el destinatario pueda abrir y acceder al contenido del mensaje, y la única manera de hacerlo es usando mensajes protegidos.
S/MIME is one approach, but sensitivity labels are a better long-term solution because Microsoft is investing heavily to increase the usefulness of these labels across Office 365. The simple fact is that only those authorized to open protected messages can access their content, so when the messages are forwarded by rules, autoforwarding addresses, or Power Automate, the external recipient won’t be able to read them.
Llamada a la Organización
Decidir si los usuarios pueden reenviar automáticamente correos electrónicos es una decisión que debería tomarse como parte de la estrategia de gobierno de datos de la organización. Es fácil erigir barreras para el reenvío automático si decides que el correo electrónico debe permanecer dentro del inquilino, pero si lo haces, recuerda comunicar la política a los usuarios.