Restringir o acesso a um locatário

Organizações de grande porte que priorizam a segurança desejam mudar para serviços de nuvem como o Microsoft 365, mas precisam ter a certeza de que seus usuários poderão acessar somente os recursos aprovados. Tradicionalmente, as empresas restringem endereços IP ou nomes de domínio quando desejam gerenciar o acesso. Essa abordagem falha em um mundo em que os aplicativos de SaaS (software como serviço) são hospedados em uma nuvem pública e são executados em nomes de domínio compartilhados como outlook.office.com e login.microsoftonline.com. Bloquear esses endereços impediria totalmente que os usuários acessassem o Outlook na web, em vez de simplesmente restringi-los a identidades e recursos aprovados.

A solução do Microsoft Entra para esse desafio é um recurso chamado Restrições de Locatário. Com as restrições de locatário, as organizações podem controlar o acesso a aplicativos de nuvem de SaaS com base no locatário do Microsoft Entra que os aplicativos usam para o logon único. Por exemplo, é possível permitir o acesso aos aplicativos do Microsoft 365 de sua organização e bloquear o acesso às instâncias de outras organizações desses mesmos aplicativos.

Com restrições de locatário, as organizações podem especificar a lista de locatários que os usuários em sua rede têm permissão para acessar. O Microsoft Entra ID só concede acesso a esses locatários permitidos, todos os outros locatários são bloqueados, mesmo aqueles em que seus usuários podem ser convidados.

Este artigo se concentra em restrições de locatário para Microsoft 365, mas o recurso protege todos os aplicativos que enviam o usuário ao Microsoft Entra ID para o logon único. Se você usar aplicativos SaaS com um locatário do Microsoft Entra diferente do locatário usado pelo seu Microsoft 365, verifique se todos os locatários necessários são permitidos. (Por exemplo, em cenários de colaboração B2B). Para obter mais informações sobre os aplicativos de nuvem de SaaS, consulte o Marketplace do Active Directory.

O recurso de restrições de locatário também dá suporte ao bloqueio do uso de todos os aplicativos MSA (aplicativos de consumidor da Microsoft), como o OneDrive, o Hotmail e o Xbox.com. Essa funcionalidade usa um cabeçalho separado para o ponto de extremidade login.live.com e é detalhada ao final desse artigo.

Como ele funciona

A solução geral inclui os seguintes componentes:

1. Microsoft Entra ID: se o Restrict-Access-To-Tenants: <permitted tenant list> cabeçalho estiver presente, o Microsoft Entra só emite tokens de segurança para os locatários permitidos.

2. Infraestrutura de servidor proxy local: Essa infraestrutura é um dispositivo proxy capaz de realizar inspeção de protocolo TLS. Você precisa configurar o proxy para inserir o cabeçalho que contém a lista de locatários permitidos no tráfego destinado ao Microsoft Entra ID.

3. Software cliente: Para dar suporte às restrições de locatário, o software cliente precisa solicitar tokens diretamente do Microsoft Entra ID, de modo que a infraestrutura de proxy possa interceptar o tráfego. No momento, tanto os aplicativos do Microsoft 365 baseados em navegador quanto os clientes do Office que usam autenticação moderna (como o OAuth 2.0) são compatíveis com restrições de locatário.

4. Autenticação moderna: os serviços de nuvem devem usar a autenticação moderna para usar restrições de locatário e bloquear o acesso a todos os locatários não permitidos. Configure os serviços de nuvem do Microsoft 365 para usar protocolos de autenticação moderna por padrão. Para obter as informações mais recentes sobre o suporte do Microsoft 365 para autenticação moderna, leia Autenticação moderna do Office 365 atualizada.

O diagrama a seguir ilustra o fluxo do tráfego de alto nível. As restrições de locatário requerem a inspeção de TLS apenas no tráfego para o Microsoft Entra ID, não para os serviços de nuvem do Microsoft 365. Essa distinção é importante porque o volume de tráfego de autenticação para o Microsoft Entra ID normalmente é muito menor do que o volume de tráfego para aplicativos de SaaS como o Exchange Online e o SharePoint Online.

Configurar as restrições de locatário

Há duas etapas para começar a usar as restrições de locatário. Primeiro, verifique se seus clientes podem se conectar aos endereços à direita. Segundo, configure sua infraestrutura de proxy.

URLs e endereços IP

Para usar restrições de locatário, seus clientes devem poder se conectar às seguintes URLs do Microsoft Entra para autenticar:

• login.microsoftonline.com
• login.microsoft.com
• login.windows.net

Além disso, para acessar o Office 365, seus clientes também precisam ser capazes de se conectar aos FQDNs (nomes de domínio totalmente qualificados), URLs e endereços IP definidos em URLs e intervalos de endereços IP do Office 365.

Requisitos e configuração de proxy

A configuração a seguir é necessária para habilitar as restrições de locatário por meio de sua infraestrutura de proxy. Essa diretriz é genérica, você deverá consultar a documentação do seu fornecedor de proxy para encontrar as etapas de implementação específicas.

Pré-requisitos

• O proxy deve ser capaz de realizar a interceptação de TLS, a inserção de cabeçalho HTTP e a filtragem de destinos usando FQDNs/URLs.

• Os clientes devem confiar na cadeia de certificados apresentada pelo proxy para comunicações TLS. Por exemplo, se forem usados certificados de uma PKI (infraestrutura de chave pública) interna, o certificado da autoridade de certificado raiz de emissão interno deverá ser confiável.

• As licenças P1 ou P2 do Microsoft Entra ID são necessárias para uso de restrições de locatário.

Configuração

Para cada solicitação de saída para login.microsoftonline.com, login.microsoft.com e login.windows.net, insira dois cabeçalhos HTTP: Restrict-Access-To-Tenants e Restrict-Access-Context.

Observação

Não inclua subdomínios em *.login.microsoftonline.com na sua configuração de proxy. Isso incluirá device.login.microsoftonline.com e interferirá na autenticação de certificado do cliente, que é usada nos cenários de registro de dispositivos e acesso condicional baseado no dispositivo. Configure seu servidor proxy para excluir device.login.microsoftonline.com e enterpriseregistration.windows.net de TLS break-and-inspect e injeção de cabeçalho.

Os cabeçalhos devem incluir os seguintes elementos:

• Para Restrict-Access-To-Tenants, use um valor de <permitted tenant list>, que é uma lista separada por vírgulas dos locatários para permitir que os usuários acessem. Qualquer domínio registrado com um locatário pode ser usado para identificar o locatário nessa lista e o próprio ID de diretório. Como exemplo das três maneiras de descrever um locatário, o par nome/valor que permite a Contoso, a Fabrikam e a Microsoft é semelhante ao seguinte: Restrict-Access-To-Tenants: contoso.com,fabrikam.onmicrosoft.com,72f988bf-86f1-41af-91ab-2d7cd011db47

• Para Restrict-Access-Context, use um valor de uma ID de diretório, declarando qual locatário está configurando as restrições de locatário. Por exemplo, para declarar a Contoso como o locatário que define a política de restrições de locatário, o par nome/valor é semelhante ao seguinte: Restrict-Access-Context: 456ff232-35l2-5h23-b3b3-3236w0826f3d. Você deve usar sua própria ID de diretório aqui para obter os logs para essas autenticações. Se você usar qualquer ID de diretório que não seja a sua, esses logs de início de sessão *aparecerão no locatário de outra pessoa, com todas as informações pessoais removidas. Para obter mais informações, confira Experiência do administrador.

Para localizar sua ID de diretório:

1. Entre no Centro de administração do Microsoft Entra como pelo menos Leitor Global.
2. Navegue atéIdentidade>Visão geral>Visão geral.
3. Copie o valor ID do Locatário.

Para validar que um ID de diretório ou nome de domínio se refere ao mesmo locatário, use esse ID ou domínio no lugar de <locatário> nessa URL: https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration. Quando os resultados são iguais com o domínio e com o ID, isso significa que eles se referem ao mesmo locatário.

Para impedir que os usuários insiram seu próprio cabeçalho HTTP com locatários não aprovados, o proxy precisará substituir o cabeçalho Restrict-Access-To-Tenants se ele já estiver presente na solicitação recebida.

Os clientes devem ser forçados a usar o proxy para todas as solicitações de login.microsoftonline.com.login.microsoft.com e login.windows.net. Por exemplo, se os arquivos PAC forem usados para direcionar os clientes para usar o proxy, os usuários finais não deverão ser capazes de editar ou desabilitar os arquivos PAC.

A experiência do usuário

Esta seção descreve a experiência para usuários finais e administradores.

Experiência do usuário final

Um usuário de exemplo está na rede da Contoso, mas está tentando acessar a instância da Fabrikam de um aplicativo de SaaS compartilhado como o Outlook online. Se a Fabrikam for um locatário não permitido para a instância da Contoso, o usuário verá uma mensagem de acesso negado. A mensagem informa que você está tentando acessar um recurso que pertence a uma organização não aprovada pelo seu departamento de TI.

Experiência de administração

Embora a configuração de restrições de locatário seja feita na infraestrutura de proxy corporativa, os administradores podem acessar os relatórios de restrições de locatário diretamente no centro de administração do Microsft Entra. Para visualizar os relatórios:

1. Entre no Centro de administração do Microsoft Entra como pelo menos Leitor Global.
2. Navegue até Identidade>Visão geral>Restrições de locatário.

O administrador do locatário especificado como o locatário Restricted-Access-Context pode usar esse relatório para ver as entradas bloqueadas por causa da política de restrições de locatário, incluindo a identidade usada e a ID de diretório de destino. As entradas serão incluídas se o locatário que define a restrição for o locatário do usuário ou o locatário do recurso para a entrada.

O relatório pode conter informações limitadas, como a ID do diretório de destino, no momento em que um usuário que está em um locatário diferente do locatário de contexto de acesso restrito entra. Nesse caso, as informações de identificação do usuário, como nome e nome UPN, são mascaradas para proteger os dados do usuário em outros locatários (Por exemplo, "{PII Removed}@domain.com" or 00000000-0000-0000-0000-000000000000 no lugar de nomes de usuários e IDs de objeto, conforme apropriado).

Como outros relatórios no centro de administração do Microsoft Entra, você pode usar filtros para especificar o escopo do relatório. Você pode filtrar por um status, usuário, aplicativo, cliente ou intervalo de tempo específico. Se você selecionar o botão Colunas, poderá optar por exibir dados com qualquer combinação dos seguintes campos:

• Usuário – Este campo pode ter dados pessoais removidos. Nesse caso, seu valor é definido como 00000000-0000-0000-0000-000000000000.
• Aplicativo
• Status
• Data
• Data (UTC) – em que UTC é o Tempo Universal Coordenado
• Endereço IP
• Cliente
• Nome de usuário – Este campo pode ter dados pessoais removidos. Nesse caso, seu valor é definido como {PII Removed}@domain.com
• Localidade
• ID do locatário de destino

Suporte do Microsoft 365

Os aplicativos do Microsoft 365 devem atender a dois critérios para dar suporte total às restrições de locatário:

1. O cliente usado dá suporte à autenticação moderna.
2. A autenticação moderna está habilitada como o protocolo de autenticação padrão para o serviço de nuvem.

Para obter as informações mais recentes sobre quais clientes do Office atualmente dão suporte à autenticação moderna, confira a Autenticação moderna do Office 365 atualizada. Essa página também inclui links para instruções para habilitar a autenticação moderna nos locatários do Exchange Online e Skype for Business Online. O SharePoint Online já habilita autenticação moderna por padrão. O Teams oferece compatibilidade apenas com a autenticação moderna e não oferece compatibilidade com a autenticação legada, portanto, essa preocupação sobre ignorar não se aplica ao Teams.

No momento, os aplicativos baseados em navegador do Microsoft 365 (como o portal do Office, o Yammer, os sites do SharePoint e o Outlook na Web) dão suporte a restrições de locatário. Thick clients (Outlook, Skype for Business, Word, Excel, PowerPoint e mais) podem impor restrições de locatário somente ao usarem a autenticação moderna.

Clientes Skype for Business e Outlook que dão suporte à autenticação moderna ainda podem usar protocolos herdados em locatários em que a autenticação moderna não está habilitada, ignorando efetivamente as restrições de locatário. Restrições de locatário poderão bloquear aplicativos que usam protocolo herdados se eles contatarem login.microsoftonline.com, login.microsoft.com ou login.windows.net durante a autenticação.

Para o Outlook no Windows, os clientes podem optar por implementar restrições que impedem que os usuários finais adicionem contas de email não aprovadas aos seus perfis. Por exemplo, consulte a configuração da política de grupo Impedir a adição de contas do Exchange não padrão.

Incompatibilidade com Azure RMS e Office Message Encryption

Os recursos Azure Rights Management Service (RMS) e Criptografia de mensagens do Officenão são compatíveis com as restrições do locatário. Esses recursos contam com a assinatura de seus usuários em outros locatários para obter chaves de descriptografia para os documentos criptografados. Como as restrições do locatário bloqueiam o acesso a outros locatários, mensagens criptografadas e documentos enviados a seus usuários por locatários não confiáveis ​​não estarão acessíveis.

Testando

Se você quiser experimentar as restrições de locatário antes de implementá-las em toda a organização, há duas opções: uma abordagem baseada em host usando uma ferramenta como o Fiddler ou uma distribuição em etapas das configurações de proxy.

Fiddler para uma abordagem baseada em host

O Fiddler é um proxy de depuração da Web gratuito que pode ser usado para capturar e modificar o tráfego HTTP/HTTPS, incluindo a inserção de cabeçalhos HTTP. Para configurar o Fiddler para testar as restrições de locatário, execute as seguintes etapas:

1. Baixe e instale o Fiddler.

2. Configure o Fiddler para descriptografar o tráfego HTTPS, de acordo com a documentação de ajuda do Fiddler.

3. Configure o Fiddler para inserir os cabeçalhos Restrict-Access-To-Tenants e Restrict-Access-Context usando regras personalizadas:

   1. Na ferramenta Fiddler Web Debugger, selecione o menu Regras e clique em Personalizar regras… para abrir o arquivo CustomRules.

   2. Adicione as seguintes linhas à função OnBeforeRequest. Substitua <Lista de identificadores de locatários> por um domínio registrado com seu locatário (por exemplo, contoso.onmicrosoft.com). Substitua <directory ID> pelo identificador de GUID do Microsoft Entra do locatário. Você deve incluir o identificador GUID correto para que os logs apareçam em seu locatário.

    // Allows access to the listed tenants.
      if (
          oSession.HostnameIs("login.microsoftonline.com") ||
          oSession.HostnameIs("login.microsoft.com") ||
          oSession.HostnameIs("login.windows.net")
      )
      {
          oSession.oRequest["Restrict-Access-To-Tenants"] = "<List of tenant identifiers>";
          oSession.oRequest["Restrict-Access-Context"] = "<Your directory ID>";
      }
   
    // Blocks access to consumer apps
      if (
          oSession.HostnameIs("login.live.com")
      )
      {
          oSession.oRequest["sec-Restrict-Tenant-Access-Policy"] = "restrict-msa";
      }
   

   Se você precisar permitir vários locatários, use uma vírgula para separar os nomes de locatário. Por exemplo:

   oSession.oRequest["Restrict-Access-To-Tenants"] = "contoso.onmicrosoft.com,fabrikam.onmicrosoft.com";

4. Salve e feche o arquivo CustomRules.

Depois de configurar o Fiddler, você pode capturar o tráfego indo para o menu Arquivo e selecionando Capturar Tráfego.

Distribuição em etapas as configurações de proxy

Dependendo dos recursos da sua infraestrutura de proxy, você poderá liberar em etapas a distribuição de configurações para seus usuários. Confira as seguintes opções de alto nível para consideração:

1. Use arquivos PAC para apontar os usuários de teste para uma infraestrutura de proxy de teste, enquanto os usuários normais continuam a usar a infraestrutura do proxy de produção.
2. Alguns servidores proxy podem dar suporte a configurações diferentes usando grupos.

Para obter detalhes específicos, veja a documentação do servidor proxy.

Bloqueando aplicativos do consumidor

Aplicativos da Microsoft com suporte para contas de consumidor e contas organizacionais, como o OneDrive, às vezes podem ser hospedados na mesma URL. Isso significa que os usuários que precisam acessar esse URL para fins de trabalho também têm acesso a ele para uso pessoal. Essa opção pode não ser permitida sob suas diretrizes operacionais.

Algumas organizações tentam corrigir isso bloqueando login.live.com para bloquear a autenticação de contas pessoais. Isso traz várias desvantagens:

1. O bloqueio de login.live.com impede o uso de contas pessoais em cenários de convidado B2B, que podem ser intrusos em visitantes e colaboração.
2. O Autopilot requer o uso de login.live.com para implantação. Os cenários do Intune e do Autopilot podem falhar quando login.live.com está bloqueado.
3. A telemetria organizacional e as atualizações do Windows que dependem do serviço login.live.com para as IDs de dispositivo deixam de funcionar.

Configuração para aplicativos de consumidor

Embora o cabeçalho Restrict-Access-To-Tenants funcione como uma lista de permitidos, o bloco MSA (conta Microsoft) funciona como um sinal de negação, informando à plataforma da conta Microsoft para não permitir que os usuários entrem em aplicativos de consumidor. Para enviar esse sinal, o cabeçalho sec-Restrict-Tenant-Access-Policy é injetado no tráfego que visita login.live.com usando o mesmo proxy corporativo ou firewall, conforme mencionado na seção de configuração e requisitos de proxy deste artigo. O valor do cabeçalho deve ser restrict-msa. Quando o cabeçalho estiver presente e um aplicativo de consumidor estiver tentando conectar um usuário diretamente, esse início de sessão será bloqueado.

Neste momento, a autenticação para aplicativos de consumidor não aparece nos logs de administração, pois o login.live.com é hospedado separadamente do Microsoft Entra ID.

O que o cabeçalho bloqueia e o que ele não bloqueia

A política restrict-msa bloqueia o uso de aplicativos de consumidor, mas permite vários outros tipos de tráfego e autenticação:

1. Tráfego sem usuário para dispositivos. Essa opção inclui o tráfego para Autopilot, Windows Update e telemetria organizacional.
2. Autenticação B2B de contas de consumidor. Usuários com contas Microsoft que são convidados para colaborar com um locatário autenticam-se no login.live.com para acessar um locatário de recursos.
   1. Esse acesso é controlado usando o cabeçalho Restrict-Access-To-Tenants para permitir ou negar o acesso a esse locatário de recursos.
3. Autenticação de "passagem", usada por muitos aplicativos do Azure, bem como o Office.com, em que os aplicativos usam o Microsoft Entra ID para conectar usuários consumidores em um contexto de consumidor.
   1. Esse acesso também é controlado usando o cabeçalho Restrict-Access-To-Tenants para permitir ou negar o acesso ao locatário especial de "passagem" (f8cdef31-a31e-4b4a-93e4-5f571e91255a). Se esse locatário não aparecer na lista Restrict-Access-To-Tenants de domínios permitidos, o Microsoft Entra ID bloqueará o início de sessão de contas de consumidor nesses aplicativos.

Plataformas que não dão suporte aos TLS break and inspect

As restrições de locatário dependem da injeção de uma lista de locatários permitidos no cabeçalho HTTPS. Essa dependência requer TLSI (Transport Layer Security Inspection) para interromper e inspecionar o tráfego. Para ambientes em que o lado do cliente não é capaz de interromper e inspecionar o tráfego para adicionar cabeçalhos, as restrições de locatário não funcionam.

Veja o exemplo do Android 7.0 e em diante. O Android alterou a forma como lida com CAs (autoridades de certificação) confiáveis para fornecer padrões mais seguros para o tráfego seguro do aplicativo. Para obter mais informações, consulte Alterações em autoridades de certificação confiáveis no Android Nougat.

Seguindo a recomendação do Google, os aplicativos clientes da Microsoft ignoram certificados de usuário por padrão. Essa política torna esses aplicativos incapazes de trabalhar com restrições de locatário, já que os certificados usados pelo proxy de rede são instalados no repositório de certificados do usuário, no qual os aplicativos cliente não confiam.

Outros recursos do Microsoft Entra ID podem fornecer proteção para esses ambientes que não podem interromper e inspecionar o tráfego para adicionar os parâmetros de restrições de locatário ao cabeçalho. A lista a seguir fornece mais informações sobre esses recursos do Microsoft Entra.

• Acesso Condicional: Permitir apenas o uso de dispositivos gerenciados/em conformidade
• Acesso Condicional: Gerenciar o acesso para usuários convidados/externos
• Colaboração B2B: Restringir regras de saída pelo acesso entre locatários para os mesmos locatários listados no parâmetro "Restrict-Access-To-Tenants"
• Colaboração B2B: Restringir convites a usuários B2B para os mesmos domínios listados no parâmetro "Restrict-Access-To-Tenants"
• Gerenciamento de aplicativos: Restringir como os usuários consentem com aplicativos
• Intune: Aplicar a Política de Aplicativo por meio do Intune para restringir o uso de aplicativos gerenciados apenas ao UPN da conta que registrou o dispositivo – Verifique a seção eno subtítulo Permitir somente contas de organização configuradas nos aplicativos.

No entanto, alguns cenários específicos só podem ser abordados usando restrições de locatário.

Próximas etapas

• Leia sobre a Updated Office 365 modern authentication (Autenticação moderna do Office 365 atualizada)
• Examine as URLs e intervalos de endereços IP do Office 365