Restringir o acesso a um inquilino

Grandes organizações que enfatizam a segurança querem migrar para serviços de nuvem como o Microsoft 365, mas precisam saber que seus usuários só podem acessar recursos aprovados. Tradicionalmente, as empresas restringem nomes de domínio ou endereços IP quando querem gerenciar o acesso. Essa abordagem falha em um mundo onde os aplicativos de software como serviço (ou SaaS) são hospedados em uma nuvem pública, executados em nomes de domínio compartilhados como outlook.office.com e login.microsoftonline.com. Bloquear esses endereços impediria que os usuários acessassem totalmente o Outlook na Web, em vez de apenas 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 restrições de locatário, as organizações podem controlar o acesso a aplicativos de nuvem SaaS, com base no locatário do Microsoft Entra que os aplicativos usam para logon único. Por exemplo, talvez você queira permitir o acesso aos aplicativos Microsoft 365 da sua organização, impedindo o acesso a 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. Em seguida, 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 nas restrições de locatário para o Microsoft 365, mas o recurso protege todos os aplicativos que enviam o usuário para o Microsoft Entra ID para logon único. Se você usa aplicativos SaaS com um locatário do Microsoft Entra diferente do locatário usado pelo 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 aplicativos de nuvem SaaS, consulte o Ative Directory Marketplace.

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

Como funciona

A solução global compreende os seguintes componentes:

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

2. Infraestrutura de servidor proxy local: essa infraestrutura é um dispositivo proxy capaz de inspeção TLS (Transport Layer Security). Você deve 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 a restrições de locatário, o software cliente deve solicitar tokens diretamente do Microsoft Entra ID, para que a infraestrutura de proxy possa intercetar o tráfego. Atualmente, os aplicativos do Microsoft 365 baseados em navegador oferecem suporte a restrições de locatário, assim como os clientes do Office que usam autenticação moderna (como o OAuth 2.0).

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. Você deve configurar os serviços de nuvem do Microsoft 365 para usar protocolos de autenticação modernos por padrão. Para obter as informações mais recentes sobre o suporte do Microsoft 365 para autenticação moderna, leia Autenticação moderna atualizada do Office 365.

O diagrama a seguir ilustra o fluxo de tráfego de alto nível. As restrições de locatário exigem inspeção TLS somente 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 para autenticação no Microsoft Entra ID normalmente é muito menor do que o volume de tráfego para aplicativos SaaS como o Exchange Online e o SharePoint Online.

Configurar restrições de locatário

Há duas etapas para começar com as restrições de inquilino. Primeiro, certifique-se de que seus clientes podem se conectar aos endereços certos. Em segundo lugar, configure sua infraestrutura de proxy.

URLs e endereços IP

Para usar restrições de locatário, seus clientes devem ser capazes de 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 devem 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.

Configuração e requisitos de proxy

A configuração a seguir é necessária para habilitar restrições de locatário por meio de sua infraestrutura de proxy. Esta orientação é genérica, portanto, você deve consultar a documentação do fornecedor do proxy para obter etapas de implementação específicas.

Pré-requisitos

• O proxy deve ser capaz de executar intercetação TLS, inserção de cabeçalho HTTP e destinos de filtro 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 certificação raiz emissora interna deverá ser confiável.

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

Configuração

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

Nota

Não inclua subdomínios em *.login.microsoftonline.com sua configuração de proxy. Isso incluirá device.login.microsoftonline.com e interferirá na autenticação do Certificado de Cliente, que é usada em cenários de Registro de Dispositivo e Acesso Condicional baseado em Dispositivo. Configure seu servidor proxy para excluir device.login.microsoftonline.com e enterpriseregistration.windows.net de quebra e inspeção TLS e injeção de cabeçalho.

Os cabeçalhos devem incluir os seguintes elementos:

• Para Restrict-Access-To-Tenants, use um valor de lista> de <locatários permitidos, que é uma lista separada por vírgulas de locatários que você deseja permitir que os usuários acessem. Qualquer domínio registrado em um locatário pode ser usado para identificar o locatário nessa lista e o próprio ID do diretório. Para obter um exemplo de todas as três maneiras de descrever um locatário, o par nome/valor para permitir Contoso, Fabrikam e Microsoft tem a seguinte aparência: Restrict-Access-To-Tenants: contoso.com,fabrikam.onmicrosoft.com,aaaabbbb-0000-cccc-1111-dddd2222eeee

• Para Restrict-Access-Context, use um valor de uma única ID de diretório, declarando qual locatário está definindo as restrições de locatário. Por exemplo, para declarar Contoso como o locatário que definiu a política de restrições de locatário, o par nome/valor tem a seguinte aparência: Restrict-Access-Context: bbbbcccc-1111-dddd-2222-eeee3333ffff. Você deve usar seu próprio ID de diretório aqui para obter logs para essas autenticações. Se utilizar qualquer ID de diretório que não seja o seu, os registos de início de sessão *aparecem no inquilino de outra pessoa, com todas as informações pessoais removidas. Para obter mais informações, consulte Experiência do administrador.

Para encontrar o ID do diretório:

1. Entre no centro de administração do Microsoft Entra como pelo menos um Leitor Global.
2. Navegue até Visão geral> da identidade.>
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 do <locatário> nesta URL: https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration. Se os resultados com o domínio e o ID forem os mesmos, 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 precisa substituir o cabeçalho Restrict-Access-To-Tenants se ele já estiver presente na solicitação de entrada.

Os clientes devem ser forçados a usar o proxy para todas as solicitações para login.microsoftonline.com, login.microsoft.come login.windows.net. Por exemplo, se os arquivos PAC forem usados para direcionar os clientes a usar o proxy, os usuários finais não poderão 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 utilizador final

Um usuário de exemplo está na rede Contoso, mas está tentando acessar a instância da Fabrikam de um aplicativo 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 negação de acesso. A mensagem de negação diz que você está tentando acessar um recurso que pertence a uma organização não aprovada pelo departamento de TI.

Experiência de admin

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

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

O administrador do locatário especificado como locatário de contexto de acesso restrito pode usar esse relatório para ver entradas bloqueadas devido à política de restrições de locatário, incluindo a identidade usada e a ID do diretório de destino. Os logins serão incluídos se o locatário que define a restrição for o locatário do usuário ou o locatário do recurso para o login.

O relatório pode conter informações limitadas, como ID do diretório de destino, quando um usuário que está em um locatário diferente do locatário de contexto de acesso restrito faz logon. Nesse caso, as informações de identificação do usuário, como nome e nome principal do usuário, são mascaradas para proteger os dados do usuário em outros locatários (por exemplo, no lugar de nomes de usuário e IDs de objeto, "{PII Removed}@domain.com" or 00000000-0000-0000-0000-000000000000 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 em um intervalo de tempo, usuário, aplicativo, cliente ou status 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, onde seu valor é definido como 00000000-0000-0000-0000-000000000000.
• Aplicação
• Status
• Date
• Data (UTC) - onde UTC é Tempo Universal Coordenado
• Endereço IP
• Cliente
• Nome de utilizador - este campo pode remover dados pessoais, onde o seu valor está definido como{PII Removed}@domain.com
• Location
• ID do locatário de destino

Suporte do Microsoft 365

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

1. O cliente usado suporta 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 oferecem suporte à autenticação moderna, consulte Autenticação moderna do Office 365 atualizada. Essa página também inclui links para instruções para habilitar a autenticação moderna em locatários específicos do Exchange Online e do Skype for Business Online. O SharePoint Online já habilita a autenticação moderna por padrão. O Teams suporta apenas a autenticação moderna e não suporta a autenticação legada, portanto, essa preocupação de desvio não se aplica ao Teams.

Os aplicativos baseados em navegador do Microsoft 365 (como o Portal do Office, o Yammer, os sites do SharePoint e o Outlook na Web.) atualmente oferecem suporte a restrições de locatário. Clientes espessos (Outlook, Skype for Business, Word, Excel, PowerPoint e muito mais) podem impor restrições de locatário somente ao usar a autenticação moderna.

Os clientes Outlook e Skype for Business que oferecem suporte à autenticação moderna ainda poderão usar protocolos herdados em locatários onde a autenticação moderna não está habilitada, ignorando efetivamente as restrições do locatário. As restrições de locatário podem bloquear aplicativos que usam protocolos herdados se contatarem , login.microsoft.comou login.windows.net durante a login.microsoftonline.comautenticação.

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

Incompatibilidade do Azure RMS e da Encriptação de Mensagens do Office

Os recursos do Azure Rights Management Service (Azure RMS) e da Criptografia de Mensagem do Office não são compatíveis com restrições de locatário. Estas funcionalidades dependem do início de sessão dos seus utilizadores noutros inquilinos para obter chaves de desencriptação para os documentos encriptados. Como as restrições de locatário bloqueiam o acesso a outros locatários, emails criptografados e documentos enviados aos usuários de locatários não confiáveis não estão acessíveis.

Testar

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

Fiddler para uma abordagem baseada em host

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 restrições de locatário, execute as seguintes etapas:

1. Transfira 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 Rules e selecione Customize Rules... para abrir o arquivo CustomRules.

   2. Adicione as seguintes linhas dentro da OnBeforeRequest função. Substitua <Lista de identificadores> de locatário por um domínio registrado com seu locatário (por exemplo, contoso.onmicrosoft.com). Substitua <a ID> do diretório pelo identificador GUID do Microsoft Entra do seu 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 dos locatários. 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 acessando o menu Arquivo e selecionando Capturar tráfego.

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

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

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

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

Bloqueando aplicativos de consumo

Os aplicativos da Microsoft que oferecem suporte a contas de consumidor e contas organizacionais, como o OneDrive, às vezes podem ser hospedados na mesma URL. Isso significa que os usuários que devem acessar essa URL para fins de trabalho também têm acesso a ela para uso pessoal. Esta opção pode não ser permitida de acordo com as suas diretrizes operacionais.

Algumas organizações tentam corrigir esse problema bloqueando login.live.com para bloquear a autenticação de contas pessoais. Esta correção tem várias desvantagens:

1. O bloqueio login.live.com bloqueia o uso de contas pessoais em cenários de convidados B2B, o que pode interferir nos visitantes e na colaboração.
2. O piloto automático requer o uso de login.live.com para implantar. Os cenários do Intune e do Autopilot podem falhar quando login.live.com estão bloqueados.
3. A telemetria organizacional e as atualizações do Windows que dependem do serviço login.live.com para IDs de dispositivo deixam de funcionar.

Configuração para aplicativos de consumidor

Enquanto o Restrict-Access-To-Tenants cabeçalho funciona como uma lista de permissões, o bloqueio de conta da Microsoft (MSA) funciona como um sinal de negação, dizendo à plataforma de conta da Microsoft para não permitir que os usuários entrem em aplicativos de consumo. Para enviar esse sinal, o cabeçalho é injetado sec-Restrict-Tenant-Access-Policy no tráfego que visita login.live.com usando o mesmo proxy corporativo ou firewall mencionado na seção de requisitos e configuração de proxy deste artigo. O valor do cabeçalho deve ser restrict-msa. Quando o cabeçalho está presente e um aplicativo consumidor está tentando entrar diretamente em um usuário, esse login é bloqueado.

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

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

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

1. Tráfego sem usuário para dispositivos. Esta opção inclui tráfego para piloto automático, Windows Update e telemetria organizacional.
2. Autenticação B2B de contas de consumidores. Os utilizadores com contas Microsoft convidados a colaborar com um inquilino são autenticados no login.live.com para aceder a um inquilino de recurso.
   1. Esse acesso é controlado usando o Restrict-Access-To-Tenants cabeçalho para permitir ou negar acesso a esse locatário de recurso.
3. Autenticação de "passagem", usada por muitos aplicativos e Office.com do Azure, em que os aplicativos usam o Microsoft Entra ID para entrar em usuários consumidores em um contexto de consumidor.
   1. Esse acesso também é controlado usando o Restrict-Access-To-Tenants cabeçalho para permitir ou negar acesso ao locatário especial "passthrough" (f8cdef31-a31e-4b4a-93e4-5f571e91255a). Se este inquilino não aparecer na sua Restrict-Access-To-Tenants lista de domínios permitidos, o Microsoft Entra ID impede que as contas de consumidor iniciem sessão nestas aplicações.

Plataformas que não suportam TLS quebram e inspecionam

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 a Inspeção de Segurança da Camada de Transporte (TLSI) para interromper e inspecionar o tráfego. Para ambientes em que o lado do cliente não é capaz de quebrar e inspecionar o tráfego para adicionar cabeçalhos, as restrições de locatário não funcionam.

Tomemos o exemplo do Android 7.0 e seguintes. O Android mudou a forma como lida com autoridades de certificação (CAs) confiáveis para fornecer padrões mais seguros para o tráfego seguro de aplicativos. 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 cliente 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, uma vez 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.

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

• Acesso condicional: permita apenas o uso de dispositivos gerenciados/compatíveis
• Acesso condicional: gerencie o acesso para usuários convidados/externos
• Colaboração B2B: Restrinja as 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: Restrinja convites para usuários B2B para os mesmos domínios listados no parâmetro "Restrict-Access-To-Tenants"
• Gerenciamento de aplicativos: restrinja como os usuários consentem com os aplicativos
• Intune: Aplique a Política de Aplicações através do Intune para restringir a utilização de aplicações geridas apenas ao UPN da conta que registou o dispositivo - Marque a secção abaixo, Permitir apenas contas de organização configuradas no subtítulo das aplicações .

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

Próximos passos

• Leia sobre a autenticação moderna atualizada do Office 365
• Rever os URLs e intervalos de endereços IP do Office 365