O primeiro artigo desta série discutiu como remover a capacidade dos usuários do OWA de criar endereços de autoforwarding. Isso faz muito para impedir o encaminhamento de e-mails fora de uma organização, mas o OWA é apenas uma parte do problema. Também precisamos lidar com outras formas pelas quais as mensagens podem ser encaminhadas automaticamente para endereços externos.
Por exemplo, as regras do Outlook podem encaminhar mensagens. É possível usar o PowerShell para analisar cada caixa de correio em busca de regras de encaminhamento, mas isso pode exigir muito processamento que teríamos que fazer continuamente. Vamos considerar métodos mais robustos para bloquear o encaminhamento automático de saída.
Bloqueio por Domínios
O bloqueio por domínio é um método eficaz para impedir o encaminhamento automático de mensagens. O bloqueio é implementado usando o cmdlet Set-RemoteDomain (ou, no EAC, editando a configuração de domínio remoto em Fluxo de Email). Este comando impede o autoforwarding de e-mails para qualquer domínio, exceto quando as configurações explícitas existem para permitir o encaminhamento para um domínio.
Set-RemoteDomain -Identity Default -AutoForwardEnabled $False
Para verificar se algum domínio permite o autoforwarding, execute este comando:
Get-RemoteDomain |?{$_.AutoForwardEnabled -eq $True}| Format-Table DomainName, AutoReplyEnabled
DomainName AutoReplyEnabled
---------- ----------------
Contoso.com True
Localizando Mensagens Descartadas
Os administradores podem verificar se uma mensagem está sendo bloqueada executando um rastreamento de mensagens usando o PowerShell ou a GUI de Rastreamento de Mensagens no Centro de Conformidade (Figura 1).
Dada a quantidade de mensagens que passam por um locatário diariamente, é mais fácil encontrar eventos de descarte com o PowerShell. Como o comando Get-MessageTrace pode processar muitos dados, é prudente restringir o período de tempo usado para buscar eventos de mensagens o máximo possível. Esse código procura por mensagens descartadas em um período de duas 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 uma Regra de Fluxo de Email
A simplicidade e a direção de bloquear o autoforwarding para domínios remotos é atraente, mas é um instrumento bruto. Outra abordagem é criar uma regra de fluxo de email para interceptar mensagens do tipo “Auto-forward” enviadas para destinatários externos com uma ação para rejeitar a mensagem e retornar uma notificação de entrega para o remetente com um motivo adequado. Por exemplo, “Sua mensagem foi bloqueada para garantir a confidencialidade da propriedade intelectual da organização.”
Alternativamente, você poderia encaminhar a mensagem automaticamente para o seu destino pretendido, mas somente após aplicar um selo de sensibilidade restritiva à mensagem, para que o destinatário não tenha o direito de lê-la. A intenção aqui é deixar claro para o destinatário que eles não deveriam estar tentando visualizar o conteúdo de nossa organização. Esperançosamente, o destinatário relatará sua frustração ao remetente, que talvez então perceba que está fazendo algo reprovado pela organização.
Cuidado com o Power Automate
Depois de erigir todas essas barreiras para impedir que os usuários encaminhem conteúdo para fora da organização, nos deparamos com o problema de que o Power Automate ignora alegremente quaisquer restrições impostas por regras de fluxo de correio, bloqueios de domínio ou remoção de endereços de encaminhamento automático das caixas de correio. Este problema foi documentado por Vasil Michev algum tempo atrás, mas a Microsoft não fez nada para melhorar a situação.
Atualização (setembro de 2020): Power Automate agora insere x-headers em mensagens que podem ser usados para interromper esse tráfego usando regras de transporte.
Por exemplo, você pode criar um novo fluxo para encaminhar mensagens quando novos itens chegam na pasta usando modelos fornecidos pela Microsoft. Usei um modelo padrão, conectei-o à minha caixa de correio, modifiquei-o para monitorar a pasta Arquivo e optei por enviar cópias para um endereço externo (Figura 2).
O resultado foi que cada vez que o Power Automate executava o fluxo, qualquer nova mensagem colocada na pasta Arquivo era encaminhada para o endereço externo. As mensagens aparecem no log de rastreamento de mensagens, mas parecem mensagens normais.
O conjunto de eventos de auditoria capturados pelo Power Automate e ingeridos no log de auditoria do Office 365 é bastante pobre e não se ganha muito auxílio ao investigar lá. A única coisa vista no log de auditoria é que o usuário criou um fluxo usando o OpenApiConnection connector.
Etiquetas de Sensibilidade Podem Ser a Solução
O fio condutor é que mensagens autoforwardadas podem ser lidas pelo destinatário. Para impedir isso, precisamos impedir que o destinatário consiga abrir e acessar o conteúdo da mensagem, e a única maneira de fazer isso é usar mensagens protegidas.
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.
Chamada da Organização
Decidir se os usuários podem autoforwardar e-mail é uma decisão que deve ser tomada como parte da estratégia de governança de dados da organização. É fácil erguer barreiras para o autoforwarding se você decidir que o e-mail deve permanecer dentro do locatário, mas se o fizer, lembre-se de comunicar a política aos usuários.