Estamos tentando substituir uma solução de gateway de e-mail segura pela criptografia de mensagens de e-mail integrada do MS365.
Temos uma regra de fluxo de mensagens configurada para forçar a criptografia de um endereço de envio específico para qualquer destinatário, como segue:
CONDIÇÕES :
Aplicar regra se:
O remetente for '[email protected]'Faça o seguinte: Modificar a segurança das mensagens - Aplicar criptografia de mensagens do Office 365 e proteção de direitos
- Os direitos protegem a mensagem com 'Criptografar' (política de criptografia padrão)
Agora, quando enviamos de alwaysencrypt- que é uma conta licenciada Business Basic neste locatário - temos resultados estranhos.
- Ao enviar para uma conta/locatário/domínio que não seja MS365, as mensagens de e-mail são entregues como propriedade e exigem o envio de um código OTP para validar o acesso. Isso funciona bem.
- Para alguns destinatários de locatários do MS365, mas NÃO fazem parte do locatário de origem, o gerenciamento de direitos funciona corretamente e identifica adequadamente esse locatário externo como um destinatário e o usuário tem acesso permitido.
- Para outros destinatários do locatário MS365 que NÃO fazem parte do locatário de origem, o sistema não permite que o usuário faça login e use a autenticação do locatário MS365 para acessar o documento e falha com uma mensagem semelhante a
Selected user account does not exist in tenant 'Example Tenant' and cannot access the application 'UUID' in that tenant. The account needs to be added as an external user in the tenant first. Please use a different account.
É muito novo que essa terceira opção aconteça, e o MS365 NÃO oferece aos locatários externos a opção de código OTP.
Não vejo uma maneira de resolver isso e permitir o acesso ao sistema de direitos para inquilinos externos sem adicioná-los manualmente ao nosso inquilino de origem, e isso é um problema porque este é um sistema automatizado que envia dados de mensagens criptografadas como parte dos sistemas de alerta para destinatários externos.
Alguém viu isso e tem alguma ideia de como podemos resolver isso para forçá-lo a NÃO usar a autenticação de locatário MS365 para acessar mensagens criptografadas e ser apenas a verificação do código OTP se estiverem fora da organização?
Devo observar que o MS365 agora está forçando o uso do Microsoft Purview para que as soluções OME herdadas não funcionem e não há documentação sobre como alterar isso ou fazer essas revisões conforme necessário.
Observe que tenho acesso a um administrador global no locatário de origem, portanto DEVO ter acesso a todas as opções do Powershell, se necessário.
Então, na verdade, essa não é uma questão de “inquilino”, mas de licenciamento. O que não é fácil de encontrar na documentação, porque as páginas básicas do Purview nem sequer fazem referência a isso, está apenas no FAQ que você não vê quando tenta depurar coisas de criptografia.
Enterrado aqui na documentação OME do Microsoft Purview nas Perguntas frequentes (mas NÃO em qualquer outro lugar da documentação do Purview), ele indica em quais planos o Purview tem suporte automático:
Infelizmente, isso NÃO está listado nas páginas de planos do MS365 e não está detalhado em nenhuma outra documentação sobre os planos do MS365 - pelo menos, não é óbvio em nenhum lugar.
Obtivemos uma licença para o Plano 1 de Proteção de Informações do Azure, conforme indicado, e a anexamos ao
alwaysencryptusuário no locatário de origem. Depois de dar tempo à Microsoft para aplicar essa alteração e o serviço AIP ao locatário de origem, ele funciona conforme o esperado e os locatários externos agora podem visualizar as mensagens, assim como os destinatários que não são do MS365.A Microsoft obteve nota -1 em sua documentação hoje, mas pelo menos resolvemos isso com uma solução simples: investir mais dinheiro na Microsoft.