Infraestrutura de mensagens híbridas de segurança aprimorada — acesso móvel

Microsoft Entra ID
Microsoft 365
Office 365

O artigo mostra como implementar a autenticação multifator para clientes móveis do Outlook que acessam o Microsoft Exchange. Existem duas arquiteturas que correspondem a duas possibilidades diferentes para o Microsoft Exchange que tem a caixa de correio do usuário:

Arquitetura (Exchange Online)

Diagrama que mostra uma arquitetura para segurança aprimorada em um cenário de acesso móvel do Outlook. A caixa de correio do usuário está no Exchange Online.

Nesse cenário, os usuários precisam usar um cliente móvel que ofereça suporte à autenticação moderna. Recomendamos o Outlook mobile (Outlook para iOS / Outlook para Android), que é suportado pela Microsoft. O fluxo de trabalho a seguir usa o Outlook mobile.

Baixe um arquivo do Visio de todos os diagramas neste artigo.

Fluxo de trabalho (Exchange Online)

  1. O usuário inicia a configuração do perfil do Outlook inserindo um endereço de e-mail. O Outlook mobile se conecta ao serviço AutoDetect.
  2. O serviço AutoDetect faz uma solicitação anônima de Descoberta Automática V2 ao Exchange Online para obter a caixa de correio. O Exchange Online responde com uma resposta de redirecionamento 302 que contém o endereço URL do ActiveSync para a caixa de correio, apontando para o Exchange Online. Pode ver um exemplo deste tipo de pedido aqui.
  3. Agora que o serviço AutoDetect tem informações sobre o ponto de extremidade do conteúdo da caixa de correio, ele pode chamar o ActiveSync sem autenticação.
  4. Conforme descrito no fluxo de conexão aqui, o Exchange responde com uma resposta de desafio 401. Ele inclui uma URL de autorização que identifica o ponto de extremidade do Microsoft Entra que o cliente precisa usar para obter um token de acesso.
  5. O serviço AutoDetect retorna o ponto de extremidade de autorização do Microsoft Entra para o cliente.
  6. O cliente se conecta ao Microsoft Entra ID para concluir a autenticação e inserir informações de entrada (email).
  7. Se o domínio for federado, a solicitação será redirecionada para o Proxy de Aplicativo Web.
  8. O Proxy de Aplicativo Web faz o proxy da solicitação de autenticação para o AD FS. O utilizador vê uma página de início de sessão.
  9. O usuário insere credenciais para concluir a autenticação.
  10. O usuário é redirecionado de volta para o Microsoft Entra ID.
  11. O Microsoft Entra ID aplica uma política de Acesso Condicional do Azure.
  12. A política pode impor restrições com base no estado do dispositivo do usuário se o dispositivo estiver inscrito no Microsoft Endpoint Manager, impor políticas de proteção de aplicativos e/ou impor autenticação multifator. Você pode encontrar um exemplo detalhado desse tipo de política nas etapas de implementação descritas aqui.
  13. O usuário implementa todos os requisitos de política e conclui a solicitação de autenticação multifator.
  14. O Microsoft Entra ID retorna tokens de acesso e atualização para o cliente.
  15. O cliente usa o token de acesso para se conectar ao Exchange Online e recuperar o conteúdo da caixa de correio.

Configuração (Exchange Online)

Para bloquear tentativas de acesso ao Exchange Online ActiveSync por meio da autenticação herdada (a linha tracejada vermelha no diagrama), você precisa criar uma política de autenticação que desabilite a autenticação herdada para protocolos usados pelo serviço móvel Outlook. Especificamente, você precisa desabilitar a Descoberta Automática, o ActiveSync e o Serviço do Outlook. Aqui está a configuração da política de autenticação correspondente:

AllowBasicAuthAutodiscover : Falso

AllowBasicAuthActiveSync : Falso

AllowBasicAuthOutlookService : Falso

Depois de criar a política de autenticação, você pode atribuí-la a um grupo piloto de usuários. Em seguida, após o teste, você pode expandir a política para todos os usuários. Para aplicar a política no nível da organização, use o Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> comando. Você precisa usar o PowerShell do Exchange Online para essa configuração.

Para domínios federados, você pode configurar o AD FS para disparar a autenticação multifator em vez de usar uma política de Acesso Condicional. No entanto, recomendamos que você controle a conexão e aplique restrições no nível da política de Acesso Condicional.

Arquitetura (Exchange local)

Diagrama que mostra uma arquitetura para segurança aprimorada em um cenário de acesso móvel do Outlook. A caixa de correio do usuário está no Exchange local.

Baixe um arquivo do Visio de todos os diagramas neste artigo.

Nesse cenário, os usuários precisam usar um cliente móvel que ofereça suporte à autenticação moderna, conforme descrito em Usando a autenticação moderna híbrida. Recomendamos o Outlook mobile (Outlook para iOS / Outlook para Android), que é suportado pela Microsoft. O fluxo de trabalho a seguir usa o Outlook mobile.

Fluxo de trabalho (Exchange local)

  1. O usuário inicia a configuração do perfil do Outlook inserindo um endereço de e-mail. O Outlook mobile se conecta ao serviço AutoDetect.
  2. O serviço AutoDetect faz uma solicitação anônima de Descoberta Automática V2 ao Exchange Online para obter a caixa de correio.
  3. Depois que a caixa de correio estiver localizada localmente, o Exchange Online responderá com uma resposta de redirecionamento 302 que contém uma URL de Descoberta Automática local que a Deteção Automática pode usar para recuperar o endereço de URL do ActiveSync para a caixa de correio.
  4. A Deteção Automática usa a URL local recebida na etapa anterior para fazer uma solicitação anônima de Descoberta Automática v2 ao Exchange local para obter a caixa de correio. O Exchange local retorna um endereço de URL do ActiveSync para a caixa de correio, apontando para o Exchange local. Pode ver um exemplo deste tipo de pedido aqui.
  5. Agora que o serviço AutoDetect tem informações sobre o ponto de extremidade do conteúdo da caixa de correio, ele pode chamar o ponto de extremidade do ActiveSync local sem autenticação. Conforme descrito no fluxo de conexão aqui, o Exchange responde com uma resposta de desafio 401. Ele inclui uma URL de autorização que identifica o ponto de extremidade do Microsoft Entra que o cliente precisa usar para obter um token de acesso.
  6. O serviço AutoDetect retorna o ponto de extremidade de autorização do Microsoft Entra para o cliente.
  7. O cliente se conecta ao Microsoft Entra ID para concluir a autenticação e inserir informações de entrada (email).
  8. Se o domínio for federado, a solicitação será redirecionada para o Proxy de Aplicativo Web.
  9. O Proxy de Aplicativo Web faz o proxy da solicitação de autenticação para o AD FS. O utilizador vê uma página de início de sessão.
  10. O usuário insere credenciais para concluir a autenticação.
  11. O usuário é redirecionado de volta para o Microsoft Entra ID.
  12. O Microsoft Entra ID aplica uma política de Acesso Condicional do Azure.
  13. A política pode impor restrições com base no estado do dispositivo do usuário se o dispositivo estiver inscrito no Microsoft Endpoint Manager, impor políticas de proteção de aplicativos e/ou impor autenticação multifator. Você pode encontrar um exemplo detalhado desse tipo de política nas etapas de implementação descritas aqui.
  14. O usuário implementa todos os requisitos de política e conclui a solicitação de autenticação multifator.
  15. O Microsoft Entra ID retorna tokens de acesso e atualização para o cliente.
  16. O cliente usa o token de acesso para se conectar ao Exchange Online e recuperar o conteúdo da caixa de correio local. O conteúdo deve ser fornecido a partir do cache, conforme descrito aqui. Para conseguir isso, o cliente emite uma solicitação de provisionamento que inclui o token de acesso do usuário e o ponto de extremidade do ActiveSync local.
  17. A API de provisionamento no Exchange Online usa o token fornecido como uma entrada. A API obtém um segundo par de token de acesso e atualização para acessar a caixa de correio local por meio de uma chamada em nome do Ative Directory. Esse segundo token de acesso tem como escopo o cliente como Exchange Online e uma audiência do ponto de extremidade do namespace ActiveSync local.
  18. Se a caixa de correio não for provisionada, a API de provisionamento criará uma caixa de correio.
  19. A API de provisionamento estabelece uma conexão segura com o ponto de extremidade do ActiveSync local. A API sincroniza os dados de mensagens do usuário usando o segundo token de acesso como mecanismo de autenticação. O token de atualização é usado periodicamente para gerar um novo token de acesso para que os dados possam ser sincronizados em segundo plano sem a intervenção do usuário.
  20. Os dados são devolvidos ao cliente.

Configuração (Exchange local)

Para bloquear tentativas de acesso ao Exchange ActiveSync local por meio da autenticação herdada (as linhas tracejadas vermelhas no diagrama), você precisa criar uma política de autenticação que desabilite a autenticação herdada para protocolos usados pelo serviço móvel Outlook. Especificamente, você precisa desabilitar a Descoberta Automática e o ActiveSync. Aqui está a configuração da política de autenticação correspondente:

BlockLegacyAuthAutodiscover: Verdadeiro

BlockLegacyAuthActiveSync: Verdadeiro

Eis um exemplo de um comando para criar esta política de autenticação:

New-AuthenticationPolicy -Name BlockLegacyActiveSyncAuth -BlockLegacyAuthActiveSync -BlockLegacyAuthAutodiscover

Depois de criar a política de autenticação, você pode primeiro atribuí-la a um grupo piloto de usuários usando o Set-User user01 -AuthenticationPolicy <name_of_policy> comando. Após o teste, você pode expandir a política para incluir todos os usuários. Para aplicar a política no nível da organização, use o Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> comando. Você precisa usar o PowerShell local do Exchange para essa configuração.

Você também precisa tomar medidas para obter consistência e permitir o acesso somente do cliente Outlook. Para permitir o Outlook mobile como o único cliente aprovado na organização, você precisa bloquear tentativas de conexão de clientes que não são clientes móveis do Outlook que oferecem suporte à autenticação moderna. Você precisa bloquear essas tentativas no nível local do Exchange concluindo estas etapas:

  • Bloquear outros clientes de dispositivos móveis:

    Set-ActiveSyncOrganizationSettings -DefaultAccessLevel Block

  • Permitir que o Exchange Online se conecte localmente:

    If ((Get-ActiveSyncOrganizationSettings).DefaultAccessLevel -ne "Allow") {New-ActiveSyncDeviceAccessRule -Characteristic DeviceType -QueryString "OutlookService" -AccessLevel Allow}

  • Bloquear autenticação básica para o Outlook para iOS e Android:

    New-ActiveSyncDeviceAccessRule -Characteristic DeviceModel -QueryString "Outlook for iOS and Android" -AccessLevel Block

Para obter mais informações sobre essas etapas, consulte Usando a autenticação moderna híbrida com o Outlook para iOS e Android.

Para domínios federados, você pode configurar o AD FS para disparar a autenticação multifator em vez de usar uma política de Acesso Condicional. No entanto, recomendamos que você controle a conexão e aplique restrições no nível da política de Acesso Condicional.

Componentes

  • ID do Microsoft Entra. O Microsoft Entra ID é um serviço de gerenciamento de identidade e acesso baseado em nuvem da Microsoft. Ele fornece autenticação moderna que é essencialmente baseada em EvoSTS (um serviço de token de segurança usado pelo Microsoft Entra ID). Ele é usado como um servidor de autenticação para o Exchange Server local.
  • Autenticação multifator Microsoft Entra. A autenticação multifator é um processo no qual os usuários são solicitados durante o processo de login para outra forma de identificação, como um código em seu celular ou uma digitalização de impressão digital.
  • Acesso condicional do Microsoft Entra. O Acesso Condicional é o recurso que o Microsoft Entra ID usa para impor políticas organizacionais, como a autenticação multifator.
  • AD FS. O AD FS permite o gerenciamento de identidade e acesso federado compartilhando direitos de identidade digital e direitos entre limites de segurança e corporativos com segurança aprimorada. Nessas arquiteturas, ele é usado para facilitar o login de usuários com identidade federada.
  • Proxy de aplicativo Web. O Proxy de Aplicativo Web pré-autentica o acesso a aplicativos Web usando o AD FS. Ele também funciona como um proxy do AD FS.
  • Microsoft Intune. O Intune é a nossa gestão unificada de terminais baseada na nuvem, gerindo terminais nos sistemas operativos Windows, Android, Mac, iOS e Linux.
  • Exchange Server. O Exchange Server hospeda caixas de correio de usuários no local. Nessas arquiteturas, ele usa tokens emitidos para o usuário pelo Microsoft Entra ID para autorizar o acesso a caixas de correio.
  • Serviços do Ative Directory. Os serviços do Ative Directory armazenam informações sobre membros de um domínio, incluindo dispositivos e usuários. Nessas arquiteturas, as contas de usuário pertencem aos serviços do Ative Directory e são sincronizadas com o Microsoft Entra ID.

Alternativas

Você pode usar clientes móveis de terceiros que oferecem suporte à autenticação moderna como uma alternativa ao Outlook mobile. Se você escolher essa alternativa, o fornecedor terceirizado será responsável pelo suporte aos clientes.

Detalhes do cenário

A infraestrutura de mensagens corporativas (EMI) é um serviço fundamental para as organizações. Passar de métodos de autenticação e autorização mais antigos e menos seguros para a autenticação moderna é um desafio crítico em um mundo onde o trabalho remoto é comum. A implementação de requisitos de autenticação multifator para o acesso ao serviço de mensagens é uma das maneiras mais eficazes de enfrentar esse desafio.

Este artigo descreve duas arquiteturas para ajudá-lo a aprimorar sua segurança em um cenário de acesso móvel do Outlook usando a autenticação multifator do Microsoft Entra.

Esses cenários são descritos neste artigo:

  • Acesso móvel do Outlook quando a caixa de correio do usuário está no Exchange Online
  • Acesso móvel do Outlook quando a caixa de correio do usuário está no Exchange local

Ambas as arquiteturas abrangem o Outlook para iOS e o Outlook para Android.

Para obter informações sobre como aplicar a autenticação multifator em outros cenários de mensagens híbridas, consulte estes artigos:

Este artigo não discute outros protocolos, como IMAP ou POP. Normalmente, esses cenários não usam esses protocolos.

Notas gerais

  • Essas arquiteturas usam o modelo de identidade federado do Microsoft Entra. Para os modelos de sincronização de hash de senha e Autenticação de Passagem, a lógica e o fluxo são os mesmos. A única diferença está relacionada ao fato de que o Microsoft Entra ID não redirecionará a solicitação de autenticação para os Serviços de Federação do Ative Directory (AD FS) locais.
  • Nos diagramas, linhas tracejadas pretas mostram interações básicas entre componentes locais do Ative Directory, Microsoft Entra Connect, Microsoft Entra ID, AD FS e Web Application Proxy. Você pode aprender sobre essas interações em Portas e protocolos necessários de identidade híbrida.
  • Por Exchange local, queremos dizer Exchange 2019 com as atualizações mais recentes e uma função de Caixa de Correio.
  • Em um ambiente real, você não terá apenas um servidor. Você terá uma matriz de servidores Exchange com balanceamento de carga para alta disponibilidade. Os cenários descritos aqui são adequados para essa configuração.

Potenciais casos de utilização

Essa arquitetura é relevante para os seguintes cenários:

  • Aumente a segurança do EMI.
  • Adote uma estratégia de segurança Zero Trust .
  • Aplique seu alto nível padrão de proteção para seu serviço de mensagens local durante a transição ou a coexistência com o Exchange Online.
  • Aplique requisitos rigorosos de segurança ou conformidade em organizações fechadas ou altamente seguras, como as do setor financeiro.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Fiabilidade

A confiabilidade garante que seu aplicativo possa atender aos compromissos que você assume com seus clientes. Para obter mais informações, consulte Visão geral do pilar de confiabilidade.

Disponibilidade

A disponibilidade geral depende da disponibilidade dos componentes envolvidos. Para obter informações sobre disponibilidade, consulte estes recursos:

A disponibilidade dos componentes da solução local depende do design implementado, da disponibilidade de hardware e de suas rotinas internas de operações e manutenção. Para obter informações de disponibilidade sobre alguns desses componentes, consulte os seguintes recursos:

Para usar a autenticação moderna híbrida, você precisa garantir que todos os clientes em sua rede possam acessar o Microsoft Entra ID. Você também precisa manter consistentemente as portas de firewall do Office 365 e as aberturas de intervalo de IP.

Para obter os requisitos de protocolo e porta para o Exchange Server, consulte "Exchange client and protocol requirements" em Visão geral da autenticação moderna híbrida para uso com os servidores Skype for Business e Exchange locais.

Para intervalos e portas IP do Office 365, consulte URLs e intervalos de endereços IP do Office 365.

Para obter informações sobre autenticação moderna híbrida e dispositivos móveis, leia sobre o ponto de extremidade AutoDetect em Outros pontos de extremidade não incluídos no serviço Web URL e Endereço IP do Office 365.

Resiliência

Para obter informações sobre a resiliência dos componentes nessa arquitetura, consulte os recursos a seguir.

Segurança

Para obter orientações gerais sobre segurança em dispositivos móveis, consulte Proteger dados e dispositivos com o Microsoft Intune.

Para obter informações sobre segurança e autenticação moderna híbrida, consulte Deep Dive: How Hybrid Authentication Really Works.

Para organizações fechadas que têm proteção de perímetro forte tradicional, há preocupações de segurança relacionadas às configurações do Exchange Hybrid Classic. A configuração Moderna Híbrida do Exchange não oferece suporte à autenticação moderna híbrida.

Para obter informações sobre o ID do Microsoft Entra, consulte o guia de operações de segurança do Microsoft Entra.

Para obter informações sobre cenários que usam a segurança do AD FS, consulte estes artigos:

Otimização de custos

O custo da sua implementação depende do seu ID do Microsoft Entra e dos custos da licença do Microsoft 365. O custo total também inclui custos de software e hardware para componentes locais, operações de TI, treinamento e educação e implementação de projetos.

Estas soluções requerem pelo menos o Microsoft Entra ID P1. Para obter detalhes de preços, consulte Preços do Microsoft Entra.

Para obter informações sobre o AD FS e o Proxy de Aplicativo Web, consulte Preços e licenciamento do Windows Server 2022.

Para obter mais informações sobre preços, consulte estes recursos:

Eficiência de desempenho

O desempenho depende do desempenho dos componentes envolvidos e do desempenho da rede da sua empresa. Para obter mais informações, consulte Ajuste de desempenho do Office 365 usando linhas de base e histórico de desempenho.

Para obter informações sobre fatores locais que influenciam o desempenho de cenários que incluem serviços do AD FS, consulte estes recursos:

Escalabilidade

Para obter informações sobre a escalabilidade do AD FS, consulte Planejando a capacidade do servidor AD FS.

Para obter informações sobre a escalabilidade local do Exchange Server, consulte Arquitetura preferencial do Exchange 2019.

Implementar este cenário

Para implementar essa infraestrutura, você precisa concluir as etapas descritas nas diretrizes incluídas nos artigos a seguir. Aqui estão as etapas de alto nível:

  1. Proteja o acesso móvel do Outlook conforme descrito nestas etapas de implementação para autenticação moderna.
  2. Bloqueie todas as outras tentativas de autenticação herdada no nível de ID do Microsoft Entra.
  3. Bloqueie tentativas de autenticação herdada no nível de serviços de mensagens usando a política de autenticação.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

  • Pavel Kondrashov - Brasil | Arquiteto de Soluções Cloud
  • Ella Parkum - Brasil | Principal Arquiteto-Engenharia de Soluções para Clientes

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos